What is the HTTP/2 Protocol
Hypertext Transfer Protocol (HTTP) is a set of standards allowing internet users to exchange website information. There have been four HTTP iterations since its introduction in 1991.
HTTP/2 was released in 2015 as a major revision to the HTTP/1.1 protocol. It was derived from the SPDY protocol as a way to improve the online experience by speeding up page loads and reducing round-trip time (RTT), especially on resource-heavy web pages.
Here we will be discussing why the new protocol was needed, its evolution from SPDY, how it differs from HTTP/1.1 and how a CDN can assist in making your site content HTTP/2 compatible.
From SPDY to HTTP/2
HTTP/1.1 was the third version of HTTP and the standard protocol for over 15 years. It introduced persistent connections for improved performance and laid the foundation for standard requests, such as GET, HEAD, PUT, and POST.
As websites became more resource-intensive, however, HTTP/1.1’s limitations began to show. Specifically, its use of one outstanding request per TCP connection created significant overhead, slowing down page load times.
In 2010, Google released the SPDY protocol as a way of modifying how HTTP handles requests and responses. Its focus was on reducing latency via TCP pipelining and providing mandatory compression, amongst other features.
While HTTP/2 was initially modeled after SPDY, it was soon modified to include unique features, including a fixed header compression algorithm, (in contrast to SPDY’s dynamic stream-based compression). Following its release, Google announced that it would remove support for SPDY in favor of HTTP/2.
HTTP/1.1 vs. HTTP/2 Protocol
HTTP/2 improved on HTTP/1.1 in a number of ways that allowed for speedier content delivery and improved user experience, including:
- Binary protocols – Binary protocols consume less bandwidth, are more efficiently parsed and are less error-prone than the textual protocols used by HTTP/1.1. Additionally, they can better handle elements such as whitespace, capitalization and line endings.
- Multiplexing – HTTP/2 is multiplexed, i.e., it can initiate multiple requests in parallel over a single TCP connection. As a result, web pages containing several elements are delivered over one TCP connection. These capabilities solve the head-of-line blocking problem in HTTP/1.1, in which a packet at the front of the line blocks others from being transmitted.
- Header compression – HTTP/2 uses header compression to reduce the overhead caused by TCP’s slow-start mechanism.
- Server push – HTTP/2 servers push likely-to-be-used resources into a browser’s cache, even before they’re requested. This allows browsers to display content without additional request cycles.
- Increased security – Web browsers only support HTTP/2 via encrypted connections, increasing user and application security.
HTTP/2 Implementation and CDN
Google’s decision to stop supporting the SPDY protocol has made upgrading to HTTP/2 imperative for online businesses wishing to reduce RTT and speed up page load times.
Migrating to HTTP/2, however, can be complicated for a number of reasons, including:
- HTTPS compatibility – The new extension to Transport Layer Security (TLS) means a site must first be HTTPS compatible to use HTTP/2.
- Server upgrades – All of your servers need to be upgraded from HTTP/1.1 to HTTP/2, a potentially cumbersome and error prone process.
- Bug fixes – HTTP/2 requires your developers and designers to come up with new solutions to overcome HTTP/1.1 bugs, as they can create issues with the new standard.
The Imperva CDN solves these issues by acting as an intermediary between site visitors and your origin servers. This automatically upgrades your servers from the moment you onboard our services, without the hassle of migrating to HTTP/2 on your own.
To learn more, visit our reverse proxy page.
