Part 01

What is QUIC 

QUIC (Quick UDP Internet Connection) is a UDP-based transmission protocol proposed by Google. Because of its high transmission efficiency and multi-channel concurrent capabilities, it has become the underlying transmission protocol of the next-generation Internet protocol HTTP/3. In May 2021, IETF Published RFC9000, the QUIC specification launched a standardized version. In addition to being used in the Web field, its advantages are also applicable to some general transmission scenarios that require low latency and high throughput.

It can be seen from the protocol stack: QUIC = HTTP/2 + TLS + UDP

Part 02

Why QUIC 

From the original HTTP/0.9, HTTP has experienced several major iterations of HTTP/1.x, HTTP/2 to the latest HTTP/3. Before the HTTP/3 version, the bottom layer of HTTP used TCP to transmit data. With the development of the mobile Internet, network interaction scenarios are becoming more and more abundant and require timeliness. The inherent performance bottleneck of traditional TCP is increasingly unable to meet the demand. The reason There are the following points:

- The handshake delay for establishing a connection is large

HTTPS includes two handshakes: 1) TCP three-way handshake, 1 RTT; 2) TLS handshake, 2 RTT. A complete handshake requires a total of 3 RTTs. For scenes such as live broadcasts that require the first frame to start in seconds, the handshake delay is too large.

- Multiplexed head-of-line blocking

Taking HTTP/2 multiplexing as an example, multiple data requests are sent as different streams through a common TCP connection, and all stream application layers must be processed sequentially. If the data of a stream is lost, the data of other streams will be blocked until the retransmission of the lost stream data is completed, and other streams can not continue to be transmitted. Even if the receiving end has received the subsequent data packets, the HTTP protocol will not notify the application layer to process them.

- The update lag of the TCP protocol

The TCP protocol is implemented in the operating system kernel, but it is very difficult to upgrade the operating system version on the client side. Many old systems are still used by a large number of users, so some updates of the TCP protocol are difficult to be quickly promoted.

Considering the above problems, QUIC implements functions such as packet loss recovery, congestion control, encryption and decryption, and multiplexing based on UDP on the application layer, which can not only optimize the handshake delay, but also completely solve the problem of kernel protocol update lag .

Part 03

The process of QUIC establishing a connection 

The steps to establish a connection in QUIC are relatively simple, and the process is as follows:

1) The client initiates Inchoate client hello;

2) The server returns Rejection, including the public key information of the key exchange algorithm, algorithm information, certificate information, etc., which are put in the server config and sent to the client;

3) The client initiates client hello, including the client public key information.

At this point, both parties have calculated the symmetric key respectively. QUIC's 1 RTT connection establishment process ends, and the average time only takes less than 100ms. In the subsequent process of initiating a connection, once the server config is cached or persisted by the client, it can be reused and combined with the locally generated private key for encrypted data transmission, without needing to shake hands again, thereby achieving 0 RTT to establish a connection.

Part 04

Advantages and disadvantages of QUIC 

4.1 The advantages of QUIC are reflected in the following aspects:

(1) Strong scalability. Changing TCP is not easy because the middleware in it resists updates, and the optional bits of TCP's 40 bytes are almost completely filled. TCP does not have any version negotiation (version negotiation) extension bits. In contrast, QUIC has 32 bits, so it has a lot of space to deploy new versions, and manufacturers can also use these spaces to define their own exclusive versions.

(2) User space is easy to implement. QUIC can be implemented at the application layer, and it can be updated much faster than TCP implemented in the operating system kernel. This further improves the scalability of QUIC, allowing services to evolve very quickly so that new features are deployed daily. At the same time, it can achieve higher responsiveness by invoking less overhead during context switching.

(3) Establishing a connection is faster. Web browsing in particular requires fast connection establishment because users often open multiple, short-lived connections. When using HTTPS, TCP requires a "three-way handshake" and subsequent TLS protocol settings before establishing a connection. QUIC (based on UDP) does not require a three-way handshake, plus it exchanges security keys during the initial handshake, making it twice as fast when establishing an encrypted connection.

(4) The packet loss sensitivity is low. When using TCP, if a data packet is lost, all subsequent data packets will stop transmitting until the lost data packet is sent. This phenomenon is called "head-of-line blocking", and it will cause a significant increase in delay. In contrast, QUIC uses a multiplexing mode similar to HTTP/2, which can support multiple data streams at the same time. If one data stream is sent incorrectly, resulting in packet loss, the other data streams continue to send packets without blocking transmission.

(5) The performance improvement when switching networks is higher. When switching networks, QUIC can achieve a smooth transition. For example, when you use your home Wi-Fi to watch videos on your phone, and then you walk out of the house, your home Wi-Fi switches to LTE; or when you have been busy watching videos and moving between different mobile base stations; In these scenarios, TCP will cut off the connection and create a new connection through a new network, which will affect your viewing experience, while QUIC can achieve seamless connection.

(6) High security and privacy protection. QUIC has encryption built into the transport layer, thereby authenticating the entire payload (including headers). TCP does not include encryption in the header, making it very vulnerable. QUIC supports secure TLS by default, which means end-to-end complete security.

4.2 The disadvantages of QUIC are reflected in the following aspects:

