Protocols
Each protocol solves one problem the others left open. They are laid out below in the order that makes them easiest to learn — which is roughly the order a packet meets them on its way out of your machine. Every module teaches the idea first, then shows it happening in real packets you can pause and take apart.
Before any of them — Networking FoundationsLayers and encapsulation, MAC and IP addresses, prefixes and masks, gateways and routing tables, ports, byte order, checksums, state and reliability. Everything on this page assumes those; that page teaches them.
Start here
Addressing, and the two questions every packet answers before it goes anywhere: who am I sending to, and are they on my wire?
What IP needs around it
IP promises nothing. These three are how problems get reported, how a program gets addressed, and how reliability gets added on top.
Internet Control Message Protocol
IP's way of reporting problems and testing whether a host is reachable.
needs first: IPv4
User Datagram Protocol
Ports and a checksum. Nothing else, on purpose.
needs first: IPv4
Transmission Control Protocol
Turns unreliable packets into a reliable, ordered byte stream.
needs first: IPv4
Services that make the internet usable
Nothing above works until a machine has an address and can turn a name into one. Both run before anything a user notices.
The web stack
Three layers that arrive together in every browser tab: the messages, the encryption around them, and the whole arrangement at once.
Hypertext Transfer Protocol
Requests and responses carried over a TCP byte stream.
needs first: TCP
Transport Layer Security
Adds confidentiality, integrity and identity to a TCP connection.
needs first: TCP
HTTP over TLS
Not a separate protocol — HTTP inside TLS inside TCP inside IP inside Ethernet.
needs first: HTTP · TLS · DNS
How routers learn where things are
Everything so far assumed a route existed. These two are how routes come to exist — inside one organisation, and between them.
A different relationship: what is inside what
The order above is about learning. This is about encapsulation — which protocol's bytes physically sit inside which other protocol's. They are not the same thing, and conflating them causes real confusion later. Two worth noticing: OSPF has no transport layer at all, riding directly on IP and implementing its own reliability; and an HTTP message is not a packet — it is a run of bytes in a TCP stream that may span many.
Ethernet frame
├── ARP message (EtherType 0x0806)
└── IPv4 packet (EtherType 0x0800)
├── ICMP message (protocol 1)
├── TCP segment (protocol 6)
│ ├── HTTP message (port 80 — spans segments)
│ ├── TLS records (port 443)
│ │ └── Encrypted HTTP (HTTPS)
│ └── BGP messages (port 179)
├── UDP datagram (protocol 17)
│ ├── DNS message (port 53)
│ └── DHCP message (ports 67/68)
└── OSPF packet (protocol 89 — no transport layer)Once you have met a few of them
Journeys — the whole chain in one captureOpening a website end to end: DHCP, ARP, DNS, TCP and HTTP in one trace; a routed enterprise application where OSPF and BGP fill the table first; and ten broken versions where exactly one layer is at fault and you have to prove which.
Capstone — the questions that need two protocols at onceEight questions belonging to no module: follow one request across everything it touches, name the failing layer from the evidence, and say why the plausible answer is wrong.