Core CS · Computer Networks

Press Enter, and eight protocols go to work

Q: Walk me through what happens when you type a URL and press Enter.

In stages, naming the layer each time. The browser parses the URL into scheme, host and path, and checks its own HTTP cache, its DNS cache, the hosts file and the OS resolver cache. On a miss, DNS resolves examate.in over UDP port 53 : recursive to your resolver, which then walks root, then the .in TLD, then the authoritative server. With the address in hand the kernel does a longest prefix match in its routing table, finds the destination off-link and picks the default gateway. ARP broadcasts for the gateway’s MAC. Then TCP completes its three way handshake to port 443, TLS 1.3 completes its handshake in one more round trip, and only then does the HTTP GET travel inside the encrypted channel. The response comes back, is decapsulated by Ethernet, IP, TCP and TLS in turn, and the browser renders. Somewhere on the way out the router rewrote your source address and port, because a private address is not routable.

Q: Whose MAC address does ARP ask for, and why is it not the server’s?

The next hop’s , which for an off-link destination is the default gateway. ARP is a broadcast and a broadcast does not cross a router, so a host can only ever resolve something inside its own broadcast domain. The server is thousands of kilometres away and is unreachable by broadcast, so asking for its MAC could never be answered. The frame therefore leaves with destination IP 198.51.100.7 and destination MAC 00:1A:A0:00:00:FE , which belong to two different machines, and that apparent mismatch is the correct and intended state. If the destination had been on the same subnet, ARP would have asked for the destination itself and no router would have been involved.

Q: The packet crosses a dozen routers. What is different in its headers at the last hop compared with the first?

Both MAC addresses are completely different, because each router strips the frame it received and builds a new one for the next link, so the Ethernet header names one hop and is rewritten at every one of them. Both IP addresses are unchanged, because the IP header names the two ends and is meant to survive the whole path. Two other fields do change at every hop and are worth volunteering: the IPv4 TTL is decremented by one, and because the TTL sits inside the header the header checksum has to be recomputed. The one exception to the IP rule is NAT , which rewrote the source address and source port once, at the boundary of your own network.

Q: One field is rewritten on the way out and rewritten back on the way in. Which, and by what?

The source address and source port , rewritten by NAT on the boundary router. Your laptop is 192.168.1.10 , which is a private address that no router on the Internet will forward, so the router substitutes its own public 203.0.113.5 and a port of its choosing, and stores one row mapping the two. The server therefore answers the public pair and has no idea your laptop exists. When the reply arrives the router reads that row backwards and restores the original destination before sending it in. This is the only point in the whole journey where an IP address changes, which is why it is worth naming as the exception rather than leaving it as a contradiction.

Q: I typed http:// instead of https://. What changes in the journey?

The default port becomes 80 instead of 443, and the entire TLS handshake stage disappears , so a cold visit costs one round trip fewer, or two fewer against TLS 1.2. Everything else is identical: the same DNS lookup, the same routing decision, the same ARP, the same TCP handshake, the same HTTP message. What you lose is all three of what TLS provides: confidentiality, so anyone on the path reads the method, the path, the headers and the body; integrity, so anyone on the path can alter them undetected; and authentication, so nothing proves you reached the site you named. In practice most sites answer a plain HTTP request with 301 Moved Permanently to the https URL, so you pay for the plaintext round trip and then do the whole journey again anyway.

Q: Where is the time actually going, and which of the delay components does a faster link reduce?

Only the transmission delay , which is the number of bits divided by the link rate and is the time to push the data onto the wire. It is usually the smallest of the four for a page like this. Propagation delay is distance divided by the signal speed in the medium and a faster link does not touch it, which is why every round trip costs the same whether you are on 10 Mbit/s or 1 Gbit/s. Queuing delay is time spent waiting in a router buffer and rises sharply as a link approaches saturation. Processing delay is the per-hop work of checking headers and looking up routes. For a cold page load, the total is dominated by the number of round trips multiplied by the propagation delay, which is exactly why removing round trips is the lever that works and buying bandwidth often is not.

Q: Something is broken and you have no idea where. Which layer do you test first?

The lowest one, because of an asymmetry: a fault at a low layer explains every symptom above it, while a fault at a high layer explains nothing below it. So one passing check at the bottom clears the entire stack underneath it in one command, and one failing check there means nothing above it was ever worth testing. Working upward: ip link and ip neigh for the interface and the ARP cache; ping and traceroute for reachability; ip route get for the next hop the kernel would actually pick; a request straight to the IP address for whether anything is listening on the port; and dig for whether the name resolves and to what. Working downward instead means every failure looks the same at the top, because a dead server, a wrong DNS answer and an unplugged cable all present as a page that will not load.

