A preface.

Since 2015, QUIC protocol has been standardized in IETF and implemented by major manufacturers at home and abroad. As QUIC has many advantages such as "0RTT connection" and "support connection migration", it will become the next generation Internet protocol.Copy the code

By the end of this article you will know and learn:

  1. History of HTTP protocol
  2. What are the problems with each version of HTTP, and what problems are resolved by each version
  3. QUIC protocol features
  4. Don’t be afraid of being asked HTTP questions!

HTTP1.1 is one of the most widely used versions in the history of HTTP1.1

History of HTTP protocol

 

  1. HTTP 0.9 (1991) only supports get methods but not request headers
  2. HTTP 1.0 (1996) was basically formed, supporting headers, rich text, status codes, caches, and connections that cannot be reused
  3. HTTP 1.1 (1999) supports connection reuse, block sending, and breakpoint continuation
  4. HTTP 2.0 (2015) Binary frame transfer, multiplexing, header compression, server push, etc
  5. HTTP 3.0 (2018) QUIC was implemented in 2013; In October 2018, the HTTP Working Group of the IETF and the QUIC Working Group jointly decided to call the HTTP mapping on QUIC “HTTP/3” in advance of making it a global standard

Problems with HTTP1.1

1. One-way request

The server can send data to the client only after the client initiates the request. The server cannot actively push data to the client.

2. High protocol overhead

Header contents are too large and cannot be compressed, which increases the transmission cost. For example, every time a client initiates a request, it will put cache-control: no-cache in the request header. Repeating these fields on every request is a waste of bandwidth

3. Queue head is blocked

HTTP 1.1 attempts to use Pipelining technology, but the inherent FIFO (first-in, first-out) mechanism makes the execution of the current request depend on the completion of the last request, which can easily lead to queue head blocking. For example: Request A and request B. A is initiated first, and the server receives the request and is processing it. At the same time, request B came in. But request A has not been returned, so request B has to wait.

Based on these problems with HTTP1.1, HTTP2 was proposed in 2015. What issues does HTTP2 address with HTTP1.1? What are the new features?

HTTP2 features and problems

HTTP2 features

1. Binary frame division

In HTTP 2.0, it divides the two parts of a datagram into header frames and data frames. That is, header frames and data body frames. The transmission of frames is finally carried out in the stream. The frame, header frame and data frame in the stream can be divided into multiple fragment frames. For example, data frame can be data = data_1 + data_2 +… + data_n

For example: request a.js and B.cs, the stream id of A.js is 1, the stream ID of B.cs is 2, the head frame of A.js is head1 and the data frame is data1, and the head frame of B.js is head2 and the data frame is data2. The browser can put head1, Data1, head2, and datA2 into the TCP channel for packet transmission. At the TCP layer, the data may be split into different packet numbers for transmission, but you do not need to pay attention to the split and assembly of this layer. Because it is possible to do sequential processing in the binary frame layer of HTTP2.0, streams with id 1 and streams with ID 2 are processed together.

2. Multiplexing

HTTP 2.0 multiplexing is an upgrade of HTTP 1.1, which allows clients to order multiple requests from a single link, as long as the link is still open, and obtain the corresponding response data for each request. The disadvantage is that a request-response interaction must wait for the previous request interaction to complete, otherwise the subsequent interaction must wait, which is HTTP level header blocking. In HTTP 2.0, after a connection is successful, the client can concurrently initiate multiple requests within a link as long as the connection is still open. Each request and its response do not need to wait for other requests. A request task takes too much time and does not affect the normal execution of other connections

3. Traffic priority

WEB application resources are different in importance. Load important resources first to render the page as soon as possible and improve user experience. In HTTP2, all resources are transferred over a single connection, so the order in which the resources are transferred becomes more important to avoid queue header blocking.

For example, if a web page has a bunch of images, it also has an external style sheet. If the browser downloads all the images first and loads the style sheet last, the page will be completely blank before everything is loaded. Who can stand that?

4. The Header compression

Reduce the redundant data in the request, reduce the overhead, using the compression algorithm for HPACK, this algorithm through the server and client each word maintenance index table to achieve.

For example, the client communicates with the server, which is similar to A talking to B. A says to B at noon every day: “Went to wanda plaza for dinner”, so every day is very tired, don’t want to say so many words, every time A and B agreed well, after A say “eat”, means “went to wanda plaza for dinner”, since then the noon eat A it just say A word “eat” with B, A, B have invited him to have dinner at wanda.

5. The server actively pushes

Push the necessary resources to the client in advance so that latency is relatively reduced

Here’s an example: When a client requests an HTML file, the server returns the HTML before, actually can parse the HTML quotes what JS and CSS file, the server can take the initiative to push these static resource file to the client, without having to wait after the client receives the HTML parsing HTML reference static resources, request the back-end again, This saves some time.

Problems with HTTP2

1. Establishing a connection takes a long time

It takes a long time to establish a connection, mainly referring to the TCP three-way handshake, and TLS connection takes a long time to establish, here is a simple understanding. QUIC 0RTT will compare HTTP2 and QUIC in the following section, and explain in depth

2. Queue head is blocked

In fact, multiplexing is only to solve the HTTP level of queue blocking, TCP level queue blocking still exists, in the following part of the QUIC to solve the queue blocking will be HTTP2 and QUIC comparison, and further explained

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

QUIC protocol

What is a QUIC?



Quick UDP Internet Connection (QUIC) is a udP-based transport protocol introduced by Google. It implements the functions of TCP + HTTPS + HTTP/2 to ensure reliability and reduce network latency.

As you can see from the figure above, QUIC runs on an unreliable UDP protocol. But that doesn’t mean QUIC itself is unreliable! In a way, QUIC should be thought of as TCP 2.0. It includes the best version of all of TCP’s features (reliability, congestion control, flow control, sorting, etc.) and much more. QUIC also fully integrates TLS and does not allow unencrypted connections.

QUIC protocol features

1. Based on UDP

HTTP2.0 and earlier versions use TCP at the transport layer, and because TCP is used to establish a connection, the TCP three-way handshake is required, which takes a long time to establish a connection. QUIC is based on UDP, which is inherently linkless, saving time in connection setup

2. Low connection delay

HTTP2 connection time is high

HTTP2 takes 3 RTT times to establish a connection for the first time, and at least 1 RTT time to establish a connection for non-first time (TLS keys have already been exchanged)

For example, a simple browser visit, typing a url into the address bar and pressing Enter, actually produces the following action:

  1. The DNS recursively queries www.abc.com to obtain the corresponding IP address for address resolution.
  2. The TCP handshake, the familiar TCP three-way handshake, requires 1 RTT (which can also be counted as 1.5 because it is a one-and-a-half round-trip delay);
  3. The TLS handshake, currently the most widely used TLS 1.2, requires two RTTS. If the connection is not established for the first time, you can enable session reuse to shorten the handshake time to one RTT. Because the core content of this article is HTTP, it will not explain the process of TLS connection in detail, if you do not understand, you can Google
  4. HTTP business data interaction, assuming that abc.com data can be retrieved in a single interaction. Then business data interaction requires 1 RTT; After the process analysis, you need to undergo the following operations to complete a short HTTPS service data exchange: new connection 3RTT + DNS; Session reuse 1RTT + DNS.

Therefore, for a small amount of data requests, a single request handshake takes a lot of time and has a significant impact on the user experience. At the same time, in the case of poor user network, RTT delay will become high, which will greatly affect user experience.

QUIC’s 0-RTT establishes the connection

QUIC is based on UDP and does not need to establish a connection. The connection is mainly to exchange TLS keys. There are two main scenarios for building a company:

  1. When establishing a connection for the first time (1RTT), you need to exchange encryption keys before sending service data
  2. If the link is not set up for the first time (0RTT), the encryption key has been exchanged and service data is directly sent

The core of the 1RTT connection is that the Diffie-Hellman algorithm is used for key exchange. The DH algorithm is a key negotiation algorithm. The two parties finally negotiate a common key, which is not transmitted over the network.

Chestnut as shown below:

Alice and Bob want to exchange data. Alice first chooses a prime number P, base g, and random number small A, and then calculates a = G ^a mod P to generate big A. Then Alice sends the base g, prime P, and calculated big A to Bob. After receiving it, Bob also selects A random number B, calculates b =g^b mod p, calculates big B, and b calculates K=A^b mod P at the same time. Bob sends the calculated big B to Alice, who can calculate K by using this formula, and the calculation result is the same as that of Bob

We regard small A as Alice’s private key, large A as Alice’s public key, small B as Bob’s private key, and large B as Bob’s public key. The essence of the DH algorithm is that both parties generate their own private key and public key. The private key is visible only to themselves, and then the public key is exchanged. The final secretKey is generated. The DH algorithm uses mathematical laws to ensure that the secretkeys calculated by both parties are 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 for encrypted data only by exchanging the public key

3. Migrate connections

HTTP2 identifies connections based on quads



When any element in a quad changes, the connection is broken and needs to be re-established

For example, when a user switches from WIFI to 4G, the TCP-based HTTP protocol cannot keep the connection alive because the elements in the quad change

QUIC identifies a connection based on a ConnectionID



So how does QUIC do connection migration? QUIC is based on UDP protocol. Any QUIC connection is identified by a 64-bit random number as AN ID instead of an IP or port quple. In this way, even if the IP or port changes, as long as the ID remains unchanged, the connection will still be maintained and the upper-layer service logic will not be aware of the change. There is no interruption, so there is no need to reconnect. Since this ID is randomly generated by the client and has a length of 64 bits, the probability of collisions is very low.

