Apart from being a very common interview question, this is one of the very first query which lingers around in our mind every time we type a URL in a browser. Here is an attempt to satiate this quest while we delve into the details of what happens in the background when we type a URL in our browsers.
Step 1. URL is typed in the browser.
Step 2. If requested object is in browser cache and is fresh, move on to Step 8.
Step 3. DNS lookup to find the ip address of the server
when we want to connect to google.com, we actually want to reach out to a server where google web services are hosted. One such server is having an ip address of 18.104.22.168. Now, if you type “http://22.214.171.124” in your browser, this will take you to google home page itself. Which means, “http://google.com” and “http://126.96.36.199” are nothing but same stuff. But, it is not so. Google has multiple servers in multiple locations to cater to the huge volume of requests they receive per second. Thus we should let Google decide which server is best suited to our needs. Using “google.com” does the job for us. When we type “google.com”, DNS(Domain Name System) services comes into play and resolves the URL to a proper ip address.
Following is a summary of steps happening while DNS service is at work:
- Check browser cache: browsers maintain cache of DNS records for some fixed duration. So, this is the first place to resolve DNS queries.
- Check OS cache: if browser doesn’t contain the record in its cache, it makes a system call to underlying Operating System to fetch the record as OS also maintains a cache of recent DNS queries.
- Router Cache: if above steps fail to get a DNS record, the search continues to your router which has its own cache.
- ISP cache: if everything fails, the search moves on to your ISP. First, it tries in its cache, if not found – ISP’s DNS recursive search comes into picture. DNS lookup is again a complex process which finds the appropriate ip address from a list of many options available for websites like Google. You can read more about this here.
For the DNS enthusiasts – here is a great guide worth reading.
Step 4. Browser initiates a TCP connection with the server.
Step 5. Browser sends a HTTP request to the server.
Browser sends a GET request to the server according to the specification of HTTP(Hyper Text Transfer Protocol) protocol.
Here, browser passes some meta information in the form of headers to the server along with the URL – “http://google.com”. User-Agent header specifies the browser properties, Accept-Encoding headers specify the type of responses it will accept. Connection header tells the server to keep open the TCP connection established here. The request also contains Cookies, which are meta information stored at the client end and contain previous browsing session information for the same website in the form of key-value pairs e.g. the login name of the user for Google.
A quick guide to HTTP specification can be found here.
Step 6. Server handles the incoming request
HTTP request made from browsers are handled by a special software running on server – commonly known as web servers e.g. Apache, IIS etc. Web server passes on the request to the proper request handler – a program written to handle web services e.g. PHP, ASP.NET, Ruby, Servlets etc.
For example URL- http://edusagar.com/index.php is handled by a program written in PHP file – index.php. As soon as GET request for index.php is received, Apache(our webserver at edusagar.com) prepares the environment to execute index.php file. Now, this php program will generate a response – in our case a HTML response. This response is then sent back to the browser according to HTTP guidelines.
Step 7. Browser receives the HTTP response
HTTP response starts with the returned status code from the server. Following is a very brief summary of what a status code denotes:
- 1xx indicates an informational message only
- 2xx indicates success of some kind
- 3xx redirects the client to another URL
- 4xx indicates an error on the client’s part
- 5xx indicates an error on the server’s part
Server sets various other headers to help browser render the proper content. Content-Type tells the type of the content the browser has to show, Content-length tells the number of bytes of the response. Using the Content-Encoding header’s value, browsers can decode the blob data present at the end of the response.
Step 8. Browsers displays the html content
Step 9. Client interaction with server
Once a html page is loaded, there are several ways a user can interact with the server. For example, he call fill out a login form to sign in to the website. This also follows all the steps listed above, the only difference is that the HTTP request this time would be a POST instead of GET and along with that request, browser will send the form data to the server for processing (username and password in this case).
Once server authenticates the user, it will send the proper HTML content(may be user’s profile) back to the browser and thus user will see that new webpage after his login request is processed.
Step 10. AJAX queries
Hopefully, that gives you an idea of what happens in the background when we do a really simple operation which is type a URL in a browser.