As a new version of the protocol, HTTP 2.0 must have many details, but for application developers and service providers, there are only a few major impacts.
New Binary Format
When http1.x was born, it was a clear text protocol, and its format consisted of three parts: start line (request line or status line), header, and body. To identify these three parts, protocol analysis is required. The analysis of http1.x is based on text. The format analysis based on the text protocol has natural flaws. The representation of the text is diverse, and there must be many scenarios for robustness considerations. The binary is different, and only the combination of 0 and 1 is recognized. Based on this consideration, the protocol analysis of http2.0 decided to use the binary format, which is convenient and robust to implement.
Some people may think that text-based http debugging is much more convenient. Many tools such as firebug, chrome, and charles can debug and modify requests in real time. In fact, many requests now go through https, and you must have a private key to debug https requests. Most of the requests in http2.0 should go through https, so the convenience of debugging cannot be a strong consideration. Tools such as curl, tcpdump, and wireshark are more suitable for http2.0 debugging.
http2.0 defines frames one by one in binary format, which is compared with the format of http1.x as shown in the following figure:
The format definition of http2.0 is closer to the way of the tcp layer, and the way of this two mechanisms is very efficient and streamlined. length defines the start to end of the entire frame, type defines the type of frame (10 types in total), flags use bits to define some important parameters, stream id is used for flow control, and the rest of the payload is the body of the request.
Although it seems that the format of the protocol is completely different from http1.x, in fact http2.0 does not change the semantics of http1.x, but re-encapsulates the header and body of http1.x with a frame. When debugging, the browser will even automatically restore the http2.0 frame to the http1.x format. The specific protocol relationship can be represented by the following figure:
[
multiplexing
A major problem to be solved by http2.0 is multiplexing (MultiPlexing), that is, connection sharing. The stream id mentioned in the protocol analysis above is used as a connection sharing mechanism. A request corresponds to a stream and is assigned an id, so that there can be multiple streams on a connection, and the frames of each stream can be randomly mixed together, and the receiver can attribute the frames to different requests according to the stream id.
As mentioned earlier, after connection sharing, priority and request-dependent mechanisms are needed to solve the problem of blocked key requests. Each stream in http2.0 can set priority (Priority) and dependency (Dependency). The stream with high priority will be processed first by the server and returned to the client, and the stream can also depend on other sub streams. Both priority and dependencies can be adjusted dynamically. Dynamic adjustment is very useful in some scenarios. Suppose a user quickly slides to the bottom of the product list when browsing products in your app, but the previous request is sent first. If the priority of the latter request is not set higher, the user's current The pictures browsed will not be downloaded until the end. Obviously, the experience is not set as a priority. In the same way, dependency is also useful in some scenarios.
header compression
As mentioned earlier, the header of http1.x is easy to expand due to cookie and user agent, and it has to be sent repeatedly every time. http2.0 uses an encoder to reduce the size of the headers that need to be transmitted, and each communication party caches a table of header fields, which not only avoids the transmission of repeated headers, but also reduces the size of the headers that need to be transmitted. An efficient compression algorithm can greatly compress the header, reduce the number of sent packets and reduce the delay.
A little knowledge point is popularized here. Now everyone knows that tcp has the feature of slow start. After the three-way handshake, the tcp segment is sent. The number of segments that can be sent for the first time without ack is determined by the size of the initial tcp window. The initial tcp window will vary depending on the implementation of the platform, but it is generally 2 segments or 4k in size (a segment is about 1500 bytes), that is to say, when the size of the packet you send exceeds this value, you must Subsequent packets cannot be sent until the previous packets are acked. Obviously, the delay is higher in this case. The initial window is not as big as possible, too large will lead to congestion of network nodes, and the packet loss rate will increase. The header of http is now inflated to the point that it may exceed the value of the initial window, so it is even more important to compress the header.
Choice of Compression Algorithm
SPDY/2 uses the gzip compression algorithm, but the two attack methods BREACH and CRIME that appeared later make the content of SPDY that uses ssl can be cracked. Finally, a comprehensive consideration is used.HPACK compression algorithm. For these two vulnerabilities and related algorithms, you can click the link to view more details, but this kind of vulnerability mainly exists on the browser side, because it needs to inject content through javascript and observe the change of payload.
Resetting the connection performs better
Many app clients have the function of canceling image downloads. For http1.x, the peer end is notified to close the connection by setting the reset flag in the tcp segment. In this way, the connection will be disconnected directly, and the connection must be re-established next time the request is sent again. http2.0 introduces the frame of type RST_STREAM, which can cancel the stream of a request without disconnecting the connection, and the performance is better.
Server Push
The function of Server Push has been mentioned before, http2.0 can push the content required by the client in advance, so it is also called "cache push". Another point worth noting is that if the client exits a certain business scenario and needs to cancel the server push due to traffic or other factors, it can also be done by sending a frame of type RST_STREAM.
Flow Control
The TCP protocol performs flow control through the sliding window algorithm. The sender has a sending window, and the receiver has a receive window. The flow control of http2.0 is similar to the receive window method. The receiver of the data indicates how much data it can receive by informing the other party of its flow window size. Only the frame of Data type has the function of flow control. For flow control, if the receiver still has more frames when the flow window is zero, it will return a frame of block type. This scenario generally indicates that there is a problem with the deployment of http2.0.
more secure SSL
HTTP2.0 uses the extended ALPN of tls to upgrade the protocol. In addition to this, there is another change in the encryption. HTTP2.0 has further strengthened the security of tls, and disabled hundreds of different types of encryption through the blacklist mechanism. No matter how secure the encryption algorithm is, some encryption algorithms may still be used. If the cipher suites of the client and server do not overlap during the SSL negotiation process, the negotiation will fail directly, and the request will fail. Pay special attention to this when deploying http2.0 on the server side.