This is the most asked question in the whole subject, and it is asked because answering it well needs every module of this course at once. One URL, one page, and the entire stack in order.

Step through all fourteen stages, then replay it warm →

Eight round trips, six lookup tables and about 5,800 bytes cross your own link to deliver 1,200 bytes of HTML. Seven of those eight round trips finish before the page has even been asked for. Every one of them is a lesson you have already done; this is where they join up.

01 The idea

Every stage is one table turning one name into the next name

You type https://examate.in/pricing.html and press Enter. What you have handed the machine is a name, and a name is the one thing no part of the network can act on. A router cannot forward to examate.in. A network card cannot address a frame to 198.51.100.7. A switch cannot find a port from a MAC address it has never seen. So the entire journey is a chain of translations, each one performed by a different box, each one reading a different table, and none of them knowing what the next one will do.

There are six of those tables and it is worth naming them before anything moves, because every stage below is one of them being consulted. DNS turns the hostname into an IP address. The routing table turns that IP address into a next hop. The ARP cache turns the next hop into a MAC address. The switch MAC table turns that MAC address into a physical port. The NAT table turns your private address and port into a public pair, and back again on the way home. The socket table turns the destination port on the far machine into the process that will actually read your request. Six lookups, six different pieces of infrastructure, and only the first of them lives on the far side of the Internet.

The second thing to hold on to is what all of this costs, because interviewers push here and the answer is not bytes. It is round trips. A round trip is one message going out and its reply coming back, and its duration is set by distance divided by the speed of a signal in glass or copper. You cannot buy it down with a faster link. On a cold first visit this page needs eight of them, and only the last one carries a single byte of HTML. That fact is the whole reason DNS caching, connection reuse and TLS 1.3 exist, and once you have counted the eight, none of those three feels like an optimisation any more. They feel like the only way this could ever have been fast.

The third thing is a rule and its one exception, and this is the pair that separates a good answer from a memorised one. The MAC addresses on a packet change at every single hop. The IP addresses do not change at all. The Ethernet header answers who hands this on next, and it is rewritten by every router on the path. The IP header answers where this is ultimately going, and it is meant to survive the whole journey untouched. The exception is NAT, which rewrites the source IP address and the source port exactly once, at the boundary of your home or campus network, and rewrites them back on the reply. If you can state the rule and then name its one exception without being prompted, you have said something most candidates do not.

So read this lesson as a re-linking exercise rather than as new material. At every stage below you should be able to say four things: which layer is acting, which protocol it is speaking, what the source and destination look like at that instant, and which earlier lesson taught it. Those four things are also, not by accident, exactly what a good spoken answer contains.

The journey from a URL to a rendered page is six lookups in a row, each turning one kind of name into the next: hostname into IP, IP into next hop, next hop into MAC, MAC into switch port, private tuple into public tuple, port into process. No box on the path knows the whole route. Each one only knows its own table and the next hop, and the whole cost is counted in round trips, not in bytes.

ResolutionTurning one identifier into another by consulting a table. DNS resolves a name to an address, ARP resolves an address to a MAC, the routing table resolves an address to a next hop. When an interviewer asks “what happens next”, they are usually asking which table is read and who holds it.

Round trip timeThe time for one message to reach the far end and its reply to return, written RTT. It is set by distance and by the speed of the signal in the medium, so it is the one cost that a faster link does not reduce. Every handshake in this lesson is priced in RTTs.

EncapsulationEach layer wraps whatever the layer above handed it in a header of its own: HTTP inside a TLS record, inside a TCP segment, inside an IP packet, inside an Ethernet frame. At the far end each layer strips exactly the header its opposite number added, which is called decapsulation.

02 Worked example

The whole journey in five moves, before we slow it down

One scenario, and it is the only scenario in the lesson. A laptop at 192.168.1.10 with MAC 00:1A:A0:00:00:0A sits behind a home router whose inside address is 192.168.1.1, MAC 00:1A:A0:00:00:FE, and whose public address is 203.0.113.5. The resolver is Google Public DNS at 8.8.8.8. The page wanted is https://examate.in/pricing.html, 1,200 bytes of HTML, and examate.in lives at 198.51.100.7. Read left to right. The highlighted node is the one candidates get wrong.

