Part 17 — Self-check questions

1. Your request crosses 15 routers. Which addresses change, and which stay the same?

MAC addresses change at every hop (each link has a new L2 frame). The IP addresses stay the same end to end, except where NAT rewrites them (your home router rewrites the source IP and port). TTL decrements at every router. Everything from L4 up is untouched by routers, but it's terminated by any L7 proxy (the ALB), which starts a brand-new connection with new IPs and ports.

2. A user reports "connection refused" and another reports "connection timed out" for the same service. What does each tell you?

Refused: the packet reached the host and the kernel replied with RST because nothing is listening on that port (process down, wrong port, bound to 127.0.0.1 only). Timed out: the SYN got no answer at all. Something dropped it silently (security group, NACL, firewall, missing route, host down). Different causes, often different owners.

3. Why do small API responses work but large ones hang after enabling a VPN/overlay?

The MTU was reduced by the encapsulation overhead, but endpoints still send 1500-byte packets with DF set. The oversized packets are dropped, and the ICMP "fragmentation needed" message that would trigger Path MTU Discovery is blocked or never generated. Fix the inner MTU, clamp TCP MSS, or allow the ICMP.

4. Why does 0.5% packet loss hurt p99 latency so much more than p50?

Most requests see no loss (p50 unaffected), but a lost packet costs a retransmission timeout of at least 200 ms (Linux minimum RTO), and a lost SYN costs 1 s. Those rare, huge penalties concentrate in the tail. HTTP/2 makes it worse: one lost TCP packet stalls every multiplexed stream on that connection.

5. You're behind an ALB and see intermittent 502s with nothing in your app's logs. What's your first hypothesis?

A keep-alive / idle-timeout race: your server closes idle connections sooner than the load balancer does, so the LB occasionally sends a request on a socket the server is closing. Make the server's keep-alive timeout longer than the LB's idle timeout. Other candidates: pod crashes/OOM kills, or pods terminating during deploys without connection draining.

6. gRPC traffic all goes to one pod even though you have 10. Why, and what's the fix?

gRPC multiplexes all requests over a long-lived HTTP/2 connection. An L4 balancer (or a Kubernetes ClusterIP Service through kube-proxy) balances connections, not requests, so each client sticks to one pod. Use L7 per-request balancing (Envoy/service mesh, an HTTP/2-aware L7 LB) or client-side load balancing.

7. Why must a POST /orders carry an idempotency key when TCP already guarantees reliable delivery?

TCP guarantees delivery of bytes on a live connection. It can't tell the client whether the server processed a request if the connection died before the response arrived. Only the application knows whether the order exists. An idempotency key lets the client safely retry, and the server deduplicates. That's end-to-end reliability, which by its nature belongs at L7.

8. Where does TLS sit in the OSI model, and why is the better question "who terminates it"?

Its handshake acts like L5 (session setup and resumption), and its record protection acts like L6 (encryption). It runs on top of L4. In practice, the important facts are which component decrypts traffic (and can therefore read, route, and log it), where the certificates live, and who rotates them. Those answers drive security, compliance, and routing capabilities.

9. Your service rate-limits per client IP. A big customer complains that their whole office is blocked. What happened?

The whole office reaches you through one NAT IP (or a corporate proxy, or CGNAT), so all their users share one rate-limit bucket. Rate-limit on authenticated identity (API key, user ID, tenant) and use IP only as a coarse abuse signal.

10. A cold request takes 240 ms, a warm one 130 ms. Name three changes that reduce the cold cost without touching server code.

(1) preconnect / DNS prefetch so TCP and TLS happen before the click; (2) HTTP/3 (QUIC) to merge the transport and TLS handshakes, and TLS session resumption / 0-RTT for safe requests; (3) terminate TCP/TLS at a CDN edge close to the user, so the handshakes cost a short RTT and the edge reuses warm connections to the origin. Also: longer DNS TTLs where safe, and keeping connections alive longer.

Where to go next

The rest of the series, in order: this guide is step 2a. Next is Networking from Zero (TCP/IP) (L1–L4 in depth), then the security pair, Security from Zero and Security Engineering in Depth, and finally The HTTPS Request Lifecycle, whose Chapter 25 traces one request through every guide in Go. The machines at both ends are covered in step 1, Operating Systems, Linux, and Containers.
Hands-on: capture your own "Place order" click with Wireshark (SSLKEYLOGFILE enabled), and label every packet with its layer and the matching step in Part 10. Doing this once is worth more than reading any guide twice.
References: RFC 9293 (TCP), RFC 8446 (TLS 1.3), RFC 9000 (QUIC), RFC 9113 (HTTP/2), RFC 9114 (HTTP/3), RFC 1918 (private IPv4), RFC 6598 (CGNAT space).