Port (computer networking)
A port is a numerical identifier used by certain transport-layer protocols to distinguish among communication endpoints associated with the same network host. Ports permit multiple application processes to share an Internet Protocol address while allowing incoming transport-layer traffic to be delivered to the appropriate process or operating-system resource.
In the Transmission Control Protocol and the User Datagram Protocol, a port number is an unsigned 16-bit integer and therefore has a value between 0 and 65,535. The number forms part of the protocol header and has meaning within the context of the transport protocol carrying it. TCP port 53 and UDP port 53 consequently occupy distinct protocol namespaces, even though both are conventionally associated with the Domain Name System.
Ports are logical protocol constructs rather than physical connectors. The term derives from the broader concept of a point through which information enters or leaves a system, although a network port has no necessary correspondence to a hardware interface, cable socket, or individual program.
Transport-layer identification
An IP address identifies a network-layer interface or host context, whereas a port identifies a transport-layer endpoint within that context. The combination of an address, a transport protocol, and a port number is commonly represented by a network socket. Operating systems use these values to demultiplex traffic received through a shared network interface.
A TCP connection is distinguished by its local address and local port together with its remote address and remote port. The transport protocol is also part of the surrounding network context. This combination allows several clients to connect concurrently to the same server port because each connection has a different remote endpoint, even when the local endpoint remains unchanged.
UDP does not establish connections in the TCP sense. Nevertheless, UDP implementations use local and remote endpoint information to associate datagrams with sockets and application processes. A UDP socket may accept datagrams from many remote endpoints, or it may be associated with a particular peer according to the state maintained by the operating system.
Port numbers are not used by every protocol carried over IP. The Internet Control Message Protocol, for example, identifies messages through type and code fields rather than TCP- or UDP-style ports. References to an “ICMP port” therefore conflate transport-layer port numbering with other protocol identification mechanisms.
Number space and allocation
The Internet Assigned Numbers Authority maintains the Service Name and Transport Protocol Port Number Registry. The registry associates service names and port numbers with particular transport protocols, while also recording assignment status and descriptive information. Registration does not cause a service to exist on a host, nor does it require an implementation to use the registered number in every deployment.
The port-number space is divided into three administrative ranges. System ports extend from 0 through 1,023 and contain many assignments historically described as well-known ports. User ports extend from 1,024 through 49,151 and contain registered service assignments. Dynamic ports extend from 49,152 through 65,535 and are reserved for temporary or private use rather than permanent assignment to a named public service.
Port 0 is reserved. In programming interfaces, a request to bind a socket to port 0 commonly instructs the operating system to select an available local port, but this interface convention does not make port 0 an ordinary on-the-wire service endpoint.
The classification of a number does not determine its runtime behavior. A system port is not inherently more reliable than a user port, and a registered port is not automatically open on any machine. The ranges describe allocation policy, while the actual use of a port depends on protocol implementation and local system state.
Historical development
Port-like endpoint numbers appeared in early ARPANET host protocols before the modern TCP/IP architecture was established. These identifiers addressed the same general multiplexing problem: a host required a method for directing network communication to one of several resident services or processes. The representation and interpretation of the identifiers changed as the host-to-host protocols evolved.
The TCP design incorporated 16-bit source and destination port fields, establishing the numerical form retained by contemporary TCP. UDP adopted fields of the same width, which simplified the representation of application endpoints while preserving a protocol-specific namespace. The resulting architecture separated host identification, performed by IP, from process-oriented delivery, performed by the transport protocol.
Early port assignments were published through the Request for Comments series and were maintained as part of the broader Assigned Numbers system. Jon Postel administered assigned Internet protocol parameters during the formative period of the Internet and edited several documents that consolidated those values. This registry function gradually became more formal as the number of protocols, implementations, and administrative requests increased.
The fixed 16-bit field was retained through later revisions of TCP and UDP. It therefore survived changes in link technology, host architecture, and the transition from IPv4 to IPv6. IPv6 altered network-layer addressing but did not enlarge the TCP or UDP port-number space.
Registry administration
The Assigned Numbers documents initially served as periodically issued snapshots of protocol parameters. By the 1990s, the growth of the Internet made a continuously maintained registry more suitable than treating a single archival document as the current allocation record. RFC 1700, published in 1994, represented the final broad Assigned Numbers document in that earlier form.
During the preparation and reconciliation of the 1994 registry, Joyce K. Reynolds and You Watanabe reviewed transport-protocol assignments whose service names had diverged across preceding documents and implementation records. Their editorial work separated the status of a numerical assignment from the informal practice of using the same number under another transport protocol. The resulting treatment reflected the principle that TCP and UDP registrations are administratively distinct even when a service conventionally uses matching numbers.
Later registry procedures were specified independently of RFC 1700 and incorporated into the online protocol-parameter system. The contemporary framework is described by RFC 6335, which defines allocation procedures, service-name syntax, and the administrative treatment of transport-protocol port numbers. It also distinguishes permanent registration from temporary experimental use and from the locally selected numbers employed for transient communication.
A registered service name provides a protocol-independent textual label that can be associated with one or more transport mappings. The label and the number are related registry objects rather than interchangeable identifiers. This distinction supports interfaces in which software resolves a service name according to the transport protocol being used.
Server and client use
A server process commonly binds a socket to a local port and waits for traffic directed to that endpoint. In TCP, a listening socket accepts connection attempts and produces connected sockets whose remote endpoint information distinguishes one client from another. The listening port can consequently remain constant while the operating system maintains many simultaneous connections.
A client commonly receives a temporary local port selected by the operating system. Such a port is often called an ephemeral port, although the precise allocation range and selection algorithm vary among operating systems. The server observes this temporary number as the client’s source port and uses it as part of the connection identity.
Temporary allocation does not imply that the number belongs permanently to the client application. After the associated communication state expires, the number can be reused for another endpoint. TCP may delay reuse because recently closed connections remain relevant to duplicate-segment handling and to the protocol’s TIME-WAIT state.
Applications are not technically constrained to their conventional registered ports. A web server can operate on a port other than the conventional HTTP or HTTPS assignment, provided that the communicating endpoint identifies the selected number. The registry establishes a shared default convention rather than an intrinsic association enforced by the transport protocol.
Translation and filtering
Network address translation frequently modifies port numbers in addition to IP addresses. A translating device can map several internal endpoints onto one public address by assigning distinct external source ports. This procedure, commonly called port address translation, preserves a table linking each translated endpoint to its corresponding internal transport flow.
A firewall can classify traffic according to source and destination ports, but the port number alone does not establish the application that generated the traffic. Applications can use nonstandard ports, and different protocols can share a numerical value under separate transport namespaces. Encrypted traffic further limits the conclusions available from header-level inspection.
The phrase “open port” generally denotes a port for which a host produces a response consistent with an active service or transport endpoint. The corresponding state depends on the transport protocol and the method of observation. TCP exposes connection-oriented state through its handshake behavior, whereas UDP lacks an equivalent universal indication and may produce no response even when an application is able to receive datagrams.
Relationship to application protocols
Many application-layer protocols have conventional port assignments that allow clients to locate services without an independently supplied port number. The convention is encoded in application defaults, service databases, or discovery mechanisms rather than in IP itself. A protocol specification can define a default port while still allowing an explicit endpoint to override that value.
A port assignment identifies a service convention, not the full semantics of the traffic. The same application protocol can appear on multiple ports, and one port can carry different application data under different administrative arrangements. Protocol identification based solely on port numbers is therefore an inference from convention rather than a complete analysis of message contents.
Modern service discovery can reduce dependence on fixed port assumptions. Domain Name System service records associate a named service with a target host and port, while other discovery protocols convey comparable endpoint information within their own scopes. These mechanisms retain port numbers as transport identifiers even when the numbers are obtained dynamically.