1. NameThe URL splits into scheme https, host examate.in and path /pricing.html. The scheme fixes the port at 443 and demands TLS. Only the host needs resolving; the path is never looked up by anyone but the server.

→

2. AddressCaches are checked first and all miss. A DNS query goes to 8.8.8.8 on UDP port 53. That resolver then asks a root server, a .in server and the authoritative server in turn. Answer: 198.51.100.7, TTL 300 s.

→

3. Next hopThe routing table has no row covering 198.51.100.7 except the default, so the packet is off-link and the next hop is 192.168.1.1. ARP therefore broadcasts for the gateway’s MAC, not the server’s. The switch learns the sender’s port on the way past.

→

4. ConnectionTCP’s three way handshake to 198.51.100.7:443 costs one RTT. The TLS 1.3 handshake on top of it costs one more. The router rewrites the source to 203.0.113.5:50000 on the way out. Still no page.

→

5. ContentOnly now does GET /pricing.html travel, encrypted inside TLS. The 200 OK comes back, is decapsulated by Ethernet, IP, TCP and TLS in turn, and the browser parses the HTML. Round trip eight of eight.

Count what happened in node 4 and node 5 together, because that is where the surprise is. The connection cost one round trip and the encryption cost one more. Add the four spent resolving the name and the one spent on ARP, and seven full round trips completed before the browser sent the word GET. The eighth is the request and its response, and it is the only one of the eight that carries page content. On a link with 85 milliseconds of one-way propagation delay, one round trip is 170 ms, so those seven cost about 1.2 seconds of pure waiting. Here is the same journey with the four addressing fields written out at each moment, which is the form to answer in:

stage  layer        protocol       source -> destination                bytes01     Application  none           parse scheme / host / path             0 B02     Application  none           four local caches, all miss            0 B03     Application  DNS over UDP   192.168.1.10:51000 -> 8.8.8.8:53      74 B04     Application  DNS iterative  resolver -> root, .in, authoritative   0 B05     Application  DNS over UDP   8.8.8.8:53 -> 192.168.1.10:51000      90 B06     Internet     none           longest prefix match -> 192.168.1.1    0 B07     Link         ARP            who has 192.168.1.1 (not the server) 128 B08     Transport    TCP SYN        ephemeral 51343 -> 198.51.100.7:443   64 B09     Internet     NAT            source becomes 203.0.113.5:50000       0 B10     Transport    TCP            SYN-ACK, then ACK                    128 B11     Application  TLS 1.3        one round trip, then encrypted      3596 B12     Application  HTTP in TLS    GET /pricing.html                    196 B13     Application  HTTP in TLS    200 OK, 1200 bytes of HTML          1506 B14     --           totals         8 round trips                       5782 B

Check the arithmetic yourself, because the console in section 04 recomputes every one of these and the two should agree. 74 for the DNS query is 14 bytes of Ethernet header, 20 of IP, 8 of UDP, 28 of DNS message and 4 of frame check sequence. 128 for ARP is two frames of 64 bytes, which is Ethernet’s minimum: an ARP packet is only 28 bytes and has to be padded up to a 46-byte payload. 64 for the SYN is the same padding again, because 20 bytes of TCP header plus 20 of IP is 40 and 40 is under the minimum. 1506 for the response is 226 bytes of HTTP headers plus a 1,200-byte body, plus 22 bytes of TLS record overhead, plus 40 of TCP and IP, plus 18 of Ethernet framing. Add the column and you get 5,782 bytes to deliver 1,200. The page is 21 per cent of what moved.

Two of those fifteen lines are highlighted because they are the two that get answered wrong. Line 7 is where students say the routing table is consulted for the gateway; it is not. It is consulted for 198.51.100.7, and the gateway is the answer, not the question. Line 8 is where students say the host broadcasts asking for the web server’s MAC address. It never does, and it never could: a broadcast does not cross a router, so a machine can only ever ARP for something on its own link. What it asks for is 192.168.1.1.

One honest note about the ordering, because it will earn you credit rather than cost it. In a real packet capture the ARP exchange at line 8 appears before the DNS query at line 4, not after it. The DNS query is itself a packet addressed to 8.8.8.8, which is also off-link, so it also needed a routing lookup and a next hop MAC before it could leave. The order above is the order the question is asked in, and it is the order to give in an interview because it is how the problem decomposes. Saying the sentence “in a capture the ARP comes first, because the DNS query is itself a packet” tells the interviewer you have watched this happen rather than only read about it.

