HTTP/2 Frame of note

Zero. Objective

Client and server side once the handshake negotiation is successfully established, the Exchange frame data can be passed between endpoints based on the HTTP/2 protocol.

One. Frame General format

Common format for HTTP/2 frame: frame header + load bit common structure:

+-----------------------------------------------+|                Length                    |+---------------+---------------+---------------+|  Type (8)     |  Flags (8)    |+-+-------------+---------------+-------------------------------+| r|                Stream Identifier (|+=+=============================================================+|)                  Frame Payload (0 ...)                       ...+---------------------------------------------------------------+

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

• Frame Length: Unsigned natural number, 24 bits, representing only the number of bytes occupied by the frame payload, excluding 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 A bit, defines the specific format of the frame payload and the semantics of the frame, the HTTP/2 specification defines 10 frame types, which do not include the test type frame and the extension type frame
• frame of the flag bit flags:8 bit representation, serving the specific frame type , 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 this may be set flag bit
• frame reserved bit r: Reserved bit in HTTP/2 context, fixed value is 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

Two. Packet header compression and decompression

As with HTTP/1, the HTTP/2 header field contains one or more related key-value pairs. The header fields are used in HTTP request/Response headers and server push operations. Originally a text field, it now needs to be serialized into a header block using HTTP header compression, which is transmitted as a load of headers, push_promise, continuation, and so on.

The Hpack protocol used for decompression is available for reference: http://http2.github.com/http2-spec/compression.html

The receiving side merges the received frames into a header block, extracting the restored header collection.

A complete header block contains:-a single HEADERS, push_promise frame that contains a header termination tag end_headers, or a push_promise tag that HEADERS, end_headers frames do not contain, Follow one or more continuation frames, and the last continuation frame contains the end_headers tag.

Header compression is stateful, in a complete connection, one side of the compression context, the other side of the decompression context, are required. The header decoding failure needs to be treated as a connection error compression_error.

The header blocks are separated from each other, as consecutive frame sequences of the same type exist, there are no interlaced frames, and from other types of frames or streams. For example, a sequential headers/continuation/push_promise frame sequence, the last frame contains the end_headers tag, indicating the end of a header. A header block is logically a frame, but whether it is complete depends on the last containing the end_headers tag of the same type continuous frame.

The header block is sent to the other end as a headers/push_promise/continuation frame load. The receiving end needs to assemble the header block from the headers/push_promise/continuation and other frame loads, performing the extract and restore header collection, regardless of the frame needs not to be discarded. If the receiver is not able to decompress the header block properly during decompression, it needs to respond to the COMPRESSION_ERROR error and terminate the connection.

Three. HTTP/2 defined Frames

The specification defines 10 formally used to the frame type, expands the experiment type ALTSVC, blocked and so on not to introduce the column. The following reordering is sorted in order of precedence.

1. SETTINGS

+-----------------------------------------------+|                Length                    |+---------------+---------------+---------------+|     0x4 (8)   | 0000 000? (8) |+-+-------------+---------------+-------------------------------+| r|                Stream identifier/0x0 (+)                   |+=+=============================+===============================+|       Identifier (+)         |+-------------------------------+-------------------------------+|                        Value (+)                             |+---------------------------------------------------------------+|       Identifier (+)         |+-------------------------------+-------------------------------+|                        Value (+)                             |+---------------------------------------------------------------+  

Set the frame, the receiver advertises to the sender the setting, the server side must first send the frame after the connection succeeds.

The field identifier defines the following parameters:-Settings_header_table_size (0x1), notifies the recipient Header table of the maximum number of bytes, the header block decoding is used, the initial value is 4,096 bytes, the default is not set-settings_ Enable_push (0x2), 0: Prohibit server push, 1: Allow push, other value illegal, protocol_error error-Settings_max_concurrent_streams (0x3), sender allowed to open the maximum value of the stream, Recommended value 100, the default is not set, 0 value is forbidden to create a new stream-settings_initial_window_size (0x4), the sender of the Flow control window size, the default value of 2^16-1 (65,535) byte size, the maximum value is 2^31-1 bytes size, If the overflow needs to report flow_control_error error-Settings_max_frame_size (0x5), the maximum single frame load, the default is 2^14 (16384) bytes, both ends of the sent frame will receive this setting effect; The value interval is 2^ (16384) -2^24-1 (16777215)-Settings_max_header_list_size (0x6), the sender advertises the maximum number of header collections that it is prepared to receive, that is, bytes. This value is dependent on the uncompressed header field, including the field name, field value, and the cost of 32 bytes per header field, etc., although the default value is not limited, because the size of the header collection is not limited, personally think not more than 2 settings_max_frame_ SIZE (ie 2^142=32768), otherwise the Baotou is too big, hidden trouble.

Flag bit: * ACK (0x1), indicating that the receiver has received a setting frame, as a confirmation must be set this flag bit, when the load is empty, otherwise you need to report frame_size_error error

Note:-The settings frame must be allowed to be sent at the start of the connection, but not necessarily sent-you can allow any end point to be sent during the lifetime of the connection-the receiver does not need to maintain the state of the parameter, just record the current value-the settings frame is used only for the current connection, not for a single stream. So the stream identifier is 0x0-incomplete or non-canonical settings frames need to throw protocol_error type connection errors-the number of payload bytes is a multiple of 6 bytes, 6*n (n>=0)

Process flow:-Send side to send the need to carry a settings set of frames, can not be with the ACK flag bit-the receiver received no ACK flag bit settings frame, must be processed in the order of the field in the frame, the middle can not handle the other frame-receive side processing, For unsupported parameters to be ignored-after the receiver has finished processing, it must respond to a settings frame with ACK Acknowledgement flag, no payload, a settings frame for the sender to receive the acknowledgement, indicating that both ends are in effect-the sending side waits for confirmation if the timeout is reported Settings_ Timeout Type connection error

2. HEADER

 +-----------------------------------------------+|    Length |+---------------+---------------+---------------+| 0x1 (8) | 00?0?? 0? (8) |+-+-------------+---------------+-------------------------------+|                r| Stream Identifier (31) |+=+=============+===============================================+| Pad Length? (8) |+-+-------------+-----------------------------------------------+|                 e| Stream Dependency?  (+) |+-+-------------+-----------------------------------------------+| Weight?                   (8) |+-+-------------+-----------------------------------------------+|                           Header Block Fragment (*) ... +---------------------------------------------------------------+| Padding (*) ... +---------------------------------------------------------------+

The primary carrier of the header, the request header, or the response header, is also used to open a stream that can be sent in the stream when the "open" or remote half-shutdown "half closed" state is available.

Field List:-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 the flow priority is set-stream dependency:31 bits represents the flow dependency, only valid when the flow priority is set Weight:8 bits (one byte) represent an unsigned natural number stream priority, and the range of values is naturally (1~256), or weights. Valid only when flow priority is set-header block Fragment: Header block Shard-Padding: filled bytes, subject to padded flag control whether displayed, length determined by pad length field

Required flag bit: end_stream (0x1): the header block is the last, which means the end of the stream. Subsequent to the continuation frame in the current stream, the continuation frame needs to be treated as part of the HEADERS frame end_headers (0x4): This header frame does not need to be fragmented, a complete 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 filled Priority (0x20): Precedence flag bit, control independent flag bit E, flow dependency, and flow weight.

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

3. Continuation

+-----------------------------------------------+|                Length                    |+---------------+---------------+---------------+|  0x9 (8)      |  0x0/0x4  (8) |+-+-------------+---------------+-------------------------------+| r|                Stream Identifier (+)                       |+=+=============================================================+|                  Header Block Fragment (*)                    |+---------------------------------------------------------------+

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

Note:-A headers/push_promise frame followed by 0 or more continuation, as long as the previous frame is not set end_headers flag bit, it does not count the end of a frame complete data. -The receiver handles this situation, 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 headers/push_promise (no End_ Headers flag bit) 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.

4. DATA

One or more data frames as the request, response content vector, the more complete structure is as follows:

+-----------------------------------------------+|                Length                    |+---------------+---------------+---------------+| 0x0 (8)       | 0000? 00? (8) |+-+-------------+---------------+-------------------------------+| r|                Stream Identifier (|+=+=============+===============================================+|)                       Pad Length? (8) |+---------------+-----------------------------------------------+|                            Data (*)                         ... +---------------------------------------------------------------+|                          Padding? (*)                       ...+---------------------------------------------------------------+

