QUIC is currently being drafted by an IETF working group for a standardized design and is expected to be submitted to an RFC in early 2021. The IETF working group released several draft versions during the design process, and the latest draft version is draft-32 released on 2020-10-20 . In addition, QUIC is implemented on the user side (User space), and version iteration will be more convenient and fast. The implementation of the QUIC protocol on the market may be based on different versions (such as draft-29, draft-30, ...). This means that the version of the QUIC protocol supported by the client (client) and the server (server) may be different. When they establish a connection, they need to perform version negotiation (Version Negotiation) first, and use a version supported by both parties.
When the client and the server create a connection, the client needs to bring the version number of the protocol it supports when initiating a request for the first time.
Send version negotiation packets
When the server receives a packet for a new connection, it checks to see if the client's protocol version is supported:
- If the server can support the client's version, the server will use this protocol version for the lifetime of the connection.
- If the server does not support the version, the server will respond to the Version Negotiation packet with the set of versions it supports, which will increase the 1-RTT (Round-Trip Time) delay overhead.
Precautions
- To reduce amplification attacks, the QUIC protocol requires clients to send an Initial Datagram Size of at least 1200 bytes. If the initial data packet is less than 1200 bytes, it needs to be filled with PADDING frame, otherwise the data packet will be discarded by the server.
- Only the server can send the Version Negotiation packet, the client cannot.
- The server recognizes the 0-RTT packet (which has been successfully connected before), and can choose not to send the version negotiation packet to reduce the extra 1-RTT version negotiation delay.
- The initial (Initial) packet or version negotiation packet sent by the server response may be lost, and the client can continue to send new packets until it successfully receives the server response, or abandon the connection attempt.
Handling version negotiation packets
After the client receives the version negotiation package, it selects the version it supports from the set of versions supported by the server.
- If all versions are not supported, the client needs to drop the connection.
- If there is a match to a supported version, the client attempts to create a new connection using that version. New connections must use a new random Destination Connection ID.
Precautions
- If the client has received and successfully processed any other packets (including earlier version negotiation packets), the client MUST discard any new version negotiation packets it later receives.
- The client needs to check whether the connection ID of the negotiated packet matches to ensure that it is not forged by an attacker.
- The current version has no mechanism to prevent downgrade attacks and cannot be outside the draft version . How to prevent downgrade attacks will be defined in a future release.
version number
QUIC versions are identified using 32-bit unsigned numbers. The version number 0x00000000 is reserved for version negotiation. Version number 0x00000001 is reserved for protocol versions published as RFCs.
Version numbers in the format 0x?a?a?a?a are reserved for enforcing version negotiation. That is, the lower 4 bits of all bytes are any version number of 1010 (binary). The reserved version numbers will never represent the real protocol, and the client can use one of the reserved version numbers and expect the server to initiate version negotiation to test whether the unsupported protocol version can be handled correctly.
0xff000000 is used to identify the IETF draft version number. For example, draft-ietf-quic-transport-13 would be identified as 0xff00000d.
QUIC protocol implementers can register QUIC version numbers for private experiments at https://link.zhihu.com/?target=https%3A//github.com/quicwg/base-drafts/wiki/QUIC-Versions .
Version Negotiation packet
When the client receives a packet, it will identify the version negotiation packet based on the value of the Version field being 0.
Version Negotiation Packet {
Header Form (1) = 1,
Unused (7),
Version (32) = 0,
Destination Connection ID Length (8),
Destination Connection ID (0..2040),
Source Connection ID Length (8),
Source Connection ID (0..2040),
Supported Version (32) ...,
}Unused: randomly selected by the server, the client must ignore the value of this field. The server should set the most significant bit (0x40) of this field to 1 so that the version negotiation packet has a Fixed Bit field.
Version: must be set to 0x00000000
Destination Connection ID: is the Source Connection ID in the packet received by the server.
Source Connection ID: It is the Destination Connection ID in the packet received by the server. This ID is initially randomly selected by the client.
Echoing these two connection IDs assures the client that the server received the packet and that the version negotiation packet was not generated by an attacker.
Future versions of QUIC may have different requirements for the length of the connection ID. In particular, the connection ID may have a smaller minimum length or a larger maximum length. Therefore, the connection ID of a specific version rule cannot influence the server's decision on whether to send a version negotiation packet.
Supported Version: A collection of 32-bit version numbers supported by the server
Precautions
- Version negotiation packets do not require ACK
- Version negotiation packets do not have Packet Number and Length fields. Therefore, it will use the entire UDP datagram.
- The server MUST NOT send multiple version negotiation packets in a single UDP datagram.
The full name of QUIC is the Quick UDP Internet Connections protocol, which was designed and proposed by Google and is currently being promoted by the IETF working group. Its design goal is to replace TCP as the data transport layer protocol of HTTP/3. In the Internet of Things (IoT) and edge computing (Edge Computing) scenarios, Xile Technology has also been building YoMo , an edge computing microservice framework based on the QUIC communication protocol at the bottom, and has been paying attention to the development of the QUIC protocol for a long time. time knowledge points.
Online community: discord/quic
Maintainer: YoMo