| Modifier and Type | Interface and Description
|
|---|
| public interface | HandshakePacketThis class models Quic Handshake Packets, as defined by
RFC 9000, Section 17.2.4:
A Handshake packet uses long headers with a type value of 0x02, followed
by the Length and Packet Number fields; see Section 17.2. The first byte
contains the Reserved and Packet Number Length bits; see Section 17.2.
It is used to carry cryptographic handshake messages and acknowledgments
from the server and client.
Handshake Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 2,
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),
Length (i),
Packet Number (8..32),
Packet Payload (..),
}
|
| public interface | InitialPacketThis class models Quic Initial Packets, as defined by
RFC 9000, Section 17.2.2:
An Initial packet uses long headers with a type value of 0x00.
It carries the first CRYPTO frames sent by the client and server to perform
key exchange, and it carries ACK frames in either direction.
Initial Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 0,
Reserved Bits (2), # Protected
Packet Number Length (2), # Protected
Version (32),
DCID Len (8),
Destination Connection ID (0..160),
SCID Len (8),
Source Connection ID (0..160),
Token Length (i),
Token (..),
Length (i),
Packet Number (8..32), # Protected
# Protected Packet Payload (..)
Protected Payload (0..24), # Skipped Part
Protected Payload (128), # Sampled Part
Protected Payload (..) # Remainder
}
|
| public interface | OneRttPacketThis class models Quic 1-RTT packets, as defined by
RFC 9000, Section 17.3.1:
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), # Protected
Key Phase (1), # Protected
Packet Number Length (2), # Protected
Destination Connection ID (0..160),
Packet Number (8..32), # Protected
# Protected Packet Payload:
Protected Payload (0..24), # Skipped Part
Protected Payload (128), # Sampled Part
Protected Payload (..), # Remainder
}
|
| public interface | PacketSpaceAn interface implemented by classes which keep track of packet
numbers for a given packet number space.
|
| public interface | QuicPacketA super-interface for all specific Quic packet implementation
classes.
|
| public interface | RetryPacketThis class models Quic Retry Packets, as defined by
RFC 9000, Section 17.2.5:
A Retry packet uses a long packet header with a type value of 0x03.
It carries an address validation token created by the server.
It is used by a server that wishes to perform a retry; see Section 8.1.
Retry Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 3,
Unused (4),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Retry Token (..),
Retry Integrity Tag (128),
}
|
| public interface | VersionNegotiationPacketThis class models Quic Version Negotiation Packets, as defined by
RFC 9000, Section 17.2.1:
A Version Negotiation packet is inherently not version-specific.
Upon receipt by a client, it will be identified as a Version
Negotiation packet based on the Version field having a value of 0.
The Version Negotiation packet is a response to a client packet that
contains a version that is not supported by the server, and is only
sent by servers.
The layout of a Version Negotiation packet is:
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) ...,
}
|
| public interface | ZeroRttPacketThis class models Quic 0-RTT Packets, as defined by
RFC 9000, Section 17.2.3:
A 0-RTT packet uses long headers with a type value of 0x01, followed
by the Length and Packet Number fields; see Section 17.2. The first
byte contains the Reserved and Packet Number Length bits; see Section 17.2.
A 0-RTT packet is used to carry "early" data from the client to the server
as part of the first flight, prior to handshake completion. As part of the
TLS handshake, the server can accept or reject this early data.
See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its limitations.
0-RTT Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 1,
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),
Length (i),
Packet Number (8..32),
Packet Payload (..),
}
|