HTTP Deep Dive

Every part of the URL means something

A URL is not just a string: every segment tells the server what you want, where it lives, and how to find it.

HTTP verbs: what you want to do

Safe methods are intended for retrieval without a requested business-state change; incidental logging is still possible. Idempotent methods have the same intended effect when repeated as when applied once. A second DELETE can return a different response while the resource remains deleted, so identical responses are not required. POST is not generally idempotent, but an application can add an idempotency contract for a particular operation.

The method (verb) tells the server what action to perform on the resource. It goes in the first line of the request:

Request and response anatomy

The method describes the requested operation, the target identifies the resource, and headers carry metadata about representation, authorization, and intermediaries. A status code describes the outcome at the HTTP boundary; the body contains the representation or error details. This separation lets caches and proxies make useful decisions without understanding every application field, provided the application uses the semantics consistently.

Every HTTP interaction is a request (what the client wants) and a response (what the server sends back). Headers carry metadata about the message itself.

GET /api/v2/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJI...
Accept-Encoding: gzip, br
User-Agent: MyApp/2.1
Cache-Control: no-cache

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 245
Cache-Control: max-age=3600
ETag: "abc123def"
X-Request-Id: req_8f3k2j

{ "id": 123, "name": "Alice", "email": "a@b.com" }

Headers describe content, control caching, handle authentication, and enable features without changing the URL or body. Common groups: Authorization / Cookie;Cache-Control / ETag;Content-Type / Content-Length;Accept-Encoding / Content-Encoding.

Content negotiation

Client and server agree on the response format through headers: the same URL can return JSON, HTML, or XML depending on what the client asks for.

Accept: application/json
Accept: text/html
Accept: application/xml, application/json;q=0.9
Accept-Language: en-US, hi;q=0.8
Accept-Encoding: gzip, br

Content-Type: application/json; charset=utf-8
Content-Language: en-US
Content-Encoding: br

GET /users/123 with Accept: application/json may return {"id":123,"name":"Alice"}; a browser asking for text/html gets markup instead. Clients advertise decompressors; servers pick one and set Content-Encoding. Older clients that omit brotli still work. Compression is content negotiation: cache keys and CDNs must treat differently encoded bodies as distinct variants when appropriate.

HTTP/1.1: the workhorse

One request at a time per connection unless you open many parallel TCP pipes; simple but easy to leave bandwidth idle.

• Keep-alive reuses one TCP socket so later requests skip a fresh handshake.
• Pipelining is often disabled because FIFO responses still serialize wait time.
• Chunked transfer streams the body so large replies need not be fully buffered first.
• Head-of-line blocking lets one slow response stall later replies; browsers open ~6 connections per domain.
• Plain text headers repeat cookies and auth, so 1-2KB of bloat per request is common.

Cold TLS setup cost is summarized in Numbers to know.

HTTP/2: multiplexed streams

Many logical streams ride one TCP session with compressed headers, though TCP itself can still block everything on one lost packet.

• Multiplexing interleaves streams on one TCP connection so pages need fewer parallel sockets.
• HPACK compresses repeated headers with tables and Huffman, often cutting 85–95% of header bytes.
• Server Push was removed from Chrome in 2022; prefer 103 Early Hints for critical assets instead.
• Stream prioritization uses weights and dependencies so browsers can prefer CSS and scripts over images.

HTTP/3: QUIC and UDP

QUIC rebuilds streams atop UDP so mobility, loss recovery, and TLS integrate without inheriting every TCP limitation.

• QUIC runs over UDP with mandatory TLS 1.3 so encryption starts with the transport itself.
• A connection ID survives IP change, which keeps mobile handoffs from restarting the session.
• 0-RTT lets resumed clients send early data; weigh replay risk on non-idempotent writes.
• Each QUIC stream recovers loss alone, so one lost packet does not freeze every stream.

Search, video, edge, and mobile fleets report better rebuffer, TTFB, and tail latency where UDP/443 is open; timing floors are in Numbers to know.

Version comparison

HTTP/2 interleaves frames from several streams on one TCP connection. This removes the application-level response ordering restriction of HTTP/1.1 pipelining, but TCP still withholds later bytes after a missing segment. HTTP/3 uses QUIC streams so a loss on one stream need not block delivery on another. Neither version removes database latency, shared congestion, or the need for application deadlines.

Fit to product: HTTP/1.1 for simple internal REST and curl debugging; HTTP/2 as the default for SPAs, gRPC, and gateways; HTTP/3 when mobile loss or handshake latency dominates (see How to choose).

Performance optimization tips

server {
  listen 443 ssl http2;
  ssl_protocols TLSv1.2 TLSv1.3;
  http2_max_concurrent_streams 128;
  http2_push_preload on;
}

How HTTP stays backward compatible

Every new HTTP version can talk to older servers and clients. That is why the web did not break when HTTP/2 or HTTP/3 launched: billions of devices upgraded at their own pace.

• ALPN during TLS lets the server pick the highest version both sides understand.
• GET, POST, headers, and status codes stay the same; only framing and transport change.
• Unknown headers are ignored, so new features stay opt-in without breaking old clients.
• Alt-Svc can advertise HTTP/3 after HTTP/2; if UDP is blocked, the client stays on TCP.

Enable HTTP/3 on the CDN edge gradually; old browsers fall back. The same API can serve HTTP/3 phones, HTTP/2 tablets, and HTTP/1.1 IoT without a flag day.

Debugging questions

• Which protocol did the client actually negotiate on this request?
• Is UDP/443 blocked so HTTP/3 users quietly fall back to HTTP/2?
• Are large cookies or auth headers bloating bandwidth on every request?
• Is tail latency due to TLS setup, origin wait, packet loss, or download size?
• Are retries safe for this HTTP method and endpoint semantics?

REST on HTTP

REST is not a protocol. It is an architectural style that maps CRUD operations to HTTP verbs and resources to URLs. It is the default way APIs are built because HTTP already provides everything REST needs.

• No new protocol is needed; existing CDNs, proxies, and caches already understand HTTP.
• A GET URL is a natural cache key, so intermediary caches can serve repeats cheaply.
• Requests stay human-readable in a browser or curl, which speeds debugging.
• Stateless requests carry what they need, so you can scale app servers horizontally.
• Pain points include over-fetching, under-fetching, endpoint explosion, and costly /v1 /v2 versioning.

Those pain points helped motivate GraphQL for some large mobile clients. Resource naming, idempotency, pagination, HATEOAS, and versioning live in the dedicated REST API Design note; this section only places REST inside HTTP's ecosystem.

Correctness invariant

What must never become false

HTTP semantics stay stable across versions: a safe method stays safe, an idempotent method stays idempotent, and intermediaries must not invent authority from client-supplied identity headers. Transport upgrades (HTTP/2, HTTP/3) may change framing and latency. They must not change what a GET or POST means to the application.

Worked example: cold vs warm connect

Specify what the timing includes. In a simplified loss-free TCP plus TLS 1.3 exchange, connection setup costs roughly two round trips before a normal request; request-to-first-response adds another round trip plus server work. A warm connection avoids setup but still pays that request-response travel. Independent calls can overlap, whereas dependent calls form a serial critical path. Do not add every connection’s setup duration when estimating a parallel page load.

One API call on a new TCP + TLS 1.2 path waits for setup, then one more RTT for the response. Reuse the connection (or use HTTP/3 / 0-RTT where allowed) and setup collapses. Exact floors and the 50K QPS capacity reading are in Numbers to know.

Failure timeline: TCP HOL under HTTP/2

T0  Browser opens one HTTP/2 TCP connection; 12 streams multiplexed
T1  One packet for stream #3 is lost on a 2% lossy mobile path
T2  TCP holds the connection until retransmission; streams #1–#12 stall
T3  Page looks "hung" even though only one image stream needed the packet
T4  HTTP/3/QUIC recovers that stream independently; others keep flowing

HTTP/2 fixed HTTP-level head-of-line blocking; TCP loss can still freeze every multiplexed stream until recovery (same idea as the generations section above).

Exercises

Topic-specific references

• RFC 9110: HTTP Semantics: methods, status codes, caching rules that versions must preserve.
• RFC 9114: HTTP/3: HTTP over QUIC framing and stream independence.
• RFC 9000: QUIC: connection IDs, loss recovery, and migration.

What to remember

Default to HTTP/2 for many web clients and service calls (including gRPC), and enable HTTP/3 on CDN/edge for mobile. Biggest wins come from cutting unnecessary round trips: 0-RTT, header compression, and multiplexing. In interviews, say HTTP/2 solves HTTP-level head-of-line blocking but not TCP-level blocking, and HTTP/3 addresses both.