HTTP/3 is on its way. Are you ready?

This time last year, the domestic Web network environment began to popularize and deploy HTTP/2. A year later, the popularity of HTTP/2 has increased significantly, and the breadth and speed of the popularity of major CDN vendors has been leading the industry. Many CDN vendors even introduce QUIC in live broadcast and some HTTP scenarios.

In my article, What are we talking about when we talk about HTTP header blocking? , we mentioned that HTTP/2 over QUIC is the only current HTTP implementation that uses ground to solve the transport layer queue header blocking problem. At that time, both HTTP/2 over TCP and HTTP/2 over QUIC(UDP) were considered HTTP/2, but the transport layer used different protocols. The vaguely ambiguous term passed into history in November 2018:

During a mailing list discussion on 28 October 2018, Mark Nottingham, chair of the Internet Engineering Task Force (IETF) WORKING Group on HTTP and QUIC, made a formal request to change the name of HTTP-over-Quic to HTTP/3, To “clearly identify it as another binding for HTTP semantics… Make people understand how it differs from QUIC, “and inherit the QUIC working group from the HTTP working group after finalizing and publishing the draft. Following several days of discussion, Mark Nottingham’s proposal was accepted by IETF members, who gave official approval in November 2018 for HTTP-over-Quic to become HTTP/3.

While this may seem like a change of name for the previous HTTP/2 over QUIC (from my perspective, HTTP/2.1 would be more appropriate), it is a reflection of the IETF’s attitude and direction towards the future standard of HTTP. Perhaps in a few years’ time the significance of this designation will become clearer.

HTTP/3 and HTTP/2 over QUIC

QUIC will become a general purpose secure transport layer protocol

At the current stage, Google’s implementation of QUIC is incompatible with the IETF implementation of QUIC. The Google version of QUIC is only available for HTTP/2 and has some strong binding with HTTP/2 at the protocol level. For example, QUIC frames map HTTP/2 frames. As a result, many large manufacturers did not follow up QUIC, making HTTP/2 over QUIC basically only available in Google’s own Chrome, Gmail and other software. For a time to the industry caused “only Google in the” illusion.

With its inclusion in the IETF, it is clear that Google can no longer play this way. QUIC is positioned as a generic secure transport layer protocol:

It can be approximated that QUIC over UDP will be the next generation (or replacement) of TLS over TCP. In other words, QUIC will be able to be applied to any application layer protocol, except for the current phase of application and validation in HTTP first.

TLS 1.3 is used as the security protocol

In 2018, several important WEB standards were finally settled, one of which was RFC 8446 TLS 1.3. This standard is important for reducing latency and improving the user experience, especially on mobile. In the article “How TLS1.3/QUIC can do 0-RTT”, we mentioned that while both TLS1.3 and QUIC can do 0-RTT to reduce latency, QUIC implemented a set of security protocols on its own. This was mainly because the TLS 1.3 standard had not yet been released and QUIC required a set of security protocols:

The QUIC crypto protocol is the part of QUIC that provides transport security to a connection. The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.

Now that the TLS 1.3 standard has been released and HTTP/3 is included in the IETF, it makes sense for QUIC to use TLS 1.3 as its security protocol. Google has never been a chicken and ink blob in these areas, thumbs up.

Use QHPACK header compression instead of HPACK

In fact, the design of QPACK is very similar to that of HPACK. QPACK alone is mainly to better adapt to QUIC, and it is also a necessary step for Google to pull QUIC out of the coupling with HTTP/2 and complete the unification with IETF standards.

HTTP/3 Issues and Challenges

The UDP connectivity is faulty. Procedure

Almost all telecom operators “discriminate” against UDP packets, and it’s easy to understand why, given that several notorious DDoS attacks in history have been based on UDP. In some areas, the broadband in a city directly prohibits UDP packets that are not from port 53. However, other carriers and IDC strictly limit UDP packets even if they do not block UDP packets. This is not optimistic, but we believe that carriers will gradually change their discriminatory policies against UDP traffic as standards become more widely available and implemented. The picture is a little better abroad, with less than 10% of their QUIC deployments downgraded, according to Google.

QUIC does not support plaintext transmission

For users, this is an advantage, not a problem. For the domestic content censorship environment is not negligible. But QUIC is also based on TLS protocol after all, domestic HTTPS can be popularized, the popularity of QUIC may be more optimistic.

UDP consumes a lot of resources

At the current stage, UDP consumes a lot of CPU resources and the processing speed is slow. This is true, but I believe that as UDP is used more and more, kernel and hardware optimizations will continue to match or exceed TCP performance. Because QUIC is implemented at the application layer, the iteration speed is faster and the deployment and update difficulty and cost are smaller, which can alleviate the rigidity of protocols such as TCP to a certain extent.

Learn more about HTTP/3

Daniel Stenberg (author of CURL) explains HTTP/3 explained.

– EOF –