Putting It Together: The Complete Journey of a Web Request

The Scenario

Having studied the application, transport, network, and link layers, let us tie them together and see what happens behind one of the most common actions: a student, Bob, plugs his laptop into the campus Ethernet switch and types www.example.com into his browser.

The campus network is the subnet 198.51.100.0/24. Its gateway router has the address 198.51.100.1 and also runs the DHCP server. The campus connects to the Internet through an ISP, which hosts a DNS server at 203.0.113.53; the web server www.example.com has the address 192.0.2.80 and lives in another network.

Step 1: DHCP, Getting an IP Address

When it first connects, Bob's laptop has no IP address and can do nothing. The operating system creates a DHCP request message and places it in a UDP segment with source port 68 and destination port 67, then in an IP datagram with source address 0.0.0.0 and destination 255.255.255.255, and finally in an Ethernet frame with destination MAC address FF:FF:FF:FF:FF:FF. The switch floods this broadcast frame out of all its ports, and the DHCP server running on the gateway router receives it and replies with a DHCP ACK containing Bob's IP address, the subnet mask, the default gateway's address, and the DNS server's address. The switch learned Bob's port when it forwarded the first frame, so the reply goes only to Bob. (A complete DHCP exchange has four messages, discover, offer, request, and ACK; only one round trip is shown here.)

Step 2: DNS and ARP, Finding the Web Server

Before the browser can open a TCP connection to www.example.com, it needs that server's IP address, so the operating system builds a DNS query and places it in a UDP segment to port 53 and an IP datagram addressed to the DNS server. The DNS server is not in Bob's subnet, so the datagram must first go to the default gateway, but Bob knows only the gateway's IP address, not its MAC address. So Bob first broadcasts an ARP query, and the gateway tells Bob its MAC address in an ARP reply.

Now the DNS query is sent in a frame addressed to the gateway's MAC address. The gateway router forwards the datagram toward the ISP according to its forwarding table, which was computed by an intra-domain routing protocol (such as OSPF) and the inter-domain routing protocol BGP. The DNS server finds that www.example.com is 192.0.2.80 and sends the DNS answer back to Bob along the reverse path.

Step 3: TCP and HTTP, Fetching the Page

With the web server's IP address in hand, the browser creates a TCP socket and starts the three-way handshake with port 80 of 192.0.2.80: the SYN segment travels hop by hop through the routers to the server, the server replies with a SYNACK, Bob answers with an ACK, and the connection is established. The browser then sends an HTTP GET request over the connection, the server returns the page in an HTTP response, and the browser finally displays it on the screen.

Throughout this process, the frame on every link is different: each router strips the frame it receives, consults its forwarding table, and builds a new frame for the next link, so the source and destination MAC addresses change link by link, and the TTL in the IP header drops by one at every hop. The source and destination IP addresses and port numbers, by contrast, stay the same all the way (assuming no NAT on the path). Switches are transparent to hosts: they look only at the Ethernet header and do not change the frame.

Summary

A simple page visit uses many protocols: DHCP, ARP, DNS, UDP, TCP, HTTP, IP, OSPF/BGP, Ethernet, and more. Each layer does only its own job and, through encapsulation, passes the data handed down from the layer above to the layer below: the application layer cares about the contents of messages, the transport layer delivers messages to the right process, the network layer moves datagrams from the source host to the destination host, and the link layer carries frames across each individual link. It is this layered design that lets so many different networks form one unified Internet.