IP Addresses and TCP Ports: The House and the Doors

IP Addresses Tell You the Building; Ports Tell You the Apartment

Every device connected to the internet has an IP address. But a modern computer runs dozens of network-connected processes simultaneously — a web browser fetching pages, an email client checking mail, a video call app streaming audio and video, a background updater downloading patches. How does the operating system know which incoming packet belongs to which application?

The answer is TCP ports. A port is a 16-bit unsigned integer — a number from 0 to 65535 — that the operating system uses to multiplex network traffic across multiple applications on a single IP address. When a packet arrives at your machine, the OS looks at both the destination IP (which confirms the packet is for this machine) and the destination port (which tells it which application should receive the data).

Together, an IP address and a port number form a socket — the complete addressing unit for a network endpoint. A socket is written as IP:port, for example 93.184.216.34:443. Every active network connection is uniquely identified by four values: source IP, source port, destination IP, and destination port. This four-tuple is how your OS tracks thousands of simultaneous connections without mixing them up.

How TCP Ports Work: The Technical Mechanics

When a server application starts, it calls the OS to bind to a specific port number. The OS opens a listening socket on that port and waits for incoming connection requests. Any TCP packet arriving at the server's IP with that port as the destination is forwarded to the waiting application.

When a client initiates a connection — your browser opening a connection to a web server — the client's OS randomly assigns a source port from the ephemeral port range (typically 49152-65535 on modern systems, though Linux defaults to 32768-60999). This source port identifies your specific browser connection back to the server's responses. The server's responses are addressed to your IP and your ephemeral source port, ensuring they arrive at the right browser tab even if you have multiple tabs open to the same server.

The TCP connection setup uses a three-way handshake: the client sends a SYN packet to the server's IP and port, the server responds with SYN-ACK, and the client completes with ACK. After this exchange, a reliable, ordered byte stream exists between the two sockets. Both sides now know exactly which four-tuple (src IP, src port, dst IP, dst port) identifies this connection.

Port Number Categories

The Internet Assigned Numbers Authority (IANA) divides the 65536 port numbers into three ranges with different management policies:

Critical Well-Known Ports Every Engineer Should Know

TCP vs. UDP: Different Port Behaviors

Ports exist in both TCP and UDP. The protocols handle them differently:

TCP is connection-oriented. Before any data flows, a handshake establishes a connection. The port is reserved for the duration of the connection. TCP provides guaranteed, ordered delivery through sequence numbers and acknowledgments. It is used for HTTP, SSH, SMTP, and any application where data integrity matters.

UDP is connectionless. A UDP socket can receive packets from any source at any time on its port, with no handshake. Each datagram is independent. UDP is used for DNS queries, streaming media, VoIP, and online games — applications where low latency is more important than guaranteed delivery. The same port number can be used by both a TCP service and a UDP service simultaneously (for example, port 53 is used by DNS over both protocols).

Real-World Use Cases

Web servers: An Nginx or Apache process binds to port 80 (HTTP) and 443 (HTTPS). The OS delivers incoming packets destined for those ports to the web server process. Multiple simultaneous connections — thousands of concurrent HTTP requests — are distinguished by their unique source IP and source port combinations, all arriving at the same destination port 443.

Database security: MySQL (3306) and PostgreSQL (5432) bind to those ports by default, but these ports should never be reachable from the internet. Firewall rules should restrict access to those ports to only the specific application server IPs that need database access. A misconfigured security group that exposes port 3306 to 0.0.0.0/0 is one of the most common cloud infrastructure security mistakes.

SSH hardening: Many administrators change the SSH port from the default 22 to a non-standard port (like 2222 or 22222). This does not provide real security, but it eliminates the constant automated scanning noise from bots that exclusively scan port 22. Actual security comes from key-based authentication and fail2ban, not port obscurity.

Port forwarding: On a home network, NAT means that multiple devices share a single public IP. Port forwarding tells the router that incoming connections on a specific public port should be forwarded to a specific private IP and port. For example, forward public port 8080 to 192.168.1.100:80 to expose a home server's web interface.

Common Misconceptions

Two programs can't use the same port number at all

This is mostly true but has nuances. Two programs cannot both bind to the same IP address and port in the same protocol (TCP or UDP) simultaneously — that will produce an address already in use error. However, a TCP service and a UDP service can both use port 53 simultaneously (DNS does exactly this). Additionally, the SO_REUSEPORT socket option on Linux allows multiple processes to bind to the same port and share incoming connections — used by high-performance servers like Nginx and HAProxy to distribute load across worker processes.

The client connects from port 80 when accessing a web server

The client connects to port 80 on the server. The client's own source port is an ephemeral port randomly assigned by the OS (typically in the range 49152-65535). This is a very common confusion. When you access http://example.com, your computer is connecting from, say, port 54321 on your machine to port 80 on the server's machine.

Closing an application immediately frees its port

In TCP, a closed connection enters a TIME_WAIT state that persists for a period after the connection ends — typically two minutes (2× the Maximum Segment Lifetime, or MSL). During this time, the port binding may still appear in use. This prevents old delayed packets from being confused with new connections on the same port. High-traffic servers can accumulate thousands of TIME_WAIT connections, which is normal and expected behavior.

Port scanning tells you everything about a server's security

Port scanning (using tools like nmap) tells you which ports are open and accepting connections. It does not tell you the version of the software, whether the software is vulnerable, what authentication is required, or what data is accessible. An open port is a necessary but not sufficient condition for a security vulnerability. A properly configured service on an open port is not inherently dangerous.

Pro Tips

• Use ss -tlnp on Linux to see all listening TCP sockets with their process names. This is faster than netstat and gives you the complete picture of what is bound to what port on your server. Run it before and after installing software to understand what new ports were opened.
• Firewall rules should default-deny all inbound ports and explicitly allow only what is required. Every open port is a potential attack surface. For a typical web server, only ports 80 and 443 should be reachable from the internet; all other ports should be blocked at the firewall regardless of what the application-level binding configuration says.
• For development servers, bind to 127.0.0.1 instead of 0.0.0.0. Binding to 127.0.0.1 means only local processes can connect to that port. Binding to 0.0.0.0 means any interface — including external network interfaces — can reach it. Accidental exposure of development databases and admin interfaces is a frequent cause of cloud security incidents.
• Check for RFC 6335 before using a port number for a custom service. IANA maintains the official port number registry. Using a registered port for a different service can cause unexpected conflicts with legitimate applications that expect to use that port.
• Monitor for unexpected open ports as part of your security baseline. Run periodic nmap scans against your own servers from an external IP to verify that only intended ports are reachable. Any port that appears in scan results but is not in your approved baseline requires immediate investigation.
• For latency-sensitive applications, tune the ephemeral port range on Linux with sysctl net.ipv4.ip_local_port_range. Under very high connection rates, a narrow ephemeral port range can be exhausted, preventing new outbound connections. Widening the range is a quick fix for connection exhaustion under load.

Ports are the mechanism that makes internet multitasking possible. Every web page you load, every email you send, and every database query your application makes relies on a specific port number to route the traffic to the right destination service. Mastering port concepts is foundational to network administration, application development, and security engineering. Scan your own open ports here.