The transport layer (TCP/UDP) - reliability is a choice

Recap

Part three came down to the scope of IP. IP gets packets to the destination host using hierarchical addresses and routing, but delivery is best-effort, so it does not repair loss, duplication, or reordering.

This part has two questions. Which process does an arriving packet belong to? And who guarantees the reliability IP deferred?

Ports: a process’s address

Inside a single host, a browser, a messenger, and a game all communicate at once. An IP address identifies only the host, so we need one more address to distinguish processes. That is the port, a 16-bit number.

Each end of a conversation is fixed by a pair of IP address:port, and that endpoint is called a socket. The server side listens on a well-known port (HTTP 80, HTTPS 443, DNS 53, SSH 22), while on the client side the operating system picks an ephemeral port.

UDP: the layer that does almost nothing

A UDP (User Datagram Protocol) header consists of source and destination ports, a length, and a checksum — that is all. UDP is a thin shell that adds nothing but port demultiplexing on top of IP’s best-effort delivery. There is no connection setup, no retransmission, no reordering.

This is not laziness; it is offering a choice. In real-time streaming or games it is better to drop late data than to have it retransmitted, and for communication like DNS — one question, one answer — the cost of establishing a connection is itself a waste.

TCP: building reliability on top

TCP (Transmission Control Protocol) builds reliability on top of IP’s best-effort delivery. It promises to deliver everything that must be received, in order, exactly once.

Connection setup: the three-way handshake

Before sending data, TCP establishes a connection that aligns both sides’ state.

Client                          Server
    | -- SYN (I'll start at x) --> |
    | <- SYN+ACK (ok, I'm at y)    |
    | -- ACK (confirmed) --------> |
    connection established, data begins

In three exchanges both sides swap their starting sequence numbers. From then on all data is tracked against those numbers.

Reliability: sequence numbers, ACKs, retransmission

TCP numbers every byte it sends. The receiver reports how far it has received with an ACK, and buffers out-of-order segments to restore the order. If no ACK arrives within a certain time, or the same ACK repeats, the sender treats it as loss and retransmits. The loss, duplication, and reordering that IP declined to handle in part three are all resolved here.

Flow control and congestion control

If the sender simply blasts data as fast as it can, two things collapse: the peer, and the network.

Flow control protects the peer. The receiver carries its remaining buffer size (the receive window) in its ACKs, and the sender does not exceed it.

Congestion control protects the network. When a router along the path saturates, it starts dropping packets; the sender reads loss as a signal of congestion and reduces its rate. It starts cautiously and ramps up (slow start), then backs off when congestion is detected. The reason the internet stays standing while crowded with countless TCP connections is that every sender regulates itself by this convention.

Closing a connection goes through a four-way teardown in which each side announces it has nothing more to send.

TCP vs UDP

Summary

The core point is this.

TCP implements the reliability IP deferred, and UDP refuses to pay for it at all. Reliability is a choice, not an obligation.

Coming up next

Packets now arrive at the right process on the right host, in order and complete. The remaining question is what is being exchanged on top of that. The next part covers the two pillars of the application layer: DNS, which turns names into addresses, and HTTP, the language of the web.