When you type a URL like google.com into your browser and hit Enter, a fascinating chain of events is set into motion. A request is sent to a server, and within seconds—thanks to a decent internet connection—you see the familiar white page with "Google" boldly written and a search bar in the center. But what exactly happens between hitting Enter and seeing the webpage? Let’s dive into the intricate processes that make this possible.
Step 1: DNS Resolution – Finding the Server’s Address
Before your browser can fetch the webpage, it needs to figure out where Google’s server is located. This process is known as Domain Name System (DNS) resolution.
What is DNS Resolution?
Computers don’t inherently understand human-readable domain names like google.com. Instead, they use IP addresses to locate servers on the internet. An IP address is a unique identifier for a computer or device on a network. Domain names are simply mnemonics to make it easier for humans to access websites without needing to remember complex numerical addresses. DNS acts like the internet’s phonebook, mapping domain names to their corresponding IP addresses so computers can locate web servers. For example, google.com might map to an IP address like 216.58.223.196.
How Does DNS Resolution Work?
When you enter google.com in your browser, the browser first tries to find its matching IP address. This is typically done in the following steps:
a.
Checking the Local Cache
The browser first checks its local DNS cache to see if it has a recent record of google.com's IP address. If found, the browser uses this cached IP and proceeds with the request, saving time.
b. Querying the Operating System’s Resolver
If the browser cache doesn’t have the IP, it makes a system call to the local DNS resolver, which is managed by the operating system. The OS resolver then checks its own cache. If it finds a matching record, it returns the IP to the browser.
Fun fact: To see the cached DNS records on a Linux system, you can use the following command: sudo resolvectl query google.com
c. Requesting from an External DNS Server
If no cached record exists, the local resolver queries an external DNS server, usually provided by your ISP or a public DNS provider like Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1).
d. Navigating the DNS Hierarchy
DNS servers are structured in a hierarchy, and the request travels through multiple layers:
Root DNS Servers: These servers direct the request to the appropriate Top-Level Domain (TLD) server (e.g., .com for google.com, .org for other domains, etc.).
TLD Servers: The .com TLD server then directs the request to the Authoritative Name Server for google.com.
Authoritative DNS Server: This server holds the actual IP address for google.com and returns it to the resolver.
e. Returning the IP Address
Once the resolver obtains the IP address, it sends it back to the browser. The browser can now initiate the actual HTTP request to Google’s server using the GET method.
By completing this process, the browser now knows exactly where to send the request and can proceed to retrieve the webpage. But the journey doesn’t end here—next comes establishing a connection to the server.
Step 2: The Three-Way TCP Handshake – Establishing a Connection
At this point, you might be wondering why we can’t just receive the response from Google’s server immediately. It’s important to keep in mind that the data requested from servers isn’t always simple or small. Often, it includes additional elements like images, videos, and scripts. To ensure smooth communication and prevent data loss, both the server and your computer need to establish a reliable connection. This process is known as the three-way TCP handshake and can be thought of as a preparation stage to ensure both parties are ready for communication.
Here’s how it works:
SYN Packet
The client (your browser) sends a SYN (synchronize) packet to Google’s server, signaling that it’s ready to initiate communication.
SYN-ACK Packet
Google’s server responds with a SYN-ACK (synchronize-acknowledge) packet, acknowledging the receipt of the SYN packet and indicating its readiness to communicate.
ACK Packet
Finally, the client sends an ACK (acknowledge) packet to Google’s server, confirming that the SYN-ACK packet was received. At this point, the connection is fully established, and data transfer can begin.
Step 3: Fetching and Rendering the Webpage
Once the connection is established, Google’s server sends back the requested homepage. This typically includes HTML, CSS, JavaScript, and other resources like images or videos. Your browser then processes these files, renders the page, and displays it as you’re used to seeing.
And just like that, within seconds, the familiar Google homepage appears in your browser, ready for you to start searching.
Conclusion
What seems like a simple action—typing a URL and hitting Enter—involves a complex series of steps working seamlessly behind the scenes. From DNS resolution to the TCP three-way handshake, each step plays a crucial role in delivering the webpage to your screen. The next time you browse the web, you’ll have a deeper appreciation for the intricate processes that make it all possible
Top comments (0)