6.1 What a Protocol Actually Is

A protocol is just a shared rule-book that lets two programs talk. Both sides agree on: how to start a conversation, what format messages take, what responses mean, how to end the conversation.

You follow protocols every day without thinking. When you ring someone, you don't just start shouting — you say "Hello?" and wait for them to say "Hello?" back. That opening handshake is a protocol. Network protocols are the same idea, just formalised into precise rules.

The internet has hundreds of protocols. You don't need to know all of them — just the eight or so that show up constantly in real networks and exam questions. We'll group them by what they do.

6.2 Web Protocols — HTTP & HTTPS

HTTP (HyperText Transfer Protocol) is the protocol your browser uses to talk to web servers. When you type a URL and hit enter, your browser builds an HTTP request: "GET /homepage". The server replies with HTML, CSS, images.

HTTPS (HTTP Secure) is HTTP running inside a TLS-encrypted tunnel. From the user's point of view it works identically to HTTP — the browser handles all the encryption invisibly. The difference is that an attacker sitting between you and the server sees only scrambled data instead of readable text.

6.3 DNS — The Internet's Phonebook

DNS (Domain Name System) translates human-friendly names like instagram.com into machine-friendly IP addresses like 157.240.7.174. Without DNS, you'd have to memorise IP addresses for every site you visit.

DNS is so critical that it's worth understanding in depth — it's heavily examined, and DNS failures are a recurring real-world incident.

How a DNS lookup actually works

Recursive vs iterative lookups

This distinction comes up in exams:

• Recursive query — you ask one server "get me the answer" and it does all the work, asking other servers on your behalf. Your browser makes a recursive query to your local resolver.
• Iterative query — each server answers only what it knows and points you to the next server. Your local resolver uses iterative queries when walking root → TLD → authoritative.

DNS caching — why DNS is usually instant

Doing the full recursive walk every time you visit a website would be painfully slow. Instead, DNS answers are cached at multiple levels:

• Your browser caches recent lookups (seconds to minutes)
• Your operating system caches (check with ipconfig /displaydns on Windows)
• Your home router often caches
• Your ISP's resolver caches aggressively

Each cache entry has a TTL (time-to-live) — how long it's allowed to be reused before checking again. TTLs range from seconds (for fast-changing records) to 24+ hours (for stable records).

The implication: when a website changes its IP (e.g., moving to a new server), the change isn't instantly visible to everyone. Old cached values keep being used until they expire. This is why DNS changes are usually scheduled days in advance.

DNS as a single point of failure

Because DNS is a prerequisite for almost everything else on the internet, DNS failures cascade. When DNS breaks, websites appear to be down even if the actual web servers are working fine — browsers can't resolve names to addresses.

DNS attacks to know

6.4 DHCP — Automatic IP Assignment

DHCP (Dynamic Host Configuration Protocol) is how your phone automatically gets an IP address when you join a Wi-Fi network. Without DHCP, you'd have to manually type in an IP, subnet mask, gateway, and DNS server every single time you connected to a new network.

The four-step handshake is sometimes called DORA:

1. Discover — new device broadcasts "is there a DHCP server here?"
2. Offer — DHCP server replies "I can give you 192.168.1.42"
3. Request — device says "yes please, I'll take it"
4. Acknowledge — server confirms and records the lease

The IP is leased for a set time (usually 24 hours on home networks, longer on offices). When the lease expires, the device renews it.

Rogue DHCP servers — a real attack

If an attacker plugs a rogue DHCP server into a network, it may respond to DORA requests faster than the real one. The attacker can then hand out IPs that route through their own machine as the "gateway" — enabling a MITM attack. Defence: DHCP snooping on managed switches (only trusted ports are allowed to answer DHCP).

6.5 Email Protocols — SMTP, IMAP, POP3

Email uses different protocols for sending versus receiving.

Email spoofing and the defences (SPF, DKIM, DMARC)

SMTP was designed in 1982 when the internet was a small, trust-based community. It has no built-in way to verify who actually sent a message. That's why email spoofing is trivial and why phishing works. Three protocols were bolted on later to help:

• SPF (Sender Policy Framework) — domain owners publish a DNS record listing which IPs are allowed to send mail from that domain. Receiving servers check it.
• DKIM (DomainKeys Identified Mail) — outgoing mail is cryptographically signed by the sending server. Receivers verify the signature matches.
• DMARC — tells receivers what to do when SPF/DKIM fail (e.g., "reject it" or "send to spam"). Also gives domain owners reporting on spoofing attempts.

6.6 File Transfer Protocols — FTP, SFTP, FTPS

6.7 SSH — Secure Remote Control

SSH (Secure Shell) lets you log into a computer over the network and control it as if you were sitting at the keyboard. Used by every system administrator on Earth for managing servers. Encrypted end-to-end.

• Runs on port 22
• Supports password auth or, better, key-based auth (public/private keypair) — you prove your identity by possessing the matching private key instead of typing a password
• Also tunnels other protocols (SFTP, port forwarding, VPN-like usage)

6.8 TCP vs UDP — The Transport Layer Choice

Every application protocol above sits on top of either TCP or UDP. The choice matters because they have very different guarantees.

6.9 Quick Reference — The Ports Table, Expanded

Expanding the table from Chapter 4 with every protocol covered in this chapter:

6.10 Quiz Time