The two questions are drawing practice. The first draws the messages of a DNS lookup
when the local DNS server already has the .com TLD server's address cached. The second
draws one persistent HTTP connection from the TCP handshake that opens it to the messages that close
it, and asks what non-persistent HTTP would add.
The tree is the DNS hierarchy §2.4.2. At the top is a root
server. Below it are the top-level-domain (TLD) servers, one set per ending such as
.com. At the bottom are the authoritative servers, each run by an organisation and
holding the real addresses for its own names; the one this question is about,
example.com's, has the heavier outline.
The dashed box, the local DNS server, is not part of the tree. It is run by the laptop's ISP or campus, and it asks the tree on the laptop's behalf. With iterated queries, every server it asks replies straight back to it, either with the address or with a pointer: the name and address of a server lower down the tree that knows more. The Weeks 1–4 guide called a pointer a referral.
A laptop wants the IP address of www.example.com. It sends every DNS
question to its local DNS server, which resolves names with iterated queries. An earlier
lookup left the .com TLD server's address in the local server's cache; nothing else
about example.com is cached.
Draw every DNS message, from the laptop's question until the laptop has the address. One arrow per message, with an arrowhead. Label each arrow Q if it carries the question, P if it carries a pointer to another server, or A if it carries the address.
Which server on the timeline is never contacted, and why not?
.com TLD server — so what can that server tell it about example.com: the
address itself, or who to ask next? Draw one arrow out and one arrow back for each server the local
server asks.1Six arrows: Q Q P Q A A
The five lifelines from the question, with time running downward and one arrow per DNS message, numbered in order and labelled with the letter the question asked for. The root's line is greyed because no message reaches it.
The laptop sends one question to its local server (1) and gets one answer back (6); those are its
only two arrows. Everything between them is the local server walking down the tree. Because it
already has the .com TLD server's address, it asks that server first (2). The TLD
server does not know www.example.com's address — it only knows which server is
authoritative for example.com — so it replies with a pointer (3). The local server
asks that authoritative server (4), which replies with the address (5), and the local server passes
it to the laptop (6).
If you drew arrows from the laptop to the TLD or authoritative server, you had the laptop doing the walk itself. The laptop asks its local server for the finished answer and waits; it is the local server's queries that are iterated §2.4.2.
If you labelled the TLD server's reply A, you gave it knowledge it does not
have. A TLD server knows which server is responsible for each name under .com, not the
addresses inside them; only the authoritative server can say A.
2The root
In this lookup the root's only job would be to say where the .com TLD server is, and
the local server already has that in its cache. A cache lets the local server start as far down
the tree as it already knows §2.4.2. A trip to the root would only have
returned a pointer the local server was already holding.
The worksheet left out how long a cached entry lasts: once its time-to-live expires, the local
server forgets the .com pointer and must ask the root again.
§2.4 The Domain Name System · video · knowledge checks · practice problems
Figures after the authors' Chapter 2 and Chapter 3 slides, copyright © 1996–2025 J.F. Kurose and K.W. Ross.
HTTP runs over a TCP connection, so before the browser can send a request a connection has to be opened, with the three-message handshake from the TCP worksheet §3.5.6. Persistent HTTP §2.2.2 means the browser leaves that connection open after a response and sends its next request on it, so the connection is opened once and closed once for the whole page. Non-persistent HTTP closes the connection after every response.
The laptop now knows the web server's address. The browser loads
http://www.example.com/, a page with one image, logo.png. It opens
one persistent TCP connection, sends one request at a time — waiting for each response
before sending the next — and, once it has the image, closes the connection. Ignore the ACKs
TCP sends for data.
Draw every message, from the first TCP message until the connection is closed. One arrow per message, with an arrowhead, labelled with the TCP flags or HTTP message it carries.
How many of your arrows carry no HTTP at all? What is each group of them for?
Suppose the browser used non-persistent HTTP instead. What would you have to add to your drawing?
GET can be sent? And how does the browser
find out that logo.png exists at all?FIN says
about its sender, and whether one side can say that on the other side's behalf.1Eleven arrows
Two diagrams with the same spacing: in each, the laptop is the left line, the web server the right, time runs downward, and every arrow is one message labelled with what it carries. The brackets on the right group the arrows by job: opening the TCP connection, the HTTP requests and responses, and closing the connection.
The left diagram is the answer to part 1. The right is part 3: the same page loaded with non-persistent HTTP, where the server closes the connection after each response.
Three arrows open the connection (SYN, SYN-ACK, ACK). Then
come two request–response pairs, and the order matters: the browser cannot send
GET /logo.png until the HTML has arrived, because it only learns the image exists by
reading the page. Last, four arrows close the connection: a FIN and an
ACK in each direction.
Two merges are also correct. The laptop's GET / can ride on its handshake
ACK, making arrows 3 and 4 one; and the server can combine its ACK of the
laptop's FIN with its own FIN, making arrows 9 and 10 one
§3.5.6.
If you drew a GET before the handshake, there was nothing to send it on. HTTP hands its request to TCP, and TCP has no connection until the third handshake message.
If you sent GET /logo.png before the HTML arrived, ask how the browser knew to ask for it. One request at a time means each request waits for the response before it, and this one also depends on what that response contains.
If you closed with a single FIN, you closed only one direction. A
FIN says "I have nothing more to send"; the other side may still have data on its way,
so it keeps its direction open until it is done and then sends its own FIN. Each
FIN is acknowledged so its sender knows it arrived.
2Seven: three to open, four to close
Three arrows open the connection: they establish that both sides are there and agree on each
side's starting sequence number. Four close it, one FIN and one ACK in
each direction. Only the other four carry HTTP. If you merged arrows as described above, your count
is lower by one for each merge.
3A whole second connection for the image
Close the first connection once the HTML has arrived; then open a new one, with another
SYN, SYN-ACK and ACK, before GET /logo.png; and
close that one too after the image arrives (Figure 2, right). Every object pays for its own
handshake and its own close.
The worksheet left out the ACKs TCP sends for the data itself. Every response here would be acknowledged by the laptop, and a large one would be split across several segments, each with its own sequence number §3.5.2.
§2.2 The Web and HTTP · §3.5 Connection-oriented Transport: TCP · video 2.2 · video 3.5 (part 2) · knowledge checks · practice problems
GW CSCI 4431/6431 Computer Networks · Timeline Worksheet