Part 2: IP Addressing and Routing (9-16)
9. What does 10.0.1.0/24 mean?
CIDR notation: the first 24 bits are the network prefix, the remaining 8 bits identify hosts. A /24 has 256 addresses, 10.0.1.0 to 10.0.1.255. Convert prefix length to a mask by writing that many 1-bits: /24 is 255.255.255.0, /26 is 255.255.255.192.
10. How many usable hosts are in a /26? How do you split a /24 into /26s?
A /26 leaves 6 host bits: 2^6 = 64 addresses, minus the network address and the broadcast address = 62 usable in classic IPv4 networking. (Cloud providers reserve more: AWS keeps five addresses per subnet.)
A /24 splits into four /26s because you borrow 2 bits (2^2 = 4): .0/26, .64/26, .128/26, .192/26. Do this math without a calculator; it comes up in every infrastructure loop.
11. What are the RFC 1918 private ranges?
10.0.0.0/8172.16.0.0/12 (172.16.0.0 to 172.31.255.255)192.168.0.0/16
They are not routed on the public internet, so they need NAT to reach it. The follow-up is overlap: two networks that both picked 10.0.0.0/16 cannot be connected without renumbering or extra NAT, which is the most expensive mistake in network planning.
12. What is a default gateway?
The router a host sends packets to when the destination is not on its own subnet. The host compares the destination with its own address and mask; if it is local, it ARPs for the destination directly, otherwise it ARPs for the gateway and sends the packet there. A wrong gateway produces the classic symptom "I can reach things on my subnet but nothing else."
13. What is NAT, and what is the difference between NAT and PAT?
Network Address Translation rewrites IP addresses as packets cross a boundary, typically mapping private addresses to a public one. Basic NAT maps one private address to one public address. PAT (port address translation, or NAPT, or "NAT overload") maps many private hosts onto one public IP by also rewriting source ports and tracking each flow in a table. That is what your home router and a cloud NAT gateway do.
Consequences worth naming: inbound connections do not work without explicit port forwarding, the NAT device holds state (and can run out of ports under heavy outbound load), and protocols that embed IPs in the payload need help.
14. How does a router choose between overlapping routes?
Longest prefix match. If the table has 10.0.0.0/8 via A and 10.1.2.0/24 via B, a packet for 10.1.2.7 goes to B because /24 is more specific. Only when prefixes tie do other factors decide: administrative distance (which source of the route is trusted more, for example static vs OSPF vs BGP) and then the protocol's own metric.
15. What is BGP, and how is it different from OSPF?
BGP is the routing protocol between autonomous systems (ASes), the independently operated networks that make up the internet. It is a path-vector protocol: routes carry the list of ASes they pass through, and operators choose paths by policy (business relationships, preferences) rather than pure shortest distance. OSPF is a link-state interior gateway protocol used inside one organisation's network; every router learns the full topology and runs a shortest-path calculation.
The follow-up is usually a BGP outage story: because BGP trusts announcements, a misconfigured or hijacked announcement can pull traffic for someone else's prefix, and withdrawing your own routes can take your services off the internet entirely.
16. How does traceroute work?
It sends probes with increasing IP TTL values: 1, 2, 3 and so on. Each router decrements the TTL, and the one that takes it to zero drops the packet and replies with an ICMP "Time Exceeded," revealing itself. Linux traceroute sends UDP probes to high ports by default; Windows tracert sends ICMP echo requests; traceroute -T uses TCP SYNs, which gets through more firewalls.
Gotchas to mention: * * * often means a router does not reply to probes, not that traffic is dropped there; the return path can differ from the forward path; and a latency jump at one hop that does not persist to later hops is usually that router deprioritising ICMP, not a real problem.
Part 3: TCP and UDP (17-26)
17. TCP vs UDP?
TCP is connection-oriented and gives you a reliable, ordered byte stream: handshakes, sequence numbers, acknowledgements, retransmission, flow control and congestion control. UDP is connectionless and gives you individual datagrams with no delivery, ordering or duplication guarantees, and an 8-byte header.
Use TCP when every byte must arrive in order (web, APIs, databases, file transfer). Use UDP when lateness is worse than loss or when you want to build your own reliability: DNS queries, real-time voice and video, games, and QUIC (which is reliable, but implements that on top of UDP in user space).
18. Walk me through the TCP three-way handshake.
- Client sends SYN with its initial sequence number (ISN).
- Server replies SYN-ACK: its own ISN, and an acknowledgement of the client's ISN + 1.
- Client sends ACK acknowledging the server's ISN + 1. The connection is established.
Why three and not two: both sides must announce a starting sequence number and confirm they received the other's. The handshake costs one full round trip before any application data moves, which is why connection reuse (question 25) and protocols that shorten setup (TLS 1.3, QUIC) matter.
19. How does a TCP connection close, and what is TIME_WAIT?
Each direction is closed independently: one side sends FIN, the other ACKs; the other side sends its own FIN, the first ACKs. Four segments, though the middle two are often combined.
The side that closes first enters TIME_WAIT and stays there for twice the maximum segment lifetime (on Linux a fixed 60 seconds). It exists so that a delayed segment from the old connection cannot be mistaken for part of a new connection with the same four-tuple, and so the final ACK can be resent if it was lost. Lots of TIME_WAIT sockets on a busy client is normal; running out of ephemeral ports because of them is not (question 56).
20. What is the difference between flow control and congestion control?
- Flow control protects the receiver. The receiver advertises a receive window ("I have this much buffer"), and the sender never has more unacknowledged data in flight than that.
- Congestion control protects the network. The sender keeps its own congestion window and grows or shrinks it based on signals like loss and delay.
The sender's effective window is the smaller of the two. Mixing them up is the most common wrong answer in this part of the round.
21. Explain TCP slow start and congestion avoidance.
A new connection does not know how much the path can take, so it starts with a small congestion window (commonly 10 segments on modern stacks) and roughly doubles it every round trip as ACKs return. That is slow start, and despite the name it is exponential growth. When the window reaches the slow-start threshold, or loss is detected, the sender switches to congestion avoidance: growing by about one segment per round trip (additive increase) and cutting the window when loss occurs (multiplicative decrease).
Algorithms differ: Reno and NewReno are loss-based, CUBIC (the Linux default) grows as a cubic function of time since the last loss, and BBR models bandwidth and RTT directly instead of treating loss as the main signal. The practical consequence: short connections spend their whole life in slow start, which is another reason to reuse connections.
22. What triggers a TCP retransmission?
Two mechanisms:
- Retransmission timeout (RTO): if an ACK does not arrive within a timeout derived from measured RTT, the segment is resent and the timeout backs off exponentially.
- Fast retransmit: when the receiver gets segments out of order it keeps acknowledging the last in-order byte. Three duplicate ACKs tell the sender a segment was probably lost, and it resends without waiting for the timer.
Selective acknowledgements (SACK) let the receiver report exactly which ranges arrived, so only the missing ones are resent.
23. What is Nagle's algorithm, and why do people turn it off?
Nagle's algorithm reduces tiny packets by holding small writes until the previous data is acknowledged, then sending what has accumulated. Combined with delayed ACKs on the other side (the receiver waits briefly before acknowledging, hoping to piggyback the ACK), a request written in two small pieces can stall for tens of milliseconds or more. Latency-sensitive applications set TCP_NODELAY to disable Nagle. Many RPC frameworks and databases do this by default.
24. Why does real-time video use UDP? What does it do about loss?
A retransmitted video frame that arrives 300 ms late is useless: the moment has passed. TCP would also block every later frame behind the lost one (head-of-line blocking). Over UDP, the application chooses what to do: skip the frame, conceal the gap, use forward error correction, or ask for a new keyframe. WebRTC uses RTP over UDP with its own congestion control so it still backs off when the network is congested. Note that streaming video on demand (watching a recorded show) usually uses HTTP over TCP or QUIC, because a few seconds of buffer makes retransmission acceptable.
25. What are TCP keep-alive and connection pooling, and why do they matter?
Opening a connection costs a TCP handshake, often a TLS handshake, and a trip through slow start. Connection pooling keeps established connections open and reuses them across requests (HTTP keep-alive, database pools). TCP keep-alive is a separate feature: periodic probes on an idle connection to detect that the peer has gone away, and to stop middleboxes like NAT gateways and load balancers from silently dropping idle state.
The classic production bug: a load balancer drops idle connections after 60 seconds, the application's pool keeps them for longer, and the first request after a quiet period fails with a reset. Fix it by making the client's idle timeout shorter than every middlebox's.
26. What are MTU, MSS and Path MTU Discovery?
The MTU is the largest packet a link carries (1500 bytes on standard Ethernet). The MSS is the largest TCP payload, typically MTU minus 40 bytes of IP and TCP headers, so 1460. Path MTU Discovery finds the smallest MTU along the path: IPv4 packets are sent with the "don't fragment" bit set, and a router that cannot forward one replies with an ICMP "fragmentation needed" message carrying its MTU. IPv6 routers never fragment, so PMTUD is mandatory there.
The failure mode is the black hole: a firewall blocks those ICMP messages, small packets work, large ones vanish, and connections hang mid-transfer (question 55).
Part 4: DNS (27-33)
27. Walk through what happens when a name is resolved.
- The application asks the OS stub resolver, which checks local caches and the hosts file.
- The stub sends the query to a configured recursive resolver (your ISP's, a corporate one, or a public one).
- On a cache miss the recursive resolver asks a root server, which refers it to the servers for the TLD (
.com).
- The TLD servers refer it to the domain's authoritative name servers.
- The authoritative server returns the record. The recursive resolver caches it for the record's TTL and answers the client.
dig +trace example.com shows every step. The authoritative server is the source of truth; everything else is a cache.
28. Name the common DNS record types.
- A / AAAA: name to IPv4 / IPv6 address.
- CNAME: an alias to another name.
- MX: mail servers for the domain, with priorities.
- TXT: free text; used for SPF, DKIM, DMARC and domain verification.
- NS: the authoritative name servers for a zone.
- SOA: start of authority; the zone's primary server, admin contact, serial number and timers, including the negative-caching TTL.
- CAA: which certificate authorities may issue certificates for the domain.
- SRV: host and port for a named service.
- PTR: reverse lookup, IP to name.
29. Why can't you put a CNAME at the zone apex?
A CNAME says "this name is an alias, look up the other one instead," so the standard forbids it from coexisting with any other record at the same name. The apex (example.com) must have SOA and NS records, so a CNAME there is invalid. DNS providers work around it with proprietary ALIAS/ANAME or "CNAME flattening" records that resolve the target themselves and return A/AAAA records, which is how you point a bare domain at a load balancer or CDN hostname.
30. What does TTL mean for a DNS migration?
Resolvers cache a record for its TTL, so after you change it, clients can keep using the old value until their cached copy expires. The playbook: lower the TTL well before the change (at least one old TTL ahead, so caches pick up the short value), make the change, keep the old target serving until traffic drains, then raise the TTL again. Also mention negative caching: a lookup that returned "no such name" is cached too, for a time set by the SOA record, so creating a record right after someone queried it may not be visible immediately.
31. Does DNS use UDP or TCP?
Both, on port 53. Ordinary queries use UDP. TCP is used for zone transfers and whenever a response is too large for UDP, in which case the server sets the truncated flag and the client retries over TCP. EDNS(0) allows larger UDP responses, but large DNSSEC answers still fall back to TCP, so "we only allow UDP 53 on the firewall" is a real misconfiguration.
32. What does DNSSEC protect, and what does it not?
DNSSEC adds digital signatures to DNS records, chained from the root down, so a validating resolver can verify that an answer really came from the zone owner and was not modified. It protects integrity and authenticity against spoofing and cache poisoning. It does not encrypt anything: queries and answers are still visible on the wire. Confidentiality is what DNS-over-HTTPS and DNS-over-TLS add (next question).
33. DNS-over-HTTPS vs DNS-over-TLS?
Both encrypt the hop between a client and its resolver. DoT runs DNS over TLS on a dedicated port, 853, which is easy to identify and block or allow at a firewall. DoH runs DNS over HTTPS on port 443, where it blends in with web traffic. That is good for user privacy and awkward for corporate networks that rely on DNS for filtering and visibility. Neither replaces DNSSEC: encryption protects the transport, signatures protect the data.
Part 5: HTTP and the Web (34-41)
34. What happens when you type a URL into the browser and press Enter?
A good answer walks the layers without getting lost:
- The browser parses the URL and checks for an HSTS entry (forces HTTPS) and its caches.
- DNS resolves the hostname (question 27).
- TCP handshake to the IP on port 443 (or a QUIC handshake over UDP for HTTP/3).
- TLS handshake: certificate validation and key agreement (question 42).
- The browser sends the HTTP request; it may pass through a CDN and a load balancer before reaching an application server.
- The response comes back with headers that control caching, cookies and security policy.
- The browser parses HTML, fetches CSS, JavaScript and images (often over the same connection with HTTP/2), builds the DOM and CSSOM, lays out and paints.
Interviewers let you choose where to go deep. Pick the part closest to the role.
35. Which HTTP methods are safe and which are idempotent?
Safe methods do not change server state: GET, HEAD, OPTIONS. Idempotent methods have the same effect whether you send them once or many times: all the safe ones plus PUT and DELETE. POST is neither, and PATCH is not guaranteed to be idempotent. This matters for retries: a client or proxy can safely retry an idempotent request after a timeout, but retrying a POST can charge a card twice, which is why payment APIs use idempotency keys.
36. Explain these status codes: 301, 302, 307, 308, 401, 403, 502, 503, 504.
- 301 permanent / 302 temporary redirect. Clients historically changed a redirected POST into a GET.
- 307 temporary / 308 permanent redirect that must keep the method and body.
- 401 Unauthorized: you are not authenticated (no or bad credentials). 403 Forbidden: you are authenticated but not allowed.
- 502 Bad Gateway: a proxy got an invalid response from the upstream (upstream crashed, reset the connection, spoke garbage).
- 503 Service Unavailable: the server is temporarily unable to handle the request (overloaded, in maintenance); can carry
Retry-After. This is the right code for a temporary outage you know about.
- 504 Gateway Timeout: a proxy gave up waiting for the upstream.
37. How does HTTP caching work?
The server tells caches what they may do with Cache-Control:
max-age=3600: fresh for an hour; serve it without asking.no-cache: you may store it, but revalidate with the server before every use.no-store: do not store it at all (sensitive responses).private vs public: whether shared caches like CDNs may store it.
Revalidation uses validators: the server sends an ETag (or Last-Modified), the client sends it back in If-None-Match (or If-Modified-Since), and the server replies 304 Not Modified with no body if nothing changed. The common pattern for static assets is content-hashed filenames with a long max-age and immutable, while HTML gets no-cache.
38. What did HTTP/2 change, and what problem does HTTP/3 solve?
HTTP/1.1 sends one request at a time per connection, so browsers opened several connections per host and pages queued behind slow responses. HTTP/2 keeps the same semantics but uses a binary framing layer and multiplexes many concurrent streams over one TCP connection, with compressed headers (HPACK). Server push was specified but has been removed from major browsers.
The remaining problem is TCP head-of-line blocking: one lost packet stalls every stream on the connection, because TCP delivers bytes strictly in order. HTTP/3 runs over QUIC, a transport built on UDP that implements reliable, independently ordered streams, so a loss stalls only its own stream. QUIC also integrates TLS 1.3, which cuts connection setup to one round trip (zero on resumption), and supports connection migration when a phone changes from Wi-Fi to cellular.
39. What is CORS and how does a preflight work?
Browsers enforce the same-origin policy: a script on https://app.example.com cannot read responses from https://api.other.com unless that server opts in. CORS is the opt-in: the server sends Access-Control-Allow-Origin (and related headers) saying which origins may read the response.
For requests that are not "simple" (custom headers such as Authorization, methods other than GET/HEAD/POST, or a JSON content type), the browser first sends an OPTIONS preflight asking whether the real request is allowed, and only sends it if the answer permits it. Gotchas: CORS is enforced by the browser, not the server, so it is not an access control mechanism against curl; and Access-Control-Allow-Origin: * cannot be combined with credentials (cookies), so the server must echo a specific origin.
40. WebSocket vs Server-Sent Events vs long polling?
- Long polling: the client sends a request that the server holds open until there is data, then the client immediately asks again. Works everywhere, wastes requests.
- Server-Sent Events (SSE): one long-lived HTTP response that streams text events from server to client. One direction only, automatic reconnection built in, works through most proxies. Good for notifications, feeds and streaming model output.
- WebSocket: an HTTP request that upgrades to a persistent, full-duplex connection. Use it when the client also sends frequent messages: chat, collaborative editing, multiplayer games.
The scaling follow-up: both SSE and WebSocket hold a connection per client, so you need load balancers with long idle timeouts and a way to fan out messages across servers (a pub/sub layer).
41. REST vs gRPC?
REST over HTTP/1.1 or HTTP/2 typically uses JSON, resource-oriented URLs and standard HTTP semantics, which makes it easy to cache, debug with curl and call from a browser. gRPC uses HTTP/2, Protocol Buffers for compact binary messages, a schema-first contract with generated clients, and supports client, server and bidirectional streaming. It shines for internal service-to-service calls. Its costs: browsers cannot speak it natively (you need gRPC-Web or a gateway), and binary payloads are harder to inspect.
Part 6: TLS and Network Security (42-46)
42. Walk me through a TLS 1.3 handshake.
- ClientHello: supported cipher suites, a random value and, in TLS 1.3, a key share (an ephemeral Diffie-Hellman public key) for the groups it expects the server to choose.
- ServerHello: the chosen suite and the server's key share. Both sides can now derive the handshake keys, so everything after this point is encrypted.
- The server sends its certificate and a CertificateVerify signature proving it holds the private key, then Finished.
- The client validates the certificate, sends its Finished, and application data flows.
That is one round trip, versus two for TLS 1.2. TLS 1.3 also removed static RSA key exchange, so every connection has forward secrecy: stealing the server's private key later does not decrypt recorded traffic. Resumption can use 0-RTT data, with the caveat that 0-RTT data can be replayed, so it should only carry idempotent requests.
43. How does a client decide to trust a certificate?
It builds a chain from the server's certificate through any intermediate certificates to a root CA in its trust store, and checks each signature. It also checks that the hostname matches a Subject Alternative Name, that the certificate is within its validity dates, and, depending on the client, revocation status (OCSP, often via a stapled response). The real-world failure: a server configured without its intermediate certificate works in browsers that have cached the intermediate and fails in curl, mobile apps and other servers (question 57).
44. Why does TLS use both asymmetric and symmetric cryptography?
Asymmetric cryptography (Diffie-Hellman key agreement, certificate signatures) solves the hard problem of agreeing on a secret with a stranger and proving identity, but it is slow. Symmetric ciphers (AES-GCM, ChaCha20-Poly1305) are fast and are used for the bulk data once both sides share keys. The handshake uses the expensive tools once; the session uses the cheap ones.
45. What is mutual TLS, and where is it used?
In ordinary TLS only the server presents a certificate. In mTLS the client presents one too, and the server verifies it, so both sides are authenticated cryptographically. It is common for service-to-service traffic inside a service mesh, for B2B APIs and for device authentication. The operational cost is certificate issuance and rotation for every client, which is why meshes automate it.
46. What is a SYN flood, and how do SYN cookies help?
An attacker sends many SYNs (often from spoofed addresses) and never completes the handshake, filling the server's queue of half-open connections so real clients cannot connect. With SYN cookies, the server stops storing state for half-open connections: it encodes the connection details into the sequence number of its SYN-ACK, and only allocates state when a valid ACK comes back carrying that value. Large floods are absorbed upstream by DDoS protection and anycast edges, which spread the load across many sites.
Part 7: Load Balancing and the Edge (47-50)
47. Layer 4 vs layer 7 load balancing?
A layer 4 load balancer works on TCP/UDP connections: it picks a backend per connection from IPs and ports, and does not look at the payload. It is fast, protocol-agnostic and can pass TLS through untouched. A layer 7 load balancer terminates the connection (and usually TLS), understands HTTP, and can route on path, host or headers, retry, rewrite, add headers and balance individual requests over long-lived HTTP/2 connections.
The trade-off: L7 gives you features and per-request balancing at the cost of CPU, latency and certificate management; L4 is the answer for non-HTTP protocols or when you need raw throughput.
48. How does consistent hashing help a load balancer or cache tier?
With hash(key) mod N, changing N remaps almost every key, which empties every cache at once. Consistent hashing places both servers and keys on a ring; a key belongs to the next server clockwise. Adding or removing a server only moves the keys in that server's slice, roughly 1/N of them. Virtual nodes (each server appearing many times on the ring) smooth out the distribution. Use it when requests for the same key should keep landing on the same backend: caches, sharded stateful services, sticky routing.
49. What is connection draining?
When a backend is removed from a load balancer (scale-in, deploy, failed health check), draining stops sending it new connections or requests but lets in-flight ones finish, up to a timeout. Without it, a deploy resets live requests. Pair it with the application handling SIGTERM gracefully: stop accepting, finish what is in flight, then exit.
50. What does a CDN do for you, and what can go wrong?
A CDN serves content from edge locations close to users. Benefits: lower latency (fewer long round trips, TLS terminated nearby), less load and bandwidth on the origin, absorbing traffic spikes and DDoS, and often edge features like WAF rules and image optimisation.
What goes wrong is almost always the cache key and headers: caching a personalised response and serving it to someone else, forgetting that query strings or Vary headers split the cache, or long TTLs on content you cannot invalidate quickly. A good answer mentions which responses must be private or no-store.
Bonus Part 8: Live Debugging Scenarios (51-58)
Senior networking rounds are rarely "define X." They are "users say the site is down, here is a terminal." What is being scored is a method: start at one layer, prove it works, move to the next, and say what each command tells you.
51. "The service is unreachable." How do you work through it?
Go up the stack and stop at the first thing that fails:
dig +short api.example.com
ping -c 3 10.0.4.12
nc -vz 10.0.4.12 443
curl -v https://api.example.com/health
On the server: ss -ltnp to confirm something is listening on the port and on which address (a service bound to 127.0.0.1 is unreachable from outside), firewall rules, and the application logs. Narrate it: "DNS is fine, TCP connects, so it is not the network path; TLS fails, so let's look at the certificate."
52. Connection refused vs connection timed out?
Refused means the host replied with a TCP RST: it is reachable, but nothing listens on that port or something rejected the connection. Look at the service. Timed out means nothing came back at all: a firewall or security group dropped the packets, the route is wrong, or the host is down. Look at the path. This one distinction saves more debugging time than any tool.
53. DNS works on my laptop but not inside the container.
Check what the container is actually using: cat /etc/resolv.conf inside it. Common causes: the container has a different resolver (Docker's embedded DNS, or the cluster's), a corporate split-horizon name only resolves on the VPN, or, in Kubernetes, the ndots:5 default means a name with fewer than five dots is tried against every search domain first, so api.example.com generates several failed lookups before the real one. That shows up as slow or flaky resolution rather than failure. A trailing dot (api.example.com.) makes the name fully qualified and skips the search list.
54. The site is slow. Where does the time go?
Measure before you guess. curl can break a request into phases:
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/
Slow DNS points at resolvers; slow connect points at distance or a congested path; slow TLS at handshakes not being reused; a long gap before the first byte at the server or its dependencies; a long transfer at payload size or throughput. Then check the browser's waterfall for request count and blocking resources.
55. Small requests work, large uploads hang forever.
That is the signature of a Path MTU black hole (question 26). Somewhere on the path the MTU is smaller than 1500 (a VPN tunnel, for example), the ICMP "fragmentation needed" messages are blocked, so large packets with "don't fragment" set are silently dropped. Confirm with ping -M do -s 1472 host (1472 + 28 bytes of headers = 1500) and step the size down until it works. Fixes: allow the ICMP messages through, clamp the TCP MSS at the tunnel, or lower the MTU on the interface.
56. A busy service starts failing outbound calls with "cannot assign requested address."
It ran out of ephemeral ports. Every outbound connection to the same destination IP and port needs a unique local port, and closed connections sit in TIME_WAIT (question 19) holding theirs. ss -s or ss -tan state time-wait | wc -l confirms it. The real fix is connection reuse (a pool or keep-alive) so you are not opening a new connection per request; widening the ephemeral port range or spreading load across more destination IPs buys headroom. A NAT gateway can hit the same limit for all the hosts behind it.
57. TLS errors started right after a certificate renewal, but only for some clients.
The new certificate was probably installed without the intermediate chain. Browsers often still work because they have cached the intermediate or can fetch it; curl, Java, mobile apps and server-to-server clients fail with "unable to get local issuer certificate." Check with openssl s_client -connect host:443 -servername host -showcerts and count the certificates sent. Other suspects: a hostname not in the SAN list, an old client that does not trust a newer root, or a load balancer still serving the old certificate on one listener.
58. A single file transfer between two regions is far slower than the link speed. Why?
Throughput on one TCP connection is bounded by window size divided by round-trip time. The bandwidth-delay product says how much data must be in flight to fill the pipe: 1 Gbps with 80 ms RTT is 1,000,000,000 x 0.08 / 8 = 10 MB in flight. If the effective window is smaller (small socket buffers, window scaling disabled, a receiver that reads slowly), you cannot get there. Packet loss makes it worse, because loss-based congestion control cuts the window. Fixes: larger buffers, a congestion control algorithm suited to long fat networks, or parallel streams.
Quick-Fire: Networking Interview Questions and Answers
The rapid round. Have one sentence ready for each.
- Well-known ports - 22 SSH, 25 SMTP, 53 DNS, 80 HTTP, 443 HTTPS, 3306 MySQL, 5432 PostgreSQL, 6379 Redis. Ports below 1024 need privileges to bind on Unix systems.
- What does DHCP do? - hands a joining host an IP address, mask, gateway and DNS servers (discover, offer, request, acknowledge).
- IPv4 vs IPv6 - 32-bit vs 128-bit addresses; IPv6 drops broadcast and router fragmentation, and uses NDP instead of ARP. NAT is not needed for address scarcity.
- What is ICMP? - the control protocol for errors and diagnostics: echo for
ping, time exceeded for traceroute, fragmentation needed for PMTUD. Blocking all of it breaks things.
- What is a socket? - the endpoint an application uses, identified by protocol, IP and port; a TCP connection is identified by the four-tuple of both ends.
- Stateful vs stateless firewall - stateful tracks connections and allows return traffic automatically; stateless evaluates every packet against rules in both directions.
- Forward proxy vs reverse proxy - a forward proxy acts for clients reaching out (corporate egress); a reverse proxy acts for servers taking traffic in (load balancers, CDNs).
- What is a VPN? - an encrypted tunnel that carries traffic between networks or from a device to a network; IPsec tunnel mode encrypts the entire original packet, which is what site-to-site VPNs use.
- GeoDNS - returns different answers based on where the resolver is, to steer users to a nearby region.
- What is a 5-tuple? - protocol, source IP, source port, destination IP, destination port; the key for connection tracking and many load balancers.
- Half-open vs half-closed - half-open: one side has lost state without the other knowing; half-closed: one side sent FIN but can still receive.
tcpdump filter for one host and port - tcpdump -i any -nn host 10.0.4.12 and port 443.
How to Practice for a Networking Interview
- Watch real traffic. Run
dig +trace, curl -v and tcpdump against a site you use every day and explain each line out loud. The handshake you have seen in a capture is the one you can describe under pressure.
- Do subnet math by hand until a
/26 is instant and you can say whether two ranges overlap without writing anything down.
- Learn the trade-offs as pairs: TCP vs UDP, L4 vs L7, HTTP/2 vs HTTP/3, SSE vs WebSocket, DoT vs DoH. Interviewers ask "when would you choose each," not "define each."
- Rehearse the debugging scenarios in Part 8 with a timer. Ten minutes each, ending with what you would check next if your first guess were wrong.
- Drill under time pressure. Recognition is fast once the concepts are solid; a timed question bank shows you which ones are not.
Keep going
- Drill it under pressure: the networking question bank covers everything above as timed multiple-choice, the security bank covers XSS, CSRF, OAuth and JWT storage, and the free daily challenge gives you one question a day with no account.
- Keep the references open: the networking essentials cheat sheet for protocols and subnetting, and the Linux performance essentials cheat sheet for the
ss, sar and tcpdump side of debugging.
- Go deeper: the DNS system, TLS and HTTPS at scale, load balancer internals and CDN and edge walkthroughs explain the systems behind these answers.
- Round out the loop: Top 50 AWS networking and VPC, Linux, operating system, SRE and distributed systems interview questions.
- Practise the follow-ups: the chat-based AI mock interview asks the "and what if that ICMP is blocked?" questions a real round runs on.
#networking #tcp #dns #http #interviews #backend #sre #career