KAHIBARO
Discord Login Register ☰
☰

2.15. What Happens When You Enter a URL?

Table of Contents

Step 1: You Type a URL

When you type a URL like:

text 
https://www.example.com/products?category=books

your browser first needs to understand and parse it.

A URL usually has these parts:

PartExampleMeaning
SchemehttpsProtocol to use, usually HTTP or HTTPS
Hostnamewww.example.comDomain name of the server
Port:443 (hidden)Network port, defaults depend on scheme
Path/productsWhich resource on the server
Query string?category=booksExtra parameters
Fragment#section-1Page position, handled only by browser

Your browser splits this into pieces so it knows:

Important: The scheme (http/https) decides:

  • Which port is used by default (80 or 443).
  • Whether the connection is encrypted or not.

For the rest of this chapter, assume you enter https://www.example.com/.

Step 2: Browser Checks Cache and Hosts

Before talking to other computers, the browser checks what it already knows.

Browser cache for the IP

The browser first needs the IP address of www.example.com. To avoid asking every time, it checks:

  1. Its own in-memory DNS cache.
  2. The operating system’s DNS cache.

If it finds a cached IP address, it can skip a lot of work.

Example:

hosts file

If the IP is not cached, the OS may check the local hosts file:

Example hosts entry:

text 
127.0.0.1   localhost
203.0.113.10   www.example.com

If such a line exists, www.example.com will resolve directly to 203.0.113.10, skipping external DNS.

As a backend developer, you sometimes use hosts entries to:

Step 3: DNS Lookup

If the browser and OS do not know the IP address, they ask a DNS resolver.

Who is the DNS resolver?

Usually:

Your computer sends a DNS query:

The resolver then does the heavy work. It might already know the answer (cached). If not, it asks other DNS servers in this order:

  1. Root DNS servers
    They do not know www.example.com, but they know where .com is managed.
  2. TLD (Top Level Domain) server for .com
    It says, "The nameserver for example.com is ns1.something.com."
  3. Authoritative DNS server for example.com
    This server knows the real IP for www.example.com, for example 93.184.216.34.

The resolver returns this IP to your computer and caches it for some time, defined by TTL (time to live).

Rule: DNS translates domain names to IP addresses.
Without DNS, you would have to use IP addresses like 93.184.216.34 instead of www.example.com.

Step 4: TCP Connection

Now the browser knows the IP, for example 93.184.216.34, and the scheme is https.

It must open a TCP connection:

TCP handshake

Before sending HTTP data, TCP does a three-way handshake:

  1. Client sends SYN to server.
  2. Server responds SYN-ACK.
  3. Client responds ACK.

After this, a reliable connection is established.

This handshake:

As a backend developer, you usually do not implement TCP directly, but it is important to know that HTTP uses TCP on ports like 80 and 443.

Step 5: TLS Handshake (for HTTPS)

Because the URL starts with https, the browser wants an encrypted connection.

On top of TCP, it performs a TLS handshake.

In simple terms:

  1. Browser says "Hello", with:
    • Supported TLS versions.
    • Supported encryption algorithms (ciphers).
    • A random number.
  2. Server responds with:
    • Selected TLS version and cipher.
    • Its TLS certificate, which contains its public key and its domain.
    • Another random number.
  3. Browser verifies the certificate:
    • Is it signed by a trusted Certificate Authority (CA)?
    • Is it valid (not expired)?
    • Does the domain in the certificate match www.example.com?
  4. If valid, the browser and server agree on a shared secret (session key), using the public key and some cryptography.
  5. From now on, data is encrypted before sending over TCP.

If certificate validation fails, the browser shows a warning like:

Your connection is not private.

Important: HTTPS = HTTP over TLS over TCP.
HTTP is the same protocol, but its content is encrypted and protected from eavesdropping and tampering.

Step 6: Browser Sends an HTTP Request

Now the browser has:

It can send a HTTP request.

Example request for https://www.example.com/:

http 
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,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cookie: session_id=abc123

Key parts:

For a GET request to a typical web page, there is no request body.

Step 7: Server Receives the Request

Somewhere on the internet, at IP 93.184.216.34 and port 443, there is a server.

This server usually has:

A simplified flow:

  1. The TCP and TLS parts are handled by the operating system and the web server / proxy.
  2. The web server reads the HTTP request.
  3. It decides which application should handle this request.
  4. It passes the request to the application server and then to your backend application.

For example, Nginx configuration might say:

nginx 
location / {
    proxy_pass http://127.0.0.1:8000;
}

So Nginx forwards the HTTP request to your backend running on port 8000.

Step 8: Backend Application Processes the Request

Your backend application now has access to:

The backend runs through several steps.

8.1 Routing

The application checks which route matches the request.

Example in FastAPI:

python 
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
    return {"message": "Hello, world!"}
