Utente:Superspritz/Sandbox

QUIC (pronunciato "quick") è un protocollo di rete general purpose di livello di trasporto progettato originariamente da Jim Roskind di Google, implementato e reso operativo nel 2012, annunciato al pubblico nel 2013 in concomitanza con l'ampliamento della sperimentazione e presentato all'IETF. Nonostante sia ancora allo stadio di Internet Draft, oltre la metà delle connessioni tra i browser Chrome e i server di Google utilizzano QUIC. QUIC è supportato inoltre, come opzione non abilitata di serie, da Microsoft Edge, da Firefox e da Safari Technology Preview.

Sebbene il nome proposto fosse in origine l'acronimo per Quick UDP Internet Connections ("Connessioni internet veloci su UDP"), IETF non usa tale definizione e adotta il termine QUIC semplicemente come nome del protocollo.

QUIC migliora le prestazioni delle applicazioni web di tipo connection oriented, che normalmente utilizzano TCP, aprendo una serie di connessioni multiplate tra i due punti terminali utilizzando però User Datagram Protocol (UDP). Questo consente di lavorare a fianco a fianco con le connessioni multiple dell'HTTP/2: in entrambi i casi ogni singolo flusso può raggiungere indipendentemente la destinazione comune senza risentire dell'eventuale perdita di pacchetti sugli altri flussi. Mentre però con HTTP/2, basato su TCP, la perdita o il ritardo eccessivo di alcuni pacchetti influenza comunque la ricostruzione dell'intero flusso da passare all'applicazione web, con QUIC questo problema non è presente grazie all'utilizzo di UDP e alla possibilità di trasferire all'applicazione i dati anche in forma parziale o incompleta. L'effetto risultante è quindi quello di una maggiore responsività dell'applicazione.

Tra gli altri obiettivi di QUIC vi sono la riduzione della latenza della connessione e del trasporto e la stima dell'impiego di banda su entrambe le direzioni per evitare congestioni. Sposta inoltre l'esecuzione degli algoritmi di controllo della congestione nello spazio utente ai punti terminali invece che nello spazio del kernel, affermando che questo consente ne velocizza il miglioramento. Infine, il protocollo prevede come successivo passo evolutivo l'impiego di algoritmi di Forward Error Correction (FEC) per un ulteriore miglioramento delle prestazioni in presenza di errori.

In June 2015, an Internet Draft of a specification for QUIC was submitted to the IETF for standardization. A QUIC working group was established in 2016. In October 2018, the IETF's HTTP and QUIC Working Groups jointly decided to call the HTTP mapping over QUIC "HTTP/3" in advance of making it a worldwide standard.

Background

Transmission Control Protocol, or TCP, aims to provide an interface for sending streams of data between two endpoints. Data is handed to the TCP system, which ensures the data makes it to the other end in exactly the same form, or the connection will indicate that an error condition exists.

To do this, TCP breaks up the data into network packets and adds small amounts of data to each packet. This additional data includes a sequence number that is used to detect packets that are lost or transmitted out of order, and a checksum that allows the errors within packet data to be detected. When either problem occurs, TCP uses automatic repeat request (ARQ) to tell the sender to re-send the lost or damaged packet.

In most implementations, TCP will see any error on a connection as a blocking operation, stopping further transfers until the error is resolved or the connection is considered failed. If a single connection is being used to send multiple streams of data, as is the case in the HTTP/2 protocol, all of these streams are blocked although only one of them might have a problem. For instance, if a single error occurs while downloading a GIF image used for a favicon, the entire rest of the page will wait while that problem is resolved.

As the TCP system is designed to look like a "data pipe", or stream, it deliberately contains little understanding of the data it transmits. If that data has additional requirements, like encryption using TLS, this must be set up by systems running on top of TCP, using TCP to communicate with similar software on the other end of the connection. Each of these sorts of setup tasks requires its own handshake process. This often requires several round-trips of requests and responses until the connection is established. Due to the inherent latency of long-distance communications, this can add significant overhead to the overall transmission.

Characteristics

