TCP, UDP & ports

Your laptop has one IP address on the network but dozens of programs talking at once: a browser with twenty tabs, a music app, a mail client, a backup agent. When a packet arrives, the operating system has to decide which one gets it. The IP header only says "this computer." The answer is the port number, a 16-bit field at the start of every TCP and UDP header. There are two in each packet: a source port and a destination port.

Servers listen on ports everyone agrees on, so clients know where to knock: 443 for HTTPS, 53 for DNS, 22 for SSH, 25 for mail between servers. Clients don't need a famous number. When your browser opens a connection, the operating system picks a spare temporary port, an ephemeral port, for the source, and the server sends its replies back to it.

A socket is the program's handle on one end of this: an address and port the program has claimed. A TCP connection is identified by five things together, the five-tuple: protocol, source address, source port, destination address, destination port. Change any one and it's a different connection. That's how a single web server on port 443 holds thousands of simultaneous connections: every client brings a different address-and-port pair.

TCP, the Transmission Control Protocol, promises the receiving program a stream of bytes that arrives complete and in order, or a clear error. To keep that promise, both ends need shared bookkeeping before any data moves. They set it up with three segments:

1. SYN (synchronize). The client says: "I'd like to talk. My byte counter starts at x."
2. SYN-ACK. The server says: "Fine. I acknowledge your x; I expect byte x+1 next. My own counter starts at y."
3. ACK. The client says: "Got it, I expect your byte y+1." Both sides are now ESTABLISHED.

Why three and not two? Each side has to announce its own starting number and hear the other side confirm it. The SYN-ACK does two jobs in one segment. The final ACK confirms the server's number; without it, the server couldn't tell a real client from a stale or forged SYN.

The starting numbers, the initial sequence numbers, are chosen unpredictably, not from zero. If they were guessable, an attacker who could send packets with a forged source address could inject data into someone else's connection. Random starting points also keep a delayed segment from an old connection on the same five-tuple from being mistaken for part of a new one.

The handshake has a cost: one full round trip before the first byte of real data. Between New York and London that's around 70 milliseconds, and an HTTPS page adds TLS's own negotiation on top. Shaving those round trips is a big part of why newer protocols exist.

TCP numbers bytes, not packets. Every segment carries a sequence number: the position of its first byte in the stream. Segments flowing back carry an acknowledgment number: the next byte the receiver expects. Ack 7,301 means "I have everything up to byte 7,300, send me 7,301 onward." It's cumulative: one ack covers everything before it.

The receiver uses sequence numbers to put segments back in order and to throw away duplicates. The sender uses acks to know what got through. Anything sent but not yet acknowledged is kept in memory, ready to send again.

Lost segments get noticed two ways:

• The retransmission timer. The sender keeps a running estimate of the round-trip time and how much it varies. If the oldest unacknowledged segment isn't acked within a timeout (the RTO) a bit longer than that, it's sent again, and the timeout doubles in case the network is struggling. The standard suggests at least one second; Linux uses a 200 millisecond floor.
• Duplicate acks. If segment 3 of 6 is lost, the receiver gets 4, 5 and 6 but can't move its ack past 3. It keeps repeating "still waiting for 3." Three duplicate acks in a row is strong evidence of a loss rather than a reorder, so the sender resends segment 3 at once without waiting for the timer: fast retransmit. When 3 arrives, the receiver, which kept 4 to 6, jumps its ack straight to 7.

The program reading the stream never sees any of this. It just sees bytes arrive in order, occasionally after a pause. That pause is the price of reliability, and it's the problem for anything live: a voice packet resent 200 milliseconds late is worse than no packet.

Waiting for each segment's ack before sending the next would be painfully slow: one segment per round trip. So TCP keeps many segments in flight at once, up to a limit called the window. As acks come back, the window slides forward and more can be sent. Two separate limits set its size.

Flow control protects the receiver. Every ack carries a receive window: how many more bytes the receiver has buffer space for right now. If the reading program is slow, the window shrinks, and at zero the sender pauses. It's the receiver saying "slow down, I'm full."

