A SPDY’ier EXPERIENCE: GOOGLE’S SOLUTION TO HTTP’S LATENCY

Olaniyi Q. Jinadu

2014

I. INTRODUCTION HTTP and TCP protocols have been the backbones of the web and mobile/cellular web but these two protocols have a lot of spinning parts that cause them to waste a lot of time during different processes which have made them very inefficient. Both protocols provide very useful features to what we know as the web today like TCP’s reliable transport protocol, providing guaranteed delivery, congestion avoidance and other transport features and HTTP’s response and request semantics, but a lot of latency can be seen within both protocols. This latency becomes very obvious in mobile web because of limited computing power [5] and slow network access in mobile/cellular devices. Even though HTTP was not originally designed to prevent that, as the need to use the web in different everyday life have proven to be more of a necessity now, it is only right for some improvement to be made in this regard. Due to the fact that TCP protocol is not easily deplorable, most of the improvements this paper talks about are in the HTTP protocol because most improvements have been proposed on this level. This paper is concentrated on SPDY, an application-layer protocol for transporting content over the web, designed specifically for minimal latency [1] as a solution or a replacement for HTTP protocol. This paper will compare both protocols’ (i.e. HTTP and SPDY) performance on both the web and mobile web and see if the latency is reduced on both platforms if SPDY is used instead of HTTP.

II. THE HTTP PROTOCOL We will be discussing the HTTP 1.1 protocol in this section. HTTP 1.1 has been updated over the previous HTTP, because it uses a persistent connection i.e. it reuses an established TCP connection and pipelining for requests. So what that means is that after a TCP connection is made (i.e. the handshake), the request is sent to get an object or a page, when the first request is responded to, all subsequent requests can be sent together at once.

The problem with this is that the responses have received in the same order it was sent so if response 2 is lost, response 3, 4 and 5 will also be lost because they have to be received in the order in which they were sent. Another problem is that a lot of mobile devices do not use pipelining so objects will still have to be sent and received after the previous one has been sent successfully. Some other problems associated with HTTP are;

a) The request and response header being uncompressed. When bandwidth is low or if the user is in an area of low

coverage, this will affect latency because requests and responses will take longer to load

b) In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client [1]. III. THE SPDY PROTOCOL

SPDY [1] is a recently proposed application-layer protocol for transporting content over the web with the objective of minimizing latency. The protocol works by opening one TCP connection per domain (or just one connection if going via a proxy). SPDY then allows for unlimited concurrent streams over this single TCP connection. Because requests are interleaved on a single connection, the efficiency of TCP is much higher: fewer network connections need to be made, and fewer, but more densely packed, packets are issued. Although unlimited parallel streams solve the serialization problem, they introduce another one: if bandwidth on the channel is constrained, the client may block requests for fear of clogging the channel. To overcome this problem, SPDY implements request priorities: the client can request as many items as it wants from the server, and assign a priority to each request. This prevents the network channel from being congested with non-critical resources when a high priority request is pending. SPDY compresses request and response HTTP headers, resulting in fewer packets and fewer bytes transmitted. SPDY also has server push and server hint advance features where the resources are sent to the client or suggested to the client respectively

before the clients even ask for them, in cases where it knows the client will need them [1]. These features can reduce the time in which resources will be sent to a client. The SPDY session offers three basic improvements over HTTP [2]:

• Multiplexed requests. There is no limit to the number of requests that can be issued concurrently over a single SPDY connection. Because requests are interleaved on a single channel, the efficiency of TCP is much higher.

• Prioritized requests. Clients can request certain resources to be delivered first. This avoids the problem of congesting the network channel with non-critical resources when a high-priority request is pending.

• Compressed headers. Clients today send a significant amount of redundant data in the form of HTTP headers. Because a single web page may require 50 or 100 sub requests, this data is significant. Compressing the headers saves a significant amount of latency and bandwidth compared to HTTP.

