Can somebody tell me what all happens behind the scenes from the time I type in a URL in the browser to the time when I get to see the page on the browser? A detailed account of the process would be of great help.

Questions on Stack Overflow are expected to relate to programming within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

2

Though this may be programming related (eventually) - the level of detail to which this could be answered would (and has) filled volumes. Please restate as a programming query.
– KevinDTimmJan 19 '10 at 9:48

3 Answers
3

Attention: this is an extremely rough and oversimplified sketch, assuming the simplest possible HTTP request (no HTTPS, no HTTP2, no extras), simplest possible DNS, no proxies, single-stack IPv4, one HTTP request only, a simple HTTP server on the other end, and no problems in any step. This is, for most contemporary intents and purposes, an unrealistic scenario; all of these are far more complex in actual use, and the tech stack has become an order of magnitude more complicated since this was written. With this in mind, the following timeline is still somewhat valid:

browser checks cache; if requested object is in cache and is fresh, skip to #9

browser asks OS for server's IP address

OS makes a DNS lookup and replies the IP address to the browser

browser opens a TCP connection to server (this step is much more complex with HTTPS)

browser sends the HTTP request through TCP connection

browser receives HTTP response and may close the TCP connection, or reuse it for another request

browser checks if the response is a redirect or a conditional response (3xx result status codes), authorization request (401), error (4xx and 5xx), etc.; these are handled differently from normal responses (2xx)

if cacheable, response is stored in cache

browser decodes response (e.g. if it's gzipped)

browser determines what to do with response (e.g. is it a HTML page, is it an image, is it a sound clip?)

Again, discussion of each of these points have filled countless pages; take this only as a summary, abridged for the sake of clarity. Also, there are many other things happening in parallel to this (processing typed-in address, speculative prefetching, adding page to browser history, displaying progress to user, notifying plugins and extensions, rendering the page while it's downloading, pipelining, connection tracking for keep-alive, cookie management, checking for malicious content etc.) - and the whole operation gets an order of magnitude more complex with HTTPS (certificates and ciphers and pinning, oh my!).

First the computer looks up the destination host. If it exists in local DNS cache, it uses that information. Otherwise, DNS querying is performed until the IP address is found.

Then, your browser opens a TCP connection to the destination host and sends the request according to HTTP 1.1 (or might use HTTP 1.0, but normal browsers don't do it any more).

The server looks up the required resource (if it exists) and responds using HTTP protocol, sends the data to the client (=your browser)

The browser then uses HTML parser to re-create document structure which is later presented to you on screen. If it finds references to external resources, such as pictures, css files, javascript files, these are is delivered the same way as the HTML document itself.