TCP vs UDP: Core Transport Layer Guarantees and System Impact

TCP and UDP represent fundamentally different philosophies at the transport layer. TCP provides a reliable, ordered byte stream with built in congestion control, flow control, automatic retransmissions, and a three way handshake. This reliability comes at a cost: connection setup adds 1 to 2 RTTs (100 to 200 ms on typical mobile links), head of line blocking occurs when a single lost packet stalls all subsequent data, and kernel state per connection limits scalability. For example, on a path with just 1% packet loss and 100 ms RTT, TCP tail latency can spike by 200 to 300 ms due to retransmission delays.

UDP is a minimal, connectionless datagram service with no reliability, ordering, or congestion control. It exposes raw IP delivery to the application. While this eliminates TCP's overhead and head of line blocking, applications must implement their own reliability mechanisms, pacing, congestion control, and ordering when needed. The key insight is that the choice is not binary: many production systems use UDP to build custom transports tailored to specific workloads. Google's QUIC (HTTP/3) achieves 1 RTT handshakes for new connections and 0 RTT for resumptions, saving 100 to 200 ms compared to TCP plus TLS. Google reported 8% reduction in search latency and 18 to 30% reduction in YouTube rebuffering on challenging networks.

The trade off is where reliability lives and how it behaves under loss. TCP's reliability is opaque and stream oriented; every byte must arrive in order. UDP gives you control over what to protect, when to retransmit, and how to prioritize, but requires significantly more engineering investment and careful attention to being a good network citizen.

💡 Key Takeaways

•TCP adds 1 to 2 RTT connection setup latency (100 to 200 ms on mobile) while UDP enables 0 to 1 RTT custom handshakes, directly impacting time to first byte

•Head of line blocking in TCP means a single lost packet stalls all subsequent bytes; at 1% loss, tail latencies can inflate by 200 to 300 ms on long RTT paths

•Google's QUIC over UDP achieved 8% search latency reduction and 18 to 30% fewer YouTube rebuffers by eliminating TCP's connection level head of line blocking

•TCP maintains per connection kernel state and enforces in order delivery; UDP is stateless and lets applications choose message semantics and selective reliability

•UDP based transports require implementing congestion control, pacing, and fairness mechanisms to avoid self inflicted network collapse and packet loss

•Production systems typically choose TCP for bulk transfer and strict ordering needs, UDP for interactive real time workloads where 100 to 200 ms latency matters

📌 Examples

Google QUIC on Chrome saves 100 to 200 ms per page load on mobile by using 0 RTT resumption vs TCP's 1 to 2 RTT handshake plus TLS negotiation

HTTP/2 over single TCP connection: one lost packet blocks all multiplexed streams. HTTP/3 over QUIC with UDP: loss only blocks the affected stream, improving p99 latency

Database replication typically uses TCP because strict in order delivery guarantees are essential and the complexity of custom reliability is not justified

Real time conferencing (Google Meet, Microsoft Teams) uses UDP with WebRTC because 0.5 to 3% loss on Wi-Fi would cause 100 to 300 ms added latency and freezes if forced over TCP

← Back to TCP vs UDP Trade-offs Overview