Networking — the floor under everything

Start here: what a "network request" actually is

Before any jargon, hold one picture in your head. Every interaction on the internet is a request sent from a client (your browser, your phone app, one of your servers calling another) to a server, followed by a response coming back. That is the whole game: ask, then receive. Everything in this lesson is machinery in service of getting one request safely and correctly from A to B, and the answer back.

A few words you'll see constantly, defined once up front so nothing later is a mystery:

• An IP address (Internet Protocol address) is the numeric "house number" of a machine on the network — e.g. 93.184.216.34 for IPv4, or a longer hex form like 2606:2800:220:1:248:1893:25c8:1946 for IPv6. Every packet carries a source and destination IP so routers know where to forward it.
• A port is a number (0–65535) that says which program on that machine the request is for. The IP gets you to the building; the port gets you to the right office door. Web servers listen on port 80 (HTTP) or 443 (HTTPS) by convention; a database might listen on 5432.
• A packet is one small chunk of data with addressing info attached. Big messages are split into many packets, sent independently, and reassembled at the other end.
• A protocol is just a rulebook both sides agree to follow — what the bytes mean, in what order, and how to handle errors. TCP, UDP, HTTP, TLS, and DNS are all protocols.
• Latency is the delay for one round trip — how long until the first byte comes back, measured in milliseconds. Bandwidth (or throughput) is how much data you can move per second once the pipe is open. They're independent: a satellite link can have huge bandwidth but terrible latency. Most "the site feels slow" problems are latency, not bandwidth — which is why cutting round trips (DNS caching, TLS 1.3, keep-alive connections, CDNs) is where the wins are.

The layers, in one minute (OSI / TCP-IP model)

Networking is taught as a stack of layers, each one only responsible for a single job and handing clean output up to the next. The classic textbook model is OSI (Open Systems Interconnection), seven layers; the practical model engineers actually use is TCP/IP, four layers. You will not be quizzed on all seven names, but the idea — separation of concerns — is the point, and naming the right layer for a thing reads as competence.

client → SYN     → server
client ← SYN/ACK ← server
client → ACK     → server   then data flows

To make the trade-off concrete: TCP (Transmission Control Protocol) is "connection-oriented" — both sides agree to a connection first (the handshake), then TCP numbers every byte, waits for acknowledgements, and retransmits anything lost so data arrives complete and in order. That guarantee costs you at least one round trip before the first byte and some bookkeeping overhead. UDP (User Datagram Protocol) is "connectionless" — it just fires datagrams (self-contained packets) with no setup, no acknowledgements, and no reordering. You trade reliability for speed and simplicity. Choose TCP when correctness matters (web pages, APIs, databases, file transfer); choose UDP when freshness beats completeness (live video/voice, online games, DNS lookups). Modern QUIC (the basis of HTTP/3) cleverly builds reliability on top of UDP so it gets TCP-like guarantees without TCP's rigidity.

The 3-way handshake, defined step by step

The diagram above shows the shape; here is what each message means, because interviewers love to ask "why three, not two?" The handshake exists so both sides confirm they can send and receive, and so both agree on the starting sequence numbers TCP uses to order bytes.

• SYN (synchronize) — the client opens with "I want to talk, and here's my starting sequence number." Now the server knows the client can send.
• SYN/ACK — the server answers with its own SYN plus an ACK of the client's. This proves the server received the client (so the client→server path works) and announces the server's sequence number.
• ACK (acknowledge) — the client confirms it received the server's SYN. Now the server knows the server→client path works too. Both directions verified ⇒ the connection is established and data flows.

Two messages can't do it: after two, the server has confirmed the client can reach it, but the client has no confirmation the server's reply got through. The third ACK closes that loop. (Closing a connection is symmetric — a FIN/ACK exchange, often four messages — but the handshake is the part that gets asked.)

HTTP (HyperText Transfer Protocol) is the application-layer language the web speaks: a request goes up, a response comes back, both as plain text headers followed by an optional body. A few terms in that box deserve unpacking:

• An HTTP method (or "verb") states your intent. GET reads without side effects; POST creates or submits; PUT replaces a whole resource; PATCH tweaks part of it; DELETE removes it.
• Idempotent means "doing it twice has the same effect as doing it once." GET, PUT, and DELETE are idempotent (re-sending is safe); POST is not (re-sending may create a duplicate). This is why a browser warns before re-submitting a form — that's a repeated POST.
• A status code is the server's three-digit verdict. Memorize the families, not every number: 2xx = success (200 OK, 201 Created), 3xx = redirect (301 permanent, 302 temporary, 304 Not Modified = "use your cache"), 4xx = the client's fault (400 bad request, 401 unauthenticated, 403 forbidden, 404 not found, 429 too many requests), 5xx = the server's fault (500 internal error, 502 bad gateway, 503 unavailable).
• Headers are key/value metadata riding alongside the body: Content-Type says what format the body is, Authorization carries credentials, Cache-Control and ETag drive caching (an ETag is a fingerprint of the content so the server can answer "unchanged, 304" cheaply).

