When your browser connects to a website today, it most likely uses the HTTP/1.1 protocol that was defined in 1999 in RFC 2616. Over the past 15 years, HTTP/1.1 has served us well and many tweaks have been discovered to make the most of it. In that time, however, the web has transformed into a platform for interactive content and applications. Today, browsers load much more data from many more sources to build the typical web page.
In 2009 Google announced a research project called SPDY (pronounced “speedy”). As Google software engineers Mike Belshe and Roberto Peon explained in “A 2x Faster Web”:
“We started working on SPDY while exploring ways to optimize the way browsers and servers communicate.”
The following year Google added SPDY support to Chrome; in 2011 they added it to all Google services. Later they announced that SPDY improves performance of their services by up to 43 percent. SPDY continued to gain popularity as it was implemented in popular web browsers and servers, by CDNs, and by popular sites like Twitter.
With SPDY gaining traction and showing significant performance benefits, the IETF chartered development of HTTP/2 in 2012 and later decided to base it on SPDY. The goals set out for HTTP/2 include:
- Improving performance by reducing “end-user perceived latency” and addressing a few specific HTTP/1.1 performance issues
- Compatibility with HTTP/1.1. This means that URLs and status codes like the familiar ‘404 Not Found’ haven’t changed
- Interoperability with HTTP/1.1, allowing web servers and browser to support both versions as usage of HTTP/2 grows over time
Binary & multiplexed
HTTP/2 achieves these goals by making a number of fundamental changes to the way data is communicated from the server to the browser. First, HTTP/2 is a binary protocol, meaning that it is more efficient and less error prone. This also means that using telnet to connect to a web server and type simple commands like ‘GET /index.html’ doesn’t work with HTTP/2.
Arguably the biggest change is that HTTP/2 is “multiplexed.” This means that one network connection can serve requests for many pieces of content at the same time. Doing this reduces waiting while each individual piece of the web page is loaded. It also eliminates the current practice of browsers opening multiple simultaneous connections to the same server and in turn makes better use of network resources.
Web servers include headers with every response they send to the browser. Headers contain information about the content, including cookies. Modern web applications use lots of cookies, and load lots of content on each page. This means that headers end up accounting for quite a bit of the data being transferred, and by compressing all this data, HTTP/2 is faster.
Finally, HTTP/2 allows a web server to anticipate that a browser is going to request a piece of content and proactively send that content to the browser before being asked for it. This is called “Server Push.” Since the server doesn’t have to wait to be asked, pages can be loaded faster.
HTTP/2 is more secure
Google designed SPDY to require the use of SSL/TLS, and during the drafting of the HTTP/2 spec this requirement was vigorously debated. The outcome is that HTTPS is not a requirement for HTTP/2 — it supports unencrypted communications via HTTP. However, Mozilla has stated that Firefox will only support HTTP/2 over SSL/TLS, and so far both Google and Microsoft have only released HTTP/2 support over SSL/TLS. Even if Microsoft and Google do as expected and implement HTTP/2 without requiring SSL/TLS, Mozilla’s decision alone is a strong reason for websites to deploy SSL/TLS so they can benefit from HTTP/2.
From a security perspective, the best news about HTTP/2 is that it specifies the use of best practices for HTTPS. TLS version 1.2 is required, eliminating vulnerabilities present in older versions. HTTP/2 also requires that the compression and renegotiation features of the protocol be disabled due to risks that they expose when used. Finally, the spec bans weak cipher suites and requires support for Perfect Forward Secrecy.
Coming soon
As of this writing, we’re still waiting for HTTP/2 to be published as a standard, but support for draft versions is already available in Google Chrome and Mozilla Firefox, as well as Microsoft’s Internet Explorer in the Windows 10 Technical Preview. Twitter has deployed HTTP/2 on their servers, so you might already be benefitting from HTTP/2 without knowing it! Akamai has also published a demonstration site.
Support for HTTP/2 in web servers is also progressing nicely. While it’s probably too early for most sites to roll out HTTP/2, you should be aware of it and start making plans to reap the benefits.
Learn about the four types of SSL certificates available.
Wildcard SSL Certificate
Extended Validation SSL Certificate
SAN SSL Certificate
Organization Validation SSL Certificate
