The Journey of a URL Request

Imagine you type https://www.example.com into your browser and hit Enter. Here’s what happens behind the scenes:

Step 1: Browser Cache Check

Before doing anything, your browser is lazy and efficient. It first checks its own cache to see if it has recently visited this website and stored a copy of the required files (like the IP address, the HTML, CSS, etc.).

Step 2: DNS Lookup (The Internet's Phonebook)

Your browser knows the website's name (www.example.com), but computers on the internet communicate using IP addresses (like 93.184.216.34). The browser needs to find the IP address for this domain name. This process is called a DNS (Domain Name System) lookup.

  1. Check OS Cache: The browser asks the operating system (Windows, macOS, etc.) if it knows the IP address. The OS also keeps a recent record of DNS lookups.
  2. Check Router Cache: If the OS doesn't know, it asks your local router, which also has a small cache.
  3. Ask the DNS Resolver: If no one in your local network knows, the request is sent to a special server called a DNS resolver (or recursive DNS server). This is usually provided by your Internet Service Provider (ISP), or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

The DNS resolver then does the heavy lifting, querying a series of servers in a hierarchy:

The resolver sends this IP address back to your browser.

Step 3: Establishing a TCP Connection (The Three-Way Handshake)

Now that the browser has the server's IP address, it needs to open a line of communication. It does this using the TCP/IP protocol suite. TCP ensures reliable, ordered delivery of data.

This is done with a "three-way handshake":

  1. SYN: Your browser sends a message to the server saying, "Hello, I'd like to open a connection. Are you ready?" (This is a SYN packet).
  2. SYN-ACK: The server responds, "Yes, I'm ready. Are you?" (This is a SYN-ACK packet).
  3. ACK: Your browser replies, "Great, I'm ready too. Let's start talking." (This is an ACK packet).

A reliable connection is now established between your browser and the server.

Step 4: Securing the Connection (The TLS Handshake for HTTPS)

Since the URL started with https://, the connection needs to be encrypted. This is handled by the TLS (Transport Layer Security) protocol, which is the modern version of SSL.

  1. Client Hello: Your browser sends a "Client Hello" message, which includes the TLS versions and encryption algorithms (cipher suites) it supports.
  2. Server Hello & Certificate: The server chooses the best protocol and cipher suite that both support. It then sends back its SSL Certificate. This certificate is like a digital ID card that proves the server is who it says it is (e.g., it's truly example.com and not an imposter).
  3. Verification: Your browser checks the certificate's validity with a trusted Certificate Authority (CA) (like GoDaddy, DigiCert, etc.) that issued it. If the certificate is valid and trusted, the browser proceeds.
  4. Key Exchange: The browser and server securely exchange information to create a unique "session key." This key will be used to encrypt and decrypt all subsequent communication between them for this session.

Now, they have a secure, private, and encrypted channel to talk through.

Step 5: Sending the HTTP Request

With a secure connection in place, your browser sends an HTTP (Hypertext Transfer Protocol) request to the server. This is a plain-text message formatted according to HTTP rules.

A typical request looks like this:


GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,...
Accept-Language: en-US,en;q=0.5

Step 6: The Server Responds

The web server (like Nginx or Apache) receives the request. It processes it, which might involve:

Once ready, the server sends back an HTTP response. It looks like this:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

<!DOCTYPE html>
<html>
<head>
    <title>Example Domain</title>
</head>
<body>
    <div>
        <h1>Example Domain</h1>
        <p>This domain is for use in illustrative examples...</p>
    </div>
</body>
</html>

Step 7: Browser Renders the Page

This is the final and most complex part. Your browser receives the HTML and starts to turn it into a visual page.

  1. Parsing HTML: The browser reads the HTML code and creates a DOM (Document Object Model) tree, which is a hierarchical structure of all the elements on the page.
  2. Finding Sub-resources: As it parses the HTML, it finds links to other resources, like CSS files (<link>), JavaScript files (<script>), and images (<img>). For each of these, it goes back to Step 2 (DNS lookup) and makes separate HTTP requests to fetch them.
  3. Parsing CSS: The browser parses the CSS files to create a CSSOM (CSS Object Model) tree, which defines the styling rules for each element.
  4. Render Tree: The browser combines the DOM and CSSOM trees to create a Render Tree, which knows what to display and how to style it.
  5. Layout & Painting: The browser calculates the exact position and size of each element on the screen (Layout) and then draws the pixels to the screen (Painting).
  6. JavaScript Execution: Finally, the browser executes any JavaScript code, which can make the page interactive—handling clicks, animations, and fetching more data from the server without a full page reload.

Once all this is done, the webpage is fully loaded and interactive, ready for you to use. All of this happens in the blink of an eye.

A Note on ddordain.com

If you replace example.com with ddordain.com in this journey, you'll notice a difference at Step 7.6. Since this website doesn't use any JavaScript, the browser skips the JavaScript execution phase entirely. This means:

This demonstrates how not all websites require JavaScript to provide a complete user experience. Sometimes, simpler is better.

Modern WebApp have made everything more complex !