Port

Reaching a server by its IP address is like finding the entrance to a building. But if a web service, SSH, a database, and a mail server are all running on the same server simultaneously, there is no way to decide which process should receive an arriving packet. An IP address can get you to 'this server' but cannot specify 'which service on this server.' The same problem arises in firewall configuration. When you need to accept web requests from the outside but block database connections, having no way to distinguish services on a single IP leaves only an all-or-nothing choice. Port numbers solve this by providing a second coordinate that identifies the service within a single IP address.

In the early days of networking, each server handled only one role, so identifying a service by IP address alone was straightforward. But as server hardware improved and operational efficiency became important, running multiple services on a single server became natural. Once web servers, mail servers, and file servers shared the same physical machine, a mechanism for deciding which process should receive a packet after it arrives became essential. Including a 16-bit port number in the transport-layer header when TCP/IP was designed was the answer to this problem. IANA (Internet Assigned Numbers Authority) assigned fixed numbers to well-known services, allowing clients to reach the desired service using a pre-agreed number. Today's concepts like container port mapping and Kubernetes service ports versus target ports all stand on this same foundation.

A port is a logical number managed by the operating system's network stack. When a process binds to a specific port on a server, packets arriving at that port are delivered to that process. When a client connects, the operating system automatically assigns an unused ephemeral port from the 49152--65535 range as the source address. The unit that actually identifies a connection is not the port alone but the 5-tuple: source IP and port, destination IP and port, and protocol. That is why different clients can connect to the same server port 443 simultaneously and each connection remains distinct. Port numbers live in TCP and UDP headers, working together with the IP header's addresses to route packets to the correct destination.

Ports and sockets frequently appear together in network programming but serve different roles. A port is a number between 0 and 65535 that identifies which door a service is listening on. A socket is a communication endpoint created by combining the protocol, IP, and port, representing the actual connection over which data is exchanged. Thousands of sockets can be open on the same port 80 because sockets combine source information to distinguish individual connections. Port numbers alone do not complete security either. Closing a port is like locking a door, not protecting the building. If the service behind an open port is vulnerable, that port remains an attack surface as long as it stays open. That is why port management must work together with firewalls, authentication, and encryption to achieve real security.

Port numbers come up repeatedly across operational tasks such as server deployment, firewall rules, container mapping, and load balancer configuration. Deciding which ports to open when deploying a new service is really deciding what to expose and what to hide, and security group or firewall rules are mostly organized by port number. However, a port number is just a service identifier -- it does not guarantee the safety of the service. Even if port 443 is open, it is meaningless if the application behind it is vulnerable, and changing to a non-standard port provides no real defense against scanning tools. The core principle of port management is minimum exposure: open only the ports you need and close the rest. This only becomes meaningful when combined with firewalls, TLS, and authentication.