Varnish HTTP/2 with SSL/TLS offloading on H2O

Varnish is a popular reverse proxy which is used to accelerate page loading by caching copies as static HTML. Varnish does not support SSL/TLS, which is in practise required to take use of the new HTTP/2 protocol. This article describes one way of achieving high performance using Varnish and HTTP/2.

HTTP/2 is the new version of the most prominent protocol on the web. HTTP (the HyperText Transfer Protocol) was originally meant for only for transferring hyper text documents. The previous version (HTTP/1.1) was released in 1999 and is no longer ideal for the modern web. More on HTTP/2 itself here: Nine Things to Expect from HTTP/2

Version two of HTTP is based on the SPDY protocol spearheaded by Google. Both SPDY and HTTP/2 protocol use a binary format for data transfer. To ensure compatibility SPDY chose to transfer data encrypted via SSL to make sure the dataflow continues even through current network architectures such as firewalls.

This was a pragmatic choice as sending encrypted binary data through the pipe is already common place. This translates to increased security as a side effect. HTTP/2 as a protocol does not require the use of SSL/TLS encryption, but all the browser implementations only support HTTP/2 over SSL/TLS.

Varnish, SSL and HTTP/2

It's no secret that the Varnish lead architect and developer Poul-Henning Kamp has not been a great fan of HTTP/2 (Why HTTP/2.0 does not seem interesting, HTTP/2.0 — The IETF is Phoning It In) and reluctant to support SSL in Varnish. He does have good reasoning not adopting SSL to the product for this which he lays out in his article, SSL revisited:

[Handling Certificates in Varnish] I still don't see a way to do that. The Varnish worker-process is not built to compartementalize bits at a cryptographic level and making it do that would be a non-trivial undertaking.

Even though this has been backtracked a bit (SSL/TLS support in Varnish Cache 4.1), it's still the state that Varnish will not fully support SSL/TLS in the near future - if ever. Varnish with HTTP/2 support (over SSL) would still be the best option for performance.

Nginx is the new chief

Currently the defacto way of running encrypted HTTPS sites with Varnish is with a separate server in front. This is called an SSL Offloader and they come in many forms such as physical dedicated devices and specialized software such as Pound. The most common way to do this today is with a web server.

Apache is still the number one web server on the internet. It powers large parts of the web and onwards from version 2.4.17 onwards it comes with HTTP/2 support. There is nothing wrong with Apache (with Fast-CGI and PHP-FPM, for example, it performs very well). But that does not change the fact that Nginx has become the defacto webserver for new developers.

There are plenty of documentation, examples and how-to articles for many scenarios for Nginx. It's a great server for running web applications, proxying and a lot more.

H2O was born to do HTTP/2

Nginx has earned it's popularity as Nginx has a powerful configuration, performs well and is also a capable solution for SSL/TLS Termination (offloading). The latest versions come with experimental HTTP/2 support. But with the evergrowing feature set and capabilities, the role of Nginx is no longer very clear. With the addition of nginScript (a subset of JavaScript used for configuration) it can get quite complex to see what is going on where.

The H2O web server was started in 2014 and is a quite a new product. H2O was built from ground up to support HTTP/2 and it currently has the most advanced server implementation out there. H2O thrives for a small footprint and high performance, due to this it is also remarkably stable for such a new product.

You can run a complete blog (such as the one you are reading) with H2O and PHP for example, but for production use more diverse setups and configuration are often a requirement. For these cases Nginx is perfect, but on the edge of your setup H2O might very well be the best product around.

Separation of application responsibilities

Most web sites don't need to have Varnish, Nginx or H2O setup. They'd do just fine with an old school Apache setup. If you're more used to Nginx configuration you can use that as well. HTTP/2 is not a game changer for end users and shouldn't be advertised as such. This is why you can keep on running Apache or Nginx and upgrade to HTTP/2 when you upgrade to a version that supports it.

It does sound perverse to suggest that a chained setup of three HTTP servers would make sense. But for many cases this is what is being done today, with a common setup being:

Nginx for SSL/TLS termination
Varnish for reverse proxy
Nginx for web application serving

Most often this setup will even run on the same (virtual) server. Nginx can be configured as a reverse proxy, so it is the obvious candidate to go for. But I'll just go ahead and suggest the following setup would be ideal for complex / high traffic sites:

H2O for SSL/TLS termination
Varnish for reverse proxy
Nginx for web application serving

With this setup you would have a clear separation of roles for all three pieces of software. If there's an issue with SSL sertificates, look at H2O. Caches not purging as expected? Gotta be Varnish. Issues with application stability or redirects? "cd /etc/nginx/".

Having separate applications also allows for clearcut horizontal scaling by adding more servers with dedicated roles. In addition to separation and scalability you'll also be able to enjoy the most advanced HTTP/2 implementation talking to your client browsers.

Written by Jani Tarvainen on Wednesday October 14, 2015
Permalink - Tags: http2, nginx, h2o, varnish