Some new features of HTTP2

Mark Nottingham wrote a blog post about 9 things to look forward to in the new deal: using the same API as HTTP. As Mark notes: "To make HTTP/2 successful, you have to make it work on the existing Web." So our effort is to get the existing HTTP to work better, rather than change the protocol. "Although there may be mechanisms that allow you to optimize some of the new features, there are generally no new methods, headers, or status codes. Cheaper request. "HTTP/2 uses multiplexing to allow multiple messages to be simultaneously on one connection, so a large response (or a response that consumes the server for a long time) does not block other responses. In addition, it adds head compression (header compression), so even for very small requests, the header of its request and response only consumes a small percentage of bandwidth. This is very important for mobile platforms. Because too large a request header, plus the number of resources required by the page, passes through several rounds, it is likely to cause the page to fail to load. "The new protocol provides a more user-friendly design for networks and services. "HTTP/2 will use fewer connections, so the load on both the server and the network will be reduced. This is of great importance for the increasingly congested network. HTTP/1 uses the multi-connection method to realize the parallel data transmission, aggravating the network congestion problem. "HTTP/2 requires only a single connection for each host, and whenever possible, you should merge multiple sites into one host. HTTP/2 introduces the concept of service-side push (server push), which allows the server to proactively send data to the client cache before the client needs data, improving performance. Of course, in some scenarios, the client may not want to do this, so HTTP/2 also allows the client to reject it. When the client (browser) changes its mind and no longer needs a response from a request, the HTTP/1 client can only close the connection, and the new protocol provides a better solution. "Http/2 added Rst_stream frame, allowing clients to change their minds. When a browser makes a page jump or the user cancels the download, it prevents the creation of a new connection and avoids wasting all of the bandwidth. "HTTP/2 provides more encryption support, and Mark's earlier articles have demonstrated their pros and cons. If you like the ability to listen and manually parse HTTP requests and responses, such as using Telnet to connect to a server, then you're ready to make those features no longer available. HTTP/1 is a text-based protocol and HTTP/2 is binary based. "Although the parsing of binary protocols has a smaller overhead and smaller network consumption, the real reason for this huge change is that the binary protocol is simpler and therefore less error-free, which is its advantage. "Mark has discussed this,It is true that this is true. For example, how to define text, one of the serious flaws of HTTP/1 is the fragility of security. "The textual nature of HTTP/1 also leads to some security issues. Because different implementations have different decisions about how to parse a message, a malicious community can invade in some way (for example, through response splitting attack) "Don't expect HTTP/2 to magically improve the performance of the server or client." "With regard to the new agreement, it is more accurate to think that it clears up some of the important obstacles to performance. Only when both the client and the server have learned how and when to use its advanced features will the performance begin to increase gradually. As Mark points out, the vast majority of today's web sites are based on HTTP/1 and are inevitably constrained by them. Only through time, when they have been reconfigured, can they play the advanced features offered by HTTP2. In addition, the disadvantage of HTTP/2 's network-friendly features is that it can cause TCP congestion control to become more prominent. Because the browser establishes only one connection per host, the initial window and packet loss will be more pronounced. "HTTP/2 is not the end of development, the team is already considering the follow-up development. "Now people are looking forward to the official release of HTTP/2, so some of the advanced (and experimental) features are not included in this release. For example, push TLS authentication and DNS entries to the client, both of which can improve performance. If the experiment goes well, maybe HTTP/3 will include these. Of course, HTTP/3 can also be a version that solves all the problems that are not currently found. But so far, confidence is growing. Whether it's a community-published Spdy experience or HTTP/2 implementations, HTTP/2 is nearing completion. ”