HTTP OVER UDP - Cronologia

SMascolo il 10:03, 26 Gen 2017

2017-01-26T10:03:33Z

SMascolo: /* The QUIC Protocol */

2017-01-26T10:02:38Z

‎The QUIC Protocol

SMascolo il 10:02, 26 Gen 2017

2017-01-26T10:02:22Z

Ldecicco il 17:58, 9 Feb 2016

2016-02-09T17:58:44Z

SMascolo il 16:29, 1 Feb 2016

2016-02-01T16:29:06Z

SMascolo il 16:28, 1 Feb 2016

2016-02-01T16:28:43Z

SMascolo il 16:28, 1 Feb 2016

2016-02-01T16:28:21Z

SMascolo il 16:27, 1 Feb 2016

2016-02-01T16:27:47Z

SMascolo: /* Testbed */

2016-02-01T16:27:00Z

‎Testbed

SMascolo il 16:25, 1 Feb 2016

2016-02-01T16:25:57Z

@@ Riga 9: / Riga 9: @@
 </paper>
 }}
 This paper investigates "Quick UDP Internet Connections"(QUIC), which was proposed by Google in 2012 as a reliable protocol on top of UDP in order to reduce Web Page retrieval time. We first check, through experiments, if QUIC can be safely deployed in the Internet and then we evaluate the Web page load time in comparison with SPDY and HTTP. We have found that QUIC reduces the overall page retrieval time with respect to HTTP in case of a channel without induced random losses and outperforms SPDY in the case of a lossy channel.

@@ Riga 3: / Riga 3: @@
 == The QUIC Protocol ==
 {{Panel|type=primary|icon=graduation-cap|title=HTTP over UDP: an experimental investigation of QUIC|body=
@@ Riga 15: / Riga 9: @@
 </paper>
 }}
 This paper investigates "Quick UDP Internet Connections"(QUIC), which was proposed by Google in 2012 as a reliable protocol on top of UDP in order to reduce Web Page retrieval time. We first check, through experiments, if QUIC can be safely deployed in the Internet and then we evaluate the Web page load time in comparison with SPDY and HTTP. We have found that QUIC reduces the overall page retrieval time with respect to HTTP in case of a channel without induced random losses and outperforms SPDY in the case of a lossy channel.

@@ Riga 7: / Riga 7: @@
 HTTP over UDP: an experimental investigation of QUIC
 </paper>
 This paper investigates "Quick UDP Internet Connections"(QUIC), which was proposed by Google in 2012 as a reliable protocol on top of UDP in order to reduce Web Page retrieval time. We first check, through experiments, if QUIC can be safely deployed in the Internet and then we evaluate the Web page load time in comparison with SPDY and HTTP. We have found that QUIC reduces the overall page retrieval time with respect to HTTP in case of a channel without induced random losses and outperforms SPDY in the case of a lossy channel.

@@ Riga 1: / Riga 1: @@
 [[Category:Research]]
-=Reducing HTTP latency with QUIC=
+=Reducing HTTP latency with Quick UDP Internet Connections (QUIC)=
 == The QUIC Protocol ==

@@ Riga 39: / Riga 39: @@
 <br>
 [[Immagine:http1.png|800px|center|'http1']]
 <center>'''Page Load time: 2.03s'''</center>
 - Six TCP connections are opened (each one requires a TCP and TLS handshake) <br>
@@ Riga 47: / Riga 46: @@
 <br>
 [[Immagine:http2.png|800px|center|'http2']]
 <center>'''Page Load time: 1.45s'''</center>
 - One TCP connection is opened. All the requests are sent when the DOM is loaded.<br>

@@ Riga 55: / Riga 55: @@
 <br>
 [[Immagine:quic.png|800px|center|'quic']]
 <center> '''Page Load time: 1.14s''' </center>
 - One UDP connection. <br>

@@ Riga 40: / Riga 40: @@
 [[Immagine:http1.png|800px|center|'http1']]
 <br>
 - Six TCP connections are opened (each one requires a TCP and TLS handshake) <br>
 - One resource per time is transferred over a connection. <br>
 === Experiment with HTTP/2.0 ===
@@ Riga 48: / Riga 48: @@
 [[Immagine:http2.png|800px|center|'http2']]
 <br>
 - One TCP connection is opened. All the requests are sent when the DOM is loaded.<br>
 - Resources  are multiplexed and sent simultaneously over the single TCP connection. <br>
 === Experiment with QUIC ===
