Web Technologies

The web is a small set of protocols and formats layered on top of the internet. Almost everything you build on it reduces to one loop: a client asks a server for a resource, the server answers, and the client does something with the answer. This section takes that loop apart.

The client/server model

Two roles, and they are roles, not machines:

A client initiates requests. A browser, curl, a mobile app, another server calling an API.
A server listens on a port, waits for requests, and returns responses. It never speaks first.

That asymmetry explains a lot of the web’s design. Servers cannot push data to a browser that has not asked for something, which is why techniques like WebSockets and server-sent events exist as workarounds. Servers also do not remember you between requests, which is why cookies exist.

A machine can be both. A Node server that calls a payment API is a server to the browser and a client to Stripe.

What happens when you open a URL

Type https://example.com/products?page=2 and press Enter. Here is the whole chain, in order.

1. The browser parses the URL

It splits the string into scheme (https), host (example.com), implied port (443), path (/products), and query (?page=2). The scheme decides which protocol to speak. Covered in URLs, DNS and TLS.

2. DNS resolves the hostname to an IP address

Computers route packets to numeric addresses, not names. The browser asks a resolver (usually your ISP’s, or 8.8.8.8, or one built into the browser) to translate example.com into something like 93.184.215.14. The answer is cached at several layers, each honouring a TTL.

dig +short example.com

3. TCP connects to that IP

A three-way handshake (SYN, SYN-ACK, ACK) establishes a reliable, ordered byte stream to port 443. One network round trip.

4. TLS negotiates encryption

Because the scheme was https, the client and server run a TLS handshake: agree on a cipher, verify the server’s certificate against a chain of trusted authorities, and derive session keys. Everything after this is encrypted. TLS 1.3 needs one round trip.

openssl s_client -connect example.com:443 -servername example.com </dev/null

5. The browser sends an HTTP request

Plain text (conceptually — HTTP/2 and HTTP/3 encode it in binary frames), consisting of a request line, headers, and an optional body.

GET /products?page=2 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

6. The server responds

It routes the request, maybe queries a database, and writes back a status line, headers, and a body.

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

<!doctype html><html>…

See HTTP fundamentals for every part of both messages.

7. The browser renders

It parses HTML into a DOM, CSS into a CSSOM, combines them into a render tree, computes geometry (layout), fills in pixels (paint), and composites layers to the screen. Along the way it discovers references to CSS, JS, images and fonts, and fires off more requests — each one repeating steps 2–6 (though connections and DNS results are reused). See browsers and rendering.

The core technologies

Technology	Layer	What it does
IP	Network	Addresses and routes packets between machines.
TCP	Transport	Turns unreliable packets into a reliable, ordered byte stream. UDP is the unreliable alternative; HTTP/3 builds on it.
TLS	Security	Encrypts and authenticates the byte stream. Turns HTTP into HTTPS.
DNS	Naming	Maps human names to IP addresses (and much else).
HTTP	Application	The request/response format everything on the web speaks.
HTML	Content	Structure and semantics of a document.
CSS	Presentation	How that structure looks.
JavaScript	Behaviour	Runs in the browser, mutates the DOM, makes further requests.

HTTP is the pivot. HTML, CSS, JS, images, JSON API responses — all of it is just bytes with a Content-Type, delivered over HTTP.

Two ideas that explain most of the rest

HTTP is stateless

Every request is independent. The server, by protocol, knows nothing about your previous requests. State must be re-sent every time — as a cookie, a token in an Authorization header, or a value in the URL. Sessions, logins, shopping carts, and CSRF vulnerabilities all fall out of this one fact.

The browser is a hostile-content sandbox

A browser loads code from strangers and runs it immediately. Everything in the security model — the same-origin policy, CORS, CSP, cookie attributes — exists to stop that code from reading data it should not see or acting as you on other sites.

How this section is laid out

Each page maps onto part of the journey above.

HTTP fundamentals — the request/response format itself: methods, status codes, headers, and how HTTP/1.1, /2 and /3 differ on the wire.
URLs, DNS and TLS — everything that has to happen before the first byte of HTTP is sent.
Cookies, sessions and auth — how statelessness is worked around, and how identity is carried.
Browsers and rendering — what the client does with the response.
The security model, CORS and headers — the rules constraining what pages can do to each other.
APIs, REST and GraphQL — using HTTP for machine-to-machine communication instead of documents.
Caching and performance — how to avoid doing all of the above.

Set up your tools first

Almost every example here uses curl. It is the fastest way to see raw HTTP without a browser in the way.

curl --version
# curl 8.x.x (x86_64-pc-linux-gnu) libcurl/8.x.x OpenSSL/3.x.x ...

The flags used throughout:

Flag	Effect
`-v`	Verbose. Shows the request and response headers, plus TLS details.
`-i`	Include response headers in the output body.
`-I`	Send a `HEAD` request — headers only, no body.
`-X METHOD`	Set the HTTP method explicitly.
`-H 'Name: value'`	Add a request header.
`-d 'data'`	Send a request body (implies `POST`).
`-L`	Follow redirects.
`-s`	Silent — suppress the progress meter.
`--http1.1` / `--http2` / `--http3`	Force a protocol version.

A first look at the whole exchange:

curl -v https://example.com/ -o /dev/null

* Connected to example.com (93.184.215.14) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=example.com
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
> GET / HTTP/2
> Host: example.com
> user-agent: curl/8.5.0
> accept: */*
>
< HTTP/2 200
< content-type: text/html; charset=UTF-8
< content-length: 1256
<

Lines starting with * are curl’s own commentary, > is what curl sent, < is what the server returned. That single command shows DNS resolution, the TCP connection, the TLS handshake, the request and the response — the whole journey in fifteen lines.

Key points

The web is a request/response loop between a client that speaks first and a server that only answers.
Loading a URL means: parse URL → DNS → TCP → TLS → HTTP request → response → render, with steps 2–4 amortised across many requests.
HTTP is stateless; every mechanism for remembering a user is a workaround layered on top.
HTML, CSS, JS and JSON are all just typed byte streams delivered by HTTP.
The browser’s security model exists because it executes untrusted code by design.