TCP vs UDP Tradeoffs

TCP provides an abstraction of a reliable, ordered, error-checked stream of octets:

• Sequence Numbers: Packets arriving out of order are reassembled into the exact original sequence. Each byte has a unique 32-bit sequence number.
• Acknowledgments (ACK) & Retransmissions: If an ACK is not received within the Retransmission Timeout (RTO), the packet is resent. RTO starts at ~200ms and doubles exponentially with each failure (exponential backoff), capping at ~120 seconds.
• Flow Control: The receiver advertises its available buffer size (receive window) to prevent buffer overflow at the receiver.
• Congestion Control: Algorithms dynamically adjust the congestion window (cwnd) to avoid saturating network pipes. TCP starts slowly (Slow Start: doubles cwnd each RTT) then probes bandwidth (Congestion Avoidance: +1 MSS per RTT) until packet loss is detected.

CUBIC (default on Linux since 2006): Loss-based algorithm. It increases cwnd aggressively in a cubic function of time since the last congestion event. When packet loss is detected, it cuts cwnd by 30% and recovers. CUBIC performs well on high-bandwidth, high-latency (BDP) links like trans-oceanic cables.

BBR (Bottleneck Bandwidth and RTT) (Google, 2016): Model-based algorithm. Instead of reacting to packet loss, BBR continuously estimates the bottleneck bandwidth and minimum RTT to keep the pipe full without creating excessive queue depth. BBR achieves significantly higher throughput on lossy links (mobile, satellite) and reduces buffer bloat. YouTube's migration to BBR increased throughput by 4% globally and reduced RTT by 14%.

UDP simply wraps data in an 8-byte header (Source Port, Dest Port, Length, Checksum) and transmits it without maintaining connection state. There is no handshake, no acknowledgment, no retransmission.

Why UDP wins in Real-Time Systems: If you are streaming a live 60 FPS multiplayer game or video call (WebRTC), a dropped frame is instantly obsolete. Waiting for TCP to retransmit a dropped packet causes Head-of-Line Blocking — the entire stream stalls waiting for one retransmission. With UDP, the application receives the next frame and simply skips the dropped one. Modern video codecs (VP9, AV1, H.265) are designed to handle periodic frame drops gracefully with interpolation.

HTTP/3 runs on QUIC, which is built on top of UDP in user-space. Google designed QUIC to solve TCP's fundamental limitations without requiring kernel changes.

Key QUIC innovations:

• Independent multiplexed streams: A packet loss on stream 1 does NOT block stream 2. TCP HOL blocking is eliminated because streams are fully independent.
• Built-in TLS 1.3: The QUIC handshake incorporates TLS 1.3 cryptography — connection + encryption negotiated in 1-RTT (vs 2-RTT for TCP + TLS 1.3 separately).
• 0-RTT for returning connections: Clients cache a "resumption token" — next connection sends encrypted data in the very first packet with zero round trips.
• Connection migration: QUIC connections are identified by a Connection ID (not IP+Port), so switching from WiFi to LTE does not drop the connection.

Real-world QUIC adoption: Google serves >50% of its traffic over QUIC. Facebook/Meta, Cloudflare, Netflix, and AWS CloudFront all support HTTP/3.