IV. EXPERIMENTAL RESULTS

With a Google Chrome client and a web server running a wired connection, 25 “Top websites” were downloaded and the load time of these websites were computed with only 1% packet loss. It was seen that SPDY performed faster 27 – 60% over HTTP with TCP (without SSL) and 39 – 55% over HTTP with TCP (with SSL). A more detailed table can be seen below;

* In many cases, SPDY can stream all requests over a single connection, regardless of the number of different domains from which requested resources originate. This allows for full parallelization of all downloads. However, in some cases, it is not possible to collapse all domains into a single domain. In this case, SPDY must still open a connection for each domain, incurring some initial RTT overhead for each new connection setup. We ran the tests in both modes: collapsing all domains into a single domain (i.e. one TCP connection); and respecting the actual partitioning of the resources according to the original multiple domains (= one TCP connection per domain). We include the results for both the strict "single-domain" and "multi-domain" tests; we expect real-world results to lie somewhere in the middle [1]. These improvements could be attributed to various reasons including; The role of header compression; SPDY compressed the header of both requests and responses up to approximately 85%. This factor may not seem very significant but on a slow DSL link with a page that has a large number of resources to download (hence a large number of requests and responses), HTTP will perform slower than SPDY. Packet loss and round trip

time also plays a role in web latency. In the case of SPDY, a 48% speed-up can be seen at a 2% packet loss rate compared to HTTP and this is because SPDY sends fewer packets than HTTP which means, SPDY will spend lesser time recovering lost packets. Also since SPDY uses fewer TCP connections, coupled with fewer packets, the probability that it will lose the SYN packet becomes slimmer compared to HTTP. In addition, since SPDY fetches all of its resources in parallel i.e. at a time, it gets resources faster than HTTP when the RTT is significantly high. For example, if there were 20 objects to get and HTTP had 4 connections, it will take 5 RTTs to get all 20 objects whereas in SPDY, it will take 1 RTT to get all 20 objects. This may not seem significant enough but the more the RTT time grows, the more you will be able to see the difference in performances. In addition, there are still areas in which SPDY could improve. In particular:

• Bandwidth efficiency is still low. Although dialup bandwidth efficiency rate is close to 90%, for high-speed connections efficiency is only about ~32%.

• SSL poses other latency and deployment challenges. Among these are: the additional RTTs for the SSL handshake; encryption; difficulty of caching for some proxies. We need to do more SSL tuning.

• Our packet loss results are not conclusive. Although much research on packet-loss has been done, we don't have enough data to build a realistic model for packet loss on the Web. We need to gather this data to be able to provide more accurate packet loss simulations.

• SPDY single connection loss recovery sometimes underperforms multiple connections. That is, opening multiple connections is still faster than losing a single connection when the RTT is very high. We need to figure out when it is appropriate for the SPDY client to make a new connection or close an old connection and what effect this may have on servers.

• The server can implement more intelligence than we have built in so far. We need more research in the areas of server-initiated streams, obtaining client network information for prefetching suggestions, and so on [1].

Now we will discuss SPDY’s performance on cellular devices since we are in an age where the usage of mobile devices, tablets and hand held devices has surpassed that of desktops and laptops. Over cellular networks, when comparing the speed at which SPDY downloads a number of objects from a webpage compared to the speed it takes HTTP to, we will observe various things; there is the initialization stage where the client realizes it needs a particular object as we may recall SPDY has two advance features, server push and server hint, which make this process faster. But even with this, this improvement in performance is not constant with all web pages and we can attribute this to the different scripting languages used on the various websites, like CSS and JavaScript. The effects of these different scripting languages on SPDY have not yet been studied so this theory is still inconclusive. The next period is the time it takes to send the request over the network for these objects. In this stage we witness that the requests happens quickly so no one protocol has

an advantage over the other even though due to SPDY using one TCP connection for all it requests, it requests get to the server faster than that of HTTP since HTTP uses pipelining and will need various connections to send a large number of objects. The next stage is the period of wait between when the requests are sent and the first byte of the first object is received. HTTP outperforms SPDY in this aspect, and SPDY basically gives up any advantage it gained earlier because the delay it experience here are very large. This delay could be attributed to the behavior of the TCP protocol. TCP is responsible for congestion control on the web and there is a congestion window and threshold which if the traffic in the network passes, TCP slows down the rate at which traffic moves through the network until it actually drops the threshold to the slow start threshold. At this point, the network goes into slow start and retransmission occurs. As long as the network keeps getting congested, this process of retransmission will happen over and over again [3]. In the event at which SPDY uses one TCP connection for all its transmission, when this process occurs, all transmission will stop and retransmission will have to occur unlike in the case of HTTP where multiple connections are established to send the same amount of objects, when one TCP connection is affected, all other TCP connections continue to transmit. With an increasing amount of objects and traffic, this TCP behavior does not favor either HTTP or SPDY but when these two protocols are compared with each other, these delays are more significant in SPDY than in HTTP. They are so significant, that they erase any lead or saved time SPDY had earlier on, making HTTP and SPDY perform at the same level.

Further experimentation shows that if the cellular network was put in DCH mode, we see a significant decrease of approximately 91 – 96 % of retransmission in both protocols which improves the latency of both protocols. But the problem with this is that in DCH mode a lot of cellular resources are used and the battery of the cellular devices is drained. So there is a trade-off of power for performance in order to get the desired performance out of both protocols in cellular devices.

V. SUMMARY The SPDY protocol has been proposed as an improvement, and in some cases, a replacement to the highly latent HTTP protocol because of its ability to compress packets thereby using lesser packets than HTTP. It also uses one TCP connection for all transmissions compared to the numerous TCP connections HTTP will have to establish to be able to send the same number of packets. On a wired and WIFI network, these key components in SPDY improved the latency of the web tremendously but SPDY seems to underperform in some areas on wired, WIFI and cellular networks. One key area is the when retransmission occurs due to congestion, SPDY seems to take longer to recover after being put in an idle state because it uses only one TCP connection. Unlike HTTP that uses several TCP connections for transmission, so when one connection enters an idle state due to congestion, the other connections keep on transmitting. This is a major factor because it leads to SPDY performing at the same level as HTTP or it even underperforms. So with this, is SPDY will only be an improvement to HTTP on

a slow DSL network or a wired network with a lot of packets but generally, the behavior of TCP hinders any improvement SPDY was designed to make. A lot of solutions have been proposed like faster retransmit [6] but most of them are in the TCP protocol and will be very difficult to deploy so most solutions are still inconclusive for now.

VI. REFERENCES [1] SPDY: An experimental protocol for a faster web. http://dev.chromium.org/spdy/spdy-whitepaper [2] SPDY Protocol - Draft 1. http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1 [3] Towards a SPDY’ier Mobile Web? Jeffrey Erman, Vijay Gopalakrishnan, Rittwik Jana, K.K. Ramakrishnan [4] Dynamic Adaptive Streaming Over HTTP/2.0 Christopher Mueller, Stefan Lederer, Christian Timmerer, and Hermann Hellwagner [5] Accelerating the mobile web with selective offloading. Xiao Sophia Wang, Haichen Shen, David Wetherall [6] Comparison of Methods for Accelerating the Response Time of TCP Sessions over Long Delay Paths. Ahmed Yusuf Tambuwal, Raffaello Secchi, Gorry Fairhurst [7] How Far Can Client-Only Solutions Go for Mobile Browser Speed? Zhen Wang, Felix Xiaozhu Lin, Lin Zhong, Mansoor Chishtie. [8] ASAP: A Low-Latency Transport Layer Wenxuan Zhou ,Qingxi Li, Matthew Caesar, P. Brighten Godfrey