@@ Riga 56: / Riga 56: @@
 [[Immagine:quic.png|800px|center|'quic']]
 <br>
 - One UDP connection. <br>
 - No handshake required. <br>
 === Waterfall diagram Legend ===
 <br>
 [[Immagine:Waterfall.png|600px|center|'Waterfall']]

@@ Riga 36: / Riga 36: @@
 Testbed settings in the scenarios below:  Buffer sizes: Q = BDP  - Base RTT: 50ms - Bottleneck Capacity: 3 Mbps - Loss free channel
-=== Example with HTTP/1.1 ===
+=== Experiment with HTTP/1.1 ===
 <br>
 [[Immagine:http1.png|800px|center|'http1']]
@@ Riga 44: / Riga 44: @@
 '''Page Load time: 2.03s'''
-=== Example with SPDY (HTTP/2.0) ===
+=== Experiment with HTTP/2.0 ===
 <br>
 [[Immagine:http2.png|800px|center|'http2']]
@@ Riga 52: / Riga 52: @@
 '''Page Load time: 1.45s'''
-=== Example with QUIC ===
+=== Experiment with QUIC ===
 <br>
 [[Immagine:quic.png|800px|center|'quic']]

@@ Riga 2: / Riga 2: @@
 =Reducing HTTP latency with QUIC=
-=== The QUIC Protocol ===
+== The QUIC Protocol ==
 <paper authors="Gaetano Carlucci, Luca De Cicco, Saverio Mascolo" conference="Proc. of 30th ACM/SIGAPP Symposium On Applied Computing (SAC 2015)" place="Salamanca, Spain" date="April 2015" pdf="QUIC_SAC15.pdf" slides="quic-slides.pdf">
@@ Riga 10: / Riga 10: @@
 This paper investigates "Quick UDP Internet Connections"(QUIC), which was proposed by Google in 2012 as a reliable protocol on top of UDP in order to reduce Web Page retrieval time. We first check, through experiments, if QUIC can be safely deployed in the Internet and then we evaluate the Web page load time in comparison with SPDY and HTTP. We have found that QUIC reduces the overall page retrieval time with respect to HTTP in case of a channel without induced random losses and outperforms SPDY in the case of a lossy channel.
-=== Motivation ===
+== Motivation ==
 The evolution of the Web in the last decade has given end users a remarkable improvement in the Web navigation experience. In order to transport a Web page the stateless HTTP protocol is employed. The first documented version of HTTP was HTTP V0.9 1 in 1991. HTTP V0.9 was designed to provide a single document request, which was sufficient to deliver a single hypertext document over a TCP connection. The advent of the HTML has changed the Web page structure which is not only made by single document, but it is the result of the composition of several multimedia resources. HTTP/1.0 introduced the notion of HTTP headers, then updated by and HTTP/1.1 which introduced some performance-oriented methods, such as keepalive, pipelining, caching and more. Recently the idea of evolving HTTP/1.1 has attracted researchers and industries which are nowadays proposing HTTP/2.0 within the IETF working group HTTPbis. The main motivation behind the need of evolving HTTP/1.1 can be seen in Figure below which clearly shows that the Page Load Time linearly decreases with Internet latency, while a further increase of the link capacity does not introduce any benefit in the Page Load Time reduction.
@@ Riga 17: / Riga 17: @@
 <br>
-=== The HTTP evolution ===
+== The HTTP evolution ==
 Figure below shows a basic overview on 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 to HTTP/1.0. Then we show the HTTP/2.0 (SPDY) multiplexing and server PUSH and finally QUIC 0-RTT connection set-up.
 <br>
 [[Immagine:HttpEvelution.png|center|'HTTP Evolution']]
-=== Testbed ===
+== 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.
 <br>
@@ Riga 36: / Riga 36: @@
 Testbed settings in the scenarios below:  Buffer sizes: Q = BDP  - Base RTT: 50ms - Bottleneck Capacity: 3 Mbps - Loss free channel
-=== Page Load Time HTTP/1.1 - Waterfall diagram ===
+=== Example with HTTP/1.1 ===
 <br>
 [[Immagine:http1.png|800px|center|'http1']]
@@ Riga 44: / Riga 44: @@
 '''Page Load time: 2.03s'''
-=== Page Load Time HTTP/2.0 - Waterfall diagram ===
+=== Example with SPDY (HTTP/2.0) ===
 <br>
 [[Immagine:http2.png|800px|center|'http2']]
@@ Riga 52: / Riga 52: @@
 '''Page Load time: 1.45s'''
-=== Page Load Time QUIC - Waterfall diagram ===
+=== Example with QUIC ===
 <br>
 [[Immagine:quic.png|800px|center|'quic']]