Networking Basics: IP Addresses, Ports, and Protocols

Picture the postal system for a moment. When you send a letter, you write a street address so it reaches the right building, you add an apartment or room number so it reaches the right person inside, and you write it all in a language the recipient can read. Miss any one of those three and the letter never arrives, or it arrives and nobody can make sense of it. Computer networking works in almost exactly the same way, and once you see that parallel clearly, a huge amount of security stops feeling like magic.

You cannot get far in security without a basic feel for networking, but the good news is that three ideas carry most of the weight: IP addresses, ports, and protocols. They are the address, the room number, and the language. Get these three straight and firewalls, DNS, web traffic, and most of the attacks you will read about later all start to slot neatly into place. Let us take them one at a time, slowly, and then join them back together.

IP address: which machine

An IP address identifies a device on a network, the way a street address identifies a building. When you send data to an IP address, the network knows which machine to deliver it to. Every phone, laptop, server, printer, and smart doorbell that talks on a network has one, even if you never see it.

The term IP stands for Internet Protocol, and there are two versions of these addresses in use today.

• IPv4 addresses look like 216.198.79.1. They are four numbers separated by full stops, and each number sits between 0 and 255. There is a limited supply of them, roughly four billion, which sounds enormous until you remember how many devices the world now owns.
• IPv6 addresses are much longer and far more plentiful. They look like 2606:4700:4700::1111 and were created precisely because the world was running short of IPv4 addresses. There are so many IPv6 addresses that we are unlikely ever to run out.

There is also an important split between public addresses and private addresses. A public address is reachable from anywhere across the internet, like a building that faces a main road. A private address is used only inside a home or office network, like a room number that only makes sense once you are already inside the building. Private addresses live in special reserved ranges such as 10.x.x.x, 172.16.x.x to 172.31.x.x, and 192.168.x.x. You have almost certainly seen 192.168.0.1 or similar as the address of your home router.

Private addresses are the reason many devices in your home can happily share a single public address. Your router performs a trick called NAT, short for Network Address Translation, where it swaps the private address of the device sending traffic for its own public address on the way out, then reverses the swap for replies coming back. To the wider internet, the whole household looks like one address.

Port: which service

A single machine rarely does just one thing. A busy server might run a web server, an email server, and a database all at the same time, on the same IP address. So when data arrives, the machine needs to know which of those services the traffic is meant for. That is what a port is: a number that says which service on the machine you want to reach. If the IP address is the building, the port is the apartment number inside it.

216.198.79.1 : 443
   |             |
  which machine  which service (443 = HTTPS)

Ports run from 0 all the way to 65535, which gives plenty of room. A handful of them are well known by long standing convention, meaning that when you connect to that port, both sides already assume a particular service is listening there.

The combination of an address and a port, written as address:port, points at exactly one service on exactly one machine. This pairing is precise, and that precision is exactly what a firewall leans on when it decides what traffic to allow and what to block. A rule like "permit incoming traffic to port 443 but nothing else" only makes sense once you understand that a port names a service.

Protocol: the rules of the conversation

Knowing which building and which room still leaves one thing unsettled: what language will the two sides speak once they are connected? A protocol is an agreed set of rules for how two machines talk to each other. It covers who speaks first, how a message is formatted, how the other side confirms it arrived, and how the conversation ends. Without a shared protocol, two computers connected together are like two people on a phone call speaking different languages: the line is open, but nothing useful happens.

Two low level protocols underpin almost everything else, and they take opposite approaches.

• TCP, the Transmission Control Protocol, is connection oriented and reliable. Before any real data flows, it sets up a connection through a short back and forth called a handshake. It then checks that every piece of data arrives, puts pieces back in the right order, and re sends anything that goes missing. It is used wherever correctness matters more than raw speed, such as loading web pages, sending email, and transferring files. Think of it as a recorded delivery that will not stop until the parcel is confirmed received.
• UDP, the User Datagram Protocol, is connectionless and fast. It simply fires data off without setting up a connection first and without guaranteeing that anything arrives. It is used wherever speed matters more than perfection, such as video calls, live streaming, online games, and DNS lookups. If one frame of a video call is lost, you would rather the call kept moving than have it freeze while the missing frame is fetched. Think of it as shouting across a room: quick, but with no receipt.

Sitting on top of TCP and UDP are the application protocols you actually deal with by name, such as HTTP and HTTPS for the web, SSH for remote access, and DNS for name lookups. These are the rules for what the conversation means once TCP or UDP has handled the job of moving the bytes across. A neat way to picture it: TCP and UDP are the postal service that moves the envelope, and the application protocol is the letter written inside.

How the three ideas fit together

Put all three ideas into a single sentence and almost any network request suddenly makes sense:

Connect to an IP ADDRESS, on a specific PORT,
speaking the right PROTOCOL.

Loading a web page, for example, is nothing more than this: connect to the server's IP address, on port 443, speaking HTTPS. That one line describes the vast majority of connections your devices make every day. Sending an email, logging into a remote server, streaming a film, all of them follow the same shape of address plus port plus protocol.

Here is the same idea walked through step by step for a single request to a website:

1. Find the address:  DNS turns holyghost.sh into 216.198.79.1
2. Pick the room:     use port 443, because we want secure web traffic
3. Open the line:     TCP sets up a reliable connection to that address and port
4. Agree the language: HTTPS rules govern the request and the reply
5. Talk:              the browser asks for a page, the server sends it back

Notice how each idea does a distinct job and none of them can do the others' work. The address alone cannot pick a service. The port alone means nothing without a machine to find it on. And even with both, the two sides need a shared protocol to understand each other.

The takeaway

An IP address says which machine, a port says which service on that machine, and a protocol says how the two sides talk, with TCP for reliable conversations and UDP for fast ones. Nearly every network interaction, from checking email to loading this page, is just address plus port plus protocol working together. This is the foundation everything else in security sits on, from how the web works to DNS to the firewalls that police it all. Hold on to the postal analogy, keep the well known ports in the back of your mind, and the rest of the field will feel a great deal less intimidating.