Shulou(Shulou.com)06/01 Report--

In this article, the editor introduces in detail "what are the knowledge points of HTTP3", the content is detailed, the steps are clear, and the details are handled properly. I hope that this article "what are the knowledge points of HTTP3" can help you solve your doubts.

HTTP3 is the latest version of the HTTP protocol. Since its inception, HTTP has been the preferred application layer protocol for exchanging hypertext documents. Over the years, HTTP has made several major upgrades to keep up with the development of the Internet and the increase in the types of content exchanged on WWW, and HTTP/3 is the latest version.

Let's take a brief look at HTTP/2. Since the release of HTTP 1.1 in 1999, Web has been developing rapidly, but unfortunately the HTTP protocol has not been updated. Google, who can't wait, created his own SPDY (pronounced "speedy") and relied on Chrome browsers to promote it. Seeing that SPDY works really well (with nearly 50 per cent performance improvement), IETF promotes the development of HTTP/2. The main features of SPDY and HTTP/2 are shown as follows:

HTTP/2 is not new now, and 33.5% have supported HTTP/2, according to a survey of the 10 million most visited websites in February 2019. In China, if you open the browser to look at the debugging mode, you will find that HTTP/2 has been widely used by major factories, especially the resource stations where css, js and pictures are placed. HTTP/2 is basically standard. This is also easy to understand, basically do nothing, you can directly enjoy the benefits of multiplexing, why not?

In traditional HTTP, the conceptual model is very simple: the lower-level TCP communication is completely incompatible with the upper HTTP, but the "connection" between TTP and TCP coincides, and the unit of TCP transmission is packet,HTTP, which adopts request-response 's model.

In HTTP/2, the conceptual model has changed, and the basic unit of transmission in HTTP/2 is the frame. Different from the plaintext transmission of HTTP 1.1, the frame of HTTP/2 is binary, and the "logical connection" carried by TCP is called data flow (stream). All the features of state flow, flow control, priority and so on are implemented on the data stream. The so-called "multiplexing" in HTTP/2 means that the data stream is divided into multiple frames, and the frames of multiple data streams are mixed and sent with the same TCP connection.

It is worth noting that HTTP has a distinction between 1.0 and 1.1, so write HTTP 1.0 and HTTP 1.1, but there will be no other small versions of HTTP/2, so don't write HTTP 2.0, you should write HTTP/2.

Although HTTP/2 has brought huge performance improvements, there is no end to the desire for performance. After many problems in the application layer have been solved, the next focus of optimization is the transport layer. Whether SPDY or HTTP/2, the transport layer protocol is caused by some fetal problems in TCP,TCP, such as slow startup. If the congestion window size is not set properly, the performance of TCP will deteriorate sharply. There has been a lot of discussion on this issue on the Internet, and I will not repeat it here.

Another important problem is that the effect of HTTP/2 multiplexing is not as good as expected. Although transport connections in HTTP/2 can be multiplexed, there is still no way to avoid head-of-line blocking. Because TCP needs to be orderly, if a single TCP connection carries four logical connections at the same time, and one of the logical connections loses packets, the other three will be affected and must be retransmitted from the moment of packet loss, which is undoubtedly a great waste. Tests show that if the packet loss rate exceeds 2%, HTTP/2 is not even as good as HTTP 1.1, because the connections in HTTP 1.1 are physically isolated and will not affect each other.

So the natural way of thinking is to "get rid of these problems of TCP." Considering that there are already thousands of network devices that can only recognize TCP and UDP, and the software will not evolve, it is certainly not feasible to update the TCP protocol-although TCP's Fast Open was released in December 2014, the situation in real applications is not satisfactory. Therefore, the only thing available is UDP. By the way, some people have considered SCTP, but SCTP still has some defects in team head blocking, TLS, four-way handshake and so on, which is not satisfactory.

Some of you have probably heard of QUIC (pronounced quick) and know that it is based on UDP's HTTP, and that it is still first proposed by Google. Indeed, last time Google took the lead in coming up with SPDY, and this time Google took the lead in coming up with QUIC. According to the original intention of Google, QUIC is to replace the TCP in the traditional HTTP/TCP/IP protocol stack with UDP (encrypted, of course), which can transmit HTTP/2 frames through encrypted UDP.