Field: Pad length: A byte indicates the size of the padding. Depends on whether the padded flag is set. data: Here is the application, and the true size needs to be subtracted from the length of other fields (such as padding length and padding content). * Padding: Padding content is a number of 0x0 bytes, controlled by the padded flag is displayed. Validation padding can be ignored when receiving-side processing. If verified, the response Protocol_error type connection exception can be populated for non-0x0 content.

Flag bit: end_stream (0x1): Flag This frame is the last frame of the corresponding flag stream, and the stream enters a semi-closed/closed state. Padded (0x8): Load needs to be filled, Padding Length + Data + Padding composition.

Note:-If the stream identifier is 0x0, the receiver needs to respond to the Protocol_error connection error-the data frame can only be sent when the stream is in the "open" or "half Closed (remote)" State, otherwise the receiving end must respond to a STREAM_ Closed a connection error. If the fill length is not less than the payload length, the receiving end must respond to a PROTOCOL_ERROR connection error.

5. Push_promise

 +-----------------------------------------------+|  Length |+---------------+---------------+---------------+| 0x5 (8) | 0000?? XX (8) |+-+-------------+---------------+-------------------------------+|                r| Stream Identifier (32) |+=+=============================================================+| Pad Length? (8) |+-+-------------+-----------------------------------------------+|                r|                  Promised Stream ID (|+-+)-------------------------------------------------------------+|                           Header Block Fragment (*) ... +---------------------------------------------------------------+| Padding (*) ... +---------------------------------------------------------- -----+

Server-side notification-to-end initialization a new push stream is ready to push the data later:-requires that the push stream be open or remote semi-closed (half closed (remote)) state, otherwise the Protocol_error error is reported:-The promised stream does not have to be used in the order in which it flows open, Used only later-the SETTINGS_ENABLE_PUSH flag bit set by the peer determines whether or not to send, otherwise treated as a protocol_error error-the receiving side once refused to receive push, will send rst_stream frame to inform the other side push invalid

Field List:-promised stream id,31 bits represents an unsigned natural number, a stream identifier for push retention, followed by sending push data-header Block Fragment, request header field value, can be seen as a server-side impersonation client initiating a resource request

Flag bit: end_headers (0x4/00000010), this frame contains the complete header block, without following the continuation frame padded (0x8/00000100), fill the switch, decided the following pad Length and padding whether to fill, concrete and headers frame content consistent, not much to say

6. PING

A priority frame with a type value of 0x6,8 bytes. The sender measures the minimum round trip time, and the heartbeat mechanism is used to detect if an idle connection is valid.

