为什么流标识符在HTTP/2中为31位，为什么在其前面保留位? [英] Why is the stream identifier 31 bit in HTTP/2 and why is it preceded with a reserved bit?
问题描述
HTTP/2中的帧格式如下所示(来源: HTTP/2:帧格式):
The frame format in HTTP/2 looks like this (source: HTTP/2: Frame Format):
+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
R : 保留的1位字段.该位的语义是不确定的，发送时必须保持未设置状态(0x0)，接收时必须忽略.
R: A reserved 1-bit field. The semantics of this bit are undefined, and the bit MUST remain unset (0x0) when sending and MUST be ignored when receiving.
流标识符:(请参见第5.1.1节)表示为无符号的31位整数.值0x0保留用于与整个连接相关联的帧，而不是单个流.
Stream Indentifier: A stream identifier (see Section 5.1.1) expressed as an unsigned 31-bit integer. The value 0x0 is reserved for frames that are associated with the connection as a whole as opposed to an individual stream.
为什么没有使用32位无符号整数?以及为什么指定保留位必须设置为0并且必须被接收器忽略?
Is there a reason why they did not use a 32-bit unsigned integer? And why specifying that a reserved bit has to be set to 0 and must be ignored by the receiver?
这仅仅是对Java之类的让步，因为Java没有32位无符号整数?
Is it just a concession to languages like Java, which do not have a 32-bit unsigned integer?
推荐答案
此处讨论: https://github.com/http2/http2-spec/issues/67
目的是进行流优先级的实验.
Purpose is for experimentation with stream reprioritization.
http://lists.w3.org /Archives/Public/ietf-http-wg/2013AprJun/0135.html
还可以防止某些实现出现问题 有签名还是无签名
Also there to protect against some implementations having problems with signed vs. unsigned
在汉堡讨论；有多种用例，无需删除 (现在).
Discussed in Hamburg; are a variety of use cases, no need to remove (now).
这篇关于为什么流标识符在HTTP/2中为31位，为什么在其前面保留位?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
