Why is the stream identifier 31 bit in HTTP/2 and why is it preceded with a reserved bit?

问题

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: 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.

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.

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?

Is it just a concession to languages like Java, which do not have a 32-bit unsigned integer?

回答1:

Discussed here: 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).

来源：https://stackoverflow.com/questions/39309442/why-is-the-stream-identifier-31-bit-in-http-2-and-why-is-it-preceded-with-a-rese