Source: Wikipedia, the free encyclopedia.
RFC 9002

QUIC (pronounced "quick") is a general-purpose

Chrome web browser to Google's servers.[9] Microsoft Edge (a derivative of the open-source Chromium browser)[10][11] and Firefox[12] support it. Safari implements the protocol, however it is not enabled by default.[13]

Although its name was initially proposed as the acronym for "Quick UDP Internet Connections",

multiplexed connections between two endpoints using User 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]

QUIC works hand-in-hand with HTTP/2'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

forward error correction (FEC) to further improve performance when errors are expected, and this is seen as the next step in the protocol's evolution. It has been designed to avoid protocol ossification
so that it remains evolvable, unlike TCP which has suffered significant ossification.

In June 2015, an

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.[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

latency of long-distance communications, this can add significant overhead to the overall transmission.[20]

TCP has suffered from

MPTCP was constrained by middlebox behaviour,[24][25] and the deployment of TCP Fast Open has been likewise hindered.[26][21]


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

HTTP traffic.[20]

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. 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 also includes a number of other 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.[8]

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.[28]

HTTP/1Transport Layer SecurityTransmission Control ProtocolHTTP/2TLS 1.2Transmission Control ProtocolHTTP/3TLS 1.3QUICUser Datagram ProtocolInternet Protocol
About this image
Protocol stack of HTTP/3 compared to HTTP/1.1 and HTTP/2

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.[8]

This organization allows future changes to be made more easily as it does not require changes to the

forward error correction (FEC) and improved congestion control.[28]

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;

IETF transport protocol to deliberately minimise its wire image for these ends.[31] Beyond encrypted headers, it is 'greased'[32] and it has protocol invariants explicitly specified.[33]

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. 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 developed with HTTP in mind, and HTTP/3 was its first application.


Browser support

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.[37]

Support in Firefox arrived in May 2021.[38][12]

Apple added experimental support in the WebKit engine through the Safari Technology Preview 104 in April 2020.[39] Official support was added in Safari 14, included in macOS Big Sur and iOS 14,[40] but the feature must be turned on manually.[41]

Client support

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

cURL 7.66, released 11 September 2019, supports HTTP/3 (and thus QUIC).[43][44]

In October 2020, Facebook announced[45] 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.[46][47] Uber's mobile app also uses QUIC.[47]

Server support

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

Citrix (Citrix ADC, NetScaler) can function as a QUIC proxy since version 13.[60][61]

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

.NET 5 introduces experimental support for QUIC using the MsQuic library.[65]

Source code

The following implementations of QUIC or gQUIC are available in source form:
Implementation License Language Description
BSD License
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.
MsQuic MIT License C A cross platform QUIC implementation from Microsoft designed to be a general purpose QUIC library. Used in Windows and cross platform by .NET. Rust and C# interop layers available.
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 and HTTP/3 implementation used by LiteSpeed Web Server and OpenLiteSpeed.
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 like nghttp3.
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 the H2O web server.
quic-go MIT License Go This library provides QUIC support for Go.
Apache License 2.0
Apache License 2.0
Rust This implementation from Mozilla is planned to be integrated in Necko, a network library used in the Firefox web browser
BSD-3-Clause License
Python This library features an I/O-free API suitable for embedding in both clients and servers.
BSD-3-Clause License
C A minimal implementation of QUIC aligned with the IETF specifications
pquic MIT License C An extensible QUIC implementation that includes an eBPF virtual machine that is able to dynamically load extensions as plugins
BSD-2-Clause License
C Quant supports traditional POSIX platforms (Linux, MacOS, FreeBSD, etc.) as well as embedded systems.
BSD-3-Clause License
Haskell This package implements QUIC based on Haskell lightweight threads.
Apache License 2.0
Java This package implements QUIC in netty based on the Quiche implementation.
nodejs-quic MIT License NodeJs This experimental package implements QUIC for Nodejs.
Apache License 2.0
Rust Open-source Rust implementation from Amazon Web Services
Apache License 2.0
Swift Swift implementation pitched for incubation at the Swift Server Workgroup.

See also


  1. ^ . Retrieved 2022-02-08.
  2. ^ a b Nathan Willis. "Connecting on the QUIC". Linux Weekly News. Retrieved 2013-07-16.
  3. ^ a b c "QUIC: Design Document and Specification Rationale". Jim Roskind, Chromium Contributor.
  4. ^ a b "First Chromium Code Landing: CL 11125002: Add QuicFramer and friends". Retrieved 2012-10-16.
  5. ^ "Experimenting with QUIC". Chromium Official Blog. Retrieved 2013-07-16.
  6. ^ "QUIC, Google wants to make the web faster". François Beaufort, Chromium Evangelist.
  7. ^ "QUIC: next generation multiplexed transport over UDP". YouTube. Retrieved 2014-04-04.
  8. ^ a b c d "QUIC: IETF-88 TSV Area Presentation" (PDF). Jim Roskind, Google. Retrieved 2013-11-07.
  9. ^ a b Lardinois, Frederic (18 April 2015). "Google Wants To Speed Up The Web With Its QUIC Protocol". TechCrunch. Retrieved 2016-10-25.
  10. ^ a b Mackie, Kurt; August 26, 2021. "Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser". Redmond Magazine. Retrieved 2022-05-08.
  11. ^ Christopher Fernandes (April 3, 2018). "Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5". Retrieved 2020-05-08.
  12. ^ a b Dragana Damjanovic (2021-04-16). "QUIC and HTTP/3 Support now in Firefox Nightly and Beta". Mozilla. Retrieved 2021-10-11.
  13. ^ "The state of QUIC and HTTP/3 2020". www.fastly.com. Retrieved 2020-10-21.
  14. ^ Tatsuhiro Tsujikawa. "ngtcp2". GitHub. Retrieved 2020-10-17.
  15. ^ "Google Will Propose QUIC As IETF Standard". InfoQ. Retrieved 2016-10-25.
  16. ^ "I-D Action: draft-tsvwg-quic-protocol-00.txt". i-d-announce (Mailing list). 17 Jun 2015.
  17. ^ "QUIC - IETF Working Group". datatracker.ietf.org. Retrieved 2016-10-25.
  18. ^ a b c Cimpanu, Catalin (12 November 2018). "HTTP-over-QUIC to be renamed HTTP/3". ZDNet.
  19. ^ "QUIC is now RFC 9000". www.fastly.com. 2021-05-27. Retrieved 2021-05-28.{{cite web}}: CS1 maint: url-status (link)
  20. ^ a b c d e f Bright, Peter (12 November 2018). "The next version of HTTP won't be using TCP". Arstechnica.
  21. ^ a b Thomson & Pauly 2021, A.5. TCP.
  22. ^ Fairhurst & Perkins 2021, 4. Encryption and Authentication of Transport Headers.
  23. ^ Edeline & Donnet 2019, p. 175-176.
  24. ^ Raiciu et al. 2012, p. 1.
  25. ^ Hesmans et al. 2013, p. 1.
  26. ^ Rybczyńska 2020.
  27. ^ Behr, Michael; Swett, Ian. "Introducing QUIC support for HTTPS load balancing". Google Cloud Platform Blog. Retrieved 16 June 2018.
  28. ^ a b Simon, Clayton (May 2021). "QUIC: A UDP-Based Multiplexed and Secure Transport". IETF.org.{{cite web}}: CS1 maint: url-status (link)
  29. ^ "Applicability of the QUIC Transport Protocol". IETF Network Working Group. Oct 22, 2018.
  30. ^ Corbet 2018.
  31. ^ Trammell & Kuehlewind 2019, p. 2.
  32. ^ Thomson & Pauly 2021, 3.3. Falsifying Active Use.
  33. ^ Thomson 2021, 2. Fixed Properties of All QUIC Versions.
  34. Akamai
  35. ^
  36. .
  37. ^ Liebetrau, Etienne (2018-06-22). "How Google's QUIC Protocol Impacts Network Security and Reporting". Fastvue - Simple Internet Usage Reporting. Retrieved 2022-04-02.
  38. ^ Cimpanu, Catalin (Sep 26, 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved Sep 27, 2019.
  39. ^ "Release Notes for Safari Technology Preview 104". webkit.org. 8 April 2020. Retrieved 7 August 2020.
  40. ^ "Safari 14 Release Notes". developer.apple.com. Retrieved 4 December 2020.
  41. ^ "How to enable HTTP3 in Chrome / Firefox / Safari". bram.us. April 8, 2020.
  42. ^ "Perform network operations using Cronet". Android Developers. Retrieved 2019-07-20.
  43. ^ "curl - Changes". curl.haxx.se. Retrieved 2019-09-30.
  44. ^ "curl 7.66.0 – the parallel HTTP/3 future is here | daniel.haxx.se". Retrieved 2019-09-30.
  45. ^ "How Facebook is bringing QUIC to billions". Facebook Engineering. 2020-10-21. Retrieved 2020-10-23.
  46. ^ "How Google's QUIC Protocol Impacts Network Security and Reporting". Fastvue. 2020-10-21. Retrieved 26 June 2021.
  47. ^ a b Green, Emily (30 September 2020). "This is what you need to know about the new QUIC protocol". NordVPN. Retrieved 26 June 2021.
  48. ^ "QUIC server". 2012. Retrieved 2022-08-17.
  49. ^ QUIC support by Akamai, Retrieved 20 May 2020.
  50. ^ QUIC in the Wild, Passive Active Measurements Conference (PAM), 2018, Retrieved 20 May 2020.
  51. ^ "lucas-clemente/quic-go". Aug 7, 2020. Retrieved Aug 7, 2020 – via GitHub.
  52. ^ QUIC support in Caddy, Retrieved 13 July 2016.
  53. ^ "LiteSpeed Web ADC - Load Balancer - LiteSpeed Technologies". www.litespeedtech.com. Retrieved Aug 7, 2020.
  54. ^ LiteSpeed Technologies QUIC Blog Post, Retrieved July 11, 2017.
  55. ^ "Distribution of Web Servers among websites that use QUIC". w3techs.com. Retrieved Aug 7, 2020.
  56. ^ "Get a head start with QUIC". 2018-09-25. Retrieved 2019-07-16.
  57. ^ "Usage Statistics of QUIC for Websites, April 2023". w3techs.com. Retrieved 2023-04-03.
  58. ^ "Enabling HTTP/3 support on Windows Server 2022". 24 August 2021.
  59. ^ "SMB over QUIC".
  60. ^ "Policy configuration for HTTP/3 traffic | Citrix ADC 13.0".
  61. ^ "Need for speed? – Just an other Citrix ADC Blog".
  62. ^ "devsisters/libquic". Aug 5, 2020. Retrieved Aug 7, 2020 – via GitHub.
  63. ^ "devsisters/goquic". Aug 5, 2020. Retrieved Aug 7, 2020 – via GitHub.
  64. ^ "Docker Hub". hub.docker.com. Retrieved Aug 7, 2020.
  65. ^ ".NET 5 Networking Improvements". .NET Blog. 2021-01-11. Retrieved 2021-01-26.


External links