Networking: from URL to packet

A networking round is one request followed down the stack, and the interviewer keeps asking what happens next. The skill being tested is not reciting layers; it is knowing, for each step, what it promises, what it costs in round trips, and how it fails. The trap is to answer with protocol names ("DNS, TCP, TLS, HTTP") and stop. Say the cost of each step and the symptom when it breaks, and every follow-up becomes a question you have already answered.

Symptoms and where they come from, on one screen

Most 'why is this slow or broken' questions have a tell in the first sentence. Hear the tell, name the layer, then say the command you would run.

"Slow the first time, fast after that": Setup cost paid once per connection or per name: a DNS lookup, a TCP handshake, a TLS handshake. Caches and reused connections hide it afterwards.
"Slow only for users far away": Propagation delay. Light in glass covers about 200 km per millisecond, so distance sets a floor on every round trip, and only moving closer or using fewer round trips lowers it.
"Everything lags while someone uploads": A full buffer in the router. TCP only slows when it loses a packet, so a big buffer fills and every other packet waits behind it: bufferbloat.
"Small replies work, large ones hang": A smaller packet size somewhere in the middle, with the 'too big' notes being thrown away. The handshake and short replies fit; a full-size packet does not.
"Connection refused, instantly": The host answered, with a reset: it is reachable and nothing listens on that port.
"Connection timed out": Silence: a firewall dropped it, there is no route, or the host is down.
"One lost packet and the whole page stalls": Head-of-line blocking: TCP delivers one ordered stream, so everything behind the gap waits. HTTP/3 over QUIC gives each stream its own order.
"It dies after exactly 60 seconds idle": A load balancer or NAT table forgetting a connection that carried no traffic for its timeout. Send something more often than the timeout.

Questions

Answer each one yourself before you open it.

