The Transport Layer — The Invisible Courier Between Applications
Royal Mail (TCP) — tracked delivery, signed receipt, guaranteed order, returned if undelivered. Slower, more overhead, but nothing gets lost. Your solicitor uses this for legal contracts.
Motorbike Courier (UDP) — no tracking, no receipt, no guarantee. But it's fast and cheap. Your pizza delivery app uses this for GPS location updates — if one position message is lost, the next one arrives anyway and nobody cares.
Both services sit on top of the same road network (the Internet / IP layer). Neither cares how the roads are laid out — they just use them. That is the Transport Layer: a service on top of IP that gives applications the delivery guarantee (or lack thereof) they need.
The Transport Layer (Layer 4) in the OSI model sits between the Network Layer (IP routing) and the Application Layer (HTTP, DNS, FTP). Its job is to provide logical communication between application processes running on different hosts — not just between hosts themselves. It does this using port numbers to identify which application on a machine should receive each packet.
IP (Network Layer) delivers packets to the correct machine
using IP addresses. It has no idea which application on that machine should
receive the data.
Transport Layer delivers data to the correct application process
on that machine using port numbers. When your browser and Spotify both run on
your laptop simultaneously, transport layer multiplexing ensures HTTP traffic
goes to Chrome and audio streams go to Spotify — not the other way around.
Transport Layer — Core Responsibilities
Port Numbers — The Addressing System
UDP — User Datagram Protocol
UDP (RFC 768, 1980) is the minimalist of the transport layer. It provides almost nothing beyond IP — just port-based demultiplexing and an optional checksum. No connection, no ordering, no retransmission, no flow control. What it lacks in reliability, it makes up in speed and simplicity.
| Field | Size | Purpose |
|---|---|---|
| Source Port | 16 bits | Sender's port (optional, can be 0) |
| Destination Port | 16 bits | Receiver's application port |
| Length | 16 bits | Header + data length in bytes |
| Checksum | 16 bits | Error detection (optional in IPv4) |
Total overhead: 8 bytes vs TCP's 20+ bytes. No connection state maintained anywhere.
| Application | Why UDP |
|---|---|
| DNS (port 53) | One request, one reply — no connection needed |
| Video streaming | Late packet is useless — better to skip |
| VoIP / Gaming | Low latency beats perfect delivery |
| DHCP (port 67/68) | Broadcast-based — TCP can't broadcast |
| QUIC (HTTP/3) | Reliability built in user space over UDP |
| SNMP (port 161) | Polling protocol; loss tolerable |
Applications that need reliability on top of UDP build it themselves — with exactly the semantics they need. QUIC (used by HTTP/3 and YouTube) reimplements TCP-like reliability with better performance because it can avoid head-of-line blocking, deploy faster (no OS kernel update needed), and use 0-RTT connection resumption. UDP is the canvas; reliability is the painting the application chooses to draw.
TCP — Transmission Control Protocol
TCP (RFC 793, 1981) is the backbone of the web. It guarantees that every byte sent by the application arrives at the destination in order, exactly once, without corruption. It achieves this through connection management, sequence numbers, acknowledgements, retransmission, flow control, and congestion control — all working together transparently beneath every HTTP, HTTPS, SSH, and SMTP session you use.
🏭 Interactive: TCP Header — Every Field Explained
The TCP header is a masterpiece of 1981 engineering that still underpins the entire web. It is 20 bytes minimum (160 bits) with up to 40 bytes of options — compared to UDP's flat 8 bytes. Every bit is there for a reason. Click any field in the diagram below to see a deep explanation.
💡 TCP header is drawn to scale in bit-widths. One row = 32 bits. The minimum header is 5 rows × 32 bits = 160 bits = 20 bytes. Options can add up to 40 more bytes (max header = 60 bytes).
TCP Options — Deep Dive
The Timestamps option carries two 32-bit values in every segment: the sender's
current clock (TSval) and an echo of the peer's most recent
timestamp (TSecr). This enables two critical features:
1. Accurate RTT Measurement — even when retransmissions make
it ambiguous which ACK corresponds to which send (Karn's algorithm problem).
2. PAWS — Protection Against Wrapped Sequence Numbers — a 32-bit
sequence number wraps after 4 GB. At 10 Gbps that takes 3 seconds. Without PAWS,
an old segment from a previous connection could be mistakenly accepted. Timestamps
let the receiver reject segments with timestamps older than recent ones.
| Field | Bits | Purpose | Key Value / Range |
|---|---|---|---|
| Source Port | 16 | Sending application identifier | 0–65535 (ephemeral: 49152–65535) |
| Destination Port | 16 | Receiving application identifier | Well-known: 0–1023 · Registered: 1024–49151 |
| Sequence Number | 32 | Byte offset of first data byte | 0 – 2³²−1 (wraps at ~4 GB) |
| Acknowledgement No. | 32 | Next expected byte from peer | Cumulative ACK — acks all prior bytes |
| Data Offset | 4 | Header length in 32-bit words | 5 (=20B min) – 15 (=60B max) |
| Reserved | 3 | Future use — must be 0 | Partially used by ECN (RFC 3168) |
| Flags | 9 | Connection control bits | NS CWR ECE URG ACK PSH RST SYN FIN |
| Window Size | 16 | Receive buffer space (rwnd) | 0–65535 bytes (× scale factor if WS option) |
| Checksum | 16 | Error detection (mandatory) | One's complement of header + data + pseudo-hdr |
| Urgent Pointer | 16 | Offset of urgent data (if URG=1) | Rarely used — Telnet era legacy |
| Options | 0–320 | Extensions (MSS, WScale, SACK, TS) | Padded to 32-bit boundary |
🏭 Animated: TCP 3-Way Handshake — Connection Establishment
Before a single byte of application data is exchanged, TCP establishes a connection — a shared understanding of initial sequence numbers, window sizes, and supported options. This takes exactly 1.5 RTT (one-and-a-half round trips) and is called the 3-way handshake.
💡 The Initial Sequence Number (ISN) is chosen randomly — not starting at 0 — to prevent old duplicate segments from a previous connection being mistakenly accepted. Each side picks its own ISN independently.
An attacker sends thousands of SYN packets with spoofed source IPs. The server
replies with SYN-ACK and allocates a half-open connection entry — waiting for
the final ACK that never comes. The server's connection table fills up, and
legitimate connections are refused. This is a SYN Flood DDoS attack.
Defence: SYN Cookies — the server encodes connection state
in the sequence number of the SYN-ACK, eliminating the need to store half-open
state. The 2016 Dyn DNS attack that took down Twitter, Netflix, and Reddit used
SYN floods as one of its vectors. Source: Cloudflare, October 2016.
TCP Flow Control — Receiver Protects Its Own Buffer
What if the sender is blazingly fast but the receiver is a slow mobile device? Without flow control, the receiver's buffer would overflow and packets would be silently dropped — then retransmitted — wasting bandwidth. TCP's flow control prevents this using the Receiver Window (rwnd) advertised in every ACK.
TCP flow control works identically. The receiver shouts its current buffer space in every ACK (
window=X bytes). The sender must never
have more than X bytes outstanding. When the receiver drains its buffer
(the application reads the data), it sends a larger window and the sender
speeds up again.
💡 When rwnd=0, the sender stops completely. It sends 1-byte window probe segments periodically to check if the receiver has freed space. This prevents permanent deadlock if the window-update ACK is lost.
TCP Congestion Control — Slow Start & Congestion Avoidance
Flow control protects the receiver. Congestion control protects the network. The sender also self-limits with a Congestion Window (cwnd), and the effective sending rate is:
The Slow Start Threshold (ssthresh)
🏭 Animated: Slow Start → Congestion Avoidance → Loss → Recovery
💡 The sawtooth pattern is the hallmark of TCP Reno — probe until loss, back off, probe again. This constant probing means TCP is always slightly congesting the network to find the maximum throughput. BBR avoids this by modelling the pipe capacity directly.
TCP vs UDP — Full Comparison
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (3-way handshake) | Connectionless — fire and forget |
| Reliability | Guaranteed delivery & ordering | No guarantee — packets may be lost or reordered |
| Header size | 20–60 bytes | 8 bytes (minimal overhead) |
| Flow control | Yes — rwnd in every ACK | None |
| Congestion control | Yes — cwnd, Slow Start, CUBIC/BBR | None (can congest the network) |
| Speed | Slower (ACKs, retransmission, setup) | Faster (no handshake, no wait for ACK) |
| Ordering | In-order delivery guaranteed | Out-of-order possible |
| Broadcast/Multicast | Not supported | Supported |
| Use case | HTTP/S, SSH, FTP, SMTP, databases | DNS, VoIP, video, gaming, DHCP, QUIC |
| RFC | RFC 793 (1981), RFC 9293 (2022) | RFC 768 (1980) |
Beyond TCP and UDP — Other Transport Protocols
Real-World Cases — Transport Layer in the News
Golden Rules — Transport Layer Engineering
sysctl -w net.ipv4.tcp_syncookies=1.
Without SYN cookies, a 10 Mbps SYN flood can exhaust the connection table of a
40 Gbps server. SYN cookies eliminate the need to store half-open connection state.
sysctl -w net.ipv4.tcp_congestion_control=bbr.
BBR outperforms CUBIC dramatically on satellite, mobile, and intercontinental
links. CUBIC is better on wired low-latency paths where its cubic growth
more efficiently fills the pipe.
min(cwnd, rwnd) / RTT. On a 100ms RTT link,
the default 87KB socket buffer limits throughput to ~7 Mbps. Set:
net.core.rmem_max=134217728 and net.core.wmem_max=134217728
on Linux for multi-gigabit long-distance paths.
The Transport Layer is where the Internet becomes reliable. IP
delivers packets between machines with no guarantees — it is the transport layer
that adds ordering, error recovery, flow control, and congestion management.
TCP's 3-way handshake establishes the shared state that makes
reliable communication possible. Flow control (rwnd) ensures the
receiver is never overwhelmed. Congestion control (cwnd, Slow Start,
Congestion Avoidance) ensures the network is never overwhelmed —
making TCP's sawtooth behaviour the self-regulating heartbeat of the Internet.
UDP strips all of this away for applications that know better than
the transport layer what guarantees they actually need — and modern protocols like
QUIC rebuild exactly the right guarantees, in user space, with none of the legacy
constraints of a 1981 standard.