What happens when you open a website?

The server chooses what a path means; it need not point to a file on disk. A query such as ?sort=name is sent to the server. A fragment such as #care stays in the browser, not the HTTP request.

The browser is the client; the server is software that responds. That server role might be fulfilled by one computer or a large fleet.

1. The browser or OS checks for a usable cached answer.
2. A recursive resolver checks its cache.
3. On a cache miss, it follows referrals: root → top-level domain → authoritative nameserver.
4. The answer can be cached for its time to live (TTL).

Cached referrals can shorten the process. A name may resolve to several addresses or point to another name. A record change does not instantly replace every cached copy.

.example is reserved for documentation. This is an illustration of DNS, not a live lookup.

The certificate must cover the hostname, pass validity and trust-chain checks, and the handshake must verify possession of its private key. This authenticates an endpoint—not an honest business or truthful content.

HTTPS protects HTTP paths, headers, and bodies from a passive network observer. Destination IP addresses, timing, and traffic sizes can remain visible. DNS or connection setup may expose the hostname. HTTPS is not anonymity.

Without HTTPS, HTTP content is readable on the network and an active attacker may alter it. The server receiving an HTTPS request can still read its contents.

Browsers can reuse connections and resume secure sessions. This model uses a new HTTP/2 connection over TCP + TLS. The resource-cache toggle later changes only how page assets load, not this connection.

HTTP/1.1 and HTTP/2 normally use TCP. HTTP/3 uses QUIC over UDP, with TLS security integrated into QUIC—not the TCP handshake shown here.

HTTP has no built-in signed-in identity. This toggle assumes an earlier successful sign-in: the server issued a session ID, and the browser stored its cookie. It compares two versions of this request; it does not submit a login form.

Earlier sign-in:
POST /login → 200 OK
Set-Cookie: demo_session=demo-7; Path=/; Secure; HttpOnly; SameSite=Lax

This visit:
GET /plants
Cookie: demo_session=demo-7
Server checks session → HTML with a personal greeting

The greeting comes from the server’s HTML, not from JavaScript or cached assets. A cookie carries an ID—not a password or automatic permission. The server must accept the session and check permissions separately. If its session expires, the cookie alone cannot restore it.

This public page is available to guests too, so both visits can return 200 OK. A protected page could reject a guest instead. Cookie sessions are one design; applications can use other credentials, such as bearer tokens.

Keep real session IDs secret. Secure restricts normal sending to secure transport; HttpOnly blocks page JavaScript from reading the cookie, but the browser still sends it. SameSite limits cross-site sending and helps mitigate some CSRF attacks, not all attacks.

Domain and path rules also affect sending. Responses use Set-Cookie to store a cookie; requests use Cookie to send matching name/value pairs without their attributes. A real sign-in system also needs safe credential handling, session rotation, expiry, and permission checks. No real cookie is set here.

GET requests a resource; headers carry metadata. 200 means success, 404 means this resource was not found, and 500 means a server error. A browser can display an error response’s HTML too.

A POST request can carry a body, such as form data. A redirect, such as 301 or 302 with a Location header, leads to another request. HTTP also carries JSON, images, and other data; Content-Type describes the body.

These are readable message sketches, not literal HTTP/2 bytes. HTTP/2 encodes messages in binary frames.

The browser can reuse fresh cached resources instead of downloading them again. A stale response can sometimes be validated; 304 Not Modified lets it reuse the cached body.

The toggle changes only the public CSS, image, and script. A fresh cache hit means no network request for that resource; the page looks the same. A missing-image experiment assumes no usable cached image, so that request still returns 404. DNS caching is separate, in step 2. The HTML is always fetched here, with Cache-Control: private, no-store, so personalized content is not reused between visitors. Cache behavior depends on headers and browser state. Cache-Control: no-cache means validate before reuse, not “never store.”

No. The browser can discover resources while parsing HTML, fetch several concurrently, and paint content before all resources arrive. Some stylesheets and scripts can delay rendering or parsing. The steps separate overlapping activities for clarity.

Not every interaction requires JavaScript: links, native forms, and expandable details can work without it. The custom watering action in this example needs a script.