Ⅰ. History of  HTTP Protocol Development 

HTTP

Only the get method is supported in HTTP 0.9 (1991), and request headers are not supported.

Request headers, rich text, status codes, caching, and connections that cannot be reused were all supported in HTTP 1.0 (1996).

Connection multiplexing, chunked transfer, and resumable upload are all features of HTTP 1.1  (1999).

Binary framing, multiplexing, header compression, server push, and other features of HTTP 2.0  (2015)

The HTTP mapping on  QUIC  was introduced in 2013; in October 2018, the  IETF 's HTTP working group and the  QUIC working group decided to refer to it as "HTTP/3[1]" to make it an early universal standard.

Problems with HTTP 1.1 

1. One-way request

Requests can only be made in one direction. Before the server may deliver data to the client, the client must make the request. The server cannot actively push data to the client.

2. High protocol overhead

The content carried in the header is too large and cannot be compressed, which increases the cost of transmission.

For example: every time the client initiates a request, it must bring  Cache -Control: no-cache in the request header. Repeating these fields for each request is actually a waste of bandwidth

3. Head of line blocking

The next request must be sent after the previous request returns, resulting in insufficient bandwidth utilization and subsequent requests being blocked (HTTP 1.1 attempts to use pipeline (Pipelining) technology, but the innate FIFO  (first-in, first-out) mechanism causes the current request's execution to be dependent on the previous request's completion. It is trivial to cause the head of the queue to stall after the prior request has been completed, and thus does not fundamentally alleviate the problem.)

For example: A and B are two requests. A is the first to begin. At this point, the server receives and processes the A request. The B request is also sent at the same time. However, the A request has not been answered, and the B request will have to wait.

HTTP2 was proposed in 2015 as a solution to the difficulties with HTTP1.1. What issues does HTTP2 address in comparison to HTTP1.1? What are the new features?

HTTP2 features and problems

HTTP2 Features

1. Binary Framing

In HTTP 2.0 , the header frame and data frame are used to separate the two sections of the datagram. That is, the data body frame and the header frame. The frame's transmission is finally completed in the stream. Multiple fragment frames can be created from the frame in the stream, the header frame, and the data frame. The data frame could be data = data 1 + data 2 +... + data n, for example.

For example: a.js and b.css are requested; the id of the stream corresponding to a.js is 1, the id of the stream corresponding to b.css is 2, the head frame of a.js is head1, the data frame is data1, and b.css is b.css. The data frame in.js is data2, and the head frame is head2. For packet transfer, the browser can put head1, data1, data2, and data2 into the TCP channel at the same time. These data may be further separated and split into different packet sequence numbers for transmission at the TCP layer, but you don't need to worry about it. Disassembly and re-assembly instructions. The received streams with the id of 1 are processed together, and the received streams with the id of 2 are treated together, because ordered processing may be done at the binary frame layer of HTTP2.0.

 2. Multiplexing

HTTP 2.0's multiplexing is basically an improved version of HTTP 1.1  's long link. After a successful link, the client can begin adding links in an orderly manner in HTTP 1.1.  as long as the link is not disconnected. request, then get the data that corresponds to each request Its downside is that a request-response interaction must wait for the prior request interaction to complete before proceeding; otherwise, the latter can just wait, which is known as HTTP header blocking. The client can initiate numerous requests concurrently in a connection in HTTP 2.0  following a successful link, as long as the link is not disconnected.

3. Stream priority

WEB applications' resources are of varying importance. Important resources should be loaded first in order to render the website as quickly as possible and improve the user experience. All resources are delivered across a single connection with HTTP2. The order of resource transfer is especially crucial at this time to avoid head-of-line blocking.

For example: There is an external style sheet if a web page has a lot of images. The page will be completely blank until all of the content is loaded if the browser downloads all of the images first and then loads the stylesheets last. Who could take it?

4. Header compression

The compression algorithm utilized is HPACK, which is implemented by maintaining the server and client index tables to remove redundant data in the request and reduce overhead.

for example： The communication between the client and the server, is comparable to a chat between A and B. Every day at noon, A must tell B, "I went to Wanda Plaza for dinner." Saying this every day is exhausting, and A does not want to say it every time. If there are a lot of words, you can agree with B. When A says "eat" in the future, she means "go to Wanda Plaza for dinner."

5. Active push from the server

Push the necessary resources to the client in advance, so that the delay time can be relatively reduced

For example: When a client requests an  HTML  file, the server can parse out which  JS  and  CSS  files are referenced by the HTML, and then actively push these static resource files to the client, saving time. There is no need to wait for the client to receive the HTML, parse the static resources referenced by the HTML, and then request the backend.

Problems with HTTP2

1. It takes a long time to establish a connection

It takes a long time to establish a connection, which mostly refers to the three-way handshake of TCP, as well as the time-consuming nature of  TLS  connection formation. HTTP2 and QUIC will be compared and discussed in detail in the section on QUIC 0RTT connections that follows.

2. Head of line blocking

