标签：byte field form nal possibly xpl windows 声明 close
欢迎访问我的个人网站获取更好的阅读排版体验： [译] QUIC Wire Layout Specification - Frame Types and Formats | QUIC协议标准中文翻译(4) 帧类型和格式 | yoko blog (https://pengrl.com/p/47156/)
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的帧类型包由一个或多个帧组成。帧有一个字节大小的帧类型，有自己的类型解释，后面跟着该帧类型的字段。一个或多个帧只能包含在一个QUIC包中，没有帧可以跨越多个QUIC包。
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.
一共有两种帧类型：特殊帧类型和常规帧类型，它们的解析是不一样的。特殊帧类型在帧类型的字节中同时编码了帧类型和相应的标志位，而常规帧的帧类型字节只用来标识类型。
Currently defined Special Frame Types are:
当前定义的特殊帧类型有：
--- src
+------------------+-----------------------------+
| Type-field value | Control Frame-type |
+------------------+-----------------------------+
| 1fdooossB | STREAM |
| 01ntllmmB | ACK |
| 001xxxxxB | CONGESTION_FEEDBACK |
+------------------+-----------------------------+
---Currently defined Regular Frame Types are:
当前定义的常规帧类型有：
--- 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 |
+------------------+-----------------------------+
---The STREAM frame is used to both implicitly create a stream and to send data on it, and is as follows:
流类型帧用于隐式创建流和在流上发送数据，格式为：
--- 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.
流类型帧的头部字段含义如下：
A stream frame must always have either non-zero data length or the FIN bit set.
流类型帧必须是非0大小的数据长度或者设置了Fin标志。
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.
发送ACK帧用于通知对端哪些包已经被接收，换句话说，通知对端哪些包接收端没有收到（丢失包的内容可能需要重新发送）。ACK帧包含了1到256个ack块。ack块是已确认的包的区间，类似于TCP的SACK的块，但是不同于TCP的不可撤销的ack，因为QUIC重传时使用了新的包序号。
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.
为了限制对于那些对端还没有接收到的ACK的块，数据发送端周期性发送STOP_WAITING帧来通知接收端停止ack小于一个指定序号的包。使得接收端产生一个"最小还没ack"的包序号。于是ACK帧的发送者值需要报告那些最小还没ack与收到的最大序号之间的ACK块。建议ACK帧的发送者在ACK帧中发送最近最大已ack的包，就像STOP_WAITING帧的最小还没ack一样。
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.
不同于TCP的SACK，QUIC的ACK块是不可撤销的，如果一个包被ack了，那么即使它不再出现在之后的ACK帧中，依然认为它已经被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.
作为QUIC已弃用的熵信息的替代方案，发送端可以有意的跳过包序号来将熵信息注入连接中。发送端如果收到一个没有发送过的包序号对应的ack，应该关闭这个连接，这个机制可以自动预防任何潜在的攻击者。ack用于表示丢失包的块的格式是高效的。
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.
各区域偏移
0: ack帧的开始
T: 时间区域的偏移
A: ack块区域的偏移
N: 最大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.
ACK帧中的字段含义如下：
Largest Observed字段的长度，可以是1，2，4，6字节Missing Packet Sequence Number Delta字段的长度，可以是1，2，4，6字节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:
发送停止等待帧来通知对端不再等待小于指定包序号的包。包序号可以被编码为1，2，4，6字节。编码方式和QUIC帧类型包的公共标志中包序号字段一样。帧格式如下：
--- 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.
停止等待帧的字段含义如下：
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:
窗口更新帧用来告知对端本端的一次流量控制接收窗口的增长。流ID为0时标识这个窗口更新帧作用于连接层面的流量控制窗口，> 0标识一个指定的流需要增长它的流量控制窗口。这个帧如下定义：
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.
指定一个绝对的字节偏移，窗口更新帧的接收端可能在指定的流上最多发送指定的字节。违反流量控制发送更多的数据会导致数据接收端关闭这个连接。
On receipt of multiple WINDOW_UPDATE frames for a specific stream ID, it is only necessary to keep track of 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.
流和连接的窗口开始的默认值是16KB，但是一般会在握手阶段增长。为了达到这个效果，一端需要在握手阶段协商SFCW（流上的流量控制窗口）和CFCW（连接/会话上的流量控制窗口）参数。流层面和连接层面的初始窗口大小需分开指定。
帧格式如下：
--- 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.
窗口更新帧的字段含义如下：
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:
阻塞信息帧用来通知对端本端已经准备好发送数据（并且有数据需要发送），但是当前被流量控制所阻塞。这是一个对调试极其有用的纯信息帧。阻塞信息帧的接收者应该简单的把这个帧丢弃掉（比如再打印一条有用的日志信息之后）。帧格式如下：
--- 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.
阻塞信息帧中的字段含义如下：
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.
拥塞反馈帧时一个实验性质的帧当前没有被使用。目的是在标准的ack帧范围之外提供额外的拥塞反馈信息。拥塞反馈帧的帧类型的头3bit必须设置为001，后5bit保留用于未来使用。
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.
填充帧在包中填充一个0x00字节。当遇到了填充帧，该包的剩余部分都是填充帧。填充帧包含0x00的字节，并且填充在QUIC包的末尾。填充帧只有一个8bit大小设置为0x00的帧类型的字段。
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:
流重置帧用于异常关闭一个流。当由流创建者发送时，标识了创建者希望取消这个流。当由流接收端发送，标识了一个错误或者接收端不希望接受这个流，所以这个流应该被关闭。这个帧的格式如下：
--- 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.
流重置帧的字段含义如下：
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帧用于验证对端是否还存活。PING没有负载信息。PING帧的接收端需要返回这个包的确认包。当流被打开时，PING帧需要用来保证连接活跃。默认静止15秒后发送，这比大部分NAT超时的时间要短得多。PING帧只有帧类型字段，8bit的帧类型必须设置为0x07。
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:
连接关闭帧用于通知连接被关闭。如果还有流在传输，所有这些流都被隐式关闭（理论上，一个GOAWAY帧可以被发送以留有足够时间用于关闭所有流）。帧格式如下：
--- 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.
连接关闭帧的字段含义如下：
帧类型： 8bit，必须设置为0x02
错误码： 32bit，标识关闭链接原因的错误码
描述信息长度： 16bit无符号数，标识描述信息的长度。可以为0如果发送端认为在错误码之上不需要给出更详细的信息
描述信息： 可选字段，可读字符串用于解释连接关闭的原因
QUIC Wire Layout Specification - Google 文档
本文作者： yoko
本文链接： http://www.pengrl.com/p/47156/
版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！
[译] QUIC Wire Layout Specification - Frame Types and Formats | QUIC协议标准中文翻译(4) 帧类型和格式
标签：byte field form nal possibly xpl windows 声明 close
原文地址：https://www.cnblogs.com/notokoy/p/10994699.html
