HTTP 2.0 Protocol Detailed

One, HTTP 2.0: Improved transmission performance

The primary goal of HTTP 2.0 is to improve transmission performance with low latency and high throughput. On the other hand, HTTP's high-level protocol semantics are not affected by this version upgrade. All HTTP headers, values, and their usage scenarios will not change. any existing sites and applications that do not require any modification can run on HTTP 2.0. You do not have to modify the markup to take advantage of the benefits of HTTP 2.0. The HTTP server must run the HTTP 2.0 protocol, but most users will not be affected. Ii. The history of HTTP2.0 and its origins with Spdy

SPDY, an experimental protocol developed by Google, was released in 2009, with the main goal of reducing the load latency of Web pages by addressing some of the widely known performance constraints in HTTP 1.1 (plt,page load Time) reduced by 50% without web site authors modifying any content, minimizing deployment complexity, eliminating the need to change the network infrastructure, and working with the open source community to develop this new protocol;

Collect the authenticity data to verify the validity of this experimental protocol.

Note: In order to reduce the 50% page loading time target, SPDY introduced a new binary frame data layer to realize multi-directional request and response, prioritize, minimize and eliminate unnecessary network latency, so as to make more efficient use of the bottom TCP connection; HTTP-WG (http Working Group) introduced HTTP 2.0 to the agenda in early 2012, drawing on the lessons of Spdy and making official standards on this basis Third, HTTP2.0 in-depth exploration

Http/2.0 should meet the following conditions: compared to the HTTP 1.1, users using TCP, there is a substantial, measurable improvement in most cases, a "team head blocking" problem in HTTP, and a parallel operation that eliminates the need to establish multiple connections to the server to improve TCP utilization, especially Is the congestion control aspect; Keep the semantics of HTTP 1.1, use existing documents, including (but not limited to) HTTP methods, status codes, URIs, and header fields, and specify how HTTP 2.0 interoperate with HTTP 1.x, especially on intermediate media; clearly indicate all new extensibility mechanisms and appropriate The extension policy when. HTTP 2.0 is committed to breaking the well-known performance limits of the previous generation, but it is also an extension of the previous 1.x standard, not an alternative. The reason to increment a large version to 2.0 is mainly because it changes the way the data is exchanged between the client and the server, and HTTP 2.0 adds a new binary frame data layer IV, HTTP2.0 design and technical objectives

Http/2.0 by supporting the first field compression and sending multiple concurrent messages on the same connection, the application makes more efficient use of network resources and reduces perceived latency. Furthermore, it supports the proactive push mechanism of the server to the client.

Binary Frame Layer HTTP 2.0 binary frame layer, encapsulating HTTP messages and transferring between client and server

HTTP2.0 divides all transmitted information into smaller messages and frames, and encodes them in binary format.

Note: HTTPS is another typical example of binary frames: All HTTP messages are encoded and decoded for us in a transparent way without any modification to the application. HTTP2.0 works a little bit like

Flow, message, and frame flow: A stream is a virtual channel in a connection that can host bidirectional messages; Each stream has a unique integer identifier (1, 2 ...). n; A message: A logical HTTP message, such as a request, response, etc., consisting of one or more frames. Frames: The smallest unit of HTTP 2.0 communication, each frame contains a frame header, or at least identifies the stream to which the current frame belongs, carrying a particular type of data, such as HTTP headers, loads, and so on

All frames of HTTP 2.0 are encoded in binary, and all header data is compressed. All traffic is done on a TCP connection. HTTP 2.0 narrows the base unit of the HTTP protocol communication to a single frame that corresponds to a message in the logical stream. Correspondingly, many streams can exchange messages on the same TCP connection in parallel

Multi-directional request and response

The new binary frame layer in HTTP 2.0 breaks through these limitations and enables multiple requests and responses: the client and server can decompose HTTP messages into mutually exclusive frames and then send them in random order, and then regroup them at the other end.

The diagram contains data flows from multiple transports on the same connection: the client is transferring a data frame (stream 5) to the server, while the server is sending a sequence of frames for stream 1 and stream 3 to the client. At this point, there are 3 request/response parallel exchanges on one connection.

Splitting HTTP messages into separate frames, interleaved, and then reassembled at the other end is one of the most important enhancements to HTTP 2.0. This mechanism triggers a series of ripple effects throughout the Web technology stack, resulting in significant performance improvements.

  * Can be interleaved in parallel to send the request, the request does not affect each other;
  * can be staggered to send the response in parallel, the response to each other;
  * Use only one connection to send multiple requests and responses in parallel;
  * Eliminate unnecessary delays, thereby reducing page load time;
  * There is no need to do much more to circumvent the HTTP 1.x restrictions;

The binary frame mechanism of 1 2 3 4 5 6 7 HTTP 2.0 resolves the problem of Team head blocking in HTTP 1.x and eliminates the dependence of multiple connections on parallel processing and sending requests and responses.

Request priority after the HTTP message is decomposed into many separate frames, it is possible to optimize the staggered and transmitted order of these frames, each with a 31-bit priority value: 0 for the highest priority, and 2 for 31 to 1 for the lowest priority. The server can control resource allocations (CPU, memory, bandwidth) based on the priority of the stream, and after the response data is ready, prioritize the highest priority frames to the client. HTTP 2.0 solves all of these inefficiencies: the browser can dispatch the request immediately when it discovers the resource, specify the priority of each stream, and let the server determine the optimal response order. The request does not have to be queued, saving time and maximizing the use of each connection.

After each source has a new frame mechanism for a connection, HTTP 2.0 no longer relies on multiple TCP connections to achieve multiple stream parallelism. Each data stream is split into many frames, which can be interleaved and can be prioritized separately. HTTP 2.0 connections are persistent and require only one connection between the client and the server.
Experiments show that a client with fewer connections can definitely reduce latency. The number of total totals sent by HTTP 2.0 is almost 40% less than HTTP. Most HTTP connections are short-lived and abrupt, but TCP is only the most efficient when connecting large chunks of data over a long period of time. HTTP 2.0 enables more efficient use of TCP connections by having all data streams share the same connection.

Traffic Control HTTP 2.0 provides a simple mechanism for flow control of data flows and connections:
Flow control is based on each hop, rather than end-to-end control, the flow control is based on the window update frame, that is, how many bytes the receiver broadcasts itself to receive a data stream, and how many bytes to receive for the entire connection; The Flow control window size is updated with the window_update frame, which specifies the stream ID And the size of the window; Flow control has directionality, that is, the receiver may set any window size for each stream or even the entire connection according to its own situation; Traffic control can be disabled by the receiver, including for individual streams and for the entire connection.

Server push

A powerful new feature added to HTTP 2.0 is that the server can send multiple responses to a client request. The server pushes resources to the client without requiring a client to explicitly request them.

After HTTP 2.0 is connected, the client exchanges the settings frame with the server to limit the maximum number of bidirectional concurrent flows. Therefore, the client can limit the number of push streams, or disable the server push completely by setting this value to 0.

All pushed resources adhere to the homology policy. In other words, the server cannot push the Third-party resources to the client, but must be confirmed by both parties.

Push_promise: All server push streams are initiated by the push_promise, and the server sends a signal to the client that the resource is intended to be pushed. After the client receives the Push_promise frame, it can choose to reject this stream depending on its own requirements.

A few restrictions: The server must follow the request-response loop, and can only push the resource through the response to the request Push_promise frames must be sent before the response is returned in order to prevent the client from appearing in a race condition.

First compression (Hpack compression algorithm, while using the index mapping table compression, while coding, this table consists of static table and dynamic table)

http2.0 compresses the first metadata: using the "first table" on both the client and server side to track and store the previously sent key-value pairs, which are no longer sent through each request and response for the same data; "Header table" Always exists during the http2.0 connection lifetime and is incrementally updated by both the client and server; each new header key value pair is either appended to the end of the current table or replaces the previous value in the table.

http2.0 First differential transmission

The definition of the request and response header is basically unchanged in the HTTP2.0, except that all the header keys must be lowercase and the request lines are independent of: method, Scheme,: host,:p ath these key-value pairs.

Effective HTTP2.0 upgrades and discoveries

