Transport-Layer Services and Multiplexing

The transport layer provides logical communication between processes running on possibly different hosts, as opposed to the network layer's logical communication between hosts themselves. This distinction is the crux of the whole article: IP delivers a packet to a machine; the transport layer must further deliver the packet's payload to the specific application process on that machine that is waiting for it. Every transport-layer packet, called a segment, carries a header with enough information to make this final delivery hop possible. The key piece of information is the port number, a 16-bit field (values 0–65535) that identifies an application-layer endpoint on a host. Ports are divided by convention into well-known ports (0–1023, assigned by IANA to standard services — port 80 for HTTP, port 443 for HTTPS, port 53 for DNS), registered ports (1024–49151, for other named applications), and ephemeral/dynamic ports (49152–65535, typically assigned automatically to client-side sockets by the OS). A process gains access to the network through a socket, the software abstraction that is the door between the application and the transport layer; a socket is uniquely identified by some combination of local IP address, local port, and — for connection-oriented protocols — the remote IP address and remote port as well. Two complementary operations make process-to-process delivery work. Multiplexing is the sender-side gathering of data chunks from multiple sockets, each wrapped with header information (crucially, port numbers), and passing the resulting segments down to the network layer. Demultiplexing is the receiver-side operation of using header information in an arriving segment to deliver its data to the correct socket among potentially many active sockets on that host. Multiplexing lets many application streams share one network-layer conduit; demultiplexing undoes that sharing correctly on arrival. Getting demultiplexing wrong — delivering a segment to the wrong or a nonexistent socket — is a violation of the entire purpose of the transport layer, so the demultiplexing rule must be an unambiguous, deterministic function of the segment header and the receiver's socket table.

Step 1 — Socket creation and binding. When a process wants network access, it asks the OS to create a socket. For a server, this typically means binding to a specific, well-known local port (e.g., a web server binds to port 80) so that clients know where to find it. For a client, the OS usually assigns an ephemeral port automatically.

Step 2 — Multiplexing at the sender. Each socket, when it sends data, has the transport layer attach a header. Minimally, this header includes a source port number and a destination port number (for connection-oriented transport, the destination IP and port were fixed at connection setup; for connectionless transport, the application specifies the destination on every send). The transport layer then hands the resulting segment to the network layer, which further wraps it in an IP datagram with source and destination IP addresses. Multiple sockets on the host interleave their segments onto the single outgoing network interface — this interleaving is multiplexing.

