Computer Networks

1The mental model (what this really is)#

Networking is a stack of agreements. Each layer trusts the layer directly below it to do one job, and exposes a clean promise to the layer above. Nobody tries to solve everything at once.

The classic teaching model is OSI with seven layers. In real interviews you mostly reason about four, the TCP/IP model:

• Link layer. Get a frame from one machine to the next on the same physical network. Ethernet, Wi-Fi, MAC addresses. Scope is one hop.
• Internet layer (IP). Get a packet from any machine to any other across networks, best effort. IP addresses, routing. No guarantees, no ordering, no retries.
• Transport layer (TCP/UDP). Turn best-effort packets into something an app can use. TCP gives a reliable ordered byte stream. UDP gives cheap, unordered datagrams.
• Application layer. HTTP, DNS, SMTP, gRPC. What your code actually speaks.

Encapsulation: how a packet gets dressed on the way down.

• Your HTTP request sits inside a TCP segment, inside an IP packet, inside an Ethernet frame.
• Each layer adds its own header: TCP carries ports and sequence numbers, IP carries source and destination addresses, Ethernet carries MAC addresses for the next hop.
• The receiver peels them off in reverse, bottom to top.

2Why it matters / core idea#

Interviewers lean on networks because it is where theory meets a real bug. A slow API, a dropped connection, a mysterious 30-second timeout: all of these force you to think across layers.

• Someone who knows networks answers "the payload is tiny but the request takes 400ms, why?" without guessing.
• Someone who does not will blame the database and be wrong.

The four ideas worth truly owning:

1. Reliable vs unreliable transport, and when you pick each, with a real use case, not a textbook line.
2. The handshake and connection lifecycle: how TCP sets up and tears down, and why the counts (three packets to open, four to close) matter.
3. How a name becomes a response: DNS, then TCP, then TLS, then HTTP, in that order and for a reason.
4. Why latency and bandwidth are different, and which one your round trips are bound by.

Everything else is detail you can reason from these four.

3The template (how it works, with pseudocode)#

Here is the mental template for the question that shows up more than any other: what happens when you type https://example.com and press enter? Walk it top to bottom.

1. Parse URL -> scheme=https, host=example.com, port=443 (default)

2. DNS resolution: hostname -> IP
 check browser cache -> OS cache -> router -> recursive resolver
 resolver walks: root -> .com TLD -> example.com authoritative
 returns A/AAAA record (IP address), cached per TTL

3. TCP connection to IP:443
 three-way handshake:
 client -> SYN
 server -> SYN-ACK
 client -> ACK
 now a reliable byte stream exists

4. TLS handshake (because https)
 negotiate version + cipher, server sends certificate,
 client verifies cert chain against trusted CAs,
 both derive a shared symmetric key

5. HTTP request over the encrypted stream
 GET / HTTP/1.1
 Host: example.com

6. Server responds: status line + headers + body

7. Browser renders; may open more connections for CSS/JS/images

8. Connection closed (FIN/ACK both ways) or kept alive / reused

Memorize the order and the reason, not the words.

• DNS before TCP: you need an IP to open a connection to.
• TLS after TCP: TLS runs on top of a reliable stream and assumes bytes arrive in order, which only TCP guarantees.
• HTTP last: it is the payload riding inside everything else.
• Say why each step precedes the next and you are already above average. Most candidates recite the list, then go silent when asked "could TLS come before TCP?" (no, and you should be able to say why in one sentence).

TCP reliability itself, in pseudocode:

# Sender side, simplified
seq = initial_sequence_number
for chunk in data:
 send(segment(seq, chunk))
 seq += len(chunk)
 start_timer(seq)

on_ack(ack_num):
 stop_timer_for(ack_num) # receiver confirmed up to here
 slide_window_forward() # flow + congestion control

on_timeout(seq):
 retransmit(seq) # lost? send it again
 shrink_congestion_window() # back off, network may be congested

The heart of TCP in four moving parts:

