Transport Protocols: TCP, UDP, and Beyond

If TCP is the meticulous accountant of the networking world—tracking every byte, confirming every delivery, managing complex state—then User Datagram Protocol (UDP) is the express courier who promises only to try their best and move on.

UDP, specified in the deceptively brief RFC 768 (just three pages!), takes a radically different approach from TCP. Instead of building reliability into the protocol, UDP provides essentially a thin wrapper around IP, adding only port-based multiplexing and an optional checksum. This minimalism isn't a deficiency—it's a deliberate design choice that makes UDP essential for a surprising variety of applications.

UDP embodies the principle of minimal mechanism—provide just enough functionality to be useful, and leave everything else to the application. This philosophy produces a protocol that is:

• Simple — Easy to implement, easy to understand, easy to debug
• Fast — No connection setup, no acknowledgment overhead, minimal header
• Flexible — Applications can implement exactly the reliability they need
• Scalable — No per-connection state in the protocol

What UDP provides:

1. Port-based multiplexing — Multiple applications can share a single IP address
2. Message boundaries — Datagrams are delivered as discrete units, not byte streams
3. Optional checksum — Error detection (mandatory in IPv6)

What UDP explicitly does NOT provide:

• Connection establishment or termination
• Reliable delivery (no retransmission)
• Ordering guarantees
• Flow control or congestion control
• Duplicate detection

UDP is connectionless, meaning there is no handshake, no established session, and no teardown. Each datagram is an independent unit that can be sent without any prior communication.

What 'connectionless' means in practice:

• No setup phase — The first packet can carry application data immediately
• No state maintenance — The UDP layer doesn't track conversations
• No teardown phase — Communication simply stops when there's nothing more to send
• Stateless at the transport layer — Each datagram is routed independently

The Scalability Implications

Connectionless operation has profound scalability implications:

• Server efficiency — A UDP server can handle millions of 'clients' without tracking millions of connections
• Memory usage — No per-connection buffers or control blocks
• NAT and firewall traversal — Simpler (though still imperfect) since there's no state to track
• Failure handling — If a server restarts, it can immediately resume processing; clients don't need to reconnect

Example: DNS

The Domain Name System (DNS) uses UDP precisely because of these properties. A DNS resolver might query thousands of different DNS servers. Maintaining TCP connections to all of them would be wasteful. Instead, each query is a single UDP datagram, and each response is independent.

UDP provides unreliable, best-effort delivery—packets might be lost, duplicated, or delivered out of order, and UDP won't do anything about it. This sounds problematic, but for many applications, it's exactly what's needed.

What 'unreliable' actually means:

1. No loss recovery — If a packet is dropped by a router, UDP doesn't detect or retransmit
2. No duplicate detection — If the network duplicates a packet, both copies arrive
3. No ordering — Packets may arrive in different order than sent
4. Delivery notification — No confirmation that data arrived

Why this is acceptable (or even desirable):

The Real-Time Streaming Example

Consider a live video call. Each video frame must be displayed at a precise time:

• TCP approach: If frame 50 is lost, TCP retransmits it. Frames 51-60 wait in the buffer (head-of-line blocking). By the time frame 50 arrives, it's too late—you've missed the display deadline.

• UDP approach: Frame 50 is lost. The application notices the gap, conceals the error (shows the previous frame, interpolates, or shows a brief glitch), and displays frame 51 on time. The user experience is far better than stalling.

This illustrates timeliness vs. reliability—for real-time applications, delivering data on time matters more than delivering every byte.

Unlike TCP's byte-stream abstraction, UDP provides a message-oriented (also called datagram-oriented) service. Each sendto() call produces exactly one datagram, and each recvfrom() call receives exactly one datagram.

Message boundary preservation:

• Send side: Application sends a 500-byte message → One 500-byte UDP datagram is transmitted
• Receive side: Application receives exactly 500 bytes in one read → Original message boundaries intact

This is fundamentally different from TCP, where message boundaries are lost in the byte stream.

UDP's header is remarkably simple—just 8 bytes containing four fields. This minimalism is a feature, not a limitation.