03 Mechanics

The stages, the fields that change, the second visit and the failures

Five tables, in the order the interview escalates. The first is the spine: every stage, the layer acting, the protocol, the addressing in use and the lesson it came from. Learn the last column as seriously as the others, because a candidate who can say “this is the routing lesson, and the next one is the ARP lesson” sounds like someone with a model rather than someone with a list.

Stage	Layer	Protocol	Addressing at that instant	Cost	Taught in
1. Parse the URL	Application	none on the wire	scheme https, host examate.in, path /pricing.html, port 443 implied	`0`	HTTP and HTTPS
2. Check four local caches	Application	none on the wire	browser HTTP cache, browser DNS cache, hosts file, OS resolver cache	`0`	DNS
3. Resolve the name	Application	DNS over UDP port 53	192.168.1.10:51000 to 8.8.8.8:53, recursive	`4 RTT cold, 0 warm`	DNS
4. Choose the next hop	Internet	none, a table lookup	destination 198.51.100.7; longest prefix match returns 192.168.1.1	`0`	Routing basics
5. Resolve the next hop’s MAC	Link	ARP	broadcast asking for 192.168.1.1, never for the server	`1 RTT`	Ethernet and ARP
6. Open the connection	Transport	TCP	ephemeral 51343 to 443, three way handshake	`1 RTT`	Three way handshake
7. Cross the NAT boundary	Internet	NAT rewrite	source becomes 203.0.113.5:50000; destination untouched	`0`	Private and public IP
8. Secure the channel	Application	TLS 1.3	identical four-tuple; nothing about the addressing changes	`1 RTT (2 on TLS 1.2)`	SSL and TLS
9. Send the request	Application	HTTP inside TLS	same connection; GET /pricing.html with a Host header	`rides the next RTT`	HTTP and HTTPS
10. Receive the response	Application	HTTP inside TLS	source and destination reversed all the way down the stack	`1 RTT`	HTTP and HTTPS
11. Decapsulate	all four	Ethernet, IP, TCP, TLS	each layer strips exactly the header its opposite number added	`0`	Encapsulation
12. Render	Application	none on the wire	the HTML is parsed, and every image and script starts this table again	`0`	HTTP and HTTPS

Read the cost column and notice where the zeros are. Six of the twelve stages cost nothing at all, because nothing has to travel and come back for any of them: parsing, checking the caches, the routing lookup, the NAT rewrite, decapsulation and rendering are all work done on one machine. Stage 9 costs nothing extra either, because the request rides out on a connection that is already open. All the time is in stages 3, 5, 6, 8 and 10, and every one of those is a message waiting for a reply. That is what it means to say the web is latency bound rather than bandwidth bound: the expensive stages are expensive because something had to travel and come back, not because anything was large.

Now the table that decides the follow-up question. The first three rows are the same TCP SYN captured at three points on its way out; the fourth is the SYN-ACK coming back on your own link. Nothing is malformed anywhere here. Read down each column rather than across each row.

Where you capture it	Source MAC	Destination MAC	Source IP : port	Destination IP : port
Your own link, laptop to gateway	00:1A:A0:00:00:0A	00:1A:A0:00:00:FE	192.168.1.10:51343	198.51.100.7:443
The router’s outside link, after NAT	`00:1A:A0:00:00:F1`	`00:1A:A0:00:00:E1`	`203.0.113.5:50000`	198.51.100.7:443
The last link before the server	`00:1A:A0:00:00:C1`	`00:1A:A0:00:00:07`	203.0.113.5:50000	198.51.100.7:443
The SYN-ACK, back on your own link	`00:1A:A0:00:00:FE`	`00:1A:A0:00:00:0A`	198.51.100.7:443	`192.168.1.10:51343`

The two MAC columns are different in every single row. The two IP columns are identical everywhere except the two cells NAT touched. That is the whole rule and its whole exception in one picture. The Ethernet header is rewritten by every device that forwards the frame, because it names one hop and a hop is over the moment the frame arrives. The IP header is meant to be carried end to end, and the only reason it is not is that 192.168.1.10 is a private address that no router on the Internet will forward, so the boundary router substitutes its own public address and remembers the substitution. Two other fields change at every hop and are worth naming without being asked: the IPv4 TTL is decremented by one, and because the TTL is inside the header the header checksum has to be recomputed.

The second visit. This is the follow-up that arrives about ninety per cent of the time, and the weak answer is “it comes from the cache”. There are three separate caches involved, they save three different things, and they run on three independent clocks.

