RFC 9000

跑在 UDP 上的多路安全传输

   QUIC is a secure general-purpose transport protocol.  This document
   defines version 1 of QUIC, which conforms to the version-independent
   properties of QUIC defined in [QUIC-INVARIANTS].

   QUIC is a connection-oriented protocol that creates a stateful
   interaction between a client and server.

   The QUIC handshake combines negotiation of cryptographic and
   transport parameters.  QUIC integrates the TLS handshake [TLS13],
   although using a customized framing for protecting packets.  The
   integration of TLS and QUIC is described in more detail in
   [QUIC-TLS].  The handshake is structured to permit the exchange of
   application data as soon as possible.  This includes an option for
   clients to send data immediately (0-RTT), which requires some form of
   prior communication or configuration to enable.

[……下接分组、流、迁移]

   Endpoints communicate in QUIC by exchanging QUIC packets.  Most
   packets contain frames, which carry control information and
   application data between endpoints.  QUIC authenticates the entirety
   of each packet and encrypts as much of each packet as is practical.
   QUIC packets are carried in UDP datagrams [UDP] to better facilitate
   deployment in existing systems and networks.

   Application protocols exchange information over a QUIC connection via
   streams, which are ordered sequences of bytes.  Two types of streams
   can be created: bidirectional streams, which allow both endpoints to
   send data; and unidirectional streams, which allow a single endpoint
   to send data.  A credit-based scheme is used to limit stream creation
   and to bound the amount of data that can be sent.

   QUIC provides the necessary feedback to implement reliable delivery
   and congestion control.  An algorithm for detecting and recovering
   from loss of data is described in Section 6 of [QUIC-RECOVERY].  QUIC
   depends on congestion control to avoid network congestion.  An
   exemplary congestion control algorithm is described in Section 7 of
   [QUIC-RECOVERY].

   QUIC connections are not strictly bound to a single network path.
   Connection migration uses connection identifiers to allow connections
   to transfer to a new network path.  Only clients are able to migrate
   in this version of QUIC.  This design also allows connections to
   continue after changes in network topology or address mappings, such
   as might be caused by NAT rebinding.

[……下接术语：QUIC 不是首字母缩写]

   QUIC:  The transport protocol described by this document.  QUIC is a
      name, not an acronym.

流是有序字节，流与流之间不排序

   Streams in QUIC provide a lightweight, ordered byte-stream
   abstraction to an application.  Streams can be unidirectional or
   bidirectional.

   Streams can be created by sending data.  Other processes associated
   with stream management -- ending, canceling, 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 canceled.  QUIC does not
   provide any means of ensuring ordering between bytes on different
   streams.

[……下接 Stream ID 低两位]

   The least significant bit (0x01) 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 (0x02) of the stream ID
   distinguishes between bidirectional streams (with the bit set to 0)
   and unidirectional streams (with the bit set to 1).

   The two least significant bits from a stream ID therefore identify a
   stream as one of four types, as summarized in Table 1.

                +======+==================================+
                | Bits | Stream Type                      |
                +======+==================================+
                | 0x00 | Client-Initiated, Bidirectional  |
                +------+----------------------------------+
                | 0x01 | Server-Initiated, Bidirectional  |
                +------+----------------------------------+
                | 0x02 | Client-Initiated, Unidirectional |
                +------+----------------------------------+
                | 0x03 | Server-Initiated, Unidirectional |
                +------+----------------------------------+

                          Table 1: Stream ID Types

发送侧 / 接收侧两套状态机

   Figure 2 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  |
          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 2: States for Sending Parts of Streams

[……下接收侧]

   Figure 3 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 Reset
          v                           v
      +-------+                   +-------+
      | Data  |                   | Reset |
      | Read  |                   | Read  |
      +-------+                   +-------+

              Figure 3: States for Receiving Parts of Streams

连接不绑死在四元组上

   Each connection possesses a set of connection identifiers, or
   connection IDs, each of which can identify the connection.
   Connection IDs are independently selected by endpoints; each endpoint
   selects the connection IDs that its peer uses.

   The primary function of a connection ID is to ensure that changes in
   addressing at lower protocol layers (UDP, IP) do not cause packets
   for a QUIC connection to be delivered to the wrong endpoint.  Each
   endpoint selects connection IDs using an implementation-specific (and
   perhaps deployment-specific) method that will allow packets with that
   connection ID to be routed back to the endpoint and to be identified
   by the endpoint upon receipt.

   Multiple connection IDs are used so that endpoints can send packets
   that cannot be identified by an observer as being for the same
   connection without cooperation from an endpoint; see Section 9.5.

   Connection IDs MUST NOT contain any information that can be used by
   an external observer (that is, one that does not cooperate with the
   issuer) to correlate them with other connection IDs for the same
   connection.  As a trivial example, this means the same connection ID
   MUST NOT be issued more than once on the same connection.

