In the last post I walked through the building blocks of networking — IP addresses, DNS, ports, subnets, routing, NAT. That post was about the nouns: the things that exist on a network. This one is about the verbs — the actual rulebooks that let two machines that have never met agree on how to talk to each other.
A protocol is a set of rules and message formats that both sides of a connection agree to follow — an internet standard, usually written down in an RFC (Request for Comments) document, that says exactly what a message looks like, what order things happen in, and what each side is supposed to do with what it receives. Your laptop and a server on the other side of the planet have never coordinated with each other directly, but because they both implement the same protocol correctly, they can hold a conversation anyway. That's the entire point.
ARP — Address Resolution Protocol (RFC 826)
ARP solves a very specific, very local problem: on a network segment, IP addresses aren't what devices actually use to deliver data — MAC addresses are. ARP is the mechanism that resolves "I know this device's IP address, what's its MAC address?"
It works with a simple request/response exchange: a device broadcasts an ARP request to the entire local network — "who has this IP address?" — and the device that owns it replies directly with its MAC address. Every device on the segment keeps a local ARP table (a cache of these IP-to-MAC mappings) so it doesn't have to re-ask for every packet.
The catch, and the reason ARP shows up constantly in security discussions: it has no authentication built in. Any device can claim to own any IP address, and everyone else will believe it. That's the basis of ARP spoofing — an attacker broadcasts fake ARP responses claiming to be, say, the default gateway, and other devices on the network start routing their traffic through the attacker without realizing anything's wrong. It's a good example of a protocol designed in an era that assumed trust on the local network — a assumption that doesn't hold up today.
FTP — File Transfer Protocol (Port 21)
FTP is exactly what it sounds like: a protocol purpose-built for transferring files between a client and a server. It predates the web by well over a decade and uses two separate connections — one for commands (like "list this directory" or "get this file") and a second, separate connection for the actual data transfer.
The major issue with plain FTP is that it sends everything, including credentials, in cleartext — which is why it's largely been replaced in practice by SFTP (FTP over SSH, unrelated to plain FTP despite the name) or FTPS (FTP with TLS layered on top) wherever security matters. Worth knowing FTP exists and how it thinks about the world, but don't reach for it unencrypted in anything you're building today.
SMTP — Simple Mail Transfer Protocol (Port 25 / 587)
SMTP is the protocol that handles sending email — the conversation between a mail client (or another mail server) and a mail server that says, in effect, "here's who this is from, here's who it's going to, here's the message, please deliver it."
It's worth knowing SMTP only covers the sending half of email. Retrieving mail from a server into a client is handled by separate protocols — IMAP (which syncs mail state across devices, the standard today) or the older POP3 (which downloads and typically removes mail from the server). If you've ever configured an email client and had to enter separate "incoming" and "outgoing" server settings, that's SMTP handling outgoing and IMAP/POP3 handling incoming.
HTTP — Hypertext Transfer Protocol (Port 80)
HTTP is the protocol underneath essentially every website and API you've ever used. It's a request/response protocol: a client sends a request (a method like GET, POST, PUT, or DELETE, plus a URL and some headers), and the server sends back a response (a status code like 200 OK or 404 Not Found, plus headers and, usually, a body of data).
HTTP itself is stateless and, by default, completely unencrypted — anything sent over plain HTTP can be read by anyone who can see the traffic in transit. That's the exact problem SSL and TLS were built to solve.
SSL / TLS — Building a Secure Tunnel
SSL (Secure Sockets Layer) and its modern successor TLS (Transport Layer Security) are protocols that let a client and a server establish an encrypted tunnel between themselves before any actual application data gets sent. SSL is effectively obsolete at this point — every version of it has known vulnerabilities — and what people casually still call "SSL" today is almost always TLS doing the actual work.
The process (a TLS handshake) involves the client and server agreeing on an encryption method, the server proving its identity with a certificate, and both sides generating a shared secret key — all before a single byte of your actual request goes anywhere. Once that tunnel exists, everything sent through it is encrypted and, as far as anyone intercepting the traffic is concerned, unreadable.
HTTPS — HTTP, Secured
HTTPS is simply HTTP run over a TLS-encrypted tunnel instead of a plain connection — same request/response model, same methods and status codes, but wrapped in the encryption TLS provides. It runs on port 443 by default, versus HTTP's port 80. This is the reason browsers show a padlock icon and warn you when a site is "not secure" — they're telling you whether the connection is riding inside that TLS tunnel or not. Practically every production service you build should be HTTPS-only; there's no good reason left to serve anything sensitive over plain HTTP.
DNS — Domain Name System (Port 53)
DNS converts the domain names people actually type into the IP addresses machines need to route traffic. It's structured as a distributed, hierarchical system rather than one giant lookup table — your query typically bounces from a resolver, to a root server, to a top-level-domain server (for .com, .org, and so on), down to the authoritative server for the specific domain, which finally returns the answer. In practice almost all of this is cached at every level, which is why most lookups resolve in milliseconds rather than making that full round trip every time.
The Four Things Every Host Needs to Get Online
Put all of the above together and there are exactly four pieces of information a device needs before it can participate on a network at all:
- IP Address — the host's own identity on the network.
- Subnet Mask — defines the size of the host's local network, i.e. which addresses count as "local" versus needing to go through a router.
- Default Gateway — the IP address of the router that connects the local network out to everything else, including the internet.
- DNS Server — the address to send DNS queries to, so domain names can actually be translated into IPs.
Miss any one of these and something breaks in a specific, recognizable way: no IP means you can't be addressed at all; wrong subnet mask means you misjudge what's "local"; no default gateway means you can talk to your own subnet but nothing beyond it; no DNS server means the internet technically works but nothing with a domain name does, which is one of the most confusing failure modes to debug the first time you hit it.
DHCP — Dynamic Host Configuration Protocol (Port 67/68)
Manually configuring those four values on every device would be miserable at any scale beyond a handful of machines, which is exactly what DHCP exists to automate. When a device joins a network, it broadcasts a DHCP request, and a DHCP server on that network responds with an IP address, subnet mask, default gateway, and DNS server — everything needed to get online, handed out automatically. This is why your laptop or phone just works the instant it joins a Wi-Fi network without you typing in a single network setting.
The exchange has a well-known rhythm worth knowing by name — DORA: Discover (client broadcasts, looking for a DHCP server), Offer (server responds with a proposed configuration), Request (client formally asks for that offer), Acknowledge (server confirms and the lease begins). Most home and office networks lease these addresses for a set period and renew automatically in the background.
Why This Actually Matters Day to Day
Once you can name what's happening at each stage — ARP resolving a MAC address, DHCP handing out an IP and gateway, DNS resolving a domain, TLS building the encrypted tunnel, HTTP carrying the actual request — debugging stops being guesswork. "The site won't load" stops being one mysterious failure and becomes a short list of specific things to check in order: is DNS resolving, is the TLS handshake completing, is the HTTP request actually reaching the server, is the response coming back on the right port. Every layer from the last post and every protocol in this one is a specific, checkable link in that same chain.
Top comments (0)