The HTTP2 specification was officially released in May 2015, and most browsers and servers already support the protocol:

(2018-04-09)

As a better protocol that enhances, complements, and refines HTTP1.x, it’s worth getting to know it well and doing wonderful things with it.

1 Past and present

We have been using Http1.x for quite some time since the release of HTTP1.1 in 1997, when it was last modified in 1999, but with the explosion of the Internet in the last decade, certain features specified in the protocol at that time are no longer adequate for the needs of modern networks.

Http1.x has the following fatal flaws :(take browser-to-server as an example)

  • The protocol stipulates that the client can only have two concurrent connections to the same domain (the browser implementation is generally 2 to 8), but the average modern web page needs to load 40 resources
  • Head of line blocking problem: Requests on the same connection need to be sent and received sequentially
  • Based on text protocols, request and response headers are very large and incompressible.
  • You cannot control the response priority and must respond in the order requested.
  • Only one-way requests, that is, what the client requests, the server can only return.

The above problems seriously affect the efficiency and flexibility of modern Internet information exchange, at this time, more modern and efficient communication protocol HTTP2 emerged.

HTTP2 addresses these issues using techniques such as multiplexing, HPACK header compression, stream + binary frames, and stream priority.

2 HTTP2

HTTP2’s predecessor is the SPDY protocol (a Google-led application layer protocol that enhances HTTP1), and the first draft is based on the SPDY3 specification. HTTP2 must overcome performance limitations, improve transport performance, and achieve low latency and high throughput without changing HTTP/1.x semantics, methods, status codes, URIs, and header fields.

Features of HTTP2 include:

  1. The content is transmitted using binary protocols
  2. Use frames as the minimum transfer unit
  3. multiplexing
  4. The first compression
  5. Server push
  6. Priorities and dependencies
  7. Can be reset
  8. Flow control
  9. The HTTPS RFC specification does not require TLS to be mandatory for HTTP2, but all browser and server implementations around the world currently implement HTTP2 based on HTTPS

2.1 the binary

In the http1.x era, both the content and headers were text /ASCII encoded, which made it easy to see the content directly from the request, but it made it extremely difficult to implement concurrent transmission (with Spaces or other characters, it was difficult to determine the start and end of the message). This problem can be avoided by using binary transport, since there are only ones and zeros transmitted, and the different types of content can be easily identified by formatting the “frames” specification in point 2 below. There is one obvious benefit to using binary at the same time: smaller transfer volumes.

2.2 Binary Framing

HTTP2 adds a binary frame division layer between the application layer (HTTP2) and the transport layer (TCP or UDP).

A Frame is the smallest unit of transmission in HTTP2 communication. All frames begin with a fixed nine-octet header, followed by a payload of variable length

Frame structure + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | Length Length (24) | + -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | Type Type (8) | logo Flags (8) | + + -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | R | Stream flow Identifier Identifier (31) | + + = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = + | Frame load Frame content (0...). . +---------------------------------------------------------------+Copy the code

The specification defines 10 different frames, the most basic of which correspond to http1.x DATA and HEADERS respectively.

A real HTTP2 request would look like this:

Multiplex and flow

The Stream Identifier mentioned in the previous section associates each frame transmitted over an HTTP2 connection with a “Stream”. A stream is an independent, bidirectional sequence of frames that can be exchanged continuously between a server and a client over an HTTP2 connection. Each single HTTP2 connection can contain multiple concurrent streams interlaced with frames from both ends. Streams can be created and used by the client/server side, shared by both sides, or closed by either side. In streams, the order in which each frame is sent is critical. The receiver processes frames in the order in which they are received.

HTTP2 > < span style = “box-width: 100%; clear: both; min-height: 1em;

A “stream” is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. –rfc7540 StreamsLayer

A “stream” is a logical concept (there is no such thing as a real transport stream), an independent bidirectional sequence of frames exchanged between the client and server in an HTTP2 connection, which is why a stream is also quoted in the specification. As you can see from the previous section, HTTP2 transfers in frames. A stream is a grouping of frames. The answer lies in multiplexing.

Multiplexing is a core technical point to address http1.x defects first (concurrency) and second (HOLB header). Here we need to take 🌰 to illustrate:

Suppose you have established a TCP connection, and now you need the client to make two requests, which looks like this from a flow point of view:

But there is only one actual TCP connection, and two frames can’t really reach the server “at the same time.” Multiplexing is more like the CPU’s concept of processing tasks concurrently, not in parallel. This conclusion can also be drawn from the specification using the term Stream Concurrency instead of Stream Parallelism, so the actual transfer looks like this:

Three things to note in the diagram above:

  1. Frames in the same stream are interlaced!
  2. Header frames must precede data frames, because both clients and servers rely on information from Header frames to parse data frames!
  3. Frames that arrive first do not necessarily return first, fast frames can return first!

It is this first property that explains the need for a logical set of “flows”. At the same time, this frame-stream-join combination solves the problem of request concurrency (connecting multiple requests at one time) and HOLB header (sending simultaneously, asynchronous response).

HTTP/2: The Future of the Internet by Akamai Company official Demo, you can see HTTP2 compared to the previous HTTP1.1 performance improvement.

HTTP1.1

HTTP2

In the past, we have found that the key to HTTP performance optimization is not high broadband, but low latency.

As can be seen from the figure above, when the bandwidth reaches a certain speed, there is little improvement in the page loading speed, but with the reduction of latency, the page loading time will correspondingly continue to decrease. The sudden and short nature of HTTP connections becomes very inefficient due to the slow start characteristic of TCP connections called tuning. HTTP2 can use TCP connections more efficiently by allowing all data streams to share the same connection, allowing high bandwidth to truly serve HTTP’s performance gains.

