#readwise # QUIC - Wikipedia  ## Metadata - Author: [[wikipedia.org]] - Full Title: QUIC - Wikipedia - URL: https://en.wikipedia.org/wiki/QUIC ## Summary QUIC is a transport layer network protocol developed by Google to improve web application performance, especially with HTTP/3. It reduces connection setup latency and enhances data loss recovery compared to older protocols like TCP. QUIC was standardized by the IETF in 2021 and is now used by many websites and applications. More than 8% of all websites use QUIC as of April 2023, showing its growing adoption. ## Highlights QUIC ([/kwɪk/](https://en.wikipedia.org/wiki/Help:IPA/English)) is a general-purpose [[Transport layer - Wikipedia|transport layer]] [network protocol](https://en.wikipedia.org/wiki/Network_protocol) initially designed by [Jim Roskind](https://en.wikipedia.org/wiki/Jim_Roskind) at [Google](https://en.wikipedia.org/wiki/Google). It was first implemented and deployed in 2012 and was publicly announced in 2013 as experimentation broadened. ([View Highlight](https://read.readwise.io/read/01jhq0q1q99gpsrn8mpm1y3jb7)) --- In Chrome, QUIC is used by more than half of all connections to Google's servers. ([View Highlight](https://read.readwise.io/read/01jhq0q7cffz8nq6mvnvvcmspq)) --- QUIC improves performance of connection-oriented [web applications](https://en.wikipedia.org/wiki/Web_application) that before QUIC used [Transmission Control Protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) (TCP). It does this by establishing a number of [multiplexed](https://en.wikipedia.org/wiki/Multiplexed) connections between two endpoints using [User Datagram Protocol](https://en.wikipedia.org/wiki/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"**. ([View Highlight](https://read.readwise.io/read/01jhq0qvxx9qhwess0pgmsxfr8)) ^m7itwi --- In the context of supporting [encrypted](https://en.wikipedia.org/wiki/HTTPS) [HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) traffic, **QUIC serves a similar role as TCP, but with reduced [latency](https://en.wikipedia.org/wiki/Network_delay) 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. --- **The first change is to greatly reduce overhead during connection setup. As most HTTP connections will demand [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security), QUIC makes the exchange of setup keys and listing of supported protocols part of the initial [handshake process](https://en.wikipedia.org/wiki/Handshake_(computing)).** 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. ([View Highlight](https://read.readwise.io/read/01jhq0wwttmxh0zvjfcxkm8c9p)) --- **The second change is to use [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol) rather than TCP** as its basis, which does not include [loss](https://en.wikipedia.org/wiki/Packet_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](https://en.wikipedia.org/wiki/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. ([View Highlight](https://read.readwise.io/read/01jhq0wwttmxh0zvjfcxkm8c9p)) ---