Transport-Layer Multiplexing

Right now your laptop is probably holding a dozen conversations at once. A chat app is waiting on a message, three browser tabs are streaming, a mail client is polling, a game is trading position updates, and something in the background is quietly phoning home for updates. All of these ride the same network card, over the same IP address, through the same cable. When a packet arrives, the operating system faces a deceptively simple question: which of these programs does this packet belong to?

The network layer can't answer that. IP delivers packets host-to-host — it gets bytes to the right machine and stops there. It has no idea that a machine runs many programs. The job of turning "the right machine" into "the right program, and even the right conversation within that program" belongs to the layer above: the transport layer. The trick it uses is called multiplexing and demultiplexing, and its whole apparatus rests on one small 16-bit number — the port.

What the transport layer adds

Imagine an apartment building with a single street address. The postal service (IP) delivers all the mail to the building's front door — that is host-to-host delivery. But inside live dozens of families, and the letters need to reach the right apartment. That last hop, from the front door to a specific mailbox, is process-to-process delivery, and it is exactly what the transport layer provides on top of IP.

Network layer (IP): host-to-host. "Deliver these bytes to 93.184.216.34." It neither knows nor cares which program will read them.
Transport layer (TCP/UDP): process-to-process. "…and hand them to this particular socket, belonging to this program, serving this conversation."

The transport layer wraps each block of application data in its own header and hands the result — a segment — down to IP for delivery. TCP calls its unit a segment; UDP calls its unit a datagram; both are "the transport layer's envelope." The two fields that appear in every transport header, TCP or UDP, are the source port and the destination port. Everything about steering data to the right program hangs off those two numbers.

Multiplexing (at the sender): gather data from many sockets, stamp each chunk with a transport header carrying its source and destination ports, and hand the segments to the network layer — many streams funnelled onto one wire.
Demultiplexing (at the receiver): inspect each arriving segment's header fields and deliver its payload to the one correct socket — one wire fanned back out to many streams.

Ports, and the ranges they live in

A port is a 16-bit unsigned integer, so it ranges from 0 to 65535. A port is not a physical thing — there is no tiny door on the side of your computer. It is purely a number in a header that the operating system uses as an index into its table of open sockets. By long-standing convention (governed by IANA) the range is carved into three zones:

Range	Name	Who uses it	Examples
0 – 1023	Well-known	Standard services; on Unix, binding needs privilege	80 (HTTP), 443 (HTTPS), 22 (SSH), 53 (DNS), 25 (SMTP)
1024 – 49151	Registered	Applications that registered a port with IANA	3306 (MySQL), 5432 (Postgres), 6379 (Redis), 8080 (alt-HTTP)
49152 – 65535	Ephemeral / dynamic	Temporary source ports the OS auto-assigns to clients	a browser's outgoing connection might use 51314

This is why a client rarely picks its own port: when your browser opens a connection to a server on port 443, it lets the OS grab a free ephemeral port — say 51314 — as its own source port. The server port is fixed and famous (443) so that clients know where to knock; the client port is disposable and anonymous, invented fresh for each connection and thrown away when it closes.

The crucial split: how UDP and TCP demultiplex

Here is the single most important idea on this page, and the one most people get subtly wrong. UDP and TCP demultiplex differently — they use a different number of fields to decide which socket gets an arriving segment.

UDP demuxes on a 2-tuple: (\text{destination IP},\ \text{destination port}). That's it. Two datagrams that arrive at the same destination IP and port are handed to the same socket, even if they came from completely different senders. A UDP socket is essentially a mailbox identified by "which port on which of my IPs" — the sender's identity does not steer the delivery. (The kernel still tells the app who sent each datagram, via recvfrom, but that's for the app to use, not part of demuxing.)
TCP demuxes on the full 4-tuple: (\text{source IP},\ \text{source port},\ \text{destination IP},\ \text{destination port}) A TCP segment is delivered to the one socket whose four numbers all match. Because the source IP and port are part of the key, two clients hitting the same server IP and port land in two different sockets — one per connection.

This difference is a direct consequence of what the two protocols are. UDP is connectionless: a single socket happily receives from the whole world, so "which port" is enough. TCP is connection-oriented: each connection is a private stream and needs its own socket, so the sender's coordinates must be part of the key. This is precisely why the socket API's accept() hands you a new socket for every client — each new 4-tuple deserves its own endpoint.

Watch it work: routing segments to sockets

The demo below builds a tiny demultiplexer. It keeps a table of open sockets — some UDP (keyed by the 2-tuple), some TCP (keyed by the 4-tuple) — and routes a stream of arriving segments to the right one. Watch how the two TCP connections to the same server port 443 are cleanly separated by their differing client ports, while every UDP datagram to 53 collapses onto a single socket.

// A segment as it arrives: who sent it, where it's going, and its protocol. type Seg = { proto: "TCP" | "UDP"; srcIP: string; srcPort: number; dstIP: string; dstPort: number }; const MY_IP = "10.0.0.7"; // The kernel's socket table. UDP sockets are keyed by (dstIP, dstPort); // TCP sockets by the full 4-tuple. We build the lookup key per protocol. function demuxKey(s: Seg): string { if (s.proto === "UDP") return `UDP ${s.dstIP}:${s.dstPort}`; return `TCP ${s.srcIP}:${s.srcPort} -> ${s.dstIP}:${s.dstPort}`; } const arrivals: Seg[] = [ { proto: "UDP", srcIP: "8.8.8.8", srcPort: 53, dstIP: MY_IP, dstPort: 53 }, { proto: "UDP", srcIP: "1.1.1.1", srcPort: 53, dstIP: MY_IP, dstPort: 53 }, { proto: "TCP", srcIP: "93.1.2.3", srcPort: 51314, dstIP: MY_IP, dstPort: 443 }, { proto: "TCP", srcIP: "93.1.2.3", srcPort: 51315, dstIP: MY_IP, dstPort: 443 }, { proto: "TCP", srcIP: "77.9.9.9", srcPort: 60001, dstIP: MY_IP, dstPort: 443 }, { proto: "TCP", srcIP: "93.1.2.3", srcPort: 51314, dstIP: MY_IP, dstPort: 443 }, ]; const sockets = new Map<string, number>(); // key -> how many segments it received for (const seg of arrivals) { const key = demuxKey(seg); sockets.set(key, (sockets.get(key) ?? 0) + 1); } console.log(`Distinct sockets after ${arrivals.length} segments: ${sockets.size}`); for (const [key, count] of sockets) console.log(` ${key} (${count} segment(s))`); console.log("\nNote: both UDP datagrams (different senders) hit ONE socket,"); console.log("but the three TCP segments to :443 split into TWO sockets by client port,"); console.log("and the repeated 4-tuple correctly lands back on its existing socket.");

A tempting mental model is "one port = one connection," as if binding port 443 lets you serve one client at a time. That is wrong, and if it were true the web could not exist. A busy server holds tens of thousands of simultaneous TCP connections all on port 443 at once. They coexist because TCP demultiplexes on the full 4-tuple, not on the destination port alone. Every connection shares the same (\text{server IP},\ 443) half; what makes each one distinct is its client IP-and-port half. So the destination port tells you which service — but the whole 4-tuple tells you which conversation. Confusing the two is the root of a hundred "why can't two clients connect at once?" misunderstandings.

Two flavours of demux, one API

Because UDP keys on just the 2-tuple, a UDP server usually needs only one socket for all its clients — DNS servers famously answer the whole planet from a single socket bound to port 53. Because TCP keys on the 4-tuple, a TCP server ends up with one socket per client, all sharing the listening port. The socket API reflects this exactly: a UDP program loops on recvfrom() over one socket, while a TCP program calls accept() to mint a fresh socket per connection.

The kernel maintains a table (conceptually a hash map) of open sockets. For every arriving segment it computes the lookup key — the 2-tuple for UDP, the 4-tuple for TCP — and finds the matching entry in roughly constant time. A TCP segment that matches no entry (say, a stray packet for a connection that already closed) typically earns a RST in reply; a UDP datagram for a port nobody is listening on earns an ICMP "port unreachable." The demultiplexer, in other words, also politely tells senders when they've knocked on a door that isn't there.

Everything else the transport layer does — reliability, ordering, flow and congestion control in TCP; cheerful minimalism in UDP — is built on top of this addressing scheme. Multiplexing is the foundation: without a way to name "which program, which conversation," none of the higher services would have anywhere to deliver their carefully-managed bytes.