QUIC

QUIC (/kwɪk/) is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google.REFERENCE FOR RFC9000 IS NOT DEFINED YET. You are invited to add it here.[1][2] It was first implemented and deployed in 2012[3] and was publicly announced in 2013 as experimentation broadened. It was also described at an IETF meeting.[4][5][6][7] QUIC is supported by major web browsers, including Chrome,[8] Edge,[9][10] Firefox,[11] and Safari.[12] In Chrome, QUIC is used by more than half of all connections to Google's servers.[8]

QUIC improves performance of connection-oriented web applications that previously relied on Transmission Control Protocol (TCP).[1][8] It does this by establishing a number of multiplexed connections between two endpoints using User Datagram Protocol (UDP), and it is designed to obsolete TCP at the transport layer for many applications. Although its name was initially proposed as an acronym for Quick UDP Internet Connections, in IETF's use of the word QUIC is not an acronym; it is simply the name of the protocol.[2][7][13]

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, which is carried over TCP, can suffer head-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 transport latency, and bandwidth estimation in each direction to avoid congestion. It also moves congestion control algorithms into the user space at both endpoints, rather than the kernel space, which is claimed[14] to allow these algorithms to improve more rapidly. Additionally, the protocol can be extended with forward error correction (FEC) to further improve performance when errors are expected. It is designed with the intention of avoiding protocol ossification.

In June 2015, an Internet Draft of a specification for QUIC was submitted to the IETF for standardization.[15][16] A QUIC working group was established in 2016.[17] 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.[18] In May 2021, the IETF standardized QUIC in RFC 9000, supported by RFC 8999, 9001 and 9002.[19] DNS-over-QUIC is another application.

## Contents

* 1 Background
* 2 Characteristics
* 2.1 Google QUIC (gQUIC)
* 3 Applications
* 4 Adoption
* 4.1 Browser support
* 4.2 Client support
* 4.3 Server support
* 5 Source code
* 6 See also
* 7 References
* 8 Bibliography
* 9 External links

## Background

Main article: Transmission Control Protocol

