Jan Mikoláš
Glossary
Network port
An IP address brings traffic to a network interface, and a port directs it to the correct service. The port does not say whether the service is secure, public or authorized for a specific user.
Short definition
A logical service number at a network address, not a connector or password.
Multiple network services can run at one IP address. A port allows the operating system to distinguish whether incoming traffic belongs to a web server, database or another application. A destination endpoint therefore consists of at least an IP address, transport protocol and port, such as a TCP connection to 203.0.113.20:443.
A server service listens on a port, while a client usually uses a temporary source port for a connection. TCP and UDP have separate port spaces, so the same number can simultaneously identify different TCP and UDP services. A port does not provide encryption, sign-in or application permissions; those are the responsibilities of TLS, the firewall and the application itself.
The problem it solves
It allows multiple network services to share one address
Without ports, the operating system would not know which process should receive incoming network data at the same IP address.
- an HTTP service typically accepts traffic on TCP port 80 and HTTPS on TCP port 443
- SSH for server administration commonly runs on TCP port 22, but access rules and keys must provide the security
- an application, PostgreSQL and Redis can communicate on internal ports that are inaccessible from the internet
- Docker can map a container port to a host port for local development or a precisely defined public entry point
- a reverse proxy allows multiple applications to share public port 443 and distinguishes them by hostname or path
Practical example
One public port, several internal services
An online store can expose only a reverse proxy on TCP port 443. The proxy accepts HTTPS for www.example.cz and api.example.cz and forwards it to the application on port 8080 on the internal network. PostgreSQL on port 5432 and Redis on port 6379 remain accessible only from the private network by the application and workers.
The database ports here are examples of common defaults, not universal instructions. Whether a specific port is reachable depends on a combination of the process, interface binding, Docker mapping, network rules and firewall.
Network service separation
Internet
│ TCP 443 (HTTPS)
▼
reverse proxy
├── app:8080 interní aplikace
├── postgres:5432 pouze interní síť
└── redis:6379 pouze interní síťHow it works
From the destination address to the process handling the connection
The operating system evaluates the address, protocol and port before passing data to a specific service.
- The client selects an endpoint After DNS resolution, the URL https://api.example.cz normally leads to TCP port 443 over HTTPS. If the URL specifies a non-standard port such as :8443, the client uses it instead of the default.
- The network delivers packets to the IP address Routers route according to the IP address. The port is not used for global routing; it becomes relevant only when data reaches the destination system.
- The transport layer distinguishes the connection TCP or UDP uses the source and destination addresses and ports to distinguish flows. TCP also establishes a reliable connection, while UDP works with datagrams.
- A process listens on the port A web server, database or other service can accept data only when it uses the given port and network rules do not block the traffic.
- The application performs its own checks TLS, HTTP, authentication, authorization and input validation occur only after the connection is opened. An open port is not permission to perform an arbitrary operation.
Important related concepts
The port number is only one part of a network endpoint.
The context always includes the transport protocol, IP address, network rules and the process actually running on the port.
TCP and UDP
TCP and UDP use ports but have different properties. TCP works with connections and delivery checks, while UDP transmits independent datagrams. The same port number does not necessarily identify the same service.
Server and client ports
A server usually listens on an expected port. The client chooses a temporary source port for a specific connection so that it can communicate with multiple services at the same time.
Port ranges
IANA distinguishes system ports 0–1023, user ports 1024–49151 and dynamic or private ports 49152–65535. Registering a number is not a security endorsement of the service.
Port in a URL
A URL can specify a port after a colon in the host portion. If it is omitted, the scheme normally defines the default, such as 80 for http and 443 for https.
Exposure and the firewall
A service can listen only on loopback, on an internal network or on a public interface. Docker port mapping and the firewall determine whether another system can reach it at all.
Benefits and limitations
Ports let services run concurrently but create additional public exposure.
Benefits
- multiple services can operate at one IP address
- standard ports improve interoperability between clients and network tools
- internal ports allow the application, database, cache and workers to be separated
- a reverse proxy can centralise the public HTTPS entry point on a single port
Limitations and common mistakes
- changing a port number does not replace a firewall or authentication
- carelessly publishing a container port can expose an internal service
- a database exposed to the internet unnecessarily expands the attack surface
- excessive timeouts on a public port can tie up resources
- the same number on TCP and UDP must be treated as two different traffic possibilities
Practical boundaries
Expose only the ports that a public service genuinely needs.
For a typical web application, it makes sense to concentrate public traffic at an HTTPS entry point. A reverse proxy can serve multiple domains and applications on port 443, while the PHP runtime, queue, cache and database communicate over the internal network. This design simplifies firewall rules, monitoring and the separation of responsibilities.
A non-standard port can make sense for an internal service, local development or a separate technical protocol. It must not be used to hide a service. Documentation, configuration variables, health checks and access rules need to describe who may connect to the port and how the application actually verifies the request.
What to consider
Design ports as part of an explicit network policy.
A clear record of what listens on each interface and who may connect to it is important for both security and operations.
- document public endpoints and allow only the expected ports from the internet
- keep databases, caches and administration services on an internal network or behind precisely defined access controls
- distinguish expose for internal documentation from actually publishing a port on the host in Docker Compose
- include a non-standard port in a URL only when the client genuinely needs to know it
- monitor the service behind the port as well: an open TCP connection does not prove the application is healthy
- do not treat a port, IP allowlist or hidden banner as a substitute for authentication and regular updates
Common questions
How to use network ports securely
Is a network port a physical connector?
No. It is a number used by the transport protocol to distinguish a service or connection at a network address.
Is port 443 always secure?
No. It is the common port for HTTPS, but security depends on the TLS configuration, application, authentication, authorization and operational rules.
Does every application need its own public port?
No. A reverse proxy can route multiple domains or paths to different internal applications on a single public port 443.
Can I secure a database simply by changing its port?
No. A database should be private where appropriate and protected by the network and its own authentication. A non-standard port number is not a security control.
How I design application operations
I separate the public HTTP entry point from internal services and their data.
When designing backends, I address the network boundary, reverse proxy, database services and monitoring so that operations remain clear and controllable.