Networking — the life of a request through a stack you operate

01The journey: you type https://api.example.com/users/42 and hit Enter

Step 0 — Layers (30-second mental model)

  L7  Application   HTTP, gRPC, DNS, TLS handshake payloads   "what to say"
  L4  Transport     TCP, UDP — ports, reliability              "which app, delivered how"
  L3  Network       IP — addressing, routing between networks  "which machine"
  L2  Link          Ethernet/WiFi — same-network hop           "next hop"

Each layer wraps the one above (encapsulation): your JSON rides in an HTTP message, in TCP segments, in IP packets, in Ethernet frames.

Step 1 — DNS: name → IP

Nobody routes on names. The resolver chain:

 browser cache → OS cache → recursive resolver (ISP/1.1.1.1/CoreDNS)
                                   │ (on miss, walks the hierarchy)
                                   ▼
   root servers ─► .com TLD servers ─► example.com's authoritative NS
                                   │
                                   ▼            A / AAAA record + TTL
                              203.0.113.7

• Record types worth knowing: A (IPv4), AAAA (IPv6), CNAME (alias), NS, MX, TXT, SRV.
• TTL governs caching — why DNS changes "propagate" slowly and why low TTLs are the standard trick before a migration.
• DNS classically runs on UDP port 53 (single question, single answer — no connection needed), TCP for big responses/zone transfers, and increasingly DoH/DoT.

Step 2 — TCP three-way handshake

You have an IP. Now establish a reliable byte pipe to port 443:

 Client                          Server
   │ ── SYN  (seq=x) ─────────────► │   "let's talk, my starting seq is x"
   │ ◄─ SYN-ACK (seq=y, ack=x+1) ── │   "sure, mine is y, I heard you"
   │ ── ACK  (ack=y+1) ───────────► │   "I heard you too" → ESTABLISHED

• 1 round trip before any data. This is why connection reuse matters: keep-alive, DB connection pools, Kong's upstream keepalive pool — all exist to amortize handshakes.
• A connection = the 4-tuple (src IP, src port, dst IP, dst port). Server listens on one port; each accepted connection is a new socket/FD.
• Teardown: FIN/ACK each way; closer lingers in TIME_WAIT (why mass short-lived connections can exhaust ephemeral ports).
• SYN flood: attacker sends SYNs, never ACKs, fills the half-open backlog — mitigated by SYN cookies.

Step 3 — TLS handshake

On top of the TCP pipe, negotiate encryption (TLS 1.3, one round trip):

 ClientHello  ──► supported ciphers + client key share (+ SNI: hostname!)
 ServerHello ◄──  chosen cipher + server key share + certificate
      [both derive session keys via ECDHE — forward secrecy]
 Finished ⇄ Finished → encrypted application data

• Certificate proves identity: server's public key signed by a CA the client trusts (chain of trust). Client checks signature chain, hostname match, expiry.
• Asymmetric crypto is only for the handshake (key exchange/authentication); the session itself uses fast symmetric encryption (AES-GCM/ChaCha20) with the derived keys.
• SNI: the client names the host in ClientHello so one IP can serve many certs — this is how Kong/any ingress routes TLS for multiple domains.
• TLS termination: in your world, TLS usually ends at the ingress/gateway (Kong); inside the cluster traffic is plaintext or re-encrypted via mTLS (service mesh). Offloads crypto and centralizes cert management (cert-manager + Let's Encrypt).

Step 4 — HTTP request/response

 GET /users/42 HTTP/1.1
 Host: api.example.com
 Authorization: Bearer eyJ...
 Accept: application/json
                                   ◄── HTTP/1.1 200 OK
                                       Content-Type: application/json
                                       Cache-Control: max-age=60
                                       {"id": 42, "name": "..."}

Then in your infra: request hits the LB → Kong (authn plugin checks the JWT, rate-limit plugin counts it, route matches /users → upstream service) → kube-proxy/Service picks a pod → uvicorn → FastAPI handler → Postgres → response back down the chain, each layer adding headers (x-request-id, CORS...).

Step 5 — Rendering (one sentence for completeness)

Browser parses HTML, discovers CSS/JS/img URLs, repeats this whole dance per origin (with connection reuse), builds DOM+CSSOM, renders. For an API interview, DNS→TCP→TLS→HTTP is the meat.

02TCP vs UDP

connect() ── 3-way handshake ──► pipe
send("hel"); send("lo")
  arrives in order, retransmitted
  on loss, congestion-controlled —
  but it's ONE byte stream, not
  messages: recv() may return "he"
HTTP, Postgres, Kafka, Redis, gRPC

sendto(datagram, addr)   no setup
  each datagram independent;
  may drop, reorder, duplicate —
  and that's YOUR problem (or
  no problem at all)