+-----------------------------------------------+|                0x8 (                       |+---------------+---------------+---------------+|  0x6 (8)      | 0000 000? (8) |+-+-------------+---------------+-------------------------------+| r|                          0x0 (+)                           |+=+=============================================================+|                        Opaque Data (+)                       |+---------------------------------------------------------------+

Field List:-Opaque data:8 bytes of load, value is freely filled in.

Flag bit: * ACK (0x1): Once set, indicates that this ping frame is a ping frame for the recipient response, not the sender.

Note:-Ping frame Sender ACK flag bit is 0x0, receiver response ping frame ACK flag bit is 0x1. Otherwise, it is discarded directly. Its priority is higher than other types of frames. -The ping frame is not associated with a specific stream, and if the stream identifier is 0x0, the receiver needs to respond to the Protocol_error type connection error. -The receiver needs to respond to Frame_size_error type connection errors beyond the load length.

7. Priority

A priority frame with a type value of 0x2,5 bytes. Suggested values that express the sender's convection priority weights can be sent in any state of the stream, including idle or closed streams.

+-----------------------------------------------+|                   0x5 (                    |+---------------+---------------+---------------+|   0x2 (8)     |    0x0 (8)    |+-+-------------+---------------+-------------------------------+| r|                  Stream Identifier (|+=+=============================================================+|)                     e|                  Stream Dependency                     |+-+-------------+-----------------------------------------------+| Weight (8)    |+---------------+

Field List:-E: Stream is independent-stream Dependency: Stream dependent, value is the identifier of the stream, which is naturally also represented by 31 bits. -Weight: Weight/priority, one byte representing natural number, range 1~256

Note:-priority frames whose stream identifier is 0x0, the receiver needs to respond to a connection error of type Protocol_error. -The priority frame can be sent in any state of the stream, but the limit is not able to appear in a continuous frame containing a header block, its sending time is required, if the stream has ended, although it can be sent, but has no effect. -More than 5 bytes of priority frame Receiver response Frame_size_error type stream error.

8. Window_update

+-----------------------------------------------+|                0x4 (                       |+---------------+---------------+---------------+|   0x8 (8)     |    0x0 (8)    |+-+-------------+---------------+-------------------------------+| r|                Stream Identifier (|+=+=============================================================+|)                       r|              Window Size Increment                     |+-+-------------------------------------------------------------+

Flow control frames, which are used for a single stream as well as an entire connection, but only affect the data frames transferred between the two endpoints. Be aware, however, that the mediation does not forward this frame.

Field List:-Window Size increment,31 bit unsigned natural number, in the range of 1-2^31-1 (2,147,483,647) bytes, indicating the maximum number of bytes a sender can send, and the maximum number of bytes a recipient can receive.

Note:-Current flow control only affects the data frame-stream identifier is 0, affecting the entire connection, not a single stream-stream identifier is not empty, the specific stream identifier, will only affect the specific flow-window_update in some carry End_ After the stream frame is sent (the current stream is closed or the remote shutdown state), the receiver can be ignored but cannot be treated as an error-the sender cannot send a window value greater than the window_update frame that the receiver has held (the receiver already has a flow-control window value) of the available space size- When the available space in the Flow control window is exhausted, the peer sends a 0 load data frame with the END_STREAM flag bit, which is allowed behavior-traffic control does not calculate 9 bytes of space occupied by the frame header-if the window value overflows, the response rst_ for a separate stream Stream (error code FLOW_CONTROL_ERROR) frame, response Goaway (error code FLOW_CONTROL_ERROR) frame for the entire connection-the receiver of the data data frame will need to calculate the available space for the consumed flow control window after it has received the frame. At the same time to send the latest available window space to the peer-to-data frame sender received the window_update frame, get the latest available window value-The receiver asynchronously updates the sender window value, avoid flow stop/stall-by default, the Traffic control window value is 65535, It will not change unless you receive the SETTINGS frame settings_initial_window_size parameter, or the window value size that is carried by the windows_update frame-Settings_initial_window_ A change in the size value causes the window to be free of space and is prone to problems, and the sender must stop sending the data frame that is affected by the flow control until it receives a new window value for the window_update frame. Eg: the client sends 60KB of data in a moment of connection establishment, but the initial window value from the server settings set frame is 16KB, the client can wait until the window_update frame tells the new window value, and then continue sending the remaining 44KB data- Settings frames cannot modify traffic control window values for an entire connection-any end point when processing the settings_initial_window_size value causes the Flow-control window value to exceed the maximum value as a Flow_control_ Error type connection wrong treatment

9. Rst_streawm

A priority frame with a type value of 0x3,4 bytes. The recommended value for the sender's convection priority weight is expressed, and any stream can be sent at any time, including idle or closed streams.

+-----------------------------------------------+|                0x4 (                       |+---------------+---------------+---------------+|  0x3  (8)     |  0x0 (8)      |+-+-------------+---------------+-------------------------------+| r|                Stream Identifier (|+=+=============================================================+|)                        Error Code (+)                        |+---------------------------------------------------------------+

Field List:-Error code: Error codes, 32-bit unsigned natural number indicates the reason the stream was turned off.

Note:-The Rst_stream frame is received and the corresponding stream needs to be closed, so the stream is also turned off. -The receiver is not able to send any frames on this stream. -The sending side needs to be prepared to receive a frame sent by the receiving end before the Rst_stream frame is received, and the frame of this void needs to be processed. -If the stream identifier is 0x0, the receiver needs to respond to the Protocol_error type connection error. -The Rst_stream frame cannot be sent when the stream is idle, otherwise the receiver will report a Prootocol_error type connection error.

Ten. Goaway

+-----------------------------------------------+|                Length                    |+---------------+---------------+---------------+|  0x7 (8)      |     0x0 (8)   |+-+-------------+---------------+-------------------------------+| r|                Stream Identifier (+)                       |+=+=============================================================+| r|                  Last-stream-id (+)                        |+-+-------------------------------------------------------------+|                      Error Code (|+)                          ---------------------------------------------------------------+|                  Additional Debug Data (*)                    |+---------------------------------------------------------------+

One end notifies the opposite end of the graceful way to stop creating the stream, while also completing the task that has previously established the flow.

• Once sent, the sender ignores the received stream identifier greater than last-stream-id any frame
• The receiver is not able to create a new stream on the current stream and creates a new connection if a new stream is created
• Can be used for server management behavior, such as the server into the maintenance phase, no longer ready to receive new connections
• Field Last-stream-id is the identifier of the sender taken from the last processing or already processed stream
• Subsequent creation of stream identifiers higher than Last-stream-id data frames will not be processed
• The terminal should be encouraged to send goaway implicitly before closing the connection to inform the other party whether certain streams have been processed
• Terminal can choose to close the connection, do not send the Goaway frame for the improperly behaved terminal
• Goaway applied to current connection, non-specific stream
• If no stream is processed, the Last-stream-id value can be 0, which is also legal
• Stream (identifier less than or equal to an existing numbered identifier) is not completely closed until the connection is closed, and a new connection needs to be created to retry
• The sending side also has some flow tasks that are not completed when sending Goaway, and will remain open until the task finishes
• The terminal can send multiple Goaway frames when the environment changes, but Last-stream-id does not allow growth
• Additional Debug Data has no semantics and is used only for online test diagnostics purposes. If you carry logging or persistent debug data, you need to have security assurances to avoid unauthorized access.

Four. The expansion of the frame

The extension of the HTTP/2 protocol is allowed to exist in the provision of additional services. Extensions include:-new type frames, need to conform to Universal frame format-New set parameters for setting new frame-related properties-new error codes, agreed frames may trigger errors

When defining a new frame, be aware of 1. The specification suggests that new extensions need to be negotiated before 1 can be used. Adds a new parameter item to the settings frame, which can be sent to the peer when the preamble is connected, or an appropriate opportunity to send 1. The two sides negotiated successfully and can use the new extension

Known altsvc, blocked belong to the extended frame.

1. Altsvc

The server provides an alternative service that is currently available to the client, similar to a CNAME, and the client does not support the available selection ignore

+-----------------------------------------------+|                Length                    |+---------------+---------------+---------------+|  0xa (8)      |     0x0 (8)   |+-+-------------+---------------+-------------------------------+| r|                Stream Identifier (+)                       |+=+=============================+===============================+|         Origin-len (+)       | Origin? (*)                 ...+-------------------------------+-------------------------------+|                   Alt-svc-field-value (*) ...                   +---------------------------------------------------------------+

Field List:-origin-len:16 bit integer, description of Origin field bytes-ORIGIN:ASCII string representation alternative service-Alt-svc-field-value: Contains alt-svc HTTP Header field, length =length-Origin-len (16)

Note:-The intermediary device cannot be forwarded to the client because the mediation itself replaces the processing, forwarding normal business data to the client.

For specific reference: https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06

2. BLOCKED

One end tells the other end that there is data but cannot be sent because it is controlled by traffic.

+-----------------------------------------------+|                Length                    |+---------------+---------------+---------------+|  0XB (8)      |     0x0 (8)   |+-+-------------+---------------+-------------------------------+| r|                Stream identifier/0x0 (+)                   |+=+=============================================================+

• Stream identifier If it is 0x0, it is for the entire connection, otherwise for a specific stream
• Cannot send blocked until the Traffic control window is in effect
• Once this problem is encountered, our implementation may be defective and the desired transfer rate cannot be obtained.
• Can only be sent before the window_update frame is received or the Settings_initial_window_size parameter is incremented

Five. Summary

The above records the HTTP/2 frame basic structure, 10 document-defined formal frames, and an additional two extended frames.

Original http://www.blogjava.net/yongboy/archive/2015/03/20/423655.html

HTTP/2 Frame of note