Tags: web-dev concept

TCP and UDP

Date: 2026-08-17

---

Two ways of moving bytes across a network: one guarantees delivery and order at the cost of waiting, the other guarantees nothing and doesn’t wait. The whole web ran on the first until HTTP/3 rebuilt the guarantees on top of the second.

---

TCP (Transmission Control Protocol) provides a reliable, ordered stream of bytes. UDP (User Datagram Protocol) sends individual packets with no guarantees at all.

TCP                      UDP
connection first         no connection
ordered delivery         any order
retransmits losses       losses just vanish
flow + congestion        no control
  control
higher latency           lower latency

The TCP handshake

Establishing a connection costs a full round trip before any data moves:

CLIENT                      SERVER
  │  SYN            ────────→│
  │←────────    SYN-ACK      │
  │  ACK            ────────→│
  │                          │
  │  now data can flow       │

One round trip of pure setup, and TLS adds one or two more on top — which on a 100ms connection is 200–300ms before the request is even sent — TLS and HTTPS, Latency and Bandwidth.

Head-of-line blocking

TCP’s defining cost, and the reason HTTP/3 exists.

Because TCP guarantees order, a lost packet stops everything behind it:

packets:  1  2  ✗  4  5  6
                 ↑ lost

TCP delivers: 1, 2, ...waiting...
4, 5 and 6 have ARRIVED and are sitting
in a buffer, undeliverable, until 3 is
retransmitted and received

The application is blocked on data it already has. On a page multiplexing many resources over one connection — which is exactly what HTTP/2 does — one lost packet stalls every stream at once — HTTP Versions.

Why UDP, then

No connection, no ordering, no retransmission — so no head-of-line blocking and no handshake. The application decides what reliability it wants.

USES
DNS lookups          one small question
video and voice      a late frame is worse
                     than a missing one
gaming               same
QUIC / HTTP/3        reliability rebuilt
                     on top, per stream

QUIC is the interesting one. It takes UDP and reimplements ordering and loss recovery per stream rather than per connection, so a lost packet in one stream doesn’t block the others. It also folds the TLS handshake into the connection setup, cutting a round trip.

HTTP/2 over TCP     one lost packet
                    stalls ALL streams

HTTP/3 over QUIC    one lost packet
                    stalls ONE stream

That’s the whole argument for HTTP/3, and it matters most on exactly the connections that are already worst — mobile, lossy, high-latency.

Congestion control and slow start

TCP doesn’t know the available bandwidth, so it probes: start conservatively, increase until loss occurs, back off.

The practical consequence is “slow start” — a new connection cannot use full bandwidth immediately. It takes several round trips to ramp up.

early round trips send only a few
packets, regardless of your bandwidth

→ small responses early in a connection
  are effectively free
→ a large response on a cold connection
  is slower than the same response on a
  warm one

This is why connection reuse matters more than it looks, and why opening a new connection per third-party domain is expensive beyond the handshake.

What this means for web work

• Reuse connections. Keep-alive, HTTP/2 multiplexing, fewer distinct hostnames
• preconnect for domains you’ll definitely use — it pays the handshake and slow start during idle time
• Round trips are the unit of cost, not kilobytes. Ten small requests are worse than one larger one on a high-latency link
• HTTP/3 helps most on poor networks and barely at all on a fast wired connection — which is why benchmark results disappoint and real-user metrics improve
• You will never write TCP code. What you’ll do is make decisions — connection count, resource count, hostname count — whose cost is set by it