HTTP/2 Done Right
By David Brown, Principal Product Manager
We are happy to announce that as of March 31st, 2017, the entire Edgecast Content Delivery Network is HTTP/2 enabled by default. All of our customers now enjoy the benefits of HTTP/2. There is no qualifying products to buy and nothing to turn-on. It is live and part of our content delivery network. As Ron Burgundy might say, “it’s kind of a big deal.”
It’s no surprise then, that CDNs scrambled to quickly find a way to support HTTP/2 traffic. However, in their rush to be first, many CDNs opted to use shortcuts that actually reduced or even reversed the intended performance gains of HTTP/2. Two common shortcuts were:
- Using a “terminator:” a server that converts HTTP/2 traffic to HTTP/1.1 at the point where a connection reaches the CDN’s servers, resulting in increased latency.
- Building a smaller, separate network to handle HTTP/2 traffic, leading to reduced capacity.
Like patching a leak with duct tape instead of replacing the pipe, both these methods could “handle” HTTP/2 traffic in the short-term, but would become problematic as HTTP/2 became more mainstream. Here at Verizon Digital Media Services, we believed there was a better way. Instead of cutting corners to implement HTTP/2 quickly, it’s better to put in the time to build a longer-lasting solution. So instead of using hardware workarounds, we did a full software overhaul, refactoring our code so that HTTP/2 would be natively built into all our servers. We knew this approach would involve a lot more engineering and would take us longer to implement, but we believed it was the right decision. It would maximize the performance benefits seen by our Edgecast CDN customers. Here are four ways we expect this native implementation of HTTP/2 to impact the performance of a website:
1. Faster performance due to no added latency
When someone clicks to visit a website, her browser sends a request to the CDN’s servers asking for the objects that make up the page (such as images and CSS files). The amount of time it takes the server to receive and process each of these requests is called “latency.” When CDNs use a shim to handle HTTP/2 traffic, they are effectively placing an additional server in front of their existing servers to convert the connection from HTTP/2 back into HTTP/1.1. While this process allows them to keep the same infrastructure they’ve used for years, it means the website now loads more slowly because there is one more server taking additional time to receive and process requests for every object on the website. Since we’ve implemented HTTP/2 natively, we have no need to use extra servers and therefore have added no latency.
2. Ability to manage large spikes in traffic
One of the main reasons companies choose to use CDNs is to manage large spikes of traffic — like when an online retailer is having a big holiday sale or a sports network is broadcasting a championship game. However, when CDNs build smaller, dedicated networks to handle HTTP/2 traffic instead of revamping their existing networks, their ability to manage these huge surges of traffic is compromised. In turn, a CDN might boast having 200,000 servers, but only 2,000 of them are able to handle HTTP/2 traffic. If there’s a sudden influx of HTTP/2 connections, its dedicated network might get overloaded — leading a website to slow down or even crash.
3. Quicker retrieval of uncached data
When a visitor clicks to view fresh content on a website (like a newly uploaded video, article or piece of merchandise), a CDN has to connect to the origin server to pull that file into cache before delivering it to the visitor. One benefit of having HTTP/2 built natively into our infrastructure is that connections to a customer origin can also take place over HTTP/2, leading to faster overall performance and less wait time for visitors.
4. More effective server push
Server push is a feature in HTTP/2 that allows a server to anticipate which files a viewer might request and “push” them to the viewer before he even asks for them. Before, with HTTP/1.1, when a visitor landed on a page, his browser would have to ask the server for each object on the page, one-by-one. Server push aims to save round-trips of communication by guessing which files the viewer will need upfront. Server push is a bit like an astute waiter who, when you order the burger, also brings out a bottle of ketchup without you needing to ask for it.
However, since server push is a new technology, it hasn’t been perfected. Our research shows that today, up to 50 percent of server pushes fail due to variables like pushing at the wrong time or pushing files already in cache. These failures lead to website slowdowns, as HTTP/2 isn’t meeting its full potential for speed. We’re working on a machine learning methodology whereby tracking traffic and requests for a website over time, we learn exactly which files need to be pushed and the exact time to push them to get the maximum performance benefit. This should increase the success rate of server push and reduce the work our clients have to do.
Refactoring our entire web server infrastructure and technology stack certainly isn’t easy, but we believe it’s the only correct way to implement HTTP/2. Not only will our CDN customers see better performance today, but they’ll also see it tomorrow, as we’ve laid the groundwork to more quickly adapt to new protocols in the future.
With contribution from Tiffany Chi of the Hippo Thinks research network.