system-design · beginner

TCP vs UDP — Reliable Streams vs Lightweight Datagrams

The Central Question

Consider two real-time network applications operating over the internet:


Using the same transport protocol for both applications would lead to catastrophic failures.

At Layer 4 of the OSI model, two transport protocols dominate network communication: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).

This lesson answers one central question: How do TCP (connection-oriented, reliable in-order byte stream) and UDP (connectionless, low-overhead datagrams) govern transport-layer data delivery, and how do engineers choose between TCP reliability guarantees and UDP low-latency execution?


Defining the Transport Layer: Ports and Demultiplexing

While IP (Internet Protocol) routes packets between computer IP addresses, transport layer protocols (TCP and UDP) utilize Port Numbers (e.g. Port 80, 443, 53) to deliver data to specific software processes running on a host.

flowchart TD
  IPPacket[Network IP Packet<br/>Src IP: 203.0.113.5 | Dst IP: 198.51.100.10] --> Demux{Transport Layer Header}
  Demux -->|TCP Port 443| WebServer[Web Server Process - Nginx]
  Demux -->|TCP Port 5432| DBServer[PostgreSQL DB Process]
  Demux -->|UDP Port 53| DNSServer[CoreDNS Process]

Figure 1: Transport layer port demultiplexing routing packets to application processes.

Ephemeral Ports and Network Address Translation (NAT)

When a client application initiates an outgoing socket connection to a server, the operating system kernel dynamically assigns a temporary **Ephemeral Port** (typically in the range 49152–65535) to identify the local client socket.

When traffic passes through home routers or cloud NAT gateways, Network Address Translation (NAT) maps multiple internal private IP addresses and ephemeral ports to a single public IP address. NAT routers maintain state tables tracking active TCP connection states and UDP datagram mappings, allowing response packets from public servers to be routed back accurately to the correct internal client device.


TCP: The Reliable Connection-Oriented Byte Stream

TCP presents application code with a continuous, ordered, reliable stream of bytes. TCP guarantees that data sent across a network arrives completely, un-duplicated, and in the exact sequence it was transmitted.

flowchart LR
  subgraph TCP Core Guarantees
    G1[1. Connection Setup: 3-Way Handshake]
    G2[2. Reliable Delivery: ACKs & Automatic Retransmission]
    G3[3. In-Order Sequencing: Sequence Numbers]
    G4[4. Flow & Congestion Control: Sliding Windows]
  end

Figure 2: The four core reliability mechanisms provided by TCP.

1. TCP 3-Way Handshake Connection Setup

Before transmitting application bytes, TCP establishes a virtual connection between client and server via a **3-Way Handshake**:
sequenceDiagram
    autonumber
    actor Client as Client Socket
    participant Server as Server Socket
    
    Note over Client,Server: Phase 1: TCP 3-Way Handshake Setup
    Client->>Server: SYN (Seq = x)
    Server-->>Client: SYN-ACK (Seq = y, Ack = x + 1)
    Client->>Server: ACK (Seq = x + 1, Ack = y + 1)
    Note over Client,Server: Connection ESTABLISHED (Data can flow)
    
    Note over Client,Server: Phase 2: TCP 4-Way Teardown (Termination)
    Client->>Server: FIN (Seq = x + 100)
    Server-->>Client: ACK (Ack = x + 101)
    Server->>Client: FIN (Seq = y + 200)
    Client-->>Server: ACK (Ack = y + 201)
    Note over Client,Server: Connection CLOSED

Figure 3: Sequence diagram detailing the TCP 3-way handshake setup and 4-way teardown.

2. Sequence Numbers, Acknowledgments (ACKs), and Retransmission

TCP breaks application byte streams into segments, assigning an incremental **Sequence Number** to every byte.

3. Flow Control and Congestion Control


Modern Congestion Control: TCP BBR vs. Loss-Based Cubic

Traditional TCP congestion control algorithms (like TCP Cubic) treat packet loss as the sole signal of network congestion. When a single router buffer overflows and drops a packet, Cubic slashes the sender's transmission window by 50%.

In modern cloud networks with high-speed links and deep router buffers, loss-based algorithms suffer from severe latency degradation known as Bufferbloat.

Modern infrastructure platforms deploy BBR (Bottleneck Bandwidth and RTT):

flowchart TD
  BBR[Google TCP BBR Algorithm] --> Model1[1. Measures Bottleneck Bandwidth: Max delivery rate]
  BBR --> Model2[2. Measures Min Round-Trip Time: Physical propagation delay]
  
  Model1 --> MaxThroughput[Paces transmissions at exact link capacity WITHOUT filling router queues]
  Model2 --> MaxThroughput

