QUIC简介

2023-05-03 08:35| 来源: 网络整理| 查看: 265

What is QUIC?

QUIC（Quick UDP Internet Connections）是一种新的互联网传输协议，由谷歌开发。 QUIC 解决了现代 Web 应用程序遇到的许多传输层和应用程序层问题，同时几乎不需要应用程序编写者进行更改。 QUIC 与 TCP+TLS+HTTP2 非常相似，但在 UDP 之上实现。将 QUIC 作为一个独立的协议可以实现现有协议无法实现的创新，因为它们会受到遗留客户端和中间件的阻碍。

QUIC (Quick UDP Internet Connections) is a new transport protocol for the internet, developed by Google. QUIC solves a number of transport-layer and application-layer problems experienced by modern web applications, while requiring little or no change from application writers. QUIC is very similar to TCP+TLS+HTTP2, but implemented on top of UDP. Having QUIC as a self-contained protocol allows innovations which aren’t possible with existing protocols as they are hampered by legacy clients and middleboxes.

QUIC 相对于 TCP+TLS+HTTP2 的主要优势包括：

连接建立延迟改进的拥塞控制无队头阻塞的多路复用前向纠错连接迁移Key advantages of QUIC over TCP+TLS+HTTP2 include:Connection establishment latencyImproved congestion controlMultiplexing without head-of-line blockingForward error correctionConnection migrationConnection Establishment

有关连接建立的完整说明，请参阅 QUIC Crypto 设计文档。简而言之，与 TCP+TLS 的 1-3 次往返相比，QUIC 握手在发送有效负载之前经常需要零次往返。

QUIC 客户端第一次连接到服务器时，客户端必须执行一次往返握手，以获取完成握手所需的信息。客户端发送一个早期的（空的）客户端问候（CHLO），服务器发送一个拒绝（REJ），其中包含客户端向前推进所需的信息，包括源地址令牌和服务器的证书。下次客户端发送 CHLO 时，它可以使用先前连接的缓存凭据立即向服务器发送加密请求。

For a complete description of connection establishment, please see the QUIC Crypto design document. Briefly, QUIC handshakes frequently require zero roundtrips before sending payload, as compared to 1-3 roundtrips for TCP+TLS.The first time a QUIC client connects to a server, the client must perform a 1-roundtrip handshake in order to acquire the necessary information to complete the handshake. The client sends an inchoate (empty) client hello (CHLO), the server sends a rejection (REJ) with the information the client needs to make forward progress, including the source address token and the server’s certificates. The next time the client sends a CHLO, it can use the cached credentials from the previous connection to immediately send encrypted requests to the server.Congestion Control

QUIC 具有可插拔的拥塞控制，并为拥塞控制算法提供比 TCP 更丰富的信息。目前，谷歌的 QUIC 实现使用了 TCP Cubic 的重新实现，并正在试验替代方法。

更丰富信息的一个示例是每个数据包，无论是原始数据包还是重新传输的数据包，都带有一个新的序列号。这允许 QUIC 发送方区分重传的 ACK 和原始的 ACK，并避免 TCP 的重传歧义问题。 QUIC ACK 还明确携带了接收数据包和发送确认之间的延迟，以及单调递增的序列号。这允许精确的往返时间计算。

最后，QUIC 的 ACK 帧支持多达 256 个 NACK 范围，因此 QUIC 比 TCP（使用 SACK）对重新排序更有弹性，并且能够在重新排序或丢失时在网络上保留更多字节。客户端和服务器都可以更准确地了解对方收到了哪些数据包。

QUIC has pluggable congestion control, and provides richer information to the congestion control algorithm than TCP. Currently, Google’s implementation of QUIC uses a reimplementation of TCP Cubic and is experimenting with alternative approaches.One example of richer information is that each packet, both original and retransmitted, carries a new sequence number. This allows a QUIC sender to distinguish ACKs for retransmissions from ACKs for originals and avoids TCP’s retransmission ambiguity problem. QUIC ACKs also explicitly carry the delay between the receipt of a packet and its acknowledgment being sent, and together with the monotonically-increasing sequence numbers. This allows for precise roundtrip-time calculation.Finally, QUIC’s ACK frames support up to 256 NACK ranges, so QUIC is more resilient to reordering than TCP (with SACK), as well as able to keep more bytes on the wire when there is reordering or loss. Both client and server have a more accurate picture of which packets the peer has received.Multiplexing

TCP 之上的 HTTP2 的一个较大问题是队头阻塞问题。应用程序将 TCP 连接视为字节流。当 TCP 数据包丢失时，在该数据包被远端重新传输和接收之前，该 HTTP2 连接上的任何流都无法向前推进——即使包含这些流数据的数据包已经到达并在缓冲区中等待。

因为 QUIC 是为多路复用操作而设计的，丢失的数据包携带单个流的数据通常只会影响该特定流。每个流帧都可以在到达时立即分派到该流，因此可以继续重组无丢失的流并在应用程序中取得进展。

One of the larger issues with HTTP2 on top of TCP is the issue of head-of-line blocking. The application sees a TCP connection as a stream of bytes. When a TCP packet is lost, no streams on that HTTP2 connection can make forward progress until the packet is retransmitted and received by the far side - not even when the packets with data for these streams have arrived and are waiting in a buffer.Because QUIC is designed from the ground up for multiplexed operation, lost packets carrying data for an individual stream generally only impact that specific stream. Each stream frame can be immediately dispatched to that stream on arrival, so streams without loss can continue to be reassembled and make forward progress in the application. Forward Error Correction

为了在不等待重传的情况下从丢失的数据包中恢复，QUIC 可以用 FEC 数据包补充一组数据包。与 RAID-4 非常相似，FEC 数据包包含 FEC 组中数据包的奇偶校验。如果组中的一个数据包丢失，则可以从 FEC 数据包和组中的其余数据包中恢复该数据包的内容。发送方可以决定是否发送 FEC 数据包以优化特定场景（例如，请求的开始和结束）。

In order to recover from lost packets without waiting for a retransmission, QUIC can complement a group of packets with an FEC packet. Much like RAID-4, the FEC packet contains parity of the packets in the FEC group. If one of the packets in the group is lost, the contents of that packet can be recovered from the FEC packet and the remaining packets in the group. The sender may decide whether to send FEC packets to optimize specific scenarios (e.g., beginning and end of a request).Connection Migration

QUIC 连接由客户端随机生成的 64 位连接 ID 标识。相反，TCP 连接由源地址、源端口、目标地址和目标端口的 4 元组标识。这意味着如果客户端更改 IP 地址（例如，通过移出 Wi-Fi 范围并切换到蜂窝网络）或端口（如果 NAT 盒丢失并重新绑定端口关联），任何活动的 TCP 连接将不再有效 . 当 QUIC 客户端更改 IP 地址时，它可以继续使用来自新 IP 地址的旧连接 ID，而不会中断任何正在进行的请求。

QUIC connections are identified by a 64 bit connection ID, randomly generated by the client. In contrast, TCP connections are identified by a 4-tuple of source address, source port, destination address and destination port. This means that if a client changes IP addresses (for example, by moving out of Wi-Fi range and switching over to cellular) or ports (if a NAT box loses and rebinds the port association), any active TCP connections are no longer valid. When a QUIC client changes IP addresses, it can continue to use the old connection ID from the new IP address without interrupting any in-flight requests.

Source: https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit

【本文地址】

公司简介

联系我们