Networking Interview Questions

OSI’s 7 layers are the textbook; TCP/IP’s 4 run the internet. Application+presentation+session ≈ application; transport = transport; network = internet; data-link+physical ≈ link. Interviewers accept either — know the mapping.

TCP: connection-based reliable ordered byte stream — handshake, ACKs, retransmission, congestion control. UDP: connectionless datagrams with no guarantees — minimal latency, used where speed beats completeness (DNS, voice, gaming, QUIC).

The distributed hierarchy mapping names to records. A: name → IPv4 address directly. CNAME: name → another name (alias), resolution restarts at the target — and it can’t coexist with other records on the same name.

2xx success (200, 201, 204), 3xx redirect (301 permanent, 302 temporary, 304 not modified), 4xx client error (400, 401, 403, 404, 429), 5xx server error (500, 502, 503, 504).

GET reads — parameters in the URL, safe, idempotent, cacheable. POST submits — body payload, may create or trigger side effects, not idempotent, not cached by default.

Private ranges (10/8, 172.16/12, 192.168/16) are never routed on the public internet — reused in every home and office behind NAT. Public addresses are globally unique and routable.

A 16-bit number identifying a process endpoint on a host. 0-1023 well-known (80 HTTP, 443 HTTPS, 22 SSH — root to bind), 49152+ ephemeral — auto-assigned to outgoing client connections.

HTTPS is HTTP inside a TLS tunnel: confidentiality (encrypted), integrity (tamper-evident), authentication (certificate proves the server’s identity via a trusted CA). Same methods, same status codes.

MAC: the link-layer hardware address, meaningful only within one network segment. ARP resolves “who has IP x?” to a MAC by broadcasting on the LAN — the glue between L3 and L2 for local delivery.

Both sides must prove they can send and receive, and exchange initial sequence numbers. Two messages confirm only one direction; the third proves the client received the server’s SYN — without it, delayed duplicate SYNs could open ghost connections.

The closer’s socket lingers (~60s) after the final FIN/ACK so that stray delayed segments die before the 4-tuple is reused, and so the final ACK can be retransmitted if lost. Floods of TIME_WAIT on clients making rapid short connections are normal — pool connections instead.

Recursive: “give me the final answer” — what your stub asks the resolver. Iterative: “tell me who to ask next” — how the resolver walks root → TLD → authoritative, following referrals and caching each step.

DNS TTL: how long resolvers may cache a record (seconds to days) — controls migration speed. IP TTL: hop counter decremented by each router, killing looping packets — and the mechanism traceroute exploits.

GET, PUT, DELETE (and HEAD) — same effect once or five times. POST isn’t. It matters because idempotency decides what clients, proxies and retry middleware may safely re-send after a timeout without risking double side effects.

Cookie session: server stores state, browser carries an opaque ID — easy revocation, but needs a session store shared across instances. JWT: state lives in a signed token — stateless and scalable, but revocation before expiry requires a denylist, reintroducing state.

Connections are keyed by the full 4-tuple (src IP, src port, dst IP, dst port). Each client arrives from a distinct IP:port, so every connection is a distinct socket even though all are “on” port 443.

The peers closed their side; our application never called close() — a descriptor leak in our code, usually a missed close in an error path. Not a network problem. (Contrast TIME_WAIT, which is normal protocol behavior.)

32−26 = 6 host bits → 2⁶ = 64 addresses − 2 (network + broadcast) = 62 usable. A /24 splits into four /26s.

Goes to B. More prefix bits = more specific knowledge of the destination; specific beats general. This is also how a /0 default route coexists with precise internal routes.

The router rewrites outgoing packets’ private source IP:port to its public IP and a tracked port, records the mapping, and reverses it for replies. Consequence: inbound connections fail without a mapping — why servers need port-forwarding and P2P needs STUN/TURN.

1.1: keep-alive but one request at a time per connection (browsers open 6). 2: multiplexed streams + header compression on one TCP connection — but TCP loss stalls all streams. 3: streams over QUIC/UDP retransmit independently, killing transport head-of-line blocking, plus 0-RTT resumption.

That a CA the client trusts vouches the server controls the domain, and the handshake proves the server holds the matching private key. That chain of signatures is the entire defense against man-in-the-middle.

Polling: simplest, fine for slow-changing data. Long polling: server holds the request until data — low latency on legacy infra. SSE: one open HTTP response streaming server→client — perfect one-way push. WebSocket: full duplex upgraded connection — chat, games, collaboration. One-way need = prefer SSE.

TCP presents one ordered byte stream, so a lost segment blocks everything behind it — even other HTTP/2 streams. QUIC (on UDP) makes each stream independently ordered and retransmitted: loss in stream A never stalls stream B. It also moves TLS and transport state into userspace, enabling faster evolution.

Slow start: cwnd doubles per RTT from a small start until loss or threshold. Then AIMD: +1 MSS per RTT, halve on loss. Modern variants (CUBIC, BBR) reshape the growth curve — BBR models bandwidth×RTT instead of reacting to loss. Flow control (receiver window) is separate; effective window = min of both.

Sockets pin users to servers, so servers share a pub/sub backbone (Redis, Kafka, NATS): server 1 publishes to the room channel; server 2, subscribed, pushes down B’s socket. Add presence tracking, heartbeats to reap dead sockets, and client reconnect-with-backoff — the socket layer and fan-out layer are separate systems.

Handshake dropped from 2 round trips to 1 (key share rides in the first flight); resumption can be 0-RTT. Risk: 0-RTT “early data” can be replayed by an attacker — so it must carry only idempotent requests; servers reject non-idempotent early data.

BGP is how ~70k autonomous systems advertise “these prefixes live behind me”. Routers believe advertisements largely on trust; a wrong announcement (route leak/hijack) redirects traffic globally — see the Facebook 2021 outage: withdrawn routes made their own DNS unreachable.

Parse URL → HSTS/cache checks → DNS (browser/OS cache → resolver → root/TLD/authoritative) → TCP 3-way handshake to :443 → TLS 1.3 handshake, cert verified → HTTP request → server side (CDN? LB → app → cache → DB) → response → parse HTML, fetch subresources over the warm connection, build DOM/CSSOM, layout, paint. Then offer to zoom into any stage.

Reproduce and segment: devtools waterfall splits DNS / connect / TLS / TTFB / download. Slow DNS → resolver or TTL churn. Slow connect/TLS → RTT distance, missing keep-alive, no CDN. High TTFB → server/DB, not network. Slow download → payload size or bandwidth. Confirm with curl -w timing fields and mtr for path loss; fix the stage the numbers indict.