Networking, from
a packet to a page.

Networking is built in layers, each solving one problem and handing off to the next. You don't need the full seven-layer OSI model; the practical stack is four layers, and every request climbs it.

Why layer at all? Separation of concerns: each layer trusts the one below and offers a clean service to the one above, so HTTP doesn't care whether it's on fiber or Wi-Fi, and IP doesn't care whether it's carrying TCP or UDP. This lets each evolve independently — which is exactly how HTTP/3 could swap TCP for a new transport without changing the app layer.

The Internet Protocol gives every device an IP address and breaks data into packets, each stamped with source and destination addresses. Packets travel hop by hop: routers read the destination and forward each packet toward it, with no guarantee of order, timing, or even delivery — IP is deliberately simple and "best-effort." Reliability, if you want it, is added above by TCP.

Two practical notes interviewers like: addresses are scarce (IPv4) so private networks use NAT to share one public address among many devices — which is why most machines have no public IP and can't be directly reached (relevant to DNS, WebRTC, and firewalls). And there's no central map; routing emerges from routers exchanging reachability info (BGP at internet scale). IP's job is just "get this packet closer to its destination."

Both run on IP; they differ in what they promise. TCP is a connection-oriented, reliable, ordered byte stream: it sets up a connection, numbers bytes, acknowledges receipt, retransmits losses, and delivers data in order. UDP is connectionless and unreliable: fire-and-forget datagrams with no ordering, no retransmission, no setup — just fast.

The rule: use TCP when every byte must arrive correctly and in order; use UDP when a late packet is worse than a lost one (real-time media would rather skip a dropped frame than wait for a retransmit). This exact tradeoff is why video calls use UDP and file downloads use TCP.

TCP's reliability starts with the three-way handshake: client sends SYN, server replies SYN-ACK, client sends ACK — synchronizing sequence numbers and confirming both directions work. The cost: a full round trip before any data, on top of which TLS adds more (section 07). This is why reusing connections and reducing round trips is a recurring performance theme.

TCP's in-order guarantee has a dark side: head-of-line blocking. Because data must be delivered in order, a single lost packet stalls everything behind it until it's retransmitted — even data that already arrived waits. This is a real limitation you'll cite repeatedly: it's why HTTP/1.1 pipelining failed, part of why HTTP/2 still suffers at the TCP layer, and precisely what HTTP/3 was built to escape.

You type a name; computers need an IP. DNS is the internet's phone book, and it's distributed by design. Your machine asks a recursive resolver, which walks a hierarchy: a root server points to the .com TLD servers, which point to the domain's authoritative nameserver, which returns the IP. Three referrals, one answer.

That would be slow every time, so DNS leans hard on caching: every record carries a TTL, and resolvers cache answers for that long, so the vast majority of lookups never touch the hierarchy. The interview-worthy consequences: a DNS change isn't instant (it "propagates" only as old TTLs expire), and DNS doubles as a coarse load-balancer and failover mechanism (returning different IPs by region or health). For the full mechanism, see the Design DNS walkthrough.

On top of transport sits HTTP, the app protocol of the web — and its evolution is a story of killing head-of-line blocking. HTTP/1.1 sends one request at a time per connection (browsers open several connections to compensate); a slow response blocks the connection behind it. HTTP/2 adds multiplexing: many requests share one connection as independent streams, plus header compression — solving request-level blocking. But it still runs on TCP, so a lost packet still stalls all streams at the transport layer.

HTTP/3 takes the radical step of moving off TCP entirely, onto QUIC — a new transport built on UDP that implements reliability and streams itself, so a lost packet only blocks its own stream, not the others. QUIC also folds the connection and TLS handshakes together to cut setup round trips. Each version chips away at the same enemy: waiting.

HTTPS is HTTP over TLS, and TLS gives three guarantees. Encryption: a network eavesdropper can't read the traffic. Integrity: tampering is detected. Authentication: the server proves its identity via a certificate signed by a trusted authority, so you're really talking to the site you think you are (thwarting impersonation).

Mechanically, a TLS handshake follows the TCP handshake: the parties agree on cipher suites, the server presents its certificate, and they establish a shared session key using asymmetric crypto, after which fast symmetric encryption protects the data. The cost is extra round trips on top of TCP — which is why TLS session resumption, and QUIC folding TLS into the transport handshake, matter for latency. The takeaway for interviews: HTTPS = confidentiality + integrity + server identity, at the price of a handshake.

The most important networking intuition: bandwidth and latency are different, and for interactive requests latency usually wins. Bandwidth is how much data per second (the pipe's width); latency is how long each round trip takes, bounded by distance and the speed of light in fiber. A fatter pipe doesn't shorten the wire.

And crucially, many operations are sequential round trips: DNS lookup, TCP handshake, TLS handshake, then the actual request — several full round trips before your data even starts, each paying the distance cost. That's why a request to a server across the ocean feels slow no matter your bandwidth, and why the biggest wins are reducing round trips (keep-alive, HTTP/2/3, caching) and reducing distance (CDNs, edge, regional deployment). When someone asks "how do I make this faster?", the network answer is almost always: fewer round trips, closer servers.