Recently in a job interview, I was asked- "What happens from the moment you enter a URL in the browser?". Although, I had an overall idea, I was quite unable to construct the entire flow loquaciously. This article is meant to give you (and me) a seamless flow chart of what happens from top to bottom until you see the very webpage. It covers both, the browser components and server side resolution of domains.
So without further ado, let's dive in...
The overall picture
Although, a webpage loads in a matter of seconds, there is quite a lot going on in the background. For simplicity, we will split them into three major flows:
1. Get the IP address of the server that your domain name refers to
2. Hit the server to fetch what is to be rendered on the UI
3. Construct, paint, and render the page
This is it. It's as simple as three steps. However, the complex part kicks in when we dive deeper into the two black boxes-
- IP address resolution.
- Constructing and rendering webpage.
If you are backend developer, the first will be of prime concern to you, and for frontend folks it's the browser rendering that takes precedence.
Anyways, let's look into both of them.
Domain name to IP Address using Domain Name Server(DNS)
Although this article is not meant for heavy theory (there are plenty on the internet), I will give a small summary why this block is important.
We as human beings don't retain long numbers. And machines don't understand our sophisticated language. As a win-win solution, we give names (domain name) to our servers while they have their identity as IP Addresses (numbers). So how do we bridge the gap and communicate? Domain Name Server acts as our mediator!
This is what goes behind the curtains:
Sorry if image is too small on your device, I had to fit in a lot of content in one flow chart. I urge you to download it and analyse each component. They are quite self-explanatory.
How the user finally gets a fancy webpage
Once we have resolved the IP Address of the server that has our relevant data (the webpage), all there is left is to actually hit it and fetch what we wanted. Most of the time, we get an HTML page in response, but we also have instances when it is a PDF, or other content-types like image, JSON, XML etc.
In this section, we will see how the browser converts an HTML file (bunch of nodes, scripts, and stylings) into a full-fledged viewable page.
This is only an overview. But, if you want to dig deeper into how each and every browser component works, refer here. This site is pretty much the Magnum Opus of how browser renders the HTML with embedded scripts and painted stylings.
However, I would like to mention a couple of important points here-
1- Your Browser Engine holds your JS environment like v8(for chrome) that has call stack, memory heap, event loop, Web API.. yada yada.
2- It's the Render Engine that parses the HTML nodes into a DOM tree and then further into a painted(CSS applied) render tree to display.
3- Everytime your HTML parser encounters script tag, it PAUSES PARSING DOM elements (IMPORTANT!!!) and synchronously downloads all scripts first.
Conclusion
Again, the agenda of this article was to help you articulate a big picture into a consolidated 3 min answer if anybody ever asks you- "What happens when you enter a URL?". Of course, there is a lot to explore here, and there are brilliant sources online to do so. Mentioning some of them in the references below.
Reference
The Big Picture
How DNS works
Rendering HTML into the browser
Thank you for reading. Hope this helps! π¦π¦π¦
Top comments (12)
I was asked some interesting questions on linkedin, which I would like to post here as well:
1) Where is the DNS resolver located? Is it in our machine?
2) Does every request, after reaching the DNS resolver, follow the sequence of going to root server, then TLD server and then ANS?
TL;DR
DNS Resolver is in fact only a software service that can run even on your computer, but most often it is provided by your Internet Service Provider(ISP). This DNS Resolver service sends requests to the wider hierarchy of DNS Servers out in the world on behalf of your Operating system.
Now, let's assume the most common case- that is, the DNS resolver is hosted by your ISP, that means, it is common for a bunch of local computers/devices connected to this network. Needless to say, DNS resolvers are distributed anywhere and everywhere across the internet.
Note: You can even configure your DNS resolver setting from Control Panel -> Network and Internet Settings. But by default, it is taken as that of your ISP (which ever WiFi or Ethernet you are connected to).
As to whether the whole DNS Root server to ANS resolution happens every time the request reaches the resolver- No.
As I mentioned above, a resolver is shared by a bunch of local clients in a network. The resolver has its own cache to maintain the bunch of resolved domains. So if you one client on that network accessed a domain, and then another client (say your phone) tries to access the same domain, it will be picked up from the cache.
Additional FYI:
Why do we maintain so much hierarchy to fetch a domain instead of having it in our system?
When you go and buy a domain, say from #GoDaddy, it is their responsibility to update the IP Address of the servers they are alloting over to the whole network (TLD, ANS). Imagine if this weren't so centralized, it would be an odious task to update every client with this info.
On the contrary, we have only a total of 13 Root Servers across the world (named from 'A' to 'M' - So unimaginative! :D), maintained by #ICANN (Internet Corporation for Assigned Names and Numbers), which are responsible for the world of DNS! PFA the list of organizations that host these root servers.
For the list of Root servers across the world-
ionos.com/digitalguide/server/know...
Very informative thanks. Postman had asked me this very same question on their interview long back.
Wow, itβs a small world. Got this question for Frontend Dev role in Postman only recently. :D
π are we allowed to even discuss this?
Too bad I wasn't selected for the role.
Hahaha. Same here! Well, Glassdoor does quite the same- discussing interview questions. So I m guessing this is no harm. Hope it prepares others who go for a postman interview. π
There should be a list of questions asked in interviews as well as assignments, ofcourse hiding the employers name.
Maybe beginners can take advantage of it.
Thatβs a good suggestion. May be I will take some time to compile this sometime :)
I was already making one. Let me know if you want to add them as well.
Ah awesome. Will send in some interesting questions then!
For sure there's so much to explore on this subject. I always have the basic idea of how it all works and at times I've read about how it works on different scenarios like on a secure HTTPS connection. Pretty interesting backend stuff. This article is a great starting point for anyone interested.
Thank you Musale. Itβs quite overwhelming how many back and forth processes are involved before one page renders. Yet we lose our patience if it takes more than a few seconds to load. If you are interested, look into the third point that I mentioned - that parsing stops until script is completed. There are a lot of trick questions based on that concept. And the results are quite surprising.
And if you are interested in backend, one thing I did not mention here was the three way TCP connection that takes place between the browser and the data server. Thatβs quite interesting too. :) Glad you liked the article.
Sweet, thanks for sharing!