Web Performance Characteristics of HTTP/2 and Comparison to HTTP/1.1

Abstract

Abstract. The HTTP/1.1 protocol has long been a staple on the web, for both pages and apps. However, it has started to show its age, especially with regard to page load performance and the overhead it entails due to its use of multiple underlying connections. Its successor, the newly standardized HTTP/2, aims to improve the protocol's performance and reduce its overhead by (1) multiplexing multiple resources over a single TCP connection, (2) by using advanced prioritization strategies and by introducing new features such as (3) Server Push and (4) HPACK header compression. This work provides an in-depth overview of these four HTTP/2 performance aspects, discussing both synthetic and realistic experiments, to determine the gains HTTP/2 can provide in comparison to HTTP/1.1 in various settings. We find that the single multiplexed connection can actually become a significant performance bottleneck in poor network conditions with high packet loss and that HTTP/2 rarely improves much on HTTP/1.1, except in terms of reduced overhead. Prioritization strategies, Server Push and HPACK compression are found to have a relatively limited impact on web performance, but together with other observed HTTP/2 performance problems this could also be due to faulty current implementations, of which we have discovered various examples.

FAURAS: A Proxy-based Framework for Ensuring the Fairness of Adaptive Video Streaming over HTTP/2 Server Push

“…We speculate Figure 10. The per-segment bitrate and RTT of the client a 1 in subscenario 2-B that this was because of the deliveries of the wasted PUSH_PROMISE frames that caused the server to delay the downloads of the responses for those segments [39]. Since the client performed similar to the HTTP/1.1 during this period, such large RTTs were unavoidable and resulted in bandwidth underutilization [6,7].…”

FAURAS: A Proxy-Based Framework for Ensuring the Fairness of Adaptive Video Streaming over HTTP/2 Server Push

“…In contrast, for the case of the Proactive method (Figures 9b and 10b), the RTT drastically increased for a consecutive number of segments (nine segments for subscenario 2-A and 12 segments for subscenario 2-B) after the new clients joined at the 100th segment. We speculate that this was because of the deliveries of the wasted PUSH_PROMISE frames that caused the server to delay the downloads of the responses for those segments [39]. Since the client performed similar to the HTTP/1.1 during this period, such large RTTs were unavoidable and resulted in bandwidth underutilization [6,7].…”

“…As a result, the client discards S n i+1 and sends request for S n i+1 , which completely compromises the mechanism of the server push. Hence, not only does the client fail to make use of the advantages discussed in Section 2, but also it wastes the server's network resources utilized for the push segment [39].…”