QUIC

QUIC (pronounced quick) is an experimental transport layer[1] network protocol designed by Jim Roskind at Google,[2] initially implemented in 2012,[3] and announced publicly in 2013 as experimentation broadened.[4][5][6] QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. QUIC's main goal is to improve perceived performance of connection-oriented web applications that are currently using TCP.[1][7] 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.

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] The QUIC working group foresees multipath support and optional forward error correction (FEC) as the next step. The working group also focuses on network management issues that QUIC may introduce, aiming to produce an applicability and manageability statement in parallel to the actual protocol work.[11] Internet statistics in 2018 suggest that QUIC is supported by approximately 0.8 percent of web servers.[12]

Details

QUIC, Quick UDP Internet Connections, aims to be nearly equivalent to an independent TCP connection, but with much reduced latency (goal: 0-RTT connectivity overhead) and better SPDY-like stream-multiplexing support. If QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle).

One of the motivations for developing QUIC was that in TCP the delay of a single packet induces head-of-line blocking for an entire set of SPDY streams; QUIC's improved multiplexing support means that only streams carried in that single packet would pause.[13]

A good way to decrease connection latency for an efficiently routed connection is to make fewer round-trips. Much of the work on QUIC is concentrated on reducing the number of round-trips required when establishing a new connection, including the handshake step, encryption setup, and initial data requests. QUIC clients would, for example, include the session negotiation information in the initial packet. This compression is enhanced by QUIC servers, which publish a static configuration record that is concisely referred to. The client also stores a synchronization cookie it received from the server, enabling subsequent connections to incur zero overhead latency (in the best case).[1]

The protocol handles packet loss well; QUIC aligns cryptographic block boundaries with packet boundaries, so the impact of packet loss is even lower. While TCP uses congestion windows to avoid congestion (see: TCP congestion avoidance algorithm), which are unforgiving to multiplexed connections, QUIC has a set of modern techniques under review.[14] Among the techniques being tested are packet pacing (with ongoing bandwidth estimation) and proactive speculative retransmission (sending duplicate copies of the most important packets, such as the ones containing error correction or initial encryption negotiation).

QUIC, with its higher level application protocol elements which multiplexes streams (similarly to SPDY), can reduce or compress redundant data transmissions (such as headers). As with SPDY, QUIC benefits greatly from this compression, and is generally able to make numerous HTTP(S) requests within a single initial congestion window.

Concerns about UDP connectivity (re: fears that too many users were behind middle-boxes which blocked UDP traffic) were mitigated by Chromium connectivity experiments[14] performed before QUIC design[2] and implementation efforts began. For the small percentages of users that have UDP blocked, QUIC automatically falls back to TCP based connectivity. Additionally, when there is a perceived risk of UDP being blocked, high performance implementations, such as Chromium's network stack, race a TCP based connection with a QUIC (UDP) connection, ensuring no latency loss at the application level.

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

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:

See also

References

  1. 1 2 3 Nathan Willis. "Connecting on the QUIC". Linux Weekly News. Retrieved 2013-07-16.
  2. 1 2 "QUIC: Design Document and Specification Rationale". Jim Roskind, Chromium Contributor.
  3. 1 2 "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. ↑ Cui, Yong (2017). "Innovating Transport with QUIC: Design Approaches and Research Challenges". IEEE Internet Computing. 21 (2): 72–76.
  12. ↑ Web Technology Surveys, "Usage of Site Elements for Websites", Retrieved 15-MAY-2018
  13. ↑ Behr, Michael; Swett, Ian. "Introducing QUIC support for HTTPS load balancing". Google Cloud Platform Blog. Google. Retrieved 16 June 2018.
  14. 1 2 "QUIC: IETF-88 TSV Area Presentation" (PDF). Jim Roskind, Google. Retrieved 2013-11-07.
  15. ↑ QUIC support in Caddy, Retrieved 13 July 2016.
  16. ↑ LiteSpeed Technologies QUIC Blog Post, Retrieved July 11, 2017.
  17. ↑ "Distribution of web servers among websites that use QUIC".
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.