What happened on the first visit	What happens the second time	What removed it	What that saves
Four DNS exchanges to resolve examate.in	nothing leaves the machine	the DNS cache entry, valid for its TTL of 300 s	`4 round trips`
ARP broadcast and unicast reply for the gateway	nothing leaves the machine	the ARP cache, kept fresh by the traffic already flowing	`1 round trip`
TCP three way handshake, 192 bytes	nothing; the connection was never closed	Connection: keep-alive, the default in HTTP/1.1	`1 round trip`
TLS handshake, about 3,600 bytes	nothing; the session on that connection is still live	reusing the connection, so there is nothing to negotiate	`1 round trip`
GET, answered with 1,200 bytes of body	a conditional GET answered 304 Not Modified	the stored ETag, quoted back in If-None-Match	`the whole body`
8 round trips, 5,782 bytes	1 round trip, 432 bytes	four things already in hand, on three independent clocks	`7 RTT, 5,350 bytes`

Three clocks, and they expire independently. The DNS entry lives for the TTL the authoritative server chose. The connection lives until either side closes it or an idle timeout fires, typically a few seconds to a couple of minutes. The cached page lives for its max-age. So a page can be stale while its name is still resolved, which is exactly the case the console’s warm run shows: 70 seconds have passed, the 300-second DNS entry is fine, and the 60-second page is not. If the entry had still been fresh there would have been no packets at all and the fastest possible request would have been the one that never happened.

The other follow-up is what changes when the destination is on your own LAN. It is a short answer and it is worth being able to give crisply, because the interviewer is checking whether you understand why the gateway was involved rather than reciting that it was.

Stage	Off-link, this lesson	Same LAN, a machine at 192.168.1.50
Routing table lookup	only 0.0.0.0/0 matches, so the next hop is 192.168.1.1	192.168.1.0/24 matches and is more specific, so the destination is its own next hop
ARP asks for	192.168.1.1, the gateway	192.168.1.50, the destination itself
Destination MAC on the frame	the gateway’s 00:1A:A0:00:00:FE	the destination host’s own NIC
Routers on the path	at least one, in practice ten to twenty	`none`
NAT	source IP and port rewritten at the boundary	`nothing is rewritten`
TTL on arrival	decremented once per router	arrives at its initial value, untouched
Typical round trip time	`tens of milliseconds`	`well under a millisecond`

The mask is the only thing that made the difference. Nothing about the two destinations differs except whether the address, ANDed with the subnet mask, equals the host’s own network number. That single bitwise comparison decides whether ARP asks for the destination or for the gateway, and therefore whether a router is ever involved. Widen the mask wrongly and a host will confidently ARP for a machine that is not on its link, get no reply, and report the destination as unreachable while insisting nothing is wrong with its configuration.

Finally, the transferable skill, which is the part of this lesson you will still be using in five years. When something is broken you do not guess. You work up the layers, and the reason is an asymmetry: a fault at a low layer explains every symptom above it, while a fault at a high layer explains nothing below it. So a check that passes at layer two has ruled out everything at layer two and below in one command, and a check that fails there means nothing above it was ever worth testing.

Layer	The question it answers	The tool	What a failure here looks like
Link	Is the interface up and do I have a neighbour?	ip link, then ip neigh	the interface is DOWN, or the ARP entry for the gateway sits at INCOMPLETE
Internet	Can a packet reach the far address at all?	ping 198.51.100.7, then traceroute	no replies, and traceroute stops at the same hop every time
Internet	Which next hop would this machine actually pick?	ip route get 198.51.100.7	the wrong gateway, or no route to host
Transport	Is anything listening on that port?	a request straight to the IP address	connection refused means the host is up and the service is not
Application	Does the name resolve, and to the right address?	dig examate.in, and dig +trace	NXDOMAIN, an empty answer section, or a stale address
Application	Is the server answering correctly?	the response status and headers	a 4xx or 5xx status, which means the whole stack underneath worked

The status code is the best news in the table. If you got a 502 or a 403 back, then DNS resolved, routing worked, ARP worked, TCP connected, TLS negotiated and HTTP was parsed. Six stages just certified themselves as healthy, and the fault is in the last one. That is why the first question to ask a user is not “is it down” but “what does it actually say”: a specific error is a diagnosis and a spinning tab is not.

