HTTP/2 (originally named HTTP/2.0) is the second major version of the HTTP network protocol used by the World Wide Web. It is based on SPDY. HTTP/2 is being developed by the Hypertext Transfer Protocol working group (httpbis, where bis means "repeat" or "twice") of the Internet Engineering Task Force. HTTP/2 would be the first new version of HTTP since HTTP 1.1, which was standardized in RFC 2616 in 1999. The Working Group presented HTTP/2 to IESG for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on Feb 17, 2015.
The standardization effort came as an answer to SPDY, an HTTP-compatible protocol developed by Google[7] and supported in Chrome, Opera, Firefox, Internet Explorer 11, Safari, and Amazon Silk browsers.
The standardization effort came as an answer to SPDY, an HTTP-compatible protocol developed by Google[7] and supported in Chrome, Opera, Firefox, Internet Explorer 11, Safari, and Amazon Silk browsers.
GOALS
The working group charter mentions several goals and issues of concern:
1. Negotiation mechanism that allows clients and servers to elect to use HTTP 1.1, 2.0, or potentially other non-HTTP protocols.
2. Maintain high-level compatibility with HTTP 1.1 (for example with methods, status codes, and URIs, and most header fields)
Decrease latency to improve page load speed in web browsers by considering:
1. Data compression of HTTP headers
2. Server push technologies
3. Fixing the head-of-line blocking problem in HTTP 1
4. Loading page elements in parallel over a single TCP connection
5. Support common existing use cases of HTTP, such as desktop web browsers, mobile web browsers, web APIs, web servers at various scales, proxy servers, reverse proxy servers, firewalls, and content delivery networks
Different from HTTP 1.1
The proposed changes do not require any changes to how existing web applications work, but new applications can take advantage of new features for increased speed.
HTTP/2 leaves most of HTTP 1.1's high level syntax, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server.
Websites that are efficient minimize the number of requests required to render an entire page by minifying (reducing the amount of code and packing smaller pieces of code into bundles, without reducing its ability to function) resources such as images and scripts. However, minification is not necessarily convenient nor efficient, and may still require separate HTTP connections to get the page and the minified resources. HTTP/2 allows the server to "push" content, that is, to respond with data for more queries than the client requested. This allows the server to supply data it knows a web browser will need to render a web page, without waiting for the browser to examine the first response, and without the overhead of an additional request cycle.
Additional performance improvements in the first draft of HTTP/2 (which was a copy of SPDY) come from multiplexing of requests and responses to avoid the head-of-line blocking problem in HTTP 1 (even when HTTP pipelining is used), header compression, and prioritization of requests.
Additional performance improvements in the first draft of HTTP/2 (which was a copy of SPDY) come from multiplexing of requests and responses to avoid the head-of-line blocking problem in HTTP 1 (even when HTTP pipelining is used), header compression, and prioritization of requests.
Genesis in and later differences from SPDY
SPDY (pronounced speedy) is a research project spearheaded by Google that is also an applicable protocol, designed for the transportation of information and other content on the web. SPDY primarily focuses on reducing latency. SPDY uses the same TCP pipe but different protocols to accomplish this reduction. The basic changes made to HTTP 1.1 to create SPDY include: "true request pipelining without FIFO restrictions, message framing mechanism to simplify client and server development, mandatory compression (including headers), priority scheduling, and even bi-directional communication".
The httpbis working group considered Google's SPDY protocol, Microsoft's HTTP Speed+Mobility proposal (SPDY based), and Network-Friendly HTTP Upgrade. In July 2012 Facebook provided feedback on each of the proposals and recommended HTTP/2 be based on SPDY. The initial draft of HTTP/2 was published in November 2012 and is based on a straight copy of SPDY.
The biggest difference between HTTP and SPDY, is that each user action in SPDY is given a "stream ID", meaning there is a single TCP channel connecting the user to the server. SPDY splits requests into either control or data, which is a “parse binary protocol with two types of "frames". SPDY has shown evident improvement from HTTP, with a new page load speedup ranging from 11.81% to 47.7%.
HTTP/2 uses SPDY as a jumping-off point; though SPDY is an improvement on HTTP 1.1, it does have some limitations. SPDY communicates separately with each host, which means that multiplexing happens only at one host at a time, no matter how many connections are open. This means that SPDY can only download things from one host at a time. The improvement HTTP/2 makes on this is that it allows multiplexing to happen at different hosts at the same time. This makes downloading multiple web pages or content from the Internet significantly faster.
HTTP/2 also uses a fixed Huffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential for attacks on the protocol.
On February 9, 2015, Google announced plans to remove support for SPDY in Chrome by early 2016, in favor of support for HTTP/2, starting with Chrome 40.
The httpbis working group considered Google's SPDY protocol, Microsoft's HTTP Speed+Mobility proposal (SPDY based), and Network-Friendly HTTP Upgrade. In July 2012 Facebook provided feedback on each of the proposals and recommended HTTP/2 be based on SPDY. The initial draft of HTTP/2 was published in November 2012 and is based on a straight copy of SPDY.
The biggest difference between HTTP and SPDY, is that each user action in SPDY is given a "stream ID", meaning there is a single TCP channel connecting the user to the server. SPDY splits requests into either control or data, which is a “parse binary protocol with two types of "frames". SPDY has shown evident improvement from HTTP, with a new page load speedup ranging from 11.81% to 47.7%.
HTTP/2 uses SPDY as a jumping-off point; though SPDY is an improvement on HTTP 1.1, it does have some limitations. SPDY communicates separately with each host, which means that multiplexing happens only at one host at a time, no matter how many connections are open. This means that SPDY can only download things from one host at a time. The improvement HTTP/2 makes on this is that it allows multiplexing to happen at different hosts at the same time. This makes downloading multiple web pages or content from the Internet significantly faster.
HTTP/2 also uses a fixed Huffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential for attacks on the protocol.
On February 9, 2015, Google announced plans to remove support for SPDY in Chrome by early 2016, in favor of support for HTTP/2, starting with Chrome 40.
Encryption
HTTP/2 is defined for both HTTP URIs (for now in the clear) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required). Some implementations, such as Firefox, have stated that they will only support HTTP/2 when it is used over an encrypted connection.
Criticisms
As of the January 2015 last call, the HTTP/2 protocol is being criticised for not supporting opportunistic encryption, a feature like STARTTLS that has long been available in other internet protocols like SMTP. Poul-Henning Kamp, lead developer of varnish HTTP accelerator and a senior FreeBSD kernel developer, has criticised IETF for following a particular political agenda with HTTP/2. It has also been pointed out that the HTTP/2 proposal goes in violation of IETF's own RFC7258 "Pervasive Monitoring Is an Attack", which also has a status of Best Current Practice 188. RFC7258/BCP188 mandates that passive monitoring be considered as an attack, and protocols designed by IETF should take steps to protect against passive monitoring (for example, through the use of opportunistic encryption). A number of specifications for opportunistic encryption of HTTP/2 have been provided, of which draft-ietf-httpbis-http2-encryption-01 is an official work item of the working group.
The criticism of the agenda of mandatory encryption within the existing certificate framework (as opposed to opportunistic encryption) is not new, nor is it unique to members of the open-source community – a Cisco employee pointed out in 2013 that the present certificate model is not compatible with small devices like the routers, because the present model requires not only annual enrollment and remission of non-trivial fees for each certificate, but must be continually repeated on an annual basis. It is noteworthy that even though the mandatory encryption that has been criticized by an agent of the industry leader in 2013 has not been made mandatory as part of the standard, as of early 2015 the agenda has nonetheless been carried over by the leading browser makers, who have thus far refused to implement HTTP/2 without encryption.
The criticism of the agenda of mandatory encryption within the existing certificate framework (as opposed to opportunistic encryption) is not new, nor is it unique to members of the open-source community – a Cisco employee pointed out in 2013 that the present certificate model is not compatible with small devices like the routers, because the present model requires not only annual enrollment and remission of non-trivial fees for each certificate, but must be continually repeated on an annual basis. It is noteworthy that even though the mandatory encryption that has been criticized by an agent of the industry leader in 2013 has not been made mandatory as part of the standard, as of early 2015 the agenda has nonetheless been carried over by the leading browser makers, who have thus far refused to implement HTTP/2 without encryption.
Browser support
Chrome supports HTTP/2, but it is not enabled by default. To turn on HTTP/2 support, a command line flag "--enable-spdy4" needs to be specified when launching Chrome. Currently only HTTP/2 over TLS is implemented. As of February 2015, Google plans to fully implement HTTP/2 in future versions of its Chrome browser, effectively dumping support for SPDY.
Firefox supports HTTP/2 which has been enabled by default since version 36. Experimental support for HTTP/2 was originally added in version 34. Currently only HTTP/2 over TLS is implemented.
Internet Explorer supports HTTP/2 in version 11, but only for Windows 10 beta, and is enabled by default. Currently only HTTP/2 over TLS is implemented.
HTTP/HTTPS servers
Support
IIS supports HTTP/2 in Windows 10 beta
Support
IIS supports HTTP/2 in Windows 10 beta
OpenLiteSpeed 1.3.8 and 1.4.5 support HTTP/2 draft 17
SPDY, but no HTTP/2
Apache provides support for SPDY via the mod_spdy module
Apache provides support for SPDY via the mod_spdy module
LiteSpeed Web Server currently supports SPDY/3.1
nginx provides experimental support for SPDY (Draft 3.1) via a module
No comments:
Post a Comment