|This article relies on references to primary sources. (October 2013)|
QUIC (Quick UDP Internet Connections, pronounced quick) is an experimental, transport layer network protocol developed by Google and implemented in 2013. 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 optimize connection-oriented web applications currently using TCP.
As improving TCP is a long-term goal for Google, QUIC aims to be nearly equivalent to an independent TCP connection, but with much reduced latency (goal: 0-RTT connectivity overhead) and better SPDY support; if QUIC features prove effective, they could migrate into a later version of TCP and TLS.
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 one stream would pause.
Round-trip times, roughly defined by the speed of light are essentially fixed; the way to decrease connection latency is to make fewer round-trips. Much of the work on QUIC is concentrated on reducing the 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, QUIC servers, on the other hand, publish a static configuration file to host some of this information. The client would store a synchronization cookie it got from the server, making subsequent connections to the same server with zero latency (in the best case).
The protocol handles packet loss well; besides packet-level forward error correction, 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. 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).
The QUIC code was merged into Google Chrome  and has been part of version 29 (released on August 20, 2013) of Chrome. It can be turned on at chrome://flags/#enable-quic and chrome://flags/#enable-quic-https, and active sessions can be seen at chrome://net-internals/#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.
Google servers support QUIC. Google has also published a prototype server.
The code is released under a BSD-style license that can be found in the LICENSE file.
- HTTP 2.0
- Reliable User Datagram Protocol (RUDP)
- Stream Control Transmission Protocol (SCTP)
- Real Time Media Flow Protocol (RTMFP)
- UDP-based Data Transfer Protocol (UDT) – a UDP-based transport protocol
- Nathan Willis. "Connecting on the QUIC". Linux Weekly News. Retrieved 2013-07-16.
- "QUIC, Google wants to make the web faster". François Beaufort, Chromium Evangelist.
- "Experimenting with QUIC". Chromium Official Blog. Retrieved 2013-07-16.
- "Chromium Code Reviews: Issue 12317026: Various small QUIC cleanups after merging to Chrome.". Retrieved 2013-02-22.
- Browsable source code