Multiplexing, in fact, only solves queue head blocking at the HTTP level; queue head blocking at the TCP level remains. HTTP2 and QUIC will be contrasted and described in detail in the section on QUIC solving queue head blocking that follows.

Based on these problems of HTTP2, Google  took a different approach and designed the QUIC protocol, which was officially proposed as  HTTP3  in 2018

Ⅱ.  QUIC protocol

What is QUIC?

QUIC

Google launched QUIC (Quick  UDP  Internet Connection), a suite of UDP-based transport protocols. It incorporates TCP +  HTTPS  + HTTP/2 features with the goal of assuring network dependability and lowering latency.

As you can see in the diagram above, QUIC is built on top of the insecure  UDP protocol. This does not, however, imply that QUIC is also untrustworthy! In certain ways, QUIC can be compared to  TCP 2.0. It provides the most up-to-date versions of all TCP features (reliability, congestion management, flow control, ordering, and so on), as well as many others.  TLS is also fully integrated into QUIC, making unencrypted connections impossible.

QUIC protocol features

1. Based on UDP

The transport layer in HTTP 2.0  and older versions use TCP, and because of this, TCP three-way handshakes must be completed when establishing a connection, resulting in a protracted connection duration.

QUIC is based on UDP, and one of UDP's features is that there is no link, which reduces the amount of time it takes to establish a connection.

2. Low connection latency

The problem of high time-consuming HTTP2 connection

HTTP2 requires three RTT times when establishing a connection for the first time, and at least one RTT time when establishing a connection for the second time (TLS keys have been exchanged) and utilizing the quickest TLS1.3 protocol.

For example, inputting a URL in the address bar and pressing Enter in a browser will result in the following actions:

For address resolution, DNS recursively searches www.abc.com to acquire the matching IP;

TCP handshake, the well-known TCP three-way handshake, needs 1 RTT (it can also be reckoned as 1.5 because the round-trip delay is 1 and a half).

In the case of TLS 1.2, which is now the most extensively used, the handshake requires two  RTTs. You can select to allow session reuse for non-first-time connection setup, which can reduce the handshake duration to 1 RTT. The method of creating a TLS connection will not be covered in depth because the main focus of this essay is HTTP. If you don't understand, Google  HTTP business data interaction, which assumes that abc.com data may be retrieved in a single interaction. The interaction of business data, on the other hand, necessitates 1 RTT; based on the previous process analysis, we can conclude that in order to complete a quick  HTTPS business data interaction, we must: For new connections, use 3RTT + DNS; for session reuse, use 1RTT + DNS.

As a result, a single request handshake takes a long time for a request with a tiny quantity of data, which has a significant impact on the user experience. Simultaneously, in the case of a weak user network, the RTT latency will increase, negatively impacting the user experience.

QUIC's 0-RTT establishes a connection

UDP is the foundation of QUIC. In fact, it is unnecessary for it to establish a link. The exchange of TLS keys is the primary goal of establishing a connection. In order to establish a link, there are two main scenarios:

When establishing a connection for the first time (1RTT), the encryption key must be transferred before the service data can be sent.

It's not the first time a link (0RTT) has been established, the encryption key has been transferred, and business data has been sent immediately.

The Diffie-Hellman algorithm is used for key exchange instead of the original implementation of the 1RTT connection. A key agreement algorithm is the DH algorithm. Finally, the two parties agree on a shared key, which will not be communicated over the network.

An example is shown below:

Alice and Bob exchange data

Alice and Bob wish to share information. After selecting a prime number p, a base g, and a small random number a, Alice calculates A=ga mod p to generate a large A, and then sends the base g, prime p, and the calculated large number A to Bob; after Bob receives it, he also selects a random number b, and then calculates B=gb mod p to calculate the maximum B, and B calculates K=Ab mod p at the same time B delivers it to Alice, who may use it to calculate K using this formula, and the outcome is the same as Bob's calculation.

Small an is considered Alice's private key, big A is considered Alice's public key, small b is considered Bob's private key, and big B is considered Bob's public key. The DH algorithm works by requiring both parties to generate their own private keys. The private key is only accessible to oneself, the public key is exchanged, and the final key secretKey is formed using its own private key and the public key of the other party. The DH method uses mathematical laws to ensure that the secretKey computed by both parties is the same.

It can be found that the final key K has not been transmitted in the network, but the two parties can calculate and negotiate the K used to encrypt the data only by exchanging the public key.

3. Connection Migration

HTTP2 identifies connections based on quads

Identify Connections Based on Quads

When any element in the quadruple changes, the connection will be disconnected and the connection needs to be re-established

For example: when the user switches from  WIFI  to 4G, the TCP-based HTTP protocol cannot keep the connection alive because the elements in the quadruple have changed

QUIC identifies connections based on ConnectionID

Identify Connections Based on ConnectionID

