HTTP over UDP: an Experimental Investigation of QUIC Gaetano Carlucci Luca De Cicco Saverio Mascolo Politecnico di Bari & Politecnico di Bari & Politecnico di Bari & Quavlive, Italy Quavlive, Italy Quavlive, Italy [email protected] [email protected] [email protected] ABSTRACT Application layer HTTP SPDY QUIC This paper investigates \Quick UDP Internet Connections" (TLS) (TLS) (Crypto) (QUIC), which was proposed by Google in 2012 as a reliable Transport layer protocol on top of UDP in order to reduce Web Page re- TCP TCP UDP trieval time. We first check, through experiments, if QUIC can be safely deployed in the Internet and then we evalu- Internet layer ate the Web page load time in comparison with SPDY and IP IP IP HTTP. We have found that QUIC reduces the overall page a) b) c) retrieval time with respect to HTTP in case of a channel without induced random losses and outperforms SPDY in Figure 1: HTTP, SPDY and QUIC stack the case of a lossy channel. The FEC module, when en- is meant to overcome the following inefficiencies of HTTP: 1) abled, worsens the performance of QUIC. a HTTP client can only fetch one resource at a time, even if this issue can be in part mitigated with pipelining; 2) Keywords a client-server pull-based communication model is used; if a TCP, UDP, HTTP, SPDY, QUIC, congestion control server knows that a client needs a resource, there is no mech- anism to push the content to the client; 3) it redundantly 1. INTRODUCTION sends several headers on the same channel. HTTP/1.1 Web browsers attempt to address these issues by opening multiple HTTP is the most used application level protocol over the concurrent HTTP connections, even though this approach is Internet [1]. Recent studies argue that HTTP will represent discouraged in the HTTP/1.1 RFC which suggests a limit the narrow waist of the future Internet [12]. During the past of two concurrent connections for each client-server pair. decade its adoption has experienced a tremendous growth To address these issues SPDY introduces the following [10] mainly fueled by the wide diffusion of HTTP-based in- features: 1) it multiplexes concurrent HTTP requests on frastructure such as Content Distribution Networks (CDNs), a single TCP socket; 2) it compresses HTTP headers; 3) proxies, caches, and other middle-boxes. This growth is it enables the server to push data to the client whenever driven by video content delivered using HTTP, which is to- possible; 4) it allows prioritization among parallel requests. day the first source of Internet traffic. In fact, video over SPDY has already been deployed world-wide in the Chrome HTTP is the mainstream choice employed by all major video Web browser and it shows encouraging improvements with distribution platforms including the ones based on the recent 1 respect to HTTP/1.1 [2] in the case of wired networks, but it MPEG-DASH , HLS standards, and the VoD systems such is still not clear whether it is able to improve performances as YouTube and NetFlix [5]. in the case of cellular networks [7]. The fact that SPDY em- Despite its widespread use, some inefficiencies of HTTP ploys only one TCP socket to deliver all the Web resources to are hindering the development of a faster Internet. The goal the client has the advantage of decreasing the port usage at of improving HTTP/1.1 has attracted researchers [12] and the server, but has a key drawback: by multiplexing streams industries, among which Google that has recently proposed 2 over a single TCP connection put SPDY in disadvantage SPDY [4] within the IETF working group HTTPbis . SPDY when compared to several HTTP/1.1 connections each with 1http://dashif.org/mpeg-dash/ a separate congestion window. In fact, a single lost packet in 2http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/ an underlying TCP connection triggers a congestion window decrease for all of the multiplexed SPDY streams, whereas in the case of N parallel HTTP/1.1 connections it would affect Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed only one out of the N parallel connections. Another disad- for profit or commercial advantage and that copies bear this notice and the full cita- vantage of SPDY is that an out-of-order packet delivery for tion on the first page. Copyrights for components of this work owned by others than TCP induces head of line blocking for all the SPDY streams ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- multiplexed on that TCP connection. Moreover, SPDY con- publish, to post on servers or to redistribute to lists, requires prior specific permission nection startup latency depends on TCP handshake which and/or a fee. Request permissions from [email protected]. requires one RTT and in the case SSL/TLS is employed up ACM SAC’15, April 13 - 17 2015, Salamanca, Spain Copyright 2015 ACM 978-1-4503-3196-8/15/04 ...$15.00. to three RTT. http://dx.doi.org/10.1145/2695664.2695706 . All the inefficiencies mentioned above are due to the use of TCP as transport protocol. This has motivated Akamai Requests HTTP HTTP and Google to propose new reliable protocols on top of UDP. Client Internet 12 3 4 5 6 7 8 Server Akamai has proposed a Hybrid HTTP and UDP content TCP Connection delivery protocol that is employed in its CDN [11]. Google is aiming at reducing TCP handshake time [13] and, more a) HTTP recently in [8], at improving TCP loss recovery mechanism. Unfortunately, the improvements above mentioned are not Requests implemented in the default version of TCP. Motivated by QUIC streams Internet 1 2 3 QUICQUIC this evidence Google has proposed QUIC [14] over UDP Client 4 5 6 Server to replace HTTP over TCP. QUIC has been already de- 7 8 ployed by Google in their servers, such as the ones powering YouTube, and can be activated in the Web client Chrome UDP Connection browser that runs on billions of desktop and mobile devices. b) QUIC This puts Google in the position of driving a switch of a siz- able amount of traffic from HTTP over TCP to QUIC over Figure 2: Multiplexing UDP. The contribution of this paper is twofold: 1) we provide an experimental investigation of QUIC to check whether its de- HTTP QUICHTTP QUIC Client Server Client Server ployment can be harmful for the network; 2) we assess the TCP QUIC performance of QUIC compared to SPDY and HTTP/1.1 1 RTT 1 RTT StartUp in terms of Page Load Time reduction. To the best of Handshake our knowledge, this is the first experimental investigation 1 RTT TLS of QUIC. negotiation 1 RTT 2. THE QUIC PROTOCOL a) b) Quick UDP Internet Connections (QUIC) is an experi- mental protocol proposed by Google and designed to pro- Figure 3: Startup latency vide security and reliability along with reduced connection 2) traffic bundling over the same UDP connection; 3) com- and transport latency. Google has already deployed QUIC pression of HTTP headers over the same connection. protocol in their servers and has a client implementation in By using the UDP, QUIC is able to eliminate the HOL the Chrome web browsers. issue affecting the SPDY multiplexed streams; for instance Figure 1 shows the main architectural differences between in the case of Figure 2(a) if packet n.1 is lost and all the other HTTP over TCP (Figure 1(a)), SPDY over TCP (Figure packets are received, all packets must wait until the lost 1 (b)) and QUIC over UDP (Figure 1(c)). The main idea packet is retransmitted before TCP can deliver the data to behind QUIC is to use the UDP to overcome the SPDY the application (TCP does not allow out-of-order delivery); inefficiencies as discussed in Section 1 along with an ad-hoc on the other hand UDP can deliver all the received packet designed encryption protocol named \QUIC Crypto" which to the application without waiting for the retransmission. provides a transport security service similar to TLS. Since the UDP is unreliable and does not implement con- 2.2 Connection startup latency and security gestion control, QUIC implements retransmissions and con- Figure 3(a) shows the time required to setup a TCP con- gestion control at the application layer. Furthermore, QUIC nection: it takes one RTT for the handshake and at least leverages most part of the SPDY design choices to inherit one extra RTT or two in the case of an encrypted connec- its benefits. tion over TLS. When QUIC is used (Figure 3(b)), the time A description of the QUIC protocol based on the official taken to set up a connection is at most one RTT; in the documentation [14] and on the analysis of the Chromium case the client has already talked to the server before, the code base is following below3. startup latency takes zero RTT even in case of an encrypted connection (QUIC uses its own encryption algorithm named 2.1 Multiplexing QUIC-Crypto). QUIC-Crypto decrypts packets indepen- QUIC multiples several QUIC streams over the same UDP dently: this avoids serialized decoding dependency which connection. Figure 2(a) shows that with HTTP/1.1 a client would damage QUIC ability to provide out-of-order deliv- can only fetch one resource at a time (even if they are ery to reduce the HOL. pipelined) whereas with QUIC (Figure 2(b)) a client can send multiple HTTP requests and receive multiple responses 2.3 Forward Error Correction over the same UDP socket (in the case of Figure 2 three re- Another interesting feature of QUIC is the Forward Er- sources are requested).