What happens when you type google.com in your browser

A Step-by-Step Guide to How Browsers Work

Have you ever wondered what happens when you type a URL into your browser and hit enter? There are several steps that take place before the website appears on your screen. In this post, we will take a closer look at the step-by-step process that browsers go through to display a webpage.

As you start typing in your browser's search bar, the browser will automatically attempt to search for previously visited websites and display auto-complete results. Some browsers will do an actual search using the default configured search engine, while others will skip this step.

URL Parsing

Once you have completed the URL, the browser will parse it and figure out whether it is a URL or a search term. If it is a URL, the browser will attempt to visit the website.

If it is a search term, the browser will send the search term to the default search engine, which will then return a list of search results.

HTTP or HTTPS?

The next step is to determine which protocol to use, HTTP or HTTPS. To know that, there is a protocol called HTTP Strict-Transport-Security (often abbreviated as HSTS). It is a local list of websites that only need to communicate with HTTPS. If the website is on the HSTS list, then the browser will use HTTPS. We now know that the port is 443, and we need to figure out the IP address to establish the connection.

DNS Lookup

Now comes the exciting part: finding out the IP address using a method known as DNS lookup. The operating system is first asked if the domain is cached. If not, then the browser looks through the hosts file to see if there is a hardcoded entry. If there isn't, the browser checks if DNS over HTTPS (DoH) is enabled.

DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. The goal of this method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks[1] by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. If DoH is enabled, then the browser communicates with the DNS provider, such as Cloudflare, and asks for DNS. Assuming we are not using DoH, we establish an insecure UDP request to port 53 on the default DNS configured on our router, which could be 8.8.8.8 or 1.1.1.1. That in itself is a connection, so we need to send the packet.

TCP Connection

Now that we know the IP and port, we can establish a connection. We also know that we should use TLS since it's HTTPS, and our client is smart enough to use TLS 1.3. We first do a three-way handshake and establish a TCP connection between 10.0.0.2 port random 1234 and 4.1.2.3 port 443.

TLS, ALPN, SNI

Assuming that the latest browser is used and supports TLS 1.3, and the server also supports TLS 1.3, the TLS handshake is performed.

What are the steps of a TLS handshake?

TLS handshakes are a series of datagrams, or messages, exchanged by a client and a server. A TLS handshake involves multiple steps, as the client and server exchange the information necessary for completing the handshake and making further conversation possible.
It goes roughly as follows:

• The 'client hello' message: The client initiates the handshake by sending a "hello" message to the server. The message will include which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the "client random."
• The 'server hello' message: In reply to the client hello message, the server sends a message containing the server's SSL certificate, the server's chosen cipher suite, and the "server random," another random string of bytes that's generated by the server.
• Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
• The premaster secret: The client sends one more random string of bytes, the "premaster secret." The premaster secret is encrypted with the public key and can only be decrypted with the private key by the server. (The client gets the public key from the server's SSL certificate.)
• Private key used: The server decrypts the premaster secret.
• Session keys created: Both client and server generate session keys from the client random, the server random, and the premaster secret. They should arrive at the same results.
• Client is ready: The client sends a "finished" message that is encrypted with a session key.
• Server is ready: The server sends a "finished" message encrypted with a session key. Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys. If TLS extensions such as ALPN and SNI are enabled, the client also sends the hostname "google.com" in the TLS client hello, along with the fact that it supports HTTP2.

GET Request

Once the browser has established a secure connection with the server, it sends a request for the web page you requested. But here's the catch: millions of users are trying to access Google at the same time, so how does Google handle all this traffic? That's where load-balancers come in. Load-balancers distribute the traffic evenly across multiple web servers to ensure that no server is overloaded.

Now that the web server has received your request, it forwards it to the application server. The application server is responsible for executing the code that generates the web page you requested. This could involve retrieving data from a database, performing calculations, or running scripts.

Database

If the web page you requested requires data from a database, the application server retrieves that data and uses it to generate the web page. The web page is then sent back to your browser, where it is rendered and displayed on your screen.

And there you have it – the journey of your request from your browser to Google's servers and back. Next time you type "https://www.google.com" and press Enter, you'll know exactly what's going on behind the scenes. Happy browsing!

Fun Fact
Did you know that the first web browser was created in 1990 by Sir Tim Berners-Lee? He called it WorldWideWeb, but later changed its name to Nexus to avoid confusion with the World Wide Web. Bet you didn't see that one coming!

Thank you for reading this post on how browsers work! We hope you found it informative and interesting. If you enjoyed this post, make sure to check out our other blogs for more fascinating topics. Keep learning and exploring!