It seems like just yesterday we rolled out SPDY support to all of our customers. But Google announced on February 8th its plan to remove SPDY from its Chrome browser in 2016. The reason? To make way for HTTP/2, the official successor of the HTTP protocol that was recently completed and approved.
For those who don’t yet know, HTTP/2 is the next evolution of HTTP. Based on Google’s SPDY, the new protocol is presented in a formal, openly available specification. While HTTP/2 maintains compatibility with SPDY and the current version of HTTP, this transition means having to rethink some of the ways we interact with the web today.
In this post, we’ll look at some of the reasons leading up to the switch and what the future of the HTTP protocol holds in store.
There’s no denying that HTTP needed an overhaul. Despite the growth of the web from a static, text-driven warehouse to an interactive, dynamic playground, the underlying protocol remained pretty much the same. We’ve evolved techniques for working around some of its shortcomings, but eventually we’ll need to move on to something more flexible and adaptable.
Although SPDY won’t exist as it does today, it’s being used as the core of HTTP/2. This decision came only after several alternatives were evaluated including the Microsoft S+M and Network-Friendly HTTP Upgrade protocols. SPDY’s real-world performance boosts earned it a glowing recommendation from Facebook, although Facebook is far from the only major website using SPDY today.
SPDY demonstrates some of the improvements that can be made to HTTP, but it was never meant to be a full replacement. SPDY laid the groundwork for HTTP/2 by improving data transmission without breaking backwards compatibility. Now that developers, users, and enterprises have had the chance to review it, it should form a smooth upgrade path to HTTP/2.
Currently the only web server to fully support HTTP/2 is IIS in Windows 10. On the browser side, Chrome 40, Firefox 35, and Internet Explorer 11 on Windows 10 offer full support. Over time, the availability of HTTP/2-ready software will continue to grow.
Although HTTP/2 is built on SPDY, it introduces some important new changes.
| SPDY | HTTP/2 |
|---|---|
| SSL Required. In order to use the protocol and get the speed benefits, connections must be encrypted. | SSL Not Required. However – even though the IETF doesn’t require SSL for HTTP/2 to work, many popular browsers do require it. And because most Internet data is accessed through popular browsers (Chrome and Firefox), what they require matters most. |
| Fast Encrypted Connections. Does not use the ALPN extension that HTTP/2 uses. | Faster Encrypted Connections. The new ALPN extension lets browsers and servers determine which application protocol to use during the initial connection instead of after. |
| Single-Host Multiplexing. Multiplexing happens on one host at a time. | Multi-Host Multiplexing. Multiplexing happens on different hosts at the same time. |
| Compression. SPDY leaves a small space for vulnerabilities in its current compression methods. | Faster, More Secure Compression. HTTP/2 introduces HPACK, a compression format designed specifically for shortening headers and preventing vulnerabilities. |
| Prioritization. While prioritization is available with SPDY, HTTP/2’s implementation is more flexible and friendlier to proxies. | Improved Prioritization. Lets web browsers determine how and when to download a web page’s content more efficiently. |
HTTP/2 promises to make the web easier for developers, administrators, enterprises and users. Many of the old tricks used to make HTTP faster – domain sharding, CSS sprites and combining files, to name a few – will become redundant. HTTP/2 also promises lower bandwidth requirements, lower network overhead, and lower memory usage on servers.
Tests by HttpWatch comparing HTTP/2 to HTTPS show reductions in page load times of over 22%. HTTP/2 consistently returned smaller page sizes with a difference of over 88% in page headers alone. It also created five separate connections across five domains (one for each domain), whereas HTTPS created seven, showcasing HTTP/2’s push toward faster delivery without the chattiness.
Users will reap the benefits of a faster web. HTTP/2 is designed to make the most of available bandwidth through compression and concurrent downloads. The ability for servers to push content to users makes it easier to preload and deliver data in real-time, while smaller headers and page sizes help users stretch their data caps and get the most out of high-latency connections.
HTTP/2 promises to reduce the amount of network strain placed on content providers.
Developers can also breathe a sigh of relief when it comes to optimizing websites. Tricks designed to work around HTTP’s limitations such as domain sharding will no longer be required, leading to less wasted time and shorter development cycles. HTTP/2 retains full compatibility with the current HTTP/1.1 protocol, giving developers time to transition web applications without hurting their current users.
HTTP/2 already accounts for 5% of Google’s global traffic. Now that the specification is finalized, we expect that number to grow. We’re excited to have helped bring SPDY to the masses, and we’re even more excited to see how HTTP/2 will define the future of the web for our partners, customers, and the Internet at large.
We’ll continue to support SPDY as HTTP/2 grows, so stay tuned for information and updates.