01What happens when you type a URL into a browser and press Enter?
The browser finds the address for the name with DNS, opens a TCP connection to it, runs the TLS handshake to make the connection private, sends an HTTP request, and the server, or a CDN near you, sends the page back. The browser then repeats the last steps for every other file the page needs, reusing the connection and its caches.
Each step has a cost you can say. On a cold page, DNS, TCP, TLS and the request are about four round trips before the first byte arrives. The Networking lesson timed one real load of a small page at 84 ms: 18 for DNS, 13 for TCP, 27 for TLS, 24 for the server to start answering, 1 for the body (measured on one home line, so a different line gives different numbers and the same shape). Underneath every one of those messages, the packets cross your home router (which rewrites the address with NAT) and then hop router to router, each choosing the next hop by longest-prefix match.
Follow-up Which of those steps disappear on the second visit?
The DNS answer is cached for its TTL, an open connection can be reused so there is no new TCP or TLS handshake, and files marked cacheable are not fetched at all. What you cannot skip is the request for whatever is not cached.
Learn more One click, every layer · DNS resolution
02Why is DNS carried over UDP, and when does it use TCP?
A DNS question and its answer each fit in one packet, so UDP gets the answer in one round trip and skips the handshake TCP would add. DNS falls back to TCP when an answer is too big for one packet (the server sets a truncated flag) and for copying whole zones between servers.
The original limit was 512 bytes, set in 1987 because that was the largest piece every network of the day could carry whole. EDNS0, in 1999, let a client say it can accept a bigger UDP answer, which is why most answers still fit. The cost of UDP is that there is no connection to prove who is answering: only a 16-bit tag in the message, and the source port, tie a reply to a question.
Follow-up If the tag is only 16 bits, what stops someone forging the reply?
Almost nothing, on its own. In 2008 Dan Kaminsky showed forged replies could be raced in at scale, and the fix was to randomise the source port as well, so a forger has to guess about 32 bits instead of 16. Signing the answers (DNSSEC) or encrypting the lookup (DoH, DoT) closes it properly.
Learn more The DNS wire format · Write the telegram yourself
03How does a resolver find the address for a name it has never seen?
It starts at a root server and asks. The root does not know the answer but refers it to the servers for the top-level domain, such as .com; those refer it to the servers for the domain itself; and that server answers. The resolver caches what it learns for each record's TTL.
Nobody has the whole list. Every level knows only who to ask next, which is why the system scales. A resolver also caches the referrals, so the next .com name starts at a .com server and skips the root. A resolver is born knowing one thing: the addresses of the root servers, shipped as a short file of root hints.
Follow-up What is glue, and why does a referral need it?
If a domain's name servers live inside the domain itself (ns1.example.com for example.com), you would need the answer to find the server that has the answer. So the parent zone sends the name server's address along with the referral. That address is glue.
Learn more DNS resolution · Write the telegram yourself
04What is a DNS TTL, and what happens if you lower it?
It is how many seconds a cache may reuse an answer without asking again. A lower TTL makes a change take effect sooner, and costs more queries to your servers and a slower first lookup for users.
Nothing pushes a change out; caches simply count down. So the time for a change to reach everyone is up to the old TTL. Failures are cached too: a 'no such name' answer is remembered for a time set by the zone's SOA record, so a typo is not free to repeat but a name you create just now may still look missing for a while.
Follow-up You moved the record, and some users still reach the old server an hour later. Why?
Their resolver is still holding the old answer for its remaining TTL, and some resolvers and devices hold it longer than asked. Lower the TTL at least one old-TTL ahead of a planned move, and keep the old server answering until its traffic drains.
Learn more DNS resolution · Lab: the TTL dial
05Walk me through the TCP three-way handshake. Why three messages?
The client sends a SYN with a random starting number. The server replies with a SYN-ACK: its own random starting number and an acknowledgement of the client's plus one. The client sends an ACK of the server's plus one. Data can flow after that, so a new connection costs one round trip before the first useful byte.
Each direction is its own numbered stream, so each side needs to tell the other where its numbering starts and to hear it read back. The numbers are random and have to be echoed, so a sender that forged its return address cannot finish the handshake, because it never sees the server's reply to read the number from.
Follow-up Why not two messages?
With two, the server's starting number is never confirmed by the client, so the server cannot tell a real client from a forged address that merely sent a SYN. The third message is the proof that the client heard the reply.
Learn more Postcards and phone calls (TCP and UDP) · The hold line (SYN queue and SYN floods)
06How does TCP know a packet was lost, and what does it do about it?
Every byte is numbered. The receiver acknowledges the next byte it expects, so a gap shows. The sender keeps a timer per outstanding data, and resends on a timeout; three repeated acknowledgements trigger a resend without waiting for the timer; and a SACK option tells the sender which later pieces did arrive, so only the missing ones are resent.
The sender cannot tell a lost packet from a lost acknowledgement; both look like silence. The timeout is computed from the measured round trip plus four times its variation, so it is long enough not to fire early and short enough to recover. A window keeps many packets in flight at once, which is why a loss does not stop everything.
Follow-up Why wait for three repeated acks, not one?
Packets can arrive out of order without being lost, and each one that arrives early makes the receiver repeat an ack. Three is the compromise: rarely a false alarm, and fast enough to beat the timer on a quick line.
Learn more The page that never arrived
07A user on a train with 5% packet loss: HTTP/2 over TCP, or HTTP/3 over QUIC?
HTTP/3. Over TCP all the streams share one ordered byte stream, so one lost packet stalls every request behind it. QUIC runs over UDP and keeps an order per stream, so only the stream missing a packet waits.
HTTP/2 fixed the queue at the HTTP level by weaving requests onto one connection, but moved it down into TCP, which is head-of-line blocking. The same eight requests ran about seven times faster on HTTP/2 than HTTP/1.1 in the lesson's test, and loss is where HTTP/2 gives much of that back. QUIC also folds the transport and TLS handshakes together, saving a round trip, and survives a phone changing networks because the connection is named by an ID, not by the address.
Follow-up Why did QUIC build on UDP instead of becoming a new protocol next to TCP?
Routers and firewalls everywhere treat anything other than TCP and UDP as suspect, and they inspect TCP closely enough that its behaviour cannot be changed in place (the protocol is ossified). UDP is the postcard nothing along the way bothers to interpret.
Learn more Outgrowing the phone call (HTTP/1.1, 2, 3) · The page that never arrived
08What does TLS cost, and what does it protect?
It costs one extra round trip on a new connection in TLS 1.3, plus a little computing. It makes the connection private and tamper-evident, and proves the server holds a certificate for the name you asked for. It does not hide which site you visited from the network, because the name travels in the clear in the first message (SNI), nor the sizes and timing of what you send.
The handshake uses public-key cryptography once, to agree a secret, then switches to fast symmetric encryption for the rest of the conversation. That is why public-key work is paid once per connection and not per byte. On the measured line in the Networking lesson, the handshake added 35 ms on top of a 13 ms round trip; the exact figure depends on the line.
Follow-up What would a man in the middle need to read your traffic?
A certificate for that name that your device trusts, which means a compromised or careless certificate authority. In 2011 one authority, DigiNotar, issued a false certificate for google.com, which was used against hundreds of thousands of users in Iran before it was caught.
Learn more The whisper code (TLS)
09How does a browser decide a certificate is genuine?
The server sends a chain: its own certificate, signed by an intermediate authority, signed by a root authority that is already in the device's trust store. The browser checks each signature up the chain, that the certificate covers the name in the address bar, that today's date is inside its validity period, and that it has not been revoked.
A public key proves nothing about who owns it until a party you already trust vouches for it. The trust store is how that trust is pre-installed. A self-signed or expired certificate fails because there is no chain to a trusted root or the dates are wrong. openssl s_client ends with a single line, Verify return code, that names which check failed.
Learn more The whisper code (TLS) · It won't load: the ladder
10HTTP is stateless. How does a site still know who you are, and what is a 304?
The server keeps nothing between requests, so every request carries what the server needs. A cookie is how identity rides along: the server sends Set-Cookie once, and the browser sends it back as a Cookie header on every later request to that site. A 304 Not Modified means the copy you already hold is still good, so the server sends no body.
Cache-Control says how long a stored copy stays fresh. After that the browser asks again with the copy's ETag, a fingerprint of it, and a server whose copy is unchanged answers 304 with no body, which costs one round trip and almost no bytes. The status code's first digit tells you who is at fault: 2xx done, 3xx look elsewhere, 4xx the client's mistake, 5xx the server's.
Follow-up Why does a 5xx matter differently from a 4xx to a client?
A 4xx will fail the same way if the client retries unchanged, so retrying is pointless. A 5xx may succeed on a retry, so a client can retry it with a back-off, as long as the operation is safe to repeat.
Learn more What a request actually says
11A page takes 200 ms to load. How do you find where the time went?
Time each phase separately, for example with curl -w: name lookup, connect, TLS, time to first byte, transfer. Each phase points to a different cause. A long lookup is the resolver or a cold cache, connect and TLS are each about one round trip, the gap before the first byte is the server's own work, and the transfer is size over bandwidth plus how fast the window grows.
On the line in the Networking lesson, one round trip was about 13 ms, so a cold page paid about four round trips before the first byte, and the full load measured 84 ms (measured on one home line). A single lost packet can turn a 13 ms stop into a one-second one, which is why the same page can take 84 ms or 1.1 s from the same desk.
Follow-up It is slow only for users on another continent. What does that tell you?
Distance. Each phase that is a round trip is multiplied by the long round trip time, so the fix is fewer round trips (reuse connections, TLS 1.3, HTTP/3) or a shorter distance (serve from a CDN or an anycast edge near the user).
Learn more One click, every layer · Where the time goes
12Why does a fast connection still feel slow for a short download?
Because a sender cannot fill a fast, long line at once. It must have a window of bandwidth times round-trip time in flight to keep the line busy, and TCP starts with a small window and doubles it each round trip (slow start). A short transfer ends before the window has grown, so it is limited by round trips, not by bandwidth.
The bandwidth-delay product is the size that fills the line. A 100 Mbit/s line with a 100 ms round trip needs 100,000,000 x 0.1 / 8 = 1.25 million bytes in flight (arithmetic, not a measurement). A new connection begins with about ten segments, roughly 14 KB at a 1,388-byte segment size.
Follow-up About how many round trips of data does a 40 KB page need on a fresh connection?
Two, after the handshake. The first window is ten segments, about 13.9 KB. The second doubles it to twenty, about 27.8 KB, which brings the total to about 41.7 KB, enough for 40 KB. (An illustration using the lesson's 1,388-byte segment and a window of ten.)
Learn more The long-distance reading · Where the time goes
13What is bufferbloat, and why does a big upload make a video call lag?
A router's buffer that is too large. TCP only slows down when it loses a packet, so a buffer that never drops anything fills and stays full, and every packet, including the video call's, waits behind the upload's queue.
Queueing delay is time spent waiting in a buffer, and it is the one delay that changes minute to minute with everyone else's traffic. A bigger buffer means fewer drops, which looks like an improvement, but TCP is never told to slow down, so the delay climbs and the throughput does not. CoDel fixes it by watching how long packets wait, not how many are waiting, and dropping one when the wait stays high.
Follow-up How would you confirm it on your own line?
Ping a nearby server while saturating the upload. If the ping rises from tens of milliseconds to hundreds or more for the length of the upload, and falls back after, the queue is in your path.
Learn more Where the time goes · The long-distance reading
14A server is 8,000 km away over fibre. What is the lowest ping you could ever get?
About 80 ms round trip. Light in glass covers about 200 km per millisecond, so 8,000 km takes 40 ms one way and 80 ms there and back, and no software can beat it.
This is propagation delay, the one delay that only distance changes. The arithmetic is 8,000 / 200 = 40 ms each way. Real paths are longer than the straight line, so real round trips are worse; this is a floor. Transmission delay (packet size over link speed) is the one a faster plan shrinks; propagation is not.
Follow-up So what does a CDN actually buy you?
A copy of the content, and the end of the TCP and TLS connections, near the user. The round trips that were multiplied by a long distance now happen over a short one.
Learn more Where the time goes · One address, a thousand doors (anycast)
15How does a packet find its way across the internet, and what is BGP?
Each router holds a table of address ranges, called prefixes, and the next hop for each. For a packet it picks the row with the longest matching prefix and hands the packet on; it never knows the whole path. Between networks, BGP is the protocol where each autonomous system tells its neighbours which prefixes it can reach.
Nobody has a map of the whole internet. A router only knows its own short list, and the narrower row wins when two rows cover the same address. BGP carries claims and nothing checks that they are true. In 2008 Pakistan Telecom announced a narrower slice of YouTube's addresses to block it at home; the claim leaked out, longest-prefix match preferred it everywhere, and YouTube's traffic went into a hole in Pakistan.
Follow-up What is the hop limit for?
Every router subtracts one from the packet's hop limit (TTL) and discards the packet at zero, sending a note back. It stops a mis-routed packet circling forever while a mess like the 2008 one is cleaned up, and traceroute uses it as a probe.
Learn more How packets find their way · Inside one postal company (routing inside a network)
16What is NAT, and why did IPv4 last as long as it did?
A home router rewrites each outgoing packet's private source address and port to its one public address and a port it picks, remembers the pairing in a table, and reverses it for the replies. A whole building of devices can share one public address.
The shortage of IPv4 addresses never reached most households because of this. The cost is that an unsolicited packet from outside has no table entry to match, so inside devices cannot be reached directly. Carrier-grade NAT repeats the trick one level up, at the provider.
Follow-up How do you accept connections to a server behind NAT?
Port forwarding on the router, so a chosen outside port maps to an inside address; or have the inside device open an outbound connection to a relay and keep it open, because replies on an outgoing connection always have an entry.
Learn more Inside your building (NAT, DHCP, ARP) · Lab: one address, many doors
17Why do you need both an IP address and a MAC address? And what is the difference between a switch and a router?
The IP address gets a packet to the right network across many routers. The MAC address gets a frame to the right device on the one link it is on. At each hop the frame is rewritten with new MAC addresses while the IP addresses inside stay the same, and ARP is how a device asks which MAC owns an IP on its link. A switch forwards frames by MAC address within one network; a router forwards packets by IP address between networks.
A switch learns which port each MAC is behind by reading the sender of every frame, sends a frame for a known address down one port, and floods one for an unknown address to every other port. A broadcast frame reaches the whole broadcast domain, which ends at the router, and a VLAN splits one switch into several such domains.
Follow-up Why would a switch flood a frame to every port?
It has not seen the destination MAC as a sender yet, so it does not know which port it is behind. It sends the frame to all ports except the one it came in on, and learns the answer from the reply.
Learn more The corridor inside (frames, switches, VLANs) · Inside your building
18What is anycast, and why is it good for DNS but awkward for long connections?
The same IP address is announced from many places over BGP, and ordinary routing sends each client to the nearest one, usually the shortest path. A site going down is just a withdrawn announcement, and traffic moves to the next best.
DNS is a one-packet question with a one-packet answer, so there is no conversation to break if the next question lands somewhere else. A long TCP connection is the opposite: if routes shift mid-connection, packets arrive at a different site that has no such connection and it answers with a reset. That is why anycast fits DNS, and CDNs that use it keep connections short or terminate them at the edge.
Follow-up What did the 2002 and 2007 root-server floods show?
That spreading one address across many sites contains an attack: the 2002 flood barely dented the internet, and the 2007 one hurt only the doors that had not been spread out yet.
Learn more One address, a thousand doors
19How does a SYN flood work, and why can't you stop it with a bigger queue?
The attacker sends a stream of SYNs with forged return addresses and never finishes any handshake. The server keeps a note for each half-open call in its SYN queue, the queue fills with notes that will never complete, and real callers are ignored. The fix is SYN cookies: the server encodes its note into its own starting number and keeps nothing until a valid final ACK returns.
Any finite queue can be filled by a sender willing to send faster than the notes expire; a bigger queue only raises the price. A SYN cookie works because a real caller's ACK must carry the server's number plus one, so the server can recompute the note from it. The cost is that options in the note, such as a large window, cannot fit in the number and are lost on those connections.
Follow-up Separately, what happens when the accept queue is full?
Handshakes complete but the program has not called accept(), so finished calls wait on the hold line; the backlog passed to listen() caps how many. Past that, the kernel drops or resets new callers, depending on the system.
Learn more The hold line (SYN queue, accept queue, SYN cookies)
20A service is unreachable. What is the difference between 'connection refused' and 'timed out', and how do you debug?
Refused, and fast, means the host answered with a reset: it is reachable and nothing listens on that port. A timeout means silence: a firewall dropped the packet, there is no route, or the host is down. Debug in order: name, route, port, TLS, HTTP, with one command for each, and only move on when the rung below passes.
The order matters because each question only makes sense once the one before it passes. dig answers whether the name resolves, and read its SERVER line, since asking the wrong resolver is as common as the wrong name. ping or a route check shows whether anything answers; a default route pointing at a missing router makes every outside address unreachable. A connect attempt tells refused from timed out. openssl s_client names a bad certificate in its last line. Only then is the application's HTTP worth reading.
Follow-up Small responses work, but large ones hang. Where do you look?
The path MTU. A link in the middle carries smaller packets, and the 'too big' ICMP notes that should make the sender shrink them are being dropped by a firewall. The handshake and short replies fit; full-size packets disappear.
Learn more It won't load: the ladder · Inside one postal company (ICMP)
21How does SSH know the server is not an impostor, and how does the server know it's you?
The server proves itself with its host key. Your client records that key in known_hosts the first time you connect (trust on first use), and a different key later triggers a loud warning. You prove yourself by signing a fresh challenge with your private key, and the server checks the signature against the public keys in authorized_keys, so no secret is sent.
A changed host key means either the server was rebuilt or someone is sitting in the middle, so you must find out which before you accept it. Forwarding your agent (-A) lets the remote machine ask your agent to sign while you are connected, so a compromised remote can use your identity; jumping through a bastion with -J does not hand it over.
Follow-up What does -L 9000:127.0.0.1:8099 do?
It listens on port 9000 on your laptop and carries each connection through the encrypted SSH session to the server, which connects on to port 8099 on its own loopback. A service that is not exposed to the internet becomes reachable from your laptop.
Learn more The key at the door (SSH)
22My WebSocket dies after about 60 seconds behind the load balancer. Why?
An idle timeout. A load balancer, and any NAT or connection-tracking table on the way, forgets a connection that has carried no traffic for its timeout, and 60 seconds is a common default. The fix is to send something more often than the timeout, an application heartbeat or a TCP keepalive, or to raise the timeout.
Nothing is broken: a middlebox kept state for the connection, the state expired, and the next packet either gets a reset or disappears. The client sees an abrupt close or silence. A heartbeat every 20 to 30 seconds, comfortably under the timeout, also tells you quickly when a peer has really gone.
Follow-up Why does the connection then reconnect fine on the second try?
A new connection creates new state in every middlebox. Only the idle one was forgotten, so a client should reconnect with back-off and resume from the last message it saw.
Learn more It won't load: the ladder · The customer who won't hang up (WebSockets)

← Data systems: which trade-off is this?