How HTTP Works — From Request to Response
Learn/Networking/

How HTTP Works — From Request to Response

2026-03-22

HTTP (Hypertext Transfer Protocol) is the protocol behind every web page, REST API, GraphQL endpoint, and webhook. When your browser loads a page, it speaks HTTP to the server. When your backend calls a third-party API, it speaks HTTP. When a CI system triggers a deployment, it speaks HTTP.

Tim Berners-Lee invented HTTP alongside HTML and the World Wide Web at CERN in 1989-1991. The protocol has evolved through four major versions, each solving problems exposed by the previous one.

How Does HTTP Work?

HTTP follows a request-response pattern. The client sends a request and the server sends a response.

A request has four parts:

GET /learn/networking HTTP/1.1
Host: 8vast.io
Accept: text/html
  1. Method — what operation to perform (GET, POST, PUT, DELETE).
  2. Path — which resource (/learn/networking).
  3. Version — which HTTP version (HTTP/1.1, HTTP/2, HTTP/3).
  4. Headers — metadata about the request (Host, Accept, Authorization, etc.).

A response has three parts:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4521

<!DOCTYPE html>...
  1. Status code — what happened (200 success, 301 redirect, 404 not found, 500 server error).
  2. Headers — metadata about the response (Content-Type, Cache-Control, etc.).
  3. Body — the actual content (HTML, JSON, binary data, or nothing).

The status codes follow a pattern: 2xx means success, 3xx means redirect, 4xx means client error, 5xx means server error. The first digit tells you the category; the rest tells you the specifics.

What Are the HTTP Methods?

MethodPurposeIdempotentBody
GETRead a resourceYesNo
POSTCreate a resource or trigger an actionNoYes
PUTReplace a resource entirelyYesYes
DELETERemove a resourceYesUsually no
PATCHPartially update a resourceNoYes
HEADGET without the body (check if resource exists)YesNo
OPTIONSAsk what methods are allowedYesNo

Idempotent means calling it multiple times has the same effect as calling it once. GET /user/123 always returns the same user. DELETE /user/123 removes them once — calling it again changes nothing. POST /users creates a new user each time.

This distinction matters for retries. If a request times out and the method is idempotent, the client can safely retry. If it's not idempotent (like POST), retrying might create a duplicate.

How Did HTTP/1.1 Work?

HTTP/1.0 (1996) opened a new TCP connection for every request. Loading a page with 50 images meant 50 TCP handshakes — each adding a round trip of latency.

HTTP/1.1 (1997) fixed this with persistent connections — keep the TCP connection open and send multiple requests over it. But requests were still sequential: request 1, wait for response 1, request 2, wait for response 2. A slow response blocked everything behind it.

Browsers worked around this by opening 6 parallel TCP connections per domain. That helped, but each connection still had its own handshake cost, and 6 connections shared the congestion window inefficiently.

What Changed with HTTP/2?

HTTP/2 (2015) introduced multiplexing — many requests and responses flowing over a single TCP connection as independent streams.

HTTP/1.1 — Sequential TCP connection GET /index.html GET /style.css GET /app.js → waiting...

HTTP/2 — Multiplexed Single TCP connection Stream 1: GET /index.html → response Stream 2: GET /style.css → response Stream 3: GET /app.js → response

Key improvements over HTTP/1.1:

  • Multiplexing — all requests share one connection. No waiting for the previous response.
  • Header compression (HPACK) — HTTP headers are repetitive (same Host, User-Agent, Cookie on every request). HPACK compresses them, sometimes by 90%.
  • Server push — the server can send resources before the client asks (e.g., push style.css along with index.html). In practice, this feature was rarely used and is being deprecated.
  • Binary framing — HTTP/2 uses a binary format instead of text. More efficient to parse, harder to read with tcpdump.

But HTTP/2 has one fundamental problem: it still runs on TCP. When a packet is lost on the TCP connection, all streams are blocked until the lost packet is retransmitted — even streams whose data arrived fine. This is head-of-line blocking at the transport layer.

How Does HTTP/3 Fix This?

HTTP/3 (2022) replaces TCP with QUIC. QUIC runs on UDP and implements its own reliable, encrypted transport with truly independent streams.

HTTP/1.1HTTP/2HTTP/3
TransportTCPTCPQUIC (on UDP)
MultiplexingNo (sequential)Yes, but TCP-limitedYes, independent streams
EncryptionOptional (HTTPS)Practically requiredAlways (QUIC mandates it)
HandshakeTCP + TLS = 2-3 RTTTCP + TLS = 2-3 RTT1 RTT (0 for repeat)
Head-of-line blockingPer connectionTransport-levelNone
Connection migrationNo (IP-bound)No (IP-bound)Yes (connection IDs)

HTTP/3 also uses QPACK instead of HPACK for header compression — adapted for QUIC's independent streams where headers may arrive out of order.

As of 2026, approximately 30% of web traffic uses HTTP/3. Google, Cloudflare, Meta, and most CDNs support it. Browsers automatically negotiate the best version — if the server supports HTTP/3, the browser upgrades; otherwise it falls back to HTTP/2 or HTTP/1.1.

What Is the Difference Between HTTP and HTTPS?

HTTP sends everything in plaintext. HTTPS wraps HTTP in TLS encryption — the same content, the same protocol, but encrypted in transit.

Today, HTTPS is the default. Browsers mark plain HTTP sites as "Not Secure." Search engines rank HTTPS sites higher. Let's Encrypt provides free certificates, removing the cost barrier. HTTP/3 goes further: QUIC mandates encryption, so HTTP/3 is always encrypted with no unencrypted option.

How Does a Web Page Load?

Putting it all together — what happens when you navigate to https://8vast.io/learn/networking:

  1. DNS — resolve 8vast.io to an IP address (20-120ms first time, cached after).
  2. TCP + TLS handshake — establish a connection and negotiate encryption (1-3 round trips for HTTP/2, 1 round trip for HTTP/3).
  3. HTTP request — GET /learn/networking HTTP/2 with headers.
  4. HTTP response — 200 OK with the HTML document.
  5. Parse HTML — the browser discovers more resources: CSS, JavaScript, images, fonts.
  6. Parallel requests — HTTP/2 or HTTP/3 loads all resources over the same connection simultaneously.
  7. Render — the browser builds the page from the loaded resources.

Each step builds on the previous lessons: DNS resolution uses UDP, transport uses TCP or QUIC, encryption uses TLS, and the application speaks HTTP.

Next Steps

HTTP sits at the top of the stack you've been building. From here:

Prerequisites

Next

Related

References

Referenced by