HTTP: The Sequel

Batman’s The Dark Night. Lord of the Rings: The Two Towers. Thor: Ragnarök. Star Wars Episode V: The Empire Strikes Back. It’s my opinion that sequels are almost always better than the originals. There, I said it. Sometimes, it almost seems as if writers needed an additional opportunity to refine plots, build out a fictional world, and create more depth to their protagonists and supporting characters. Sometimes, the story isn’t quite finished.

And with technology, the story never seems to be quite over either. Technologists are innovators at heart and strive to create sequels that are improvements upon their predecessors. Take the example of the HTTP/HTTPS protocol. Developed first in 1989 by the HTTP Working Group of the Internet Engineering Task Force (IETF), the first major version of HTTP/HTTPS has been the staple of communication between clients and the web for the last 25 years, iterating through several minor versions to increase performance and cut web page load times. And while it served us well over that time period, it was certainly time for a reboot.

Enter HTTP/2 and HTTP/3. In 2015, HTTP/2 was introduced as a faster, more efficient version of the original HTTP/HTTPS protocol thanks to the HTTP Working Group. An improved sequel, if you will. And as I write this, another IETF task force—comprising Internet leaders such as F5, among others—is looking to further elevate the performance enhancements of HTTP/2. The QUIC working group released HTTP/3 as a draft in June of 2021. The task force's imperative is to create a new and improved protocol QUIC, a UDP-based protocol on which the next generation of HTTP, HTTP/3, runs. And so, the saga of innovation continues...

With F5 solutions, you can take advantage of HTTP’s innovative sequel. Use F5 SSL Orchestrator to upgrade your security stack and peer into HTTP/2 traffic to detect and protect against encrypted threats.

What is HTTP/2?

The goal of HTTP/2 is to deliver web applications faster and more efficiently. The task force did this by creating a protocol that would reduce web page load time by multiplexing requests and responses and minimizing the number of requests required to load a page by minifying resources.

So, what’s remained unchanged between HTTP/1x and HTTP/2? First off, the semantics remain the same. The architecture, headers, status codes, and request methods have not changed. The primary target transport—TCP—also remains the same. HTTPS is still used to transport encrypted traffic through your network, and still uses TLS certificates to encrypt the traffic. The fundamental purpose of HTTP/HTTPS is not changing, and the building blocks of the protocol are likely here to stay for a long while.

HTTP/1x did have a few limitations. First, it could not compress response and request headers, leading to network overutilization and complexity. Second, it did not enable effective resource prioritization and suffered from occasional head-of-the-line blocking, grinding performance to a snail’s pace as each subsequent request is held up by the first packet in line.

HTTP/2 makes needed improvements on these limitations in order to deliver applications faster to the end user. HTTP/2 enables faster page loads by minimizing the number of requests required to load a page and multiplexing requests and responses, resulting in better transport performance, decreased problems with head-of-the-line blocking, higher throughput, and lower latency for the end user.

How widespread is HTTP/2?

The short answer is “very.” According to the HTTP Archive, about 67% of web page load requests used HTTP/2 in the first half of 2021. Major browsers such as Chrome, Firefox, Safari, and Edge all support HTTP/2. Because of the protocol’s ubiquity, internet users are already taking advantage of the faster web page loading times that HTTP/2 affords.

But, if your organization’s security stack does not support HTTP/2, you may not be providing your users with all the advantages the upgrade provides, leading to longer page load times for end users and lower customer satisfaction. And reducing latency is especially important—from the perspective of the end user—if your security stack is already complex.

What does this mean for you and your network?

Upgrading your security stack to support HTTP/2 is critical for driving customer satisfaction and for achieving better resource utilization within your network. Additionally, many leading browsers that support HTTP/2 (such as Chrome and Firefox) only do so with a TLS certificate, meaning that all HTTP/2 traffic originating from Chrome or Firefox must be encrypted.

F5 SSL Orchestrator enables you to inspect HTTPS traffic for threats that may be traversing your network. It is an all-in-one appliance solution designed specifically to optimize the SSL infrastructure, provide security devices with visibility of SSL/TLS encrypted traffic, and maximize efficient use of your existing security investment. As a result, your network will experience lower latency, less complexity, easier change management, lower total cost of ownership (TCO), and protection against encrypted threats.

The most recent version of SSL Orchestrator (BIG-IP 16.1 and SSL Orchestrator version 9.0) allows you to inspect encrypted HTTP/2 traffic for malware that may harm your network. Since the SSL Orchestrator proxy recognizes HTTP/2 traffic, it can take advantage of the speed the updated protocol provides, while also inspecting the encrypted traffic packets for threats. Currently, security devices in your SSL Orchestrator dynamic service chain must also support HTTP/2 if you would like to make use of the improved performance in the new HTTP version.

Interested in protecting yourself against encrypted threats with the most up to date HTTP technology? Download the recently released version of SSL Orchestrator (BIG-IP 16.1 and SSL Orchestrator version 9.0).

Sources:

HTTP Archive: https://httparchive.org/reports/state-of-the-web#h2 (cited inline)

High Performance Browser Networking, by Ilya Grigorik (supplementary research)

HTTP/2: A New Excerpt from High Performance Browser Networking by Ilya Grigorik (supplementary research)