Welcome to my personal website for better reading experience typesetting: [translated] QUIC Wire Layout Specification - Frame Types and Formats | QUIC protocol standard Chinese translation (4) frame type and format | yoko Blog ( https://pengrl.com / the p-/ 47156 / )
table of Contents
- Frame Types | Frame Type
- STREAM Frame | stream type frame
- ACK Frame | ACK 帧
- STOP_WAITING Frame | frame stop waiting
- WINDOW_UPDATE Frame | update window frame
- BLOCKED Frame | frame blocking information
- CONGESTION_FEEDBACK Frame | congestion feedback frame
- PADDING Frame | filling frame
- RST_STREAM Frame | stream reset frame
- PING frame | PING帧
- CONNECTION_CLOSE frame | Connection closed frame
Frame Types and Formats | frame type and format
QUIC Frame Packets are populated by frames. which have a Frame Type byte, which itself has a type-dependent interpretation, followed by type-dependent frame header fields. All frames are contained within single QUIC Packets and no frame can span across a QUIC Packet boundary.
QUIC frame packet type by one or more frames. Frame has a frame type of the byte size, type has its own explanation, followed by the frame type field. Can contain one or more frames in a QUIC package, no frame may span multiple packets QUIC.
Frame Types | Frame Type
There are two interpretations for the Frame Type byte, resulting in two frame types: Special Frame Types, and Regular Frame Types. Special Frame Types encode both a Frame Type and corresponding flags all in the Frame Type byte, while Regular Frame Types use the Frame Type byte simply.
There are two frame types: special frame type and conventional frame types, their resolution is not the same. A special frame type in the frame type coding of the bytes in the frame type and simultaneously the corresponding flag bit, byte and frame type conventionally used to identify the type of frame only.
Currently defined Special Frame Types are:
The current definition of special frame types are:
--- src
+------------------+-----------------------------+
| Type-field value | Control Frame-type |
+------------------+-----------------------------+
| 1fdooossB | STREAM |
| 01ntllmmB | ACK |
| 001xxxxxB | CONGESTION_FEEDBACK |
+------------------+-----------------------------+
---Currently defined Regular Frame Types are:
Current conventional frame types are defined:
--- src
+------------------+-----------------------------+
| Type-field value | Control Frame-type |
+------------------+-----------------------------+
| 00000000B (0x00) | PADDING |
| 00000001B (0x01) | RST_STREAM |
| 00000010B (0x02) | CONNECTION_CLOSE |
| 00000011B (0x03) | GOAWAY |
| 00000100B (0x04) | WINDOW_UPDATE |
| 00000101B (0x05) | BLOCKED |
| 00000110B (0x06) | STOP_WAITING |
| 00000111B (0x07) | PING |
+------------------+-----------------------------+
---STREAM Frame | stream type frame
The STREAM frame is used to both implicitly create a stream and to send data on it, and is as follows:
Frames for stream type is implicitly created stream and transmit data on the stream, the format is:
--- src
0 1 … SLEN
+--------+--------+--------+--------+--------+
|Type (8)| Stream ID (8, 16, 24, or 32 bits) |
| | (Variable length SLEN bytes) |
+--------+--------+--------+--------+--------+
SLEN+1 SLEN+2 … SLEN+OLEN
+--------+--------+--------+--------+--------+--------+--------+--------+
| Offset (0, 16, 24, 32, 40, 48, 56, or 64 bits) (variable length) |
| (Variable length: OLEN bytes) |
+--------+--------+--------+--------+--------+--------+--------+--------+
SLEN+OLEN+1 SLEN+OLEN+2
+-------------+-------------+
| Data length (0 or 16 bits)|
| Optional(maybe 0 bytes) |
+------------+--------------+
---The fields in the STREAM frame header are as follows:
- Frame Type: The Frame Type byte is an 8-bit value containing various flags (1fdooossB):
- The leftmost bit must be set to 1 indicating that this is a STREAM frame.
- The 'f' bit is the FIN bit. When set to 1, this bit indicates the sender is done sending on this stream and wishes to "half-close" (described in more detail later.)
- which is described in more detail later in this document.
- The 'd' bit indicates whether a Data Length is present in the STREAM header. When set to 0, this field indicates that the STREAM frame extends to the end of the Packet.
- The next three 'ooo' bits encode the length of the Offset header field as 0, 16, 24, 32, 40, 48, 56, or 64 bits long.
- The next two 'ss' bits encode the length of the Stream ID header field as 8, 16, 24, or 32 bits long.
- Stream ID: A variable-sized unsigned ID unique to this stream.
- Offset: A variable-sized unsigned number specifying the byte offset in the stream for this block of data.
- Data length: An optional 16-bit unsigned number specifying the length of the data in this stream frame. The option to omit the length should only be used when the packet is a "full-sized" Packet, to avoid the risk of corruption via padding.
Meaning stream type frame header field as follows:
- Frame type: 8bit, comprising a variable flag (1fdooossB):
- The leftmost bit must be set to 1 Mark This is a type of stream of frames.
- 'F' bit is Fin bit. If completed on this transmission stream 1, and identifying the transmitting end into the desired semi-closed state (discussed further details follow).
- 'D' header identifying the current bit stream contains data length. If set to 0, identifies the frame type of flow is the size of the packet size.
- The next 'ooo' 3 th coded bit length header offset such 0,16,24,32,40,48,56,64bit long.
- The next 'ss' two bit code length of the first flow ID, such 8,16,24,32bit long.
- Flow ID: a variable length unsigned integer that uniquely identifies this stream
- Offset: this data a variable length unsigned integer offset in the stream identifier
- Data length: the optional 16bit unsigned integer that identifies the data type of the frame length. When the length of this package is a full size when this field may be omitted, for avoiding the risk of filling.
A stream frame must always have either non-zero data length or the FIN bit set.
It must be non-flow type of frame size of the data length of 0 or set flag Fin.
ACK Frame | ACK 帧
The ACK frame is sent to inform the peer which packets have been received, as well as which packets are still considered missing by the receiver (the contents of missing packets may need to be resent). The ack frame contains between 1 and 256 ack blocks. Ack blocks are ranges of acknowledged packets, similar to TCP’s SACK blocks, but QUIC has no equivalent of TCP’s cumulative ack point, because packets are retransmitted with new sequence numbers.
Transmits an ACK frame for notifying the terminal which has been received for the packet, in other words, an end notification packet which the receiving side is not received (the contents of the missing packet may need to be retransmitted). ACK frame includes a block ack 1-256. Block ack interval is acknowledged packet, the TCP SACK blocks similar to, but different from the TCP irrevocable ack, since the use of a new packet number when QUIC retransmission.
To limit the ACK blocks to the ones that haven't yet been received by the peer, the peer periodically sends STOP_WAITING frames that signal the receiver to stop acking packets below a specified sequence number, raising the "least unacked" packet number at the receiver. A sender of an ACK frame thus reports only those ACK blocks between the received least unacked and the reported largest observed packet numbers. It is recommended for the sender to send the most recent largest acked packet it has received in an ack as the stop waiting frame’s least unacked value.
In order to limit to those of the end block ACK has not been received, the data transmission periodically sends STOP_WAITINGa frame to inform the receiving end stop ack packet sequence number is less than a specified. Such that the receiving end generates a "minimal yet ack" packet number. Thus the sender of the ACK frame needs to report that the minimum value of the ack and not between the maximum sequence number of the received block ACK. It recommends ACK frame sent by the sender has recently been the greatest ack ACK packet in the frame, just STOP_WAITINGas the smallest yet ack frame.
Unlike TCP SACKs, QUIC ACK blocks are irrevocable, so once a packet is acked, even if it does not appear in a future ack frame, it is assumed to be acked.
Unlike the TCP SACK, QUIC the block ACK is irrevocable, if a packet is ack, then even though it no longer appears in the frame after the ACK, it has been still considered the ack.
As a replacement for QUIC’s deprecated entropy, the sender can intentionally skip packet numbers to introduce entropy into the connection. The sender must always close the connection if an unsent packet number is acked, so this mechanism automatically defeats any potential attackers. The ack format is efficient at expressing blocks of missing packets, so this has a low cost to the receiver and sender and efficiently provides up to 8 bits of entropy on demand, rather than incurring the constant overhead and achieving 8 bits of entropy. The 8 bits is the longest gap between ack ranges the ack format can efficiently express.
Alternatively QUIC deprecated information entropy, the sender may be intentionally skip packet number information to the entropy of the filling connection. If the transmission side does not send a receive packet number corresponding to the ACK, the connection should be closed, this mechanism may be automatically preventing any potential attacker. a format for representing the block ack packet is lost and efficient.
Section Offsets
0: Start of the ack frame.
T: Byte offset of the start of the timestamp section.
A: Byte offset of the start of the ack block section.
N: Length in bytes of the largest acked.
Each area offset
0: ack frame is started
T: time zone offset
A: ack block region offset
N: maximum length of ack
--- src
0 1 => N N+1 => A(aka N + 3)
+---------+-------------------------------------------------+--------+--------+
| Type | Largest Acked | Largest Acked |
| (8) | (8, 16, 32, or 48 bits, determined by ll) | Delta Time (16) |
|01nullmm | | |
+---------+-------------------------------------------------+--------+--------+
A A + 1 ==> A + N
+--------+----------------------------------------+
| Number | First Ack |
|Blocks-1| Block Length |
| (opt) |(8, 16, 32 or 48 bits, determined by mm)|
+--------+----------------------------------------+
A + N + 1 A + N + 2 ==> T(aka A + 2N + 1)
+------------+-------------------------------------------------+
| Gap to next| Ack Block Length |
| Block (8) | (8, 16, 32, or 48 bits, determined by mm) |
| (Repeats) | (repeats Number Ranges times) |
+------------+-------------------------------------------------+
T T+1 T+2 (Repeated Num Timestamps)
+----------+--------+---------------------+ ... --------+------------------+
| Num | Delta | Time Since | | Delta | Time |
|Timestamps|Largest | Largest Acked | |Largest | Since Previous |
| (8) | Acked | (32 bits) | | Acked |Timestamp(16 bits)|
+----------+--------+---------------------+ +--------+------------------+
---The fields in the ACK frame are as follows:
- Frame Type: The Frame Type byte is an 8-bit value containing various flags (01nullmmB).
- The first two bits must be set to 01 indicating that this is an ACK frame.
- The 'n' bit indicates whether the frame has more than 1 ack range.
- The 'u' bit is unused.
- The two 'll' bits encode the length of the Largest Observed field as 1, 2, 4, or 6 bytes long.
- The two 'mm' bits encode the length of the Missing Packet Sequence Number Delta field as 1, 2, 4, or 6 bytes long.
- Largest Acked: A variable-sized unsigned value representing the largest packet number the peer has observed.
- Largest Acked Delta Time: A 16-bit unsigned float with 11 explicit bits of mantissa and 5 bits of explicit exponent, specifying the time elapsed in microseconds from when largest acked was received until this Ack frame was sent. The bit format is loosely modeled after IEEE 754. For example, 1 microsecond is represented as 0x1, which has an exponent of zero, presented in the 5 high order bits, and mantissa of 1, presented in the 11 low order bits. When the explicit exponent is greater than zero, an implicit high-order 12th bit of 1 is assumed in the mantissa. For example, a floating value of 0x800 has an explicit exponent of 1, as well as an explicit mantissa of 0, but then has an effective mantissa of 4096 (12th bit is assumed to be 1). Additionally, the actual exponent is one-less than the explicit exponent, and the value represents 4096 microseconds. Any values larger than the representable range are clamped to 0xFFFF.
- Ack Block Section:
- Num Blocks: An optional 8-bit unsigned value specifying one less than the number of ack blocks. Only present if the 'n' flag bit is 1.
- Ack block length: A variable-sized packet number delta. For the first missing packet range, the ack block starts at largest acked. For the first ack block, the length of the ack block is 1 + this value. For subsequent ack blocks, it is the length of the ack block. For non-first blocks, a value of 0 indicates more than 256 packets in a row were lost.
- Gap to next block: An 8-bit unsigned value specifying the number of packets between ack blocks.
- Timestamp Section:
- Num Timestamp: An 8-bit unsigned value specifying the number of timestamps that are included in this ack frame. There will be this many pairs of <packet number, timestamp> following in the timestamps.
- Delta Largest Observed: An 8-bit unsigned value specifying the packet number delta from the first timestamp to the largest observed. Therefore, the packet number is the largest observed minus the delta largest observed.
- First Timestamp: A 32-bit unsigned value specifying the time delta in microseconds, from the beginning of the connection of the arrival of the packet specified by Largest Observed minus Delta Largest Observed.
- Delta Largest Observed (Repeated): (Same as above.)
- Time Since Previous Timestamp (Repeated): A 16-bit unsigned value specifying delta from the previous timestamp. It is encoded in the same format as the Ack Delay Time.
Field Meaning ACK frame as follows:
- Frame Type: 8bit, it contains a flag variable content (01nullmmB).
- The first two bit must be set to 01 to identify it is an ACK frame.
- 'N' identifies the frame contains more than one section ack
- 'U' is not used
- 'll' which encodes 2bit
Largest Observedfield length may be 1,2,4,6 byte - 'mm' which encodes 2bit
Missing Packet Sequence Number Deltafield length may be 1,2,4,6 byte
- Has confirmed that the maximum packet number: a variable length unsigned identification number of the received end of the maximum packet number
- It has confirmed that the maximum time difference: a 16bit unsigned floating point, 11bit protocol for identifying the mantissa low, high index identifies 5bit. The transmission time field for identifying the ack frame subtracting the maximum packet reception time has been confirmed, the unit subtle. Definition Format approximate IEEE754. For example, 0x1 represents a delicate, index 0, indicates high 5bit mantissa is 1, indicates the low 11bit. When the index portion of the protocol is greater than 0, the mantissa of the implicit default 12bit 1. For example, the agreement of a floating-point value 0x800 explicit index of 1, there is an implicit ending in 0, since the index is greater than 1 in the protocol, so that we have a valid 4096 mantissa values (implicit mantissa the first 12 is considered to be 1). In addition, the real index than small protocol index 1, so this value identifies 4096 microseconds. May represent any value greater than the range are defined as 0xFFFF.
- Ack block area:
- Number of blocks: An optional 8bit unsigned value, equal to the number minus one block ack. Only the 'n' flag set to 1 exists.
- Block size: a variable difference in packet number. For the first packet loss interval, ack block ack starting sequence number is the largest. For non-first block, 0 indicates a packet loss over 256.
- The next block interval: a 8bit unsigned number of packets between the value of the identification block ack.
- Timestamp area:
- Number stamp: a 8bit unsigned value identifies the ACK frame in a plurality of time stamps. Will be behind the plurality of packet sequence number, the timestamp of
- It has been observed with the largest difference: 8bit unsigned values identify the first timestamp and the maximum difference was observed. Therefore, the packet number equal to the maximum packet number has been observed by subtracting the difference.
- The first timestamp: unsigned 32-bit value that identifies the time difference in the delicate units, equal to the maximum reception time has been observed that the maximum minus the packet has been observed.
- Has been observed that the maximum difference (in duplicate): (the same as described above.)
- And the difference between the previous timestamp (repeated): 16bit unsigned values, identifies the difference between a timestamp before. Ack coding scheme and the same delay time.
STOP_WAITING Frame | frame stop waiting
The STOP_WAITING frame is sent to inform the peer that it should not continue to wait for packets with packet numbers lower than a specified value. The packet number is encoded in 1, 2, 4 or 6 bytes, using the same coding length as is specified for the packet number for the enclosing packet's header (specified in the QUIC Frame Packet's Public Flags field.) The frame is as follows:
Wait frame transmission stop notification to the terminal without waiting for the packet is less than the specified packet number. Packet sequence number may be encoded as 1,2,4,6 bytes. Coding scheme and public signs QUIC frame packet type field of the same packet number. Frame format is as follows:
--- src
0 1 2 3 4 5 6
+--------+--------+--------+--------+--------+-------+-------+
|Type (8)| Least unacked delta (8, 16, 32, or 48 bits) |
| | (variable length) |
+--------+--------+--------+--------+--------+--------+------+
---The fields in the STOP_WAITING frame are as follows:
- Frame Type: The Frame Type byte is an 8-bit value that must be set to 0x06 indicating that this is a STOP_WAITING frame.
- Least Unacked Delta: A variable length packet number delta with the same length as the packet header's packet number. Subtract it from the header's packet number to determine the least unacked. The resulting least unacked is the smallest packet number of any packet for which the sender is still awaiting an ack. If the receiver is missing any packets smaller than this value, the receiver should consider those packets to be irrecoverably lost.
Stop waiting frame fields have the following meanings:
- Frame type: 8bit, it must be set to 0x06.
- No acknowledgment number smallest difference: a difference in length of the sequence number header packet number and use the same variable length. This is worth minus the minimum number has not ack packet with a packet number. The minimum number is not ack packet still waiting for all the transmitting end ack packet number of the smallest number. If the receiver is missing any smaller than this number of packets, then the receiving end of these packages should be considered permanently lost.
WINDOW_UPDATE Frame | update window frame
The WINDOW_UPDATE frame is used to inform the peer of an increase in an endpoint's flow control receive window. The stream ID can be 0, indicating this WINDOW_UPDATE applies to the connection level flow control window, or > 0 indicating that the specified stream should increase its flow control window. The frame is as follows:
Update window frame used to inform the local end of the primary flow control receive window growth. When the stream ID is identified as 0 on the window frames to update the connection level flow control window, > 0identifying a need to increase its specified stream flow control window. This frame is defined as follows:
An absolute byte offset is specified, and the receiver of a WINDOW_UPDATE frame may only send up to that number of bytes on the specified stream. Violating flow control by sending further bytes will result in the receiving endpoint closing the connection.
An absolute byte offset specified, the receiving side window frame update may be sent up to the specified byte in the specified stream. Violation of the flow control send more data leads to data sink close the connection.
On receipt of multiple WINDOW_UPDATE frames for a specific stream ID, it is only necessary to keep track of the maximum byte offset.
If a stream on the plurality of received update window frames, only need to focus the maximum byte offset.
Both stream and session windows start with a default value of 16 KB, but this is typically increased during the handshake. To do this, an endpoint should negotiate the SFCW (Stream Flow Control Window) and CFCW (Connection/Session Flow Control Window) parameters in the handshake. The value associated with each tag should be the number of bytes for initial stream window and initial connection window respectively.
The default value starts flowing and window connection is 16KB, but usually grow in the handshake stage. To achieve this effect, the end of the handshake negotiation phase need SFCW (flow rate on the flow control window) and CFCW (traffic on the connection / session control window) parameter. The initial window size is required level and connected separately specified level.
Frame format is as follows:
--- src
0 1 4 5 12
+--------+--------+-- ... --+-------+--------+-- ... --+-------+
|Type(8) | Stream ID (32 bits) | Byte offset (64 bits) |
+--------+--------+-- ... --+-------+--------+-- ... --+-------+
---The fields in the WINDOW_UPDATE frame are as follows:
- Frame Type: The Frame Type byte is an 8-bit value that must be set to 0x04 indicating that this is a WINDOW_UPDATE frame.
- Stream ID: ID of the stream whose flow control windows is being updated, or 0 to specify the connection-level flow control window.
- Byte offset: A 64-bit unsigned integer indicating the absolute byte offset of data which can be sent on the given stream. In the case of connection level flow control, the cumulative number of bytes which can be sent on all currently open streams.
Update window frame fields have the following meanings:
- Frame type: 8bit, it must be set to 0x04
- Flow ID: needs updating traffic flow control which window is set to zero flow connection level control window is updated.
- Byte offset: 64bit unsigned integer, data may be transmitted on the absolute byte offset identifies the specified stream. If the connection-level flow control, it is the sum of all currently open connection stream.
BLOCKED Frame | frame blocking information
The BLOCKED frame is used to indicate to the remote endpoint that this endpoint is ready to send data (and has data to send), but is currently flow control blocked. This is a purely informational frame, which is extremely useful for debugging purposes. A receiver of a BLOCKED frame should simply discard it (after possibly printing a helpful log message). The frame is as follows:
Congestion information of the present frame is used to inform the peer end is ready to send data (and the need to send data), but is currently blocked by the flow control. This is an extremely useful for debugging pure information frame. Recipient blocking information frame should simply discard this frame (for example, reprinting a useful log information after). Frame format is as follows:
--- src
0 1 2 3 4
+--------+--------+--------+--------+--------+
|Type(8) | Stream ID (32 bits) |
+--------+--------+--------+--------+--------+
---The fields in the BLOCKED frame are as follows:
Frame Type: The Frame Type byte is an 8-bit value that must be set to 0x05 indicating that this is a BLOCKED frame.
Stream ID: A 32-bit unsigned number indicating the stream which is flow control blocked. A non-zero Stream ID field specifies the stream that is flow control blocked. When zero, the Stream ID field indicates that the connection is flow control blocked at the connection level.
Field Meaning congestion information frame as follows:
- Frame Type: 8bit, it must be set to 0x05 Mark This is a blocking message frame.
- Flow ID: 32bit unsigned number indicates which stream flow control is blocked. Stream ID identifies a particular non-zero flow. 0 identifies the stream ID is connected to the connection level flow control is blocked.
CONGESTION_FEEDBACK Frame | congestion feedback frame
The CONGESTION_FEEDBACK frame is an experimental frame currently not used. It is intended to provide extra congestion feedback information outside the scope of the standard ack frame. A CONGESTION_FEEDBACK frame must have the first three bits of the Frame Type set to 001. The last 5 bits of the Frame Type field are reserved for future use.
A frame experimental nature is not currently being used when congestion feedback frame. Additional object is to provide congestion feedback information in addition to the standard range ack frame. Congestion feedback frame a frame header 3bit type must be set to 001, the 5bit reserved for future use.
PADDING Frame | filling frame
The PADDING frame pads a packet with 0x00 bytes. When this frame is encountered, the rest of the packet is expected to be padding bytes. The frame contains 0x00 bytes and extends to the end of the QUIC packet. A PADDING frame only has a Frame Type field, and must have the 8-bit Frame Type field set to 0x00.
A filling frame 0x00 byte padding packet. When filling frame encountered, the remainder of the package is filled frames. Fill frames containing bytes of 0x00, and the end of the filled package QUIC. 8bit filling frame size is set to only one frame type field of 0x00.
RST_STREAM Frame | stream reset frame
The RST_STREAM frame allows for abnormal termination of a stream. When sent by the creator of a stream, it indicates the creator wishes to cancel the stream. When sent by the receiver of a stream, it indicates an error or that the receiver did not want to accept the stream, so the stream should be closed. The frame is as follows:
Stream reset frame for closing a flow abnormality. When sent by the creator of the stream, it identifies the creator wish to cancel this stream. When the stream sent by the receiving end, identifying an error or a receiver does not want to accept the stream, so that the stream should be closed. This frame format is as follows:
--- src
0 1 4 5 12 8 16
+-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+
|Type(8)| StreamID (32 bits) | Byte offset (64 bits)| Error code (32 bits)|
+-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+
---The fields in a RST_STREAM frame are as follows:
Frame type: The Frame Type is an 8-bit value that must be set to 0x01 specifying that this is a RST_STREAM frame.
Stream ID: The 32-bit Stream ID of the stream being terminated.
Byte offset: A 64-bit unsigned integer indicating the absolute byte offset of the end of data for this stream.
Error code: A 32-bit QuicErrorCode which indicates why the stream is being closed. QuicErrorCodes are listed later in this document.
Field Meaning flow resets frame is as follows:
- Frame type: 8bit, it must be set to 0x01.
- Stream ID: 32bit, closed flow ID.
- Byte offset: the absolute end of the data bytes on 64bit unsigned integer that identifies the offset of flow.
- Error code: 32bit error code identifies why the stream was closed. Error code defined in the subsequent portion of the document.
PING frame | PING帧
The PING frame can be used by an endpoint to verify that a peer is still alive. The PING frame contains no payload. The receiver of a PING frame simply needs to ACK the packet containing this frame. The PING frame should be used to keep a connection alive when a stream is open. The default is to do this after 15 seconds of quiescence, which is much shorter than most NATs time out. A PING frame only has a Frame Type field, and must have the 8-bit Frame Type field set to 0x07.
PING frame used to verify whether the peer still alive. PING no load information. PING frame receiving end need to return an acknowledgment packet in the packet. When the stream is opened, PING frames needed to ensure that the connection active. After resting 15 seconds to send the default, which is more than most of the NAT timeout period is much shorter. PING frame only frame type field, 8bit frame type must be set to 0x07.
CONNECTION_CLOSE frame | Connection closed frame
The CONNECTION_CLOSE frame allows for notification that the connection is being closed. If there are streams in flight, those streams are all implicitly closed when the connection is closed. (Ideally, a GOAWAY frame would be sent with enough time that all streams are torn down.) The frame is as follows:
Connection closed frame for notifying the connection is closed. If there is a transmission stream, all of these streams are implicitly closed (in theory, a GOAWAY frame may be sent off to leave sufficient time for all streams). Frame format is as follows:
--- src
0 1 4 5 6 7
+--------+--------+-- ... -----+--------+--------+--------+----- ...
|Type(8) | Error code (32 bits)| Reason phrase | Reason phrase
| | | length (16 bits)|(variable length)
+--------+--------+-- ... -----+--------+--------+--------+----- ...
---The fields of a CONNECTION_CLOSE frame are as follows:
Frame Type: An 8-bit value that must be set to 0x02 specifying that this is a CONNECTION_CLOSE frame.
Error Code: A 32-bit field containing the QuicErrorCode which indicates the reason for closing this connection.
Reason Phrase Length: A 16-bit unsigned number specifying the length of the reason phrase. This may be zero if the sender chooses to not give details beyond the QuicErrorCode.
Reason Phrase: An optional human-readable explanation for why the connection was closed.
The connection is closed frame fields have the following meanings:
Frame type: 8bit, it must be set to 0x02
Error Code: 32bit, the close link identification error reason code
description information length: 16bit unsigned number, the identification information described length. 0 If the sender may not require that give more detailed information on the error code
description information: an optional field, for the reasons explained readable string of connected closed
English description link
QUIC Wire Layout Specification - Google 文档
Author: yoko
This link: http://www.pengrl.com/p/47156/
Disclaimer: All articles in this blog unless otherwise specified, are used CC BY-NC-SA 3.0 license. Please indicate the source!