According to Google, this has many benefits, such as much lower latency for UDP to establish a connection and avoiding head-of-line blocking. In addition, Google provides a very attractive feature, FEC (Forward Error Correction). Simply put, what it wants to do is that once a packet is lost, the receiver can infer the data of the lost packet from the previous and subsequent packet, thus avoiding retransmission. But this inevitably requires an increase in redundant load, or that is, RAID 5 in the network protocol. According to the data we have seen so far, the redundancy ratio is about 10%, that is, one packet can be reconstructed for every 10 pakcet redundant information.

Although Google's QUIC is very advanced, but QUIC is not the only one, IETF also has QUIC, which has now been renamed HTTP/3, so Google's QUIC sometimes writes gQUIC. Unlike Google, which basically uses HTTP/2 in the application layer, IETF's QUIC is a hybrid solution, which includes both changes in the transport layer and changes in the HTTP layer (such as new header compression). On the other hand, it is more "complete". Although theoretically, QUIC can also support other upper-level applications other than HTTP, but at present, this is just a plan, and the first version of QUIC does not include this aspect.

In November 2018, IETF officially announced that HTTP-over-QUIC had changed its name to HTTP/3. What this article discusses is that the IETF version of QUIC,Google has announced that it will gradually incorporate the IETF specification into its own protocol version and implement the same specification.

Although TCP has all kinds of problems, if it is changed to UDP, many functions of TCP also need to be transplanted as is. Many people know that TCP is a reliable transport protocol, while UDP is unreliable. Of course, HTTP/3 cannot be unreliable, so it must implement its own features such as ordering, error detection, retransmission, congestion control, transmission rhythm adjustment, and so on.

HTTP/2 "seems" to have to use HTTPS, but the specification does not force HTTP/2 to use HTTPS, that is, if you use HTTP to run HTTP/2, it is theoretically possible, although this is a bit weird.

In contrast, all connections to QUIC are encrypted, currently using TLS 1.3. If you look closely at the figure above, you will see that TLS 1.3 is "included" in QUIC, that is, QUIC completes the encrypted handshake during the handshake process of establishing a connection. The handshake of HTTP/3 is very fast. If a connection has been established between the two hosts and the previous secret is cached, as long as the client verifies the previously cached server config, the connection can be established directly, which is equivalent to 0-RTT, otherwise only 1-RTT can be used to establish the connection. In addition, QUIC also allows you to carry data from the start in the case of 0-RTT, and the traditional "establish a connection-encrypt a handshake-send data" can now take three steps and one step (the implementation of both 0-RTT and 1-RTT is very interesting, you should look for information if you are interested).

Although there is also a Connection in QUIC, which is also based on IP and port, it does not directly correspond to the connection in TCP, nor is it different from the connection in HTTP/2. The reason is that when QUIC establishes the connection, it completes both the classic transport handshake and the encrypted handshake-you can think that the hierarchical responsibility is not clear, but it does improve efficiency. QUIC connections are similar to HTTP/2, where a physical connection can also host multiple logical connections (that is, data streams). But unlike HTTP/2, the logical connections in QUIC are independent of each other, so it avoids the situation that "logical connection A packet loss leads to logical connection B, C, D all need to be retransmitted" on TCP.

Another feature of QUIC connections is that each connection has a set of connection ID. Each end of the connection can set its own connection ID and recognize each other's connection ID. The purpose of the connection ID is to logically identify the current connection. So, if the user's IP changes and the connection ID does not change, because the packet contains the network ID identifier, you just need to continue sending packets to re-establish the connection. At present, if the user's device has a network handoff, such as switching from Wi-Fi to 4G, all connections will be disconnected and reconnected.

If you have studied HTTP/2 in detail, you should know the HPACK used in its header compression, because gzip does header compression has security risks. HTTP/3 also provides header compression, but you can't follow HPACK directly. The reason is that, roughly speaking, HPACK is a dynamic table (dynamic table), which is jointly maintained by request-response. The subsequent header will not completely repeat the previous entry, but will refer to the previous entry. The order of TCP ensures that it must be modified and then read, that is, it must be encoded and then decoded.

However, if you use HPACK, the order of multiple streams cannot be guaranteed, which can lead to parsing errors. QUIC's solution is QPACK, and the principle is simple: all header must be transmitted over the same data stream and must be strictly orderly. But as a result, the head-of-line blockage that has plagued HTTP for a long time since HTTP 1.1 appears again. Therefore, one of the long-term goals of QUIC is to solve the problem of head-of-line blocking in header.

