GitHub

HTTP

LogoHTTP | MDN

About

Follows a classical client-server model, with a client opening a connection to make a request, and then waiting until it receives a response from the server.

It's a stateless protocol (doesn't retain session state from previous requests), although with the addition of cookies state was added to some client-server interactions. (making HTTP stateless but not sessionless)

Stateless Protocols

Stateless protocols improve:

  • Visibillity: Since a monitoring system don't need to look beyond a single request to determine it's full nature.

  • Reliability: It eases the task of recovering from partial failures.

  • Scalability: Not having to store session states allow the server to quickly free resources and simplifies implementation.

But may decrease network performance by increasing the repetitive data sent in a series of requests, since data cannot be reused.

Designed in the early 1990s it has evolved over time.

It's an application layer protocol sent over TCP, or over a TLS-encrypted TCP connection.

Versions

HTTP/0.9

Was extremely simple, requests consisted of a single line and started with only possible method GET followed by the path to the resource.

request
GET /page.html
response
<html>
  Simple page.
</html>

There were no headers in the request, so only HTML files could be transmitted.

There were no status codes.

HTTP/1.0

First published in 1996.

With:

  • Versioning information HTTP/1.0 now appended to the GET line.

  • Status code was also sent at the beginning of the response.

  • The concept of headers was introduced for request and responses.

  • Other types of documents could be transmitted thanks to the Content-Type header.

request
GET /page.html HTTP/1.0
User-Agent: ...
response
HTTP/1.0 200 OK
Date: ...
Server: ...
Content-Type: text/html
<html>
  Simple page.
</html>

HTTP/1.1 (Standardized)

First published in 1997.

The standard version. It clarified ambiguities and more improvemets:

  • Reusable connections.

  • Pipelining was added, allowing a second request to be sent before the answer to the first was fully transmitted. (lowering latency of communication)

  • Chunked reponses now supported.

  • Additional cache controls added.

  • Content negotiation, including language, encoding and type were introduced.

  • Thanks to Host header, the ability to host different domains from the same IP address allowed server collocation.

request
GET /en-US/docs/Glossary/CORS-safelisted_request_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: ...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
response
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

HTTP/2

With the increase of complexity from web pages, Google implemented in the early 2010 SPDY, serving as the foundation for the version 2 of the protocol.

Officially standardized in 2015.

Made some changes related to the last version:

  • It's now a binary protocol rather than a text protocol.

  • It's a multiplexed protocol, so parallel requests can be made over the same connection.

    • But still runs over a single TCP connection, so packtet loss detection and retransmission can block all streams.

  • It compresses headers, removing duplication and overhead of data transmissions, since headers are often similar among sets of requests.

  • Smarter CDN caching mechanism with Alt-Svc.

  • Introduction of client hints allowing the client to proactively communicate information about its requirements and hardware constraints.

To update from HTTTP/1.1, only an up-to-date server that communicate with a recent browser was necessary, without significant work for web developers.

HTTP/3

The next major version now uses QUIC instead of TCP for transport layer portion.

Designed to provide much lower latency, QUIC runs multiple streams over UDP and implements packet loss detection and retransmission independently for each stream.

More Details

Connection Management

Short-lived connections

The original model of HTTP, and the default one in HTTP/1.0.

Each HTTP request is completed on its own connection, this means a TCP handshake happens before each request and these are serialized.

TCP handshake itself is time-consuming, but TCP connections adapts to it load, becoming more efficient with more sustained connections.

Short-lived on the other hand don't make use of this efficiency feature of TCP.

In HTTP/1.1 this model is used if Connection header value is set to close.

Persistent connections

A persistent connection is onw which remains open for a period of time, and can be reused for several requests. (also known as keep-alive connection)

It saves the need for a new TCP handshake.

Persistent connections have drawbacks, consuming server resources even when idling.

In HTTP/1.1 persistent connection are default, even if not using Connection header.

Pipelining

By default HTTP requests are issued sequentially, where the next request is only issued once the response to the current has been received.

Pipelining is the process to send successive requests over the same persisten connection without waiting for the answer, avoiding latency of the connection.

Not all types of HTTP can be pipelined; only idempotent methods (GET, HEAD, PUT and DELETE), since should a failure happen, the pipeline content can be repeated.

Domain Sharding

Deprecated technique.

Where client open several connection to each domain, sending parallel requests.

There is a risk of triggering DoS protection on the server side if attempting to open more than 6 parallel connections.

Messages

HTTP messages are how data is exchanged between server-client.

Requests

Messages sent by the Client to the Server, to initiate an action on the server.

  1. Request line: The first line of the request that consist of:

    1. Method: like Get, Put, ..., or HEAD or OPTIONS. These describes the action to be performed.

    2. Target: usually a URL, or absolute path of the protocol, port and domain.

    3. Version: Protocol version which defines the structure of the remaining message.

  2. Headers: contains different header key and values and can be divided in several groups.

  3. Body: the request body is optional, and some Methods shoudn't have one.

{ {Method} {Target} {Version} }
{Headers}
{Body}

Responses

Messages sent by the Server to the Client.

  1. Status line: The first line of the response that consist of:

    1. Version: Protocol version.

    2. Status Code: Indicating success or failure of the request.

    3. Status Text: Brief, purely informational, textual description of the status code.

  2. Headers: contains different header key and values and can be divided in several groups.

  3. Body: the response body is also optional, when only a status code is sufficient.

{ {Version} {Status Code} {Status Text} }
{Headers}
{Body}

HTTP/2 Frames

It divides HTTP/1.x messages into frames which are embedded in a stream.

Data and header frames are separated, which allows header compression.

The streams can be combined together with multiplexing, allowing more efficient use of underlying TCP connections.

HTTP frames are now transparent to Web developers and NO changes are needed in the APIs to use HTTP frames.

Compression

An important way to increase the performance of a website and lower bandwidth needs. For some document, size reduction of up to 70%.

In practice, web developers don't need to implement compression mechanisms, browsers and servers implemented already. It just needs to be configured.

Caching

HTTP cache stores a response associated with a request and reuses the stored response for subsequent requests.

Drawing

Private Caches

A private cache is tied to a specific client, typically a browser cache.

If a response contains personalized content and you want to store the response only in the private cache, specify a private directive.

Cache-Control: private

Shared Caches

Are located between the client and the server and can store responses that can be shared among users.

Proxy Caches

  • Some proxies implement caching to reduce traffic out of the network.

  • Usually managed by the service developer, so must be controlled by appropriate headers.

  • Cache-Control: no-store, no-cache, ...

Managed Caches

  • Are explicitly deployed by service developers to offload the origin server.

  • Like reverse proxies, CDN and service workers in combination with Cache API.

  • Cache-Control: no-store

HTTP Structure

Headers

PreviousRabbitMQNextREST

Last updated