One warning about ping, because it is the tool people reach for first and it decides the least. ping uses ICMP, which is neither TCP nor UDP and is filtered by a great many networks as policy. A successful ping proves the path and the host are alive. A failed ping proves almost nothing, because the host may be perfectly healthy and configured not to answer. Never conclude “the server is down” from a failed ping alone; go up one layer and try to open the port instead.

05 Cheat sheet

Sixteen answers to have ready the morning of the interview

Every row is something asked flat out in this question or in the follow-ups to it. The right-hand column is the specific wrong answer that gets given, not a general caution.

What they ask	The answer	The trap
The order of the whole journey	`parse · caches · DNS · route · ARP · TCP · TLS · HTTP · render`	Starting at DNS. Four local caches are checked first, and a hit on the first one ends the story.
DNS port and transport	`UDP 53`, with TCP 53 for oversized answers and zone transfers	Answering TCP. UDP is the default because one query and one answer fit in one datagram each.
Recursive against iterative	`you to the resolver is recursive · resolver to root, TLD, authoritative is iterative`	Calling the whole thing recursive. Only the first hop is; the resolver does the walking.
Whose MAC does ARP ask for	`the next hop’s, which for an off-link destination is the default gateway`	`“the server’s”` — a broadcast does not cross a router, so it could not work
How the next hop is chosen	`longest prefix match in the routing table`	Saying the first matching row wins. The most specific matching row wins.
What changes at every router hop	`both MAC addresses change · both IP addresses do not`	Forgetting the TTL decrement and the IPv4 header checksum recomputation that follows it.
The one exception to that rule	`NAT rewrites the source IP and source port, once, at the boundary`	`“IP addresses never change”` — they change exactly once, and back again on the reply
The ports on the connection	`an ephemeral source port to destination 443`, or 80 for plain HTTP	Saying the source port is 443 as well. Only the destination is the well-known port.
Round trips before the first byte, cold	`4 DNS · 1 ARP · 1 TCP · 1 TLS 1.3 · 1 request = 8`	`counting DNS as one` — the resolver’s own walk is inside your wait, and the ARP exchange is a round trip too
TLS 1.2 against TLS 1.3	`1.2 needs two round trips · 1.3 needs one`	Saying it the other way round, or forgetting TCP’s own round trip underneath both.
What is plaintext in a TLS 1.3 handshake	`only ClientHello and ServerHello; the certificate is encrypted`	Claiming the certificate travels in the clear. That was true in TLS 1.2, not 1.3.
What is skipped on the second visit	`DNS cached · connection reused · 304 instead of a body`	`“it comes from the cache”` — three caches, three clocks, three different savings
What a 304 carries	`status line and headers, no body at all`	Reading 304 as a failure. It is a success meaning your stored copy is still correct.
Same LAN, what changes	`ARP resolves the destination itself · no gateway, no router, no NAT`	Still sending the frame to the gateway. The mask decided this, nothing else did.
Which delay a faster link reduces	`transmission delay only`	`expecting propagation to fall` — that is distance over signal speed
Which layer to test first	`the lowest one`, because a link fault explains every symptom above it	Starting at the application, where a DNS fault and a dead server look identical.

Six tables, one journeyDNS turns the name into an address, the routing table turns the address into a next hop, the ARP cache turns the next hop into a MAC, the switch table turns the MAC into a port, the NAT table turns your private tuple into a public one, and the socket table turns the destination port into a process. Naming which table is being read is a better answer than describing what happens.

Seven round trips buy nothing yetOf the eight a cold visit needs, seven finish before the word GET is sent. At 85 ms of one-way propagation that is about 1.2 seconds during which the page has not been requested. This is why caching, keep-alive and TLS 1.3 are not optimisations but load-bearing.

MACs hop, IPs travelThe Ethernet header names one hop and is rewritten by every device that forwards the frame. The IP header names the two ends and survives the whole path. NAT is the single exception, and being able to state the rule and then volunteer its exception is what separates the two grades of answer.

06 Where & why

Four tools that print these stages back to you

None of this is a teaching abstraction. Every stage above has a command or a panel that shows it happening on your own machine, and each of the four below shows you something a written description leaves out.

Chrome DevTools

The Timing panel is this lesson with a stopwatch on it

Open the Network panel, click a request, choose Timing, and the breakdown reads Queueing, Stalled, DNS Lookup, Initial connection, SSL, Waiting (TTFB) and Content Download. Those are stages 3, 6, 8, 9 and 10 of the table above, with a millisecond figure attached to each. Reload the page and watch DNS Lookup, Initial connection and SSL all collapse to zero: that is the warm run in the console above, measured rather than argued. A row whose Size column reads (disk cache) never reached the network at all.

