[译] QUIC Wire Layout Specification - Introduction & Overview | QUIC协议标准中文翻译(1) 简介和概述

本文同步发布于： https://www.pengrl.com/p/33330/ ，转载请注明出处，谢谢。

目录

• 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 文档