What happens when you type google.com in your browser and press Enter

Everyone has visited a URL to get to a website. That’s how you got to this blog. But how is that writing “medium.com/some_id” gets you to this site, and specifically this post?

First let’s break down our URL. It is composed or two main parts: “https://” and “www.google.com”.

HTTPS is the name of the protocol used to send the request and data from your browser to www.google.com. We can think of this as a letter with all the data you want to send. When making these kind of requests it is important you make sure that you are using HTTPS protocol instead of the HTTP (no ‘s’) protocol. Their work the same as data and structure is concerned, but the difference is that HTTPS uses SSL (secure socket layers) to ensure data is encrypted. This makes the transaction more secure and makes so if someone intercepts your letter, they cannot read the content inside.

This is the structure of a HTTP/S request.

So now that we have our letter, where do we send it? We know we want it to go to the second part of the URL, www.google.com. But where exactly is www.google.com? This is where the IP protocol comes in. The Internet Protocol asigns each server an IP address we can use to connect to it, for example 192.168.0.1. If we follow the letter metaphor, then the IP would be like the street address used to deliver said letter. But wait, a number like 192.168.0.1 would be very difficult to remember for every website we want to visit, right? We might want to use an easier name for that, this is what the DNS is for. The Domain Name Service translates complex IP addresses into readable names, for example: www.google.com. Now we can use human language to access a website.

Each IP is an address to a server.

We have our letter and our destination, how do we send it? This is the job for the TCP Protocol. If HTTPS is the letter and IP the address, then the Transmission Control Protocol is the mailman that makes sure your letter gets delivered in the correct shape and order to its destination. This is acomplished by using a three-way handshake, where both parties must acknowledge the connection in each data transaction. This is like when Amazon delivers a package to your house and you confirm the package arrived with no problems.

So to recap: HTTPS is the letter with the data being sent, TCP is the mailman making sure the letter is delivered, and IP is the destination. We can use DNS to give a human-readable name as an address so the mail office will do the rest of the work and determine the IP for the request.

Of course, it is way more complicated than the examples described above and there are some concepts left out for when the request reaches the intended location. So let’s talk about them.

First is the Firewall, it acts a protection barrier from the outside that only allows certain requests to enter or exit the server. This can be used for example to block specific IP addresses or requests from certain geographical locations.

Second, if the server has to deal with many queries at the same time, it is likely that your request may go through a load-balancer, this step makes so no part of the infrastructure of a network is overflowing with requests.

Third, after the load-balancer sends your package to the correct location, it will reach a web server that will handle your HTTP/S request and return a response. The response may be static content like prerendered HTML or some images, or maybe a JSON with data records. This content will be most likely retrieved from an application server, where the data from our request will be processed to generate a response to return to the user. If some stored information is needed by the application server, it will call a database server to retrieve the persistant data required.

An example of this workflow would be a user sending a request with their credentials to an API to fetch some JSON data. The web server receives the request and ask the application server to get the data. First the application server will check the database if any user with the sent credentials exists, if so, then it will return the request data in a JSON format.

So, what happens when you type www.google.com in your browser and press enter? A lot of things, but to summarize it: First your request will be encrypted using HTTPS and SSL, then it will ask to a DNS where it can find the IP address of www.google.com. Once it finds it, the request is send to the destination where it will go through a firewall and load-balancer to finally reach a web server. The web server will analyze the request and call an application server to render some static content, authenticate the user or fetch some data. All of these requests and packages and data are being sent using the TCP protocol to ensure everything is in the correct order and format.

Diagram of what happens when you make a HTTP/S request