Computer Networking Roadmap

Press Enter on a URL and see the whole ladder once; then the layer model, encapsulation, and local delivery — frames, MAC addresses, ARP / Neighbor Discovery, and what separates a switch from a router. Every later stage is one rung of this ladder in detail.

Before moving on: Name the layers a request passes through after pressing Enter, and explain how a frame finds the right cable on a local network when all you know is the IP address.

• What Happens When You Press EnterNot startedLearningPracticingMastered
• Follow a Web Request Through Every LayerNot startedLearningPracticingMastered
• The Layer Model: TCP/IP First, OSI as a MapNot startedLearningPracticingMastered
• Encapsulation: Data, Segment, Packet, FrameNot startedLearningPracticingMastered
• Packet Inspector: Read a Frame Field by FieldNot startedLearningPracticingMastered
• Ethernet: Delivery on One Local NetworkNot startedLearningPracticingMastered
• MAC Addresses: Identity for One HopNot startedLearningPracticingMastered
• ARP and Neighbor Discovery: From an IP to a Local MACNot startedLearningPracticingMastered
• Switches vs RoutersNot startedLearningPracticingMastered

Best-effort packet delivery across links that do not know each other: the IP header, IPv4 and IPv6 as two different protocols (not one with bigger addresses), and what a port actually identifies. Addressing has to come before subnetting, routing and every transport.

Before moving on: Read an IP header, explain how IPv4 and IPv6 differ as protocols and not just in address size, and say what a port identifies.

• IP: Best-Effort Delivery Between MachinesNot startedLearningPracticingMastered
• IPv4: 32 Bits, Networks and HostsNot startedLearningPracticingMastered
• IPv6: Not Just Bigger AddressesNot startedLearningPracticingMastered
• Ports: Addressing a Process, Not a MachineNot startedLearningPracticingMastered

CIDR, masks, and the question every host asks before every packet — "is this next door or via the gateway?" — then NAT, the translation table that let IPv4 outlive its address space.

Before moving on: Compute the network of an address from a CIDR mask, decide whether a destination is local or via the gateway, and trace a packet through a NAT translation table in both directions.

• Subnetting: Splitting an Address SpaceNot startedLearningPracticingMastered
• NAT: Many Private Hosts Behind One Public AddressNot startedLearningPracticingMastered

A router with three matching routes picks the longest prefix; the routing table on your own laptop; and how the internet is stitched from autonomous systems announcing prefixes with BGP. Longest-prefix match only makes sense once you can read a CIDR prefix.

Before moving on: Read the routing table on your own machine, pick the winning route by longest-prefix match, and explain how BGP stitches autonomous systems into one internet.

• Routing: From a Destination IP to a Next HopNot startedLearningPracticingMastered
• The Routing Table and Longest-Prefix MatchNot startedLearningPracticingMastered
• Internet Routing: Autonomous Systems and BGPNot startedLearningPracticingMastered

From engineer-atlas.dev to an address: the cache chain, recursive resolution through root, TLD and authoritative servers, record types and TTLs — and the failure simulator that explains "it works after five minutes". It sits here because the answer it produces is an IP address.

Before moving on: Trace a name from the browser cache through recursive, root, TLD and authoritative servers, read a record set with its TTLs, and explain why a change "works after five minutes".

• DNS: Why Names Need a Distributed DatabaseNot startedLearningPracticingMastered
• Following One Lookup Through Every CacheNot startedLearningPracticingMastered
• DNS Record Types and What They Are ForNot startedLearningPracticingMastered
• DNS Failure Modes: What Each One Looks LikeNot startedLearningPracticingMastered

A transport that will lose your data, and why DNS, real-time media and QUIC choose exactly that. The smallest transport comes first so TCP can be read as everything UDP leaves out.

Before moving on: Explain what UDP leaves out compared with TCP, and say why DNS, real-time media and QUIC want exactly that.

• UDP: Datagrams and the Contract You ChooseNot startedLearningPracticingMastered

Building a reliable ordered byte stream out of packets that can be lost, duplicated and reordered: the handshake, sequence numbers, loss recovery, rwnd and cwnd, head-of-line blocking and the state machine through TIME_WAIT. TLS, HTTP and sockets all sit on top of this stream.

Before moving on: Draw the three-way handshake and the close through TIME_WAIT, explain how sequence numbers and ACKs recover a lost packet, and tell flow control from congestion control.

• TCP: A Reliable Ordered Byte Stream over an Unreliable NetworkNot startedLearningPracticingMastered
• The Three-Way HandshakeNot startedLearningPracticingMastered
• Sequence Numbers, ACKs and ReassemblyNot startedLearningPracticingMastered
• Packet Loss: Duplicate ACKs, Fast Retransmit and the RTONot startedLearningPracticingMastered
• Flow Control: The Receive WindowNot startedLearningPracticingMastered
• Congestion Control: Protecting the NetworkNot startedLearningPracticingMastered
• Head-of-Line BlockingNot startedLearningPracticingMastered
• The Connection Lifecycle: Close, Reset, TIME_WAIT, CLOSE_WAITNot startedLearningPracticingMastered

TCP delivers bytes but not confidentiality or identity: the TLS 1.3 handshake, key agreement, and the certificate chain that lets a browser trust a server it has never met. A certificate names a DNS name, so DNS comes first.

Before moving on: Walk through a TLS 1.3 handshake, explain how a certificate chain lets a browser trust a server it has never met, and say what TLS does and does not protect.

• Why TLS ExistsNot startedLearningPracticingMastered
• The TLS HandshakeNot startedLearningPracticingMastered
• Certificates and the Chain of TrustNot startedLearningPracticingMastered