Most modern browsers are built with an efficient background upgrade mechanism, and clients that support HTTP2.0 must be able to discover whether the server and all intermediate devices support the HTTP2.0 protocol before initiating a new request. There are three possible scenarios: initiating a new HTTPS connection via TLS and ALPN, initiating a new HTTP connection based on previous information, and initiating a new HTTP connection without prior information.

A link in the HTTPS negotiation process is used by the ALPN (Application layer protocol negotiation). Reducing network latency is a key condition for HTTP 2.0, so it is certain that ALPN negotiation is used when establishing an HTTPS connection.

Establishing a HTTP2.0 connection through a conventional unencrypted channel requires a little more work. Because both HTTP1.0 and HTTP2.0 use the same port (80) and if the server supports any other information HTTP2.0, the client can only use the HTTP upgrade mechanism to determine the appropriate protocol through coordination:

Upgrade:http/2.0➊
http2-settings: (Settings payload) ➋ http/1.1 Ok➌ http/1.1-switching
c3/> ...

1 2 3 4 5

➊ initiates HTTP 1.1 request with HTTP 2.0 Upgrade header
➋http/2.0 SETTINGS net load Base64 URL encoding
➌ server rejects upgrade, returns response via HTTP 1.1
➍ server accepts HT TP 2.0 upgrade, switch to New frame

1 2 3 4 Brief introduction of HTTP2.0 binary frame

After the HTTP2.0 connection is established, the client and the server communicate by exchanging frames, which are the smallest units of communication based on this new protocol. All frames share a 8-byte header that contains the length, type, flag of the frame, and a reserved bit and a 31-bit stream identifier.

Initiating a new stream before sending the application data, a new stream must be created and the corresponding metadata sent, such as stream priority, HTTP header, etc.; the client initiates a new stream by sending a headers frame; the server initiates a push stream by sending a push_promise frame.

After you send the application data to create a new stream and send the HTTP header, the next step is to use a data frame. Application data can be divided into multiple data frames, the last frame to flip the End_stream field of the frame header

The HTTP 2.0 standard requires that the data frame not exceed 2 of 14-1 (16383) bytes. The length exceeds this threshold data, and the score frame is sent.

HTTP2.0 frame Data Flow analysis HTTP2.0 send requests and responses at the same time on shared connections

The IDs of 3 streams are odd, indicating that the stream 1 sent by the client-initiated server contains multiple data frames, which are the response data servers that were requested before the client, and the HEADERS frames of stream 1 and Stream 3 are interleaved, which is the sound Multiple multiplexing. The client is sending a DATA frame of stream 5 indicating that the HEADERS frame has been sent before. suggestions for optimization of HTTP2.0

Remove optimizations for 1.x each source uses a connection, and HTTP 2.0 improves performance by maximizing the throughput of a TCP connection. Remove unnecessary file merging and Picture stitching: HTTP 2.0, many small resources can be sent in parallel with the server push: Most of the resources previously embedded in the HTTP 1.x can and should be delivered through the server push.

Dual protocol Application policy same application code, dual Protocol deployment separation application code, Dual Protocol deployment Dynamic HTTP 1.x and HTTP 2.0 optimization: Some automated Web optimization framework dynamically rewrites delivery application code (including connection, flattening, partitioning, etc.) in response to request single Protocol deployment

The conversion between 1.x and 2.0

Evaluate server quality and performance HTTP 2.0 servers must understand the flow priority; HTTP 2.0 servers must handle response and delivery resources according to priority; HTTP 2.0 servers must support server push; HTTP 2.0 servers should provide implementations of different push policies.

2.0 with TLS

Two scenarios where ALPN negotiation and TLS termination may occur the TLS connection may terminate on the HTTP 2.0 server, and the TLS connection may terminate on the upstream (such as load balancer).

The first situation requires that the HTTP 2.0 server be able to handle TLS, and the second case to create an encrypted channel that sends unencrypted HTTP 2.0 streams directly to the server

Load balancer, agent and Application server to implement HTTP 2.0 communication over TLS, the Terminal server must support ALPN, terminate TLS as close to the user as possible, and if ALPN is not supported, select TCP load Balancing mode if ALPN is not supported and TCP load balancing Can not be done, then the next to the second, in the unencrypted channel using HTTP upgrade flow;