What Happens When You Type google.com?

What happens when I type https://google.com in the browser:

1. URL Parsing
   The browser parses the URL to obtain:

   • Scheme: The scheme tells the browser which L7 protocol to use (well, not really, but in most common cases, it's true. Sometimes you can see things like mailto://, which is not really a protocol, just a URI that gets passed to the OS to handle - open a default desktop mail client. Most modern browsers support many protocols, such as FTP, HTTP, and DNS).
   • Domain
   • Path
   • Query String
   • Fragment (e.g., #contact-form)
   • Port: If none is provided, the default and standard for HTTPS is 443, and for HTTP, it is 80.

2. URL Encoding
   The browser will validate (and, if needed, transform) whether the URL is properly encoded (uses only ASCII (American Standard Code for Information Interchange) Unicode characters). You can see that yourself; for example, if you use empty spaces inside query parameter values, they will get translated into %20. If non-ASCII characters are found, the browser would apply Punycode encoding.

3. HSTS List Lookup
   Modern browsers will check their preloaded HSTS (HTTP Strict Transport Security) list to see which websites have requested to be contacted with HTTPS only. You have probably observed this little step many times when you tried to change the protocol from HTTPS to HTTP while developing something locally and couldn't do that. In Chrome, you can clear the HSTS list. Here's my article on how to do it: Prevent Chrome from Redirecting Your HTTP Localhost to HTTPS.

4. Domain Name Translation by DNS Server
   The domain name is translated by the DNS server (it might be cached locally in the browser or not; if not, it might need to go through one or multiple DNS servers (first your ISP, then external ones) to translate it to an IP address). This usually takes a few milliseconds. As developers, we can often see DNS prefetch headers or meta tags for different third parties in our apps. Prefetching helps reduce that few milliseconds from the request in the background.

5. TCP Connection Request
   After the browser receives the IP address of the server, it applies the parsed port to it and calls a system library to request a TCP connection.

   • TCP Handshake (Establishing/Opening a Connection): Unlike UDP, TCP provides a connection between two devices. To make it reliable, those devices have to first handshake on that deal (connection). This is a three-way handshake. If the TCP handshake happened with people, it would look like this: we first say hi to someone and expect them to respond. They respond with hello and give us a gift, expecting us to return it. We return the gift and are trusted (trusted enough to establish a connection, but not enough to call it a secure connection) to proceed. Here's a more detailed flow:
     • Device A (client) sends a SYN (Synchronize) packet to Device B (server).
     • Device B responds with a SYN-ACK packet (Synchronize-Acknowledge).
     • Device A sends an ACK packet back to the server.

6. TLS/SSL Handshake
   The TLS handshake (more likely the TLS handshake, since all versions of SSL are deprecated, but the term is often used for historical reasons and marketing) happens immediately after the TCP handshake. The client sends the server all supported TLS versions and cipher suites in the order of preference. The server responds with the best mutually supported TLS version and cipher suite. They exchange and verify certificates and exchange session keys.

7. GET Request
   After the secure connection is established, the browser sends a GET request to the server.

8. Server Response
   The server handles the request and responds with something (let's say an HTML document).

9. Response Handling
   The browser receives the response and, depending on the status and headers, either goes to the next steps or does something else (e.g., redirects to the Location header value).

10. Decompression
    The browser does decompression on the response body if it's compressed.

11. HTML Parsing
    The browser parses the HTML code inside the response body and resolves any additional resources (scripts, images, prefetch, preloads, predns). A lot of security mechanisms take place at that step (and many other steps), e.g., Same-Origin Policy, Content Security Policy (CSP), CORS, etc.

12. Resource Loading
    The browser starts loading those resources via their URLs using the same steps (it might not start right away depending on the fetch priority set for each resource and the browser's mechanics).

13. Rendering
    The browser does the rendering, but that's a topic for another article or ten of them. A lot of steps happen here, like parsing CSS to CSSOM, creating the DOM tree, painting, etc.