If your business relies heavily on online assets, then for sure you have already switched to HTTP/2, the new and improved protocol to deliver online content. New features like server push, full multiplexing and improved parallelism, along with attached advanced technologies, make the performance gains quite obvious with HTTP/2. Right next to the performance boost there’s the security aspect, greatly because of all major clients like Firefox, Chrome, Safari, Opera, etc. stated they will only support HTTP/2 over Transfer Layer Security (TLS). This makes encryption practically mandatory, with HTTP/2 actually becoming a HTTPS (HTTP “Secured”). Also, since Google clearly pushes the security segment as an increasingly important ranking factor, delivering content over HTTP/2, which ultimately translates to HTTPS, boosts your SEO efforts as well as performance. Major CDN providers report constant and increased adoption of the new protocol which suggests HTTP/2 will definitely become even more dominant in recent future.
However, while it’s safe to say that the switch to HTTP/2 is a trend, many companies still fail to fully leverage all the benefits and features that the new protocol offers. One such hidden gem is this one features that keeps hiding under the radar and is yet to be fully recognized. We’re talking about the header compression feature – HPACK.
How One AI-Driven Media Platform Cut EBS Costs for AWS ASGs by 48%
The Background
Back in the old HTTP era, all the compression was executed within the TLS with gzip and using DEFLATE, a lossless data compression algorithm, to reduce both header and body payloads. Then came the SPDY protocol, developed mainly by Google, which was used to shape HTTP traffic in order to reduce load latency and provide a better security structure. SPDY also introduced a new compression algorithm designed specifically for headers which still used DEFLATE along with dynamic Huffman codes and string matching algorithms. The gains were short lived as soon it became clear it was quite vulnerable to CRIME attacks (Compression Ratio Info-leak Made Easy), a security exploit used to recover the content of authentication cookies which then allowed hackers to perform session hijacking and launch further attacks. The discovered vulnerability pushed network providers to fully disable header compression. And it was so until HTTP/2 took the scene.
Tweet this: Due to security issues, header compression was fully disabled until HTTP/2
Header Compression With HPACK
With SPDY, the header compression was executed within a single gzip context in each direction for header compression. This solution was rather simple to implement and proved as efficient. Since the implementation of SPDY, major security flaws were spotted in the process of header compression and a particular vulnerability to earlier mentioned CRIME attacks. HTTP/2 was developed with attacks like CRIME in mind and its dedicated header compression algorithm HPACK is now considered safe to use.
You may ask yourself to why do we even need header compression? As pointed out on Github’s HTTP/2 FAQ page, assuming a page has 80 assets and each request results in 1400 bytes of header, it takes at least 7-8 roundtrips to deliver all the headers to the client. This is largely due to TCP’s Slow Start implementation which sets up new connections based on the number of confirmed packets, thus resulting in a limited amount of packets for the first few roundtrips. Even a low level of compression on headers greatly reduces roundtrips and payload, and can help deliver the request within just one roundtrip, or even within a single packet.
Using HPACK that’s exactly what happens. Headers can now be compressed using Huffman encoding which results in an average 30% reduction of header size. As KeyCDN pointed out in their blogpost, the 3 main benefits of HPACK are:
- Resilient against compression based attacks (CRIME)
- Fixed Huffman codes allow encoding of large headers
- Frequently used headers can be encoded as variable length integer, opposed to re-sending the whole header every time
Essentially, the Huffman encoding algorithm operates by assigning binary codes to most commonly used characters. When a HPACK header is received, it gets looked up in the list of binary codes. This way the header can access frequently used characters compressed in smaller packets which in turn results in less bits required to complete the transmission. Previously, an accept string encoded with 7 bits per character would require 6 bytes while the HPACK version only takes 2 bytes. It means less data gets transferred which ultimately results in improved web performance.
A proof of the efficiency of HPACK header compression is provided by CloudFlare. They monitored request and response headers within their network and found that total ingress traffic with HTTP/2’s HPACK was reduced by 53%. The analysis also pointed out that CloudFlare’s infrastructure processes the same number of requests for HTTP/1 and HTTP/2 over HTTPS, but with ingress traffic for HTTP/2 amounting at merely half of the HTTP/1.
As for response headers (egress traffic) the gains were not that substantial but still relevant. Total egress traffic resulted in modest 1.4% savings. Although it’s not much at first glance, on a larger scale even minimal savings of that amount could result in significant reduction of traffic.
Worth mentioning is the fact that HPACK uses indexing. It consists of a table filled with frequently used headers (e.g. user-agent) which means once a header contained in the list is sent, HPACK will use the index from the table opposed to the literal string.
Conclusion
With header compression once again being available without security issues attached, significant savings can be achieved in terms of transferred payload and load times. As this post points out, HTTP/2 HPACK compression enables substantially faster content delivery. By implementing HPACK compression for HTTP headers, the responses will be faster and smaller. It all translates to significantly reduced ingress and egress bandwidth.
Taking all of the above stated in consideration, it is safe to say that there has never been a better time to migrate to HTTPS and take full advantage of its benefits. Is your site or CDN provider already running over HTTP/2 yet? Are you taking advantage of the HPACK feature? Make sure to find out. And if you need help on the matter, feel free to contact our experts at Globaldots for everything web performance and security related.
