Transport services and UDP
The transport layer turns host-to-host delivery into process-to-process communication. UDP offers the simplest version of that service.
What the transport layer does
IP delivers datagrams between hosts on a best-effort basis: they may be lost, duplicated, reordered, or corrupted. The transport layer, running only in end hosts, extends this to communication between processes, adding multiplexing and, depending on the protocol, reliability, ordering, flow control, and congestion control.
Multiplexing and demultiplexing
Many applications on a host share one network connection. When sending, the transport layer gathers data from sockets and adds headers with source and destination port numbers: multiplexing. When receiving, it uses those ports to deliver each segment to the correct socket: demultiplexing. A UDP socket is identified by destination IP and port; a TCP connection by source IP, source port, destination IP, and destination port.
UDP
The User Datagram Protocol (UDP), defined in RFC 768 in 1980, adds almost nothing to IP: an 8-byte header with source port, destination port, length, and checksum. There is no connection setup, no reliability, no ordering, and no congestion control. Each message is sent as one datagram and either arrives intact or not at all.
Why use UDP
UDP has no handshake delay, no connection state, and small headers, and it lets applications send at whatever rate they choose. It suits DNS queries (one request, one reply), live voice and video (where late data is useless), online games, network management (SNMP), and streaming protocols. Applications can build their own reliability on top, as QUIC does.
The checksum
The UDP and TCP checksums detect corruption: the sender computes the ones' complement of the ones' complement sum of the segment's 16-bit words, including a pseudo-header with IP addresses; the receiver repeats the sum, and any result other than all ones indicates an error. The checksum catches most accidental errors but is weak against deliberate tampering, which cryptography handles.
Principles of reliable delivery
Building reliability over an unreliable channel requires error detection (checksums), receiver feedback (acknowledgements, ACKs, and sometimes negative acknowledgements), retransmission after timeouts, and sequence numbers to detect duplicates and order data. The simplest protocol, stop-and-wait, sends one packet and waits for its ACK before sending the next.
Pipelining
Stop-and-wait wastes capacity: on a 1 Gbit/s link with 30 ms RTT, sending one 1,500-byte packet per round trip uses about 0.04% of the link. Pipelined protocols keep many unacknowledged packets in flight. Go-Back-N retransmits everything from a lost packet onward; selective repeat retransmits only the lost packets, using receiver buffers to hold out-of-order arrivals.
Worked example
Stop-and-wait utilisation: transmission time of a 12,000-bit packet at 1 Gbit/s is 12 microseconds. With RTT 30 ms, the sender is busy for 0.012 ms in every 30.012 ms: about 0.04%. To fill the link, about 30.012 / 0.012, or roughly 2,500 packets, must be in flight at once, which is why windows of many packets are essential on fast, long paths.
Key takeaways
The transport layer runs in hosts and turns host-to-host delivery into process-to-process communication via multiplexing and demultiplexing with port numbers. UDP (RFC 768) adds only ports, length, and a checksum: no connections, reliability, ordering, or congestion control. UDP suits DNS, real-time media, games, and protocols like QUIC that add their own features. Checksums detect accidental corruption. Reliable delivery needs checksums, ACKs, timeouts, retransmission, and sequence numbers. Stop-and-wait wastes fast links; pipelining with Go-Back-N or selective repeat keeps many packets in flight.
Flashcard
Process-to-process communication
Check your understanding
Why does DNS normally use UDP rather than TCP for queries?