Transport Layer Overview

Your laptop is currently running perhaps fifty applications—each one a separate process with its own memory space, execution context, and communication needs. Your web browser maintains multiple connections to different servers. Your email client checks for new messages. A video streaming app buffers media. A cloud sync service uploads files. Background system services handle updates, security, and diagnostics.

All these processes share a single network connection, a single IP address. Yet when a packet arrives for Netflix, it reaches the Netflix application—not your email client, not your web browser. How does this work?

The answer lies in process-to-process delivery—the transport layer's defining capability. While the network layer gets data to the right machine, the transport layer gets data to the right process within that machine. This seemingly simple extension transforms how we use networked computers.

To appreciate the elegance of process-to-process delivery, we must first understand the problem it solves. Consider the challenge facing network operating systems:

The Multi-Process Reality:

Modern operating systems are fundamentally multi-process environments. At any moment, dozens or hundreds of processes run concurrently:

• User applications: Browsers, editors, media players, games
• System services: Print spoolers, update checkers, authentication daemons
• Network services: Web servers, database engines, mail transfer agents
• Background tasks: Antivirus scanners, cloud sync clients, telemetry collectors

Many of these processes communicate over the network—simultaneously, continuously. They send data to different destinations and receive data from different sources.

What IP Provides (And What It Doesn't):

The Internet Protocol assigns addresses to network interfaces, not processes. An IP address like 192.168.1.100 identifies a specific machine on the network. When a packet arrives at this address, the operating system's IP stack receives it. But the IP protocol provides no mechanism to specify which process on that machine should receive the data.

The Conceptual Gap:

Without transport layer addressing, every network-aware process would receive every incoming packet. The operating system would have no principled way to route data. Applications would need to:

1. Receive all incoming packets
2. Examine packet contents to determine relevance
3. Discard irrelevant packets (most of them)

This approach:

• Wastes computational resources
• Violates process isolation (security concern)
• Requires every application to implement filtering logic
• Doesn't scale as process counts increase

The transport layer's process addressing mechanism solves all these problems through a deceptively simple concept: port numbers.

Port numbers are 16-bit unsigned integers that identify specific processes or services on a host. Combined with an IP address, a port number creates a complete endpoint address for network communication.

The Mathematics of Port Space:

With 16 bits, port numbers range from 0 to 65,535, providing 65,536 possible values. This number was chosen carefully:

• Large enough to accommodate many simultaneous processes
• Small enough to fit in transport headers efficiently
• Consistent across TCP and UDP (though ports are independent per protocol)

Port Number Ranges:

The Internet Assigned Numbers Authority (IANA) divides the port space into three ranges with different allocation policies:

Well-Known Ports (0-1023):

These ports are reserved for standardized services. When you connect to a web server, you assume port 80 (HTTP) or 443 (HTTPS). When you send email, SMTP servers listen on port 25. This standardization is essential—clients need to know where to find services.

Common well-known port assignments:

On Unix-like systems, binding to ports 0-1023 requires superuser (root) privileges—a security measure preventing unprivileged processes from impersonating critical services.

Ephemeral Ports (49152-65535):

When a client application initiates a connection, it needs a source port to receive responses. The client typically doesn't care which port it uses—it just needs any available one. The OS assigns a temporary (ephemeral) port from the dynamic range.

Different operating systems historically used different ephemeral ranges:

• IANA recommended: 49152-65535
• Linux: 32768-60999 (configurable via /proc/sys/net/ipv4/ip_local_port_range)
• Windows: 49152-65535 (Vista+)
• BSD/macOS: 49152-65535

Understanding ephemeral ports matters for high-connection-count servers—you can exhaust the ephemeral port range with too many concurrent connections to the same destination.

A port number alone identifies a process locally—on a single host. But for Internet-wide communication, we need globally unique identification. This is achieved through socket addresses.

Definition:

A socket address (sometimes called a transport address or socket endpoint) is the combination of an IP address and a port number:

Socket Address = IP Address + Port Number
Example: 192.168.1.100:443
IPv6 Example: [2001:db8::1]:443

This combination is globally unique—no two endpoints anywhere on the Internet share the same socket address (assuming no NAT complications).

The Five-Tuple:

For TCP connections, uniqueness is determined by a five-tuple:

1. Protocol (TCP or UDP)
2. Source IP address
3. Source port number
4. Destination IP address
5. Destination port number

This five-tuple uniquely identifies a connection. Multiple connections can share the same destination IP:port as long as different source IP:port combinations are used.

Why This Matters for Servers:

A web server running on port 443 can handle thousands of simultaneous connections—all to the same local socket address. How? Each connection has a different client socket address. The server's OS maintains the connection table indexed by the full five-tuple.

When a packet arrives at the server:

1. The IP layer delivers it based on destination IP
2. The transport layer identifies the connection using all five tuple elements
3. The correct connection's data buffers receive the payload

Socket Binding:

In socket programming, servers bind to a specific local socket address:

// Server binds to listen on port 443
bind(socket, {address: "0.0.0.0", port: 443})
listen(socket)

// Client binds to any available ephemeral port
bind(socket, {address: "0.0.0.0", port: 0})  // Often implicit
connect(socket, {address: "93.184.216.34", port: 443})

The address 0.0.0.0 means "all interfaces"—the server accepts connections arriving on any network interface.

The mechanism that enables process-to-process delivery has two complementary operations: multiplexing at the sender and demultiplexing at the receiver. Together, these operations allow multiple applications to share a single network interface.

Multiplexing (At Sender):

Multiplexing is the process of gathering data from multiple application processes, encasing each with transport headers (including port numbers), and passing them to the network layer.

Think of it as multiple postal customers at a single post office—each customer's letters are tagged with sender/recipient addresses and merged into a single outgoing mail stream.

Demultiplexing (At Receiver):

Demultiplexing is the reverse—examining incoming segments' destination port numbers and directing each segment's payload to the correct receiving process.

Think of it as the mail room in a large office building—incoming mail is sorted by recipient and delivered to individual offices.

How Demultiplexing Works:

When a segment arrives at the transport layer, demultiplexing follows this process:

1. Extract destination port from the transport header
2. Look up the socket bound to that port
3. Deliver the payload to the socket's receive buffer
4. Notify the application that data is available (if blocking on recv())

UDP vs TCP Demultiplexing:

The demultiplexing process differs slightly:

UDP Demultiplexing:

• Uses only destination port to identify the receiving socket
• All datagrams to the same port reach the same socket
• Source information is available but not required for demux

TCP Demultiplexing:

• Uses the full four-tuple (source IP, source port, dest IP, dest port)
• Different connections to the same server port are distinguished
• Each connection has its own socket

This difference explains why UDP servers typically have one socket serving all clients, while TCP servers create a new socket for each connected client.

Process-to-process delivery enables the dominant pattern of Internet communication: the client-server model. Understanding how ports work in this model clarifies their practical significance.

Server Behavior:

Servers provide services on well-known ports. A web server listens on port 80 (HTTP) or 443 (HTTPS). The server:

1. Creates a socket
2. Binds to a specific port (e.g., 443)
3. Listens for incoming connections (TCP) or datagrams (UDP)
4. Accepts connections or receives data
5. Processes requests and sends responses

The server's port is fixed and advertised—clients know where to connect.

Client Behavior:

Clients initiate communication. They need to:

1. Know the server's IP address (usually via DNS)
2. Know the server's port (well-known or discovered)
3. Obtain a local ephemeral port (OS-assigned)
4. Connect to the server (TCP) or send datagrams (UDP)
5. Exchange data
6. Close connection and release port

A Complete Transaction Example:

Let's trace a complete HTTPS request from your browser:

1. Browser resolves hostname: DNS returns 142.250.80.46 for google.com
2. Browser requests ephemeral port: OS assigns port 52341
3. Browser initiates TCP connection:
   • Source: 192.168.1.100:52341
   • Destination: 142.250.80.46:443
4. Three-way handshake completes: Connection established
5. Browser sends HTTP request: Data flows through connection
6. Server processes and responds: Response flows back
7. Connection terminates: Port 52341 released after TIME_WAIT

The server never knows or cares about the client's ephemeral port—it just uses whatever the client provides. The client's port exists solely to identify which process receives the response.

Concurrent Connections:

Modern browsers open multiple concurrent connections to the same server—often 6-8 per origin. Each connection has a different client ephemeral port, making them distinguishable despite sharing the same server port.

The relationship between processes and ports is more nuanced than a simple one-to-one mapping. Understanding these relationships clarifies common architectures and potential pitfalls.

One Process, Multiple Ports:

A single process can bind to multiple ports simultaneously. Examples:

• Web server: Listens on both 80 (HTTP) and 443 (HTTPS)
• Email server: Listens on 25 (SMTP), 143 (IMAP), 993 (IMAPS)
• Database: Listens on primary port plus replication/admin ports

The process creates multiple sockets, each bound to a different port. The OS demultiplexes to the correct socket; the process reads from each as needed.

One Port, Multiple Processes (Special Cases):

Normally, only one process can bind to a port. But exceptions exist:

• SO_REUSEPORT: Modern kernels allow multiple processes to share a port, with load balancing among them. This enables multi-process servers:

Process 1: bind(socket1, {:8080}, SO_REUSEPORT) ✅
Process 2: bind(socket2, {:8080}, SO_REUSEPORT) ✅
Kernel distributes incoming connections between them

• Fork after bind: A server binds, then forks child processes. All children share the bound socket, competing to accept connections (pre-fork model).

Port Inheritance Across Fork:

When a process forks, the child inherits all open file descriptors—including sockets. This means:

• Children share listening sockets
• Children can accept on parent's bound ports
• Connection sockets remain with the process that accepted them

This is the basis of the pre-fork model used by Apache and early nginx.

Port Conflicts:

If a process tries to bind a port that's already bound:

• Error: EADDRINUSE ("Address already in use")
• Resolution: Use different port, wait for TIME_WAIT expiry, or use SO_REUSEADDR/SO_REUSEPORT

This is why multiple web servers can't typically run on the same port without explicit sharing mechanisms.

Port numbers have profound security implications. Because they identify services, they're fundamental to network security mechanisms.

Firewall Port Filtering:

Most firewalls implement port-based access control:

• Allow traffic to port 443 (HTTPS): Permit secure web access
• Block traffic to port 23 (Telnet): Prevent insecure remote access
• Block traffic to port 3306 (MySQL): Prevent direct database access

These rules don't examine packet contents—they simply allow or deny based on port numbers. This is fast and effective for controlling service access.

Port Scanning:

Attackers use port scanning to discover services:

• Send probe packets to many ports
• Observe responses (open, closed, filtered)
• Identify running services for exploitation

Tools like Nmap automate this process. Defensive measures include:

• Only exposing necessary ports
• Rate-limiting connection attempts
• Logging and alerting on port scan patterns
• Port knocking (obscure open ports behind secret sequences)

Port-Based Network Segmentation:

Enterprise networks often segment traffic by port:

• Web traffic (80, 443) routes through web proxies
• Database traffic (3306, 5432) stays within data centers
• Management traffic (22, 3389) restricted to admin VLANs

This provides defense in depth—compromised web servers can't directly attack databases.

Non-Standard Ports:

Services can run on unusual ports for:

• Security through obscurity: SSH on 2222 instead of 22 avoids automated attacks (weak protection)
• Multiple instances: Multiple databases on 3306, 3307, 3308
• User-space limitations: Non-root services on ports > 1024

However, port numbers don't guarantee service type—a web server could run on any port. Deep packet inspection examines actual protocol behavior, not just ports.

We've explored how the transport layer extends network addressing to reach specific processes. Let's consolidate the key concepts:

What's Next:

Process-to-process delivery is the transport layer's most fundamental capability, but it's just the beginning. The next page explores end-to-end communication—the principles and mechanisms that enable reliable data exchange between processes regardless of the network path between them.