QUIC aims to be nearly equivalent to a TCP connection but with much-reduced latency. It does this primarily through two changes that rely on the understanding of the behaviour of HTTP traffic.

The first change is to greatly reduce overhead during connection setup. As most HTTP connections will demand TLS, QUIC makes the exchange of setup keys and supported protocols part of the initial handshake process. When a client opens a connection, the response packet includes the data needed for future packets to use encryption. This eliminates the need to set up the TCP connection and then negotiate the security protocol via additional packets. Other protocols can be serviced in the same way, combining together multiple steps into a single request-response. This data can then be used both for following requests in the initial setup, as well as future requests that would otherwise be negotiated as separate connections.

QUIC uses UDP as its basis, which does not include loss recovery. Instead, each QUIC stream is separately flow controlled and lost data retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently. This can be very useful in improving performance on error-prone links, as in most cases considerable additional data may be received before TCP notices a packet is missing or broken, and all of this data is blocked or even flushed while the error is corrected. In QUIC, this data is free to be processed while the single multiplexed stream is repaired.

QUIC includes a number of other more mundane changes that also improve overall latency and throughput. For instance, the packets are encrypted individually, so that they do not result in the encrypted data waiting for partial packets. This is not generally possible under TCP, where the encryption records are in a bytestream and the protocol stack is unaware of higher-layer boundaries within this stream. These can be negotiated by the layers running on top, but QUIC aims to do all of this in a single handshake process.

Another goal of the QUIC system was to improve performance during network-switch events, like what happens when a user of a mobile device moves from a local WiFi hotspot to a mobile network. When this occurs on TCP, a lengthy process starts where every existing connection times out one-by-one and is then re-established on demand. To solve this problem, QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes.

QUIC can be implemented in the application-space, as opposed to being in the operating system kernel. This generally invokes additional overhead due to context switches as data is moved between applications. However, in the case of QUIC, the protocol stack is intended to be used by a single application, with each application using QUIC having its own connections hosted on UDP. Ultimately the difference could be very small because much of the overall HTTP/2 stack is already in the applications (or their libraries, more commonly). Placing the remaining parts in those libraries, essentially the error correction, has little effect on the HTTP/2 stack's size or overall complexity.

This organization allows future changes to be made more easily as it does not require changes to the kernel for updates. One of QUIC's longer-term goals is to add new systems for forward error correction (FEC) and improved congestion control.

One concern about the move from TCP to UDP is that TCP is widely adopted and many of the "middle-boxes" in the internet infrastructure are tuned for TCP and rate-limit or even block UDP. Google carried out a number of exploratory experiments to characterize this and found that only a small number of connections were blocked in this manner. This led to the use of a rapid fallback-to-TCP system; Chromium's network stack opens both a QUIC and traditional TCP connection at the same time, which allows it to fallback with zero latency.

Google QUIC (gQUIC)

The protocol that was created by Google and taken to the IETF under the name QUIC (already in 2012 around QUIC version 20) is quite different from the QUIC that has continued to evolve and be refined within the IETF. The original Google QUIC was designed to be a general purpose protocol, though it was initially deployed as a protocol to support HTTP(S) in Chromium, while the current evolution of the IETF protocol QUIC is the general purpose transport protocol. Chromium developers continued to track the evolution of IETF QUIC's standardization efforts to adopt and fully comply with the most recent internet standards for QUIC in Chromium.

Adoption

Client and browser support

The QUIC code was experimentally developed in Google Chrome starting in 2012, and was announced as part of Chromium version 29 (released on August 20, 2013) of Chrome. It is currently enabled by default in Chromium. In the Chrome browser, experimental QUIC support can be enabled in chrome://flags. There is also a browser extension to indicate which pages are served by QUIC.

Similarly, it has been introduced in Opera 16, it can be turned on at opera://flags/#enable-quic and opera://flags/#enable-quic-https, and active sessions can be seen at opera://net-internals/#quic.

Support in Firefox Nightly arrived in November 2019

The cronet library for QUIC and other protocols is available to Android applications as a module loadable via Google Play Services.