So, how does QUIC manage to migrate connections? QUIC is built on the UDP protocol, to put it simply. Any QUIC connection is now recognized by a 64-bit random number as an ID, rather than by an IP and port quad, so that even if the IP or port changes, the connection is still maintained, the upper-level business logic is not affected, it is not interrupted, and there is no need to reconnect. The likelihood of a collision is extremely low because this ID is created at random by the client and has a length of 64 bits.

4. Customizable congestion control

Congestion Control is a feature of transport layer protocols such as TCP and QUIC. Slow start, congestion avoidance, fast retransmission, and fast recovery are just a few examples.

The congestion controller's primary responsibility is to guarantee that the network is not overburdened with data at the same time. The packet will overflow if there is no buffer, therefore it normally merely sends a small amount of data (usually 14KB) to see if it gets through. If the data is received, the receiver responds by sending an acknowledgment to the sender. Until a packet loss event is recorded (which implies the network is overloaded (1 bit) and it needs to back off (1 bit), the sender doubles its transmitting rate at each RTT. A TCP connection "probes" its available bandwidth in this manner.

HTTP2.0 relies on TCP's Cubic congestion control algorithm, which cannot be altered and has limited flexibility.

QUIC's transmission control is implemented at the application layer, rather than the kernel's congestion control algorithm, which means we implement and configure alternative congestion control techniques and parameters based on different business circumstances. The GOOGLE-proposed BBR congestion control method and CUBIC are two fundamentally distinct algorithms. BBR is less sensitive and performs better than CUBIC in weak network and certain packet loss conditions. According to the business, we can specify the congestion control method and parameters flexibly in QUIC, and even various connections of the same business can use different congestion control algorithms.

5. No head-of-line blocking

HTTP2 has a head-of-line blocking problem

Head-of-Line Blocking Problem

HTTP2 sends four streams simultaneously over a single TCP connection, as demonstrated in the sample above. Stream1 has arrived safely and has been read by the application layer. However, Stream2's third tcp segment is missing. TCP must retransmit the third segment in order to tell the application layer to read the next data, despite the fact that all data from Stream3 and Stream4 has arrived at this point. The receiving end is not completely blocked, but it is. At the TCP level, this is the problem of head-of-line blocking.

Please note that while both we and the browser are aware that we are receiving JavaScript and  CSS files, HTTP/2 does not need to be aware of this. It just knows that chunks from a different resource stream id are being used. TCP, on the other hand, is completely unaware that it is transmitting HTTP!

How do you deal with TCP head of queue blocking? The solution is actually fairly simple: all we have to do is make the transport layer aware of the various, separate streams. As a result, if the data in one stream is lost, the transport layer understands it doesn't need to block other streams. Although this approach is simple in theory, it is difficult to put into practice in practice. Changing TCP to be stream-aware is already problematic for a variety of reasons.

QUIC solves the HTTP2 head-of-line blocking problem

QUIC Solves the Head-of-Line Blocking Problem

QUIC takes the framing approach of HTTP2 and adds its own frames. The stream id (stream id) used to be in the data frame (DATA frame) of HTTP2, but it has now been moved to the transport layer's QUIC stream frame (STREAM frame). QUIC's design of a monotonically growing Packet Number, on the other hand, can eliminate the need to confirm data packets in order, like TCP does. Out-of-order confirmation is supported by QUIC. If Packet N is lost, the current window will continue to shift to the right as long as a new received packet confirmation is received. When the sender realizes that data packet Packet N has been lost, it will queue the data packet that needs to be resent, renumber the data packet Packet N+M, and resend it to the receiver. The new data packet is similar, hence the current window will not be blocked in place due to packet loss and retransmission, thereby resolving the head-of-line blocking problem. How can we be confident that the contents of the two data packets are the same if the Packet N+M of the retransmitted data packet is not the same as the Packet N number of the lost data packet? QUIC uses Stream ID to determine which resource request the current data stream belongs to, and it's also how data packets are assembled after multiplexing and transmission to the receiving end. The content consists of the retransmitted data packet Packet N+M and the lost data packet Packet N cannot be determined only by comparing the Stream ID. Stream ID offset in bytes. Data packets belonging to the same Stream ID can also be communicated out of order using the Stream Offset field information (with HTTP/2, just the Stream ID is used for identification, and data frames belonging to the same Stream ID must be transmitted in sequence). If the data packets' Stream ID and Stream Offset are the same, then the contents of the two data packets are the same.

Ⅲ. Summary

The bulk of the transmitted data is no longer the key performance constraint, but network latency has become more critical as network capacity has greatly improved. As a result of this background, QUIC no longer employs TCP as the transport layer protocol, instead opting for a modified implementation of UDP to adapt to changing network conditions. In certain ways, QUIC can be compared to TCP 2.0. It provides the most up-to-date versions of all TCP features (reliability, congestion management, flow control, ordering, and so on), as well as many others. TLS is also fully integrated into QUIC, making unencrypted connections impossible. At the same time, I believe QUIC has a bright future with zero RTT connection setup, easy connection migration, almost eliminating head-of-line blocking, improved