Ports, TCP & UDP

An IP address gets a packet to the right machine; the transport layer gets it to the right program on that machine, and decides what happens when a packet is lost. In this course every service listens on a port (8080 for a Spring Boot app, 5432 for PostgreSQL), every ports: line in a compose.yaml maps one port to another, and most calls between services ride on TCP — while DNS, and HTTP/3, ride on UDP. This page covers ports, the difference between TCP and UDP, the handshake that opens a TCP connection, and what TCP's reliability costs when the network loses packets.

Ports

An IP address identifies a host; a port identifies a specific process on that host. Together, IP:port (called a socket address) identifies a communication endpoint on the network.

Ports are 16-bit numbers (0–65535) divided into three ranges¹:

Well-known ports

Ephemeral ports and connections

A server listens on a fixed port; the client's side gets a temporary one. When a browser connects to https://example.com, it connects to port 443 of the server's address, and the operating system picks an ephemeral port (e.g., 52413) for the client side, so the full connection is client_ip:52413 ↔ server_ip:443. Operating systems pick from their own range: IANA suggests 49152–65535, while Linux uses 32768–60999 by default².

A connection is identified by four numbers — source IP, source port, destination IP, destination port — so one server port can hold thousands of connections at once, one per client socket. You can list the ports your machine is listening on:

ss -tlnp                         # Linux: TCP sockets in LISTEN state, with the process
lsof -iTCP -sTCP:LISTEN -n -P    # macOS (and Linux)

In Docker, ports: - "8081:8080" means "host port 8081 forwards to container port 8080": the service inside still listens on its own port, and the host publishes it under another one (Addressing & NAT).

TCP and UDP

The Transport layer offers two fundamentally different delivery models:

The three-way handshake

Before any data flows, a TCP client and server agree on initial sequence numbers — the counters each side uses to number its bytes, so the other can acknowledge them and spot what is missing:

sequenceDiagram
    participant C as Client<br/>ephemeral port 52413
    participant S as Server<br/>port 443
    C->>S: SYN (seq = x)
    S-->>C: SYN-ACK (seq = y, ack = x+1)
    C->>S: ACK (ack = y+1) + first data (request)
    Note over C,S: connection established after one round trip
    S-->>C: data (response), ack = bytes received so far
    C->>S: ACK

The handshake costs one round trip before the first byte of the request leaves the client. HTTPS adds a TLS handshake on top — one more round trip with TLS 1.3⁵. On a 77 ms São Paulo – Virginia path that is about 150 ms before the request is even sent, which is why clients and services reuse connections (HTTP keep-alive, connection pools) instead of opening a new one per request.

A port that nobody listens on answers the SYN with a reset (RST): that is the "connection refused" error. A SYN that gets no answer at all (a firewall dropped it, the host is down) is retried until the client gives up: a "timeout".

What reliability costs

TCP's guarantee has a price, and it is paid in time. The sender keeps every segment until the receiver acknowledges it. If no acknowledgement arrives before the retransmission timer (RTO) runs out, it sends the segment again, and doubles the timer for the next attempt⁶. Meanwhile the receiver may already hold the segments that came after the lost one — but TCP promises bytes in order, so it cannot hand them to the application yet. One lost segment holds back everything behind it: head-of-line blocking.

UDP pays nothing of the kind: what arrives is delivered at once, and what is lost stays lost. Compare both over the same link, with the same losses:

The simulator keeps only the timer. Real TCP also retransmits early when duplicate acknowledgements show a gap (fast retransmit), and slows its sending rate when it sees loss (congestion control) — so on a lossy network throughput drops, not just latency. Head-of-line blocking is also why HTTP/3 moved to QUIC, which runs over UDP and retransmits per stream: a lost packet of one response no longer stalls the others sharing the connection⁷.

Key takeaways