Networking

Before the first byte of a page arrives, the browser has to find the server and agree how to talk to it. Each step is a round trip (RTT): a message there and an answer back, bound by distance and the speed of light, not bandwidth.

• Parse the URL, then DNS turns the host name into an IP address (cached by the browser, the OS and resolvers; see Origins, DNS and CORS).
• TCP handshake (SYN, SYN-ACK, ACK): one round trip to open a connection.
• TLS handshake for HTTPS: one round trip with TLS 1.3, two with TLS 1.2. HTTP/3 merges transport and TLS into one.
• Then the HTTP request: one more round trip plus the server's time. That total is the Time to First Byte.
• A reused (kept-alive) connection skips everything but the request, which is why browsers keep connections open and why preconnect helps.

IP only does its best: packets can be lost, duplicated or arrive out of order. TCP numbers every byte, waits for acknowledgements, resends what is missing and hands the data over in order. UDP skips all that: no connection, no guarantees, less delay.

• Slow start: a new connection may send only about 10 packets (~14 KB) before waiting for an acknowledgement, then doubles each round trip. Small first responses arrive fastest.
• Loss is read as congestion: the window is cut in half and grows slowly again, so a lossy network hurts far more than its loss rate suggests.
• Head-of-line blocking: because data is delivered in order, one lost packet holds back everything after it until it is resent.
• UDP suits live audio and video, games and DNS, where late data is useless; QUIC builds its own reliability on UDP so it can avoid TCP's limits.

HTTP is a text-shaped conversation: a request (method, path, headers, optional body) and a response (status code, headers, optional body). It is stateless: every request carries what the server needs, usually including a cookie or token.

• Methods: GET reads (safe, cacheable), POST creates or acts, PUT replaces, PATCH changes part, DELETE removes. GET, PUT and DELETE are idempotent: repeating them has the same effect, so they can be retried.
• Status codes: 2xx success, 3xx redirect or cached, 4xx the client's fault, 5xx the server's. Return the precise one: 201 with a Location, 401 vs 403, 404, 429 with Retry-After.
• Headers carry the metadata: Content-Type, Accept, Authorization, Cache-Control, Set-Cookie, CORS headers.
• fetch() only rejects on network failure; a 404 or 500 still resolves, so check response.ok. It follows redirects for you.

The fastest request is the one never sent. The server says with Cache-Control how long a response stays fresh; after that the browser revalidates it cheaply instead of downloading it again.

• max-age=N: reuse without asking for N seconds. no-cache: may store, but must check first. no-store: never store (private data). private keeps it out of shared caches like CDNs.
• Revalidation: the response carries an ETag (or Last-Modified); the browser asks with If-None-Match, and 304 Not Modified means "keep your copy", with no body.
• Best pattern: hashed file names (app.3f9c.js) with max-age=31536000, immutable, and HTML with no-cache so a deploy is picked up at once.
• Scripts can't see a 304: fetch() reports the cached 200. DevTools shows "(disk cache)" or 304.

The meaning of HTTP hasn't changed since HTTP/1.1; what changed is how messages travel. Each version fixes the bottleneck of the one before.

• HTTP/1.1: text messages, one request at a time per connection. Browsers open up to 6 connections per host, which is why bundling and domain sharding were invented.
• HTTP/2: binary frames, many requests at once (multiplexing) on one connection, compressed headers (HPACK). But it still rides on TCP, so one lost packet stalls every stream.
• HTTP/3: runs on QUIC over UDP. Streams are independent, the handshake includes TLS, and connections survive a network change (Wi-Fi to mobile).
• With HTTP/2 and later, many small files are cheap again; bundle for caching and compression, not to save connections.

HTTPS is HTTP inside TLS. It gives three guarantees: confidentiality (nobody on the path can read it), integrity (nobody can change it unnoticed) and authenticity (you are talking to the real site).

• The server proves its identity with a certificate signed by a certificate authority your system trusts; the browser checks the name, the dates and the chain.
• The handshake agrees on fresh keys (forward secrecy): even a later key leak can't decrypt today's traffic.
• HSTS (Strict-Transport-Security) makes the browser use HTTPS for the site from then on, so the first insecure redirect can't be attacked.
• Browsers block mixed content (HTTP files on an HTTPS page) and keep powerful features (service workers, geolocation, the clipboard, passkeys) to secure contexts. HTTP/2 and HTTP/3 are only used over HTTPS.