uses header compression to reduce overhead.can therefore use one connection for parallelism.is fully multiplexed, instead of ordered and blocking.In other words, the HTTP version only indicates wire compatibility, not feature sets or “marketing.” What are the key differences to HTTP/1.x? The Working Group decided to drop the minor version (“.0”) because it has caused a lot of confusion in HTTP/1.x. In February 2015, Google announced its plans to remove support for SPDY in favor of HTTP/2. Throughout the process, the core developers of SPDY have been involved in the development of HTTP/2, including both Mike Belshe and Roberto Peon. Since then, there have been a number of changes, based on discussion in the Working Group and feedback from implementers. HTTP/2 was first discussed when it became apparent that SPDY was gaining traction with implementers (like Mozilla and nginx), and was showing significant improvements over HTTP/1.x.Īfter a call for proposals and a selection process, SPDY/2 was chosen as the basis for HTTP/2. To learn more about participating in the IETF, see the Tao of the IETF you can also get a sense of who’s contributing to the specification on Github’s contributor graph, and who’s implementing on our implementation list. Tim Berners-Lee and the W3C TAG are kept up-to-date with the WG’s progress, however.Ī large number of people have contributed to the effort, but the most active participants include engineers from “big” projects like Firefox, Chrome, Twitter, Microsoft’s HTTP stack, Curl and Akamai, as well as a number of HTTP implementers in languages like Python, Ruby and NodeJS. Note that while our mailing list is hosted on the W3C site, this is not a W3C effort. It’s made up of a number of HTTP implementers, users, network operators and HTTP experts. HTTP/2 was developed by the IETF’s HTTP Working Group, which maintains the HTTP protocol. These hacks are indications of underlying problems in the protocol itself, and cause a number of problems on their own when used. 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. 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).Īt the same time, the large number of requests means a lot of duplicated data “on the wire”.īoth 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. In the past, browsers have used multiple TCP connections to issue parallel requests. 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. HTTP/1.1 has served the Web well for more than fifteen years, but its age is starting to show. How do I debug HTTP/2 if it’s encrypted?.Will I need TCP_NODELAY for my HTTP/2 connections?.Is the priority example in Section 5.3.2 incorrect?.Can I implement HTTP/2 without implementing HTTP/1.1?.Why is there a single compression/flow-control context?.What is the minimum or maximum HPACK state size?.Why the rules around Continuation on HEADERS frames?.What does HTTP/2 do to improve security?.Can HTTP/2 make cookies (or other headers) better?.What are the key differences to HTTP/1.x?.These are Frequently Asked Questions about HTTP/2.
0 kommentar(er)
