The association between HTTP2 and HTTP3 versions.

1. Deficiencies of THE HTTP protocol (HTTP/1.1)

  1. One connection can only correspond to one request at a time (note: instead of establishing multiple connections, multiple requests can only be queued within one connection). Most browsers allow up to six concurrent connections for the same domain name.

  2. Only clients are allowed to initiate requests (request-reply mode, where only one request corresponds to one response).

  3. Headers are transmitted repeatedly in multiple requests for the same session. This typically adds 500 to 800 bytes of overhead per transfer. If cookies are used, the added overhead can sometimes reach thousands of bytes.

1.1. SPDY

SPDY (short for Speedy) is a TCP-based application layer protocol that enforces the use of SSL/TLS. In November 2009, Google announced SPDY as an internal project to speed up the web.

1.2. SPDY and HTTP

  • SPDY is not intended to replace HTTP, it just modifies the way HTTP requests and responses are transmitted
  • All existing server applications need not be modified by adding a SPDY layer
  • SPDY is a precursor to HTTP/2

In September 2015, Google announced that it was removing support for SPDY and embracing HTTP/2.

Second, the HTTP / 2

HTTP/2, officially released as RFC_7540 in May 2015. According to W3Techs, 36.5 percent of websites around the world support HTTP/2 as of June 2019.

HTTP/1.1 vs. HTTP/2: www.http2demo.io, https://http2.akam…

HTTP/2 has many improvements and optimizations in the underlying transport, but is fully semantics compatible with HTTP/1.1. For example, the request methods (GET, POST), Status Code, Headers, etc., have not changed, so to upgrade to HTTP/2, the developer does not need to change any Code, just upgrade the server configuration, and upgrade the browser.

Note: TLS is mandatory in SPDY, but the HTTP/2 documentation does not say that TLS is mandatory, but TLS is recommended for development.

2.1. Basic Concepts

Data stream: a bidirectional byte stream within an established connection that can carry one or more messages. All communication is done over a SINGLE TCP connection, which can host any number of two-way data streams at the same time.

Message: A sequence of frames corresponding to a logical HTTP request or response message.

Frame: The smallest unit of HTTP/2 communication. Each frame contains a frame header (which identifies the data stream to which the current frame belongs). Frames from different data streams can be sent interlaced and then reassembled according to the data stream identifier of each frame header.

2.2. Features of HTTP/2

2.2.1. Binary format

HTTP/2 transmits data in binary format rather than HTTP/1.1’s text format.

Binary formats bring more advantages and possibilities in protocol parsing and optimization extensions.

2.2.2. Multiplexing (Multiplexing)

  • Clients and servers can break HTTP messages into discrete frames, send them interlaced, and then reassemble them at the other end.

  • Multiple requests are sent in parallel and interleaved, without affecting each other.

  • Multiple responses are sent interleaved in parallel and do not interfere with each other.

  • Use a single connection to send multiple requests and responses in parallel.

  • You don’t have to do a lot of work to get around HTTP/1.1 restrictions, such as image sprites, merging CSS/JS (all in one file), embedding CSS/JS/Base64 images, domain sharding (6N connections for n domain names), etc.

Sprites are concepts in front-end development. Image sprites (also known as CSS sprites) combine several small images into one large image, and finally make precise positioning by combining the position and size of small images with CSS (attribute background).

2.2.3. Priority

  • The HTTP/2 standard allows each data stream to have an associated weight and dependency

    • Each data stream can be assigned an integer between 1 and 256
    • There can be explicit dependencies between each data flow and other data flows

  • A client can build and pass a “priority tree” indicating how it prefers to receive responses

  • The server can use this information to prioritize data flow processing by controlling the allocation of CPU, memory, and other resources

    • After the resource data is available, ensure that high-priority responses are optimally transmitted to the client

Whenever possible, resources should be allocated to the parent data stream first. Peer data streams (sharing the same parent) should allocate resources proportionally to their weight.

  1. A and B rely on the implicit “root data stream”, where A gets 12/16 resources and B gets 4/16 resources.

  2. D depends on the root data stream, C depends on D, and D should get the full resource allocation before C.

  3. D should get the full resource allocation before C, and C should get the full resource allocation before A and B, with B getting 1/3 of A’s resources.

  4. D should receive the full resource allocation before E and C, and E and C should receive the same resource allocation before A and B, with B receiving 1/3 of the resources A received.

