Common Network Protocols (HTTP, FTP, DNS, etc.)

Imagine two strangers, neither speaking a word of the other's language, trying to complete a business deal through gestures alone. It can be done, badly, with enough patience and luck. Now imagine instead that both of them have quietly agreed, in advance, on exactly what each gesture means, in exactly what order, and what to do if one of them doesn't understand. That agreement is the entire difference between chaos and commerce — and it's exactly the difference between two computers exchanging meaningless noise and two computers having a conversation. A network protocol is nothing more mystical than that agreement, written down with unusual precision: what the bytes look like on the wire, what each message actually means, and what order things have to happen in, including what to do when something doesn't show up on time. Skip any one of those three ingredients — syntax, meaning, timing — and you don't have communication, you have two machines shouting past each other.

Almost every protocol in this chapter started life as an RFC, a "Request for Comments," a public, versioned, endlessly argued-over specification maintained mostly by the IETF. That habit of publishing the rules openly, rather than keeping them as a vendor's private trade secret, is arguably the single most important cultural decision in the internet's entire history — it's why a Go program you write today can speak HTTP to a server running an operating system that doesn't exist yet, written by someone who hasn't been born yet, simply because both sides will implement the same publicly documented rules rather than someone's private convention. It's also why protocols change so slowly and so carefully: HTTP/1.1 is still everywhere, nearly thirty years after HTTP/1.0, because breaking the agreement breaks the internet for everyone depending on it, not just the one team that wanted a cleaner design.

The All-Stars of Networking

HTTP and HTTPS

Picture a waiter taking your order and returning with exactly what you asked for — that's HTTP in a sentence. A client sends a request line (GET /path HTTP/1.1) plus headers and, optionally, a body; the server replies with a status line (HTTP/1.1 200 OK), its own headers, and a body. Methods like GET, POST, PUT, and DELETE describe intent, while status codes like 200, 404, and 500 describe the outcome. The version matters more than most people realize: HTTP/1.1 handles one request at a time per connection (or pipelines awkwardly); HTTP/2 multiplexes many requests over a single connection using binary framing; HTTP/3 goes further still, abandoning TCP altogether in favor of QUIC over UDP, precisely to dodge the head-of-line blocking problem covered in the previous chapter. HTTPS is simply HTTP wrapped in TLS — identical requests and responses, carried inside an encrypted, authenticated tunnel, the mechanics of which are the subject of the next chapter.

[Browser] <---HTTP/HTTPS---> [Web Server]

FTP

FTP is the moving truck of the internet — built specifically to haul large boxes (files) between houses (computers), rather than to carry the light conversational traffic HTTP is good at. It's unusual among these protocols in using two separate TCP connections at once: a control connection on port 21 for commands like USER, PASS, RETR, and STOR, and a completely separate data connection for the actual file bytes. In the original active mode, the server connects back out to the client to deliver data, which routinely gets blocked by NAT and firewalls, since an inbound connection initiated by the server looks exactly like an unsolicited intrusion attempt. Passive mode, where the client opens both connections itself, sidesteps that problem and became the default almost everywhere. FTP is also older than you'd guess: it was standardized in 1971 — the same year as the earliest email systems, not one before the other. Because plain FTP sends both credentials and file contents completely unencrypted, SFTP (file transfer riding over SSH) and FTPS (FTP wrapped in TLS) have replaced it almost anywhere credentials actually matter.

[Client] <---FTP (control + data)---> [Server]

DNS

If HTTP is the waiter, DNS is the phone book nobody remembers agreeing to use, yet everybody relies on constantly — translating a name like www.example.com into a number a machine can actually route to. It was designed in 1983 by Paul Mockapetris, replacing a scheme that sounds almost absurd in hindsight: before DNS, every single machine on the early internet kept its own manually updated copy of one shared file, HOSTS.TXT, and someone had to email out a new version whenever an address changed. Mockapetris's insight was to make the whole thing a distributed hierarchy instead of a giant flat list: your resolver asks a root server "who handles .com?", then asks that TLD server "who handles example.com?", then finally asks that domain's authoritative server for the actual address record. In practice, most of that walk is skipped entirely, because your ISP or a public resolver like 8.8.8.8 or 1.1.1.1 caches answers for as long as the record's TTL (time-to-live) allows, making repeat lookups nearly instant. Common record types include A (an IPv4 address), AAAA (an IPv6 address), CNAME (an alias to another name), MX (a mail server), and TXT (arbitrary text, often used to prove domain ownership).

