译：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