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


  • 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 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.


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.


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.


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


  • 连接建立的时延
  • 弹性的拥塞控制
  • 没有队列头部阻塞问题的多路复用
  • 认证和加密的头和负载
  • 流和连接两个层面的流量控制
  • 连接迁移

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 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.


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.


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.


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.


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.


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.


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.


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.


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.


Caveat: PUBLIC_RESET packets that reset a connection are currently not authenticated.


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.


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.


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 Wire Layout Specification - Google 文档

本文完,作者yoko,尊重劳动人民成果,转载请注明原文出处: https://pengrl.com/p/33330/