Transmission Control Protocol, or TCP, aims to provide an interface for sending streams of data between two endpoints. Data is sent to the TCP system, which ensures it reaches the other end in the exact same form; if any discrepancies occur, the connection will signal an error condition.[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 ask 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 has little information regarding 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 delay to the overall transmission.[20]

TCP has suffered from protocol ossification,[21] due to its wire image being in cleartext and hence visible to and malleable by middleboxes.[22] 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.[23] Extensions to TCP have been affected: the design of Multipath TCP (MPTCP) was constrained by middlebox behaviour,[24][25] and the deployment of TCP Fast Open has been likewise hindered.[26][21]

## Characteristics

Handshake of QUIC compared to TCP with TLS 1.2

In the context of supporting encrypted HTTP traffic, QUIC serves a role similar to that of TCP, but with reduced latency 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.[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 listing of 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 an unencrypted pipe 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.[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 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.[7]

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 local Wi-Fi 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 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's IP address changes.[28]

Error: No valid link was found at the end of line 4.

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

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.[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.[2] 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.[29]

QUIC has been specifically designed to be deployable and evolvable and to have anti-ossification properties;[30] it is the first 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]

The security layer of QUIC is based on TLS 1.2 or TLS 1.3.[34] Earlier insecure protocols such as TLS 1.0 are not allowed in a QUIC stack.

### Google QUIC (gQUIC)

The protocol originally developed by Google, known as gQUIC, was first deployed around 2012 and later brought to the IETF. However, the version of QUIC standardized by the IETF is significantly different from the earlier Google implementation.[35] Google's QUIC was initially designed as a general-purpose web protocol and was deployed mainly to support HTTP and HTTPS in Chromium, using its own encryption and transport mechanisms.[36] In contrast, the IETF QUIC protocol has been redeveloped as a general-purpose transport protocol that uses standard TLS 1.3 for its cryptographic handshake and incorporates a modular packet and connection design intended for broader interoperability.[37] Chromium developers have continued to follow the progress of IETF QUIC standardization and have worked to adopt and comply with the evolving Internet standards for QUIC within Chromium. The transition to IETF QUIC in Chrome began progressing publicly around 2020.[38]

## Applications

QUIC was developed with HTTP in mind, and HTTP/3 was its first application.[39][40] DNS-over-QUIC is an application of QUIC to name resolution, providing security for data transferred between resolvers similar to DNS-over-TLS.REFERENCE FOR RFC9250 IS NOT DEFINED YET. You are invited to add it here. The IETF is developing applications of QUIC for secure network tunnelling[40] and streaming media delivery.[41] XMPP has experimentally been adapted to use QUIC.[42] Another application is SMB over QUIC, which, according to Microsoft, can offer an "SMB VPN" without affecting the user experience.[43] SMB clients use TCP by default and will attempt QUIC if the TCP attempt fails or if intentionally requiring QUIC.

## Adoption

### Browser support

The QUIC code was experimentally developed in Google Chrome starting in 2012,[3] 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.[44]

Support in Firefox arrived in May 2021.[45][11]

Apple added experimental support in the WebKit engine through the Safari Technology Preview 104 in April 2020.[46] Official support was added in Safari 14, included in macOS Big Sur and iOS 14,[47] but the feature needed to be turned on manually.[48] It was later enabled by default in Safari 16.[12]

### Client support

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

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

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

### Server support

As of 2017[update], there are several actively maintained implementations. Google servers support QUIC and Google has published a prototype server.[55] Akamai Technologies has supported QUIC since July 2016.[56][57] A Go implementation called quic-go[58] is also available, and powers experimental QUIC support in the Caddy server.[59] On July 11, 2017, LiteSpeed Technologies officially began supporting QUIC in their load balancer (WebADC)[60] and LiteSpeed Web Server products.[61] As of October 2019[update], 88.6% of QUIC websites used LiteSpeed and 10.8% used Nginx.[62] Although at first only Google servers supported HTTP-over-QUIC connections, Facebook also launched the technology in 2018,[18] and Cloudflare has been offering QUIC support on a beta basis since 2018.[63] The HAProxy load balancer added experimental support for QUIC in March 2022[64] and declared it production-ready in March 2023.[65] As of April 2023[update], 8.9% of all websites use QUIC,[66] up from 5% in March 2021. Microsoft Windows Server 2022 supports both HTTP/3[67] and SMB over QUIC[68][9] protocols via MsQuic. The Application Delivery Controller of Citrix (Citrix ADC, NetScaler) can function as a QUIC proxy since version 13.[69][70]

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

## Source code

QUIC or gQUIC implementations available in source form  Implementation  | License  | Language  | Description

|
|
|

Chromium | BSD-3-Clause 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 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 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.
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 the H2O web server.
quic-go | MIT License | Go  | This library provides QUIC support for Go.
Quinn | Apache License 2.0 MIT License | Rust  | An async-friendly QUIC implementation in Rust
Neqo | Apache License 2.0 MIT License | Rust  | This implementation from Mozilla 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 an eBPF 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 the Quiche implementation.
nodejs-quic | MIT License | NodeJs  | This experimental package implements QUIC for Nodejs.
s2n-quic | Apache License 2.0 | Rust  | Open-source Rust implementation from Amazon Web Services
swift-quic | Apache License 2.0 | Swift  | Swift implementation pitched for incubation at the Swift 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 in 100% Java. Supports HTTP3 with "Flupke" add-on.
OpenSSL | Apache License | C  | OpenSSL has added QUIC support since version 3.2.[75]
GnuTLS | GNU Lesser General Public License version 2.1  | C  | GnuTLS has added QUIC support since version 3.7.[76]
Linux QUIC | GNU General Public License version 2  | C  | An in‑kernel QUIC implementation for Linux, offering standard POSIX socket APIs to kernel subsystems and userspace applications.

## See also

* 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

1. ↑ 1.0 1.1 Nathan Willis. "Connecting on the QUIC". Linux Weekly News. https://lwn.net/Articles/558826/.
2. ↑ 2.0 2.1 2.2 "QUIC: Design Document and Specification Rationale". Jim Roskind, Chromium Contributor. https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit.
3. ↑ 3.0 3.1 "First Chromium Code Landing: CL 11125002: Add QuicFramer and friends.". https://chromiumcodereview.appspot.com/11125002.
4. ↑ "Experimenting with QUIC". Chromium Official Blog. https://blog.chromium.org/2013/06/experimenting-with-quic.html.
5. ↑ "QUIC, Google wants to make the web faster". François Beaufort, Chromium Evangelist. https://plus.google.com/u/0/100132233764003563318/posts/b36wVornPtD.
6. ↑ "QUIC: next generation multiplexed transport over UDP". YouTube. 11 February 2014. https://www.youtube.com/watch?v=hQZ-0mXFmk8.
7. ↑ 7.0 7.1 7.2 7.3 "QUIC: IETF-88 TSV Area Presentation". Jim Roskind, Google. http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf.
8. ↑ 8.0 8.1 8.2 Lardinois, Frederic (18 April 2015). "Google Wants To Speed Up The Web With Its QUIC Protocol". https://techcrunch.com/2015/04/18/google-wants-to-speed-up-the-web-with-its-quic-protocol/.
9. ↑ 9.0 9.1 Mackie, Kurt; August 26, 2021. "Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser" (in en-US). https://redmondmag.com/articles/2021/08/26/native-quic-in-windows-edge.aspx.
10. ↑ Christopher Fernandes (April 3, 2018). "Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5". https://www.windowslatest.com/2018/04/03/microsoft-to-add-support-for-googles-quic-fast-internet-protocol-in-windows-10-redstone-5/.
11. ↑ 11.0 11.1 Dragana Damjanovic (2021-04-16). "QUIC and HTTP/3 Support now in Firefox Nightly and Beta". Mozilla. https://hacks.mozilla.org/2021/04/quic-and-http-3-support-now-in-firefox-nightly-and-beta/.
12. ↑ 12.0 12.1 Belson, David; Pardue, Lucas (June 6, 2023). "Examining HTTP/3 usage one year on". https://blog.cloudflare.com/http3-usage-one-year-on/.
13. ↑ Cite error: Invalid `<ref>` tag; no text was provided for refs named `rfc9000`
14. ↑ Langley, Adam; Riddoch, Alistair; Wilk, Alyssa; Vicente, Antonio; Krasic, Charles; Zhang, Dan; Yang, Fan; Kouranov, Fedor et al. (2017-08-07). "The QUIC Transport Protocol: Design and Internet-Scale Deployment". ACM. doi:10.1145/3098822.3098842. ISBN 978-1-4503-4653-5. ""developing and deploying networking protocols in user space brings substantial benefits, and it makes development, testing, and iteration cycles faster and easier.""
15. ↑ "Google Will Propose QUIC As IETF Standard". https://www.infoq.com/news/2015/04/google-quic-ietf-standard.
16. ↑ "I-D Action: draft-tsvwg-quic-protocol-00.txt". i-d-announce (Mailing list). 17 Jun 2015.
17. ↑ "QUIC - IETF Working Group". https://datatracker.ietf.org/wg/quic/documents/.
18. ↑ 18.0 18.1 18.2 Cimpanu, Catalin (12 November 2018). "HTTP-over-QUIC to be renamed HTTP/3". https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/.
19. ↑ "QUIC is now RFC 9000" (in en-US). 2021-05-27. https://www.fastly.com/blog/quic-is-now-rfc-9000.
20. ↑ 20.0 20.1 20.2 20.3 20.4 20.5 Bright, Peter (12 November 2018). "The next version of HTTP won't be using TCP". https://arstechnica.com/gadgets/2018/11/the-next-version-of-http-wont-be-using-tcp/.
21. ↑ 21.0 21.1 Thomson & Pauly 2021, A.5. TCP. sfn error: no target: CITEREFThomsonPauly2021 (help)
22. ↑ Fairhurst & Perkins 2021, 4. Encryption and Authentication of Transport Headers. sfn error: no target: CITEREFFairhurstPerkins2021 (help)
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". https://cloudplatform.googleblog.com/2018/06/Introducing-QUIC-support-for-HTTPS-load-balancing.html.
28. ↑ 28.0 28.1 Simon, Clayton (May 2021). QUIC: A UDP-Based Multiplexed and Secure Transport. https://datatracker.ietf.org/doc/html/rfc9000#section-9.
29. ↑ "Applicability of the QUIC Transport Protocol". Oct 22, 2018. https://quicwg.org/ops-drafts/draft-ietf-quic-applicability.html.
30. ↑ Corbet 2018.
31. ↑ Trammell & Kuehlewind 2019, p. 2. sfn error: no target: CITEREFTrammellKuehlewind2019 (help)
32. ↑ Thomson & Pauly 2021, 3.3. Falsifying Active Use. sfn error: no target: CITEREFThomsonPauly2021 (help)
33. ↑ Thomson 2021, 2. Fixed Properties of All QUIC Versions. sfn error: no target: CITEREFThomson2021 (help)
34. ↑ Andrea Gaminara. Performance and Security Evaluation of TLS, DTLS and QUIC Security Protocols (PDF) (master's thesis). Politecnico di Torino.
35. ↑ "QUIC, a multiplexed transport over UDP". https://www.chromium.org/quic/.
36. ↑ DN.org. "gQUIC vs IETF QUIC: What Changed and Why". https://dn.org/gquic-vs-ietf-quic-what-changed-and-why/.
37. ↑ "What's Happening with QUIC". https://www.ietf.org/blog/whats-happening-quic/.
38. ↑ "Chrome is deploying HTTP/3 and IETF QUIC". 7 October 2020. https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html.
39. ↑ Bishop, Mike (21 June 2021). "HTTP/3 and QUIC: Past, Present, and Future". Akamai. https://www.akamai.com/blog/performance/http3-and-quic-past-present-and-future.
40. ↑ 40.0 40.1 Duke, Martin; Sarker, Zaheduzzaman; Westerlund, Magnus (3 June 2021). "A new era in Internet transport". IETF. https://www.ietf.org/blog/new-era-transport/.
41. ↑ Bralley, Brett (25 January 2024). "What's the deal with Media Over QUIC?". IETF. https://www.ietf.org/blog/moq-overview/.
42. ↑ Burtrum, Travis (13 July 2022). "XEP-0467: XMPP over QUIC". https://xmpp.org/extensions/xep-0467.html.
43. ↑ Pyle, Ned (2023-06-27). "SMB over QUIC" (in en-us). https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic.
44. ↑ Liebetrau, Etienne (2018-06-22). "How Google's QUIC Protocol Impacts Network Security and Reporting" (in en-US). https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/.
45. ↑ Cimpanu, Catalin (Sep 26, 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/.
46. ↑ "Release Notes for Safari Technology Preview 104". 8 April 2020. https://webkit.org/blog/10264/release-notes-for-safari-technology-preview-104/.
47. ↑ "Safari 14 Release Notes". https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes.
48. ↑ "How to enable HTTP3 in Chrome / Firefox / Safari". April 8, 2020. https://www.bram.us/2020/04/08/how-to-enable-http3-in-chrome-firefox-safari/.
49. ↑ "Perform network operations using Cronet" (in en). https://developer.android.com/guide/topics/connectivity/cronet.
50. ↑ "curl – Changes". https://curl.haxx.se/changes.html#7_66_0.
51. ↑ "curl 7.66.0 – the parallel HTTP/3 future is here | daniel.haxx.se" (in en-US). 11 September 2019. https://daniel.haxx.se/blog/2019/09/11/curl-7-66-0-the-parallel-http-3-future-is-here/.
52. ↑ "How Facebook is bringing QUIC to billions" (in en-US). 2020-10-21. https://engineering.fb.com/networking-traffic/how-facebook-is-bringing-quic-to-billions/.
53. ↑ "How Google's QUIC Protocol Impacts Network Security and Reporting" (in en-US). 2020-10-21. https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/.
54. ↑ 54.0 54.1 Green, Emily (30 September 2020). "This is what you need to know about the new QUIC protocol" (in en-US). https://nordvpn.com/blog/what-is-quic-protocol/.
55. ↑ "QUIC server". 2012. https://quiche.googlesource.com/quiche/+/envoy-integration/quic/tools/quic_server.cc. Retrieved 2022-08-17.
56. ↑ Bishop, Mike (June 21, 2021). "HTTP/3 and QUIC: Past, Present, and Future". https://www.akamai.com/blog/performance/http3-and-quic-past-present-and-future.
57. ↑ Rüth, Jan; Poese, Ingmar; Dietzel, Christoph; Hohlfeld, Oliver (2018). "A First Look at QUIC in the Wild". Passive and Active Measurement. Lecture Notes in Computer Science. 10771. pp. 255–268. doi:10.1007/978-3-319-76481-8_19. ISBN 978-3-319-76480-1.
58. ↑ "lucas-clemente/quic-go". Aug 7, 2020. https://github.com/lucas-clemente/quic-go.
59. ↑ QUIC support in Caddy, Retrieved 13 July 2016.
60. ↑ "LiteSpeed Web ADC – Load Balancer – LiteSpeed Technologies". https://www.litespeedtech.com/products/litespeed-web-adc.
61. ↑ LiteSpeed Technologies QUIC Blog Post, Retrieved July 11, 2017.
62. ↑ "Distribution of Web Servers among websites that use QUIC". https://w3techs.com/technologies/segmentation/ce-quic/web_server.
63. ↑ "Get a head start with QUIC". The Cloudflare Blog. 2018-09-25. https://blog.cloudflare.com/head-start-with-quic/.
64. ↑ "Announcing HAProxy 2.6" (in en). 31 May 2022. https://www.haproxy.com/blog/announcing-haproxy-2-6.
65. ↑ "[ANNOUNCE haproxy-2.8.0"]. https://www.mail-archive.com/haproxy@formilux.org/msg43600.html.
66. ↑ "Usage Statistics of QUIC for Websites, April 2023". https://w3techs.com/technologies/details/ce-quic.
67. ↑ "Enabling HTTP/3 support on Windows Server 2022". 24 August 2021. https://techcommunity.microsoft.com/t5/networking-blog/enabling-http-3-support-on-windows-server-2022/ba-p/2676880.
68. ↑ "SMB over QUIC". 27 June 2023. https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic.
69. ↑ "Policy configuration for HTTP/3 traffic | Citrix ADC 13.0". https://docs.citrix.com/en-us/citrix-adc/13/system/http3-over-quic-protocol/http3-policy-configuration.html.
70. ↑ "Need for speed? – Just an other Citrix ADC Blog". https://norz.at/?p=2022.
71. ↑ "devsisters/libquic". Aug 5, 2020. https://github.com/devsisters/libquic.
72. ↑ "devsisters/goquic". Aug 5, 2020. https://github.com/devsisters/goquic.
73. ↑ "Docker Hub". https://hub.docker.com/r/devsisters/quic-reverse-proxy/.
74. ↑ ".NET 5 Networking Improvements" (in en-US). 2021-01-11. https://devblogs.microsoft.com/dotnet/net-5-new-networking-improvements/.
75. ↑ "Openssl-quic - OpenSSL Documentation". https://docs.openssl.org/master/man7/openssl-quic/.
76. ↑ "What's new in GnuTLS 3.7.0 – Daiki Ueno". 3 December 2020. https://blogs.gnome.org/dueno/whats-new-in-gnutls-3-7-0/.

## Bibliography

* Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP". Usenix NSDI: 399–412. https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp.
* Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). "Are TCP extensions middlebox-proof?". HotMiddlebox '13. doi:10.1145/2535828.2535830.
* Corbet, Jonathan (29 January 2018). "QUIC as a solution to protocol ossification". LWN.net. https://lwn.net/Articles/745590/.
* Edeline, Korian; Donnet, Benoit (2019). "A Bottom-Up Investigation of the Transport-Layer Ossification". 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:10.23919/TMA.2019.8784690.
* Rybczyńska, Marta (13 March 2020). "A QUIC look at HTTP/3". LWN.net. https://lwn.net/Articles/814522/.

## External links

* No URL found. Please specify a URL here or add one to Wikidata.
* on GitHub
* 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)
* EPIQ 2018 Keynote – Facebook's IETF QUIC deployment, Subodh Iyengar on YouTube
* EPIQ 2021 Keynote – QUIC at Microsoft, Nick Bankson on YouTube
* QUIC at Google (2020) – David Schinazi on YouTube
* QUIC at Apple (2021) – Tommy Pauly on YouTube
* qvis: QUIC and HTTP/3 visualization suite.
* The Illustrated QUIC Connection
* Template:Sum RFC
* Template:Sum RFC
* Template:Sum RFC
* Template:Sum RFC
* Template:Sum RFC
* Template:Sum RFC

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/QUIC. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=QUIC&oldid=4227736"