Congestion control protects the network. The sender doesn't know how much capacity the path has, or how many other connections share it, so it keeps its own estimate, the congestion window, and probes:

• Slow start. A new connection begins with a small window (ten segments on modern systems) and adds one segment for every ack, which doubles the window every round trip. "Slow" is ironic: it grows exponentially.
• Congestion avoidance. Past a threshold, growth becomes gentle: about one extra segment per round trip.
• Back off on loss. A lost segment is read as "the network is full." On fast retransmit the window is cut in half; on a timeout, it collapses to one segment and slow start begins again.

Grow by adding, shrink by halving: additive increase, multiplicative decrease, AIMD. Plotted over time it makes a sawtooth. Many connections all doing it share a bottleneck roughly fairly, and the internet doesn't collapse under its own traffic, which it did in 1986 before these rules existed. Linux, Windows and macOS now default to a variant called CUBIC that regrows faster on high-speed paths, but the shape is the same idea.

The window, not the link speed, often limits a single download. A connection can never move more than one window per round trip.

A TCP connection is really two one-way streams, and each side closes its own. A side that has finished sending sends a FIN. The other side acks it, can keep sending for as long as it likes (that's a "half-close"), and eventually sends its own FIN, which gets acked in turn. Four segments, though the middle two are often combined into one.

The side that closed first doesn't forget the connection right away. It sits in TIME-WAIT for twice the maximum segment lifetime. That covers two risks: its final ACK might be lost (so it must be around to resend it when the other side repeats its FIN), and stray delayed segments from this connection must die out before the same five-tuple can be used again. The standard's segment lifetime is two minutes, making TIME-WAIT four; Linux uses a fixed 60 seconds and Windows two minutes. A busy client making thousands of short connections to the same server can run out of ephemeral ports because they're all parked in TIME-WAIT.

RST, reset, is the hard stop. A host sends it when a segment arrives for a connection that doesn't exist: a SYN to a port where nothing is listening gets a RST back, which your program reports as "connection refused." Programs can also abort a connection with RST, and middleboxes such as firewalls sometimes inject one to kill a connection they don't like. Compare that with a silent drop: if a firewall simply discards the SYN, the client just waits, retries, and eventually reports a timeout. "Refused" means you reached the machine. "Timed out" usually means you didn't.

The User Datagram Protocol, defined in 1980 on three pages, adds just two things to IP: ports, and an optional checksum. Its header is 8 bytes: source port, destination port, length, checksum. No handshake, no sequence numbers, no acks, no retransmission, no windows. A program hands UDP a message, the message goes out as one packet, and it arrives once, or not at all, possibly out of order. Nobody tells the sender which.

That sounds like a worse TCP, but for a lot of traffic it's what you want:

• Voice and video calls. Audio arrives in chunks every 20 milliseconds or so. A late chunk is useless; it's better to skip it and conceal the gap than to stall the whole call waiting for a resend. Calls use RTP over UDP and handle loss themselves.
• DNS. One small question, one small answer. A TCP handshake would triple the time. If no answer comes, the resolver just asks again.
• Games. The newest position update replaces the last one. Resending old positions would be worse than useless.
• Tunnels like WireGuard (and Tailscale, which is built on it). The traffic inside the tunnel is often TCP already, with its own retransmission. Carrying TCP inside TCP stacks two sets of timers that fight each other when packets are lost. WireGuard sends each encrypted packet as one UDP datagram and lets the inner protocol do its job. UDP is also much easier to get through NAT, as Chapter 09 shows.
• QUIC and HTTP/3. Rather than change TCP, which lives inside every operating system and many middleboxes, QUIC builds its own reliable, encrypted streams in the application on top of UDP. It combines the transport and encryption handshakes, and a lost packet stalls only the one stream it belonged to.

The catch: a UDP application has to do for itself whatever it needs. It has to pace itself so it doesn't flood the network, cope with loss, and keep NAT mappings alive with periodic packets, because a router can't see a FIN to know when a UDP "connection" is over. It just forgets the mapping after a quiet spell.