This is the 7th day of my participation in the August More Text Challenge.

HTTP/2

Why HTTP/2? How does it improve over HTTP1.1? Why HTTP/2? Of course HTTP/1.1 is too slow.

What are the improvements in HTTP/2 over HTTP/1.1?

  1. Binary frame layer

At the heart of all HTTP/2 performance enhancements lies the new binary framing layer, which defines how HTTP messages are encapsulated and transmitted between clients and servers.

By “layer,” I mean a new, optimized encoding mechanism between the socket interface and the high-level HTTP API visible to the application

At the binary framing layer, HTTP 2.0 splits all transmitted information into smaller messages and frames and encodes them in binary format, where the http1.x header is encapsulated in the Headers frame and our Request body is encapsulated in the Data frame.

  1. The head of compression

Each HTTP transport carries a set of headers that describe the transferred resource and its properties. In HTTP/1.x, this metadata is always in plain text, typically adding 500-800 bytes of overhead per transfer. If HTTP cookies are used, the added overhead can sometimes reach thousands of bytes.

To reduce this overhead and improve performance, HTTP/2 compresses request and response header metadata using the HPACK compression format, which uses two simple but powerful techniques:

  1. This format reduces the size of the individual transports by supporting the encoding of the header fields of the transports through static Huffman code.
  2. This format requires both the client and server to maintain and update an index list of previously seen header fields (in other words, it establishes a shared compression context), which is then used as a reference to effectively encode previously transmitted values.

HTTP 2.0 uses “header tables” on both the client and server sides to track and store previously sent key-value pairs, instead of sending the same data through each request and response; Generic key-value pairs (user agents, acceptable media types, and so on) that hardly change during communication need only be sent once. In fact, if a header is not included in the request (such as a polling request for the same resource), then the header overhead is zero bytes. All headers now automatically use the headers that were previously requested to be sent.

  1. multiplexing

In HTTP/1.X data is ordered based on text, cannot be transmitted in parallel and the receiver does not know the order of packets. But the new binary framing layer in HTTP/2 breaks through these limitations and enables complete request and response reuse: clients and servers can break HTTP messages into discrete frames, send them interlaced, and finally 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.
  • Reduce page load times by eliminating unnecessary latency and increasing utilization of existing network capacity
  • And so on…

The new binary framing layer in HTTP/2 addresses the problem of queue head blocking in HTTP/1.x and eliminates the need for multiple connections to process and send requests and responses in parallel.

  1. Data flow priority
  2. Server push

Another powerful new feature added to HTTP/2 is the ability for the server to send multiple responses to a single client request. In other words, in addition to the response to the initial request, the server can push additional resources to the client without the client explicitly requesting them.

Some shortcomings of HTTP/2

  1. It takes a long time to establish a connection, but there is no way. Who let it dad is TCP? As we know, the TCP three-way handshake requires three interactions between the client and the server, which means 1.5RTT, and the TLS encryption handshake, so about 3RTT. The specific elapsed time varies according to the distance between the server and the client. If the elapsed time is relatively close, the elapsed time is less than 100ms, which may not be obvious to users. However, if the elapsed time of an RTT reaches 300-400ms, the total elapsed time of a connection establishment process may reach about one second. The user will obviously perceive that the web page loads slowly.

Network delay is also called Round Trip Time (RTT). This refers to the time it takes for a request to send a request packet from the client browser to the server and receive a response packet from the server. RTT is an important indicator of network performance.

  1. Queue head congestion problem. Didn’t HTTP/2 solve the problem of queue header blocking? This is only half true, HTTP/2 only addresses HTTP queue header blocking, not TCP queue header blocking.

The queue blocking problem dates back to HTTP/1.1, and if you are familiar with HTTP history, you will know that the main improvement of HTTP1.1 over HTTP/1.0 is the introduction of keep-alive connections.

So-called persistent connections: Multiple HTTP requests and responses can be sent over a single TCP connection, reducing the cost and latency of resume and closing connections.

In addition, HTTP/1.1 allows the use of request pipelines over persistent connections, another performance optimization over persistent connections.

A request pipeline is a process where multiple requests can be queued up before an HTTP response arrives, and when the first HTTP request flows over the network to the server, the second and third requests can be sent. This can reduce the loopback time and improve the performance in high delay networks.

However, there are certain restrictions and requirements for pipe connections, one of which is critical: the server must send back HTTP responses in the same order as the requests.

This means that if a response return is delayed, subsequent responses will be delayed until the response at the head of the queue arrives. This is known as HTTP header blocking.