Linux ip route and dig

The routing decision and the DNS walk, printed

ip route get 198.51.100.7 does not guess: it runs the real longest prefix match and prints the interface, the next hop and the source address the kernel would use, which settles stage 4 in one line. ip neigh lists the ARP cache with each entry marked REACHABLE, STALE or INCOMPLETE, and an incomplete entry for the gateway is a layer-two fault you can see. dig +trace examate.in performs the iterative walk itself, printing the root referral, then the .in referral, then the authoritative answer, so stage 3 stops being three sentences and becomes three blocks of output.

Google Public DNS 8.8.8.8

The recursive resolver, and where the TTL comes from

This is the address that ends up in most machines’ resolver configuration, handed out by DHCP or typed in by hand. It is the box that turns your one recursive query into the three iterative ones, and it caches every answer it gets for the TTL the authoritative server set. So the first person on your network to visit a domain pays the full walk and everyone after them does not, which is why the same page can feel slow once and instant for a colleague. It answers on UDP 53 like any resolver, and also on DNS over TLS and DNS over HTTPS, which is the only way that stage stops being readable by anyone on the path.

Cloudflare

The address you resolved is not one machine

Run dig against a name behind Cloudflare and the address you get back is anycast: the same address is announced from hundreds of locations at once, and routing delivers you to whichever one is nearest. So the TCP and TLS handshakes of stages 6 and 8 terminate on an edge machine, not on the origin server, and the certificate the browser validates is Cloudflare’s. The cf-cache-status header on the response says whether the origin was involved at all. The TTL on such a name is usually 60 seconds or less, precisely so you can be steered somewhere else quickly.

Every stage of this journey exists because the stage before it produced the wrong kind of name. That is the sentence to carry out of the lesson. A URL is not an address, an address is not a next hop, a next hop is not a MAC, a MAC is not a port, and a private address is not routable. Each translation has its own table, its own cache and its own way of failing, and if you can say which table you are standing on you can always say what to check next.

07 Interview questions

The escalation, in the order it actually happens

They open with the whole journey and then probe wherever you were vaguest. These eleven are deliberately cross-layer rather than single-topic, because that is what this question tests and it is where the other lessons in the course do not help you. Name the protocol, the port and the addressing every time you can; an answer with 198.51.100.7:443 in it reads as understanding, and one without reads as recitation.

Walk me through what happens when you type a URL and press Enter.

In stages, naming the layer each time. The browser parses the URL into scheme, host and path, and checks its own HTTP cache, its DNS cache, the hosts file and the OS resolver cache. On a miss, DNS resolves examate.in over UDP port 53: recursive to your resolver, which then walks root, then the .in TLD, then the authoritative server. With the address in hand the kernel does a longest prefix match in its routing table, finds the destination off-link and picks the default gateway. ARP broadcasts for the gateway’s MAC. Then TCP completes its three way handshake to port 443, TLS 1.3 completes its handshake in one more round trip, and only then does the HTTP GET travel inside the encrypted channel. The response comes back, is decapsulated by Ethernet, IP, TCP and TLS in turn, and the browser renders. Somewhere on the way out the router rewrote your source address and port, because a private address is not routable.

Whose MAC address does ARP ask for, and why is it not the server’s?

The next hop’s, which for an off-link destination is the default gateway. ARP is a broadcast and a broadcast does not cross a router, so a host can only ever resolve something inside its own broadcast domain. The server is thousands of kilometres away and is unreachable by broadcast, so asking for its MAC could never be answered. The frame therefore leaves with destination IP 198.51.100.7 and destination MAC 00:1A:A0:00:00:FE, which belong to two different machines, and that apparent mismatch is the correct and intended state. If the destination had been on the same subnet, ARP would have asked for the destination itself and no router would have been involved.

The packet crosses a dozen routers. What is different in its headers at the last hop compared with the first?

Both MAC addresses are completely different, because each router strips the frame it received and builds a new one for the next link, so the Ethernet header names one hop and is rewritten at every one of them. Both IP addresses are unchanged, because the IP header names the two ends and is meant to survive the whole path. Two other fields do change at every hop and are worth volunteering: the IPv4 TTL is decremented by one, and because the TTL sits inside the header the header checksum has to be recomputed. The one exception to the IP rule is NAT, which rewrote the source address and source port once, at the boundary of your own network.

How many round trips before the first byte of HTML arrives, and what is each one for?