[You] ---(www.example.com)---> [DNS Resolver] ---(93.184.216.34)---> [Website]

SMTP, POP3, and IMAP

Email protocols split the same job three different postal services used to divide among themselves. SMTP (port 25 between servers, 587 for a client submitting new mail) only ever sends — it never fetches anything. POP3 (port 110) downloads messages down to one device and typically deletes them from the server afterward, which was perfectly reasonable in the 1990s when "one device" was all anyone had, and increasingly awkward now that people check the same mailbox from a phone, a laptop, and a tablet. IMAP (port 143) instead keeps mail on the server and synchronizes state — read or unread, which folder a message lives in — across every device at once, which is exactly why almost every modern mail app defaults to it. The @ symbol that separates a username from a host in every email address was chosen deliberately by Ray Tomlinson in 1971, specifically because it almost never appeared inside an actual person's name, making user@host unambiguous on sight.

[Sender] --SMTP--> [Mail Server] --IMAP/POP3--> [Recipient]

DHCP

DHCP is the hotel receptionist of a network, handing a fresh room number to every guest the moment they check in, without anyone at the front desk having to think about it. It runs a compact four-step exchange, memorably nicknamed DORA: a device broadcasts a Discover ("is anyone a DHCP server out there?"), a server answers with an Offer of a candidate address, the device broadcasts a Request confirming it wants that specific offer, and the server closes the loop with an Acknowledgment, handing over the address along with a subnet mask, a default gateway, and DNS servers to use. Without this quiet four-step handshake, every phone, laptop, and smart speaker joining a coffee shop's Wi-Fi would need a human to manually type in a unique address — DHCP is the entire, invisible reason "just connect to the Wi-Fi" is allowed to be that simple.

SSH

SSH is a secret, authenticated tunnel straight into another machine, and its origin story is a genuinely good one: it was created in 1995 by Tapio Ylönen, a researcher at the Helsinki University of Technology, directly in response to a password-sniffing attack that had hit his university's own network. Telnet, the tool everyone used for remote logins at the time, sent every keystroke — including passwords — as plain, readable text, and once one attacker started harvesting them, the entire academic network was exposed at once. Ylönen's response was to build a protocol (port 22) that negotiates an encrypted channel first, authenticates the user — usually with a public/private key pair rather than a password — and only then hands over a remote shell, a file-transfer channel (SFTP or SCP), or even an arbitrary tunneled connection through port forwarding. SSH spread from that one university network to nearly the entire industry within a few years, which is a fairly rare thing for a piece of software written to solve one specific, local emergency.

The Supporting Cast

A handful of quieter protocols keep the rest of the internet honest. Telnet (port 23), dating all the way back to 1969, almost as old as the ARPANET itself, is the plaintext remote-login protocol SSH was built to replace, and today it survives mostly for talking to unencrypted device consoles, never for anything sensitive. SNMP (ports 161/162) lets network equipment report its health and statistics back to a monitoring system, and lets that system push configuration changes in return. NTP (port 123) keeps clocks synchronized across the internet, which sounds mundane until you remember that TLS certificate validation, log correlation across servers, and any distributed system that needs to reason about "before" and "after" all quietly depend on it. LDAP (port 389, or 636 as LDAPS) is a directory-lookup protocol, effectively a company phone book for usernames, groups, and permissions.

Protocol Cheat Sheet

Protocols in Action: A Web Page Load