@app.get("/products")
def list_products():
    return [{"id": 1, "name": "Book"}]

When it sees GET /, it calls read_root.

If you had requested GET /products, it would call list_products.

8.2 Middleware and authentication

Before hitting your route handler, the request might go through:

Example logic:

8.3 Business logic

Your route handler performs the business logic:

Example (pseudo code):

python 
def list_products():
    # Query database
    products = db.query("SELECT id, name, price FROM products LIMIT 20")
    # Return them as a JSON-compatible object
    return {"items": products}

8.4 Creating the HTTP response

The backend then builds a response:

Example HTTP response for an HTML page:

http 
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1256
Set-Cookie: session_id=abc123; HttpOnly; Secure; Path=/
Cache-Control: max-age=600
<!DOCTYPE html>
<html>
  <head>
    <title>Example</title>
  </head>
  <body>
    <h1>Hello from example.com</h1>
  </body>
</html>

The web server sends this back over the TLS and TCP connection to your browser.

Step 9: Browser Receives the Response

The browser now has the HTTP response. It does several things.

9.1 Check the status code

Based on the status code, the browser decides what to do:

9.2 Parse headers

The browser uses headers to adjust behavior:

Example Set-Cookie:

http 
Set-Cookie: session_id=abc123; HttpOnly; Secure; Path=/; Max-Age=3600

The browser stores session_id=abc123 and will send it with every future request to this domain, unless it expires or is deleted.

Step 10: Browser Renders the Page

If the response is HTML, the browser starts rendering.

10.1 Parse HTML

The browser:

Example HTML:

html 
<!DOCTYPE html>
<html>
  <head>
    <title>Example</title>
    <link rel="stylesheet" href="/styles.css">
    <script src="/app.js"></script>
  </head>
  <body>
    <h1>Hello</h1>
    <img src="/logo.png" alt="Logo">
  </body>
</html>

From this, the browser finds subresources:

10.2 Make additional HTTP requests

For each external resource, the browser makes more HTTP requests to the same server (unless full URLs point elsewhere).

Example requests:

http 
GET /styles.css HTTP/1.1
Host: www.example.com
...
GET /app.js HTTP/1.1
Host: www.example.com
...
GET /logo.png HTTP/1.1
Host: www.example.com
...

These go through exactly the same network steps:

Your backend may serve these:

10.3 Apply CSS, run JavaScript

The browser:

As a backend developer, you mainly care about:

Step 11: Further Requests and Interactions

Once the initial page is loaded, the user might:

Each of these can cause new HTTP requests.

Examples:

  1. User clicks link <a href="/products">Products</a>
    Browser requests:
http 
   GET /products HTTP/1.1
   Host: www.example.com
   Cookie: session_id=abc123
  1. User submits a login form:
    Form:
html 
   <form method="POST" action="/login">
     <input name="username">
     <input name="password" type="password">
     <button type="submit">Login</button>
   </form>

Browser sends:

http 
   POST /login HTTP/1.1
   Host: www.example.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: ...
   username=alice&password=secret123
  1. JavaScript fetch:
javascript 
   fetch("/api/products")
     .then(response => response.json())
     .then(data => console.log(data));

Browser sends:

http 
   GET /api/products HTTP/1.1
   Host: www.example.com
   Accept: application/json

Each request repeats the same high-level sequence:

  1. Browser prepares HTTP request.
  2. Uses existing connection or opens a new one.
  3. Optional DNS lookup if domain is different.
  4. Sends request.
  5. Backend processes it and returns a response.
  6. Browser updates the page or internal state.

Step 12: Connection Reuse and Closing

TCP connections are not always closed immediately.

After some time of inactivity, either the client or the server closes the connection with a TCP FIN message.

New requests later may open new connections.

Putting It All Together

Let us summarize the main steps when you enter a URL like https://www.example.com/:

  1. Parse URL into scheme, host, port, path, query.
  2. Check cache and hosts for an existing IP.
  3. Do DNS lookup if needed, to find the IP of www.example.com.
  4. Open TCP connection to IP on port 443.
  5. Perform TLS handshake to secure the connection (HTTPS).
  6. Send HTTP request, for example GET / HTTP/1.1.
  7. Server receives and forwards request to backend application.
  8. Backend routes the request, runs middleware, business logic, database queries.
  9. Backend builds HTTP response with status, headers, and body.
  10. Browser receives response, stores cookies, applies caching rules.
  11. Browser parses HTML, makes more requests for CSS, JS, images.
  12. Browser renders page and runs JavaScript.
  13. Further user actions cause more HTTP requests and responses.

As a backend developer, you mostly work on steps 7 to 9, but understanding the whole journey helps you:

Views: 12

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3059 / 24h
Impressum / Imprint
Datenschutz / Data Policy