协议：
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=1
前三章整合：
https://blog.csdn.net/hunter___/article/details/88786666
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 Iyengar & Thomson Expires September 12, 2019 [Page 5] Internet-Draft QUIC Transport Protocol March 2019 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). Accompanying documents describe QUIC's loss detection and congestion control [QUIC-RECOVERY], and the use of TLS for key negotiation [QUIC-TLS]. This document defines QUIC version 1, which conforms to the protocol invariants in [QUIC-INVARIANTS].文档描述了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. Terms and Definitions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Commonly used terms in the document are described below. QUIC: The transport protocol described by this document. QUIC is a name, not an acronym. QUIC packet: The smallest unit of QUIC that can be encapsulated in a UDP datagram. Multiple QUIC packets can be encapsulated in a single UDP datagram. Endpoint: An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets. There are only two types of endpoint in QUIC: client and server. Iyengar & Thomson Expires September 12, 2019 [Page 7] Internet-Draft QUIC Transport Protocol March 2019 Client: The endpoint initiating a QUIC connection. Server: The endpoint accepting incoming QUIC connections. Connection ID: An opaque identifier that is used to identify a QUIC connection at an endpoint. Each endpoint sets a value for its peer to include in packets sent towards the endpoint. Stream: A unidirectional or bidirectional channel of ordered bytes within a QUIC connection. A QUIC connection can carry multiple simultaneous streams. Application: An entity that uses QUIC to send and receive data. 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. Streams Streams in QUIC provide a lightweight, ordered byte-stream abstraction to an application. An alternative view of QUIC streams is as an elastic "message" abstraction. Streams can be created by sending data. Other processes associated with stream management - ending, cancelling, and managing flow control - are all designed to impose minimal overheads. For instance, a single STREAM frame (Section 19.8) can open, carry data for, and close a stream. Streams can also be long-lived and can last the entire duration of a connection. Streams can be created by either endpoint, can concurrently send data interleaved with other streams, and can be cancelled. QUIC does not provide any means of ensuring ordering between bytes on different streams. QUIC allows for an arbitrary number of streams to operate concurrently and for an arbitrary amount of data to be sent on any stream, subject to flow control constraints (see Section 4) and stream limits.QUIC中的流为应用程序提供轻量级，有序的字节流抽象。 从另一个角度来看，QUIC流是作为弹性“消息”抽象。 可以通过发送数据来创建流。 与流管理相关的其他过程 如：结束，取消和管理流控制 都旨在实现最小的开销。 例如，单个STREAM帧（第19.8节）可以打开流，携带数据和关闭流。 流也可以是长寿的，并且可以持续整个连接的持续时间。 流可以由任一端点创建，可以同时发送与其他流交错的数据，并且可以被取消。 QUIC没有提供任何确保不同流上字节之间排序的方法。 QUIC允许任意数量的流同时运行，并且允许在任何流上发送任意数量的数据，这些操作受流控制约束（参见第4节）和流限制。2.1. Stream Types and Identifiers Streams can be unidirectional or bidirectional. Unidirectional streams carry data in one direction: from the initiator of the stream to its peer. Bidirectional streams allow for data to be sent in both directions. Streams are identified within a connection by a numeric value, referred to as the stream ID. Stream IDs are unique to a stream. A QUIC endpoint MUST NOT reuse a stream ID within a connection. Stream IDs are encoded as variable-length integers (see Section 16). The least significant bit (0x1) of the stream ID identifies the initiator of the stream. Client-initiated streams have even-numbered stream IDs (with the bit set to 0), and server-initiated streams have odd-numbered stream IDs (with the bit set to 1). The second least significant bit (0x2) of the stream ID distinguishes between bidirectional streams (with the bit set to 0) and unidirectional streams (with the bit set to 1). The least significant two bits from a stream ID therefore identify a stream as one of four types, as summarized in Table 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 Within each type, streams are created with numerically increasing stream IDs. A stream ID that is used out of order results in all streams of that type with lower-numbered stream IDs also being opened. The first bidirectional stream opened by the client has a stream ID of 0.流类型和标识符 流可以是单向的或双向的。单向流在一个方向上传输数据：从流的发起者到其对等体。双向流允许数据在两个方向上发送。 通过数值在连接中标识流，称为流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. Sending and Receiving Data STREAM frames (Section 19.8) encapsulate data sent by an application. An endpoint uses the Stream ID and Offset fields in STREAM frames to place data in order. Endpoints MUST be able to deliver stream data to an application as an ordered byte-stream. Delivering an ordered byte-stream requires that an endpoint buffer any data that is received out of order, up to the advertised flow control limit. QUIC makes no specific allowances for delivery of stream data out of order. However, implementations MAY choose to offer the ability to deliver data out of order to a receiving application. An endpoint could receive data for a stream at the same stream offset multiple times. Data that has already been received can be discarded. The data at a given offset MUST NOT change if it is sent multiple times; an endpoint MAY treat receipt of different data at the same offset within a stream as a connection error of type PROTOCOL_VIOLATION. Streams are an ordered byte-stream abstraction with no other structure that is visible to QUIC. STREAM frame boundaries are not expected to be preserved when data is transmitted, when data is retransmitted after packet loss, or when data is delivered to the application at a receiver. An endpoint MUST NOT send data on any stream without ensuring that it is within the flow control limits set by its peer. Flow control is described in detail in Section 4.发送和接收数据 STREAM帧（第19.8节）封装了应用程序发送的数据。 端点使用STREAM帧中的Stream ID和Offset字段按顺序放置数据。 端点必须能够将流数据作为有序字节流传递给应用程序。提供有序的字节流要求端点缓冲任何无序接收的数据， 直到已知的流量控制限制值。 QUIC没有特别规定无序传输流数据。但是，实现可以选择提供将数据无序传递到接收应用程序的能力。 端点可以多次接收相同流偏移的流的数据。已经收到的数据可以被丢弃。如果多次发送，给定偏移量的数据不得 改变;端点可以将流中相同偏移量的不同数据的接收视为PROTOCOL_VIOLATION类型的连接错误。 Streams是一种有序的字节流抽象，没有QUIC可见的其他结构。当数据传输，数据包丢失后重传数据或者数据在 接收器传送到应用程序时，预计不会保留STREAM帧边界。 端点不得在任何流上发送数据，而不确保它在同级（peer）设置的流量控制限制范围内。流量控制在第4节中详细描述。2.3. Stream Prioritization Stream multiplexing can have a significant effect on application performance if resources allocated to streams are correctly prioritized. QUIC does not provide frames for exchanging prioritization information. Instead it relies on receiving priority information from the application that uses QUIC. A QUIC implementation SHOULD provide ways in which an application can indicate the relative priority of streams. When deciding which streams to dedicate resources to, the implementation SHOULD use the information provided by the application.2.3流优先级 如果分配给流的资源被正确地优先化，则流复用可以对应用性能产生显着影响。 QUIC不提供交换优先级信息的框架。 相反，它依赖于从使用QUIC的应用程序接收优先级信息。 QUIC实现应该提供应用程序可以指示流的相对优先级的方式。 在决定将资源专用于哪些流时，实现 时应该使用应用程序提供的信息。3. Stream States This section describes streams in terms of their send or receive components. Two state machines are described: one for the streams on which an endpoint transmits data (Section 3.1), and another for streams on which an endpoint receives data (Section 3.2). Unidirectional streams use the applicable state machine directly. Bidirectional streams use both state machines. For the most part, the use of these state machines is the same whether the stream is unidirectional or bidirectional. The conditions for opening a stream are slightly more complex for a bidirectional stream because the opening of either send or receive sides causes the stream to open in both directions. An endpoint MUST open streams of the same type in increasing order of stream ID. Note: These states are largely informative. This document uses stream states to describe rules for when and how different types of frames can be sent and the reactions that are expected when different types of frames are received. Though these state machines are intended to be useful in implementing QUIC, these states aren't intended to constrain implementations. An implementation can define a different state machine as long as its behavior is consistent with an implementation that implements these states.流状态 本节按发送或接收组件来描述流。描述了两个状态机：一个用于端点传输数据的流（第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 The sending part of stream that the endpoint initiates (types 0 and 2 for clients, 1 and 3 for servers) is opened by the application. The "Ready" state represents a newly created stream that is able to accept data from the application. Stream data might be buffered in this state in preparation for sending. Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a sending part of a stream to enter the "Send" state. An implementation might choose to defer allocating a stream ID to a stream until it sends the first frame and enters this state, which can allow for better stream prioritization. The sending part of a bidirectional stream initiated by a peer (type 0 for a server, type 1 for a client) enters the "Ready" state then immediately transitions to the "Send" state if the receiving part enters the "Recv" state (Section 3.2). In the "Send" state, an endpoint transmits - and retransmits as necessary - stream data in STREAM frames. The endpoint respects the flow control limits set by its peer, and continues to accept and process MAX_STREAM_DATA frames. An endpoint in the "Send" state generates STREAM_DATA_BLOCKED frames if it is blocked from sending by stream or connection flow control limits Section 4.1. After the application indicates that all stream data has been sent and a STREAM frame containing the FIN bit is sent, the sending part of the stream enters the "Data Sent" state. From this state, the endpoint only retransmits stream data as necessary. The endpoint does not need to check flow control limits or send STREAM_DATA_BLOCKED frames for a stream in this state. MAX_STREAM_DATA frames might be received until the peer receives the final stream offset. The endpoint can safely ignore any MAX_STREAM_DATA frames it receives from its peer for a stream in this state. Once all stream data has been successfully acknowledged, the sending part of the stream enters the "Data Recvd" state, which is a terminal state. From any of the "Ready", "Send", or "Data Sent" states, an application can signal that it wishes to abandon transmission of stream data. Alternatively, an endpoint might receive a STOP_SENDING frame from its peer. In either case, the endpoint sends a RESET_STREAM frame, which causes the stream to enter the "Reset Sent" state. An endpoint MAY send a RESET_STREAM as the first frame that mentions a stream; this causes the sending part of that stream to open and then immediately transition to the "Reset Sent" state. Once a packet containing a RESET_STREAM has been acknowledged, the sending part of the stream enters the "Reset Recvd" state, which is a terminal state.图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 The receiving part of a stream initiated by a peer (types 1 and 3 for a client, or 0 and 2 for a server) is created when the first STREAM, STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. For bidirectional streams initiated by a peer, receipt of a MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the stream also creates the receiving part. The initial state for the receiving part of stream is "Recv". The receiving part of a stream enters the "Recv" state when the sending part of a bidirectional stream initiated by the endpoint (type 0 for a client, type 1 for a server) enters the "Ready" state. An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or STOP_SENDING frame is received from the peer for that stream. Receiving a MAX_STREAM_DATA frame for an unopened stream indicates that the remote peer has opened the stream and is providing flow control credit. Receiving a STOP_SENDING frame for an unopened stream indicates that the remote peer no longer wishes to receive data on this stream. Either frame might arrive before a STREAM or STREAM_DATA_BLOCKED frame if packets are lost or reordered. Before creating a stream, all streams of the same type with lower- numbered stream IDs MUST be created. This ensures that the creation order for streams is consistent on both endpoints. In the "Recv" state, the endpoint receives STREAM and STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be reassembled into the correct order for delivery to the application. As data is consumed by the application and buffer space becomes available, the endpoint sends MAX_STREAM_DATA frames to allow the peer to send more data. When a STREAM frame with a FIN bit is received, the final size of the stream is known (see Section 4.4). The receiving part of the stream then enters the "Size Known" state. In this state, the endpoint no longer needs to send MAX_STREAM_DATA frames, it only receives any retransmissions of stream data. Once all data for the stream has been received, the receiving part enters the "Data Recvd" state. This might happen as a result of receiving the same STREAM frame that causes the transition to "Size Known". In this state, the endpoint has all stream data. Any STREAM or STREAM_DATA_BLOCKED frames it receives for the stream can be discarded. The "Data Recvd" state persists until stream data has been delivered to the application. Once stream data has been delivered, the stream enters the "Data Read" state, which is a terminal state. Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states causes the stream to enter the "Reset Recvd" state. This might cause the delivery of stream data to the application to be interrupted. It is possible that all stream data is received when a RESET_STREAM is received (that is, from the "Data Recvd" state). Similarly, it is possible for remaining stream data to arrive after receiving a RESET_STREAM frame (the "Reset Recvd" state). An implementation is free to manage this situation as it chooses. Sending RESET_STREAM means that an endpoint cannot guarantee delivery of stream data; however there is no requirement that stream data not be delivered if a RESET_STREAM is received. An implementation MAY interrupt delivery of stream data, discard any data that was not consumed, and signal the receipt of the RESET_STREAM immediately. Alternatively, the RESET_STREAM signal might be suppressed or withheld if stream data is completely received and is buffered to be read by the application. In the latter case, the receiving part of the stream transitions from "Reset Recvd" to "Data Recvd". Once the application has been delivered the signal indicating that the stream was reset, the receiving part of the stream transitions to the "Reset Read" state, which is a terminal state.图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. Permitted Frame Types The sender of a stream sends just three frame types that affect the state of a stream at either sender or receiver: STREAM (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM (Section 19.4). A sender MUST NOT send any of these frames from a terminal state ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the terminal states and in the "Reset Sent" state. A receiver could receive any of these three frames in any state, due to the possibility of delayed delivery of packets carrying them. The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and STOP_SENDING frames (Section 19.5). The receiver only sends MAX_STREAM_DATA in the "Recv" state. A receiver can send STOP_SENDING in any state where it has not received a RESET_STREAM frame; that is states other than "Reset Recvd" or "Reset Read". However there is little value in sending a STOP_SENDING frame in the "Data Recvd" state, since all stream data has been received. A sender could receive either of these two frames in any state as a result of delayed delivery of packets.允许的帧类型 流的发送方只发送三种帧类型，这些类型会影响发送方或接收方的流状态：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 A bidirectional stream is composed of sending and receiving parts. Implementations may represent states of the bidirectional stream as composites of sending and receiving stream states. The simplest model presents the stream as "open" when either sending or receiving parts are in a non-terminal state and "closed" when both sending and receiving streams are in terminal states. Table 2 shows a more complex mapping of bidirectional stream states that loosely correspond to the stream states in HTTP/2 [HTTP2]. This shows that multiple states on sending or receiving parts of streams are mapped to the same composite state. Note that this is just one possibility for such a mapping; this mapping requires that data is acknowledged before the transition to a "closed" or "half-closed" state. +-----------------------+---------------------+---------------------+ | 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.双向流状态 双向流由发送和接收部分组成。 实现可以将双向流的状态表示为发送和接收流状态的组合。 当发送或接收部分处于非 终端状态时，最简单的模型将流呈现为“open”，而当发送和接收流都处于终端状态时，呈现为“closed”。 表2显示了与HTTP / 2 [HTTP2]中的流状态与双向流状态的更复杂映射间的不太紧密的对应关系。 这表明发送或接 收部分流的多个状态被映射到相同的复合状态。 请注意，这只是这种映射的一种; 此映射要求在转换到“关闭”或“半关闭” 状态之前对数据确认。3.5. Solicited State Transitions If an endpoint is no longer interested in the data it is receiving on a stream, it MAY send a STOP_SENDING frame identifying that stream to prompt closure of the stream in the opposite direction. This typically indicates that the receiving application is no longer reading data it receives from the stream, but it is not a guarantee that incoming data will be ignored. STREAM frames received after sending STOP_SENDING are still counted toward connection and stream flow control, even though these frames will be discarded upon receipt. A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame if the stream is in the Ready or Send state. If the stream is in the Data Sent state and any outstanding data is declared lost, an endpoint SHOULD send a RESET_STREAM frame in lieu of a retransmission. An endpoint SHOULD copy the error code from the STOP_SENDING frame to the RESET_STREAM frame it sends, but MAY use any application error code. The endpoint that sends a STOP_SENDING frame MAY ignore the error code carried in any RESET_STREAM frame it receives. If the STOP_SENDING frame is received on a stream that is already in the "Data Sent" state, an endpoint that wishes to cease retransmission of previously-sent STREAM frames on that stream MUST first send a RESET_STREAM frame. STOP_SENDING SHOULD only be sent for a stream that has not been reset by the peer. STOP_SENDING is most useful for streams in the "Recv" or "Size Known" states. An endpoint is expected to send another STOP_SENDING frame if a packet containing a previous STOP_SENDING is lost. However, once either all stream data or a RESET_STREAM frame has been received for the stream - that is, the stream is in any state other than "Recv" or "Size Known" - sending a STOP_SENDING frame is unnecessary. An endpoint that wishes to terminate both directions of a bidirectional stream can terminate one direction by sending a RESET_STREAM, and it can encourage prompt termination in the opposite direction by sending a STOP_SENDING frame.
征求状态过渡
如果端点不再对它在流上接收的数据感兴趣，它可以发送一个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帧来促使在相反方向上的快速终止。
603
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
