翻：QUIC协议前3章（整合）

https://blog.csdn.net/hunter___/article/details/88758324

https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=1

兴趣需要，翻译的比较潦草。排版也差，暂时没空弄了。

 

带着问题：

1.stream（什么是流）

2.multiplexitng (prioritization) （复用）

 

QUIC                                                     J. Iyengar, Ed.
Internet-Draft                                                    Fastly
Intended status: Standards Track                         M. Thomson, Ed.
Expires: September 12, 2019                                      Mozilla
                                                          March 11, 2019

           QUIC: A UDP-Based Multiplexed and Secure Transport
                      draft-ietf-quic-transport-19

Abstract

   This document defines the core of the QUIC transport protocol.
   Accompanying documents describe QUIC's loss detection and congestion
   control and the use of TLS for key negotiation.

描述QUIC的丢失检测和拥塞控制和使用TLS进行密钥协商。

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   <https://mailarchive.ietf.org/arch/search/?email_list=quic>.

   Working Group information can be found at <https://github.com/
   quicwg>; source code and issues list for this draft can be found at
   <https://github.com/quicwg/base-drafts/labels/-transport>.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Iyengar & Thomson      Expires September 12, 2019               [Page 1]
Internet-Draft           QUIC Transport Protocol              March 2019


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

目录：

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1.  Document Structure  . . . . . . . . . . . . . . . . . . .   6
     1.2.  Terms and Definitions . . . . . . . . . . . . . . . . . .   7
     1.3.  Notational Conventions  . . . . . . . . . . . . . . . . .   8
   2.  Streams . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.1.  Stream Types and Identifiers  . . . . . . . . . . . . . .   9
     2.2.  Sending and Receiving Data  . . . . . . . . . . . . . . .  10
     2.3.  Stream Prioritization . . . . . . . . . . . . . . . . . .  10
   3.  Stream States . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.  Sending Stream States . . . . . . . . . . . . . . . . . .  11
     3.2.  Receiving Stream States . . . . . . . . . . . . . . . . .  13
     3.3.  Permitted Frame Types . . . . . . . . . . . . . . . . . .  16
     3.4.  Bidirectional Stream States . . . . . . . . . . . . . . .  16
     3.5.  Solicited State Transitions . . . . . . . . . . . . . . .  18
   4.  Flow Control  . . . . . . . . . . . . . . . . . . . . . . . .  19
     4.1.  Data Flow Control . . . . . . . . . . . . . . . . . . . .  19
     4.2.  Flow Credit Increments  . . . . . . . . . . . . . . . . .  20
     4.3.  Handling Stream Cancellation  . . . . . . . . . . . . . .  21
     4.4.  Stream Final Size . . . . . . . . . . . . . . . . . . . .  22
     4.5.  Controlling Concurrency . . . . . . . . . . . . . . . . .  22
   5.  Connections . . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.1.  Connection ID . . . . . . . . . . . . . . . . . . . . . .  23
       5.1.1.  Issuing Connection IDs  . . . . . . . . . . . . . . .  24
       5.1.2.  Consuming and Retiring Connection IDs . . . . . . . .  25
     5.2.  Matching Packets to Connections . . . . . . . . . . . . .  26
       5.2.1.  Client Packet Handling  . . . . . . . . . . . . . . .  26
       5.2.2.  Server Packet Handling  . . . . . . . . . . . . . . .  27
     5.3.  Life of a QUIC Connection . . . . . . . . . . . . . . . .  27
   6.  Version Negotiation . . . . . . . . . . . . . . . . . . . . .  28
     6.1.  Sending Version Negotiation Packets . . . . . . . . . . .  28
     6.2.  Handling Version Negotiation Packets  . . . . . . . . . .  28
       6.2.1.  Version Negotiation Between Draft Versions  . . . . .  29
     6.3.  Using Reserved Versions . . . . . . . . . . . . . . . . .  29
   7.  Cryptographic and Transport Handshake . . . . . . . . . . . .  29
     7.1.  Example Handshake Flows . . . . . . . . . . . . . . . . .  31
     7.2.  Negotiating Connection IDs  . . . . . . . . . . . . . . .  32

Iyengar & Thomson      Expires September 12, 2019               [Page 2]
Internet-Draft           QUIC Transport Protocol              March 2019

     7.3.  Transport Parameters  . . . . . . . . . . . . . . . . . .  33
       7.3.1.  Values of Transport Parameters for 0-RTT  . . . . . .  34
       7.3.2.  New Transport Parameters  . . . . . . . . . . . . . .  35
   8.  Address Validation  . . . . . . . . . . . . . . . . . . . . .  35
     8.1.  Address Validation During Connection Establishment  . . .  35
       8.1.1.  Address Validation using Retry Packets  . . . . . . .  36
       8.1.2.  Address Validation for Future Connections . . . . . .  37
       8.1.3.  Address Validation Token Integrity  . . . . . . . . .  39
     8.2.  Path Validation . . . . . . . . . . . . . . . . . . . . .  39
     8.3.  Initiating Path Validation  . . . . . . . . . . . . . . .  40
     8.4.  Path Validation Responses . . . . . . . . . . . . . . . .  40
     8.5.  Successful Path Validation  . . . . . . . . . . . . . . .  41
     8.6.  Failed Path Validation  . . . . . . . . . . . . . . . . .  41
   9.  Connection Migration  . . . . . . . . . . . . . . . . . . . .  42
     9.1.  Probing a New Path  . . . . . . . . . . . . . . . . . . .  43
     9.2.  Initiating Connection Migration . . . . . . . . . . . . .  43
     9.3.  Responding to Connection Migration  . . . . . . . . . . .  44
       9.3.1.  Peer Address Spoofing . . . . . . . . . . . . . . . .  44
       9.3.2.  On-Path Address Spoofing  . . . . . . . . . . . . . .  45
       9.3.3.  Off-Path Packet Forwarding  . . . . . . . . . . . . .  45
     9.4.  Loss Detection and Congestion Control . . . . . . . . . .  46
     9.5.  Privacy Implications of Connection Migration  . . . . . .  47
     9.6.  Server's Preferred Address  . . . . . . . . . . . . . . .  48
       9.6.1.  Communicating A Preferred Address . . . . . . . . . .  48
       9.6.2.  Responding to Connection Migration  . . . . . . . . .  49
       9.6.3.  Interaction of Client Migration and Preferred Address  49
     9.7.  Use of IPv6 Flow-Label and Migration  . . . . . . . . . .  50
   10. Connection Termination  . . . . . . . . . . . . . . . . . . .  50
     10.1.  Closing and Draining Connection States . . . . . . . . .  50
     10.2.  Idle Timeout . . . . . . . . . . . . . . . . . . . . . .  52
     10.3.  Immediate Close  . . . . . . . . . . . . . . . . . . . .  52
     10.4.  Stateless Reset  . . . . . . . . . . . . . . . . . . . .  53
       10.4.1.  Detecting a Stateless Reset  . . . . . . . . . . . .  56
       10.4.2.  Calculating a Stateless Reset Token  . . . . . . . .  56
       10.4.3.  Looping  . . . . . . . . . . . . . . . . . . . . . .  57
   11. Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  58
     11.1.  Connection Errors  . . . . . . . . . . . . . . . . . . .  58
     11.2.  Stream Errors  . . . . . . . . . . . . . . . . . . . . .  59
   12. Packets and Frames  . . . . . . . . . . . . . . . . . . . . .  59
     12.1.  Protected Packets  . . . . . . . . . . . . . . . . . . .  59
     12.2.  Coalescing Packets . . . . . . . . . . . . . . . . . . .  60
     12.3.  Packet Numbers . . . . . . . . . . . . . . . . . . . . .  61
     12.4.  Frames and Frame Types . . . . . . . . . . . . . . . . .  62
   13. Packetization and Reliability . . . . . . . . . . . . . . . .  65
     13.1.  Packet Processing and Acknowledgment . . . . . . . . . .  65
       13.1.1.  Sending ACK Frames . . . . . . . . . . . . . . . . .  66
       13.1.2.  ACK Frames and Packet Protection . . . . . . . . . .  67
     13.2.  Retransmission of Information  . . . . . . . . . . . . .  67

Iyengar & Thomson      Expires September 12, 2019               [Page 3]
Internet-Draft           QUIC Transport Protocol              March 2019

     13.3.  Explicit Congestion Notification . . . . . . . . . . . .  69
       13.3.1.  ECN Counts . . . . . . . . . . . . . . . . . . . . .  70
       13.3.2.  ECN Verification . . . . . . . . . . . . . . . . . .  70
   14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . .  72
     14.1.  Path Maximum Transmission Unit (PMTU)  . . . . . . . . .  73
     14.2.  ICMP Packet Too Big Messages . . . . . . . . . . . . . .  73
     14.3.  Datagram Packetization Layer PMTU Discovery  . . . . . .  74
   15. Versions  . . . . . . . . . . . . . . . . . . . . . . . . . .  75
   16. Variable-Length Integer Encoding  . . . . . . . . . . . . . .  76
   17. Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .  77
     17.1.  Packet Number Encoding and Decoding  . . . . . . . . . .  77
     17.2.  Long Header Packets  . . . . . . . . . . . . . . . . . .  78
       17.2.1.  Version Negotiation Packet . . . . . . . . . . . . .  80
       17.2.2.  Initial Packet . . . . . . . . . . . . . . . . . . .  82
       17.2.3.  0-RTT  . . . . . . . . . . . . . . . . . . . . . . .  84
       17.2.4.  Handshake Packet . . . . . . . . . . . . . . . . . .  85
       17.2.5.  Retry Packet . . . . . . . . . . . . . . . . . . . .  86
     17.3.  Short Header Packets . . . . . . . . . . . . . . . . . .  89
   18. Transport Parameter Encoding  . . . . . . . . . . . . . . . .  90
     18.1.  Transport Parameter Definitions  . . . . . . . . . . . .  91
   19. Frame Types and Formats . . . . . . . . . . . . . . . . . . .  94
     19.1.  PADDING Frame  . . . . . . . . . . . . . . . . . . . . .  94
     19.2.  PING Frame . . . . . . . . . . . . . . . . . . . . . . .  95
     19.3.  ACK Frames . . . . . . . . . . . . . . . . . . . . . . .  95
       19.3.1.  ACK Ranges . . . . . . . . . . . . . . . . . . . . .  97
       19.3.2.  ECN Counts . . . . . . . . . . . . . . . . . . . . .  98
     19.4.  RESET_STREAM Frame . . . . . . . . . . . . . . . . . . .  99
     19.5.  STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 100
     19.6.  CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 100
     19.7.  NEW_TOKEN Frame  . . . . . . . . . . . . . . . . . . . . 101
     19.8.  STREAM Frames  . . . . . . . . . . . . . . . . . . . . . 102
     19.9.  MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 103
     19.10. MAX_STREAM_DATA Frame  . . . . . . . . . . . . . . . . . 104
     19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 105
     19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 106
     19.13. STREAM_DATA_BLOCKED Frame  . . . . . . . . . . . . . . . 106
     19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 107
     19.15. NEW_CONNECTION_ID Frame  . . . . . . . . . . . . . . . . 107
     19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 109
     19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 110
     19.18. PATH_RESPONSE Frame  . . . . . . . . . . . . . . . . . . 110
     19.19. CONNECTION_CLOSE Frames  . . . . . . . . . . . . . . . . 110
     19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 111
   20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 112
     20.1.  Application Protocol Error Codes . . . . . . . . . . . . 113
   21. Security Considerations . . . . . . . . . . . . . . . . . . . 113
     21.1.  Handshake Denial of Service  . . . . . . . . . . . . . . 113
     21.2.  Amplification Attack . . . . . . . . . . . . . . . . . . 114

Iyengar & Thomson      Expires September 12, 2019               [Page 4]
Internet-Draft           QUIC Transport Protocol              March 2019

     21.3.  Optimistic ACK Attack  . . . . . . . . . . . . . . . . . 115
     21.4.  Slowloris Attacks  . . . . . . . . . . . . . . . . . . . 115
     21.5.  Stream Fragmentation and Reassembly Attacks  . . . . . . 115
     21.6.  Stream Commitment Attack . . . . . . . . . . . . . . . . 116
     21.7.  Explicit Congestion Notification Attacks . . . . . . . . 116
     21.8.  Stateless Reset Oracle . . . . . . . . . . . . . . . . . 116
     21.9.  Version Downgrade  . . . . . . . . . . . . . . . . . . . 117
   22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117
     22.1.  QUIC Transport Parameter Registry  . . . . . . . . . . . 117
     22.2.  QUIC Frame Type Registry . . . . . . . . . . . . . . . . 119
     22.3.  QUIC Transport Error Codes Registry  . . . . . . . . . . 119
   23. References  . . . . . . . . . . . . . . . . . . . . . . . . . 121
     23.1.  Normative References . . . . . . . . . . . . . . . . . . 122
     23.2.  Informative References . . . . . . . . . . . . . . . . . 123
   Appendix A.  Sample Packet Number Decoding Algorithm  . . . . . . 125
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . . 125
     B.1.  Since draft-ietf-quic-transport-18  . . . . . . . . . . . 126
     B.2.  Since draft-ietf-quic-transport-17  . . . . . . . . . . . 126
     B.3.  Since draft-ietf-quic-transport-16  . . . . . . . . . . . 127
     B.4.  Since draft-ietf-quic-transport-15  . . . . . . . . . . . 128
     B.5.  Since draft-ietf-quic-transport-14  . . . . . . . . . . . 128
     B.6.  Since draft-ietf-quic-transport-13  . . . . . . . . . . . 128
     B.7.  Since draft-ietf-quic-transport-12  . . . . . . . . . . . 129
     B.8.  Since draft-ietf-quic-transport-11  . . . . . . . . . . . 130
     B.9.  Since draft-ietf-quic-transport-10  . . . . . . . . . . . 130
     B.10. Since draft-ietf-quic-transport-09  . . . . . . . . . . . 131
     B.11. Since draft-ietf-quic-transport-08  . . . . . . . . . . . 132
     B.12. Since draft-ietf-quic-transport-07  . . . . . . . . . . . 132
     B.13. Since draft-ietf-quic-transport-06  . . . . . . . . . . . 133
     B.14. Since draft-ietf-quic-transport-05  . . . . . . . . . . . 134
     B.15. Since draft-ietf-quic-transport-04  . . . . . . . . . . . 134
     B.16. Since draft-ietf-quic-transport-03  . . . . . . . . . . . 135
     B.17. Since draft-ietf-quic-transport-02  . . . . . . . . . . . 135
     B.18. Since draft-ietf-quic-transport-01  . . . . . . . . . . . 136
     B.19. Since draft-ietf-quic-transport-00  . . . . . . . . . . . 138
     B.20. Since draft-hamilton-quic-transport-protocol-01 . . . . . 138
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 138
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 138
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 139

简介：

1.  Introduction

   QUIC is a multiplexed and secure general-purpose transport protocol
   that provides:

   o  Stream multiplexing

   o  Stream and connection-level flow control

   o  Low-latency connection establishment

   o  Connection migration and resilience to NAT rebinding

   o  Authenticated and encrypted header and payload

   QUIC uses UDP as a substrate to avoid requiring changes to legacy
   client operating systems and middleboxes.  QUIC authenticates all of
   its headers and encrypts most of the data it exchanges, including its
   signaling, to avoid incurring a dependency on middleboxes.

QUIC是一种支持多路复用和安全的（常规目的）传输协议。它提供：
1.流的多路复用
2.流的控制以及连接层次的流（量）控制。
3.低延时的连接建立
4.连接迁移和NAT重绑定的弹性？
5.经身份认证和加密的头部及负载

QUIC使用UDP来避免之前的技术的一系列麻烦，如……


文本结构（文章大纲！）也是协议梗概：

1.1.  Document Structure

   This document describes the core QUIC protocol and is structured as
   follows.

   o  Streams are the basic service abstraction that QUIC provides.

      *  Section 2 describes core concepts related to streams,

      *  Section 3 provides a reference model for stream states, and

      *  Section 4 outlines the operation of flow control.

   o  Connections are the context in which QUIC endpoints communicate.

      *  Section 5 describes core concepts related to connections,

      *  Section 6 describes version negotiation,

      *  Section 7 details the process for establishing connections,

      *  Section 8 specifies critical denial of service mitigation
         mechanisms,

      *  Section 9 describes how endpoints migrate a connection to a new
         network path,

      *  Section 10 lists the options for terminating an open
         connection, and

      *  Section 11 provides general guidance for error handling.

   o  Packets and frames are the basic unit used by QUIC to communicate.

      *  Section 12 describes concepts related to packets and frames,

      *  Section 13 defines models for the transmission, retransmission,
         and acknowledgement of data, and

      *  Section 14 specifies rules for managing the size of packets.

   o  Finally, encoding details of QUIC protocol elements are described
      in:

      *  Section 15 (Versions),

      *  Section 16 (Integer Encoding),

      *  Section 17 (Packet Headers),

      *  Section 18 (Transport Parameters),

      *  Section 19 (Frames), and

      *  Section 20 (Errors).

  

文档描述了QUIC的核心协议如下：

o流（stream）是QUIC提供的最基本的服务抽象
       *第2 描述与流(stream)相关的概念。
       *第3 列举与stream 状态相关的模型
       *第4 勾勒流量控制的操作（步骤）

o Connections(链接)是QUIC终端节点间通信的内容。
       *第5 描述与connection相关的核心概念
       *第6 描述版本沟通？？？
       *第7 详述建立connection的过程
       *第8 规定了关键的拒绝服务缓冲机制
       *第9节 描述了端点如何将连接迁移到新的网络路径，
       *第10节 列出了终止开放连接的选项，和
       *第11节 提供了错误处理的一般指导。

o数据包和帧是QUIC用于通信的基本单位。
       *第12节 描述了与数据包和帧相关的概念，
       *第13节 定义了传输，重传，和确认数据，和
       *第14节 规定了管理数据包大小的规则。
 
o最后，描述了QUIC协议元素的编码细节：
       *第15节（版本），
       *第16节（整数编码），
       *第17节（包头），
       *第18节（运输参数），
       *第19节（框架），和
       *第20节（错误）。
 
随附文档描述了QUIC的丢失检测和拥塞控制[QUIC-RECOVERY]，并使用TLS进行密钥协商[QUIC-TLS]。

整个文档核心要点：
o Streams是QUIC提供的基本服务抽象。
o Connections是QUIC端点通信的上下文。
o 数据包和帧是QUIC用于通信的基本单位。
o 最后，QUIC协议元素的编码细节描述如下：



1.2术语和定义下面描述文档中常用的术语。
 
   QUIC：本文档描述的传输协议。 QUIC是一个名字，不是首字母缩略词。
 
   QUIC包：可以封装在UDP数据报中的最小QUIC单元。可以将多个QUIC数据包封装在单个UDP数据报中。
 
   端点：通过生成，接收和处理QUIC数据包可以参与QUIC连接的实体。 QUIC中只有两种类型的端点：客户端和服务器。
 
   客户端：启动QUIC连接的端点。
 
   服务器：接受传入的QUIC连接的端点。
 
   连接ID：不透明标识符，用于标识端点上的QUIC连接。每个端点都为其对等体设置一个值，以包含在发送到端点的数据包中。
 
   流（stream）：QUIC连接中有序字节的单向或双向通道。 QUIC连接可以携带多个同时的流。
 
   应用程序：使用QUIC发送和接收数据的实体。



1.3.  Notational Conventions

   Packet and frame diagrams in this document use the format described
   in Section 3.1 of [RFC2360], with the following additional
   conventions:

   [x]:  Indicates that x is optional

   x (A):  Indicates that x is A bits long

   x (A/B/C) ...:  Indicates that x is one of A, B, or C bits long

   x (i) ...:  Indicates that x uses the variable-length encoding in
      Section 16

   x (*) ...:  Indicates that x is variable-length

2.流（stream）
QUIC中的流为应用程序提供轻量级，有序的字节流抽象。 从另一个角度来看，QUIC流是作为弹性“消息”抽象。
可以通过发送数据来创建流。 与流管理相关的其他过程 如：结束，取消和管理流控制 都旨在实现最小的开销。
例如，单个STREAM帧（第19.8节）可以打开流，携带数据和关闭流。 流也可以是长寿的，并且可以持续整个连接的持续时间。
流可以由任一端点创建，可以同时发送与其他流交错的数据，并且可以被取消。 QUIC没有提供任何确保不同流上字节之间排序的方法。
QUIC允许任意数量的流同时运行，并且允许在任何流上发送任意数量的数据，这些操作受流控制约束（参见第4节）和流限制。

2.1流类型和标识符

                +------+----------------------------------+
                | Bits | Stream Type                      |
                +------+----------------------------------+
                | 0x0  | Client-Initiated, Bidirectional  |
                |      |                                  |
                | 0x1  | Server-Initiated, Bidirectional  |
                |      |                                  |
                | 0x2  | Client-Initiated, Unidirectional |
                |      |                                  |
                | 0x3  | Server-Initiated, Unidirectional |
                +------+----------------------------------+

                         Table 1: Stream ID Types


 
   流可以是单向的或双向的。单向流在一个方向上传输数据：从流的发起者到其对等体。双向流允许数据在两个方向上发送。
 
   通过数值在连接中标识流，称为流ID。流ID对于流是唯一的。 QUIC端点绝不能重用连接中的流ID。流ID被编码为可变长
度整数（参见第16节）。
 
   流ID的最低有效位（0x1）标识流的发起者。客户端发起的流具有偶数编号的流ID（位设置为0），服务器启动的流具有奇
数编号的流ID（位设置为1）。
 
   流ID的第二个最低有效位（0x2）区分双向流（位设置为0）和单向流（位设置为1）。
 
   因此，来自流ID的最低有效两位将流识别为四种类型之一，如表1中所总结的。

在每种类型中，使用数字增加的流ID创建流。 不按顺序使用的流ID导致该类型的所有具有较低编号的流ID的流也被打开。
 客户端打开的第一个双向流的流ID为0。


2.2发送和接收数据
 
   STREAM帧（第19.8节）封装了应用程序发送的数据。
   端点使用STREAM帧中的Stream ID和Offset字段按顺序放置数据。
   端点必须能够将流数据作为有序字节流传递给应用程序。提供有序的字节流要求端点缓冲任何无序接收的数据，
直到已知的流量控制限制值。
 
   QUIC没有特别规定无序传输流数据。但是，实现可以选择提供将数据无序传递到接收应用程序的能力。
 
   端点可以多次接收相同流偏移的流的数据。已经收到的数据可以被丢弃。如果多次发送，给定偏移量的数据不得
改变;端点可以将流中相同偏移量的不同数据的接收视为PROTOCOL_VIOLATION类型的连接错误。
 
   Streams是一种有序的字节流抽象，没有QUIC可见的其他结构。当数据传输，数据包丢失后重传数据或者数据在
接收器传送到应用程序时，预计不会保留STREAM帧边界。
 
   端点不得在任何流上发送数据，而不确保它在同级（peer）设置的流量控制限制范围内。流量控制在第4节中详细描述。

2.3流优先级
 
    如果分配给流的资源被正确地优先化，则流复用可以对应用性能产生显着影响。
 
    QUIC不提供交换优先级信息的框架。 相反，它依赖于从使用QUIC的应用程序接收优先级信息。
 
    QUIC实现应该提供应用程序可以指示流的相对优先级的方式。 在决定将资源专用于哪些流时，实现
时应该使用应用程序提供的信息。

3.流状态
本节按发送或接收组件来描述流。描述了两个状态机：一个用于端点传输数据的流（第3.1节），另一个用于端点
接收数据的流（第3.2节）。

单向流直接使用应用的状态机。双向流使用两个状态机。在大多数情况下，无论流是单向还是双向，这些状态机
的使用都是相同的。打开流的条件对于双向流来说稍微复杂一些，因为发送侧或接收侧的打开会导致流在两个方向
上打开。

端点必须按流ID的递增顺序打开相同类型的流。

注意：
这些状态主要是提供信息。本文档使用流状态来描述何时以及如何发送不同类型的帧以及在接收到不同类
型的帧时预期的反应的规则。虽然这些状态机旨在用于实现QUIC，但这些状态并非旨在约束实现。实现可以定义
不同的状态机，只要其行为与实现这些状态的实现一致即可。


3.1.  Sending Stream States

   Figure 1 shows the states for the part of a stream that sends data to
   a peer.

          o
          | Create Stream (Sending)
          | Peer Creates Bidirectional Stream
          v
      +-------+
      | Ready | Send RESET_STREAM
      |       |-----------------------.
      +-------+                       |
          |                           |
          | Send STREAM /             |
          |      STREAM_DATA_BLOCKED  |
          |                           |
          | Peer Creates              |
          |      Bidirectional Stream |
          v                           |
      +-------+                       |
      | Send  | Send RESET_STREAM     |
      |       |---------------------->|
      +-------+                       |
          |                           |
          | Send STREAM + FIN         |
          v                           v
      +-------+                   +-------+
      | Data  | Send RESET_STREAM | Reset |
      | Sent  |------------------>| Sent  |
      +-------+                   +-------+
          |                           |
          | Recv All ACKs             | Recv ACK
          v                           v
      +-------+                   +-------+
      | Data  |                   | Reset |
      | Recvd |                   | Recvd |
      +-------+                   +-------+

               Figure 1: States for Sending Parts of Streams

3.1发送流状态
图1显示了将数据发送到对等方的流的一部分的状态

端点启动的流的发送部分（客户端类型0和2，服务器类型1和3）由应用程序打开。 “就绪”状态表示新创建的流，该流能够接受来自应用程序的数据。可以在此状态下缓冲流数据以准备发送。

发送第一个STREAM或STREAM_DATA_BLOCKED帧会导致流的发送部分进入“发送”状态。实现可以选择将流ID分配给流，直到它发送第一帧并进入该状态，这可以允许更好的流优先级。

 由对等方发起的双向流的发送部分（服务器类型0，客户机类型1）进入“就绪”状态，然后如果接收部分进入“恢复”状态则立即转换到“发送”状态（第3.2节）。

 在“发送”状态中，端点发送（并在必要时重新发送 ）流数据到STREAM帧中。端点遵守其对等方设置的流量控制限制，并继续接受和处理MAX_STREAM_DATA帧。如果阻塞是通过流或连接流控制限制发送来的，则“发送”状态的端点会生成STREAM_DATA_BLOCKED帧。

在应用程序指示已发送所有流数据并且发送包含FIN位的STREAM帧之后，流的发送部分进入“数据已发送”状态。从该状态开始，端点仅在必要时重传流数据。端点不需要检查流控制限制，也不需要为此状态的流发送STREAM_DATA_BLOCKED帧。可以接收MAX_STREAM_DATA帧，直到对等体接收到最终流偏移。端点可以安全地忽略它从对等端接收到的处于此状态的流的任何MAX_STREAM_DATA帧。

一旦成功确认了所有流数据，流的发送部分就进入“数据记录”状态，这是一种终端状态。

在任何“就绪”，“发送”或“数据发送”状态中，应用程序可以发信号通知（对方）它希望放弃流数据的传输。或者，端点可能从其对等端接收STOP_SENDING帧。在任何一种情况下，端点都会发送RESET_STREAM帧，这会导致流进入“重置已发送”状态。

端点可以发送RESET_STREAM作为标识流的第一帧;这会导致该流的发送部分打开，然后立即转换到“重置已发送”状态。

一旦确认了包含RESET_STREAM的分组，则流的发送部分进入“重置Recvd”状态，这是终端状态。



3.2.  Receiving Stream States

   Figure 2 shows the states for the part of a stream that receives data
   from a peer.  The states for a receiving part of a stream mirror only
   some of the states of the sending part of the stream at the peer.
   The receiving part of a stream does not track states on the sending


   part that cannot be observed, such as the "Ready" state.  Instead,
   the receiving part of a stream tracks the delivery of data to the
   application, some of which cannot be observed by the sender.

          o
          | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
          | Create Bidirectional Stream (Sending)
          | Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
          | Create Higher-Numbered Stream
          v
      +-------+
      | Recv  | Recv RESET_STREAM
      |       |-----------------------.
      +-------+                       |
          |                           |
          | Recv STREAM + FIN         |
          v                           |
      +-------+                       |
      | Size  | Recv RESET_STREAM     |
      | Known |---------------------->|
      +-------+                       |
          |                           |
          | Recv All Data             |
          v                           v
      +-------+ Recv RESET_STREAM +-------+
      | Data  |--- (optional) --->| Reset |
      | Recvd |  Recv All Data    | Recvd |
      +-------+<-- (optional) ----+-------+
          |                           |
          | App Read All Data         | App Read RST
          v                           v
      +-------+                   +-------+
      | Data  |                   | Reset |
      | Read  |                   | Read  |
      +-------+                   +-------+

              Figure 2: States for Receiving Parts of Streams


3.2接收流状态
图2显示了从对等方接收数据的流部分的状态。 接收流的一部分的状态仅镜像对等体流的发送部分的一些状态。 
流的接收部分不跟踪发送部分上无法观察到的状态，例如“就绪”状态。 相反，流的接收部分跟踪向应用程序传
送数据，其中一些数据不能被发送者观察到。

当是该流接收到第一个STREAM，STREAM_DATA_BLOCKED或RESET_STREAM时，将创建由对等方发起的流的接收
部分（客户端的类型1和3，或服务器的0和2）。对于由对等方发起的双向流，接收流的发送部分的MAX_STREAM_DATA
或STOP_SENDING帧也会创建接收部分。流的接收部分的初始状态是“Recv”。

当端点发起的双向流的发送部分（客户端类型0，服务器类型1）进入“就绪”状态时，流的接收部分进入“Recv”状态。

 当从该流的对等体收到MAX_STREAM_DATA或STOP_SENDING帧时，端点将打开双向流。为未打开的流接收
MAX_STREAM_DATA帧表示远程对等体已打开流并提供流控制信任。为未打开的流接收STOP_SENDING帧表示远程对等体
不再希望接收此流上的数据。如果数据包丢失或重新排序，则任何一个帧都可能在STREAM或STREAM_DATA_BLOCKED帧
之前到达。

 在创建流之前，必须创建具有编号较小的流ID的所有相同类型的流。这可确保流的创建顺序在两个端点上保持一致。

在“Recv”状态中，端点接收STREAM和STREAM_DATA_BLOCKED帧。传入的数据被缓冲，可以重新组合成正确的顺序
以便传送到应用程序。当应用程序使用数据并且缓冲区空间可用时，端点发送MAX_STREAM_DATA帧以允许对等方
发送更多数据。

当接收到具有FIN位的STREAM帧时，流的最终大小是已知的（参见第4.4节）。然后，流的接收部分进入“大小已知”状态。
在此状态下，端点不再需要发送MAX_STREAM_DATA帧，它只接收流数据的任何重传。

一旦接收到流的所有数据，接收部分就进入“数据记录”状态。这种状态可能是由于接收到导致转换为“已知大小”的相同STREAM帧
而发生的。在此状态下，端点具有所有流数据。此时可以丢弃它为流接收到的任何STREAM或STREAM_DATA_BLOCKED帧。

 “数据记录”状态持续存在，直到流数据已传送到应用程序。一旦传送了流数据，流就进入“数据读取”状态，这是一种终端状态。

在“Recv”或“Size Known”状态下接收RESET_STREAM帧会使流进入“Reset Recvd”状态。这可能导致流数据传递到应用程序中断。

 当接收到RESET_STREAM时（即，从“Data Recvd”状态），可能接收到所有流数据。类似地，在接收RESET_STREAM帧之后
剩余的流数据可能到达（“重置Recvd”状态）。一个应用可以自由选择管理这种情况。发送RESET_STREAM意味着端点无法保证
流数据的传递;但是，如果收到RESET_STREAM，也不要求停止传送流数据。应用可以中断流数据的传送，丢弃未使用的任何数据，
并立即发出RESET_STREAM的接收信号。或者，如果流数据被完全接收并且缓冲以供应用程序读取，则可以抑制或保留
RESET_STREAM信号。在后一种情况下，流的接收部分从“Reset Recvd”转换为“Data Recvd”。

一旦应用程序已经被传送指示流被重置的信号，流的接收部分就转换到“重置读取”状态，这是终端状态。

3.3允许的帧类型

流的发送方只发送三种帧类型，这些类型会影响发送方或接收方的流状态：STREAM（第19.8节），
STREAM_DATA_BLOCKED（第19.13节）和RESET_STREAM（第19.4节）。

发送方不得从终端状态（“Data Recvd”或“Reset Recvd”）发送任何这些帧。发送者在发送RESET_STREAM后
不得发送STREAM或STREAM_DATA_BLOCKED;也就是说，在终端状态和“重置已发送”状态下不能发送帧。接收方
可以在任何状态下接收这三个帧中的任何一个，因为可能会有延迟传送携带它们的分组情况。

流的接收端发送MAX_STREAM_DATA（第19.10节）和STOP_SENDING帧（第19.5节）。

接收端仅发送处于“Recv”状态的MAX_STREAM_DATA。接收器可以在没有收到RESET_STREAM帧的任何状态下发
送STOP_SENDING;这是除“重置Recvd”或“Reset Read”以外的状态。但是，在“Data Recvd”状态下发送
STOP_SENDING帧几乎没有价值，因为已收到所有流数据。由于数据包的延迟传送，发送方可以在任何状态下接
收这两个帧中的任何一个。

3.4.  Bidirectional Stream States

   +-----------------------+---------------------+---------------------+
   | Sending Part          | Receiving Part      | Composite State     |
   +-----------------------+---------------------+---------------------+
   | No Stream/Ready       | No Stream/Recv *1   | idle                |
   |                       |                     |                     |
   | Ready/Send/Data Sent  | Recv/Size Known     | open                |
   |                       |                     |                     |
   | Ready/Send/Data Sent  | Data Recvd/Data     | half-closed         |
   |                       | Read                | (remote)            |
   |                       |                     |                     |
   | Ready/Send/Data Sent  | Reset Recvd/Reset   | half-closed         |
   |                       | Read                | (remote)            |
   |                       |                     |                     |
   | Data Recvd            | Recv/Size Known     | half-closed (local) |
   |                       |                     |                     |
   | Reset Sent/Reset      | Recv/Size Known     | half-closed (local) |
   | Recvd                 |                     |                     |
   |                       |                     |                     |
   | Reset Sent/Reset      | Data Recvd/Data     | closed              |
   | Recvd                 | Read                |                     |
   |                       |                     |                     |
   | Reset Sent/Reset      | Reset Recvd/Reset   | closed              |
   | Recvd                 | Read                |                     |
   |                       |                     |                     |
   | Data Recvd            | Data Recvd/Data     | closed              |
   |                       | Read                |                     |
   |                       |                     |                     |
   | Data Recvd            | Reset Recvd/Reset   | closed              |
   |                       | Read                |                     |
   +-----------------------+---------------------+---------------------+

           Table 2: Possible Mapping of Stream States to HTTP/2

   Note (*1):  A stream is considered "idle" if it has not yet been
      created, or if the receiving part of the stream is in the "Recv"
      state without yet having received any frames.

3.4双向流状态

双向流由发送和接收部分组成。 实现可以将双向流的状态表示为发送和接收流状态的组合。 当发送或接收部分处于非
终端状态时，最简单的模型将流呈现为“open”，而当发送和接收流都处于终端状态时，呈现为“closed”。
  表2显示了与HTTP / 2 [HTTP2]中的流状态与双向流状态的更复杂映射间的不太紧密的对应关系。 这表明发送或接
收部分流的多个状态被映射到相同的复合状态。 请注意，这只是这种映射的一种; 此映射要求在转换到“关闭”或“半关闭”
状态之前对数据确认。

3.5征求状态过渡

如果端点不再对它在流上接收的数据感兴趣，它可以发送一个STOP_SENDING帧来标识该流，以提示

在相反方向关闭流。这通常表示接收应用程序不再从流中读取接收到的数据，这也不表明将忽略传入的数据。
 

发送STOP_SENDING后收到的STREAM帧仍计入连接和流量控制，即使这些帧在接收时将被丢弃。
 

STOP_SENDING帧请求接收端点发送RESET_STREAM帧。如果流处于就绪或发送状态，则接收

STOP_SENDING帧的端点必须发送RESET_STREAM帧。如果流处于数据发送状态（data sent）并且任所有

未完成的数据被丢弃，则端点应该发送RESET_STREAM帧代替重传。

 端点应该将错误代码从STOP_SENDING帧复制到它发送的RESET_STREAM帧，但是可以使用任何应用程序

错误代码。发送STOP_SENDING帧的端点可以忽略它接收的任何RESET_STREAM帧中携带的错误代码。

如果在已经处于“Data Sent”状态的流上接收到STOP_SENDING帧，则希望停止在该流上重传先前发送的

STREAM帧的端点必须首先发送RESET_STREAM帧重置流。

STOP_SENDING应该仅针对未被对等方重置的流发送。 STOP_SENDING对于“Recv”或“Size Known”状态

的流最有用。

如果包含先前STOP_SENDING的数据包丢失，则端点应发送另一个STOP_SENDING帧。但是，一旦流接

收到所有流数据或RESET_STREAM帧（也就是说，流处于“Recv”或“Size Known”以外的任何状态 ） 发送

STOP_SENDING帧则是不必要的。

希望终止双向流的两个方向的端点可以通过发送RESET_STREAM来终止一个方向，并且它可以通过发送

STOP_SENDING帧来促使在相反方向上的快速终止。