[Note the ticket has morphed a bit, and older comments at the top may not be very relevant anymore!]
We should support HTTP2, as this is the true standard that replaces the experimental SPDY and brings mostly the same benefits we've enjoyed so far with SPDY. Note that our current production TLS terminators already support ALPN w/ SPDY, so ALPN-vs-NPN isn't an issue anymore.
Our current termination software is nginx 1.9.4 with a few extra local patches in support of parallel RSA+ECDSA certs. Upstream nginx introduced HTTP2 support with their release of version 1.9.5. However, they made an implementation decision to replace SPDY/3 support with HTTP2 support, rather than support both protocols side-by-side. We believe that was a very poor decision, as it would have been easy to support both in the patches, and client statistics indicate the real world still has a fair number of clients out there which are SPDY- but not HTTP2- capable.
Our preliminary stats from sampling live TLS ClientHello data from our traffic (this was a fairly small sample, but I wouldn't expect too much change from a larger one) were:
On a practical level, SPDY/3 and HTTP2 are both doing the same job in terms of effects on client and server performance and such. If the stats above are broadly-accurate and we dropped SPDY/3 support for HTTP2 support today, we'd fall from ~50% of client connections on SPDY to only ~27% of client connections on HTTP2.
For an extra kick, this now also blocks us from upgrading to nginx 1.9.5 or higher in general, should we want to do so to apply fixes and improvements to other unrelated things. We have a few basic categorical options here:
- Re-work nginx's HTTP2 patch such that it doesn't remove SPDY/3 support, and then sort out making that into a reasonable diff against current nginx 1.9.x code. Not completely trivial, but not all that difficult either given the patch history / diffs available at http://nginx.org/patches/http2/ . Kind of awful in the sense of moving further away from upstream and having to deal with more local code maintenance burden.
- Convince upstream nginx to do something similar on their own.
- Do all the work of option 1 ourselves, and submit the patches and get them included in upstream, removing the latter half of the problem in option 1.
- Move to a different TLS termination software altogether, which ideally supports SPDY/3 + HTTP2, or at least supports SPDY/3 and has future plans to introduce HTTP2 alongside it (so that at least we can continue tracking upstream on unrelated bugs/improvements, unlike the situation with nginx today). Apache might be an option here, but there are probably others that fit the bill as well. Some googling and evaluating is in order.