TCP vs UDP

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two primary transport-layer protocols in the Internet protocol suite. Every networked application must choose one (or, increasingly, build on top of UDP with custom reliability), and the choice fundamentally shapes the application's latency, throughput, and failure characteristics. Understanding both protocols at a deep level is essential for system design because the transport layer determines how data is framed, delivered, and recovered across unreliable networks.

TCP is a connection-oriented protocol that establishes a session between two endpoints through a 3-way handshake (SYN, SYN-ACK, ACK) before any data is exchanged. Once connected, TCP guarantees reliable delivery through sequence numbers and acknowledgments -- every byte sent is numbered, the receiver ACKs received bytes, and the sender retransmits anything not acknowledged within a timeout. TCP also guarantees ordering: bytes arrive at the application in the exact order they were sent, even if the underlying IP packets arrive out of order. Flow control via the sliding window mechanism prevents a fast sender from overwhelming a slow receiver. Congestion control algorithms (from classic Reno/NewReno to modern CUBIC and BBR) dynamically adjust the sending rate to avoid overwhelming the network. These guarantees make TCP the default choice for HTTP, database connections, file transfers, email, and any protocol where correctness trumps latency.

UDP is a connectionless protocol with a minimal 8-byte header -- no handshake, no sequence numbers, no acknowledgments, no flow control, no congestion control. Each datagram is independent: the sender fires it into the network, and the receiver either gets it or does not. There is no retransmission, no ordering guarantee, and no mechanism to detect or adapt to network congestion. This minimalism is UDP's strength: without the overhead of connection establishment, acknowledgment tracking, and retransmission timers, UDP achieves significantly lower latency and supports use cases where losing a few packets is preferable to waiting for retransmissions. Real-time voice (VoIP), video streaming, online gaming, and DNS queries all rely on UDP because a slightly degraded experience from packet loss is better than the latency spikes and head-of-line blocking that TCP's reliability mechanisms introduce.

The modern networking landscape has evolved beyond the simple TCP-vs-UDP binary. QUIC, originally developed by Google and now standardized as RFC 9000, builds reliability and multiplexing on top of UDP. QUIC provides the guarantees that applications need (reliable delivery, ordering within streams, encryption) without TCP's head-of-line blocking problem, where a single lost packet in a TCP connection stalls all multiplexed streams. QUIC achieves 0-RTT connection resumption, per-stream flow control, and integrated TLS 1.3 encryption. HTTP/3 runs on QUIC, and as of 2026 roughly 30% of web traffic uses HTTP/3 over QUIC over UDP. This shift demonstrates a broader trend: rather than choosing between TCP and UDP, modern protocols choose UDP as the transport and build exactly the reliability semantics they need at the application layer.

TCP is like a phone call: you dial, wait for the other person to pick up (handshake), confirm they can hear you, then have an ordered conversation where you repeat anything they missed. If the line drops, you both know and reconnect. UDP is like sending text messages: you fire them off without checking if the recipient is ready, they might arrive out of order, some might get lost, and you will never know unless the recipient tells you. For a business negotiation (database transaction), you want the phone call. For shouting game coordinates to your teammate while dodging bullets (real-time gaming), rapid-fire texts are better even if a few get lost.