Domain

Networking

How bytes get from one machine to another — the protocols, the physical hardware that actually carries them (routers, switches, modems, Wi-Fi), and the infrastructure built around both (firewalls, VPNs, proxies). None of it works alone: Ethernet can't reach past your local network, IP can't tell one program on a machine from another, and a router is a different device doing a different job from a switch or a modem, no matter how often one box in the corner does all three. Each topic is written standalone, but they were designed to be read in the order below the first time through.

How the pieces fit together

Every protocol here sits at one of four layers, each one solving exactly the problem the layer below it can't. Application protocols never talk to Ethernet directly — they hand data down, one layer at a time, and each layer only ever talks to the one immediately above or below it. If you've also heard of a 7-layer model (OSI) and aren't sure how it relates to the 4 layers here, or you've ever wondered why "TCP/IP" doesn't leave UDP out in the cold, OSI vs. TCP/IP Model answers both directly — read it first if either of those has ever tripped you up.

• Ethernet (or Wi-Fi, the same job over radio) gets a frame to the next device over — nothing further. It has no idea what "the internet" is. A switch and a modem are the physical hardware doing this layer's job.
• IP solves what Ethernet can't: addressing and routing across many networks, hop by hop, with no delivery guarantee of its own — resolved from a name in the first place by DNS, one layer up. A router is the hardware making this layer's decisions; BGP is how routers agree on those decisions at internet scale; ICMP is how the network layer itself reports problems back, rather than carrying any application's data.
• TCP and UDP solve what IP can't: telling one program on a machine from another (via ports), and — for TCP only — turning IP's best-effort delivery into a reliable, ordered stream. QUIC is a third, newer option here too — reliable like TCP, but built on top of UDP instead.
• Everything above that is an application protocol — a message format and set of rules built on top of a transport for one specific job. This domain now covers eleven of them; see the full grouped list below.
• Firewalls, VPNs, and proxies don't add a new layer — they sit alongside this whole stack, shaping or securing traffic that still has to pass through every layer above like anything else.
• All of this assumes some shape to how devices are physically or logically arranged in the first place — see Network Topologies & Scope (PAN/LAN/WAN, star/bus/mesh) — and some shape to who talks to whom once connected — see Client-Server vs. P2P. Neither is a layer either; both are lenses the whole stack above gets built under.

Where to start

If you're new to this domain, read in this order — each topic assumes you already understand the one before it, and explicitly says so where it matters.

1. OSI vs. TCP/IP Model — read this zeroth, even before Ethernet. It sets up the vocabulary ("Layer 3," "Layer 7") and the layering mental model every other topic here assumes. Network Topologies & Scope and Client-Server vs. P2P are worth reading right alongside it — neither is a layer, but both shape how you picture every diagram from here on.
2. Ethernet, then Wi-Fi — every topic above this one exists to solve a problem Ethernet by itself can't; Wi-Fi is the same job again over radio. The hardware doing this job — Switch, Modem — is worth reading right after, since the modem-vs-router mix-up is one of the most common everyday confusions in networking.
3. IP, then DNS — once you've seen Ethernet's "local only" limit, IP's whole reason for existing makes sense; DNS is the step before IP that turns a name into the address IP actually needs. Router & NAT is the hardware making IP's decisions in the real world; BGP is how that works at internet scale; ICMP is worth reading right after — it's how ping and traceroute actually work, and it travels alongside IP rather than on top of it.
4. TCP, then UDP — read TCP first; UDP's own page explains itself largely by contrast with TCP's guarantees. QUIC is worth reading right after both, since it only makes sense as a reaction to specific costs in each.
5. Pick an application protocol by what you're actually building:
   • Web traffic, general request/response → HTTP, then HTTPS & TLS
   • A persistent connection the server can push to → WebSocket
   • Automatic network configuration for a new device → DHCP
   • Remote shell access or administration → SSH
   • Legacy file transfer → FTP
   • Outbound notification/alert email → SMTP
   • IoT devices publishing to a broker → MQTT
   • Constrained/battery-powered devices, REST-style → CoAP
   • Enterprise messaging with routing rules → AMQP
6. Pick from security & traffic infrastructure by what you're securing or shaping — none of these add a new layer, they all sit alongside the stack above:
   • A deliberate, rule-based security boundary → Firewall & DMZ
   • Making a remote device behave like it's on a private network → VPN
   • Caching, filtering, anonymity, or load distribution → Proxy
7. Then, as reference rather than reading order: Bandwidth, Latency & Jitter (the vocabulary for describing how well any of the above is performing), IoT Architecture (how these pieces combine in a real device-to-cloud system), Serialization (how the bytes inside any of these payloads are actually structured), Linux Networking Tools (how to observe all of the above on a real running system), and Project-Based Example (all of the above, traced through one real device).

Topics

Foundations

• OSI vs. TCP/IP Model — 7 layers vs. 4, and what "TCP/IP" actually meanswritten
• Network Topologies & Scope — PAN/LAN/WAN, star/bus/meshwritten
• Client-Server vs. P2P — who talks to whom, once connectedwritten
• Bandwidth, Latency & Jitter — why "fast" and "responsive" aren't the same thingwritten

Link layer

• Ethernet — MAC addresses, framing, switching, ARP, cablingwritten
• Wi-Fi — the same job as Ethernet, over radiowritten
• Switch — hub vs. switch, MAC address learningwritten
• Modem — modulation, and why it isn't a routerwritten

Network layer

• IP — Internet Protocol (addressing & routing, IPv4 vs. IPv6)written
• ICMP — how ping and traceroute actually workwritten
• BGP — routing between Autonomous Systems at internet scalewritten
• Router & NAT — routing vs. switching, the default gateway, NATwritten

Transport layer

• TCP — reliable, connection-oriented transportwritten
• UDP — connectionless transportwritten
• QUIC — reliable transport rebuilt on top of UDPwritten

Application & messaging layer

• HTTP — methods, status codes, headers, statelessnesswritten
• HTTPS & TLS — encrypting and authenticating a connectionwritten
• WebSocket — persistent, full-duplex connections over HTTP's handshakewritten
• DHCP — automatic IP address assignmentwritten
• DNS — turning a name into an IP addresswritten
• SSH — encrypted remote shell access and tunnelingwritten
• FTP — legacy two-channel file transferwritten
• SMTP — relaying outbound emailwritten
• MQTT — publish/subscribe messaging over TCPwritten
• CoAP — REST over UDP for constrained deviceswritten
• AMQP — exchanges, queues, and bindingswritten

Security & traffic infrastructure

• Firewall & DMZ — packet filtering, stateful inspection, DMZ zoneswritten
• VPN — encrypted tunnels, site-to-site vs. remote-accesswritten
• Proxy — forward vs. reverse, caching, load distributionwritten

Reference & tooling

• IoT Architecture — device, gateway, cloud, and application layerswritten
• Serialization — Protobuf & Base64written
• Linux Networking Tools — ip, arp, ping, ss/netstat, ethtoolwritten
• Project-Based Example — a real IoT gateway device, traced protocol by protocolwritten

Nothing left in "Planned" — this domain now covers every layer, the physical hardware carrying it, and the infrastructure built around it. New topics get classified straight into the grouping above as they're written, per GUIDE.md.