I work with HTTP/2 daily, and there are some pain points when running at high speeds:
- Headers are still head of line blocking. You must synchronize sending them to maintain the HPACK table state. At a high number of requests per second, this is a bottle neck
- Running over TLS is CPU bottleneck since encrypted messages are sequential. We get around this by making multiple TCP connections.
- Long lived HTTP/2 connections will often break because of NAT's (home internet), or changing IP address (mobile). A single dropped packet kills throughput for highspeed links too.
All of these are addressed by the QUIC protocol. I suspect that eventually HTTP/2 will be last major protocol over TCP because of most of the aforementioned problems come from running over it.
Does TLS off-loading help in this case?
> Headers are still head of line blocking. You must synchronize sending them to maintain the HPACK table state
Is this still an issue if you only use the static table, and send any other namevalue-pairs as either dynamic non-indexed  or more likely, dynamic never-indexed ?
ChaCha20 takes around 4cycles/byte on a xeon. At 3GHz that's 750MB/s. Or about a 10Gbit pipe fed with a single core, i.e. without any need for parallelization.
 https://cr.yp.to/snuffle/salsafamily-20071225.pdf#2 (page 2)
Now with HTTP/2 there's only one connection and it stays open for a long time so that connection info can be used to identify a client session. It's TLS only so much less likely to be a proxy, since the proxy needs a trusted certificate added to the browser. And also connections to a third-party domain are shared across all pages, so if you are doubleclick.net you know the same user is browsing different sites.
The new protocol makes tracking users much easier and fixes a huge privacy problem in HTTP/1.1.
NAT one is interesting though.
It's one of the easiest ways to distinguish the two versions. Host headers enable virtual hosts (multiple domains on one IP), letting the Internet grow to billions of domains without requiring an IP for each of them.
It's not a replacement/ enhancement of HTTP, it's definitively not a Transport layer. It has no use/gain for webservices, and as single page apps tends to optimise resources delivery (webpack, browserify, scss, stylus & co, very few resources are left to deliver) so no urgent "need" for it here.
So, for an _application layer_ it's comming a little late, i guess "block SPA" with intrisected client side & server side (nodejs/ express & spa) apps might gain of it, but it have to be considered as the very first line of the app developpement , the transition/ enhancement cost / gain ratio for existing apps is too hard to plan.
Great writing !
Also my brief experiments using HTTP/2 in Haskell involved zero changes to my web service handler code, and maybe one or two extra lines to give paths to the TLS cert files. Web services will benefit massively from HTTP/2 in some domains, I do a lot of web geospatial work and using it for servers which return hundreds of image tiles will be a massive win