KAHIBARO
Discord Login Register ☰
☰

2.5. Ports

Table of Contents

Understanding Ports

When your browser talks to a server on the Internet, it is not enough to know which computer to talk to. You also need to know which application on that computer should receive the data. This is what ports are for.

This chapter explains ports from a backend developer perspective, with many practical examples you will see in web development.

What Is a Port?

Every machine on a network is identified by an IP address. But a machine almost always runs many networked programs at the same time. For example, on one server you might have:

All of these need to receive and send data over the network.

A port is a number that identifies a specific networked application (or service) on a machine.

You can think of it like this:

To talk to a specific service, you need both:

Together they give you a complete destination like:

This says: "Connect to the machine at IP 203.0.113.10, application listening on port 5432."

Port Numbers and Their Ranges

Ports are just integers between 0 and 65535.

The range is:

$$ 0 \leq \text{port} \leq 65535 $$

This is because ports are stored as 16-bit unsigned numbers, and $2^{16} = 65536$ possible values, from 0 to 65535.

Rule: Valid TCP or UDP port numbers are from 0 to 65535. Values outside this range are invalid.

Port numbers are divided into three main ranges:

RangeNameTypical Use
0 to 1023Well-known portsStandard services like HTTP, HTTPS, SSH, FTP, DNS, etc.
1024 to 49151Registered portsServices registered by companies or projects
49152 to 65535Dynamic / privateTemporary ports chosen by clients (ephemeral ports)

As a backend developer, you will most often care about:

Common Ports Backend Developers Should Know

Here are some of the ports you will see all the time.

Web and API related

PortProtocol / UseExample
80HTTPhttp://example.com defaults to port 80
443HTTPShttps://example.com defaults to port 443
8080Alternative HTTP portLocal dev servers, proxies, test servers
3000Common dev portNode.js, frontend dev servers, some APIs
8000Common dev portDjango, FastAPI, local API servers
8001Alt. dev / admin portAdmin interfaces, second service instance

Database related

PortService (often default)
5432PostgreSQL
3306MySQL / MariaDB
6379Redis
27017MongoDB

System and remote access

PortService
22SSH
25SMTP (sending email)
53DNS

You do not have to memorize all ports, but you should quickly recognize:

How Ports Work with IP and Protocol

A full network address for a service is actually a combination of:

So a connection is identified by:

$$ \text{Protocol} + \text{IP} + \text{Port} $$

As a result, these are all different "endpoints":

Even if the port numbers match, different protocols or IPs give you different endpoints.

For web backends, you will almost always work with TCP ports. UDP is used in other contexts, such as DNS or streaming.

Important: When people say "port 80" in web development, they almost always mean TCP port 80.

Listening Ports and Active Connections

On a machine, there are two important concepts:

  1. Listening port
    • A server program calls a system function that says: "I want to listen on port X."
    • Example: Nginx listens on port 80, PostgreSQL listens on 5432.
  2. Active connection
    • When a client connects, the operating system creates a connection between:
      • Client IP + client port
      • Server IP + server port

So for one connection you can think of this 4-part combination:

This combination is often called a "4-tuple."

Clients usually use ephemeral ports (high ports) chosen automatically by the OS.

Example:

Your browser might be using port 51123 on your machine to connect to port 443 on the server. If you opened another tab to the same site, your browser might open a second connection like:

The server still listens on 443, but there are multiple connections to it from different client ports.

Ports in URLs

When you type a URL in your browser, you often do not see the port. The browser uses default ports based on the scheme:

You only see a port in the URL if it is not the default:

Example comparisons:

URLSchemeHostPort used
http://example.comhttpexample.com80
https://example.comhttpsexample.com443
http://localhost:3000httplocalhost3000
https://api.example.com:8443httpsapi.example.com8443

As a backend developer, in development you will very often specify ports explicitly in URLs, for example:

Localhost and Common Development Ports

When you run services on your own machine, you almost always connect to localhost with a port:

Examples in backend development:

Example workflow:

  1. Start a FastAPI app:
bash 
   uvicorn main:app --reload --port 8000

This command tells Uvicorn to listen on port 8000.

  1. Now you can open:
    • http://localhost:8000/ in your browser
    • Or call it from another script:
python 
     import requests
     response = requests.get("http://localhost:8000/health")
     print(response.status_code, response.text)

If you change --port 8000 to --port 5000, then you must also change the URLs you use to http://localhost:5000.

What Happens If a Port Is Already in Use?

Only one process on a machine can listen on a specific port for a specific protocol and IP combination.

If you try to start a second server on the same port, you will usually get an error, for example in Python:

text 
OSError: [Errno 98] Address already in use

Typical situations:

Solutions:

As a backend developer, you will often change ports when:

Ports and Firewalls

A firewall is a system that can allow or block network traffic based on rules. One of the most common things a firewall checks is the port number.

For example, on a production server you might configure:

This means:

In cloud providers like AWS, DigitalOcean, GCP, you will see firewall-like settings called "security groups" or "firewalls" that typically specify allowed port ranges.

Ports on the Server vs Ports on the Client

When a client connects to a server, both sides use ports, but for different purposes.

For example, when your browser connects to a website:

If you click another link:

You usually only configure the server side ports. The client side ports are handled by the operating system.

Multiple Services on One Server With Different Ports

One physical or virtual machine can host many services at once by using different ports.

Example:

ServicePortURL or Address
Main website80http://example.com
Secure website443https://example.com
Admin API8443https://example.com:8443
PostgreSQL DB5432postgres://db.example.com:5432/...
Redis cache6379Connected to from app code, not browser

Clients choose which service to talk to by picking the right port.

In many real deployments, you might hide some ports behind a reverse proxy so that external clients only see port 80 and 443, while your backend services talk to each other on internal ports.

Ports and Docker (Briefly)

You will learn Docker in detail later, but ports are important there too.

When you run a Docker container, it can expose a port inside the container. To reach it from your host machine, you map a host port to a container port.

Example:

bash 
docker run -p 8000:80 my-web-app

This means:

You will do this often when running databases, Redis, or API servers in containers.

Practical Exercises You Can Try

You can try these on a Linux or macOS terminal. On Windows, use PowerShell with appropriate equivalents.

See which ports are listening

On Linux or macOS:

bash 
sudo lsof -i -P -n | grep LISTEN

You will see output like:

text 
nginx   1234 root   6u  IPv4  12345  0t0  TCP *:80 (LISTEN)
postgres 5678 postgres 7u IPv4  23456  0t0 TCP 127.0.0.1:5432 (LISTEN)

This tells you which applications are listening on which ports.

Run a simple Python HTTP server on a custom port

In a directory with some files, run:

bash 
python -m http.server 9000

Now open:

If you run a second one on a different port:

bash 
python -m http.server 9001

You can now access:

Same program, same machine, different ports, so they can coexist.

Summary

Understanding ports is essential when you configure servers, connect to databases, run services in Docker, or debug network connectivity issues in backend development.

Views: 9

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3057 / 24h
Impressum / Imprint
Datenschutz / Data Policy