Requests, responses, headers and status codes; one request followed through its lifecycle; HTTP/1.1 and its one-request-at-a-time connection; keep-alive and connection pools, and the idle-timeout race they create. Each of those is a consequence of running over one TCP stream.

Before moving on: Write a raw HTTP/1.1 request and read the response, explain what keep-alive and a connection pool buy you, and spot the idle-timeout race.

• HTTP: Requests, Responses, Headers and Status CodesNot startedLearningPracticingMastered
• The Lifecycle of One HTTP RequestNot startedLearningPracticingMastered
• HTTP/1.1: Persistent Connections and Their LimitsNot startedLearningPracticingMastered
• Keep-Alive and Connection ReuseNot startedLearningPracticingMastered
• Connection PoolingNot startedLearningPracticingMastered

Why HTTP needed two transport redesigns — HTTP/2 multiplexing over one TCP stream, then HTTP/3 over QUIC — and the real-time options built on top: WebSockets, SSE and polling. It needs the head-of-line blocking from TCP, the UDP that QUIC runs on, and the TLS that QUIC folds in.

Before moving on: Explain what HTTP/2 multiplexing fixed and which head-of-line blocking it could not, why HTTP/3 moved to QUIC over UDP, and choose between polling, SSE and WebSockets for a given feature.

• HTTP/2: Streams on One ConnectionNot startedLearningPracticingMastered
• HTTP/3 and QUICNot startedLearningPracticingMastered
• HTTP/1.1 vs HTTP/2 vs HTTP/3Not startedLearningPracticingMastered
• WebSocketsNot startedLearningPracticingMastered
• Polling vs Long Polling vs SSE vs WebSocketsNot startedLearningPracticingMastered

What the kernel actually hands you when you call socket(), and how a network namespace gives every container its own descriptors, interfaces and port 80. This is where the transport stack becomes something a process can hold; a published container port is the NAT from the Subnetting stage, seen from inside the host.

Before moving on: Describe what socket() returns and the buffers behind it, and explain how a network namespace lets two containers on one host both bind port 80.

• The Socket: A Descriptor With Two Kernel Buffers Behind ItNot startedLearningPracticingMastered
• Network NamespacesNot startedLearningPracticingMastered
• Container NetworkingNot startedLearningPracticingMastered

What the client is really connected to: forward and reverse proxies, L4 vs L7 balancing and health checks, firewalls and VPN tunnels, and Kubernetes services and ingress as the same ideas with new names. L4 versus L7 is TCP versus HTTP, which is why both come first.

Before moving on: Say what a client is really connected to behind a reverse proxy, choose L4 or L7 balancing for a given service, and explain why a ping can fail while the service still works.

• Forward and Reverse ProxiesNot startedLearningPracticingMastered
• Load Balancers: L4 vs L7Not startedLearningPracticingMastered
• FirewallsNot startedLearningPracticingMastered
• VPNs and TunnelsNot startedLearningPracticingMastered
• Kubernetes Networking, Just EnoughNot startedLearningPracticingMastered

Geography as a performance layer: edge locations and caches, then the arithmetic that explains them — RTT, bandwidth versus latency, throughput, and where 800 ms goes while the server sits idle. The arithmetic is handshakes and round trips, so it needs DNS, TCP and HTTP.

Before moving on: Explain how a CDN uses DNS and edge caches to shorten the path, and account for where 800 ms goes in a request from RTT, handshakes and bandwidth while the server sits idle.

• CDNs: The Networking ViewNot startedLearningPracticingMastered
• Latency: Same Machine to Cross-ContinentNot startedLearningPracticingMastered
• Bandwidth vs LatencyNot startedLearningPracticingMastered
• Throughput: Requests, Packets and Bytes per SecondNot startedLearningPracticingMastered
• Where the Time Goes: The Request TimelineNot startedLearningPracticingMastered

"Why can’t I connect?" as a layered procedure, which tool answers which layer, DNS / TCP / TLS / HTTP diagnosis, the capstone, and the packet lab where you inject the failures yourself. Bisecting by layer only works once you know every layer.

Before moving on: Bisect "why can’t I connect?" layer by layer with ping, traceroute, dig, ss, curl and openssl, and say which layer each tool answers.

• Why Can’t I Connect?Not startedLearningPracticingMastered
• The Tools, and Which Layer Each One AnswersNot startedLearningPracticingMastered
• ping: What an Echo Actually ProvesNot startedLearningPracticingMastered
• traceroute: Discovering the Path Hop by HopNot startedLearningPracticingMastered
• DNS Debugging: Who Answered, and With What?Not startedLearningPracticingMastered
• TCP Debugging: Reading the Handshake on the WireNot startedLearningPracticingMastered
• TLS Debugging: Why the Certificate Is "Invalid"Not startedLearningPracticingMastered
• HTTP Debugging: 502, 503 and 504 Are Different FailuresNot startedLearningPracticingMastered
• Capstone: What Happens When You Visit https://example.comNot startedLearningPracticingMastered
• Follow One PacketNot startedLearningPracticingMastered
• Network Failure Lab: Predict, Inject, Observe, DiagnoseNot startedLearningPracticingMastered

Where the network meets the process: send() through the kernel to a recv() on another machine, the buffer chain and backpressure when the receiver is slow, and the combined capstone that budgets every millisecond. It is last because it joins the socket, the transport and the debugging method in one path.

Before moving on: Follow send() through the kernel and NIC to a recv() on another machine, explain what happens to the buffer chain when the receiver is slow, and budget every millisecond of a request.

• Follow send() Through the OS to recv()Not startedLearningPracticingMastered
• The Buffer ChainNot startedLearningPracticingMastered
• What Happens When the Receiver Is SlowNot startedLearningPracticingMastered
• Capstone: Three Seconds from WarsawNot startedLearningPracticingMastered