The above is purely personal understanding, if there is any wrong, please feel free to point out and discuss together, thank you!

2.4 compressed

We all know that the HTTP protocol itself is stateless: each request is unrelated, and each request needs to carry all the details that the server needs. For example, request 1 sends the message “I am user A” to the server, and request 2 sends the message “Change my user name XX”. If request 2 does not carry the message “I am user A”, the server does not know which user name to change.

This is obviously not in line with the current Web application system architecture, because general systems require authentication, logging, security verification and other restrictions, so it is necessary to obtain the information of the current user. For security and performance reasons, we cannot include such information in the message body. Previous solutions to HTTP2 used Cookies, server sessions, and so on to simulate “state.” The disadvantage of using Cookies is that each request needs to carry a huge amount of repeated information and cannot be compressed. Suppose that the header of a request is 2KB, then 100 requests will be repeated 200Kb of information, which is a huge waste of bandwidth.

HTTP2 adds two features to address the above issues:

  • HPACKThe algorithm, designed specifically for head compression, is also specified in a separate draft.
  • Header tables, HTTP2 uses “header tables” on both the client and server sides to track and store key-value pairs previously sent. For the same data, it is no longer sent through each request and response. Generic key-value pairs (user agents, acceptable media types, and so on) that hardly change during communication need only be sent once.

2.5 Server Push

This feature is often referred to as cache push. The main idea is that when a client requests resource X and the server knows that it probably also needs resource Z, the server can proactively push resource Z to the client before the client sends the request. This feature helps clients cache Z for future use.

Server push requires the client to explicitly allow the server to provide this functionality. Even so, the client can choose whether to interrupt the stream of the push. If not, the client can abort the push by sending an RST_STREAM frame.

Let’s take a look at the actual scenario: now when we visit a website, the first request is generally to obtain the Document page, and then the browser parses this page. When it needs to obtain resources (CSS, JS, images, etc.), it initiates the request to obtain resources, as shown below:

【 Traditional practice 】

In order to speed up the process and reduce the white screen time, the traditional approach is to inline all the resources required by the home page into the Document, as well as merge resources such as CSS Sprites, JS compression merge, etc. The diagram below:

【 HTTP2 】

In the HTTP2 scenario, if the client requests a Document and the server knows what resources are required for the page, it can return those resources as well:

Note: actively pushed resources can be cached by the browser!

The problem is, if the client has already cached the resource, isn’t it wasteful for the server to push the same resource to the client every time?

A: This does happen, so the IETF team is working on a technical specification called cache-digest to help clients proactively tell servers which resources are already cached and do not need to be sent again.

For comparison of the impact of server push on web page performance and the use of CDN, please refer to the following two articles:

  1. measuring-server-push-performance
  2. http://www.ruanyifeng.com/blog/2018/03/http2_server_push.html

Conclusion: Using HTTP2’s multiplexing and server push capabilities does not mean that the use of CDN can be reduced or even discarded, because CDN can bring about real geographical delay reduction that HTTP2 cannot solve. Instead, we should consider how to combine HTTP2 and CDN. Further improve the efficiency and stability of network services and reduce latency.

2.6 Priorities and Dependencies

Each stream contains a priority (also known as a “weight”) that is used to tell the peer end which stream is more important. When resources are limited, the server chooses which streams to send first based on priority.

With PRIORITY frames, the client can also tell the server which other streams the current stream depends on. This feature allows clients to establish a “tree” of priorities, with all “sub-streams” depending on the completion of the transmission of the “parent stream”.

Priorities and dependencies can be changed dynamically during transport. This allows the browser to specify which image has higher priority when the user scrolls a page full of images. Or when you switch tabs, the browser can elevate the priority of streams that are included in the new page.

2.7 can be reset

One drawback of http1.x is that it is very difficult to interrupt an HTTP message with an exact content-Length value after it has been sent. Of course, you can usually break the entire TCP connection (but not always), but this comes at the cost of re-establishing a new TCP connection with a three-way handshake.

A better solution is to terminate only the currently transmitted message and resend a new one. In HTTP2, we can implement this requirement by sending RST_STREAM frames to avoid wasting bandwidth and breaking existing connections.

2.8 Flow Control

Each HTTP2 stream has its own public traffic window that restricts the other end from sending data. If you happen to know how SSH works, the two are very similar.

For each stream, each end must tell the other that it has enough room to process new data, and the other end is only allowed to send so much data until the window is enlarged.

Only data frames are subject to flow control.

conclusion

Let’s summarize the benefits of using HTTP2:

  • Smaller transmission volume, smaller or omit duplicate header messages
  • Breaking the original TCP connection concurrency limit, using a TCP connection can achieve multiple requests concurrency, single link can also reduce the pressure on the server (less memory and CPU usage)
  • To resolve HOLB header issues, slow requests or requests sent first do not block the return of other requests
  • Combined with CDN, it provides content distribution agent service with higher real-time performance and lower delay, greatly reducing the white screen time
  • Controllable data transfer priority allows for more flexible and powerful page control
  • The ability to stop (reset) data transmission without breaking the TCP connection

This article is mainly about learning notes and personal understanding, first published in Xlaoyu.info.

Reference article:

  1. Ideal HTTP Performance is written by Mark Nottingham, Chair of THE IETF HTTP Working Group and Chief Architect at Akamai.
  2. TCP those things
  3. HTTP2 overview
  4. HTTP2 interpretation
  5. HTTP/2 is here, let’s optimize! Ilya Grigorik, Velocity SC 2015
  6. rfc7540
  7. HTTP2 summary
  8. Fantastic daily for HTTP2.0 — AlloyTeam