• Sequence numbers order the bytes.
• Acknowledgments confirm delivery.
• Timers plus retransmission recover loss.
• A sliding window controls how much is in flight at once, doing two jobs together: flow control (do not overwhelm the receiver's buffer) and congestion control (do not overwhelm the network in the middle).

When a timeout fires, TCP assumes congestion and backs off. That is exactly why a lossy link feels slow even when the pipe is wide.

4A worked example (walk through one problem step by step)#

Question I actually ask: "You load a web page. The HTML comes back fast, but one API call on the page consistently takes about 300ms even though the server says it processed the request in 5ms. Where did the time go?"

Here is how I want you to think out loud.

Step 1: separate server time from everything else.

• The server reports 5ms, so the other 295ms is network and connection setup.
• That already rules out "the database is slow."

Step 2: count the round trips. Say the client is 60ms RTT from the server, normal for a cross-region hop like US East to Europe. A brand new HTTPS connection costs:

• DNS lookup: maybe already cached, so 0, or one RTT if not.
• TCP handshake: 1 RTT (SYN, SYN-ACK, then you can send with the ACK).
• TLS handshake: 1 to 2 RTTs depending on version (TLS 1.3 is 1 RTT, older is 2).
• The actual request and response: 1 RTT.

Do the math:

• A fresh request is easily 3 to 4 RTTs.
• At 60ms each, that is 180 to 240ms before the server even matters.
• Add an uncached DNS lookup and you are near 300ms.
• The server was never the problem, and the 5ms number was the giveaway all along.

Step 3: the fix.

• Reuse the connection. Keep-alive or HTTP/2 means the handshake happens once; later requests cost a single RTT (around 60ms) instead of four.
• TLS 1.3 session resumption can get a repeat connection down to 0-RTT, where the client sends real data in the first packet.
• Put the API behind a CDN or edge closer to the user and you cut the RTT itself, the only move that helps the first request too.

What this is testing: do you know connection setup is round-trip-bound, and that RTT multiplies?

• Candidates who say "maybe the database is slow" without checking the 5ms number fail: they ignored the one hard fact in the problem.
• Candidates who count RTTs pass.
• The best candidates then ask "is this the first request or a repeat?" because the answer changes the fix.

5Variations and gotchas#

TCP vs UDP. The most common follow-up, so have a crisp answer ready before the interviewer finishes the question.

The sharp line to deliver: "TCP trades latency for reliability. UDP trades reliability for latency. QUIC and HTTP/3 are interesting because they rebuild TCP-like reliability on top of UDP to avoid TCP's head-of-line blocking." Say that and the interviewer knows you understand the trade-off, not just the labels.

Head-of-line blocking. One slow item stalls everything queued behind it.

• HTTP/1.1: one slow response blocks the ones behind it on the same connection, so browsers used to open 6 connections per host just to parallelize.
• HTTP/2: multiplexes many streams over one TCP connection, fixing the application layer. But a single TCP packet loss still stalls all streams, because TCP must deliver bytes in order and will not hand up stream B's data while stream A's lost packet is being retransmitted.
• HTTP/3 over QUIC/UDP: each stream has independent delivery, so loss on one stream does not block the others.
• Bring this up unprompted and you look like you have actually read about where the protocols are going.

The TCP handshake is three packets, the teardown is four.

• Open: SYN, SYN-ACK, ACK.
• Close: FIN, ACK, FIN, ACK, because each side closes its half independently (one direction can keep sending after the other has finished).
• Know TIME_WAIT: the side that closes first waits a bit (often 2 times the maximum segment lifetime) before fully releasing the port, so stray late packets from the old connection do not corrupt a new one reusing the same port.
• This is also why a server that opens and closes tons of connections can run out of ephemeral ports under load.

DNS record types.

• A (IPv4), AAAA (IPv6), CNAME (alias pointing one name at another), MX (mail servers), TXT (verification, SPF, domain ownership proofs).
• TTL controls caching, which is why a DNS change can take minutes to hours to take effect everywhere: resolvers keep serving the old answer until the TTL expires.

Public vs private IPs and NAT.

• Your laptop has a private IP (something like 192.168.x.x); your router does Network Address Translation to share one public IP across every device.
• This is why inbound connections to a home machine are hard: there is no stable public address and port mapped to it by default.
• Good to know for any "why can't two peers connect directly" question, which is really about NAT traversal and techniques like STUN/TURN.

HTTP status codes by class:

• 2xx success, 3xx redirect, 4xx client error (you sent something wrong), 5xx server error (server broke).
• 301 vs 302 (permanent vs temporary redirect, which matters because browsers cache 301s hard) and 401 vs 403 (not authenticated vs authenticated but not allowed) signal polish.
• Throwing in 429 for rate limiting or 504 for a gateway timeout signals you have run things in production.

6Trade-offs#

The whole field is latency vs reliability vs complexity. Name the axis you are trading on and you sound like an engineer, not a flashcard.

• Reliability costs round trips. Every guarantee TCP gives you (ordering, delivery) is paid for with acknowledgments and retransmissions, which means waiting for the other side to confirm. There is no free reliability over an unreliable network.
• Latency vs bandwidth. Bandwidth is how wide the pipe is; latency is how long one trip takes. A fat 1Gbps pipe does not help a chatty protocol doing ten sequential round trips, because you spend the whole time waiting, not transferring. This is why batching requests beats upgrading the connection for many workloads, and why mobile apps fight so hard to cut request count.
• Caching vs freshness. DNS TTLs, HTTP cache headers, CDNs: all trade stale-data risk for fewer network trips. Faster, but you can serve old data until the cache expires or is invalidated.
• Connection reuse vs resource cost. Keep-alive saves handshakes but holds server sockets open. At scale that is real memory, real file descriptors, and a connection limit you will hit if you are careless.

7Mistakes that cost people the round#

• Confusing the OSI layer numbers under pressure. Do not memorize numbers you will fumble. Know the four TCP/IP layers and what each does. Saying "TCP is layer 3" loses trust instantly: it is transport, layer 4, and IP is layer 3.
• Saying TCP is "more secure" than UDP. It is not. Reliability is not security. TLS provides security, over either transport.
• Thinking HTTPS is a different protocol from HTTP. It is HTTP over TLS. Same requests, same methods, just an encrypted channel underneath.
• Forgetting DNS is usually UDP. DNS mostly uses UDP port 53 for speed and falls back to TCP for large responses or zone transfers. People assume everything is TCP and get caught.
• Ignoring RTT in a latency question. If you never count round trips you will blame the wrong layer and talk yourself into a fix that changes nothing.
• Describing the handshake as two packets. It is three. And then not knowing teardown at all, or not knowing TIME_WAIT exists.
• Hand-waving "the packet just goes to the server." Interviewers want encapsulation, routing, the hop-by-hop idea where each router only knows the next hop. Show the machinery, even briefly.

8Your practice path (study order)#

Go in this order. Each builds on the last, and skipping ahead leaves holes the interviewer will find.

1. The URL walkthrough (section 3). Say it out loud until it is smooth and you can explain the reason for each step, not just the sequence. Highest-return thing to drill.
2. TCP vs UDP, with two concrete use cases each and the one-line trade-off ("TCP trades latency for reliability").
3. TCP connection lifecycle: three-way handshake, sequence numbers, ACKs, retransmission, four-way teardown, TIME_WAIT.
4. DNS end to end: resolver hierarchy (root, TLD, authoritative), record types, caching and TTL, why it is mostly UDP.
5. TLS at a high level: cert verification against trusted CAs, symmetric vs asymmetric keys (asymmetric to exchange a key, symmetric for the data because it is faster), why the handshake exists. You do not need the byte format.
6. HTTP evolution: 1.1 keep-alive, 2 multiplexing, 3 over QUIC, and the head-of-line blocking story that connects all three.
7. A latency debugging scenario like the worked example. Practice reasoning from numbers: separate server time, count RTTs, propose a fix.

If you can teach all seven to a friend without notes, and survive them asking "but why," you are ready.

9Where this shows up#

Networks appear most in backend, infrastructure, and system design rounds.

• Expect the URL walkthrough and TCP vs UDP at companies that care about fundamentals: the big tech names, payments and fintech, anything real-time (video, gaming, chat).
• System design rounds assume you know this cold when you discuss load balancers, CDNs, API gateways, and replication latency, because every one of those is a networking decision in disguise.
• Even frontend and mobile interviews touch it through HTTP caching, CORS, and request waterfalls in the network tab.

The pattern: networks rarely get a dedicated round, but they get probed inside other rounds to check if your mental model is real.

• An interviewer drops "and how does that request actually reach the service?" into a system design and watches whether you reach for encapsulation and RTT or just wave at a box.
• Treat networking as the connective tissue that makes the rest of your systems answers credible.

Count the round trips before you blame the server.

Want to see which companies push hardest on networking fundamentals and how they phrase it? Check the company guides to map this pattern to the rooms you are actually walking into.