Figure 4: BBR congestion control model pacing traffic to prevent bufferbloat.

Why BBR Outperforms Cubic

Instead of filling router queues until packets drop, BBR continuously models the physical bottleneck bandwidth and minimum RTT of the network path. It paces packet transmissions to maximize throughput while keeping queue lengths near zero, reducing p99 tail latency by up to 10x over lossy networks.

UDP: Lightweight, Connectionless Datagrams

UDP is a minimal, connectionless transport protocol. It wraps application data in a lightweight header containing source/destination ports and a checksum, then transmits the packet directly onto the network as an independent Datagram.

flowchart TB
  App[Application Data Payload] --> UDPHeader[UDP Header: Ports + Length + Checksum]
  UDPHeader --> IP[IP Packet Output]
  
  style UDPHeader fill:#fff3cd,stroke:#ffebaa

Figure 5: Anatomy of a lightweight UDP datagram.

What UDP Does NOT Provide


Head-of-Line (HOL) Blocking: The Latency Penalty of TCP

Because TCP guarantees strict in-order byte delivery, a single dropped packet stalls all subsequent data bytes arriving behind it:

sequenceDiagram
    autonumber
    actor Client as Receiver Socket Buffer
    participant Net as Network Link
    participant Server as Sender
    
    Server->>Net: Send Packet 1, Packet 2, Packet 3
    Net-->>Client: Packet 1 Arrives (Delivered to App)
    Net--xClient: PACKET 2 DROPPED IN TRANSIT!
    Net-->>Client: Packet 3 Arrives (Held in TCP Buffer)
    
    Note over Client: Head-of-Line Blocking!<br/>Packet 3 cannot be delivered to application<br/>until Packet 2 is retransmitted & ACKed!
    
    Server->>Net: Retransmit Packet 2
    Net-->>Client: Packet 2 Arrives
    Note over Client: Buffer Unlocked! Packet 2 & 3 delivered to App.

Figure 6: Sequence diagram illustrating Head-of-Line (HOL) blocking in TCP.


Architectural Comparison: TCP vs. UDP

Feature / VectorTCP (Transmission Control Protocol)UDP (User Datagram Protocol)
Connection ModelConnection-Oriented (Requires Handshake).Connectionless (No Setup).
Data FormatContinuous Byte Stream.Discrete Datagram Messages.
Delivery GuaranteeGuaranteed (Automatic Retransmissions).Best-Effort (Un-guaranteed).
Ordering GuaranteeGuaranteed (In-order Sequence Numbers).Un-ordered (Packets may arrive out of order).
Head-of-Line BlockingYes (Packet loss stalls subsequent bytes).No (Datagrams processed independently).
Header Size20 Bytes (up to 60 with options).8 Bytes.
Congestion ControlBuilt-in (Cubic, BBR).None (Application responsibility).

Socket API Pseudocode: Code-Level Differences

Application code interacts with TCP and UDP using distinct OS socket types:

1. TCP Socket Pseudocode (SOCK_STREAM)

import socket

Create TCP Stream Socket

server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.bind(('0.0.0.0', 8080)) server_socket.listen(128) # Listen for incoming TCP handshakes

Accept connection (Completes 3-Way Handshake)

client_socket, client_address = server_socket.accept()

Read from continuous byte stream

data = client_socket.recv(4096) client_socket.sendall(b"HTTP/1.1 200 OK\r\n\r\n") client_socket.close()

2. UDP Socket Pseudocode (SOCK_DGRAM)

import socket

Create UDP Datagram Socket

udp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) udp_socket.bind(('0.0.0.0', 5353))

Receive discrete datagram payload directly (No connection setup)

data, client_address = udp_socket.recvfrom(512)

Send discrete datagram payload back

udp_socket.sendto(b"\x81\x80ResponseData", client_address)

Complete Worked Example: CheckoutLab Platform Protocol Selection

Let's inspect the transport protocol selection across different services in the CheckoutLab platform (checkoutlab.com).

flowchart TD
  Platform[CheckoutLab Network Platform] --> Service1[1. REST Payment API]
  Platform --> Service2[2. Live Telemetry Stream]
  Platform --> Service3[3. Internal DNS Resolution]
  
  Service1 -->|Requires 100% Data Integrity| TCP1[TCP + TLS 1.3 - Port 443]
  Service2 -->|Requires Lowest Latency - Drop Old Stats| UDP1[UDP Metrics Collector - Port 8125]
  Service3 -->|Requires Fast 1-RTT Small Lookups| UDP2[UDP DNS - Port 53]

