Jump to content

QUIC

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Rodw (talk | contribs) at 22:02, 14 November 2018 (Disambiguated: TLS → Transport Layer Security, latency → Network latency). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

QUIC, or Quick UDP Internet Connections, is an experimental transport layer[1] network protocol designed by Google,[2] initially implemented in 2012,[3] and announced publicly in 2013 as experimentation broadened.[4][5][6]

QUIC's main goal is to improve perceived performance of connection-oriented web applications that are currently using TCP.[1][7] It does this by establishing a number of multiplexed connections between two endpoints over User Datagram Protocol (UDP). This works hand-in-hand with HTTP/2's multiplexed connections, allowing multiple streams of data to reach the endpoints independently. In contrast, HTTP hosted on TCP/IP can be blocked if any of the multiplexed data streams has an error.

QUIC's secondary goals include reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. It also moves control of the congestion avoidance algorithms into the application space at both endpoints, rather than the kernel space, which it is claimed will 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, and this is seen as the next step in the protocol's evolution.

In June 2015, an Internet Draft of a specification for QUIC was submitted to the IETF for standardization.[8][9] A QUIC working group was established in 2016.[10] In October 2018, the IETF'S HTTP and QUIC Working Group made an official request to rename the protocol HTTP/3 in advance of making it a worldwide standard.[11]

Details

TCP

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 is error checked and reliable, meaning that data the application provides will make it through the connection both complete and error-free, or the connection will indicate that an error condition exists.[12]

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

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

As the TCP system is designed to look like a "data pipe", or stream, it contains very 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.[12]

QUIC

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

The first change is to greatly reduce overhead during connection setup. As most HTTP connections will demand TLS and compression, 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 the encryption or any desired compression. This eliminates the need to set up the TCP connection and then negotiate the transmission protocols 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.[12]

QUIC uses UDP as its basis, which does not include error correction. Instead, each QUIC request is separately multiplexed and error corrected at the level of the QUIC driver, not the underlying transmission protocol. In addition to providing error correction, like TCP, QUIC's data also includes packet routing information that allows it to be multiplexed at the protocol layer. 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.[13]

QUIC includes a number of other more mundane changes that also improve overall latency and throughput. For instance, the packet sizes are selected to lie on the boundaries of the underlying encryption protocol, so that they do not result in the encrypted data waiting for partial packets. The same is true for the compression packet sizes. This is not generally possible under TCP, where the packet size is a "one size fits all" situation as the protocol stack does not know what additional protocols are running within it. These can be negotiated by the layers running on top, but QUIC aims to do all of this in a single handshake process.[14]

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 its own 64-bit stream identifiers which contain both the multiplexing data and a unique network-wide ID. 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.[15]

QUIC is 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 is 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/3 stack's size or overall complexity.[14]

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 reason for the use of FEC is that QUIC currently uses HTTP/2 header compression, which includes head-of-line blocking for header frames. By adopting FEC, such errors can be eliminated before they reach the HTTP level, and this source of blocking removed without changing the underlying HTTP/2 protocol.[15]

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

Adoption

Client (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) of Chrome. It is currently enabled by default in Chromium, and active sessions can be seen at chrome://net-internals/#quic. 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.

Server support

As of 2017 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.[17] On July 11, 2017, LiteSpeed Technologies officially began supporting QUIC in their load balancer (WebADC) and LiteSpeed Web Server products.[18] As of December 2017, 97.5% of websites using QUIC are running LiteSpeed Web Server.[19]

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 are available in source form:[citation needed]

See also

References

  1. ^ a b Nathan Willis. "Connecting on the QUIC". Linux Weekly News. Retrieved 2013-07-16.
  2. ^ a b "QUIC: Design Document and Specification Rationale". Jim Roskind, Chromium Contributor.
  3. ^ a b "First Chromium Code Landing: CL 11125002: Add QuicFramer and friends". Retrieved 2012-10-16.
  4. ^ "Experimenting with QUIC". Chromium Official Blog. Retrieved 2013-07-16.
  5. ^ "QUIC, Google wants to make the web faster". François Beaufort, Chromium Evangelist.
  6. ^ "QUIC: next generation multiplexed transport over UDP". YouTube. Retrieved 2014-04-04.
  7. ^ Lardinois, Frederic. "Google Wants To Speed Up The Web With Its QUIC Protocol". TechCrunch. Retrieved 2016-10-25.
  8. ^ "Google Will Propose QUIC As IETF Standard". InfoQ. Retrieved 2016-10-25.
  9. ^ "I-D Action: draft-tsvwg-quic-protocol-00.txt". i-d-announce (Mailing list). 17 Jun 2015.
  10. ^ "QUIC - IETF Working Group". datatracker.ietf.org. Retrieved 2016-10-25.
  11. ^ Cimpanu, Catalin (12 November 2018). "HTTP-over-QUIC to be renamed HTTP/3". ZDNet.
  12. ^ a b c d e f Bright, Peter (12 November 2018). "The next version of HTTP won't be using TCP". Arstechnica.
  13. ^ Behr, Michael; Swett, Ian. "Introducing QUIC support for HTTPS load balancing". Google Cloud Platform Blog. Google. Retrieved 16 June 2018.
  14. ^ a b "QUIC: IETF-88 TSV Area Presentation" (PDF). Jim Roskind, Google. Retrieved 2013-11-07.
  15. ^ a b "QUIC at 10,000 feet". Chromium.
  16. ^ "Applicability of the QUIC Transport Protocol". IETF Network Working Group. 22 October 2018.
  17. ^ QUIC support in Caddy, Retrieved 13 July 2016.
  18. ^ LiteSpeed Technologies QUIC Blog Post, Retrieved July 11, 2017.
  19. ^ "Distribution of web servers among websites that use QUIC". {{cite web}}: Cite has empty unknown parameter: |dead-url= (help)
Retrieved from "https://en.wikipedia.org/w/index.php?title=QUIC&oldid=868856379"