One of the most frequently asked questions during IT interviews is, “What happens when you try to access google.com in your browser?”
It’s a fantastic question that allows you to demonstrate a wide variety of technical understanding. There are so many different layers involved: HTTP, DNS, TCP/IP networking, caching, load balancing, and browser details (autocomplete, tracking, memory management, etc).
This is my attempt at answering, in more detail than warranted for an interview, what happens when you try to access google.com in your browser.
We will assume google.com has already been typed into the address bar and begin with the enter key bottoming out.
Assumptions:
- The URL has already been typed into the address bar and the process starts with the enter key bottoming out
- This is the first time we are accessing google.com on our local network.
- The DNS server configured for our local machine is on the internet but does not contain a record for google.com (even though under typical circumstances, most DNS requests are cached by intermediate servers)
Depending on whether the enter key is on a physical keyboard or touch screen, a series of interrupts and API calls are made through the CPU, operating system kernel and hardware abstraction layers to notify the browser that a URL has been submitted. This kicks off another series of window manager and operating system API calls which tells the browser to begin processing the URL.
The browser then parses the input to determine whether it is a search query or a URL. In this case, it recognizes google.com as a valid domain name (otherwise, it would submit the input as a query to its default search engine).
Then, the browser compares the URL to a preconfigured list of websites that have requested to be contacted only via HTTPS. Since google.com is already on the list, the request is made over HTTPS.
Next, the browser attempts to use its own cache of DNS records to resolve google.com to an IP address. If no record is found, the DNS request will be forwarded to the operating system, which attempts to resolve it by checking the local hosts file or sending a request to the configured DNS server.
In this case, the request is forwarded to the DNS root name servers which contains a list of Top Level Domains. These TLDs in turn are able to forward the request to the google.com domain as the authoritative source.
The next stage of the process is to establish a TCP or UDP socket with the DNS server. In this scenario, we’re assuming the DNS server is on an external network, so the initial request has to be forwarded to the default gateway where it can access the internet. In order to reach the default gateway, the Address Resolution Protocol (ARP) is used to lookup the MAC address of the router. This process is repeated anytime the MAC address of the next hop is unknown.
Once the DNS connection is established, the service responds to the client with an IP address associated with google.com.
Once the client machine receives the IP address of the web server hosting the website, it establishes a connection to Google’s infrastructure. In this case, their infrastructure is likely to include a load balancer, which directs traffic to the appropriate server based on factors such as server load and location, as well as application firewalls to protect against security threats.
When the connection is established with the web server (one additional layer of complexity here is that HTTP headers like Strict-Transport-Security are likely in play which forces the browser to reconnect via HTTPS on port 443 instead of port 80), the client sends a GET request to the web server, asking it to retrieve and send the requested webpage. The web server receives the GET request and passes it on to the web application, which in turn talks to the database to fetch any necessary results. The web application then assembles the webpage using the retrieved data and sends it back to the client as a response to the GET request. The client’s browser then renders the page for the user to view.
This process occurs every time a user accesses a website, and it’s a testament to the complexity and efficiency of the systems and protocols that make the internet possible.