In this section we will do a complete step-by-step walk-through of a
traffic example, showing which steps that a computer will go through
when it wants to communicate over a computer network.
This example will incorporate a lot of information from the other
sections and serves as an all-inclusive example.
In the example below we will display a small home network where a
computer has just booted up.
The computer has a manually configured IP address, and has not yet
communicated on the network.
A user sits down by the computer and opens up a Web Browser and
tries to browse to www.iis.se
This image shows the network topology in the example.
Within a lot of the steps, we will zoom in on just the most relevant
part of the network to avoid having to draw the whole picture every
single time.
Now let’s start with the traffic example walk-through!
1.3.1 Step 1: The computer wants to
send traffic
A computer connected to the home network has just booted up.
The computer has a manually configured IP address, Subnet Mask, DNS
server and a Default Gateway.
Both the DNS server and the Default Gateway address is pointing at
the LAN IP address of the home router.
The user of the computer opens a web browser and goes to
www.iis.se
The first thing that happens is that the Web Browser instructs the
OS on the computer to set up the communication between the computer and
www.iis.se
1.3.2 Step 2: DNS
This part is divided into numerous sub-steps
1.3.2.1 Step 2a: DNS cache
The computer OS checks its DNS cache to see if it already knows the
IP address of www.iis.se
Since the computer just started up, and it hasn’t previously
contacted www.iis.se, the DNS cache is completely empty.
The computer must now ask its DNS server what IP address that www.iis.se
has.
1.3.2.2 Step 2b: Putting a DNS
query together
The computer will construct a DNS query that it can send off to the
DNS server, 192.168.1.1, that it was pre-configured to use.
The destination address of the DNS query is 192.168.1.1, and the
source IP address is the IP address of the computer itself,
192.168.1.5
DNS uses UDP as its transport protocol.
The destination port for DNS queries is 53/UDP.
Later when the DNS query reaches the DNS server, the DNS server will
be able to tell by looking at the destination port 53/UDP that the
message is intended for a DNS server program, and can forward the
message to the running DNS program.
The computer OS must also randomize a source port which is also
written into the message.
But when the computer puts the DNS query together, it notices that
it must check what destination MAC address that it should send the
packet to.
So for now, the OS puts the packet in a queue in memory, and then
starts working on figuring out what destination MAC address to use.
1.3.2.3 Step 2c: Check the ARP
table for a valid MAC address
The computer will now check its ARP table, to see if it knows what
MAC address that is associated with the IP address of the router,
192.168.1.1
But the computer has a completely empty ARP table, since it just
booted up, and hasn’t yet learned any ARP entries.
Computer checks its ARP table:
1.3.2.4 Step 2d: ARP request to the
network
Now the computer must construct an ARP request to the rest of the
network.
The request will be sent to destination MAC address
FF:FF:FF:FF:FF:FF, which is the broadcast address.
The result is that every other computer and device on the LAN will
receive the request, and read the contents.
The home router receives the ARP request, and reads the message,
since the request is sent to the broadcast MAC address
FF:FF:FF:FF:FF:FF
The home router can see in the message that the computer is asking
for the MAC of the device with IP address 192.168.1.1.
Because the router is configured to use that IP address, the home
router will respond to this message by constructing an ARP reply, and
then sending it back to the computer.
1.3.2.5 Step 2e: ARP reply from the
router
When the ARP reply is received by the computer, the OS will read the
reply.
It will enter the reply into its ARP table, to remember for a few
minutes which MAC address that is associated with 192.168.1.1
Now the computer finally has gathered all the information it requires to
be able to send off the DNS message.
1.3.2.6 Step 2f: Send off the DNS
query
The DNS query is now going to be sent from the computer to the DNS
server, which exists as a service that is running on the home router
192.168.1.1
The home router receives the query, sees that it is a DNS query
aimed at the router’s own IP address and MAC address, and understands
that it must handle this DNS query and send back an answer.
1.3.2.7 Step 2g: The home router
checks its DNS cache
The home router is a DNS server, but it is also dependent on other
DNS servers on the Internet.
The home router can’t know every single DNS address host/IP binding
on the Internet.
Instead, it will ask those DNS servers that are responsible for
different domains (such as example.com) as needed.
The home router also has a DNS cache, just like the computer.
Every time the home router handles a DNS query from a computer, it
will also save the DNS reply in its own DNS cache for some time.
This is to avoid having to handle the same DNS queries over and
over, thus speeding up response time.
In this case, the home router has not received any question about
www.iis.se in a long time, so it doesn’t exist in the DNS cache on the
router.
Therefore, the router must ask its configured DNS servers on the
Internet to answer this DNS query.
1.3.2.8 Step 2h: The home router
prepares and sends away its DNS query
Now the router prepares a DNS query that it will send to its DNS
server.
The router learned about available DNS servers via DHCP from the
Internet Service Provider when the home router first booted up, and
received its own public IP address from the ISP.
So the home router will prepare a DNS query for transmission by
putting the query inside a UDP message with destination port 53/UDP, and
a random UDP source port.
It will then put the message inside an IP packet.
The IP packet is sent from the home router’s public IP address, to
the DNS server address.
Home router sends a DNS query
When the home router has prepared the packet, and is ready to send
it, then the home router will look in its routing table, to see which
way it should send the packet.
It can see in the routing table
that the best path to the inside LAN 192.168.1.0 is via the LAN
ports, but
this externally directed packet should be sent to another IP network
on the Internet.
So the home router picks the WAN port as the best destination.
At this stage of the process, it is possible that the home router
would have to perform an ARP request to find out which MAC address of
the next hop router 115.20.97.113, but we assume that the home router
already has this information in its ARP cache.
1.3.2.9 Step 2i: The DNS query is
routed over the Internet
Here a number of steps have been somewhat simplified and
shortened.
Each router on the Internet that receives the DNS request will
perform the following:
Receive the packet
Looks at the destination IP address to see where the packet is
going
Looks in its routing table to see which path that is best for the
packet
Removes the old MAC addresses from the packet and adds new
ones.
It will use its own MAC address on the outbound interface as the
Source MAC address for the traffic, and will put the next-hop router’s
MAC address as the destination MAC address
Sends off the packet to the next hop router
1.3.2.10 Step 2j: The DNS server
responds
Eventually, the packet reaches the DNS server, which will handle the
packet and prepare a response.
Just like a regular computer, the server has an IP address, a Subnet
Mask, and a Default Gateway.
So, it works in much the same way as a regular computer.
The DNS server replies back to the Home Router
1.3.2.11 Step 2k: The home router
can send a DNS reply to the computer
Now after receiving the DNS reply from the DNS server, the home
router can finally create a DNS reply, and send it to the computer, to
let the computer know which IP address that www.iis.se has.
1.3.3 Step 3: The computer sets up
a session to www.iis.se
During this part, a lot of things happen at once.
Mainly the computer will initialize something called a “TCP 3-way
Handshake” which is a setup phase of TCP communication that consists of
three messages between the computer and the server.
When TCP is being used, as is the case with web browsing, TCP sets
up a reliable connection, which includes setting up a session via a
handshake.
This is done to prepare the server for an incoming session, and to
decide which ports that should be used for the communication.
The TCP 3-way Handshake consists of three messages:
The first one is sent from the computer, and is called “SYN” which
stands for Synchronize.
It lets the other side know that we want to Synchronize settings for
a TCP session.
The message also contains the random source TCP port that the
computer has chosen.
The second message is the reply back from the server and is called
“SYN-ACK”, which stands for Synchronize Acknowledgment.
This simply means that the server acknowledges that it received the
message and that it also is prepared to set up a session for
communication
The third message is sent by the computer and finalizes the session
by sending “ACK” or Acknowledgment.
This means that everything is now fully prepared.
The computer has the correct ARP information for the IP address of
the home router in its ARP cache.
So the computer can send off any packets it wants to the Internet
via the home router without first having to go through ARP lookups.
But this is also the first time so far in this example that the
computer wants to communicate directly with something that is located
beyond the router.
The TCP 3-way handshake will take place directly between the
computer and the Web Server on the Internet.
Earlier during the DNS lookup process, the computer just talked with
the Home Router.
The home router, in turn, talked with the DNS servers on the
Internet.
But no communication was traveling directly between the computer and
any IP address on the Internet.
The difference is that now that the computer wants to communicate
directly with something on the Internet then the home router has to
perform Address Translation for the traffic.
1.3.3.1 Step 3a: The computer sends
a TCP SYN message
Here we take a closer look at what happens when the computer is
establishing the TCP session by initializing the TCP 3-way
handshake.
To do so, the computer OS will randomize a TCP source port that it
will use for the communication.
Then it assembles the TCP SYN message and sends it to the Web
Server.
The TCP message doesn’t contain any other data.
It is just an empty TCP message.
When the TCP SYN message passes through the router, the router will
perform NAT on the message.
The router will also save information about the performed NAT in its
NAT table, so that it can keep track of the session, and perform reverse
NAT on any replies.
The picture shows a TCP SYN traveling from the computer to the web
server:
“I would like to Synchronize a TCP session with you”
1.3.3.2 Step 3b: The Web Server
replies with TCP SYN-ACK
Here you can see the returning TCP SYN-ACK response from the Web
Server to the computer:
“Okay, I’m good to set up a session and I confirm that I got your
message”
The packet matches the NAT table entry on the router, so that the router
can see which LAN computer it should forward the packet to and how it
should perform NAT on the packet.
1.3.3.3 Step 3c: The computer sends
a TCP ACK
Finally, a TCP ACK is sent from the computer to the Web Server
“Then I confirm that we have established a session!”
As long as the computer and the server keep on communicating with
each other, they will keep using the same session for the
communication.
This also includes using the same TCP ports, which lets all devices
along the way keep track of the session, the address translation, and so
on.
The session could last just long enough to download the web page, or
the web server and the computer could choose to keep the session alive
for longer, in case the user wants to keep browsing around on that web
page.
1.3.4 Step 4: The web browser talks
with the Web Server
Once the TCP session is established by the OS, then the OS will let
the Web Browser know that it is now alright for it to start
communicating with the Web Server.
The web browser will communicate by using the HTTP protocol, which
is the standard protocol for transferring web pages on the Internet
DayInLifeOfPacket/http-session.jpg
From now on the computer and the server can communicate with each
other to transmit the web pages until they are done.
Then they can choose to end the session, either with a graceful
termination using FIN-ACKs, or by sending a so-called TCP RESET message
if they want, which lets all devices know that the session has now
ended.
1.4 Traffic example 2:
Now that we’ve covered the link layer in this chapter, and the
network, transport and application layers in earlier chapters, our
journey down the protocol stack is complete!
In the very beginning, we wrote “much of this class is concerned
with computer network protocols,” and in the first five chapters, we’ve
certainly seen that this is indeed the case!
Before heading into the topical chapters in second part of this
book, we’d like to wrap up our journey down the protocol stack by taking
an integrated, holistic view of the protocols we’ve learned about so
far.
One way then to take this “big picture” view is to identify the many
(many!) protocols that are involved in satisfying even the simplest
request: downloading a Web page.
We illustrate our setting:
a student, Bob, connects a laptop to his school’s Ethernet switch
and downloads a Web page (say the home page of www.google.com).
As we now know, there’s a lot going on “under the hood” to satisfy
this seemingly simple request.
A Wireshark lab at the end of this chapter examines trace files
containing a number of the packets involved in similar scenarios in more
detail.
(open this image tiled to one side, with text to the other side).
1.4.1 Getting Started: DHCP, UDP,
IP, and Ethernet
Let’s suppose that Bob boots up his laptop and then connects it to
an Ethernet cable connected to the school’s Ethernet switch, which in
turn is connected to the school’ s router.
The school’s router is connected to an ISP, in this example,
comcast.net. In this example, comcast.net is providing the DNS service
for the school;
thus, the DNS server resides in the Comcast network, rather than the
school network.
We’ll assume that the DHCP server is running within the router, as
is often the case.
When Bob first connects his laptop to the network, he can’t do
anything (e.g., download a Web page) without an IP address.
Thus, the first network-related action taken by Bob’s laptop is to
run the DHCP protocol to obtain an IP address, as well as other
information, from the local DHCP server:
The operating system on Bob’s laptop creates a DHCP request message,
and puts this message within a UDP segment, with destination port 67
(DHCP server) and source port 68 (DHCP client).
The UDP segment is then placed within an IP datagram, with a
broadcast IP destination address (255.255.255.255) and a source IP
address of 0.0.0.0, since Bob’s laptop doesn’t yet have an IP
address.
The IP datagram containing the DHCP request message is then placed
within an Ethernet frame.
The Ethernet frame has a destination MAC addresses of
FF:FF:FF:FF:FF:FF so that the frame will be broadcast to all devices
connected to the switch (hopefully including a DHCP server);
the frame’s source MAC address is that of Bob’s laptop, 00:
16:D3:23:68:8A.
The broadcast Ethernet frame containing the DHCP request is the
first frame sent by Bob’s laptop to the Ethernet switch.
The switch broadcasts the incoming frame on all outgoing ports,
including the port connected to the router.
The router receives the broadcast Ethernet frame containing the DHCP
request on its interface with MAC address 00:22:6B:45:IF:1B and the IP
datagram is extracted from the Ethernet frame.
The datagram’s broadcast IP destination address indicates that this
IP datagram should be processed by upper layer protocols at this node,
so the datagram’ s payload (a UDP segment) is thus de-multiplexed up to
UDP, and the DHCP request message is extracted from the UDP
segment.
The DHCP server now has the DHCP request message.
Let’s suppose that the DHCP server running within the router can
allocate IP addresses in the CIDR block 68.85.2.0/24.
In this example, all IP addresses used within the school are thus
within Comcast’s address block.
Let’s suppose the DHCP server allocates address 68.85.2.101 to Bob’
s laptop.
The DHCP server creates a DHCP ACK message containing this IP
address, as well as the IP address of the DNS server (68.87.71.226), the
IP address for the default gateway router (68.85 .2.1), and the subnet
block (68.85.2.0/24) (equivalently, the “network mask”).
The DHCP message is put inside a UDP segment, which is put inside an
IP datagram, which is put inside an Ethernet frame.
The Ethernet frame has a source MAC address of the router’ s
interface to the home network (00:22:6B:45:1F:IB) and a destination MAC
address of Bob’ s laptop (00: 16:D3:23:68:8A).
The Ethernet frame containing the DHCP ACK is sent (unicast) by the
router to the switch.
Because the switch is self-learning and previously received an
Ethernet frame (containing the DHCP request) from Bob’ s laptop, the
switch knows to forward a frame addressed to 00:16:D3:23:68:8A only to
the output port leading to Bob’ s laptop.
Bob’s laptop receives the Ethernet frame containing the DHCP ACK,
extracts the IP datagram from the Ethernet frame, extracts the UDP
segment from the IP datagram, and extracts the DHCP ACK message from the
UDP segment.
Bob’ s DHCP client then records its IP address and the IP address of
its DNS server.
It also installs the address of the default gateway into its IP
forward- ing table.
Bob’s laptop will send all datagrams with destination address
outside of its subnet 68.85 .2.0/24 to the default gateway.
At this point, Bob’ s laptop has initialized its networking
components and is ready to begin processing the Web page fetch.
(Note that only the last two DHCP steps of the four presented in
Chapter 4 are actually necessary.)
1.4.2 Still Getting Started: DNS
and ARP
When Bob types the URL for www.google.com into his Web browser, he
begins the long chain of events that will eventually result in Google’s
home page being displayed by his Web browser.
Bob’s Web browser begins the process by creating a TCP socket that
will be used to send the HTTP request to www.google.com.
In order to create the socket, Bob’s laptop will need to know the IP
address of www.google.com.
We learned that the DNS protocol is used to provide this
name-to-IP-address translation service.
The operating system on Bob’s laptop thus creates a DNS query
message, putting the string “www.google.com” in the question section of
the DNS message.
This DNS message is then placed within a UDP segment with a
destination port of 53 (DNS server).
The UDP segment is then placed within an IP datagram with an IP
destination address of 68.87.71.226 (the address of the DNS server
returned in the DHCP ACK in step 5) and a source IP address
of68.85.2.101.
Bob’s laptop then places the datagram containing the DNS query
message in an Ethernet frame.
This frame will be sent (addressed, at the link layer) to the
gateway router in Bob’ s school’s network.
However, even though Bob’s laptop knows the IP address of the
school’s gateway router (68.85.2.1) via the DHCP ACK message in step 5
above, it doesn’t know the gateway router’s MAC address. In order to
obtain the MAC address of the gateway router, Bob’s laptop will need to
use the ARP protocol.
Bob’s laptop creates an ARP query message with a target IP
address of 68.85.2.1 (the default gateway), places the ARP message
within an Ethernet frame with a broadcast destination address
(FF:FF:FF:FF:FF:FF) and sends the Ethernet frame to the switch, which
delivers the frame to all connected devices, including the gateway
router.
The gateway router receives the frame containing the ARP query
message on the interface to the school network, and finds that the
target IP address of 68.85.2.1 in the ARP message matches the IP address
of its interface.
The gateway router thus prepares an ARP reply, indicating that its
MAC address of 00:22:6B:45: IF: 1B corresponds to IP address 68.85
.2.1.
It places the ARP reply message in an Ethernet frame, with a
destination address of 00:l6:D3:23:68:8A (Bob’s laptop) and sends the
frame to the switch, which delivers the frame to Bob’s laptop.
Bob’s laptop receives the frame containing the ARP reply message
and extracts the MAC address of the gateway router (00:22:6B:45:1F:1B)
from the ARP reply message.
Bob’s laptop can now (finally!) address the Ethernet frame
containing the DNS query to the gateway router’ s MAC address.
Note that the IP datagram in this frame has an IP destination
address of 68.87 .71.226 (the DNS server), while the frame has a
destination address of 00:22:6B:45:IF:1B (the gateway router).
Bob’s laptop sends this frame to the switch, which delivers the
frame to the gateway router.
1.4.3 Still Getting Started:
Intra-Domain Routing to the DNS Server
The gateway router receives the frame and extracts the IP
datagram containing the DNS query.
The router looks up the destination address of this datagram
(68.87.71.226) and determines from its forwarding table that the
datagram should be sent to the leftmost router in the Comcast network in
Figure 6.32.
The IP datagram is placed inside a link-layer frame appropriate for
the link connecting the school’s router to the leftmost Comcast router
and the frame is sent over this link.
The leftmost router in the Comcast network receives the frame,
extracts the IP datagram, examines the datagram’s destination address
(68.87.71.226) and determines the outgoing interface on which to forward
the datagram toward the DNS server from its forwarding table, which has
been filled in by Comcast’s intra-domain protocol (such as RIP, OSPF or
IS-IS) as well as the Internet’s inter-domain protocol, BGP.
Eventually the IP datagram containing the DNS query arrives at
the DNS server.
The DNS server extracts the DNS query message, looks up the name
www.google.com in its DNS database, and finds the DNS resource record
that contains the IP address (64.233.169.105) for www.google.com.
(assuming that it is currently cached in the DNS server).
Recall that this cached data originated in the authoritative DNS
server for www.google.com.
The DNS server forms a DNS reply message containing this
hostname-to-IP- address mapping, and places the DNS reply message in a
UDP segment, and the segment within an IP datagram addressed to Bob’s
laptop (68.85.2.101).
This datagram will be forwarded back through the Comcast network to
the school’s router and from there, via the Ethernet switch to Bob’s
laptop.
Bob’s laptop extracts the IP address of the server www.google.com
from the DNS message.
Finally, after a lot of work, Bob’s laptop is now ready to contact
the www.google.com server!
1.4.4 Web Client-Server
Interaction: TCP and HTTP
Now that Bob’s laptop has the IP address of www.google.com, it
can create the TCP socket that will be used to send the HTTP GET message
to www.google.com.
When Bob creates the TCP socket, the TCP in Bob’s laptop must first
perform a three-way handshake with the TCP in www.google.com.
Bob’s laptop thus first creates a TCP SYN segment with destination
port 80 (for HTTP), places the TCP segment inside an IP datagram with a
destination IP address of 64.233.169.105 (www.google.com), places the
datagram inside a frame with a destination MAC address of
00:22:6B:45:1F:1B (the gateway router) and sends the frame to the
switch.
The routers in the school network, Comcast’s network, and
Google’s network forward the datagram containing the TCP SYN toward
www.google.com, using the forwarding table in each router, as in steps
14-16 above.
Recall that the router forwarding table entries governing forwarding
of packets over the inter-domain link between the Comcast and Google
networks are determined by the BGP protocol (Chapter 5).
Eventually, the datagram containing the TCP SYN arrives at
www.google.com.
The TCP SYN message is extracted from the datagram and
de-multiplexed to the welcome socket associated with port 80.
A connection socket is created for the TCP connection between the
Google HTTP server and Bob’s laptop.
A TCP SYNACK segment is generated, placed inside a datagram
addressed to Bob’s laptop, and finally placed inside a link-layer frame
appropriate for the link connecting www.google.com to its first-hop
router.
The datagram containing the TCP SYN ACK segment is forwarded
through the Google, Comcast, and school networks, eventually arriving at
the Ethernet card in Bob’s laptop.
The datagram is de-multiplexed within the operating system to the
TCP socket created in step 18, which enters the connected state.
With the socket on Bob’s laptop now (finally!) ready to send
bytes to www.google.com, Bob’ s browser creates the HTTP GET message
containing the URL to be fetched.
The HTTP GET message is then written into the socket, with the GET
message becoming the payload of a TCP segment.
The TCP segment is placed in a datagram and sent and delivered to
www.google.com as in steps 18-20 above.
The HTTP server at www.google.com reads the HTTP GET message from
the TCP socket, creates an HTTP response message, places the requested
Web page content in the body of the HTTP response message, and sends the
message into the TCP socket.
The datagram containing the HTTP reply message is forwarded
through the Google, Comcast, and school networks, and arrives at Bob’s
laptop.
Bob’s Web browser program reads the HTTP response from the socket,
extracts the html for the Web page from the body of the HTTP response,
and finally (finally!) displays the Web page!
1.4.5 Conclusions
Our scenario above has covered a lot of networking ground!
If you’ve understood most or all of the above example, then you’ve
also covered a lot of ground since you first started the class, where we
said “much of this book is concerned with computer network protocols”
and you may have wondered what a protocol actually was!
As detailed as the above example might seem, we’ve omitted a number
of possible additional protocols (e.g., NAT running in the school’s
gateway router, wireless access to the school’s network, security
protocols for accessing the school network or encrypting segments or
datagrams, network management protocols), and considerations (Web
caching, the DNS hierarchy) that one would encounter in the public
Internet.
We’ll cover a number of these topics and more in the second part of
this book.
Lastly, we note that our example above was an integrated and
holistic, but also very “nuts and bolts,” view of many of the protocols
that we’ve studied in the first part of this book.
The example focused more on the “how” than the “why.”
