How Speedy Is SPDY?
Total Page:16
File Type:pdf, Size:1020Kb
How Speedy is SPDY? Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall, University of Washington https://www.usenix.org/conference/nsdi14/technical-sessions/wang This paper is included in the Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’14). April 2–4, 2014 • Seattle, WA, USA ISBN 978-1-931971-09-6 Open access to the Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’14) is sponsored by USENIX How speedy is SPDY? Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall University of Washington Abstract provides only a modest improvement [13, 19]. In our SPDY is increasingly being used as an enhancement own study [25] of page load time (PLT) for the top 200 to HTTP/1.1. To understand its impact on performance, Web pages from Alexa [1], we found either SPDY or we conduct a systematic study of Web page load time HTTP could provide better performance by a significant (PLT) under SPDY and compare it to HTTP. To identify margin, with SPDY performing only slightly better than the factors that affect PLT, we proceed from simple, syn- HTTP in the median case. thetic pages to complete page loads based on the top 200 As we have looked more deeply into the performance Alexa sites. We find that SPDY provides a significant im- of SPDY, we have come to appreciate why it is chal- provement over HTTP when we ignore dependencies in lenging to understand. Both SPDY and HTTP perfor- the page load process and the effects of browser compu- mance depend on many factors external to the protocols tation. Most SPDY benefits stem from the use of a single themselves, including network parameters, TCP settings, TCP connection, but the same feature is also detrimen- and Web page characteristics. Any of these factors can tal under high packet loss. Unfortunately, the benefits have a large impact on performance, and to understand can be easily overwhelmed by dependencies and com- their interplay it is necessary to sweep a large portion of putation, reducing the improvements with SPDY to 7% the parameter space. A second challenge is that there for our lower bandwidth and higher RTT scenarios. We is much variability in page load time (PLT). The vari- also find that request prioritization is of little help, while ability comes not only from random events like network server push has good potential; we present a push pol- loss, but from browser computation (i.e., JavaScript eval- icy based on dependencies that gives comparable perfor- uation and HTML parsing). A third challenge is that de- mance to mod spdy while sending much less data. pendencies between network activities and browser com- putation can have a significant impact on PLT [25]. 1 Introduction In this work, we present what we believe to be the HTTP/1.1 has been used to deliver Web pages using mul- most in-depth study of page load time under SPDY to tiple, persistent TCP connections for at least the past date. To make it possible to reproduce experiments, we decade. Yet as the Web has evolved, it has been criti- develop a tool called Epload that controls the variabil- cized for opening too many connections in some settings ity by recording and replaying the process of a page load and too few connections in other settings, not providing at fine granularity, complete with browser dependencies sufficient control over the transfer of Web objects, and and deterministic computational delays; in addition we not supporting various types of compression. use a controlled network environment. The other key to To make the Web faster, Google proposed and de- our approach is to isolate the different factors that affect ployed a new transport for HTTP messages, called PLT with reproducible experiments that progress from SPDY, starting in 2009. SPDY adds a framing layer for simple but unrealistic transfers to full page loads. By multiplexing concurrent application-level transfers over looking at results across this progression, we can sys- a single TCP connection, support for prioritization and tematically isolate the impact of the contributing factors unsolicited push of Web objects, and a number of other and identify when SPDY helps significantly and when it features. SPDY is fast becoming one of the most im- performs poorly compared to HTTP. portant protocols for the Web; it is already deployed by Our experiments progress as follows. We first com- many popular websites such as Google, Facebook, and pare SPDY and HTTP simply as a transport protocol Twitter, and supported by browsers including Chrome, (with no browser dependencies or computation) that Firefox, and IE 11. Further, IETF is standardizing a transfers Web objects from both artificial and real pages HTTP/2.0 proposal that is heavily based on SPDY [10]. (from the top 200 Alexa sites). We use a decision tree Given the central role that SPDY is likely to play in analysis to identify the situations in which SPDY out- the Web, it is important to understand how SPDY per- performs HTTP and vice versa. We find that SPDY im- forms relative to HTTP. Unfortunately, the performance proves PLT significantly in a large number of scenarios of SPDY is not well understood. There have been sev- that track the benefits of using a single TCP connection. eral studies, predominantly white papers, but the find- Specifically, SPDY helps for small object sizes and un- ings often conflict. Some studies show that SPDY im- der low loss rates by: batching several small objects in a proves performance [20, 14], while others show that it TCP segment; reducing congestion-induced retransmis- 1 USENIX Association 11th USENIX Symposium on Networked Systems Design and Implementation 387 sions; and reducing the time when the TCP pipe is idle. 2.1 Limitations of HTTP/1.1 Conversely, SPDY significantly hurts performance under When HTTP/1.1, or simply HTTP, was designed in the high packet loss for large objects. This is because a set late 1990’s, Web applications were fairly simple and of TCP connections tends to perform better under high rudimentary. Since then, Web pages have become more packet loss; it is necessary to tune TCP behavior to boost complex and dynamic, making it difficult for HTTP to performance. meet the increasingly demanding user experience. Be- Next, we examine the complete Web page load pro- low, we identify some of the limitations of HTTP: cess by incorporating dependencies and computational i) Browsers open too many TCP connections to load delays. With these factors, the benefits of SPDY are re- a page. HTTP improves performance by using parallel duced, and can even be negated. This is because: i) there TCP connections. But if the number of connections is are fewer outstanding objects at a given time; ii) traffic is too large, the aggregate flow may cause network conges- less bursty; and iii) the impact of the network is degraded tion, high packet loss, and reduced performance [9]. Fur- by computation. Overall, we find SPDY benefits to be ther, services often deliver Web objects from multiple do- larger when there is less bandwidth and longer RTTs. For mains, which results in even more TCP connections and these cases SPDY reduces the PLT for 70–80% of Web the possibility of high packet loss. pages, and for shorter, faster links it has little effect, but ii) Web transfers are strictly initiated from the client. it can also increase PLT: the worst 20% of pages see an Consider the loading of embedded objects. Theoreti- increase of at least 6% for long RTT networks. cally, the server can send embedded objects along with In search of greater benefits, we explore SPDY mech- the parent object when it receives a request for the par- anisms for prioritization and server push. Prioritiza- ent object. In HTTP, because an object can be sent only tion helps little because it is limited by load dependen- in response to a client request, the server has to wait for cies, but server push has the potential for significant im- an explicit request which is sent only after the client has provements. How to obtain this benefit depends on the received and processed the parent page. server push policy, which is a non-trivial issue because of iii) A TCP segment cannot carry more than one HTTP caching. This leads us to develop a policy based on de- request or response. HTTP, TCP and other headers could pendency levels that performs comparably to mod spdy’s account for a significant portion of a packet when HTTP policy [11] while pushing 80% less data. requests or responses are small. So if there are a large Our contributions are as follows: number of small embedded objects in a page, the over- A systematic measurement study using synthetic • head associated with these headers is substantial. pages and real pages from 200 popular sites that iden- tifies the combinations of factors for which SPDY 2.2 SPDY improves (and sometimes reduces) PLT compared to SPDY addresses several of the issues described above. HTTP. We now review the key ideas in SPDY’s design and im- A page load tool, Epload, that emulates the detailed • plementation and its deployment status. page load process of a target page, including its depen- dencies, while eliminating variability due to browser Design: There are four key SPDY features. computation. With a controlled network environment, i) Single TCP connection. SPDY opens a single Epload enables reproducible but authentic page load TCP connection to a domain and multiplexes multiple experiments for the first time. HTTP requests and responses (a.k.a., SPDY streams) A SPDY server push policy based on dependency over the connection.