2.2.4. Header compression

HTTP/2 uses HPACK to compress request and response headers, which can greatly reduce header overhead and thus improve performance.

Earlier versions of HTTP/2 and SPDY used Zlib compression to reduce the size of the transmitted header data by 85% to 88%. But in the summer of 2012, an attack led to session hijacking, which was later replaced by the more secure HPACK.

The client and the server can cache Static table a request header (Static table), when the client sends a request, detects the request of the client side head head the same data in the table, if you have, just need to send to the server head corresponding index of data in the table, so it can reduce the data of the head, head compression is achieved.

2.2.5. Server push (Server Push)

The server can send multiple responses to a client request. In addition to the response to the initial request, the server can push additional resources to the client without the client explicitly requesting additional resources.

2.3. Problems with HTTP/2

2.3.1. Queue head Blocking (head of line blocking)

TCP transmits data sequentially, and HTTP/2 requests or responses are out of order. If packets are lost in the header of the QUEUE during TCP transmission, subsequent requests are invalid, and only new requests or responses can be made. This is a TCP problem, not an HTTP problem.

QUIC protocol solves the problem of queue head blocking. If packet loss is found, other data assembly will not be affected. The main reason is that the underlying QUIC is implemented using UDP.

2.3.2. Handshake delay

Round Trip Time (RTT) : round-trip delay, which can be simply understood as the Time of communication.

TCP requires three handshakes, so TLS delays the handshake. QUIC uses UDP, so there is no handshake.

Third, HTTP / 3

Google decided HTTP/2 was still not fast enough, so HTTP/3 was created.

HTTP/3 is developed by Google, which uses QUIC protocol based on UDP instead of TCP protocol.

Quick UDP Internet Connections (QUIC) : fast UDP network connection. Developed by Google and implemented in 2013, it changed from HTTP-over-QUIC to HTTP/3 in 2018.

Queue head blocking and handshake delay are disadvantages of TCP, while TCP’s advantage is reliable transmission. UDP and TCP complement each other to get QUIC.

3.1. Features of HTTP/3

3.1.1. Connection migration

TCP is based on four elements (source IP address, source port, destination IP address, and destination port). During network switchover, at least one element changes, causing the connection to change. When the connection changes, if the original TCP connection is still used, the connection fails and the connection must be re-established after the original connection times out. So we sometimes find that when we switch to a new network, even though the new network is in good condition, the content still takes a long time to load. If implemented well, a new TCP connection can be established as soon as a network change is detected, and even then it can take hundreds of milliseconds to establish a new connection.

The connection of QUIC is not affected by the four elements, and the original connection is still maintained when the four elements change. QUIC connections are not identified by four elements, but by a set of Connection ids that identify a Connection. Even if the IP or port changes, as long as the Connection ID does not change, the Connection can still be maintained. Such as moving ongoing downloads from a cellular connection to a faster Wi-Fi connection when the device is connected to Wi-Fi, and moving the connection to a cellular connection when the Wi-Fi connection is no longer available.

3.1.2. Operating system kernel and CPU load

According to Google and Facebook, their mass-deployed QUICS require nearly twice as much CPU usage as TLS based HTTP/2. The UDP part of the Linux kernel is not as optimized as TCP, because UDP has not traditionally been used for such high-speed information transfer. TCP and TLS have hardware acceleration, which is rare for UDP and almost nonexistent for QUIC.

With the passage of time, it is believed that this problem will gradually improve.

3.2. Question

  • HTTP/3 is based on UDP, how to ensure reliable transmission?

    • Guaranteed by QUIC (adding algorithms to ensure reliable transmission in QUIC)

  • Why doesn’t Google develop a new transport layer protocol that is different from TCP and UDP?

    • First of all, Google is absolutely capable of development, mainly the current network equipment in the world only recognize TCP, UDP. If you change the transport layer, that means that the operating system kernel also needs to change.
    • In addition, new features standardized by IETF that require TCP have not been widely deployed or used due to a lack of broad support.
    • Therefore, it is extremely difficult to develop and apply a new transport layer protocol.

HTTP/3 is still being optimized (immature), so most companies are still using HTTP/2 or HTTP/1.1.

For more articles in this series, please pay attention to wechat official account [1024 Planet].