The Internet can be a bit of a dichotomy with respect to how it evolves. New technologies seem to pop up, grow, and expand almost on a daily basis, yet the underlying protocol that powers the web as we know it saw (until recently) almost no meaningful growth for nearly 15 years. The Hypertext Transfer Protocol (HTTP) was originally designed by Tim Berners-Lee in the late 1980s, and the last significant rework of the protocol was done in 1999 (standardized as an RFC that was released when I was in second grade). Last year, a major rework of HTTP was finalized in the form of HTTP/2, a major upgrade to the underlying backbone of the web as we know it today.
Why Update HTTP?
The developers of the HTTP/2 spec have provided an excellent summary as to why and how HTTP was improved in the latest protocol spec. In short, HTTP/1.1 was designed for a different time, when web pages were smaller, simpler, and cheaper to send across the wire. The explosive growth of the web in the last decade has seen a paradigm shift in how site and applications are designed and deployed. Websites and web applications use larger, more complex media assets, and serve more content than ever—and there’s no sign of this slowing down. The workarounds put in place by developers and engineers to get around some of the inherent limitations of HTTP/1.1 (like request pipelining, domain sharding, etc.) were hacks and bandaids that were never addressed at a fundamental level, and stood largely in contrast to some of the design features of TCP, the underlying communication protocol that HTTP lives on. HTTP/2 was designed to take into account the nature of the modern web, providing an efficient standard for modern servers and clients to communicate over.
HTTP/2 brings a number of new features to the table, including:
- A binary protocol, making it more compact to ship over the wire
- Fully multiplexed, parallel connections allow for faster, more efficient data transfer
- Server push functionality, allow web designers to build sites that proactively send assets that will be needed by a web page
Shiny features and well-designed protocols are all well and good, but they’re worthless without actually being used. After finalization in mid-2015, the HTTP/2 protocol soon saw early adoption from service providers like Akamai, Google, and Facebook, open-source HTTP servers like Nginx, and browsers, including Chrome, Firefox, Safari, and even Internet Explorer (shocker, I know). According to researchers tracking the adoption rate of HTTP/2, nearly 200,000 sites from the Alexa list of top one million websites announce support for HTTP/2.
As the successor to the SPDY protocol, many early adopters expected HTTP/2 to require a TLS connection, just as its predecessor did. Ultimately it was decided by the protocol’s designers that secure connections would not be required; however, that hasn’t prevent browser developers to require encryption. Currently no browser implementations support plaintext HTTP/2 connections (also known as h2c).
HTTP/2 servers use one of two negotiation protocols to announce their support via TLS connections: NPN and ALPN. NPN is an older, less-efficient negotiation protocol, while ALPN is newer, faster, and has seen much less adoption due to its exclusion from older OpenSSL builds. Interestingly, Google has announced plans for Chrome to drop support for NPN in exclusive favor of ALPN, which could leave many users in the HTTP/2 dark while legacy OpenSSL packages still float around.
HTTP/2 at DreamHost
As a provider dedicated to embracing open source projects, we’ve excitedly decided to push forward with adoption of HTTP/2. Starting this week, domains hosted on VPS and dedicated servers powered by Nginx can now take full advantage of the HTTP/2 protocol. HTTP/2 support in Nginx is designed to work seamlessly alongside existing HTTP/1.1 connections, albeit only for HTTPS sites. Other existing features provided by our Nginx services, including extra web security and Lua support via OpenResty, will also continue to work transparently under HTTP/2.
Additionally, DreamHost-powered HTTP/2 servers are fully capable of supporting both NPN and ALPN negotiations, meaning Chrome’s impending cutoff for NPN won’t result in connection errors on bleeding-edge browsers.
Adding HTTP/2 support to your Nginx/HTTPS domain is as simple as activating a checkbox. View the Knowledge Base article for further details and instructions on how to activate this service.
And for the extra-curious, there are a number of excellent resources about HTTP/2 that delve much deeper into the nitty gritty:
So what are you waiting for? Check that HTTP/2 box and take your domain to the next level today!