Transport layer computer network protocol / From Wikipedia, the free encyclopedia

Dear Wikiwand AI, let's keep it short by simply answering these key questions:

Can you list the top facts and stats about QUIC?

Summarize this article for a 10 year old


QUIC (/kwɪk/) is a general-purpose[1] transport layer[2] network protocol initially designed by Jim Roskind at Google,[3] implemented, and deployed in 2012,[4] announced publicly in 2013 as experimentation broadened,[5][6][7] and described at an IETF meeting.[8] QUIC is used by more than half of all connections from the Chrome web browser to Google's servers.[9] Microsoft Edge (a derivative of the open-source Chromium browser),[10][11] Firefox[12] and Safari support it.[13]

Quick facts: Purpose, Developer(s), Introduction, Based on...
Communication protocol
PurposeGeneral Purpose
Developer(s)IETF, Google
IntroductionOctober 12, 2012; 11 years ago (2012-10-12)
Based onIP, normally layered with UDP
OSI layerTransport layer
RFC(s)RFC 9000, RFC 8999, RFC 9001, RFC 9002

Although its name was initially proposed as the acronym for "Quick UDP Internet Connections",[3][8] IETF's use of the word QUIC is not an acronym; it is simply the name of the protocol.[1] QUIC improves performance of connection-oriented web applications that are currently using TCP.[2][9] It does this by establishing a number of 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 is 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 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. It has been designed to avoid protocol ossification so that it remains evolvable, unlike TCP, which has suffered significant 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, RFC 9001 and RFC 9002.[19] DNS-over-QUIC is another application.

Oops something went wrong: