Is the Web Ready for HTTP/2 Server Push?
Total Page：16
File Type：pdf, Size：1020Kb
Is the Web ready for HTTP/2 Server Push? Torsten Zimmermann, Benedikt Wolters, Oliver Hohlfeld, Klaus Wehrle Communication and Distributed Systems, RWTH Aachen University {zimmermann,wolters,hohlfeld,wehrle}@comsys.rwth-aachen.de ABSTRACT 240K HTTP/2 800 Server Push HTTP/2 supersedes HTTP/1.1 to tackle the performance challenges 180K 400 of the modern Web. A highly anticipated feature is Server Push, 120K enabling servers to send data without explicit client requests, thus J F M A M J J A S O N D J F M A M J J A S O N D potentially saving time. Although guidelines on how to use Server Figure 1: Adoption of HTTP/2 and Server Push over the course Push emerged, measurements have shown that it can easily be used of one year1(2017) on the Alexa 1 M list [39]. Although the use of in a suboptimal way and hurt instead of improving performance. We both is increasing, the adoption of Server Push is relatively low. thus tackle the question if the current Web can make better use of Server Push. First, we enable real-world websites to be replayed in a testbed to study the effects of different Server Push strategies. Using This potential for speeding up the Web manifests in a grow- this, we next revisit proposed guidelines to grasp their performance ing interest in Server Push, both among CDNs [10, 38] and in impact. Finally, based on our results, we propose a novel strategy research [14, 22, 32, 39]. These efforts face the challenge that the using an alternative server scheduler that enables to interleave standard only defines the Server Push protocol, not how touse resources. This improves the visual progress for some websites, with it, i.e., what to push when, determining its performance. In this minor modifications to the deployment. Still, our results highlight regard, previous work provided several strategies or approaches the limits of Server Push: a deep understanding of web engineering how to use Server Push. They involve signaling clients what to is required to make optimal use of it, and not every site will benefit. fetch next [32], dependency analysis of content [14], gaze tracking to identify regions of interest to be pushed [22], or guidelines for CCS CONCEPTS its basic usage [10]. However, its usage is still low relative to the H2 • Networks → Application layer protocols; Network mea- adoption (cf. Fig. 1) [35, 39]—potentially given its complex usage. surement; In previous studies, we showed that Server Push can be easily used suboptimally in real-world deployments and hurt instead of im- KEYWORDS proving performance [39, 40]. These findings, as well as discussions among web and protocol engineers [7, 23, 26, 28], highlight that HTTP/2, Server Push, Interleaving Push the quest for optimal Server Push usage is far from being settled. ACM Reference Format: We thus tackle the question what influences the Server Push Torsten Zimmermann, Benedikt Wolters, Oliver Hohlfeld, Klaus Wehrle. performance, how push strategy performance can be reproducibly 2018. Is the Web ready for HTTP/2 Server Push?. In CoNEXT ’18: Interna- tested on any website, and how a new strategy can speed up the cur- tional Conference on emerging Networking EXperiments and Technologies, December 4–7, 2018, Heraklion, Greece. ACM, New York, NY, USA, 7 pages. rent Web without major modifications. Specifically, we i) propose a https://doi.org/10.1145/3281411.3281434 new evaluation method to automatically and reproducibly evaluate Server Push strategies on any website by replay. This complements 1 INTRODUCTION measurements of real-world deployments and provides a method to systematically understand the isolated baseline performance of The Hypertext Transfer Protocol (HTTP) is the de-facto protocol Server Push strategies for a broad class of websites. We ii) use this for realizing desktop and mobile websites as well as applications. method to study the performance impact of strategies on real-world Traffic shares of > 50 %, e.g., in a residential access link [24], an and synthetic websites. In this regard, we revisit existing strategies IXP [6], or backbone [12, 33], express this dominance. Despite this, arXiv:1810.05554v1 [cs.NI] 12 Oct 2018 proposed in related work and find that pushing all objects, asa HTTP-based applications are built on top of a protocol designed straightforward approach, can hurt the performance. By varying nearly two decades ago, now suffering from various inefficiencies in the amount, order, and type of objects, we observe positive and the modern Web, e.g., Head of Line (HoL) blocking. To address the negative effects, highlighting the challenge of optimal usage. Given drawbacks, HTTP/2 (H2) was standardized [8] as H1’s successor. these results and based on an analysis of the respective rendering Among others, a highly anticipated feature [17] is Server Push, process in the browser, we iii) investigate a new approach to push changing the pull-only into a push-enabled Web. It enables servers the right resource at the right time, by interleaving the base docu- to send additional resources without explicit requests, e.g., send a ment and pushed objects. This can lead to a faster visual progress CSS upon a request for index.html, thus saving round trips. for some popular websites. Still, our results also highlight the limits CoNEXT ’18, December 4–7, 2018, Heraklion, Greece of Server Push, as it requires a deep understanding of the load and © 2018 Association for Computing Machinery. This is the author’s version of the work. It is posted here for your personal use. render process and not every website can benefit. Not for redistribution. The definitive Version of Record was published in CoNEXT ’18: International Conference on emerging Networking EXperiments and Technologies, December 4–7, 2018, Heraklion, Greece, https://doi.org/10.1145/3281411.3281434. 1Live results available at https://netray.io CoNEXT ’18, December 4–7, 2018, Heraklion, Greece Zimmermann et al. 2 BACKGROUND 3 RELATED WORK We now briefly present an overview of H2, as well as two prominent Our work relates to approaches that focus on H2 and Server Push metrics to assess the performance of websites. performance, as well as frameworks and guidelines. H2. Wang et al. [37] provided the first analysis of SPDY, H2’s prede- 2.1 H2 Overview cessor. Comparing SPDY to H1 on the transport level, they observe H2 was standardized in 2015 [8] to replace H1. A key difference is benefits, especially for large objects and low loss, and for fewsmall a binary instead of an ASCII representation, allowing easier fram- objects in good conditions with large TCP initial windows. Also, ing and parsing, which increases the processing efficiency [17]. Server Push can improve PLT for large RTTs, but the analysis of Further, H2 allows to multiplex requests/responses over one con- several policies also reveals impairments. De Saxcé et al. [15] eval- nection, leading to parallel streams, identified by IDs. Clients can uate H2 and focus on latency and loss, showing that H2 is less prioritize streams, e.g., to prefer certain objects. Multiplexing also prone to higher latencies than H1. They regard Server Push as valu- reduces application layer HoL blocking, an issue in H1. Like H1, able, but more performance research is required. Varvello et al. [35] H2 is stateless, thus header information for a connection is repeti- present an adoption study (Alexa 1 M) and compare the real-world tive. As mitigation, H2 adds header compression [30]. Though not performance of H2 websites to their H1 counterparts. They observe mandatory, most implementations use H2 via TLS. Besides privacy benefits for 80 % of websites, but also degradations, without an and security benefits, a TLS-tunnel over deployed intermediaries explicit focus on Server Push. eases the deployment of new protocols [17]. Server Push. In previous work [39], we complement the view on H2 Server Push. Finally, H2 adds Server Push. To grasp its poten- H2’s adoption provided in [35] and target broader sets, i.e., IPv4 tial benefits, recall the classic H1 request/response model: a browser scans and all .com/.net/.org domains, and Server Push explicitly. requests the base document, parses it, and then requests all discov- While the adoption of H2 and Server Push is rising, the latter is ered objects individually. Contrary, an H2 server can push objects orders of magnitude lower (cf. Fig. 1). Using different protocol set- without explicit request, e.g., a CSS upon a request to index.html, tings, we observe that Server Push can improve as well as hurt thus saving round trips. Hence, H2 allows transferring resources the performance, but the results cannot be mapped to simple rea- before the browser finishes parsing. To push, a server announces sons (e.g., amount of bytes pushed), and that further analysis is information about the object and stream it will use. Afterward, the required. Instead of resources, Han et al. [20] propose to push hints, data is sent. A server is only allowed to push content from ori- enabling the client to request critical resources earlier, which can gins under its authority. Further, a client can cancel an announced improve the performance. Rosen et al. [31] analyze the benefits and push, which is useful if the object is already cached. Also, a client challenges of Server Push and show that network characteristics can deactivate the feature by setting SETTINGS_ENABLE_PUSH in play a major role in the effectiveness, similar to [15, 37]. As one a specific settings header to 0 at connection startup. Yet, as seen guideline, they propose to push as much as possible, which not al- in own measurements, by the time a client cancels the push, the ways leads to improvements.