握手：CRYPTO 帧里跑 TLS 1.3

   QUIC relies on a combined cryptographic and transport handshake to
   minimize connection establishment latency.  QUIC uses the CRYPTO
   frame (Section 19.6) to transmit the cryptographic handshake.  The
   version of QUIC defined in this document is identified as 0x00000001
   and uses TLS as described in [QUIC-TLS]; a different QUIC version
   could indicate that a different cryptographic handshake protocol is
   in use.

   QUIC provides reliable, ordered delivery of the cryptographic
   handshake data.  QUIC packet protection is used to encrypt as much of
   the handshake protocol as possible.  The cryptographic handshake MUST
   provide the following properties:

   *  authenticated key exchange, where

      -  a server is always authenticated,

      -  a client is optionally authenticated,

      -  every connection produces distinct and unrelated keys, and

      -  keying material is usable for packet protection for both 0-RTT
         and 1-RTT packets.

   *  authenticated exchange of values for transport parameters of both
      endpoints, and confidentiality protection for server transport
      parameters (see Section 7.4).

   *  authenticated negotiation of an application protocol (TLS uses
      Application-Layer Protocol Negotiation (ALPN) [ALPN] for this
      purpose).

   The CRYPTO frame can be sent in different packet number spaces
   (Section 12.3).  The offsets used by CRYPTO frames to ensure ordered
   delivery of cryptographic handshake data start from zero in each
   packet number space.

   Figure 4 shows a simplified handshake and the exchange of packets and
   frames that are used to advance the handshake.  Exchange of
   application data during the handshake is enabled where possible,
   shown with an asterisk ("*").  Once the handshake is complete,
   endpoints are able to exchange application data freely.

   Client                                               Server

   Initial (CRYPTO)
   0-RTT (*)              ---------->
                                              Initial (CRYPTO)
                                            Handshake (CRYPTO)
                          <----------                1-RTT (*)
   Handshake (CRYPTO)
   1-RTT (*)              ---------->
                          <----------   1-RTT (HANDSHAKE_DONE)

   1-RTT                  <=========>                    1-RTT

                    Figure 4: Simplified QUIC Handshake

[……下接 1-RTT 实例]

   Figure 5 provides an overview of the 1-RTT handshake.  Each line
   shows a QUIC packet with the packet type and packet number shown
   first, followed by the frames that are typically contained in those
   packets.  For instance, the first packet is of type Initial, with
   packet number 0, and contains a CRYPTO frame carrying the
   ClientHello.

   Multiple QUIC packets -- even of different packet types -- can be
   coalesced into a single UDP datagram; see Section 12.2.  As a result,
   this handshake could consist of as few as four UDP datagrams, or any
   number more (subject to limits inherent to the protocol, such as
   congestion control and anti-amplification).  For instance, the
   server's first flight contains Initial packets, Handshake packets,
   and "0.5-RTT data" in 1-RTT packets.

   Client                                                  Server

   Initial[0]: CRYPTO[CH] ->

                                    Initial[0]: CRYPTO[SH] ACK[0]
                          Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
                                    <- 1-RTT[0]: STREAM[1, "..."]

   Initial[1]: ACK[0]
   Handshake[0]: CRYPTO[FIN], ACK[0]
   1-RTT[0]: STREAM[0, "..."], ACK[0] ->

                                             Handshake[1]: ACK[0]
            <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[0]

                     Figure 5: Example 1-RTT Handshake