DNS, QUIC/HTTP-3, video/games,
syslog, StatsD

Two TCP subtleties that make you sound experienced:

• It's a byte stream, not messages. One send() ≠ one recv(). Application protocols must frame messages themselves (HTTP's Content-Length/chunked, Kafka's length-prefixed binary protocol, Postgres's wire protocol). "Why did my socket read return half a message" = this.
• Congestion control: TCP probes for bandwidth (slow start: cwnd doubles per RTT, then AIMD; loss → back off). It's why throughput ramps up on long transfers and why a lossy link crushes TCP throughput.

03HTTP/1.1 vs HTTP/2 vs HTTP/3 — intuition level

 HTTP/1.1: one request AT A TIME per TCP connection
   conn1: [req A ▓▓▓▓][resp A ▓▓▓▓][req B ...]      → browsers open 6 conns/host
                                                      (head-of-line at HTTP level)

 HTTP/2: one TCP connection, many interleaved streams (binary frames)
   conn: [A1][B1][A2][C1][B2][A3] ...               → multiplexing + header
          BUT one lost TCP packet stalls ALL streams   compression (HPACK) + prio
          (head-of-line moved down to TCP)

 HTTP/3: streams over QUIC over UDP
   independent streams — a lost packet stalls only ITS stream.
   TLS 1.3 built in; 1-RTT (0-RTT resume) setup; connection ID survives
   IP changes (wifi→5G, connection migration).

• 1.1: text protocol, keep-alive reuses the connection but requests are serialized per connection; pipelining existed and failed. Still everywhere server-side (simple, debuggable — curl -v shows it raw).
• 2: binary framing → true multiplexing over one connection, header compression, server push (deprecated in practice). Solves HTTP-level HoL but inherits TCP-level HoL: one lost segment blocks every stream behind it.
• 3: rebuilds the transport as QUIC on UDP — per-stream reliability, so loss is isolated; crypto and transport handshakes merged (fewer RTTs); userspace evolution (no waiting for kernel TCP changes).

04REST semantics

REST = resources (nouns) identified by URLs, manipulated by a uniform verb set, stateless requests.

• Safe = no state change (cacheable, prefetchable). Idempotent = N identical calls ≡ 1 call — this is not academic: retries and at-least-once delivery are only sane against idempotent operations. It's why payment APIs use idempotency keys on POST, and the same reasoning as your Kafka consumers needing idempotent handlers.
• Stateless: every request carries what's needed (token, etc.); no server session affinity → any pod can serve any request → horizontal scaling and rolling deploys just work. This property is what makes K8s Services' random pod-picking correct.
• Good REST hygiene: nouns not verbs (POST /orders, not /createOrder), plural collections, status codes over {"error": ...}-with-200, versioning strategy, pagination on collections.

05Real-time: WebSockets vs SSE vs long polling

