HTTP/2 Protocol explained

What is HTTP?

Hypertext Transfer Protocol (HTTP) is an application protocol that is, currently, the foundation of data communication for the World Wide Web.

HTTP is based on the Client/Server model. Client/Server model can be explained as two computers, Client (receiver of service) and Server (provider of service) that are communicating via requests and responses.

A simple and abstract example would be a restaurant guest and a waiter. The guest (Client) asks (sends request) waiter (Server) for a meal, then the waiter gets the meal from the restaurant chef (your application logic) and brings the meal to the guest.

Why HTTP Revised?

Loading a Web page is more resource intensive than ever (see the HTTP Archive’s page size statistics), and loading all of those assets efficiently is difficult, because HTTP practically only allows one outstanding request per TCP connection.

In the past, browsers have used multiple TCP connections to issue parallel requests. However, there are limits to this; if too many connections are used, it’s both counter-productive (TCP congestion control is effectively negated, leading to congestion events that hurt performance and the network), and it’s fundamentally unfair (because browsers are taking more than their share of network resources).

At the same time, the large number of requests means a lot of duplicated data “on the wire”.

Both of these factors means that HTTP/1.1 requests have a lot of overhead associated with them; if too many requests are made, it hurts performance.

This has led the industry to a place where it’s considered Best Practice to do things like spriting, data: inlining, domain sharding and concatenation. These hacks are indications of underlying problems in the protocol itself, and cause a number of problems on their own when used.

What is HTTP/2?

In 2015, Internet Engineering Task Force (IETF) release HTTP/2, the second major version of the most useful internet protocol, HTTP. It was derived from the earlier experimental SPDY protocol (Developed by Google).

Main goals of developing HTTP/2 was:

• Protocol negotiation mechanism - protocol electing, eg. HTTP/1.1, HTTP/2 or other.
• High-level compatibility with HTTP/1.1 — methods, status codes, URIs and header fields.
• Page load speed improvements trough:
  • Compression of request headers
  • Binary protocol
  • HTTP/2 Server Push
  • Request multiplexing over a single TCP connection
  • Request pipelining
  • HOL blocking (Head-of-line) — Package blocking

Request multiplexing

HTTP/1.x has a problem called “head-of-line blocking,” where effectively only one request can be outstanding on a connection at a time.

HTTP/1.1 tried to fix this with pipelining, but it didn’t completely address the problem (a large or slow response can still block others behind it). Additionally, pipelining has been found very difficult to deploy, because many intermediaries and servers don’t process it correctly.

HTTP/2 can send multiple requests for data in parallel over a single TCP connection. This is the most advanced feature of the HTTP/2 protocol because it allows you to download web files asynchronously from one server. Most modern browsers limit TCP connections to one server.

This reduces additional round trip time (RTT), making your website load faster without any optimization, and makes domain sharding unnecessary.

Header compression

If you assume that a page has about 80 assets (which is conservative in today’s Web), and each request has 1400 bytes of headers (again, not uncommon, thanks to Cookies, Referer, etc.), it takes at least 7-8 round trips to get- the headers out “on the wire.” That’s not counting response time - that’s just to get them out of the client.

This is because of TCP’s Slow Start mechanism, which paces packets out on new connections based on how many packets have been acknowledged – effectively limiting the number of packets that can be sent for the first few round trips.

HTTP/2 compress a large number of redundant header frames. It uses the HPACK specification as a simple and secure approach to header compression. Both client and server maintain a list of headers used in previous client-server requests.

HPACK compresses the individual value of each header before it is transferred to the server, which then looks up the encoded information in a list of previously transferred header values to reconstruct the full header information.

Binary protocol

The latest HTTP version has evolved significantly in terms of capabilities and attributes such as transforming from a text protocol to a binary protocol. HTTP1.x used to process text commands to complete request-response cycles. HTTP/2 will use binary commands (in 1s and 0s) to execute the same tasks. This attribute eases complications with framing and simplifies implementation of commands that were confusingly intermixed due to commands containing text and optional spaces.

Browsers using HTTP/2 implementation will convert the same text commands into binary before transmitting it over the network.

Benefits:

• Low overhead in parsing data — a critical value proposition in HTTP/2 vs HTTP1.
• Less prone to errors.
• Lighter network footprint.
• Effective network resource utilization.
• Eliminating security concerns associated with the textual nature of HTTP1.x such as response splitting attacks.
• Enables other capabilities of the HTTP/2 including compression, multiplexing, prioritization, flow control and effective handling of TLS.
• Compact representation of commands for easier processing and implementation.
• Efficient and robust in terms of processing of data between client and server.
-

HTTP/2 Server Push

HTTP/2 server push allows a server to provide content to clients without waiting for a request. This can improve the time to retrieve a resource, particularly for connections with a large bandwidth-delay product where the network round trip time comprises most of the time spent on a resource.

This capability allows the server to send additional cacheable information to the client that isn’t requested but is anticipated in future requests. For example, if the client requests for the resource X and it is understood that the resource Y is referenced with the requested file, the server can choose to push Y along with X instead of waiting for an appropriate client request.

Benefits:

• The client saves pushed resources in the cache.
• The client can reuse these cached resources across different pages
.
• The server can multiplex pushed resources along with originally requested information within the same TCP connection.
• The server can prioritize pushed resources — a key performance differentiator in HTTP/2 vs HTTP1.
• The client can decline pushed resources to maintain an effective repository of cached resources or disable Server Push entirely.
• The client can also limit the number of pushed streams multiplexed concurrently.