[……下接 0-RTT 实例]

   Figure 6 shows an example of a connection with a 0-RTT handshake and
   a single packet of 0-RTT data.  Note that as described in
   Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets,
   and the client sends 1-RTT packets in the same packet number space.

   Client                                                  Server

   Initial[0]: CRYPTO[CH]
   0-RTT[0]: STREAM[0, "..."] ->

                                    Initial[0]: CRYPTO[SH] ACK[0]
                                     Handshake[0] CRYPTO[EE, FIN]
                             <- 1-RTT[0]: STREAM[1, "..."] ACK[0]

   Initial[1]: ACK[0]
   Handshake[0]: CRYPTO[FIN], ACK[0]
   1-RTT[1]: STREAM[0, "..."] ACK[0] ->

                                             Handshake[1]: ACK[0]
            <- 1-RTT[1]: HANDSHAKE_DONE, STREAM[3, "..."], ACK[1]

                     Figure 6: Example 0-RTT Handshake

[……下接 0-RTT 无重放保护]

   An application protocol can use the connection during the handshake
   phase with some limitations.  0-RTT allows application data to be
   sent by a client before receiving a response from the server.
   However, 0-RTT provides no protection against replay attacks; see
   Section 9.2 of [QUIC-TLS].  A server can also send application data
   to a client before it receives the final cryptographic handshake
   messages that allow it to confirm the identity and liveness of the
   client.  These capabilities allow an application protocol to offer
   the option of trading some security guarantees for reduced latency.

Initial 不是明文，但初期旁观者解得开

   QUIC packets have different levels of cryptographic protection based
   on the type of packet.  Details of packet protection are found in
   [QUIC-TLS]; this section includes an overview of the protections that
   are provided.

   Version Negotiation packets have no cryptographic protection; see
   [QUIC-INVARIANTS].

   Retry packets use an AEAD function [AEAD] to protect against
   accidental modification.

   Initial packets use an AEAD function, the keys for which are derived
   using a value that is visible on the wire.  Initial packets therefore
   do not have effective confidentiality protection.  Initial protection
   exists to ensure that the sender of the packet is on the network
   path.  Any entity that receives an Initial packet from a client can
   recover the keys that will allow them to both read the contents of
   the packet and generate Initial packets that will be successfully
   authenticated at either endpoint.  The AEAD also protects Initial
   packets against accidental modification.

   All other packets are protected with keys derived from the
   cryptographic handshake.  The cryptographic handshake ensures that
   only the communicating endpoints receive the corresponding keys for
   Handshake, 0-RTT, and 1-RTT packets.  Packets protected with 0-RTT
   and 1-RTT keys have strong confidentiality and integrity protection.

[……下接 DCID 派生 Initial 密钥]

   The Destination Connection ID field from the first Initial packet
   sent by a client is used to determine packet protection keys for
   Initial packets.  These keys change after receiving a Retry packet;
   see Section 5.2 of [QUIC-TLS].

[……下接 Initial 包上的保护说明]

   In order to prevent tampering by version-unaware middleboxes, Initial
   packets are protected with connection- and version-specific keys
   (Initial keys) as described in [QUIC-TLS].  This protection does not
   provide confidentiality or integrity against attackers that can
   observe packets, but it does prevent attackers that cannot observe
   packets from spoofing Initial packets.

[……下接盐 + DCID]

   The packets that carry the cryptographic handshake are protected with
   a key that is derived from this connection ID and a salt specific to
   the QUIC version.  This allows endpoints to use the same process for
   authenticating packets that they receive as they use after the
   cryptographic handshake completes.  Packets that cannot be
   authenticated are discarded.  Protecting packets in this fashion
   provides a strong assurance that the sender of the packet saw the
   Initial packet and understood it.

