Network & Protocols
When a service is unreachable or slow, the worst move is to restart things at random. "The site is down" is not one failure — it is a dozen possible failures stacked from the physical link up through IP, routing, DNS, and the transport port to the application itself. The engineer who fixes it fast is the one who walks those layers in order, isolating each one, instead of guessing. That method is only as good as the protocol knowledge under it: you have to know that a failed ping does not prove a host is down, that a resolver can serve a stale record its authoritative server has already replaced, and that a SYN with no SYN-ACK means a very different thing from a SYN-ACK followed by RST.
The second half is HTTP and TLS on the wire. A 502 versus a 503 versus a 504 each names a different upstream fault; a certificate error is either a broken chain, a hostname mismatch, or an expiry; and a redirect loop behind a TLS-terminating proxy almost always traces back to the app trusting the wrong scheme. Read these correctly and the error message tells you whose fault it is before you touch anything.
Topic map
- Network troubleshooting — the bottom-up layered method (link → IP → routing → DNS → transport → app), what
ping/traceroute/dig/ss/tcpdumpreally tell you, and the connectivity decision tree. - HTTP & TLS — methods and idempotency, the
502/503/504trio, the headers that matter behind a proxy, the TLS handshake and certificate validation, SNI/HSTS/termination, and HTTP/1.1 → HTTP/2 → HTTP/3.
Common traps
| Mistake | Consequence |
|---|---|
| "Ping fails, so the host is down" | ICMP is often filtered while TCP ports stay open — you declare a healthy host dead |
| Trusting the resolver over the authoritative server | You chase routing or the app while a stale cached record is the real fault |
Treating CLOSE_WAIT and TIME_WAIT as the same | You miss that piled-up CLOSE_WAIT is your own app leaking sockets |
Reading 502, 503, 504 as one "backend error" | You fix the timeout when the backend crashed, or vice versa |
| Forgetting TLS terminated at the proxy | The app sees plain HTTP, "redirects to HTTPS", and loops forever |
| Validating a cert as "just expiry" | A wrong-hostname (SAN) or a missing intermediate fails validation too |
Interview relevance
This topic is where interviewers test whether you diagnose or guess. The strong signal is a method: "I'd go up the layers — link, IP, routing, DNS, port, then the app — and isolate where it breaks." From there they probe the traps: why a failed ping is not proof, what many CLOSE_WAIT sockets mean, and the exact difference between 502 and 504. On the protocol side they check that you can name what certificate validation actually verifies (chain to a trusted root, hostname/SAN, expiry) and why a service behind a TLS-terminating proxy must be told the original scheme via X-Forwarded-Proto.