When TCP was invented, the network was wired and quite reliable. QUIC improved the unreliable and unpredictable wireless connection, but it did not change the essence of Internet transmission. Its limitations caused it to only change some specific usage Scenes. Some additional QUIC limitations are listed below:

(1) Migrating apps faces huge challenges. Migrating an app from HTTP/2 to HTTP/3 (or from TCP to UDP) takes a lot of effort. The whole process needs to transfer the application layer implementation and transport layer implementation to UDP, and build a new solution on the server and client. This is undoubtedly a challenge for small manufacturers with relatively limited resources in the streaming media field, and it also explains why technology giants such as Google and Microsoft can take the lead in adopting the QUIC protocol.

(2) Adoption is limited. The biggest problem with QUIC is that its adoption is still limited. Almost every browser accepts the use of QUIC for simple web browsing, but apart from chromium, no browser has it set as a default option. In addition, in the field of streaming media, apart from Google and Facebook, few companies use QUIC. Only a few CDN providers support QUIC, and some of them have only verified QUIC implementations and are not ready for large-scale deployment. This poses a problem: if you launch a new service that uses multi-CDN and is based on QUIC, only 20% of the visits will use QUIC, because you can't prove to users that it has a significant impact on user experience.

(3) QUIC includes a TCP fallback. QUIC is built on top of UDP in part because very few middleware and networking devices intercept UDP. But there is a real risk of being intercepted, so QUIC-based apps must be designed to fall back to TCP, just in case. This means that developers of apps (based on QUIC) are heavily burdened to develop and maintain two different versions at the same time (due to TCP fallbacks and limited adoption). The good news is that with the latest DEVOPS structure and the use of HTTP's Alt-Svc tags, supporting both protocols is much simpler than it used to be.

(4) Unable to inspect packets. Network firewalls cannot decrypt QUIC traffic to inspect packets, so there is a high chance that potentially malicious traffic can enter the network without being detected by standard security features. As a result, security vendors such as Cisco and Palo Alto Networks typically intercept QUIC packets (thinking they contain malware) on ports 80 (web servers) and 443 (TSL), forcing clients to fall back to HTTP/2 and TCP. However, the above operation will not significantly affect the content user experience, because the streaming media service implemented correctly will fall back to TCP+TLS by default, but this operation may prevent the idea of ​​deploying QUIC first. Only by solving this challenge can QUIC be widely accepted by major enterprises.

Part 05

The use of QUIC in actual scenarios 

5.1 Application prospects of QUIC in MQTT communication scenarios

MQTT is a TCP-based communication protocol for the Internet of Things. The compact message structure can achieve stable transmission on severely limited hardware devices and low-bandwidth, high-latency networks; many features such as heartbeat mechanism, will message, and QoS quality level can handle Various IoT scenarios. However, due to the limitations of the underlying TCP transport protocol, the MQTT protocol has inherent disadvantages in some complex network environments:

• Network switching causes frequent connection interruptions;
• Difficulty re-establishing connection after network disconnection: the operating system releases resources slowly after network disconnection, and the application layer cannot perceive the disconnection status in time, and the Server/Client overhead is large when reconnecting;
• Data transmission in a weak network environment is limited by congestion, packet loss detection and retransmission mechanisms.

For example, Internet of Vehicles users usually face similar problems: Vehicles may run in mountainous areas, mines, tunnels, etc., and when they enter a signal dead spot or passively switch base stations, the connection will be interrupted, frequent connection interruptions and slow connection recovery Speed ​​can lead to poor user experience. In some services that require high real-time and stability of data transmission, such as L4 driverless driving, customers need to spend a lot of money to alleviate this problem.

In the above-mentioned scenarios, the characteristics of QUIC's low connection overhead and multi-path support show its advantages. Based on QUIC's 0 RTT/1 RTT reconnection/creation capabilities, it can effectively improve in weak and unfixed network paths. user experience.

5.2 Application of QUIC Protocol in CDN Acceleration

A traditional CDN will have a multi-level structure, and each level will have different heat data. There is a large amount of communication data between CDN nodes, and the path for distributed storage of these data has a very important impact on the final CDN service quality. Generally speaking, factors affecting communication quality are usually affected by the nature of the cached business content, the network connection between nodes, and the transmission architecture and mechanism on the client-server side. The performance of data fetching between these layers will directly affect the delivery response speed of the overall CDN. Usually, further transmission between ultra-distance nodes can be realized by means of TCP optimization (data connection pool, TCP optimization), cache data block, high-level data push to low-level data, cache data pre-fetch, data compression, etc.

In this case, the advantages of QUIC are revealed. CDN QUIC service is fully optimized for business scenarios, including 4 aspects:

• Connection optimization 0-RTT connection multiplexing rate, reducing connection delay.
• Encryption and decryption optimize plaintext transmission, which can reduce some impacts caused by encryption and decryption.
• Transmission optimizes out-of-order message buffering, and adjusts for special data priority requirements.
• Adjust parameters for different online business scenarios, and use congestion algorithms to improve the effect in different business scenarios.

Part 06

Summarize 

This article mainly gives a brief overview of the conceptual background of the QUIC protocol and the advantages and disadvantages of the protocol. At the same time, it gives examples of the application scenarios of the protocol, so that everyone can have a preliminary understanding of the protocol. At present, large Internet companies using this protocol are using it in different business scenarios, and have achieved good performance improvements. China Mobile is also actively exploring new technologies to change life with technology.