Versions matter for one reason: cutting round trips and head-of-line blocking. HTTP/1.1 sends one request at a time per connection (slow, so browsers open many). HTTP/2 multiplexes many requests over a single TCP connection at once. HTTP/3 runs over QUIC/UDP to dodge a subtle TCP penalty (see pitfalls below).

Plain English for that box: TLS (Transport Layer Security) is what turns HTTP into HTTPS — the "S" is "Secure." It does three jobs at once. First, confidentiality: traffic is encrypted so a snooper on the Wi-Fi sees only gibberish. Second, integrity: every message is tamper-checked, so nobody can quietly alter it in transit. Third, authentication: you're really talking to the site you think you are. That last one rests on certificates. A certificate is a signed document binding a domain name to a public key; it's signed by a Certificate Authority (CA), an organization your browser/OS already trusts out of the box. The chain of trust is: your browser trusts the CA → the CA signed this site's certificate → therefore the browser trusts the site. If the signature is missing, expired, or doesn't match the domain, you get the scary "Your connection is not private" warning. The shared symmetric key both sides derive (cheap to encrypt with) is used for the actual data; the certificate's key is only used during the handshake. That separation is what gives forward secrecy: each session uses a fresh ephemeral key, so stealing the server's long-term key later can't decrypt yesterday's captured traffic.

Spelled out: DNS (Domain Name System) is the internet's phone book — it translates a name humans can remember (example.com) into the IP address machines route to. It's hierarchical and read right-to-left. A recursive resolver (usually run by your ISP, or a public one like 1.1.1.1) does the legwork for you: it asks a root server "who handles .com?", then asks that TLD (top-level domain) server "who's authoritative for example.com?", then asks that authoritative server for the actual record. The answer comes back with a TTL (time to live) — how many seconds it may be cached — so the next lookup skips most of the walk. The records themselves come in types: A (name → IPv4), AAAA (name → IPv6), CNAME (an alias pointing one name at another), MX (where mail for the domain goes), TXT (free-form text, often for domain-ownership verification), and NS (which servers are authoritative — "delegation").

The full trip: typing a URL, step by step

This is the single most common networking interview question — "what happens when you type a URL and press enter?" The on-ramp above gave the shape; here is the same journey broken into named, defined steps you can recite. We'll trace https://example.com/page.

1. Parse the URL. The browser splits it into scheme (https ⇒ use TLS, default port 443), host (example.com), and path (/page).
2. DNS resolution. The browser needs example.com's IP. It checks its own cache, then the OS cache, then asks the recursive resolver, which (if nothing is cached) walks root → TLD → authoritative and returns an IP with a TTL. Result: a numeric address to connect to.
3. TCP connection. The browser opens a TCP connection to that IP on port 443 via the 3-way handshake (SYN → SYN/ACK → ACK). One round trip; now there's a reliable, ordered byte channel.
4. TLS handshake. Over that channel, client and server negotiate a cipher, the server presents its certificate, the browser verifies the CA chain and that the cert matches example.com, and both derive a shared key. After this the channel is encrypted. (TLS 1.3: one round trip.)
5. HTTP request. The browser sends GET /page HTTP/2 with headers (Host, User-Agent, Accept, any cookies). This is the actual "ask."
6. Server processing. The request may hit a load balancer first, get routed to one of many app servers, possibly served from a CDN edge cache, and the app may query a database before composing a response.
7. HTTP response. Back comes a status code (hopefully 200 OK), response headers, and the body (HTML). A 3xx would send the browser to a new URL; a 4xx/5xx would be an error page.
8. Render. The browser parses the HTML, discovers more resources (CSS, JS, images), and fires off more requests — often reusing the same connection — until the page is painted.

Two infrastructure pieces from step 6 are worth defining because they show up in every system-design round. A load balancer sits in front of a pool of servers and spreads incoming requests across them (round-robin, least-connections, or by hashing a key), so no single box is overwhelmed and a dead one can be dropped without users noticing. A CDN (Content Delivery Network) is a fleet of caching servers placed physically close to users around the world; it serves static assets (and increasingly dynamic ones) from the nearest "edge," which slashes latency because the bytes travel a short distance instead of crossing an ocean to your origin server.

Pitfalls & gotchas

Next up, see how these pieces assemble into real architectures in System design — load balancers, CDNs, and caching all reappear there as building blocks.