The Journey of an HTTP Request – From Client to the Server

Developers are known for working with HTTP requests. But have you ever wondered what happens in the background – when a button that performs an HTTP request is clicked to get a response from the server? 

The journey of an HTTP request from the client’s side to the server comprises multiple stages.

POV of the Client 

• Users interact with an application such as a web browser or a mobile application, and the former requests for an action that initiates the HTTP request.
• Once a user clicks on an action button, the client application prepares the HTTP request with all the required information ( for instance, URL, request body, headers, and request type).

DNS Resolution

• URL contains the domain name (eg: https://www.google.com), which is used for a user’s convenience because remembering IP addresses (such as 192.158.1.38) can be tough.
• Internet communication between two individuals occurs via numbers. These numerics are called an IP address.
• Every domain name is assigned to an IP address.
• The Internet DNS (Domain Name System) works like a phone book, which manages the mapping between the name and IP address.
• DNS resolution is the translation of the domain name into IP address.

How Does DNS Work – Internal Resolution

• The browser stores IP addresses for a specific domain name in its cache, but only if the request has been done from a browser’s end.
• If the IP address is not present in the cache, then it goes for DNS resolution.
• The browser sends a DNS query to the DNS resolver.
• The DNS resolver receives the query and initiates the process of resolving the domain name into an IP address.
• If the resolver has the IP address cached from previous queries, it can provide the IP address immediately without performing additional steps. This is known as “caching”.
• If not present in the cache, recursive queries to the Authoritative DNS server responsible for the domain begins.

• In the recursive resolution stage, the resolver queries the Root DNS server, which redirects to the Top Level Domain (TLD) of the requested domain name (eg: .com, .net, .org, etc).
• TLD stores the address information for the top level domains such as .com, .net, .org, etc.
• The resolver queries the TLD for the authoritative name server.
• Now, TLD redirects to the authoritative name server, which contains every detail about the IP address.
• Authoritative name server returns the IP address to the DNS resolver, and then stores the resolver cache for future references.
• Once the above steps are completed, the Destination IP address is achieved.

Transport Layer

• Once the target server’s IP address is known, the request is segmented into small packets.
• Before sending these packets to the server, the Transmission Control Protocol (TCP) establishes the connection with the server.
• The TCP 3-Way Handshake is used for connection establishment.
• TCP is a reliable, connection-oriented communication channel.

TCP Handshake

• The 3-Way Handshake involves exchange of SYN, SYN ACK, and ACK packets.
• Each packet contains the sequence number, initial sequence number (SYN) or acknowledge number, and flags to set either SYN or ACK or both ( SYN ACK).
• Once the connection has been established, the request is ready to be sent.

TLS(SSL) Handshake

• If the request uses HTTPS protocol, which is 443 port, then it needs to perform the TLS Handshake to check if the connection is secure.
• After the TCP connection is established, the client and server initiate the TLS Handshake over the TCP connection to establish the secure encrypted channel.
• TLS Handshake involves negotiation of encryption parameters, authenticating each other’s identities using digital certificates, and exchanging the cryptographic keys.
• Once the TLS Handshake is successfully completed, a secure TLS/SSL tunnel is established over the underlying TCP connection.

Data Transfer

• Let’s take a scenario. A request message fits in 3 packets. Each packet contains a header and a payload.
• The header includes metadata such as a source and a destination IP address, a protocol type, and a sequence of numbers and flags.
• The payload contains a portion of the HTTP message.
• These packets are transmitted to the server with the sequence number, and then require the acknowledgement from the server for each packet.
• If the second packet’s acknowledgement is not received, the TCP ensures to retransmit the second packet that fails to reach the destination.
• Usually, each packet takes different paths instead of the same route. This speeds up the process and reduces traffic.
• Each packet has information about how many packets are going to be received.

Server

• Once all the packets are received by the server, they are reassembled into the original HTTP message based on the packet sequence numbers.
• The server processes the request based on the specific request method and the URL.
• The server may perform various tasks such as retrieving data from the database and more.
• Finally, it will return the response to the client. 
• Once the response is received by the client, the TCP connection closes.