Let's be friends

What really happens when you visit a website

Last updated: July 30, 2025

This is in the works! Would you like to help flesh it out? Let's do it!

1. The Browser & Request

  • User enters URL in the address bar (e.g., http://example.com).

  • Browser parses the URL into:

    • Protocol (http or https)

    • Domain (example.com)

    • Path (/about etc.)

  • DNS Lookup:

    • Checks local cache → ISP → recursive DNS → authoritative DNS

    • Returns the server’s IP address

  • TCP Connection (3-way handshake)

  • TLS/HTTPS Handshake (if https)

    • Certificate check

    • Encryption keys exchanged

2. The Server

  • Request reaches the server’s IP

    • Often through routers, firewalls, and load balancers

  • Web Server (Apache) receives the request

    • Checks virtual host config

    • Maps example.com/about to a directory or PHP file

  • PHP Interpreter executes if it’s a .php file

    • Optionally queries MySQL if dynamic content is needed

    • Assembles an HTML response

  • Response sent back over TCP → encrypted (if HTTPS)

3. The Browser Rendering Pipeline

  • Receives the HTML

  • Parses HTML:

    • Encounters <link> → fetch CSS

    • Encounters <script> → fetch JS

    • Encounters <img> → fetch images

  • Each request repeats the DNS + TCP + TLS steps (or uses keep-alive)

  • CSSOM + DOM → Render Tree → Paint

    • Runs JS

    • Applies CSS

    • Builds the final visible page

4. Extra Layers Students Might Notice

  • Caching:

    • Browser cache

    • CDN or proxy caching

    • Server cache (like opcache for PHP)

  • Compression & Optimization:

    • Gzip / Brotli

    • Minified assets

  • Security Checks:

    • HTTPS certificate verification

    • Mixed content warnings

  • Errors & Logging:

    • 404, 500

    • Apache logs, PHP error logs

 

Browser → DNS → TCP/HTTPS → Apache → PHP → MySQL
         ↑                           ↓
       CSS/JS/IMG requests        HTML Response

What we want you to find….

 

  • That a “simple page” is the tip of an iceberg of:

    • DNS resolution

    • TCP/HTTP(S) handshakes

    • Web server config

    • PHP execution

    • Database queries

    • Multiple asset requests

    • Rendering and scripting

  • That every layer can break or slow things down.

  • That “the web” is a stack of cooperating systems, not just a file being opened.

….

1. Open DevTools → Network Tab

  • Reload the page with Network tab open

  • Filter by “All”

  • Explain each column: Name, Status, Type, Initiator, Size, Time

  • What to notice:

    • First request = HTML

    • Then all the assets (CSS, JS, images)

    • Some requests have different domains (fonts, CDNs)

2. Step Through the Timeline

  • Click the first HTML request → Headers tab

    • Show Request URL (the full thing the browser sent)

    • Show Response Headers (server type, content-type)

    • Show Status Code (200 OK, 304, 404, etc.)

  • Then pick an image or CSS file

    • Compare the request/response

    • Reinforce that each one is a separate trip

3. Simulate Slow Networks

  • Use the Throttling dropdown (Slow 3G)

  • Reload the page

    • Students see waterfall bars crawl across

    • Every request becomes obvious

4. Show Links as New Requests

  • Click a link to another page

    • Clear the network tab first

    • Show that everything fires again

  • Even internal links are fresh requests (unless SPA or cached)

5. Key Lesson

  • A “simple” page is dozens of tiny conversations between browser and server

  • Every link = a new conversation

  • DevTools lets us see the dialogue

  • ….

  1. Part 2: Links

    • Show that every <a> tag creates a brand-new trip

    • Emphasize:

      • Even links on the same site can trigger a new request

      • Browser may reuse DNS and connections if possible (keep-alive, HTTP/2)

    • Visual: arrows looping back to “Browser → DNS → TCP…”

 

…

…

this is the perfect time to seed security awareness without scaring them or overwhelming them with advanced concepts. Even for pure HTML websites, there are a few practical ways to frame security so they start thinking like responsible developers.

Here’s how I’d approach it:

1. Separate Two Kinds of Security

  1. System/Network Security (server, hosting, traffic)

  2. Content/Client-Side Security (the files, the browser, the links)

Since they’re only making static HTML, the attacks are mostly system/network unless they do something silly like link to malicious resources.

2. Attacks They Can Understand Early

A. Denial of Service (DoS / DDoS)

  • What it is: Overwhelm your server with too many requests.

  • How it works for HTML sites:

    • Send thousands of requests → server can’t handle real users.

  • Takeaway: Even static sites rely on a server that can be swamped.

B. Defacement / Unauthorized Access

  • What it is: Hacker gets into your server and changes your HTML files.

  • How it might happen:

    • Weak password on FTP or hosting control panel

    • Poorly secured hosting

  • Takeaway: The site is “static,” but the server is dynamic and vulnerable.

C. Hotlinking / Resource Abuse

  • What it is: Someone embeds your images on their site, using your bandwidth.

  • Takeaway: Even if your site is safe, people can steal resources.

D. Clickjacking or Misuse

  • What it is: Someone loads your page in a hidden iframe and tricks users into clicking.

  • Takeaway: Even innocent pages can be abused in another context.

E. Social Engineering

  • What it is: If you post personal info or predictable admin URLs, attackers can exploit that.

  • Takeaway: Don’t expose private details even on static sites.

3. Framing Security Early

You don’t need to teach them cryptography yet—just cause and effect awareness:

  • Servers are real computers; people can attack them.

  • Static HTML isn’t bulletproof—security ≠ “I didn’t write PHP.”

  • Every website lives in a bigger ecosystem where traffic, hosting, and configuration matter.

  • Being a good web citizen means considering both user safety and system safety.

4. Optional Cool Demo

  • Spin up a test server → hit it with ab (ApacheBench) or similar

  • Show how even a small flood of requests can freeze a cheap shared host

  • Students viscerally understand DDoS in 30 seconds
Let's be friends