Step 3 — Demultiplexing at the receiver. When a segment arrives at a host (after the network layer strips the IP header and identifies the transport protocol via the IP header's protocol field, e.g., 17 for UDP, 6 for TCP), the transport layer must decide which socket, if any, receives the payload. The rule differs by protocol family:

• Connectionless demultiplexing (UDP-style): a socket is identified by the 2-tuple (destination IP, destination port). Any segment arriving with a given destination IP and port is delivered to the socket bound to that pair, regardless of source. Two UDP segments with different source IPs/ports but the same destination IP/port go to the same socket.
• Connection-oriented demultiplexing (TCP-style): a socket is identified by the full 4-tuple (source IP, source port, destination IP, destination port). Two arriving segments with the same destination IP and port, but different source IP or port, are demultiplexed to different sockets, because each represents a distinct connection (this is what allows a single web server on port 80 to serve thousands of simultaneous distinct client connections through one listening port).

Step 4 — Delivery. The identified socket's receive buffer receives the payload; the application process, blocked on a read call, wakes up and consumes the data. ``` // SENDER SIDE: multiplexing function send(socket, data): header = build_transport_header( src_port = socket.local_port, dst_port = socket.remote_port, // known for TCP; // supplied per-call for UDP protocol_specific_fields...) segment = header + data network_layer.send(segment, socket.local_ip, socket.remote_ip)

// RECEIVER SIDE: demultiplexing function on_segment_arrival(segment, src_ip, dst_ip, protocol): header = parse_transport_header(segment) src_port = header.src_port dst_port = header.dst_port if protocol == UDP: key = (dst_ip, dst_port) socket = socket_table.lookup_connectionless(key) if socket == NONE: send_icmp_port_unreachable(src_ip, src_port) return socket.receive_buffer.enqueue(segment.payload) else if protocol == TCP: key = (src_ip, src_port, dst_ip, dst_port) socket = socket_table.lookup_connection(key) if socket == NONE: // no matching established/pending connection listening_socket = socket_table.lookup_listener(dst_ip, dst_port) if listening_socket == NONE: send_reset(src_ip, src_port) return socket = listening_socket.handle_new_connection(src_ip, src_port) socket.receive_buffer.enqueue(segment.payload) ``` The pseudocode captures the entire mechanism: the only difference between UDP and TCP demultiplexing is the size of the key used to index the socket table — a 2-tuple versus a 4-tuple. Everything else (parsing the header, looking up a table, enqueueing into a buffer) is identical machinery.

Time complexity. Both multiplexing and demultiplexing are, in the standard implementation, O(1) expected time per segment, because the socket table is a hash table keyed by the 2-tuple (UDP) or 4-tuple (TCP). Building the transport header on send is O(1) (a fixed number of fields). Parsing the header and doing a hash-table lookup on receive is O(1) expected, O(k) worst case in pathological hash-collision scenarios where k is the number of colliding entries — in practice negligible with a well-designed hash function over IP/port fields. This is essential: a host may be demultiplexing tens of thousands of TCP connections (e.g., a busy web server), and this operation happens on the critical path for every arriving packet, so anything worse than O(1) amortized would not scale.

Space complexity. The socket table requires O(S) space, where S is the number of open sockets on the host — each entry stores the identifying tuple, buffer pointers, and protocol state (for TCP: sequence numbers, window size, connection state). This is unavoidable: the OS must remember, for every open socket, enough information to route future segments to it and to track protocol state.

Correctness argument. The correctness of demultiplexing rests on an invariant we can state precisely: > Demultiplexing invariant. At any moment, no two active sockets on a host share the same identifying key (2-tuple for UDP-style, 4-tuple for TCP-style). If this invariant holds, then the lookup function `socket_table.lookup(key)` is a well-defined partial function — each key maps to at most one socket — so delivery is unambiguous. The invariant is maintained by the OS's socket-allocation logic:

• For UDP, `bind()` fails or is disallowed if another socket has already claimed the same (IP, port) pair (barring explicit `SO_REUSEPORT`-style opt-ins with well-defined additional rules), so the space of active 2-tuples is kept a valid partial function's domain by construction.
• For TCP, a listening socket is keyed only by (IP, port) with wildcards for the remote side, but each accepted connection is assigned a distinct 4-tuple, because the remote (client) IP and port are, by the birthday-bound argument over the client's own ephemeral port allocation and distinct client addresses, virtually always distinct across simultaneous clients; the rare theoretical collision (same client IP and port connecting "twice") cannot happen because that client's OS itself will not reuse an in-use (local IP, local port, remote IP, remote port) tuple while a connection using it is live.

Given the invariant, induction over segment arrivals shows every segment is delivered to exactly one socket (or correctly rejected, e.g. via ICMP port-unreachable for UDP or a TCP RST) — never dropped silently to the wrong destination and never duplicated across sockets.

Tradeoffs, honestly. The 2-tuple vs. 4-tuple design is not accidental generosity — it reflects what each protocol needs to track. UDP is connectionless: it has no notion of "a connection" to distinguish, so it only needs enough of a key to reach some socket bound to that port; if a UDP server wants to distinguish clients (e.g., a DNS-style responder), the application must do so using the source address information handed up alongside the payload, not the transport layer. TCP, being connection-oriented, must distinguish flows to maintain per-connection state (sequence numbers, congestion window), so the finer 4-tuple key is a necessity, not an optimization. This is one root cause of the qualitatively different service models offered by UDP: Connectionless Transport and TCP.

Consider a web server at IP address `203.0.113.7`, listening on TCP port 80, simultaneously serving two browser clients, plus a DNS resolver on the same host listening on UDP port 53.

Step by step reasoning: 1. The first arriving segment is a fresh TCP SYN. No entry exists yet for the exact 4-tuple, but a listening socket exists for (203.0.113.7, 80), so the OS spawns a new connected socket S1 and inserts its 4-tuple key into the table. 2. A second client's SYN arrives, targeting the same destination IP and port 80, but with a different source IP and port. The 4-tuple differs, so a second socket S2 is spawned — Alice's and Bob's HTTP requests are never confused, even though they share a destination port. 3. A later data segment from Alice, still using her original ephemeral port 51000, matches S1's exact key and is delivered to the same socket, preserving her connection's byte stream. 4. A DNS query arrives via UDP. Because UDP demultiplexes only on (destination IP, destination port), it lands at S3 regardless of which client sent it. 5. A second, entirely different client's DNS query also lands at S3 — this is the qualitative difference from TCP: UDP's demultiplexing key is coarser, so all traffic to a given UDP port funnels into one socket, and it is the application's job (reading the sender's address from the received datagram's metadata) to tell the two queries apart if it needs to. This trace demonstrates precisely why TCP servers can maintain per-client state transparently (each client gets its own socket, hence its own buffers and sequence numbers) while UDP servers must manage multiple clients' state themselves within a single socket's application logic.

The transport layer's port-based multiplexing model crystallized during the design of the ARPANET's successor protocols, as researchers needed a general mechanism for many applications to share one network path. The abstraction of "ports" as software-addressable endpoints, distinct from network addresses, was central to making TCP/IP a genuinely multi-application internetworking architecture rather than a single-purpose file-transfer or terminal-access protocol.

Every internet-facing application depends on transport-layer multiplexing whether or not its developers think about it explicitly. Web servers handling thousands of simultaneous HTTPS connections on port 443 rely on TCP's 4-tuple demultiplexing to keep each client's request stream separate and correctly sequenced. DNS resolvers, video-streaming protocols (many built atop UDP-based QUIC), and multiplayer games (often raw UDP for low latency) rely on the coarser UDP demultiplexing rule, pushing client-differentiation logic into the application layer by design. Network Address Translation (NAT) devices, firewalls, and load balancers manipulate and inspect exactly the port fields discussed here — a NAT box, for instance, rewrites source ports specifically to keep its own internal-to-external 4-tuple mappings unambiguous, a direct application of the demultiplexing invariant to a middlebox rather than an endpoint. Operating system kernels implement the socket table itself as a core piece of networking infrastructure, and its performance (O(1) hashed lookup) is one reason modern servers can sustain hundreds of thousands of concurrent connections. Understanding this layer is also the necessary foundation for the two natural next steps: the connectionless minimalism of UDP: Connectionless Transport, and the machinery — sequence numbers, acknowledgments, retransmission timers — that Principles of Reliable Data Transfer builds on top of an unreliable channel to deliver TCP's stronger guarantees.

Ask the tutor: How does NAT rewrite the 4-tuple, and why does that rewriting have to preserve the demultiplexing invariant on both sides of the translation?