Ports

Every second, your computer handles hundreds of simultaneous network connections—web browsers fetching pages, email clients checking for messages, streaming services delivering video, games synchronizing state, and background services updating silently. Yet the network interface card (NIC) on your computer has only one IP address.\n\nHow does your operating system know which incoming packet belongs to Chrome versus Spotify? How does it route a response from a web server to the correct browser tab while simultaneously delivering DNS responses to the resolver and SSH data to your terminal?\n\nThe answer lies in one of the most elegant and essential abstractions in computer networking: ports.

To appreciate ports, we must first understand the problem they solve. Consider the network layer's role in the OSI and TCP/IP models:\n\nThe Network Layer (IP) provides host-to-host delivery. Given a source IP address and a destination IP address, the network layer—through routing protocols, forwarding tables, and packet switching—ensures that a datagram reaches the correct machine on the internet. This is a remarkable achievement: billions of devices, all addressable, all reachable.\n\nBut host-to-host delivery is not enough.\n\nOn any modern computer, dozens of processes run simultaneously. A single host might have:\n- A web browser with 20 open tabs, each maintaining separate connections\n- An email client checking multiple accounts\n- A music streaming application\n- A file synchronization service\n- System services (DNS resolver, NTP client, software update checkers)\n- Development tools (SSH connections, database clients, API calls)\n\nAll these processes communicate over the network. All share the same IP address. And each expects to receive only its own data, without interference from other applications.

The transport layer solves this problem through ports.\n\nWhile the network layer delivers packets to the right host, the transport layer delivers data to the right process within that host. This is called process-to-process delivery or end-to-end communication, and ports are the addressing mechanism that makes it possible.\n\nAnalogy: The Office Building\n\nThink of an IP address like a building's street address. The postal service (network layer) can deliver mail to 100 Main Street, but once it arrives, how does the mail room know which office suite should receive it?\n\nThe answer is suite numbers—just like ports. Each office (process) has a unique suite number (port number). The mail room (operating system) reads the suite number on each piece of mail and delivers it to the correct office.\n\nWithout suite numbers, all mail would pile up in the lobby with no way to distribute it. Without ports, all network data would arrive at the host with no way to deliver it to the correct application.

A port is a 16-bit unsigned integer that serves as an endpoint identifier for process-to-process communication within a host. Let's unpack this definition precisely:\n\n16-bit unsigned integer:\n- Ports range from 0 to 65,535 (2¹⁶ - 1 = 65,535)\n- This provides 65,536 possible port numbers per transport protocol\n- Both TCP and UDP maintain separate port namespaces (port 80 TCP is different from port 80 UDP)\n\nEndpoint identifier:\n- A port identifies one end of a communication channel\n- Combined with an IP address, it forms a socket address (e.g., 192.168.1.100:443)\n- The socket address uniquely identifies a point of communication in the global internet\n\nProcess-to-process:\n- Ports enable operating systems to multiplex multiple applications over a single network interface\n- Each process binds to specific ports to send or receive network data\n- The OS maintains a mapping between ports and processes

The Mathematical Address Space:\n\nWith 16 bits, we have exactly 65,536 possible port numbers. This might seem limiting, but remember:\n\n1. Each host has its own complete set of 65,536 ports\n2. TCP and UDP have separate namespaces, effectively doubling the available ports\n3. Ports are endpoints, not connections—many connections can share a server port\n4. The actual limit is on active socket combinations, not port numbers alone\n\nA single server on port 80 can handle millions of concurrent connections because each connection is identified by the four-tuple: (source IP, source port, destination IP, destination port). As long as any element differs, the connection is unique.

Port numbers are represented and notated in specific ways across different contexts. Understanding these conventions is essential for reading documentation, configuring systems, and debugging network issues.\n\nSocket Address Notation:\n\nThe most common representation combines an IP address with a port number, separated by a colon:\n\n\n192.168.1.1:443 # IPv4 address with port\n10.0.0.1:8080 # IPv4 with non-standard HTTP port\n127.0.0.1:3306 # Localhost with MySQL port\n\n\nIPv6 Notation Challenge:\n\nIPv6 addresses contain colons, creating ambiguity. The solution is to wrap the IPv6 address in square brackets:\n\n\n[2001:db8::1]:443 # IPv6 with port\n[::1]:8080 # IPv6 loopback with port\n[fe80::1%eth0]:22 # Link-local with interface\n\n\nURL Notation:\n\nIn URLs, the port follows the host, separated by a colon. Standard ports can be omitted:\n\n\nhttps://example.com:443/path # Explicit port (redundant for HTTPS)\nhttps://example.com/path # Port 443 implied by https://\nhttp://example.com:8080/api # Non-standard port, must be explicit\n

In Protocol Headers (Binary Representation):\n\nWithin actual network packets, port numbers are stored as 16-bit unsigned integers in network byte order (big-endian):\n\n\nPort 443 in binary: 00000001 10111011\nPort 443 in hex: 0x01BB\n\nIn the TCP header (bytes 0-3):\n[Source Port: 2 bytes][Destination Port: 2 bytes]\n\n\nWhen captured in tools like Wireshark, you'll see both the decimal and hexadecimal representations, along with the service name when known (e.g., 443 → https).