Watch what actually happens, in order, the instant you press enter on a web address, and the whole chapter collapses into one concrete sequence. First, DNS: your browser asks a resolver for the site's address, often already sitting in cache from an earlier lookup. Then a TCP handshake: your operating system opens a connection to that address on port 443. Then a TLS handshake: certificates are exchanged and verified, and a shared encryption key gets negotiated, a process the next chapter covers in real depth. Only then does HTTP actually happen: your browser sends its GET request over the now-encrypted connection and receives the page back. And it rarely stops there — the HTML that comes back typically references images, scripts, and fonts hosted elsewhere, triggering another round of DNS lookups and HTTP requests, often reusing connections wherever the browser can.

A protocol is not the wire format alone — it's the agreed sequence of who speaks when, and what silence or a wrong answer is supposed to mean.

Frequently Asked Questions

If HTTPS is just HTTP wrapped in TLS, why does it need a completely different default port, 443 instead of 80? Nothing about the HTTP request or response itself changes — the port difference exists purely so a server can tell, before a single byte of HTTP is even exchanged, whether it should expect a TLS handshake first or plain text right away. In the earliest days of the web, a server listening on one port had no reliable way to guess which flavor was coming down the wire, so the simplest fix was to give encrypted traffic its own front door entirely, and that convention has simply never needed to change since.

Why does FTP need two separate connections when HTTP manages everything over just one? FTP was designed in 1971, decades before anyone had settled on the request-response pattern HTTP would later popularize, and its authors split the job the way a shipping company might: one line for talking business (usernames, passwords, which file you want) and a separate line for the actual freight. That separation is also exactly why FTP fights so badly with modern NAT and firewalls, since the data connection in active mode requires the server to reach back out to the client, something firewalls are built to block by default.

Is it a problem that DNS mostly runs over UDP, a protocol with no guaranteed delivery? Not in practice, because a typical DNS query and its answer are so small that they fit in a single packet, and if that packet gets lost, the resolver simply asks again a moment later — a cost far lower than the overhead of opening and tearing down a full TCP connection for every single lookup. DNS only reaches for TCP when a reply grows too large for one UDP datagram, such as a DNSSEC-signed response or a full zone transfer between servers, which is a good example of a protocol choosing its transport deliberately rather than being stuck with one.

Why do so many people still confuse POP3 and IMAP, and does it actually matter which one you use? It matters more than the "just email" framing suggests: POP3 was built for an era when a person owned exactly one computer, so it happily deletes messages off the server once they're downloaded, while IMAP was built for a world of multiple devices, keeping everything on the server and merely showing you a synchronized view of it. Someone who sets up POP3 today, expecting their phone and laptop to show the same inbox, will be genuinely confused when messages read on one device silently vanish from the other.

How is SSH different from just running Telnet with a password? The difference isn't the password at all — it's that Telnet transmits that password, and everything else, as plain readable text across the network, so anyone quietly listening on the wire captures it outright. SSH negotiates an encrypted channel first and typically authenticates with a public/private key pair rather than a password, which is precisely the fix Tapio Ylönen built in 1995 after watching a password-sniffing attack tear through his own university's network.

Carrying This Forward

None of these protocols were handed down from on high — each one is a group of people, often just a handful of them, solving one specific, often quite mundane problem: physicists losing track of documents, a university getting its passwords sniffed, a room full of mainframes with no shared address book. What makes them worth learning as a set, rather than memorizing in isolation, is noticing how often the same shape reappears: a request and a response, a fixed well-known port waiting patiently for anyone to knock, a fallback plan for when the fast path isn't good enough. Once you can see that shape, a protocol you've never encountered before stops being intimidating, because you already know what questions to ask it. Starting in the Go Fundamentals part of this book, you'll get to ask those questions directly — resolving a name, opening a connection, and reading a response with your own code instead of your own imagination.

Fun Facts and Memes

• If DNS ever fails, it's a little like forgetting everyone's phone number at once — no websites load for you, even though every server involved is running perfectly fine.
• FTP and email are the same age — both trace back to 1971 — which surprises almost everyone who assumes "sending a file" is the newer, more advanced idea.
• If protocols were people at a party: HTTP is the chatty waiter who never stops taking orders, DNS is the quiet phone book everyone secretly depends on, and SSH is the guest who only speaks in ciphers and trusts almost no one at the door.