How the Web Works

The Request-Response Cycle

Every time you type a URL into a browser, an entire chain of events fires off. Understanding this chain is the single most important thing a web developer can learn before touching any framework.

The sequence:

1. You type https://example.com/products?page=2 into the address bar
2. The browser performs a DNS lookup to find the IP address
3. The browser opens a TCP connection to that IP
4. If HTTPS, a TLS handshake secures the connection
5. The browser sends an HTTP request
6. The server processes the request and sends an HTTP response
7. The browser parses and renders the response

Each step can fail, and each step has performance implications. A slow DNS lookup adds latency before the first byte even arrives.

DNS: Turning Names into Numbers

The Domain Name System translates human-readable domains into IP addresses. When you request example.com, the browser does not know where to send the request until DNS resolves it.

The lookup process (simplified):

1. Browser checks its own DNS cache
2. OS checks its DNS cache
3. Query goes to the configured DNS resolver (often your ISP or 8.8.8.8)
4. The resolver walks the DNS hierarchy: root server, TLD server (.com), authoritative server

Browser cache → OS cache → Resolver → Root → .com TLD → example.com authoritative
                                                         ↓
                                                    93.184.216.34

DNS results are cached based on the TTL (Time To Live) value set by the domain owner. A TTL of 3600 means the result is cached for one hour.

TCP: Establishing a Connection

HTTP runs on top of TCP. Before any data is exchanged, the browser and server perform a three-way handshake:

Browser → Server:  SYN        (I want to connect)
Server → Browser:  SYN-ACK    (Acknowledged, I'm ready)
Browser → Server:  ACK        (Let's go)

This handshake takes one round trip. For a server 100ms away, that is 100ms of latency before any HTTP data flows.

HTTP/2 and HTTP/3 reduce the impact of this by multiplexing multiple requests over a single connection.

HTTPS & TLS

HTTPS wraps HTTP in a TLS (Transport Layer Security) layer. After the TCP handshake, a TLS handshake negotiates encryption:

1. Browser sends supported cipher suites
2. Server picks one and sends its certificate
3. Browser verifies the certificate against trusted Certificate Authorities
4. Both sides derive session keys
5. All subsequent data is encrypted

TLS adds another round trip (TLS 1.3 reduced this to one round trip, or zero with session resumption).

Why HTTPS matters beyond security: browsers block mixed content (HTTP resources on HTTPS pages), HTTP/2 requires HTTPS in practice, and many APIs (geolocation, service workers) require a secure context.

HTTP Methods

HTTP defines methods (verbs) that indicate what the client wants to do:

Idempotent means making the same request multiple times produces the same result. GET for the same URL should always return the same resource. POST can create a new record each time.

GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{"name": "Ada Lovelace", "email": "ada@example.com"}

HTTP Status Codes

The server responds with a status code that tells the client what happened:

2xx: Success

3xx: Redirection

4xx: Client Error

5xx: Server Error

HTTP Headers

Headers carry metadata about the request or response. They are key-value pairs.

Common Request Headers

GET /page HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en-US
User-Agent: Mozilla/5.0 ...
Cookie: session_id=abc123
Authorization: Bearer eyJhbG...
Cache-Control: no-cache

Common Response Headers

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 3842
Cache-Control: max-age=3600
Set-Cookie: session_id=abc123; HttpOnly; Secure
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Content-Type tells the browser how to interpret the body. Cache-Control tells it how long to cache the response. Set-Cookie stores data in the browser for future requests.

Putting It All Together

Here is what happens when you visit https://shop.example.com/products?category=books:

1. DNS lookup: shop.example.com → 198.51.100.42
2. TCP handshake: SYN → SYN-ACK → ACK
3. TLS handshake: negotiate encryption
4. HTTP request:
   GET /products?category=books HTTP/1.1
   Host: shop.example.com
   Accept: text/html

5. Server processes:
   - Routes request to handler
   - Queries database for books
   - Renders HTML template

6. HTTP response:
   HTTP/1.1 200 OK
   Content-Type: text/html; charset=utf-8

   <!DOCTYPE html>
   <html>...product listing...</html>

7. Browser parses HTML, discovers CSS/JS/image resources
8. Browser fires off additional requests for those resources
9. Page renders progressively as resources arrive

Steps 7-9 are where the browser rendering pipeline begins -- covered in the next topic.

Common Pitfalls

• Ignoring HTTPS in development: Use HTTPS locally too. Tools like mkcert make it easy. Behavior differences between HTTP and HTTPS cause real bugs.
• Treating POST as idempotent: Double-clicking a submit button can create duplicate records. Use idempotency keys or disable the button after first click.
• Not understanding caching headers: Setting Cache-Control wrong can serve stale content for hours. Worse, not setting it at all means browser defaults vary.
• Assuming DNS is instant: DNS lookups can take 20-120ms. Use dns-prefetch link hints for domains you know you will need.
• Confusing 401 and 403: 401 means "who are you?" (not authenticated). 403 means "I know who you are, but you cannot do this" (not authorized).
• Ignoring status codes in API clients: Treating all non-200 responses as generic errors makes debugging impossible. Handle specific codes.

Key Takeaways

• The web is built on a request-response cycle: client asks, server answers
• DNS translates domain names to IP addresses and is a real source of latency
• TCP provides reliable delivery; the three-way handshake adds a round trip
• TLS encrypts the connection; HTTPS is non-negotiable for production
• HTTP methods express intent: GET reads, POST creates, PUT replaces, DELETE removes
• Status codes are a contract: 2xx success, 3xx redirect, 4xx client fault, 5xx server fault
• Headers carry critical metadata for caching, authentication, content negotiation, and security
• Every step in the chain can fail or add latency -- understanding the chain helps you debug and optimize