The Internet Engineering Task Force's HTTP Working Group has finalized its work on Hypertext Transfer Protocol 2, the successor to the HTTP/1.0 and HTTP/1.1 protocols that are the core of the Web.
The working group has actually finalized two closely related specifications. The first is HTTP/2 itself. The second is called HPACK, a specification for compressing HTTP/2 headers.
Work on HTTP/2 began in 2012 in response to the development of Google's SPDY protocol. Google created SPDY to address a number of performance gripes that the company had with traditional HTTP.
Perhaps the biggest issue with HTTP/1.x was its use of multiple connections to load resources in parallel. While a single HTTP/1.x connection between a client and a server can be used to request multiple different objects (the images, CSS, and JavaScript that an HTML page may require), those objects have to be served up in order, one after the other. If one object takes a long time, perhaps because it's very large or perhaps because it requires a lot of server time to create, then all the other objects requested subsequently have to wait.
As a result, most HTTP/1.x connections are used to request just a single object. Web clients do perform parallel loading of the objects that they need, but they do so by creating multiple connections to each server. But this has a cost of its own: it uses up additional network resources, and it takes extra time, with each individual connection requiring several transfers from client to server and back again.
HTTP/2 directly addresses this issue. In HTTP/2, multiple bidirectional streams are multiplexed over a single TCP connection. Each stream can carry a request/response pair, and multiple requests to a server can be made by using multiple streams. However, the streams are all independent; if one stream is slow, the HTTP/2 connection can still be used to transfer data belonging to other streams. Similarly, a client can request a large object and then a small object, and the response to the small object can be given before, or even during, the response to the large object. The waiting and sequential processing that are a feature of HTTP/1.x aren't needed in HTTP/2. The specification recommends that clients and servers support at least 100 different streams over a single connection.
HTTP/2 also brings some other changes to improve performance and capabilities. Traditional HTTP/1.x is a text protocol, with requests and responses all using plain human-readable text. HTTP/2 is a binary protocol that splits requests and responses into sequences of non-human-readable frames that are transmitted over the TCP connection. HTTP/2 also allows servers to push streams to clients without those clients having to make the initial request.
While a binary protocol, HTTP/2 doesn't change the underlying semantics of an HTTP connection. Requests and responses are still divided between headers and (optionally) bodies, with the headers used to provide important metadata about the bodies. Rather, the protocol is a new way of expressing those same messages designed to make HTTP communication more efficient.
HTTP/2 is based in large part on Google's SPDY. SPDY did some things that HTTP/2 does not. It required the use of TLS (Transport Layer Security) to enhance privacy and security. HTTP/2 makes this optional; it can operate over TLS or over plain TCP. Some vendors, however, have said that their implementations will only support HTTP/2 over encrypted TLS connections to regain these privacy benefits.
SPDY also—initially—used gzip compression for the headers sent in both directions. In 2012, however, this use of gzip was discovered to be dangerous, exposing users to an attack that has become known as CRIME. SPDY was altered to stop using gzip in this way. HTTP/2's solution is that second specification: HPACK.
HPACK is a way of compressing the HTTP headers sent over HTTP/2 connections that avoids the CRIME flaw. Unlike gzip, which is a general purpose compression algorithm, HPACK is designed specifically for HTTP/2's needs.
With IETF signing off on HTTP/2, the next steps are for some editing to be done and for both HTTP/2 and HPACK to be officially published as RFCs.
Browsers are well on their way toward supporting the new specification. Chrome 40 will include HTTP/2 support, with Google announcing earlier this month that SPDY support would be removed from Chrome in early 2016. Mozilla has said that Firefox 36, due to be released next week, will negotiate HTTP/2 connections using drafts 14 and 15 of the specification. Firefox 37 and 38 will add draft 16. The finalized version, draft 17, should follow soon after. The Windows 10 Technical Preview also includes support for draft 14, and the Project Spartan browser that's replacing Internet Explorer will include HTTP/2 support.
The working group has actually finalized two closely related specifications. The first is HTTP/2 itself. The second is called HPACK, a specification for compressing HTTP/2 headers.
Work on HTTP/2 began in 2012 in response to the development of Google's SPDY protocol. Google created SPDY to address a number of performance gripes that the company had with traditional HTTP.
Perhaps the biggest issue with HTTP/1.x was its use of multiple connections to load resources in parallel. While a single HTTP/1.x connection between a client and a server can be used to request multiple different objects (the images, CSS, and JavaScript that an HTML page may require), those objects have to be served up in order, one after the other. If one object takes a long time, perhaps because it's very large or perhaps because it requires a lot of server time to create, then all the other objects requested subsequently have to wait.
As a result, most HTTP/1.x connections are used to request just a single object. Web clients do perform parallel loading of the objects that they need, but they do so by creating multiple connections to each server. But this has a cost of its own: it uses up additional network resources, and it takes extra time, with each individual connection requiring several transfers from client to server and back again.
HTTP/2 directly addresses this issue. In HTTP/2, multiple bidirectional streams are multiplexed over a single TCP connection. Each stream can carry a request/response pair, and multiple requests to a server can be made by using multiple streams. However, the streams are all independent; if one stream is slow, the HTTP/2 connection can still be used to transfer data belonging to other streams. Similarly, a client can request a large object and then a small object, and the response to the small object can be given before, or even during, the response to the large object. The waiting and sequential processing that are a feature of HTTP/1.x aren't needed in HTTP/2. The specification recommends that clients and servers support at least 100 different streams over a single connection.
HTTP/2 also brings some other changes to improve performance and capabilities. Traditional HTTP/1.x is a text protocol, with requests and responses all using plain human-readable text. HTTP/2 is a binary protocol that splits requests and responses into sequences of non-human-readable frames that are transmitted over the TCP connection. HTTP/2 also allows servers to push streams to clients without those clients having to make the initial request.
While a binary protocol, HTTP/2 doesn't change the underlying semantics of an HTTP connection. Requests and responses are still divided between headers and (optionally) bodies, with the headers used to provide important metadata about the bodies. Rather, the protocol is a new way of expressing those same messages designed to make HTTP communication more efficient.
HTTP/2 is based in large part on Google's SPDY. SPDY did some things that HTTP/2 does not. It required the use of TLS (Transport Layer Security) to enhance privacy and security. HTTP/2 makes this optional; it can operate over TLS or over plain TCP. Some vendors, however, have said that their implementations will only support HTTP/2 over encrypted TLS connections to regain these privacy benefits.
SPDY also—initially—used gzip compression for the headers sent in both directions. In 2012, however, this use of gzip was discovered to be dangerous, exposing users to an attack that has become known as CRIME. SPDY was altered to stop using gzip in this way. HTTP/2's solution is that second specification: HPACK.
HPACK is a way of compressing the HTTP headers sent over HTTP/2 connections that avoids the CRIME flaw. Unlike gzip, which is a general purpose compression algorithm, HPACK is designed specifically for HTTP/2's needs.
With IETF signing off on HTTP/2, the next steps are for some editing to be done and for both HTTP/2 and HPACK to be officially published as RFCs.
Browsers are well on their way toward supporting the new specification. Chrome 40 will include HTTP/2 support, with Google announcing earlier this month that SPDY support would be removed from Chrome in early 2016. Mozilla has said that Firefox 36, due to be released next week, will negotiate HTTP/2 connections using drafts 14 and 15 of the specification. Firefox 37 and 38 will add draft 16. The finalized version, draft 17, should follow soon after. The Windows 10 Technical Preview also includes support for draft 14, and the Project Spartan browser that's replacing Internet Explorer will include HTTP/2 support.