Eight on a cold visit, and only the last carries page content. Four for DNS: one from your machine to the resolver, and three more while the resolver asks a root server, a TLD server and the authoritative server, all of which happen inside your wait. One for the ARP exchange on your own link. One for the TCP three way handshake, since the SYN goes out and the SYN-ACK comes back before you may send anything. One for the TLS 1.3 handshake, which would be two on TLS 1.2. One for the request and its response. So seven complete before the word GET is even sent, and that is the number that makes DNS caching, connection reuse and TLS 1.3 feel necessary rather than academic.

You reload the page. What is different the second time?

Three separate caches act and they save three different things. The DNS cache still holds the address for the remainder of its TTL, so stages 3 to 5 do not happen at all and four round trips vanish. The TCP connection was never closed, because Connection: keep-alive is the HTTP/1.1 default, so there is no handshake and no TLS negotiation, and two more round trips vanish along with the ARP exchange. The HTTP cache holds the page: if it is still inside its max-age no request is made at all, and if it is stale the browser sends a conditional GET with If-None-Match and gets back 304 Not Modified with no body. Naming all three separately, with what each removes, is what distinguishes this answer from “it comes from the cache”.

What if the site is on the same LAN as me?

The routing lookup changes and everything follows from that. The destination now matches the 192.168.1.0/24 row, which is more specific than the default route, so the destination is its own next hop. ARP therefore broadcasts for the destination itself rather than for the gateway, and the frame carries the destination host’s own MAC address. No router is involved at all, so nothing decrements the TTL and nothing rewrites anything, which means no NAT. DNS still runs unless the name is in the hosts file or answered by mDNS. The round trip time drops from tens of milliseconds to well under one. And the only thing that decided all of this is whether the destination, ANDed with the subnet mask, matches the host’s own network number.

One field is rewritten on the way out and rewritten back on the way in. Which, and by what?

The source address and source port, rewritten by NAT on the boundary router. Your laptop is 192.168.1.10, which is a private address that no router on the Internet will forward, so the router substitutes its own public 203.0.113.5 and a port of its choosing, and stores one row mapping the two. The server therefore answers the public pair and has no idea your laptop exists. When the reply arrives the router reads that row backwards and restores the original destination before sending it in. This is the only point in the whole journey where an IP address changes, which is why it is worth naming as the exception rather than leaving it as a contradiction.

I typed http:// instead of https://. What changes in the journey?

The default port becomes 80 instead of 443, and the entire TLS handshake stage disappears, so a cold visit costs one round trip fewer, or two fewer against TLS 1.2. Everything else is identical: the same DNS lookup, the same routing decision, the same ARP, the same TCP handshake, the same HTTP message. What you lose is all three of what TLS provides: confidentiality, so anyone on the path reads the method, the path, the headers and the body; integrity, so anyone on the path can alter them undetected; and authentication, so nothing proves you reached the site you named. In practice most sites answer a plain HTTP request with 301 Moved Permanently to the https URL, so you pay for the plaintext round trip and then do the whole journey again anyway.

Where is the time actually going, and which of the delay components does a faster link reduce?

Only the transmission delay, which is the number of bits divided by the link rate and is the time to push the data onto the wire. It is usually the smallest of the four for a page like this. Propagation delay is distance divided by the signal speed in the medium and a faster link does not touch it, which is why every round trip costs the same whether you are on 10 Mbit/s or 1 Gbit/s. Queuing delay is time spent waiting in a router buffer and rises sharply as a link approaches saturation. Processing delay is the per-hop work of checking headers and looking up routes. For a cold page load, the total is dominated by the number of round trips multiplied by the propagation delay, which is exactly why removing round trips is the lever that works and buying bandwidth often is not.

Something is broken and you have no idea where. Which layer do you test first?

Hard

The site is moved behind a CDN. The name now resolves to an anycast address announced from hundreds of locations, TLS terminates on an edge machine, and that edge holds the page in its own cache. Go through the fourteen stages of the cold run and say which disappear, which stay unchanged, and which stay but terminate somewhere different. Then give the number of round trips a cold visitor still needs before the first byte when the edge already has the page, compare it with the number in this lesson, and say what has to have got smaller instead for the page to arrive sooner.

Follow-up

Not one round trip is removed, so whatever made the page faster is not in the count. Work out what a CDN is able to change about a round trip once it cannot change how many there are.

Show the hint

Write the total wait as a number of round trips multiplied by something, then settle which of those two factors moved.