Figure 7: Decision tree selecting transport protocols for diverse platform workloads.


Failure Modes and Engineering Mitigations

Failure ScenarioRoot CauseSystem SymptomDetection MetricMitigation Strategy
1. TCP Head-of-Line StallingUnstable cellular network causes 5% packet loss on an HTTP/2 connection.Web app freezes; all parallel multiplexed HTTP streams stall waiting for TCP retransmission.High TCP retransmit rates and elevated p99 user response latency.Upgrade transport to HTTP/3 (QUIC over UDP) to isolate packet loss to individual streams.
2. Un-controlled UDP Network FloodCustom UDP application sends data at 10 Gbps without congestion control logic.Network routers drop packets globally, causing severe bufferbloat for adjacent services.High packet drop rates on network switches and router buffer overflows.Implement application-level congestion control and rate limiting on custom UDP protocols.
3. TCP Idle Connection DropStateful firewall or NAT router drops idle TCP socket state after 5 minutes.Client app attempts to reuse socket, resulting in connection reset errors (RST).High connection_reset_by_peer error spikes on long-lived connections.Implement TCP Keep-Alive probes (SO_KEEPALIVE) or application-level ping/pong heartbeats.
4. Assuming TCP Implies Application IdempotencyDevelopers assume TCP reliability guarantees that business transactions execute once.Network socket drops after server processes mutation; client retry double-executes charge.Duplicate transaction records in application database.Enforce application-level Idempotency-Key headers on all state-mutating HTTP POST requests.

What You Should Remember

  1. TCP is a reliable in-order byte stream: TCP uses handshakes, ACKs, retransmissions, and flow control to guarantee complete, ordered data delivery.
  2. UDP is a lightweight datagram protocol: UDP sends independent messages without handshakes, ACKs, or retries, offering minimal latency overhead.
  3. TCP causes Head-of-Line (HOL) blocking: Dropped TCP packets stall all subsequent bytes in the stream until the missing segment is retransmitted.
  4. BBR prevents bufferbloat: Modern BBR congestion control paces TCP transmissions based on bottleneck bandwidth rather than packet loss.
  5. TCP reliability does not equal application idempotency: TCP guarantees byte delivery; application code must still enforce idempotency keys to handle retries safely.

Glossary of Terms

TermDefinition
TCP (Transmission Control Protocol)A connection-oriented transport protocol providing reliable, ordered byte stream delivery.
UDP (User Datagram Protocol)A connectionless transport protocol providing lightweight, best-effort datagram delivery.
Port NumberA 16-bit integer in transport headers used to route data packets to specific application processes.
Ephemeral PortA temporary high-numbered port assigned dynamically by the operating system kernel for outgoing client connections.
3-Way HandshakeThe TCP connection setup sequence consisting of SYN, SYN-ACK, and ACK packets.
Head-of-Line (HOL) BlockingThe delay phenomenon where a lost packet stalls the delivery of subsequent arrived packets in a stream.
TCP BBRA congestion control algorithm that paces transmissions based on bottleneck bandwidth and round-trip time.

Practice Scenario and Self-Assessment

Architecture Scenario

You are designing the networking architecture for an online multiplayer battle-royale game. The game engine requires:
  1. Player Authentication & Store Purchases (Must be 100% reliable)
  2. Real-time Player Position Synchronization (60 updates/sec, low latency)
  3. In-Game Text Chat (Reliable text delivery)
**Questions**:
  1. Recommend TCP or UDP for each of the three game networking requirements and justify your choice.
  2. Explain how Head-of-Line blocking would degrade gameplay if player position synchronization were implemented over standard TCP connections.

Interactive Self-Assessment

UDP avoids TCP Head-of-Line blocking delays, allowing applications to drop stale packets rather than freezing for retransmissions.

UDP automatically encrypts all voice data using hardware AES encryption.

UDP requires a complex 5-way handshake that verifies audio quality.

UDP guarantees that audio packets always arrive in perfect sequential order.

Subsequent arrived packets are held in the OS buffer and cannot be delivered to application code until the missing packet is retransmitted.

The OS buffer immediately deletes all subsequent arrived packets.

The TCP socket connection is forcibly closed with an HTTP 500 error.

The TCP socket automatically converts the stream into UDP datagrams.


What to Learn Next

Track: Reliability and Operations

Previous: Single Point of Failure (SPOF) — Identifying and Eliminating SPOFs

Next: Thundering Herd

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab