译：QUIC协议文档
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=1
https://blog.csdn.net/hunter___/article/details/88786666
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
Iyengar & Thomson Expires July 27, 2019 [Page 5]
Internet-Draft QUIC Transport Protocol January 2019
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.
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
Iyengar & Thomson Expires July 27, 2019 [Page 6]
Internet-Draft QUIC Transport Protocol January 2019
* 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].
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.
Client: The endpoint initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections.
Iyengar & Thomson Expires July 27, 2019 [Page 7]
Internet-Draft QUIC Transport Protocol January 2019
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.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. Any stream can
be initiated by either endpoint. 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
Iyengar & Thomson Expires July 27, 2019 [Page 8]
Internet-Draft QUIC Transport Protocol January 2019
stream, subject to flow control constraints (see Section 4) and
stream limits.
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.
Iyengar & Thomson Expires July 27, 2019 [Page 9]
Internet-Draft QUIC Transport Protocol January 2019
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.
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.
Iyengar & Thomson Expires July 27, 2019 [Page 10]
Internet-Draft QUIC Transport Protocol January 2019
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. Sending Stream States
Figure 1 shows the states for the part of a stream that sends data to
a peer.
Iyengar & Thomson Expires July 27, 2019 [Page 11]
Internet-Draft QUIC Transport Protocol January 2019
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.
Iyengar & Thomson Expires July 27, 2019 [Page 12]
Internet-Draft QUIC Transport Protocol January 2019
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.
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
Iyengar & Thomson Expires July 27, 2019 [Page 13]
Internet-Draft QUIC Transport Protocol January 2019
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".
Iyengar & Thomson Expires July 27, 2019 [Page 14]
Internet-Draft QUIC Transport Protocol January 2019
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
Iyengar & Thomson Expires July 27, 2019 [Page 15]
Internet-Draft QUIC Transport Protocol January 2019
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.
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.
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
Iyengar & Thomson Expires July 27, 2019 [Page 16]
Internet-Draft QUIC Transport Protocol January 2019
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.
Iyengar & Thomson Expires July 27, 2019 [Page 17]
Internet-Draft QUIC Transport Protocol January 2019
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.
Iyengar & Thomson Expires July 27, 2019 [Page 18]
Internet-Draft QUIC Transport Protocol January 2019