QUIC

QUIC (

QUIC works hand-in-hand with HTTP/3's multiplexed connections, allowing multiple streams of data to reach all the endpoints independently, and hence independent of packet losses involving other streams. In contrast, HTTP/2 hosted on Transmission Control Protocol (TCP) can suffer head-of-line-blocking delays of all multiplexed streams if any of the TCP packets are delayed or lost.

QUIC's secondary goals include reduced connection and transport

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.^[20]

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 arrive 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.^[20]

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.^[20] This phenomenon is known as head-of-line blocking.

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

QUIC aims to be nearly equivalent to a TCP connection but with much-reduced

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 multiple steps into a single request–response pair. 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.^[20]

The second change is to use UDP rather than TCP as its basis, which does not include loss recovery. Instead, each QUIC stream is separately flow controlled and lost data is 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.^[27]

QUIC includes a number of other changes that 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

QUIC can be implemented in the application space, as opposed to being in the

One concern about the move from TCP to UDP is that TCP is widely adopted and many of the "middleboxes" 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.[3] 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 fall back with negligible latency.^[29]

QUIC has been specifically designed to be deployable, evolvable and to have anti-ossification properties;

Google QUIC (gQUIC)

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "GQUIC" – news · newspapers · books · scholar · JSTOR (July 2023) (Learn how and when to remove this template message)

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. The current evolution of the IETF QUIC protocol is a 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.

Applications

QUIC was developed with HTTP in mind, and HTTP/3 was its first application.

The QUIC code was experimentally developed in Google Chrome starting in 2012,^[4] and was announced as part of Chromium version 29 (released on August 20, 2013).^[18] It is currently enabled by default in Chromium and Chrome.^[39]

Support in Firefox arrived in May 2021.^[40][12]

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

cURL 7.66, released 11 September 2019, supports HTTP/3 (and thus QUIC).^[45][46]

In October 2020, Facebook announced^[47] that it has successfully migrated its apps, including Instagram, and server infrastructure to QUIC, with already 75% of its Internet traffic using QUIC. All mobile apps from Google support QUIC, including YouTube and Gmail.^[48][49] Uber's mobile app also uses QUIC.^[49]

Server support

As of 2017^[update], there are several actively maintained implementations. Google servers support QUIC and Google has published a prototype server.

In addition, there are several stale community projects: libquic[66] was created by extracting the Chromium implementation of QUIC and modifying it to minimize dependency requirements, and goquic^[67] provides Go bindings of libquic. Finally, quic-reverse-proxy^[68] 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.

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

References