| Communication protocol | |
| Purpose | General purpose |
|---|---|
| Developer(s) | IETF,Google |
| Introduction | October 12, 2012; 12 years ago (2012-10-12) |
| Based on | IP, normally layered withUDP |
| OSI layer | Transport layer |
| RFC(s) | RFC 9000,RFC 8999,RFC 9001,RFC 9002 |
| Website | quicwg |
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
QUIC (/kwɪk/) is a general-purposetransport layernetwork protocol initially designed byJim Roskind atGoogle.[1][2][3] It was first implemented and deployed in 2012[4] and was publicly announced in 2013 as experimentation broadened. It was also described at anIETF meeting.[5][6][7][8] TheChrome web browser,[9]Microsoft Edge,[10][11]Firefox,[12] andSafari all support it.[13] In Chrome, QUIC is used by more than half of all connections to Google's servers.[9]
QUIC improves performance of connection-orientedweb applications that before QUIC usedTransmission Control Protocol (TCP).[2][9] It does this by establishing a number ofmultiplexed connections between two endpoints usingUser Datagram Protocol (UDP), and is designed to obsolete TCP at the transport layer for many applications, thus earning the protocol the occasional nickname "TCP/2".[14][additional citation(s) needed] Although its name was initially proposed as an acronym forQuick UDP Internet Connections, in IETF's use of the word, QUIC is not an acronym; it is simply the name of the protocol.[3][8][1]
QUIC works hand-in-hand withHTTP/3's multiplexed connections, allowing multiple streams of data to reach all the endpoints independently, and hence independent ofpacket losses involving other streams. In contrast, HTTP/2 carried over TCP can sufferhead-of-line-blocking delays if multiple streams are multiplexed on a TCP connection and any of the TCP packets on that connection are delayed or lost.
QUIC's secondary goals include reduced connection and transportlatency, andbandwidth estimation in each direction to avoidcongestion. It also movescongestion control algorithms into theuser space at both endpoints, rather than thekernel space, which it is claimed[15] will allow these algorithms to improve more rapidly. Additionally, the protocol can be extended withforward error correction (FEC) to further improve performance when errors are expected. It is designed with the intention of avoidingprotocol ossification.
In June 2015, anInternet Draft of a specification for QUIC was submitted to theIETF for standardization.[16][17] A QUIC working group was established in 2016.[18] 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.[19] In May 2021, the IETF standardized QUIC inRFC 9000, supported byRFC 8999,RFC 9001 andRFC 9002.[20]DNS-over-QUIC is another application.
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.[21]
To do this, TCP breaks up the data intonetwork 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 achecksum that allows the errors within packet data to be detected. When either problem occurs, TCP usesautomatic repeat request (ARQ) to ask the sender to re-send the lost or damaged packet.[21]
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 theHTTP/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 afavicon, the entire rest of the page will wait while that problem is resolved.[21] This phenomenon is known ashead-of-line blocking.
As the TCP system is designed to look like a "data pipe", or stream, it deliberately has little information regarding the data it transmits. If that data has additional requirements, likeencryption usingTLS, 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 ownhandshake process. This often requires several round-trips of requests and responses until the connection is established. Due to the inherentlatency of long-distance communications, this can add significant delay to the overall transmission.[21]
TCP has suffered fromprotocol ossification,[22] due to itswire image being incleartext and hence visible to and malleable bymiddleboxes.[23] One measurement found that a third of paths across the Internet encounter at least one intermediary that modifies TCP metadata, and 6.5% of paths encounter harmful ossifying effects from intermediaries.[24] Extensions to TCP have been affected: the design ofMultipath TCP (MPTCP) was constrained by middlebox behaviour,[25][26] and the deployment ofTCP Fast Open has been likewise hindered.[27][22]
In the context of supportingencryptedHTTP traffic, QUIC serves a similar role as TCP, but with reducedlatency during connection setup and more efficient loss recovery when multiple HTTP streams are multiplexed over a single connection. It does this primarily through two changes that rely on the understanding of the behaviour of HTTP traffic.[21]
The first change is to greatly reduce overhead during connection setup. As most HTTP connections will demandTLS, QUIC makes the exchange of setup keys and listing of supported protocols part of the initialhandshake 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 an unencryptedpipe and then negotiate the security protocol as separate steps. 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 and future requests that would otherwise be negotiated as separate connections.[21]
The second change is to useUDP rather than TCP as its basis, which does not includeloss 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, theprotocol 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.[28]
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 abytestream 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.[8]
Another goal of the QUIC system was to improve performance during network-switching events, like what happens when a user of a mobile device moves from a localWi‑Fi hotspot to amobile 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 to uniquely identify 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'sIP address changes.[29]
QUIC can be implemented in the application space, as opposed to being in theoperating system kernel. This generally invokes additional overhead due tocontext 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.[8]
This organization allows future changes to be made more easily as it does not require changes to thekernel for updates. One of QUIC's longer-term goals is to add new systems forforward error correction (FEC) and improved congestion control.[29]
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 system for rapid fallback to TCP;Chromium's network stack starts both a QUIC and a conventional TCP connection at the same time, which allows it to fall back with negligible latency.[30]
QUIC has been specifically designed to be deployable and evolvable and to have anti-ossification properties;[31] it is the firstIETF transport protocol to deliberately minimise its wire image for these ends.[32] Beyond encrypted headers, it is 'greased'[33] and it has protocol invariants explicitly specified.[34]
 | This sectiondoes notcite anysources. Please helpimprove this section byadding citations to reliable sources. Unsourced material may be challenged andremoved. Find sources: "GQUIC" – news ·newspapers ·books ·scholar ·JSTOR(July 2023) (Learn how and when to remove this 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.
QUIC was developed with HTTP in mind, and HTTP/3 was its first application.[35][36]DNS-over-QUIC is an application of QUIC to name resolution, providing security for data transferred between resolvers similar toDNS-over-TLS.[37] The IETF is developing applications of QUIC for securenetwork tunnelling[36] andstreaming media delivery.[38]XMPP has experimentally been adapted to use QUIC.[39] Another application isSMB over QUIC, which, according to Microsoft, can offer an "SMB VPN" without affecting the user experience.[40] SMB clients use TCP by default and will attempt QUIC if the TCP attempt fails or if intentionally requiring QUIC.
The QUIC code was experimentally developed inGoogle Chrome starting in 2012,[4] and was announced as part of Chromium version 29 (released on August 20, 2013).[19] It is currently enabled by default in Chromium and Chrome.[41]
Support inFirefox arrived in May 2021.[42][12]
Apple added experimental support in theWebKit engine through the Safari Technology Preview 104 in April 2020.[43] Official support was added inSafari 14, included inmacOS Big Sur andiOS 14,[44] but the feature needed to be turned on manually.[45] It was later enabled by default in Safari 16.[13]
The cronet library for QUIC and other protocols is available to Android applications as a module loadable viaGoogle Play Services.[46]
cURL 7.66, released 11 September 2019, supports HTTP/3 (and thus QUIC).[47][48]
In October 2020, Facebook announced[49] that it has successfully migrated its apps, includingInstagram, and server infrastructure to QUIC, with already 75% of its Internet traffic using QUIC. All mobile apps from Google support QUIC, includingYouTube andGmail.[50][51]Uber's mobile app also uses QUIC.[51]
As of 2017[update], there are several actively maintained implementations. Google servers support QUIC and Google has published a prototype server.[52]Akamai Technologies has been supporting QUIC since July 2016.[53][54] AGo implementation called quic-go[55] is also available, and powers experimental QUIC support in theCaddy server.[56] On July 11, 2017, LiteSpeed Technologies officially began supporting QUIC in their load balancer (WebADC)[57] andLiteSpeed Web Server products.[58] As of October 2019[update], 88.6% of QUIC websites used LiteSpeed and 10.8% usedNginx.[59] Although at first only Google servers supported HTTP-over-QUIC connections,Facebook also launched the technology in 2018,[19] andCloudflare has been offering QUIC support on a beta basis since 2018.[60] TheHAProxy load balancer added experimental support for QUIC in March 2022[61] and declared it production-ready in March 2023.[62] As of April 2023[update], 8.9% of all websites use QUIC,[63] up from 5% in March 2021.Microsoft Windows Server 2022 supports both HTTP/3[64] and SMB over QUIC[65][10] protocols viaMsQuic. The Application Delivery Controller ofCitrix (Citrix ADC, NetScaler) can function as a QUIC proxy since version 13.[66][67]
In addition, there are several stale community projects: libquic[68] was created by extracting the Chromium implementation of QUIC and modifying it to minimize dependency requirements, and goquic[69] providesGo bindings of libquic. Finally, quic-reverse-proxy[70] is aDocker image that acts as areverse proxy server, translating QUIC requests into plain HTTP that can be understood by the origin server.
.NET 5 introduces experimental support for QUIC using theMsQuic library.[71]
| Implementation | License | Language | Description |
|---|---|---|---|
| Chromium | BSD-3-Clause License | C++ | This is the source code of theChrome 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 ofLINE'sstellite and Google's cronet. |
| MsQuic | MIT License | C | A cross platform QUIC implementation fromMicrosoft designed to be a general purpose QUIC library. Used in Windows and cross platform by .NET. Rust and C# interop layers available are available, as well as convenience C++ wrapper classes. |
| QUIC Library (mvfst) | MIT License | C++ | mvfst (Pronounced move fast) is a client and server implementation of IETF QUIC protocol in C++ by Facebook. |
| LiteSpeed QUIC Library (lsquic) | MIT License | C | This is the QUIC andHTTP/3 implementation used byLiteSpeed Web Server andOpenLiteSpeed. |
| ngtcp2 | MIT License | C | This is a QUIC library that's crypto library agnostic and works with OpenSSL or GnuTLS. For HTTP/3, it needs a separate library likenghttp3. |
| Quiche | BSD-2-Clause License | Rust | Socket-agnostic and exposes a C API for use in C/C++ applications. |
| quicly | MIT License | C | This library is the QUIC implementation for theH2O web server. |
| quic-go | MIT License | Go | This library provides QUIC support forGo. |
| Quinn | Apache License 2.0MIT License | Rust | An async-friendly QUIC implementation in Rust |
| Neqo | Apache License 2.0MIT License | Rust | This implementation fromMozilla is planned to be integrated in Necko, a network library used in the Firefox web browser |
| aioquic | BSD-3-Clause License | Python | This library features an I/O-free API suitable for embedding in both clients and servers. |
| picoquic | MIT License | C | A minimal implementation of QUIC aligned with the IETF specifications |
| pquic | MIT License | C | An extensible QUIC implementation that includes aneBPF virtual machine that is able to dynamically load extensions as plugins |
| quic | BSD-3-Clause License | Haskell | This package implements QUIC based on Haskell lightweight threads. |
| netty-incubator-codec-quic | Apache License 2.0 | Java | This package implements QUIC in netty based on theQuiche implementation. |
| nodejs-quic | MIT License | NodeJs | This experimental package implements QUIC for Nodejs. |
| s2n-quic | Apache License 2.0 | Rust | Open-source Rust implementation fromAmazon Web Services |
| swift-quic | Apache License 2.0 | Swift | Swift implementation pitched for incubation at theSwift Server Workgroup. |
| TQUIC | Apache License 2.0 | Rust | A high-performance, lightweight, and cross-platform QUIC library |
| nginx | BSD-2-Clause License | C | Open-source QUIC server implementation |
| HAProxy | GNU General Public License version 2 | C | Open-source QUIC server implementation |
| kwik | GNU Lesser General Public License version 3 | Java | Client and server implementations of the QUIC protocol (RFC 9000) in 100% Java. Supports HTTP3 (RFC 9114) with"Flupke" add-on. |
| OpenSSL | Apache License | C | OpenSSL has added QUIC support since version 3.2.[72] |
| GnuTLS | GNU Lesser General Public License version 2.1 | C | GnuTLS has added QUIC support since version 3.7.[73] |
{{cite web}}: CS1 maint: numeric names: authors list (link)developing and deploying networking protocols in user space brings substantial benefits, and it makes development, testing, and iteration cycles faster and easier.