Ports exist at the transport layer (Layer 4) of both the OSI model and the TCP/IP model. They appear in the headers of transport layer protocols—primarily TCP and UDP.\n\nPosition in the Protocol Stack:\n\n\nApplication Layer → Uses sockets (IP:port) to send/receive data\n─────────────────────────────────────────────────────────────────\nTransport Layer → TCP/UDP headers contain SOURCE and DEST ports\n─────────────────────────────────────────────────────────────────\nNetwork Layer → IP header contains SOURCE and DEST IP addresses\n─────────────────────────────────────────────────────────────────\nData Link Layer → Frame headers contain SOURCE and DEST MAC addresses\n\n\nEncapsulation Perspective:\n\nWhen an application sends data:\n\n1. Application creates data for a specific destination socket\n2. Transport layer adds a header with source port (local) and destination port (remote)\n3. Network layer adds a header with source IP and destination IP\n4. Data link layer adds a frame header with source MAC and destination MAC (next hop)\n\nWhen data is received, the process reverses:\n\n1. Data link layer removes frame header, passes to network layer\n2. Network layer removes IP header, uses protocol field to choose transport layer handler\n3. Transport layer removes TCP/UDP header, uses destination port to select process\n4. Application receives the data

The Demultiplexing Function:\n\nThe transport layer performs demultiplexing—directing incoming segments to the correct process based on port numbers. This is one of two fundamental transport layer functions (the other being multiplexing at the sender).\n\nFor TCP, demultiplexing uses the full four-tuple:\n- Source IP address\n- Source port\n- Destination IP address\n- Destination port\n\nFor UDP, demultiplexing typically uses only:\n- Destination IP address\n- Destination port\n\nThis difference exists because TCP maintains connection state while UDP is connectionless. A TCP server needs to distinguish between connections from different clients on the same port; UDP simply delivers to whatever process is listening on the destination port.

Before a process can receive data on a port, it must bind to that port. Binding is the act of claiming a port number, telling the operating system: "Send all traffic for this port to me."\n\nThe Binding Process:\n\n1. Process creates a socket (an abstract endpoint for communication)\n2. Process calls bind() to associate the socket with a specific port\n3. Operating system records this mapping in its internal tables\n4. For servers, process calls listen() to begin accepting connections\n5. Incoming packets matching the port are delivered to the socket buffer\n\nExclusive Binding (Default):\n\nNormally, a port can only be bound by one process at a time. If process A binds to port 8080, and process B tries to bind to the same port, the bind() call fails with "Address already in use."\n\nThis exclusivity is essential: it would be chaotic if multiple processes received the same network traffic.

Clients and servers use ports very differently. Understanding these patterns is crucial for network programming, troubleshooting, and security.\n\nServer Port Usage:\n\n- Servers bind to well-known, predictable ports so clients know where to connect\n- The server port remains constant across connections (e.g., HTTP server always on port 80)\n- Servers explicitly bind() to their designated port before accepting connections\n- A single server port can handle thousands of concurrent connections\n\nClient Port Usage:\n\n- Clients use ephemeral (temporary) ports automatically assigned by the OS\n- Each outgoing connection gets a different ephemeral port\n- Clients rarely call bind() explicitly; they let the OS choose a port\n- The client's ephemeral port is used only for the duration of the connection

Connection Example:\n\n\nClient (Browser) Server (Web)\n───────────────── ────────────\nIP: 203.0.113.50 IP: 93.184.216.34\nPort: 54321 (ephemeral) Port: 443 (HTTPS)\n\nFour-tuple identifying this connection:\n(203.0.113.50, 54321, 93.184.216.34, 443)\n\nIf the same client opens another tab to the same server:\nNew ephemeral port: 54322\nFour-tuple: (203.0.113.50, 54322, 93.184.216.34, 443)\n\nBoth connections coexist—different source ports make them unique.\n\n\nWhy Servers Use Fixed Ports:\n\nClients must know where to find servers. If a web server used a random port, how would browsers know where to connect? Standard services use standard ports, creating a universal addressing convention:\n\n- HTTP → Port 80\n- HTTPS → Port 443\n- SSH → Port 22\n- DNS → Port 53\n\nThis convention is codified in the IANA Port Number Registry and embedded in every operating system.

Ports are not just a technical mechanism—they're a critical component of network security. Every open port is a potential entry point for attackers.\n\nPrivileged Port Restriction:\n\nOn Unix-like systems, ports 0-1023 (well-known ports) are privileged. Only processes running as root (or with CAP_NET_BIND_SERVICE capability) can bind to these ports. This restriction exists for security:\n\n- Prevents unprivileged users from impersonating system services\n- A malicious user can't start a fake SSH server on port 22\n- Ensures that well-known services are controlled by the system administrator\n\nPort Scanning and Reconnaissance:\n\nAttackers use port scanning to discover which services are running on a target system. Tools like Nmap probe thousands of ports to build a map of exposed services. Each open port reveals:\n\n- What software is running (service fingerprinting)\n- Potential vulnerabilities to exploit\n- The attack surface of the system

We've established the foundational understanding of ports in the transport layer. Let's consolidate the key concepts:

What's Next:\n\nNow that we understand what ports are and why they exist, we'll explore the three major categories of port numbers in detail. The next page examines well-known ports (0-1023)—the reserved range used by fundamental internet services like HTTP, SSH, DNS, and SMTP.