Unveiling HTTP/2: How HTTP/2 establishes a connection

[[285457]]

Preface

The Hypertext Transfer Protocol (HTTP) is a very successful protocol. However, HTTP/1.1 uses several features of the underlying transport that negatively impact the performance of today's applications.

In particular, HTTP/1.0 allows only one request to be outstanding at a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addresses request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to the server to achieve concurrency and thus reduce latency.

[[285458]]

Additionally, HTTP header fields are often repeated and lengthy, causing unnecessary network traffic and causing the initial TCP (https://tools.ietf.org/html/rfc7540#ref-TCP) congestion window to fill up quickly. This can cause excessive latency when multiple requests are made on a new TCP connection.

HTTP/2 addresses these issues by defining an optimized HTTP semantics that maps to the underlying connection. Specifically, it allows interleaving of request and response messages on the same connection and uses efficient encoding of HTTP header fields. It also allows prioritization of requests, allowing more important requests to complete faster, further improving performance.

HTTP/2 is more network-friendly because fewer TCP connections can be used compared to HTTP/1.x. This means less competition with other traffic and long connections, which in turn allows for better utilization of available network capacity. Finally, HTTP/2 can also process messages more efficiently by using binary message frames.

HTTP/2 is compatible with the original behavior of HTTP/1.1 to the greatest extent possible:

1. Modify the application layer based on and fully exploit the performance of the TCP protocol.

2. The model of the client sending a request to the server has not changed.

3. The scheme has not changed, there is no http2://

4. Clients and servers using HTTP/1.X can be seamlessly transferred to HTTP/2 through proxy.

5. Proxy servers that do not recognize HTTP/2 can downgrade requests to HTTP/1.X.

HTTP/2 Protocol Overview

HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supports all the core features of HTTP/1.1, but is designed to be more efficient in several ways.

The basic protocol unit in HTTP/2 is a frame. Each frame type has a different purpose. For example, HEADERS and DATA frames form the basis of HTTP requests and responses; other frame types (such as SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE) are used to support other HTTP/2 features.

HTTP/2 is a completely binary protocol. Both header information and data packet bodies are binary, collectively referred to as "frames". Compared with HTTP/1.1, in HTTP/1.1, header information is text-encoded (ASCII encoding), and data packet bodies can be either binary or text. The benefit of using binary as a protocol implementation method is that it is more flexible. 10 different types of frames are defined in HTTP/2.

Request multiplexing is achieved by associating each HTTP request/response exchange with its own stream. The streams are largely independent of each other, so a blocked or stalled request or response does not prevent other streams from communicating.

Since HTTP/2 data packets are sent out of order, responses to different requests may be received in the same connection. Different data packets carry different tags to identify which response they belong to.

HTTP/2 calls each request and response data packet a data stream. Each data stream has its own globally unique number. Each data packet needs to be marked with which data stream ID it belongs to during transmission. It is stipulated that the ID of the data stream sent by the client is always odd, and the ID of the data stream sent by the server is even.

At any time during the data flow, the client and server can send a signal (RST_STREAM frame) to cancel the data flow. In HTTP/1.1, the only way to cancel the data flow is to close the TCP connection. HTTP/2 can cancel a request while ensuring that the TCP connection is still open and can be used by other requests.

Flow control and prioritization ensure that multiplexed streams can be used efficiently. Flow control helps ensure that only data that the receiver can consume is transmitted. Prioritization ensures that limited resources are directed to the most important streams first.

HTTP/2 adds a new interaction mode where the server can push responses to the client. Server push allows the server to speculatively send data to the client that the server predicts the client will need, offsetting potential latency by sacrificing some network traffic. The server does this by synthesizing a request and sending it as a PUSH_PROMISE frame. The server is then able to send the response to the synthesized request on a separate stream.

Since the HTTP header fields used in a connection can contain a lot of redundant data, the frames containing them are compressed. Allowing many requests to be compressed into a single packet has a particularly beneficial effect on typical request sizes.

HTTP protocol does not have state, and all information must be attached to each request. Therefore, many fields in the request are repeated, such as Cookie and User Agent. Even if the content is exactly the same, each request must still carry it every time, which wastes a lot of bandwidth and affects the speed. Although HTTP/1.1 can compress the request body, it cannot compress the message header. Sometimes the message header is very large.

HTTP/2 optimizes this by introducing a header compression mechanism. On the one hand, the header information is compressed using gzip or compress before being sent; on the other hand, the client and server simultaneously maintain a header information table, in which all fields are stored and an index number is generated. In the future, the same field will not be sent, only the index number will be sent, which increases the speed.

Header compression may improve the response rate by about 95%. The average response header size of HTTP/1.1 is about 500 bytes, while the average response header size of HTTP/2 is only more than 20 bytes, which is a significant improvement.

The following four sections discuss HTTP/2 in detail.

Unveiling HTTP/2: How HTTP/2 establishes a connection

The framing and streaming layers describe the structure of HTTP/2 frames and how to form multiplexed streams.

The framing and errors definitions include details about the framing and error types used in HTTP/2.

The HTTP mapping and additional requirements describe how HTTP semantics are expressed using frames and streams.

Although some framing and stream layer concepts are isolated from HTTP, this specification does not define a completely general framing layer. The framing and stream layers are customized to the needs of the HTTP protocol and server push.

Starting HTTP/2

HTTP/2 connection is an application layer protocol running on top of TCP connection. The client is the TCP connection initiator.

HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1. HTTP/2 shares the same default port numbers: 80 for "http" URIs and 443 for "https" URIs. Therefore, an implementation that needs to handle a request for a target resource URI (such as "http://example.org/foo" or "https://example.com/bar") first needs to discover whether the upstream server (the direct peer to which the client wishes to establish a connection) supports HTTP/2.

1. HTTP/2 Version Identification

The protocol defined in this document has two identifiers.

• The string "h2" identifies the HTTP/2 protocol using Transport Layer Security (TLS) TLS12. This identifier is used in the TLS Application Layer Protocol Negotiation (ALPN) extension TLS-ALPN field and anywhere else HTTP/2 over TLS is identified.

The "h2�" string is serialized as the ALPN protocol identifier as a two-octet sequence: 0x68,0x32.

• The string "h2c" identifies a protocol running HTTP/2 over clear text TCP. This identifier is used in the HTTP/1.1 Upgrade header field and anywhere HTTP/2 over TCP is identified.

The "h2c" string is reserved from the ALPN identifier space, but describes a protocol that does not use TLS. Negotiating "h2" or "h2c" implies using the transport, security, framing, and message semantics described in this document.

2. Starting HTTP/2 for "http" URIs

A client that requests an "http" URI without prior knowledge that the next hop supports HTTP/2 uses the HTTP Upgrade mechanism (Section 6.7 of [RFC7230]). The client does this by issuing an HTTP/1.1 request that includes an Upgrade header field with the "h2c" flag. Such an HTTP/1.1 request MUST include an HTTP2-Settings (Section 3.2.1) header field.

For example:

GET / HTTP/1.1

Host: server.example.com

Connection: Upgrade, HTTP2-Settings

Upgrade: h2c

HTTP2-Settings:

Before the client can send HTTP/2 frames, the request including the payload body must be sent in its entirety. This means that large requests can block use of the connection until they are fully sent.

If concurrency of the initial request with subsequent requests is important, an upgrade to HTTP/2 can be performed using an OPTIONS request, at the cost of an extra round trip. A server that does not support HTTP/2 can respond to the request as if there were no Upgrade header field:

HTTP/1.1 200 OK

Content-Length: 243

Content-Type: text/html

...

Servers MUST ignore the "h2" token in the Upgrade header field. The presence of a token with "h2" implies HTTP/2 over TLS, which replaces the negotiation process described in Section 3.3.

A server that supports HTTP/2 accepts the upgrade via a 101 (Switch Protocols) response. After the empty line at the end of the 101 response, the server MAY begin sending HTTP/2 frames. These frames MUST include a response to the request that initiated the upgrade.

For example:

HTTP/1.1 101 Switching Protocols

Connection: Upgrade

Upgrade: h2c

[HTTP/2 connection ...

The first HTTP/2 frame sent by the server MUST be a server connection prelude consisting of a SETTINGS frame. After receiving a 101 response, the client MUST send a connection prelude, which includes a SETTINGS frame.

HTTP/1.1 requests sent prior to the upgrade are given stream identifier 1 (see Section 5.1.1), which is the default priority value (Section 5.3.5). Stream 1 is implicitly "half-closed" from the client to the server (see Section 5.1), because the request is completed as an HTTP/1.1 request. After starting an HTTP/2 connection, stream 1 is used for responses.

3. HTTP2-Settings Header Field

Requests to upgrade from HTTP/1.1 to HTTP/2 MUST include an "HTTP2-Settings" header field. The HTTP2-Settings header field is a connection-specific header field that contains parameters for managing HTTP/2 connections, and is provided if the server accepts the upgrade request.

 HTTP2-Settings = token68

If this header field is not present or multiple connections are present, the server MUST NOT upgrade the connection to HTTP/2. The server MUST NOT send this header field.

The content of the HTTP2-Settings header field is the payload of the SETTINGS frame, encoded as a base64url string (i.e., the URL- and filename-safe Base64 encoding described in Section 5 of [RFC4648], omitting any trailing '=' characters). ABNF RFC5234 (RFC5234: https://tools.ietf.org/html/rfc5234) generates "token68" as defined in Section 2.1 of [RFC7235].

Since the upgrade is only intended for immediate connections, a client sending an HTTP2-Settings header field MUST also send "HTTP2-Settings" as a connection option in the Connection header field to prevent it from being forwarded.

The server decodes and interprets these values ​​just like any other SETTINGS frame. It is not necessary to explicitly confirm these settings, as the 101 response serves as an implicit confirmation. The purpose of providing these values ​​in the Upgrade request is to give the client a chance to provide the parameters before receiving any frames from the server.

4. Starting HTTP/2 for "https" URIs

Clients making requests to "https" URIs use TLS TLS12(https://tools.ietf.org/html/rfc7540#ref-TLS12) and the Application Layer Protocol Negotiation (ALPN) extension TLS-ALPN(https://tools.ietf.org/html/rfc7540#ref-TLS-ALPN).

HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS.

Once TLS negotiation is complete, both the client and server must send a connection prelude.

5. Starting HTTP/2 with Prior Knowledge

There are other ways for a client to learn whether a particular server supports HTTP/2. For example, ALT-SVC describes a mechanism by which a client can learn whether a server supports HTTP/2.

The client MUST send a connection prelude, and may immediately send HTTP/2 frames to the server; servers MAY recognize these connections by the presence of the connection prelude. This only affects HTTP/2 connections established over plaintext TCP; implementations supporting HTTP/2 over TLS MUST use protocol negotiation in TLS TLS-ALPN. Likewise, the server MUST send a connection prelude.

Without additional information, prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections. For example, the server configuration could change, making the configuration different between instances in a cluster, or network conditions could change.

6. HTTP/2 Connection Preface

"Connection prelude" is also translated as "connection preface" in some places.

In HTTP/2, each endpoint needs to send a connection prelude as a final confirmation of the protocol being used and to establish the initial setup of the HTTP/2 connection. The client and server each send a different connection prelude.

The client connection prelude begins with a sequence of 24 octets, in hexadecimal notation:

 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

That is, the connection prelude begins with the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n". This sequence MUST be followed by a SETTINGS frame, which MAY be empty. The client sends the client connection prelude immediately after receiving a 101 (Switch Protocols) response (indicating a successful upgrade) or as the first application data octet of a TLS connection. If an HTTP/2 connection is initiated with prior knowledge of the server's support for the protocol, the client connection prelude is sent when the connection is established.

NOTE: The client connection prelude is chosen so that most HTTP/1.1 or HTTP/1.0 servers and middleware do not attempt to process further frames. Note that this does not address the issue raised in TALKING.

The strings in the prelude are connected to form PRISM, which means "Prism", which is the "Prism Project" revealed by Snowden in 2013.

The server connection prelude consists of a possibly empty SETTINGS frame, which MUST be the first frame sent by the server in an HTTP/2 connection.

A SETTINGS frame received from a peer as part of the connection prelude MUST be acknowledged after the connection prelude was sent.

To avoid unnecessary delays, a client is allowed to send additional frames to a server immediately after sending a client connection prelude, without waiting to receive a server connection prelude. However, it is important to note that the server connection prelude SETTINGS frame may contain parameters that are required by the client if it wishes to communicate with the server. Upon receiving a SETTINGS frame, the client SHOULD adhere to any parameters established. In some configurations, the server MAY send SETTINGS before the client sends additional frames, providing an opportunity to avoid this problem.

Clients and servers MUST treat an invalid connection preamble as a connection error of type PROTOCOL_ERROR. The GOAWAY frame MAY be omitted in this case, since an invalid connection preamble indicates that the peer is not using HTTP/2.

Finally, let's capture packets to see how HTTP/2 over TLS establishes a connection. After the TLS handshake is completed (the TLS handshake process is temporarily omitted here), the client and server have negotiated through ALPN that the application layer will use the HTTP/2 protocol for communication, so you will see a packet capture diagram similar to the following:

You can see that after the TLS 1.3 Finished message, the HTTP/2 connection preface, the Magic frame, follows.

The client connection prelude begins with a sequence of 24 octets, in hexadecimal notation:

 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

The connection prelude starts with the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n". The Magic frame is followed by the SETTINGS frame. When the server successfully acks this message and there is no connection error, the HTTP/2 protocol connection is considered established.