[譯] 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 文檔