What Is the Transport Layer? — Computer Networks

Summary#

The transport layer sits directly above IP and gives applications an end-to-end channel between processes on two hosts. IP gets a packet to a host — best-effort, no ordering, no delivery guarantee. The transport layer turns “host-to-host best-effort” into “process-to-process with the semantics this application actually needs.” That’s it. Everything interesting about TCP and UDP grows out of that one job.

Two pieces are universal: multiplexing (one host runs many processes; the transport header carries port numbers so the receiving stack can demultiplex) and a checksum over the segment (so the receiver can detect corruption). Everything beyond that — reliability, ordering, flow control, congestion control, connection state — is a choice. UDP picks “nothing extra”; TCP picks “everything”; QUIC picks “everything but on UDP, redone for the modern Internet.”

Why it matters#

Almost every networking design question — TCP or UDP, where to terminate TLS, what a load balancer does at L4 vs L7, why an RPC framework picks gRPC over plain HTTP — is really a transport-layer question. If you can explain why an application picks one transport over another, you can explain most of the protocol stack.

It also matters operationally. The 5-tuple (src IP, src port, dst IP, dst port, protocol) is the unit of identity for connection tracking, load balancing, NAT, and firewall rules. When a load balancer “hashes by 5-tuple” it is doing transport-layer demultiplexing in front of your backends. When a NAT rewrites a port on the way out, it is rewriting a transport-layer field. The transport layer is where most of the policy of the Internet lives.

How it works#

Multiplexing and demultiplexing#

A host has one IP address (per interface) and runs many processes. Each process that wants network I/O opens a socket, which the OS binds to a port number. The sender’s transport header carries (src port, dst port); the receiving kernel reads those and hands the segment to the right socket.

For UDP, demultiplexing is by (dst IP, dst port) only — a UDP socket bound to port 53 receives every datagram sent to that port regardless of source. For TCP, demultiplexing is by the full 4-tuple (src IP, src port, dst IP, dst port); a listening socket on port 443 fans out into many ESTABLISHED sockets, one per client connection.

The reliability spectrum#

UDP  ----- TCP -----  QUIC
 |          |          |
no state    full       per-stream loss
no order    order      multiplexed streams
no retx     ARQ + cwnd integrated TLS 1.3
checksum    everything 0-RTT setup

UDP delivers a datagram or drops it. TCP guarantees in-order delivery of a byte stream, retransmits losses, paces itself with congestion control, and tells the sender to slow down when the receiver’s buffer fills. QUIC keeps TCP’s guarantees but rebuilds them on UDP so each stream can be lost independently and the handshake folds in encryption.

The cost grows with the guarantee. UDP’s header is 8 bytes; TCP’s is 20 minimum, plus connection-setup RTTs, plus per-segment ACK overhead, plus kernel memory for in-flight buffers. The application picks the point on the spectrum it can afford to pay for.

What the transport layer adds beyond IP#

Ports — process-level addressing.
Checksum — corruption detection (covering header, data, and a pseudo-header from IP).
Optional reliability — sequence numbers, ACKs, retransmissions.
Optional ordering — TCP guarantees byte-stream order; UDP does not.
Optional flow control — receiver tells sender how much it can buffer.
Optional congestion control — sender backs off when the network shows stress.
Optional connection state — handshake, teardown, half-close.

Variants and trade-offs#

Connection-oriented (TCP, QUIC) — explicit handshake establishes state on both sides. Reliability, ordering, flow control, congestion control are built in. Pay 1 RTT (TCP) or 0–1 RTT (QUIC with resumption) at setup. Sender and receiver agree on initial sequence numbers, options, and capabilities.

Connectionless (UDP) — no handshake, no state. Each datagram is independent. Zero setup cost. Application picks which reliability features (if any) to build on top. Best for short queries, real-time media, multicast, and anything where you’d rather drop a late packet than wait for a retransmit.

Other axes:

Byte stream vs message — TCP is a stream (you must frame messages yourself); UDP preserves datagram boundaries (one sendto produces one recvfrom).
Head-of-line blocking — TCP blocks the whole stream on one lost packet; QUIC isolates per-stream loss; UDP has nothing to block.
Fairness — TCP backs off under congestion so flows converge to roughly fair shares. UDP doesn’t, which is why a misbehaving UDP application can swamp a link.
NAT and middlebox friendliness — stateful boxes are tuned for TCP’s handshake; UDP traversal often needs hole-punching or STUN.

Why is the transport layer end-to-end and not hop-by-hop?

The end-to-end principle says: put functions at the endpoints where they’re needed, not at every hop. A reliability mechanism at every router would still need a final check at the receiver (a router can’t know if the application read the bytes). So put reliability once, at the endpoints, and let the routers be dumb and fast. The transport layer is the canonical example — TCP’s sequence numbers, ACKs, and retransmissions all live on the two endpoints; the routers in between never look at them.

When this is asked in interviews#

Often a warm-up before the deep TCP questions. Expect “what does the transport layer do?” or “what’s the difference between TCP and UDP?” early in a networking screen. Strong answers go past the headline (“TCP is reliable, UDP is not”) into why — multiplexing as the universal job, reliability/order/flow/congestion as the options TCP picks.

Common follow-ups:

“What does multiplexing mean here?” — many processes, one IP, ports disambiguate. Demultiplexing by 2-tuple for UDP, 4-tuple for TCP.
“Why would a real system use UDP?” — DNS, NTP, real-time audio/video, QUIC, gaming, multicast. Any case where late delivery is worse than loss, or where setup cost dominates.
“Could you put reliability above UDP instead of using TCP?” — yes, that’s exactly what QUIC does. Lets you skip TCP’s head-of-line blocking and fold encryption into the handshake.
“What’s the smallest unit the transport layer cares about?” — the segment (TCP) or datagram (UDP). One transport-layer unit fits in one IP packet (usually) and carries the ports and any transport-level fields.

Asked across SRE, backend, and platform loops — anywhere the candidate is expected to reason about RPC, load balancing, or wire protocols.