Curl 7.66, released 11 September 2019, supports HTTP/3 (and thus QUIC).

Server support

Template:As of there are three actively maintained implementations. Google servers support QUIC and Google has published a prototype server. A Go implementation called quic-go is also available, and powers experimental QUIC support in the Caddy server. On July 11, 2017, LiteSpeed Technologies officially began supporting QUIC in their load balancer (WebADC) and LiteSpeed Web Server products. Template:As of, 88.6% of QUIC websites used LiteSpeed and 10.8% used Nginx. Although at first only Google servers supported HTTP-over-QUIC connections, Facebook also launched the technology in 2018, and Cloudflare has been offering QUIC support on a beta basis since 2018. Template:As of, 4.2% of all websites use QUIC.

In addition, there are several stale community projects: libquic was created by extracting the Chromium implementation of QUIC and modifying it to minimize dependency requirements, and goquic provides Go bindings of libquic. Finally, quic-reverse-proxy is a Docker image that acts as a reverse proxy server, translating QUIC requests into plain HTTP that can be understood by the origin server.

Source code

The following implementations of QUIC or gQUIC are available in source form:

Implementation	Language	Description
Chromium	C++	This is the source code of the Chrome web browser and the reference gQUIC implementation. It contains a standalone gQUIC and QUIC client and server programs that can be used for testing. Browsable source code. This version is also the basis of LINE's stellite and Google's cronet.
QUIC Library (mvfst)	C++	mvfst (Pronounced move fast) is a client and server implementation of IETF QUIC protocol in C++ by Facebook.
LiteSpeed QUIC Library (lsquic)	C	This is the QUIC and HTTP/3 implementation used by LiteSpeed Web Server and OpenLiteSpeed.
Quiche	Rust	Socket-agnostic and exposes a C API for use in C/C++ applications.
quicly	C	This library is the QUIC implementation for the H2O web server.
quic-go	Go	This library provides QUIC support in Caddy web server. Client functionality is also available.
Quinn	Rust
Neqo	Rust	This implementation from Mozilla is planned to be integrated in Necko, a network library used in the Firefox web browser
aioquic	Python	This library features an I/O-free API suitable for embedding in both clients and servers.
picoquic	C	A minimal implementation of QUIC aligned with the IETF specifications
pquic	C	An extensible QUIC implementation that includes an eBPF vrtual machine that is able to dynamically load extensions as plugins
MsQuic	C	A cross platform QUIC implementation from Microsoft designed to be a general purpose QUIC library.

See also

• Structured Stream Transport
• Constrained Application Protocol (CoAP) – a UDP-based protocol utilizing REST model
• HTTP/3
• SPDY
• Datagram Transport Layer Security (DTLS)
• Datagram Congestion Control Protocol (DCCP)
• Reliable User Datagram Protocol (RUDP)
• Real-Time Media Flow Protocol (RTMFP)
• LEDBAT (Low Extra Delay Background Transport)
• Micro Transport Protocol (µTP)
• Multipurpose Transaction Protocol (MTP/IP) – an alternative to QUIC from Data Expedition, Inc.
• Stream Control Transmission Protocol (SCTP UDP Encapsulation; RFC 6951)
• UDP-based Data Transfer Protocol (UDT) – a UDP-based transport protocol
• Fast and Secure Protocol

External links

• IETF QUIC Specification, Draft 27
• Chromium: QUIC, a multiplexed stream transport over UDP
• QUIC: Design Document and Specification Rationale, Jim Roskind's original document (2012/2013)
• Daniel Stenberg: HTTP/3 explained
• Linux Weekly News: Connecting on the QUIC (2013)
• QUIC:, IETF-88 TSV Area Presentation (2013-11-07)
• Chromium Blog: Experimenting with QUIC (2013)
• QUIC: next generation multiplexed transport over UDP (Google Developers, 2014)
• HTTP over UDP: an Experimental Investigation of QUIC
• Multipath QUIC (extension to QUIC)
• Innovating Transport with QUIC: Design Approaches and Research Challenges (2017)