DrupalCon Dublin 2016: HTTP/2: what no one is telling you

HTTP/2 (or "H2" as the cool kids call it) has been ratified for months and browsers already support or have committed to supporting the protocol. Everything we hear tells us that the new version of HTTP will provide significant performance benefits while requiring little to no change to our applications -- all the problems with HTTP/1.x have seemingly been addressed, we no longer need the "hacks" that enabled us to circumvent them, and the Internet is about to be a happy place, at last!

But maybe we should put the pom poms down for a minute! Deploying HTTP/2 may not be as easy as it seems, since the protocol brings with it new complications and issues. Likewise, the new features the spec introduces may not work as seamlessly as we'd hope. In this session, we'll take a practical look at HTTP/2 and examine some of its core features and how they relate to real-world conditions. We'll discuss positives, negatives, and new caveats and practical considerations for deploying HTTP/2. Specifically, we'll cover:

- The single-connection model, and the impact of degraded network conditions on HTTP/2 vs HTTP/1

- How server push interacts (or doesn’t) with modern browser caches

- What HTTP/2's flow control mechanism means for server-to-client communication

- New considerations for deploying HPACK compression

- Difficulties in troubleshooting HTTP/2 communications, new tools, and new ways to use old tools

----

The audience will walk understanding the basic concepts of HTTP/2, and its pitfalls, allowing them to properly implement it.

[gagarine]

This is a very interesting talk. But I feel some example are cheery pick to make a point, like in 43:56 with the twitter content security header, most of the website don't have a 2.2k header. I also agree with OMGclueless about the packet loos, they don't append randomly. I feel the conclusion at 56:00 should be at the beginning.

[OMGclueless]

How does webpagetest.org do packet loss? It looks like it's uniformly random, judging by the shapes of the graphs at 18:55. I was under the impression that in the wild, packet loss over TCP tends not to be uniformly random, but rather you are chugging along happily when suddenly up to one TCP window size's worth of packets gets buffered for too long and/or dropped.

Randomly dropped packets are terrible for TCP, because TCP assumes that packet loss indicates congestion. Random packet loss *might* be realistic for a WiFi or mobile connection, but I don't think it's typical even there. So I'm really not all that worried -- if HTTP/2 exposes problems with TCP in conditions with random packet loss, so be it, I don't expect many people to experience those conditions.