The problem: HTTP is request→response; servers can't spontaneously talk. Three workarounds:

 Long polling:  client ──req──►(server holds until data or timeout)──resp──► repeat
                ~compatible everywhere; latency + reconnect overhead; no infra needs

 SSE:           client ──GET──► server keeps response open, streams
                "data: ...\n\n" events forever. ONE WAY (server→client).
                Plain HTTP: proxies/LBs happy, auto-reconnect built in (EventSource).

 WebSocket:     HTTP GET + Upgrade: websocket → 101 Switching Protocols
                → same TCP conn becomes a FULL-DUPLEX message pipe (ws:// wss://)

Choosing:

• Server→client stream only (notifications, live feeds, LLM token streaming) → SSE.
• Bidirectional, low latency (chat, collab editing, games) → WebSocket.
• Lowest common denominator / firewall hell → long polling fallback.

06Load balancers: L4 vs L7

 L4 (transport):  routes on IP:port. Sees TCP/UDP, not HTTP.
   client ──TCP──► [LB: pick backend, forward/NAT packets] ──► backend
   Blazing fast, protocol-agnostic, cheap. Can't route by path/header,
   can't retry a request, one connection = one backend.

 L7 (application): TERMINATES the connection, parses HTTP, makes a new
   request upstream.
   client ══HTTP══► [LB: read path/headers/cookies] ══HTTP══► chosen backend
   Path/host routing, TLS termination, retries, header rewrites,
   per-request balancing, canary %, auth — at parsing + memory cost.

• Algorithms: round-robin, least-connections, weighted, consistent hashing (nice segue: same consistent hashing that Kafka-esque systems and caches use to minimize reshuffling).
• Health checks eject bad backends — the LB-level mirror of K8s readiness probes.

07API gateway — what Kong actually does for you

A gateway is an L7 reverse proxy + policy engine: one front door where cross-cutting concerns live so N services don't reimplement them.

            ┌──────────────────────── KONG ────────────────────────┐
 client ──► │ route match → [authn: JWT/key] → [rate limit] →      │ ──► upstream
            │ [transform headers] → [log/metrics/tracing] → proxy  │     service
            └──────────────────────────────────────────────────────┘

Speak concretely, since you run it:

• Routing: Routes → Services → Upstreams (with its own LB + health checks across targets).
• Auth at the edge: JWT validation / API keys / OAuth introspection before traffic ever reaches a pod — services can then trust identity headers.
• Rate limiting & quotas: per-consumer/route counters (local, or Redis-backed for cluster-accurate limits — a distributed-counter problem, ties to system design).
• Observability: uniform access logs, latency metrics, request-id injection for tracing across services.
• Transformations, CORS, request size limits, canary/traffic-split, plugin ecosystem (Kong = OpenResty = NGINX + Lua/plugins).
• Gateway (north-south, edge policy) vs service mesh (east-west, sidecar-per-pod mTLS/retries/telemetry) — complementary, not competitors.

08Common ports

(Ports < 1024 are privileged — need root/CAP_NET_BIND_SERVICE, why containers often listen on 8080 and let the LB own 443.)

09Status codes that matter

• 2xx — 200 OK · 201 Created (+ Location) · 202 Accepted (async job queued — your "enqueue to Kafka and return" pattern) · 204 No Content (DELETE).
• 3xx — 301 permanent / 302 temporary redirect · 304 Not Modified (conditional GET hit: ETag/If-None-Match — caching's handshake) · 307/308 (redirect preserving method).
• 4xx (client's fault) — 400 malformed · 401 unauthenticated (who are you) vs 403 unauthorized (I know you; no) · 404 · 405 wrong verb · 409 conflict (version/duplicate) · 422 validation failed (FastAPI's default for Pydantic errors) · 429 Too Many Requests (what Kong's rate limiter returns; include Retry-After).
• 5xx (server's fault) — 500 unhandled error · 502 Bad Gateway (proxy got garbage/refusal from upstream — Kong couldn't reach or parse your pod's reply) · 503 Service Unavailable (no healthy upstream / overload — what you see when all pods fail readiness) · 504 Gateway Timeout (upstream too slow — proxy timeout < app timeout misconfigs live here).

10Status-code quiz — what does the client see?

11Self-test — say these answers out loud