HTTP header blocking was solved in HTTP/2, which abandoned the pipelining approach and introduced the concept of frames, messages, and data streams. Clients and servers could break up HTTP messages into discrete frames, send them out of order, and reassemble them at the other end.

Http2 does a good job of addressing HTTP header blocking. However, HTTP/2 still has the problem of TCP queue header blocking because HTTP/2 is implemented based on TCP.

During TCP transmission, data is divided into small ordered packets, which are forwarded by intermediate devices, such as routers, hubs, and switches, and finally reach the destination. If one of the packets does not arrive in order, the receiver stays connected and waits for the packet to return. Subsequent requests are blocked, resulting in TCP queue header blocking.

HTTP/1.1 pipelinized persistent connection also enables the same TCP connection to be used by multiple HTTP connections. However, HTTP/1.1 stipulates that a domain name can have six TCP connections, while HTTP/2 requires only one TCP connection to be used for the same domain name. Once the TCP queue head in HTTP/2 is blocked, the impact will be greater. Because HTTP/2 multiplexing allows multiple requests to be based on the same TCP connection, if a single request blocks the TCP header, multiple requests will be affected.

HTTP/3

Given HTTP/2’s obvious shortcomings, why wouldn’t they let it “live on”? That’s why HTTP/3 is coming just a few years after HTTP/2 came out.

Some enhancements to HTTP/3

As you can see from the figure above, the QUIC protocol in HTTP/3 contains the following features.

HTTP/3 is also called HTTP OVER QUIC because it is based on QUIC

  • It realizes the functions of flow control and transmission reliability similar to TCP. Although UDP does not provide reliable transmission, QUIC adds a layer on top of UDP to ensure reliable transmission of data. It provides packet retransmission, congestion control, and other features found in TCP.
  • Integrated TLS encryption function. QUIC currently uses TLS1.3, which has more advantages than the earlier version of TLS1.3, the most important of which is the reduction in the number of RTT spent on the handshake.
  • The multiplexing function in HTTP/2 is realized. Unlike TCP, QUIC enables multiple independent logical data flows over the same physical connection (see figure below). Realize the separate transmission of data stream, and solve the problem of TCP squadron head blocking.

Some pain points addressed by HTTP/3

Let’s take a look at some of the drawbacks of HTTP/2 and how QUIC addresses them

  1. Long connection time

An HTTP2 connection usually takes 2 or 3 RTTS to complete, but QUIC can achieve 1 or 0RTT to complete a connection. If it is the first time, 1RTT is needed to complete the connection, but if it is not the first time, 0RTT can be completed. This is because the configuration file will be cached for the first time and can be directly used for subsequent connections, thus skipping 1RTT and realizing 0RTT service data interaction.

  1. The TCP queue header is blocked

After TCP receives data packets, these data may arrive in disorder, but TCP must collect and sort all data to be used by the upper layer. If a packet is lost, it must wait for retransmission. As a result, certain packet loss data blocks the data use of the whole connection.

The QUIC protocol is based on UDP protocol. There can be multiple streams on a link, and the streams are not affected by each other. When a stream loses packets, the impact range is very small, thus solving the problem of queue head blocking.

Let’s look at HTTP/1.1, HTTP/2, and QUIC data transfer.

HTTP / 1.1

HTTP/2

QUIC

Some challenges of HTTP/3

From the above analysis, we believe that HTTP/3 is a perfect protocol on a technical level. However, there are still a number of serious challenges to implementing HTTP/3 in a real-world environment, mainly in the following three areas.

First, as of now, HTTP/3 is not fully supported on the server or browser side. Chrome has supported Google’s version of QUIC for several years, but there are major differences between this version and the official QUIC.

Second, deploying HTTP/3 is also very problematic. Because the system kernel optimization of UDP is not nearly as good as TCP optimization, this is also an important reason to block QUIC.

Third, the rigidity of intermediate equipment. The UDP optimization of these devices is much lower than that of TCP. According to statistics, when QUIC is used, the packet loss rate is about 3% to 7%.

Here are two things I can say about the future of HTTP/3:

  • There is still a long way to go from standard formulation to practice and protocol optimization;
  • HTTP/3 grows slowly because of the underlying protocol, which is essentially different from HTTP/2

Give me a star, everyone

Reference documentation

  1. Introduction to the HTTP / 2
  2. HTTP3: get rid of TCP, TCL baggage build efficient network browser | principle and practice
  3. HTTP/2 header compression algorithm – HPACK