长包头、短包头、包类型

   Long Header Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2),
     Type-Specific Bits (4),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Type-Specific Payload (..),
   }

                    Figure 13: Long Header Packet Format

   Long headers are used for packets that are sent prior to the
   establishment of 1-RTT keys.  Once 1-RTT keys are available, a sender
   switches to sending packets using the short header (Section 17.3).
   The long form allows for special packets -- such as the Version
   Negotiation packet -- to be represented in this uniform fixed-length
   packet format.  Packets that use the long header contain the
   following fields:

   Header Form:  The most significant bit (0x80) of byte 0 (the first
      byte) is set to 1 for long headers.

   Fixed Bit:  The next bit (0x40) of byte 0 is set to 1, unless the
      packet is a Version Negotiation packet.  Packets containing a zero
      value for this bit are not valid packets in this version and MUST
      be discarded.  A value of 1 for this bit allows QUIC to coexist
      with other protocols; see [RFC7983].

   Long Packet Type:  The next two bits (those with a mask of 0x30) of
      byte 0 contain a packet type.  Packet types are listed in Table 5.

   Type-Specific Bits:  The semantics of the lower four bits (those with
      a mask of 0x0f) of byte 0 are determined by the packet type.

   Version:  The QUIC Version is a 32-bit field that follows the first
      byte.  This field indicates the version of QUIC that is in use and
      determines how the rest of the protocol fields are interpreted.

   Destination Connection ID Length:  The byte following the version
      contains the length in bytes of the Destination Connection ID
      field that follows it.  This length is encoded as an 8-bit
      unsigned integer.  In QUIC version 1, this value MUST NOT exceed
      20 bytes.  Endpoints that receive a version 1 long header with a
      value larger than 20 MUST drop the packet.  In order to properly
      form a Version Negotiation packet, servers SHOULD be able to read
      longer connection IDs from other QUIC versions.

   Destination Connection ID:  The Destination Connection ID field
      follows the Destination Connection ID Length field, which
      indicates the length of this field.  Section 7.2 describes the use
      of this field in more detail.

   Source Connection ID Length:  The byte following the Destination
      Connection ID contains the length in bytes of the Source
      Connection ID field that follows it.  This length is encoded as an
      8-bit unsigned integer.  In QUIC version 1, this value MUST NOT
      exceed 20 bytes.  Endpoints that receive a version 1 long header
      with a value larger than 20 MUST drop the packet.  In order to
      properly form a Version Negotiation packet, servers SHOULD be able
      to read longer connection IDs from other QUIC versions.

   Source Connection ID:  The Source Connection ID field follows the
      Source Connection ID Length field, which indicates the length of
      this field.  Section 7.2 describes the use of this field in more
      detail.

   Type-Specific Payload:  The remainder of the packet, if any, is type
      specific.

   In this version of QUIC, the following packet types with the long
   header are defined:

                   +======+===========+================+
                   | Type | Name      | Section        |
                   +======+===========+================+
                   | 0x00 | Initial   | Section 17.2.2 |
                   +------+-----------+----------------+
                   | 0x01 | 0-RTT     | Section 17.2.3 |
                   +------+-----------+----------------+
                   | 0x02 | Handshake | Section 17.2.4 |
                   +------+-----------+----------------+
                   | 0x03 | Retry     | Section 17.2.5 |
                   +------+-----------+----------------+

                     Table 5: Long Header Packet Types

[……下接 Initial 布局]

   Initial Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 0,
     Reserved Bits (2),
     Packet Number Length (2),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Token Length (i),
     Token (..),
     Length (i),
     Packet Number (8..32),
     Packet Payload (8..),
   }

                         Figure 15: Initial Packet

[……下接短包头 1-RTT]

   This version of QUIC defines a single packet type that uses the short
   packet header.

17.3.1.  1-RTT Packet

   A 1-RTT packet uses a short packet header.  It is used after the
   version and 1-RTT keys are negotiated.

   1-RTT Packet {
     Header Form (1) = 0,
     Fixed Bit (1) = 1,
     Spin Bit (1),
     Reserved Bits (2),
     Key Phase (1),
     Packet Number Length (2),
     Destination Connection ID (0..160),
     Packet Number (8..32),
     Packet Payload (8..),
   }

                          Figure 19: 1-RTT Packet

无队头阻塞指跨流，不是包永不丢

   This version of QUIC uses the long packet header during connection
   establishment; see Section 17.2.  Packets with the long header are
   Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake
   (Section 17.2.4), and Retry (Section 17.2.5).  Version negotiation
   uses a version-independent packet with a long header; see
   Section 17.2.1.

   Packets with the short header are designed for minimal overhead and
   are used after a connection is established and 1-RTT keys are
   available; see Section 17.3.

[……下接多路复用与丢包]

   Stream multiplexing is achieved by interleaving STREAM frames from
   multiple streams into one or more QUIC packets.  A single QUIC packet
   can include multiple STREAM frames from one or more streams.

   One of the benefits of QUIC is avoidance of head-of-line blocking
   across multiple streams.  When a packet loss occurs, only streams
   with data in that packet are blocked waiting for a retransmission to
   be received, while other streams can continue making progress.  Note
   that when data from multiple streams is included in a single QUIC
   packet, loss of that packet blocks all those streams from making
   progress.  Implementations are advised to include as few streams as
   necessary in outgoing packets without losing transmission efficiency
   to underfilled packets.