HTTP protocol is fundamental to the Internet. It’s a simple request-response protocol where the request is initiated by the client, typically a web browser
HTTP 1.0, 1.1, 2 and 3
However, HTTP is so pervasive that it’s also used to communicate between machines through APIs. Most important chatacteristics of HTTP are:
- both request and response contain a set of headers
- both request and response may contain a body
- body can be anything: HTML, JSON, binary image, MP3, etc.
- request contains the name of the resource we’d like to access
- accessing is described using a few verbs, like
- a response starts with code, most commonly used are
404 Not Found
But rather than explaining the basics, I’d like to discuss the differences between protocol versions. They are very important from performance perspective.
So the first major version of the protocol was 1.0.
Version 1.0 has one flaw: it opens a new TCP/IP connection for each request.
It’s a big deal: creating a new network connection requires a few round-trips.
Also, TCP/IP has a built-in mechanism called slow start.
Each new connection is initially rather slow but gets faster over time.
This mechanism adapts to varying network conditions dynamically.
Unfortunately, if you keep opening and closing new connections, they may never reach their full potential.
To overcome this issue a
Keep-alive request header was added as an afterthought.
It instructs the server to keep connection open even after finishing with the response.
Another request may come through the same connection.
This is called a persistent connection.
In HTTP 1.1 persistent connections are enabled by default and you have to disable them explicitly using
Connection: close header.
Another important addition was HTTP pipelining.
In HTTP 1.0, even with persistent connections, it wasn’t allowed to send second request before response to the first request was fully received.
Pipelining allows sending multiple requests at once and then simply waiting for responses.
This reduces network round-trips and overall waiting time.
However, keep in mind that responses must be delivered in the same order as requests.
So if your first response is really slow, server is not allowed to return subsequent faster responses.
This is called head-of-line-blocking.
HTTP/3 is not yet released, but some browsers already support it. It is based on QUIC protocol and operates using UDP, rather than TCP/IP. It turned out that head-of-line-blocking emerged one more time on TCP/IP level, unaware of independent streams in HTTP/2. Moving on to UDP tries to solve this problem. Lost packets no longer cause the whole TCP/IP connection to recover and retry. Only a single stream is affected.