Life of a Web Request
We all know that when we type a URL in the browser, it sends an HTTP request to the web server requesting the required page. The server in turn returns the page, if available and the browser finally displays it. Only, it’s not this simple, there is a lot more happening behind this simple web request. Let’s find out what actually happens!
DHCP — Identify yourself
You just joined the network, your machine needs an IP address to be identified in the network. The OS broadcasts out a DHCP request with multiple layers of encapsulation — UDP, IP and then Ethernet with destination IP 255.255.255.255 and MAC FF:FF:FF:FF:FF:FF and source IP 0.0.0.0 and source MAC as the client’s MAC.
The router broadcasts this request to all the devices in the network. Once the DHCP server receives the request, it allocates an IP to the machine and sends the ACK message containing the new IP, default gateway, IP of the DNS and the subnet mask.
ARP — Where do I send my requests?
Before resolving the URL, the machine must identify it’s gateway router’s MAC, it is aware of only the IP address from the DHCP reply. So, the machine constructs an ARP request destined to the router’s IP. This request is encapsulated in an Ethernet frame, broadcasted to FF:FF:FF:FF:FF:FF MAC address.
So the switch broadcasts this request throughout and once the gateway router receives it and matches the IP, replies with its MAC.
DNS — The machines do not recognize URLs
Now that the machine has the MAC address ready, it can start with the next step. The URL entered must be resolved into IP. If browser can find the URL’s record in the local DNS i.e. the DNS cache, it directly takes the IP from there, else it reaches out to the DNS server.
So the machine encapsulates the DNS request in UDP then further in Ethernet. The first hop router / the gateway router decapsulates the frame and extracts the IP. Using the forwarding table, the destination MAC i.e. of the DNS server is determined. The DNS query is forwarded to the DNS server.
From here on, the server handles the URL resolution by looking up its root, TLD and Name servers. If found, it includes the IP for the domain in the response as well as caches the results for further use. It sends back the reply encapsulated in UDP segment and then in Ethernet frame. Once the client machine receives the message, it decapsulates it and extracts the web server IP.
TCP — Establish connection with a handshake
The next step is establishing connection with the web server. First the client creates a TCP socket. Post this, it starts the TCP 3 way handshake. First, the client sends a SYN message with a segment and sequence number to server informing it that the clients wants to open a connection. The server then replies with SYN + ACK, acknowledging the connection request and includes the expected sequence number in the reply. Then finally, the client sends ACK acknowledging the server’s reply and sends the sequence number as well as the next sequence number expected from the server. The connection is now established and the actual data transfer begins now.
HTTP — You can now send your request
Finally, the actual data transfer is done using HTTP / HTTPS protocol. The client sends a HTTP GET request to retrieve data from the web server. If the requested resources are available, the servers sends them in the HTTP response. Typical resources shared via HTTP include, webpages — text/ html files, photos, videos, etc. Other resources are shared using different application layer protocols and each of them have standard port numbers. HTTP uses port 80, HTTPS uses 443. FTP protocol via ports 20, 21 can be used for file transfer. SMTP for mail transfer via port 25. Remote connection can be established via TELNET and SSH through ports 23 and 22.
Tying it all together!
That is what a day in the life of a web request seems like! Starting from fetching an IP address and network details upon starting the machine, followed by getting the web server’s address and finally sending it the request to displaying the requested page on your browser.
It travels through all the OSI layers with layer by layer encapsulation while using a variety of protocols at each layer. Once it finds the server’s IP and sends the request, the server decapsulates the received message at each layer and in turn responds with the requested resources.
Thanks for stopping by this article and I really hope you did find out something new and useful today 😊!
Have fun learning. See you next time! Until then check out my other stories at AskPranaviSree.
Byee!