UDP Header Structure (8 bytes total):

Field Details:

Source Port (16 bits) Identifies the sending application. This is optional—a value of 0 means 'no port.' However, if the receiver needs to reply, a source port must be provided.

Destination Port (16 bits) Identifies the receiving application. This is mandatory and must correspond to a listening socket on the destination host.

Length (16 bits) The total length of the UDP datagram in bytes, including both header and data. Minimum value is 8 (header only). Maximum is 65,535, though practical limits are much lower.

Checksum (16 bits) Covers the header, data, and a pseudo-header (source/destination IP, protocol, UDP length). In IPv4, a checksum of 0 means 'no checksum computed.' In IPv6, the checksum is mandatory because IPv6 has no header checksum.

The UDP checksum provides error detection (not correction)—it detects when data has been corrupted during transmission. If the receiver calculates a different checksum than what's in the header, the datagram is silently discarded.

Checksum Calculation:

The checksum covers three components:

1. Pseudo-header — Source IP, destination IP, zero, protocol (17 for UDP), UDP length
2. UDP header — All 8 bytes
3. UDP data — The actual payload

The pseudo-header inclusion is critical—it ensures datagrams aren't accidentally delivered to the wrong host even if headers are corrupted.

IPv4 vs. IPv6 Checksum Requirements:

• IPv4: Checksum is optional. A value of 0 means 'not computed.' This was a concession to performance on early systems.

• IPv6: Checksum is mandatory. IPv6 removed the IP header checksum for efficiency, so the transport layer must ensure integrity.

Checksum Algorithm:

UDP uses the Internet Checksum algorithm:

1. Divide data into 16-bit words
2. Sum all words using one's complement arithmetic
3. Take one's complement of the result
4. Receiver performs same calculation; result should be all 1s if no errors

UDP's 'limitations' are actually advantages in many scenarios. Let's examine why UDP often outperforms TCP:

1. Zero Connection Setup Latency

The first UDP datagram carries data. Compare:

• TCP: SYN → SYN-ACK → ACK with data (1.5 RTT minimum before data)
• UDP: Data → Response (0.5 RTT for request-response)

For short exchanges like DNS queries, UDP completes before TCP even finishes handshaking.

2. No Head-of-Line Blocking

In TCP, if segment N is lost, segments N+1, N+2, ... wait even if they've arrived. In UDP, each datagram is independent—loss of one doesn't affect others.

3. No Congestion Control Interference

TCP's congestion control can throttle applications even when the receiver and network have capacity. UDP lets applications control their own rate.

4. Multicast and Broadcast Support

TCP is unicast-only. UDP supports sending to multiple recipients simultaneously, essential for service discovery, streaming, and real-time updates.

Understanding where UDP is used reveals why its characteristics matter. Here are the most important UDP-based applications:

Case Study: DNS

DNS is the perfect UDP use case:

1. Request-response pattern — One query, one answer
2. Small payloads — Typically under 512 bytes (original limit)
3. Latency sensitive — Every webpage load waits for DNS
4. Idempotent — Repeating a query is harmless
5. Timeout and retry — Simple reliability at application layer

DNS does support TCP (for large responses and zone transfers), but the vast majority of queries use UDP.

Case Study: VoIP

Voice over IP illustrates the real-time tradeoff:

1. Audio is sampled every 20ms, producing ~160 bytes/sample
2. Playback is continuous—samples must arrive on time
3. If a sample is lost, the next sample arrives 20ms later
4. Retransmitting the lost sample would take at least one RTT (often 50-150ms)
5. By the time retransmit arrives, you've played 3-8 more samples
6. Concealing the gap (interpolation, silence) sounds better than glitching

UDP represents a fundamentally different philosophy from TCP—minimal mechanism, maximum flexibility. Let's consolidate the key concepts:

What's next:

TCP and UDP represent two extremes: full reliability with overhead, or minimal service with flexibility. But what if you need something in between—or something that combines features of both? The next page explores SCTP (Stream Control Transmission Protocol), which offers message boundaries with reliable delivery, multiple streams in one connection, and other features that neither TCP nor UDP provide.