Friends who have done online upgrades know that a necessary component of online upgrades is to provide downgrade solutions to ensure "degradation" compatibility. Neither HTTP/2 nor HTTP/3 can evade this part of the workload. Although HTTP/2 can be upgraded through the header of upgrade, there is also a simpler way to negotiate the version of HTTP when TLS shakes hands. For example, Nginx has NPN (Nginx Protocol Negotiation) extension, automatic negotiation protocol, and has been adopted by IETF as ALPN (Application Layer Protocol Negotiation).

If web server has such a feature, the application service code does not have to do much to be compatible with HTTP 1.1 and HTTP/2. However, if you use new features such as Push in your application, you still have to do a lot of things. In the industry, Google, Youtube, Wikipedia and other big factories have already provided complete services, HTTP/2 and HTTP 1.1 seamless switching, the client is completely unaware, their experience is worthy of reference.

Unlike HTTP/2, a new header is defined in HTTP/3, which can be used to indicate that the client "provides a dedicated HTTP/3 service on another port."

Alt-Svc: H4 = ": 20003"

This header indicates that the HTTP/3 service is enabled on port 20003 of the host. So, the client can then try to establish a pure HTTP/3 connection to this port.

After talking so much about the benefits of QUIC, let's talk about it. Some views come from me personally and may not be accurate and objective enough. Welcome to discuss.

Although QUIC has so many benefits, you can see that it has quite a lot of changes compared to HTTP/2, so there will be no fewer problems.

The first issue is compatibility with legacy network equipment.

Based on the current application situation, many network devices have a fixed policy for TCP and UDP. TCP is limited to common ports, while UDP only opens 53 ports (DNS). So if HTTP/3 uses UDP, there may be a lot of compatibility issues that need to be addressed.

However, if this problem can be solved, it may not happen again in the future, because the future has already been considered in the design idea of HTTP/3, and the responsibilities of the application layer and the transport layer are strictly separated to avoid the situation that the transport layer knows what the application layer is doing at a glance at the port.

The second problem is the performance of QUIC.

Although TCP is also a very old protocol, it is widely used. There is corresponding processing code in the operating system kernel, and new features such as BBR can also greatly improve the performance of TCP. But QUIC gave up on TCP, according to Google's documentation, precisely because TCP is too stable and code updates in the kernel are particularly troublesome. In addition, because the expansion problem of multicore is not considered at the beginning of the design of Linux kernel, repeated traps will occur in the case of multicore (core), resulting in process blocking and serious impact on performance.

In view of the above problems, many new schemes put the network protocol stack into the user state, and QUIC also conforms to this trend. The only problem is that UDP's protocol stack does not seem to have a satisfactory solution ready-made, and we may have to wait a little longer before we can use a reliable and efficient solution.

The third problem is server push.

Although many people want this feature, and HTTP/2 does add it, there is still a lot of controversy about its use. To put it simply, HTTP/2 's push breaks HTTP's traditional "ask and answer" communication mode. When the client has no request, the server can send data to the client, which is bound to be abused (think of the messages that can be seen everywhere that like "business" most and do not like to talk about "morality" the least), although Chrome developers say they check the push and block malicious content. That is also to be done after receiving the push data, this scheme is not perfect.

At the same time, the server may insist on repeated push regardless of the client's cache, resulting in a waste of bandwidth. HTTP/3 retains the push, but the mechanism is different. The client needs to agree before the server can push. In addition, the client can set the upper limit of server push, and the push beyond the upper limit will make an error. However, there is no accepted and clear answer to how to make good use of push.

The last problem comes from debugging and supporting tools.

If any technology wants to be applied in large-scale engineering, it must not be possible to rely on "standard implementation" alone, because it cannot be sliced and fine-grained debugging. In the classic HTTP technology stack, each layer has corresponding tools, such as ping and traceroute in the IP layer, telnet in the transport layer and curl in the application layer. With these tools, developers can easily locate the level and details of the problem. Although HTTP/2 has been changed, there are a lot of debugging tools, which can be supported by curl, as well as nghttp2, H3C and other tools, which have initially formed a complete system. HTTP/3 has changed a lot, and without corresponding debugging support tools, it is conceivable that deployment and migration will not be easy.

After reading this, the article "what are the knowledge points of HTTP3" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself to understand it. If you want to know more about related articles, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.