When you type a web address and a page appears, a quiet little conversation happens behind the curtain. Your browser finds the right machine, knocks on a specific door, and speaks in a language the machine already understands. Two ideas make that possible: ports and protocols. They sound like networking jargon reserved for people who wear headsets in server rooms, but the concepts are simpler than they look, and understanding them will make a lot of everyday development feel less like guesswork.
This guide walks through both ideas slowly, with plain wording and a few small pictures. By the end, you’ll know why :443 shows up in some addresses, what HTTP and TCP actually are, and how to read a URL like an address on an envelope.
What a port really is
Imagine a large office building with one street address. Mail arrives at that address all day long, but the building has many offices inside it. If a letter just said “deliver to this building,” the mailroom wouldn’t know where to take it. So letters also carry a room number. The street address gets the letter to the building; the room number gets it to the right desk.
A computer works the same way. The machine has one network address (its IP address, like 203.0.113.10), but a single machine usually runs several network programs at once: a web server, maybe a mail server, maybe a remote-login service. A port is the room number. It’s a numbered door on the machine that points to one specific program.
So a port is not a physical thing you can touch. It’s just a number, from 0 to 65535, that the operating system uses to decide which program should receive an incoming message.
IP address = the building
┌──────────────────────────────────┐
│ 203.0.113.10 │
│ │
│ :80 → web server (HTTP) │
│ :443 → web server (HTTPS) │
│ :22 → SSH (remote login) │
│ :25 → mail server (SMTP) │
└──────────────────────────────────┘
Ports = the room numbersWhen a program wants to receive traffic, it “listens” on a port. The web server says, in effect, “anything that arrives on port 443 is for me.” When your browser sends a request to that port, the operating system hands it straight to the web server and nobody else.
One IP, many doors
A single server can host a website, a mail service, and remote access all at the same time, simply because each one waits at a different port. The IP address gets you to the machine; the port decides which service answers.
Common ports worth memorizing
A handful of port numbers come up constantly. Some are so standard that software assumes them by default, which is why you rarely type them by hand. Here are the ones every developer ends up recognizing:
| Port | Used for | Plain meaning |
|---|---|---|
| 80 | HTTP | Plain (unencrypted) web traffic |
| 443 | HTTPS | Encrypted web traffic |
| 22 | SSH | Secure remote login to a server |
| 25 | SMTP | Sending email between mail servers |
A few notes that make these stick. Port 80 is the original door for the web; when HTTP began, this was the default and still is for non-encrypted pages. Port 443 is its secure sibling: the same web traffic, but wrapped in encryption so nobody in the middle can read it. Today almost every real website uses 443.
Port 22 is for SSH, short for Secure Shell. It’s how you log in to a remote server from your own terminal to run commands, deploy code, or fix something. If you’ve ever managed a server, you’ve almost certainly knocked on port 22.
Port 25 belongs to SMTP (Simple Mail Transfer Protocol), the system that carries email from one mail server to another. There are other mail-related ports too, but 25 is the classic one to recognize.
Ports below 1024 are special
Ports from 0 to 1023 are called “well-known” ports and are reserved for standard services. On most systems, only an administrator can start a program that listens on these. That’s a small safety measure so a random app can’t pretend to be the web server.
What a protocol is
A port tells you where a message should go. A protocol tells you how the two sides should talk once the message arrives. It’s the agreed set of rules for the conversation: what counts as a greeting, what order things happen in, how to mark the end of a message, and what a valid reply looks like.
Think of two people on a phone call. Even before they discuss anything, they follow an unspoken script: one says hello, the other answers, they take turns, and they say goodbye before hanging up. If one person spoke French and the other only understood Japanese, the call would fail no matter how clear the connection was. A protocol is that shared script for computers.
Several protocols matter for web work, and they sit at different layers. Some handle the delivery of raw data; others handle the meaning of the data on top.
TCP and UDP: getting data across
At the delivery layer, two protocols dominate: TCP and UDP.
TCP (Transmission Control Protocol) is the careful courier. Before sending anything, it sets up a connection with a small back-and-forth (often called a handshake), then sends your data in order and checks that every piece arrived. If something gets lost along the way, TCP notices and resends it. This reliability is why the web, email, and file transfers all sit on top of TCP. You get correctness, at the cost of a little extra overhead.
UDP (User Datagram Protocol) is the opposite personality: fast and casual. It just fires the data off without setting up a connection or confirming delivery. Some packets might arrive out of order or not at all, and UDP won’t lose sleep over it. That sounds worse, but for things like live video, voice calls, or online games, speed matters more than perfection — a single missing frame is better than waiting for a re-send that arrives too late.
TCP → "Did you get packet 1? Good. Packet 2? Good. Packet 3?"
Reliable, ordered, a bit slower. (web, email, downloads)
UDP → "Here's the data. Bye."
Fast, no guarantees. (video calls, games, live streams)HTTP: the language of the web
On top of TCP sits HTTP (HyperText Transfer Protocol), the protocol your browser and web servers use to exchange pages, images, and data. HTTP defines the shape of a request (“please give me this page”) and the shape of a response (“here it is, and here’s a status code telling you how it went”).
HTTPS is simply HTTP with a layer of encryption underneath. The rules of the conversation are the same; the difference is that the whole exchange is scrambled so it can’t be read or tampered with in transit. This is why the secure web lives on port 443 while plain HTTP lives on port 80 — same language, different door, one of them wearing armor.
Don't confuse ports and protocols
A port is a number that points to a program. A protocol is the set of rules for talking to it. They work together but they aren’t the same thing: HTTPS (a protocol) usually travels over port 443 (a door), but you could technically run it on a different port if you configured the server that way.
How host:port works in a URL
Now the two ideas come together in something you see every day: a web address. A URL secretly contains both the machine you want and the door to knock on, even when part of it is hidden.
Take this full address:
https://blog.acy-partner.com:443/articles
│ │ │ │
scheme host port pathRead it left to right:
httpsis the scheme — it names the protocol. It tells the browser “speak HTTPS for this.”blog.acy-partner.comis the host — the name of the machine, which the browser turns into an IP address behind the scenes.:443is the port — the specific door on that machine./articlesis the path — which page or resource you want once you’re inside.
Here’s the part that confuses newcomers: you almost never type the port. That’s because each scheme has a default. When you write https://, the browser quietly assumes :443. When you write http://, it assumes :80. So these two addresses mean exactly the same thing:
https://acy-partner.com/contact
https://acy-partner.com:443/contactThe port is still there. It’s just invisible because it matches the default.
You’ll see the port written out most often during local development. When you run a development server on your own machine, it commonly listens on a non-standard port, so you visit something like:
http://localhost:3000Here localhost means “this very machine” and :3000 is the door your dev server chose. Because 3000 isn’t a default for any scheme, you have to include it, otherwise the browser would try port 80 and find nobody listening.
A quick mental test
If an address doesn’t show a port, ask yourself what protocol it uses. https:// → port 443. http:// → port 80. The default is always there, just hidden. If you ever see a port like :8080 or :5432, that’s a service running somewhere other than the usual door.
If you’d like to go a layer deeper into how addresses and ports cooperate on real servers, this companion piece covers it from the server side: IP Addresses and Ports (server).
Recap
Ports and protocols are the two halves of every network conversation, and neither is as intimidating as the names suggest.
- A port is a numbered door on a machine, from 0 to 65535. The IP address gets a message to the right computer; the port gets it to the right program.
- A few ports are worth knowing on sight: 80 (HTTP), 443 (HTTPS), 22 (SSH), and 25 (SMTP). Ports under 1024 are reserved for standard, privileged services.
- A protocol is the agreed set of rules for how two sides talk. TCP delivers data reliably and in order; UDP delivers it fast without guarantees. HTTP is the web’s language, and HTTPS is the same language with encryption added.
- In a URL, the shape is
scheme://host:port/path. The port is often hidden because each scheme has a default —httpsmeans:443,httpmeans:80— but it’s always implied.
Once these click, a lot of small mysteries dissolve: why a local app lives at :3000, why secure sites show 443, why you SSH into a server over 22. It’s all just doors and the rules for talking through them.
