I'm not sure if the behaviour they encountered in testing generalises to actual production environments. Specifically: > Penalty #2: TCP window size will drop

I'm not sure if the behaviour they encountered in testing generalises to actual production environments. Specifically: > Penalty #2: TCP window size will drop dramatically, and all streams will be simultaneously throttled down. This implies that, for both HTTP/1 and /2 connections, throughput per connection can be limited by min(throughput) for that connection. With a http/2 connection being used for multiple streams, and therefore more packets, the connection is more likely to get hit by a dropped packet. That scenario doesn't quite seem to be realistic, because it assumes that dropped packets are independent (3% in the test). The rate of injected errors was apparently also not adjusted for any of the factors that would affect errors in the real world, such as package size and (attempted) speed. But reducing sizes and throttling are direct countermeasures intended to provide maximum throughput even on flakey connections. Since any connection problems are bound to be highly correlated per client, it would seem that http/2 may actually perform faster than /1 because the "information" about connection troubles, and the countermeasures, are applied to a larger number of streams.