gaetanoMotivation for This Research
The evolution of the Web in the last decade has given end users a remarkable improvement in the Web navigation experience. To transport a Web page the stateless HTTP protocol is used. A web page is made of many multimedia objects transported by HTTP. HTTP version 1.0 was replaced by HTTP/1.1 which introduced some performance-oriented methods, such as keepalive, pipelining, caching, and more.
After more than a decade from the introduction of HTTP/1.1, the idea of further evolving HTTP has attracted researchers and industries. HTTP/2.0 has been proposed within the IETF working group HTTPbis and afterward HTTP/3.0 followed. The main motivation behind the need to evolve HTTP/1.1 can be seen in the figure below which clearly shows that the Page Load Time linearly decreases with Internet latency. On the other hand, a further increase of the link capacity does not introduce any benefit in the Page Load Time reduction.
High-Performance Browser Networking by Ilya Grigorik.
This means that reducing some HTTP and transport protocol inefficiency dependent on network latency can increase user quality of experience.
Here we evaluate if the transport protocol used by HTTP/3.0 can be safely deployed over the Internet by analyzing its behaviour. This protocol named QUIC "Quick UDP Internet Connections" was proposed by Google in 2012 as a reliable protocol on top of UDP to reduce Web Page retrieval time.
We have checked if QUIC can be safely deployed on the Internet and then we evaluate the Web page load time in comparison with SPDY (HTTP/2.0) and HTTP/1.1.
We have found that QUIC reduces the overall page retrieval time with respect to HTTP in the case of a channel without induced random losses and outperforms HTTP/2.0 in the case of a lossy channel.
The HTTP Evolution
The figure below shows a basic overview of the evolution of the HTTP protocol when downloading a Modern Web Page made of 5 resources as shown in the Figure. We show the benefit of HTTP/1.1 persistent connection and pipelining with respect to HTTP/1.0. Then we show the HTTP/2.0 multiplexing, server PUSH, and QUIC 0-RTT connection set-up.
Evolution of HTTP
Testbed
The figure below shows the testbed employed to compare the performance of HTTP/1.1, HTTP2.0 (SPDY), and QUIC when they are used to download a simple Web page containing only jpeg images without any JavaScript code and CSS file.
Testbed
- HTTP server: Apache/2.4.10 with TLS 1.2.
SPDY server': nghttp2 with TLS 1.2. We have employed nghttp2 which supports SPDY 4 which is the Google implementation of HTTP/2.0.
QUIC server: (version 24) server in Chromium code base with QUIC-Crypto
Netshaper: sets channel capacity and propagation delays.
Real experiments using the open-source browser Chromium. An example of how to use the testbed is available on my GitHub.
Testbed settings in the scenarios below: Buffer sizes: Q = BDP - Base RTT: 50ms - Bottleneck Capacity: 3 Mbps - Loss free channel
Experiment with HTTP/1.1
Page Load time: 2.03s
- Six TCP connections are opened (each one requires a TCP and TLS handshake)
- One resource per time is transferred over a connection.
Experiment with HTTP/2.0
Page Load time: 1.45s
- One TCP connection is opened. All the requests are sent when the DOM is loaded.
- Resources are multiplexed and sent simultaneously over the single TCP connection.
Experiment with QUIC
Page Load time: 1.14s
- One UDP connection.
- No handshake required.
Waterfall Diagram Legend
Legend
Detailed Analysis
This paper contains the details of this research activity.
Gaetano Carlucci, Luca De Cicco, Saverio Mascolo. HTTP over UDP: an experimental investigation of QUIC. Proc. of 30th ACM/SIGAPP SAC 2015, Salamanca, Spain, April 2015