HTTP2 Frame Basics and information about header and continuation frames:

The HTTP2 was formally finalized on February 28, 2015 through an IETF organization approval release. The contents of it can be consulted: HTTP2 Overview http://www.cnblogs.com/ghj1976/p/4552583.html.

In HTTP2 network communication, frame is the smallest transmission unit in communication and contains at least one Frame header, which can indicate which Stream it belongs to. A specific request resembles the following:

HTTP/2 Frame General Format:

Bit-common structure of frame header + load:

The frame header is rendered as a fixed 9-byte ((24+8+8+1+31)/8=9), changing the frame's load (frame Payload), and the payload content is defined by the frame type (type).

• Length of frame: Unsigned natural number, 24 bits, represents only the number of bytes occupied by frame Payload, not including the 9 bytes occupied by the frame header.
  The default size interval is 0~16,384 (2^14), and once the default maximum value of 2^14 (16384) is exceeded, the sender is no longer allowed to send unless a receiver-defined settings_max_frame_size is received (typically this value interval is 2^14 ~ 2^ 24) Notification of the value.
• The frame type Type:8 bits, defines the frame payload specific format and the frame semantics, the HTTP/2 specification defines 10 frame types, here does not include the experiment type frame and the extension type frame
• The flag bit of the frame flags:8 a bit, serves the specific frame type, and the default value is 0x0.
  There is a little trick to note, generally speaking, 8 bits can hold 8 different flags, for example, padded value is 0x8, binary is represented as 00001000;end_headers value is 0x4, binary is expressed as 00000100;end_stream value is 0x1, Binary is 00000001. The three flags can be conveyed in one byte at the same time, and the binary is represented as 00001101, or 0x13. Therefore, in the subsequent frame structure, the flag bit will typically use 8 bits, if a bit is indeterminate, use a question mark instead, indicating that the flag bit may be set here
• Frame-Preserving bits R: Reserved bits in HTTP/2 context, with a fixed value of 0x0
• Stream identifier Stream Identifier: Unsigned 31-bit represents an unsigned natural number. A 0x0 value is expressed as a frame only for a connection, not to a separate stream.

With regard to frame length, a little attention is needed:-0 ~ 2^14 (16384) is the default contract length, all endpoints need to obey-2^14 (16,384) ~ 2^24-1 (16,777,215) This interval value, need receiver set settings_max_frame_ The SIZE parameter is assigned individually-one end receives a frame length exceeding the set limit or frame is too small to send a frame_size_err error-when the frame length error affects the entire connection state, it must be treated with a connection error, such as Headers,push_promise, Continuation,settings, and frame identifiers should not be 0 frames, and so on, need to do so-no one end of the obligation must use all the free space of a frame-large frames may cause delay, time-sensitive frames, such as Rst_stream, Window_ UPDATE, priority, need to be sent out quickly to avoid delays causing performance problems

The HTTP2 frame contains the following types, corresponding to the type region definition.

Frame Type      Code   
DATA            0x0
HEADERS         0x1
PRIORITY        0x2
RST_STREAM      0x3
SETTINGS        0x4
PUSH_PROMISE    0x5
PING            0x6
GOAWAY          0x7
WINDOW_UPDATE   0x8
CONTINUATION    0x9

Reference:
HTTP/2 frame Format
http://segmentfault.com/a/1190000002586816

The frame's flag bit (flags) means the following:

Figure from: http://search.cpan.org/~crux/Protocol-HTTP2-0.14/lib/Protocol/HTTP2/Frame.pm

Case:

Suppose we want to send a 0x12345678 with a stream number of 10 and a type of data, then the 16 binary representation of this frame is:

‘000004‘ + ‘00‘ + ‘00‘ + ‘0000000A‘ +   ‘12345678‘

Header Frame of HTTP2

The format of the header frame of the HTTP2 is as follows:

The corresponding field list is described below:
-Pad Length: Subject to the padded flag control is displayed, 8 bits indicates the number of bytes populated.
-E: A bit indicates whether the flow dependency is private, optional, only valid when flow priority is set
-Stream dependency:31 bits indicates flow dependency, only valid when flow priority is set
-Weight:8 bits (one byte) represents an unsigned natural number stream priority, and the value range is naturally (1~256), or weight. Valid only if flow priority is set
-Header block Fragment: Header chunk Shard
-Padding: Populated bytes, subject to padded flag control whether displayed, length determined by pad length field

Required flag:

End_stream (0x1): the header block is the last, which means the end of the stream. Subsequent continuation frames in the current stream require that the continuation frame be treated as part of the headers frame
End_headers (0x4): This header frame does not need to be fragmented, a full frame. Follow-up no longer need continuation frame help to gather. Without the header frame for this flag, subsequent frames must be passed in the current stream as continuation frames, otherwise the receiver needs to respond to a connection error of type Protocol_error.
Padded (0x8): Flags that need to be populated priority (0x20): Precedence flag bit, control independent flag bit E, flow dependency, and flow weight.

Precautions :
-its payload is the header block Shard, if the content is too large, need to use the continuation frame to continue transmission. If the stream identifier is 0x0, the end segment needs to return an PROTOCOL_ERROR connection exception. Headers frames contain priority information in order to avoid potential interference between different flows of priority order.
-in fact, in general, the message head is not very large, a headers can be completed, the special case is that the cookie field is more than 16KiB size, not common.

Continuation frame of HTTP2

The format of the HTTP2 continuation frame is as follows:

Field List:
-Header Block Fragment, used to assist headers/push_promise such as single frame cannot contain complete header remainder data.

Precautions:

-A headers/push_promise frame followed by 0 or more continuation, as long as the previous frame did not set the end_headers flag bit, it does not count the end of a frame complete data.
-Receive-side processing in this case, from the beginning of the headers/push_promise frame to the last containing the end_headers flag frame end, the merged data is considered a complete copy of the data
-In the middle of the headers/push_promise (no end_headers flag) and continuation frame, is not able to doping other frames, otherwise need to report protocol_error error

Flag bit: * End_headers (0X4): Represents the last frame of the header block, otherwise the continuation frame is followed.

Resources:

The message header in the HTTP2 protocol can be encoded using Haffman, and the message header information we see is binary information.

HTTP2 Message Format Please refer to: http://www.blogjava.net/yongboy/archive/2015/03/20/423655.html

Analysis of HTTP2 packet header and data frame format analytic example
http://blog.csdn.net/jiayanhui2877/article/details/45074315

Haffman compression algorithm Please refer to: http://coolshell.cn/articles/7459.html

HTTP2 Frame Basics and information about header and continuation frames: