Age old tech interview question, “what happens when you type …..”
I remember my first official tech interview at a design firm, the Tech Lead asked me, “What happens when you type google.com?”
My answer…. was well….. inadequate to say the least. Now, nearly 3 years later, I can answer the question a little better :)
In my example, instead of using google.com, i’ll use holbertonschool.com
Quick sales pitch lol, Holberton School is a 2-year college replacement program to learn software engineering. Unlike a bootcamp, Holberton goes very deep into CS fundamentals.
Back to the topic at hand.
To make this topic easier to understand, I’m breaking it down to two parts.
One: How does the browser know where to requests a site from
This is quite a fundamental question. A server, is basically a number. An IP address. So when holbertonschool.com is requested, the browser can’t just look for a server named holbertonschool.com, it needs to know the IP address of the server.
Step 1:
The browser checks to see if the domain is stored in the browser’s cache.
Possible Step 2:
If not in the browser’s cache, the resolver checks the hosts file to see if there is any mention.
Possible Step 3:
If the resolver does not find it in the hosts file, the resolver then goes on a journey to find the IP.
Resolver’s Journey
- Resolver asks the nearest root server, if the root does not have it in cache, it gives the resolver the TLD server
- Resolver asks the TLD server
- If the TLD server does not know the IP, it gives the resolver the name servers
- Resolver asks the domain registrar to validate the name servers
- Name Server gives the IP of the server
- Finally, the resolver gives the IP to the browser
- The browser caches the IP with the domain name
Two: Requesting, retrieving, displaying the site
HTTP/HTTPS request
Now that the browser knows where to request information from, the browser sends either a HTTP or HTTPS request to the IP.
If the browser sends an HTTPS request, an encryption process is done, where the browser initiates a TCP handshake and requests the SSL certificate from the server. The server accepts the handshake and responds with the certificate. The browser checks the certificate to see if it’s issued from a known issuer. If so the browser and the server negotiate a encryption key. If successful, all data going between the browser through TCP/IP is now encrypted.
Load Balancer
Normally, a site will have a load balancer, and the servers is setup so that they can only be accessed through the load balancer and not individually.
This way if a server goes down, there’s a backup. But to further combat the Single Point of Failure, sometimes there are multiple load balancers that communicate with each other. So if one load balancer goes down, the others can take more of the load.
For additional security, most times the load balancers themselves will have a firewall that can filter out flagged or malicious traffic so bad requests don’t even make it to the actual servers that are running the web services.
Web Server
Now that the load balancer has selected a server to use for the request, the web server on the physical server/container/vm/cloud/etc takes the HTTP/HTTPS request.
Depending on what kind of information is requested, the web server can either serve static html content or dynamic content through the application server
Application Server
The application server is a used for dynamic content and is where backend logic comes in with languages like Python, Golang, Ruby, Javascript, etc. The Application server, if needed, the application server send queries to the database.
The content is then served through TCP/IP either encrypted (HTTPS) or unencrypted (HTTP) to the browser.
That’s the high level overview of what happens when you type in a URL in your browser.
This all happens within milliseconds. Pretty neat huh?