4. Customized congestion control

Transport-layer protocols such as TCP and QUIC include a mechanism called Congestion Control. For example: slow start, congestion avoidance, fast retransmission, fast recovery. The main job of a congestion controller is to ensure that the network is not overloaded with too much data at once. If there is no buffer, the packet will overflow, so it usually just sends a bit of data (usually 14KB) to see if it gets through. If the data arrives, the receiver confirms sending back to the sender. As long as all sent data is confirmed, the sender doubles its sending rate at each RTT until a packet loss event is observed (which means the network is overloaded (1 bit) and it needs to back up (1 bit)). This is how a TCP connection “probes” its available bandwidth

HTTP2.0 uses Cubic congestion control algorithm in TCP underlying solidification, which cannot be changed and has poor flexibility

The transmission control of QUIC is no longer dependent on the congestion control algorithm of the kernel, but implemented on the application layer, which means that we implement and configure different congestion control algorithm and parameters according to different business scenarios. The congestion control algorithm of BBR proposed by GOOGLE is completely different from that of CUBIC. In weak network and certain packet loss scenarios, BBR is less sensitive and has better performance than CUBIC. Under QUIC, we can specify the congestion control algorithm and parameters randomly according to the business, and even different connections of the same business can use different congestion control algorithm.

5. No queue head is blocked

HTTP2 has queue header blocking problems



As in the example above, HTTP2 sends four streams simultaneously over a TCP connection. Where Stream1 has arrived correctly and is read by the application layer. The third segment of the Stream2 stream is missing. TCP retransmits the third segment of the Stream2 stream so that the application layer can read the following data. Although all Stream3 and Stream4 data has reached the receiver at this point, it is blocked, which is the TCP level queue header blocking problem

Understand this: while we and the browser know that we’re getting JavaScript and CSS files, HTTP/2 doesn’t need to know that. It only knows that it is using blocks from different resource stream ids. However, TCP doesn’t even know it’s transmitting HTTP!

How to solve the problem of TCP queue header blocking? The solution is simple: we “just” need to let the transport layer know about different, independent streams. This way, if data is lost for one stream, the transport layer itself knows that it does not need to block other streams. Although this solution is simple in concept, it is difficult to implement in reality. Changing TCP itself to be stream-aware has been difficult for a variety of reasons

QUIC addresses HTTP2 header blocking



Inspired by the HTTP2 framing approach, QUIC also added its own frames. The stream ID, formerly in the HTTP2 DATA frame, is now moved down to the transport layer’s Stream frame, and the Packet Number used by the QUIC is monotonically increasing. QUIC supports out-of-order confirmation. When Packet N is lost, as long as a new received Packet is confirmed, the current window will continue to slide to the right. When the sending end learns that Packet N is lost, it will put the packets that need to be retransmitted into the waiting queue and renumbered them. For example, Packet N+M will be re-sent to the receiving end. The processing of retransmitted packets is similar to sending new packets, so that the current window will not be blocked in place because of Packet loss and retransmission. Thus solve the problem of queue head blocking. Then, since the number of Packet N+M of the retransmitted Packet is not consistent with that of Packet N of the lost Packet, how can we determine that the contents of the two packets are the same? QUIC uses the Stream ID to identify which resource request the current data Stream belongs to, which is also the basis for the packet to be assembled properly after multiplexing to the receiving end. Packet N+M retransmitted Packet and Packet N lost Packet cannot be determined by the consistency of Stream ID only. A new field, Stream Offset, needs to be added to identify the byte Offset of the current Packet in the current Stream ID. With the Stream Offset field information, packets belonging to the same Stream ID can also be sent out of order (HTTP/2 is only identified by the Stream ID, requiring data frames belonging to the same Stream ID must be transmitted in order). If the Stream ID and Stream Offset of the two packets are the same, the contents of the two packets are the same.

conclusion

As the network bandwidth has been greatly improved, the size of the transmitted data is not the main performance bottleneck, but the network delay becomes more important. Based on this background, QUIC no longer uses TCP as the transport layer protocol, but adopts UDP in a new way to adapt to the changes of the network conditions of The Times. In a way, QUIC should be thought of as TCP 2.0. It includes the best version of all of TCP’s features (reliability, congestion control, flow control, sorting, etc.) and much more. QUIC also fully integrates TLS and does not allow unencrypted connections. With 0 RTT connection establishment, smooth connection migration, virtually no queue blocking, improved congestion control and flow control, I believe QUIC has a great future.

Refer to the article

  1. HTTP/3 From A To Z: Core Concepts

  2. QUIC website