目录
- Introduction | 简介
- Conventions and Definitions | 约定和定义
- A QUIC Overview | 概述
- Connection Establishment Latency | 连接建立延时
- Flexible Congestion Control | 弹性拥塞控制
- Stream and Connection Flow Control | 流和链接两个层面的流量控制
- Multiplexing | 多路复用
- Authenticated and Encrypted Header and Payload | 认证和加密头部和负载
- Connection Migration | 连接迁移
Introduction | 简介
QUIC (Quick UDP Internet Connection) is a new multiplexed and secure transport atop UDP, designed from the ground up and optimized for HTTP/2 semantics. While built with HTTP/2 as the primary application protocol, QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport. QUIC provides multiplexing and flow control equivalent to HTTP/2, security equivalent to TLS, and connection semantics, reliability, and congestion control equivalent to TCP.
QUIC是一种新的基于UDP的多路复用、安全的传输协议，设计的基础来源于HTTP/2以及对它的优化。在构建以HTTP/2为首要应用层协议的同时，QUIC构建在许多传输和安全性的经验之上，并且实现了一个现代的、有吸引力的、通用的传输机制。QUIC提供等价于HTTP/2的多路复用和流量控制，等价于TLS的安全性，还有等价于TCP的面向连接语义，可靠性，拥塞控制。
QUIC operates entirely in userspace, and is currently shipped to users as a part of the Chromium browser, enabling rapid deployment and experimentation. As a userspace transport atop UDP, QUIC allows innovations which have proven difficult to deploy with existing protocols as they are hampered by legacy clients and middleboxes, or by prolonged Operating System development and deployment cycles.
QUIC完全工作于用户态，并且目前作为chrome浏览器的一部分提供给用户使用，可以快速部署和体验。已存协议的改进由于发布受到传统客户端和中间件，或操作系统较长的开发和发布周期的限制，已经被证明是非常困难的，但是QUIC作为构建于UDP之上的用户态传输协议却可以做到。
An important goal for QUIC is to inform better transport design through rapid experimentation. As a result, we hope to inform and where possible migrate distilled changes into TCP and TLS, which tend to have much longer iteration cycles.
GUIC的一个重要目标是通过高速迭代设计出更好的传输协议。因此，我们希望以后把这些提取出来的优良的修改迁移到迭代周期要长得多的TCP和TLS中。
This document describes the conceptual design and the wire specification of the QUIC protocol prior to standardization. Accompanying documents describe the combined crypto and transport handshake [QUIC-CRYPTO], and loss recovery and congestion control [draft-iyengar-quic-loss-recovery]. Additional resources, including a more detailed rationale document, are available on the Chromium QUIC webpage.
这个文档描述QUIC协议在标准之前的概念上的设计以及传输规格。相关联的文档描述了加密和协议握手[QUIC-CRYPTO]，以及丢包恢复和拥塞控制[draft-iyengar-quic-loss-recovery]。包含更详细理论基础的文档和其他资源，在Chromium QUIC官方网站上 https://www.chromium.org/quic 。
Proposals for standardization of QUIC based on this early deployment are [draft-hamilton-quic-transport-protocol], [draft-shade-quic-http2-mapping], [draft-iyengar-quic-loss-recovery], and [draft-thomson-quic-tls].
QUIC标准的提案基于这些早期文档 [draft-hamilton-quic-transport-protocol], [draft-shade-quic-http2-mapping], [draft-iyengar-quic-loss-recovery], and [draft-thomson-quic-tls].
Conventions and Definitions | 约定和定义
All integer values used in QUIC, including length, version, and type, are in little-endian byte order, and not in network byte order. QUIC does not enforce alignment of types in dynamically sized frames.
所有QUIC中使用的整型数据，包括长度，版本，类型，都是小端字节序，并不是网络字节序。QUIC在动态大小的帧中并不强制类型对齐。
A few terms that are used throughout this document are defined below.
- “Client”: The endpoint initiating a QUIC connection.
- “Server”: The endpoint accepting incoming QUIC connections.
- “Endpoint”: The client or server end of a connection.
- “Stream”: A bi-directional flow of bytes across a logical channel within a QUIC connection.
- “Connection”: A conversation between two QUIC endpoints with a single encryption context that multiplexes streams within it.
- “Connection ID”: The identifier for a QUIC connection.
- “QUIC Packet”: A well-formed UDP payload that can be parsed by a QUIC receiver. QUIC packet size in this document refers to the UDP payload size.
这个文档中使用的一些术语定义如下。
- “Client”: 发起QUIC连接的端
- “Server”: 接受QUIC连接的端
- “Endpoint”: 客户端或服务端
- “Stream”: 在QUIC连接内的一条用于传输双向流数据的逻辑通道
- “Connection”: 两个QUIC端使用同一个上下文的可包含多个stream的会话
- “Connection ID”: 一条QUIC连接的标识
- “QUIC Packet”: 一个定义好格式的可被QUIC接收端解析的UDP包。在这个文档中QUIC包的大小取决于UDP负载的大小
A QUIC Overview | 概述
We now briefly describe QUIC’s key mechanisms and benefits. QUIC is functionally equivalent to TCP+TLS+HTTP/2, but implemented on top of UDP. Key advantages of QUIC over TCP+TLS+HTTP/2 include:
- Connection establishment latency
- Flexible congestion control
- Multiplexing without head-of-line blocking
- Authenticated and encrypted header and payload
- Stream and connection flow control
- Connection migration
我们现在简单介绍QUIC的核心机制和优势。QUIC在功能上等价于TCP+TLS+HTTP/2，但是实现是基于UDP的。QUIC相较于TCP+TLS+HTTP/2的核心优势有：
- 连接建立的时延
- 弹性的拥塞控制
- 没有队列头部阻塞问题的多路复用
- 认证和加密的头和负载
- 流和连接两个层面的流量控制
- 连接迁移
Connection Establishment Latency | 连接建立延时
QUIC combines the crypto and transport handshakes, reducing the number of roundtrips required for setting up a secure connection. QUIC connections are commonly 0-RTT, meaning that on most QUIC connections, data can be sent immediately without waiting for a reply from the server, as compared to the 1-3 roundtrips required for TCP+TLS before application data can be sent.
QUIC结合了加密和传输握手，降低了建立可靠连接的往返时间。QUIC连接大部分是0-RTT，意味着对于大部分QUIC的连接，数据可以不用等待server的回复而直接发送，相比较之下，TCP+TLS在发送应用层数据前需要1到3次往返时间。
QUIC provides a dedicated stream (Stream ID 1) to be used for performing the handshake, but the details of this handshake protocol are out of this document’s scope. For a complete description of the current handshake protocol, please see the QUIC Crypto Handshake document. QUIC current handshake will be replaced by TLS 1.3 in the future.
QUIC提供一个专门的流（Stream ID 1）用来处理握手，但是握手协议的细节超出了本文档的范围。完整的关于当前握手协议的描述，请查阅这个文档 https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit 。QUIC当前的握手协议会在未来替换成TLS 1.3。
Flexible Congestion Control | 弹性拥塞控制
QUIC has pluggable congestion control and richer signaling than TCP, which enables QUIC to provide richer information to congestion control algorithms than TCP. Currently, the default congestion control is a reimplementation of TCP Cubic; we are currently experimenting with alternative approaches.
相较于TCP，QUIC有可插拔的拥塞控制以及更丰富的信号，使得QUIC有能力提供更多的信息供拥塞控制算法使用。当前默认的拥塞控制是对TCP Cubic的重新实现；我们正在测试其它可替代的算法。
One example of richer information is that each packet, both original and retransmitted, carries a new packet sequence number. This allows a QUIC sender to distinguish ACKs for retransmissions from ACKs for original transmissions, thus avoiding 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 packet numbers, this allows for precise roundtrip-time (RTT) calculation.
一个关于QUIC提供更丰富信息的例子，对于每个包，不管是原始包还是重传包，都携带了一个新的包序号。这使得QUIC的发送端可以区分ACK包是用来请求重传包的还是请求原始包，避免了TCP重传的歧义。QUIC的ACK包还显式携带了包接收和ACK包发送的时间间隔，加上线性增长的包序号，可以精确计算出RTT往返时间。
Finally, QUIC’s ACK frames support up to 256 ack blocks, 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.
最后，QUIC的ACK帧支持最多256个ack块，所以QUIC的重排序比使用SACK的TCP更有弹性，同时在乱序和丢包时可以在链路上保持传输更多的数据。客户端和服务端对于哪些包已经被对端收到也有更精准的认知。
Stream and Connection Flow Control | 流和链接两个层面的流量控制
QUIC implements stream- and connection-level flow control, closely following HTTP/2’s flow control. QUIC’s stream-level flow control works as follows. A QUIC receiver advertises the absolute byte offset within each stream upto which the receiver is willing to receive data. As data is sent, received, and delivered on a particular stream, the receiver sends WINDOW_UPDATE frames that increase the advertised offset limit for that stream, allowing the peer to send more data on that stream.
QUIC实现了流和链接两个层面的流量控制，近似遵循HTTP/2的流量控制。QUIC的流层面的流量控制工作如下。QUIC接收端通告每个流的绝对字节偏移直到接收端愿意接收数据。伴随着数据在特定的流上被发送，接收，传输，接收端发送WINDOW_UPDATE帧来增加这个流的通告的偏移限制，使得对端可以在这个流上发送更多的数据。
In addition to per-stream flow control, QUIC implements connection-level flow control to limit the aggregate buffer that a QUIC receiver is willing to allocate to a connection. Connection flow control works in the same way as stream flow control, but the bytes delivered and highest received offset are all aggregates across all streams.
作为对每个流的流量控制的补充，QUIC实现了连接层面的流量控制来限制一个QUIC接收端为一个连接所分配的总buffer大小。连接层面的流量控制的工作方式和流层面的流量控制相同，但是传输的字节数和更高层面的接收偏移是所有流的总和。
Similar to TCP’s receive-window autotuning, QUIC implements autotuning of flow control credits for both stream and connection flow controllers. QUIC’s autotuning increases the size of the credits sent per WINDOW_UPDATE frame if it appears to be limiting the sender’s rate, and throttles the sender when the receiving application is slow.
类似于TCP的自适应接收窗口，QUIC实现了同时基于流和连接的自适应的流量控制。如果发现限制了发送端的速度，QUIC会通过发送WINDOW_UPDATE帧来增长窗口大小，如果接收程序很慢那么会限制发送端。
Multiplexing | 多路复用
HTTP/2 on TCP suffers from head-of-line blocking in TCP. Since HTTP/2 multiplexes many streams atop TCP’s single-bytestream abstraction, a loss of a TCP segment results in blocking of all subsequent segments until a retransmission arrives, irrespective of the HTTP/2 stream that is encapsulated in subsequent segments.
基于TCP的HTTP/2会有队列头部阻塞的问题。因为HTTP/2的多路复用的多条流是基于TCP单个字节形式的流的抽象，丢失一个TCP分片会导致所有后续的分片被阻塞直到重传包的到来，而后续的分片有些属于其它无关的流。
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.
因为QUIC从底层就为了多路复用而设计，丢包只影响特定的流。每个流的帧收到后可以立即分派给那个流，所以没丢包的流可以继续组包并且供应用层处理。
Caveat: QUIC currently compresses HTTP headers via HTTP/2 HPACK header compression on a dedicated header stream(3), which imposes head-of-line blocking for header frames only.
警告：QUIC目前通过HTTP/2 HPACK 的HTTP头压缩只发生在一个指定的stream(3)上，所以头部帧也有队列头部阻塞的问题。
Authenticated and Encrypted Header and Payload | 认证和加密头部和负载
TCP headers appear in plaintext on the wire and not authenticated, causing a plethora of injection and header manipulation issues for TCP, such as receive-window manipulation and sequence-number overwriting. While some of these are active attacks, others are mechanisms used by middleboxes in the network sometimes in an attempt to transparently improve TCP performance. However, even “performance-enhancing” middleboxes still effectively limit the evolvability of the transport protocol, as has been observed in the design of MPTCP and in its subsequent deployability issues.
TCP头以明文传输并且没有经过认证，导致了TCP有很多劫持和头部篡改的问题，比如篡改接收窗口和重写包序号。这些问题有些是蓄意攻击，有时候是网络的中间件利用这些机制来尝试提高TCP的性能。然后，这些为了加强性能的中间件的努力限制了传输协议的改进，例如已知的MPTCP的设计和由它引起的部署问题。
QUIC packets are always authenticated and typically the payload is fully encrypted. The parts of the packet header which are not encrypted are still authenticated by the receiver, so as to thwart any packet injection or manipulation by third parties. QUIC protects connections from witting or unwitting middlebox manipulation of end-to-end communication.
QUIC包总是经过认证的并且负载完全加密。包头没有被加密的部分也需要经过接收端认证，这使得第三方无法修改任何一个QUIC包。QUIC保护了连接，避免了中间件对点对点通信的有意无意的干扰。
Caveat: PUBLIC_RESET packets that reset a connection are currently not authenticated.
警告：用于重置一个连接的PUBLIC_RESET包目前没有被认证。
Connection Migration | 连接迁移
TCP connections are identified by a 4-tuple of source address, source port, destination address and destination port. A well-known problem with TCP is that connections do not survive IP address changes (for example, by switching from WiFi to cellular) or port number changes (when a client’s NAT binding expires causing a change in the port number seen at the server). While MPTCP addresses the connection migration problem for TCP, it is still plagued by lack of middlebox support and lack of OS deployment.
TCP连接用源IP，源端口，目的IP，目的端口的四元组来标识。一个常见的问题是当IP地址变更（比如从WiFi切换到手机网络）或端口变更（当客户端的NAT绑定超时导致服务端看到的客户端的端口发生变化）将导致连接不可用。MPTCP解决了TCP的连接迁移问题，但是它依然由于缺乏中间件的支持和操作系统的发布而受到限制。
QUIC connections are identified by a 64-bit Connection ID, randomly generated by the client. QUIC can survive IP address changes and NAT re-bindings since the Connection ID remains the same across these migrations. QUIC also provides automatic cryptographic verification of a migrating client, since a migrating client continues to use the same session key for encrypting and decrypting packets.
QUIC连接使用一个由客户端随机产生的64bit的连接ID来标识连接，当IP地址发生变化或者NAT重新绑定了，QUIC的连接依然可以保持，因为连接ID并没有发生变化。而且QUIC为迁移的客户端提供了自动密码验证，一个迁移的客户端继续使用同一个会话key来加解密数据包。
In cases when the connection is unambiguously identified by the 4-tuple, such as when a server sends packets to a client using an ephemeral port, there is an option to not send the connection ID to save bytes on the wire.
如果连接明确指定使用四元组作为标识，比如服务端使用一个临时端口给客户端发送数据，QUIC有一个选项设置不发送连接ID以使得节约链路上的包大小。
英文原文链接
QUIC Wire Layout Specification - Google 文档
本文完，作者yoko，尊重劳动人民成果，转载请注明原文出处： https://pengrl.com/p/33330/