How HTTP works in one exchange
HTTP (Hypertext Transfer Protocol) works as a series of request and response exchanges. A client, usually a browser, sends a request naming a method and a resource, such as GET /pricing. The server answers with a status code, headers and usually a body, such as the HTML of the page.
Before the first request can go out, the browser has to find the server and open a connection to it. Loading a page then repeats the exchange for the HTML and for every stylesheet, script, image and API call the page needs.
The life of one request, step by step
Opening https://example.com/pricing with nothing cached takes these steps:
- The browser resolves example.com to an IP address through DNS, unless the browser or operating system already has the answer cached.
- It opens a TCP connection to that address on port 443, or port 80 for a plain http:// URL. The three-way handshake costs one round trip.
- For HTTPS, a TLS handshake follows. The server presents its certificate, the browser checks it against the hostname and its trusted authorities, and both sides agree on encryption keys. TLS 1.3 needs one more round trip for this.
- The browser sends the request: the method and path (GET /pricing), a Host header naming example.com, and headers such as Accept, Accept-Encoding and Cookie.
- The server returns a response: a status line such as 200 OK, headers such as Content-Type and Cache-Control, and the HTML body.
- The browser parses the HTML, finds the stylesheets, scripts and images it references, and requests each of them, reusing the open connection where it can.
Why connections are reused
A new connection costs round trips before any HTTP data moves: one for TCP and at least one more for TLS. On a mobile network with long round-trip times, that setup can take longer than transferring a small file.
HTTP/1.1 keeps connections open by default, so later requests to the same server skip the handshakes. Either side can end the connection with a Connection: close header or by closing it after a period of inactivity.
The limit of HTTP/1.1 is that each connection carries one request at a time. Browsers work around it by opening several parallel connections to each host.
HTTP/1.1, HTTP/2 and HTTP/3 compared
All three versions share the same semantics, defined in RFC 9110: the same methods, status codes and headers. They differ in how those messages travel over the network.
To see which version a page used, open the Network panel in your browser's developer tools and turn on the Protocol column.
- HTTP/1.1 (RFC 9112) sends messages as plain text over TCP, one request at a time per connection.
- HTTP/2 (RFC 9113) sends binary frames and multiplexes many requests as parallel streams over one TCP connection, with compressed headers. One lost TCP packet still stalls every stream on that connection until it is resent.
- HTTP/3 (RFC 9114) runs over QUIC, which uses UDP and builds TLS 1.3 into its own handshake. A lost packet delays only the stream it belongs to. Browsers usually learn that a server supports HTTP/3 from an Alt-Svc header or a DNS HTTPS record, so a first visit may still use HTTP/2.
Statelessness, and how cookies add state
HTTP is stateless: each request carries everything the server needs to handle it, and the protocol keeps no memory of earlier requests. Any server behind a load balancer can then answer any request, but the protocol alone can't tell that two requests came from the same person.
Cookies add that state. The server sends a header such as Set-Cookie: session_id=8f3a2c91; Secure; HttpOnly, and the browser stores it. On later requests to the same site the browser sends it back in a Cookie header, and the server uses the value to find the session.
APIs often carry state with a token in the Authorization header instead. Either way, the credential travels with every request, so it should only ever be sent over HTTPS.