Mobile Taobao uses content delivery networks (CDNs) for short videos and images. Mobile Taobao makes use of Alibaba Cloud CDN technologies to deliver better user experiences. One of these technologies is acceleration based on Internet Engineering Task Force Quick UDP Internet Connections (IETF QUIC). This topic uses Alibaba Cloud CDN as an example to introduce the application scenarios and effects of using IETF QUIC-based acceleration and the XQUIC library in Taobao Mobile.
Background information
With the rapid development of the Internet, network environments are also changing. The HTTP protocol has evolved from HTTP/1 to HTTP/3. HTTP/3 uses QUIC as the transport layer instead of TCP, which provides advantages such as stream multiplexing, zero round trip time (0-RTT) handshake, connection migration, and user-state congestion algorithms. Alibaba Cloud CDN closely follows the evolution of the QUIC protocol and implements the latest, from Google QUIC (gQUIC) to IETF QUIC, which has been deployed on Alibaba Cloud CDN points of presence (POPs) and has achieved considerable benefits in scenarios such as short videos and images.
QUIC is a new, multiplexed, and secure transport built on top of UDP. It provides lower connection and transfer latency, and has excellent performance under poor network conditions. Even when faced with severe packet loss and network latency issues, QUIC can still ensure service availability. This topic describes the technical features, application scenarios, and benefits of QUIC, as well as the best practices for implementing QUIC in business. Alibaba Cloud constantly promotes the development and implementation of QUIC to provide customers with the best experience.
Introduction to QUIC
When we visit video websites and apps, we often encounter various performance issues, such as slow page loading, video stuttering, and network errors. A key factor in these issues is the network protocol.
Evolution of HTTP
As a web protocol, HTTP has gone through several major upgrades:
HTTP/1.0 to HTTP/1.1: supports persistent connections and pipeline requests, and reduces the overhead of establishing connections by simplifying the TCP three-way handshake.
HTTP to HTTPS: adds Transport Layer Security (TLS) handshake to implement end-to-end encryption. The added security features, resulted in an increased time required to establish connections.
The HTTP/1.1 to HTTP/2: supports multiplexing and header compression for the request data stream, which improves the concurrency of a single connection.
In its evolution from HTTP/1.0 to HTTP/2, many changes were introduced, except for the transport layer, which remains as TCP. TCP is a reliable data transfer protocol that requires a three-way handshake, and is prone to head-of-line (HOL) blocking. QUIC, a reliable data transfer protocol based on UDP, was released to solve this issue. This paved the way for the next upgrade to HTTP.
HTTP/2 to HTTP/3: HTTP/3 is based on the QUIC protocol and has the characteristics of QUIC. HTTP/3 solves the HOL blocking problem and provides features such as TLS 1.3 0-RTT, multiplexing, and connection migration. QUIC was standardized in RFC 9000 in May 2021.
QUIC features
Low connection latency: QUIC is based on UDP and does not require TCP connections. Ideally, QUIC can transfer data in the 0-RTT mode. HTTPS is based on TCP, and transfers data in the 1-RTT mode even with the early data feature of TLS 1.3. However, with a complete handshake in TLS 1.2, HTTPS transfers data in the 3-RTT mode.
No HOL blocking: Although HTTP/2 implements multiplexing, TCP is still used in the transport layer. If a packet loss occurs, all request flows under multiplexing are affected. However, QUIC is based on UDP, which eliminates HOL blocking by design. In addition, HTTP/3 uses QPACK encoding instead of HPACK encoding, which also reduces HOL blocking of HTTP request headers to some extent.
User-state congestion control: The transmission control of QUIC no longer relies on congestion control algorithms executed by the kernel, but is implemented at the application layer. This means that different congestion control algorithms and parameters can be configured for different scenarios, and QUIC connections of a service can use different congestion control algorithms.
Connection migration: When a user's network changes, for example, from Wi-Fi to 4G, the user's IP address changes, TCP-based HTTP connections are lost. QUIC uses connection identifiers (CIDs) to allow connections to survive network changes and ensure reliable data movement.
Comparison between QUIC and TCP
QUIC is designed to solve the transport layer protocol issues that are inherent in TCP. The two protocols have the following differences:
Except for the 0-RTT and 1-RTT keys, QUIC uses a separate packet number space for each encryption layer. The isolated packet number space ensures that acknowledgments (ACKs) of packets are sent using one encryption layer and ensures idempotence.
The packet number of QUIC increases strictly according to the packet number space and directly encodes the transmission order. A larger packet number indicates that the packet is sent later, and a smaller packet number indicates that the packet is sent earlier. When a packet with an ACK frame is detected lost, QUIC includes a necessary frame in a new packet and adds a new packet number to confirm the packet when the packet is received. Therefore, a more accurate RTT can be measured to detect false retransmissions.
QUIC ACK frames contain information similar to selective acknowledgment (SACK) of TCP. However, QUIC does not allow the confirmation of data packets to be violated, which greatly simplifies the implementation for both the sender and receiver and reduces the memory pressure of the sender.
TCP supports three SACK ranges, and QUIC supports more ACK ranges. In network environments with a high rate of packet loss, QUIC accelerates packet recovery and reduces false retransmissions.
In TCP, RTT is calculated using the timestamps when the packet is sent and when the packet is received, without considering the host delay. QUIC uses the delayed ACK mechanism to obtain a more precise RTT measurement.
QUIC uses the probe timeout (PTO) mechanism instead of retransmission timeout (RTO) and tail loss probe (TLP) used by TCP.
TCP uses the minimum congestion window for a packet. If a single packet is lost, the sender must wait until the PTO is exceeded to recover the packet. When the receiver delays the confirmation, sending a single ack-eliciting packet causes additional delay. Therefore, The recommended minimum congestion window for QUIC is two packets. Although this increases the network load, it is considered to be more secure. In the case of continuous congestion, the sender reduces the transmission rate exponentially.
Use scenarios
Dynamic requests (API operation and signaling transmission): reduces time consumed in dynamic interactions.
Short videos: improves instant loading and reduces stuttering.
Image files: reduces the download time.
Live streaming: reduces the playback stuttering and improves stream ingest stability.
Advantages
Quick connection establishment: 0-RTT handshake reduces the time for required for the TCP and TLS handshakes and improves instant loading.
Multiplexing: Compared with HTTP/2, QUIC uses true single-channel parallel transmission, which eliminates HOL blocking in TCP.
Congestion algorithms: Flexible congestion algorithms are not restricted by the kernel or the OS, and can be directly modified at the application layer.
Persistent connections: Frequent network changes do not terminate connections and are imperceptible to users
Evolution of QUIC in Alibaba Cloud CDN
Taobao Mobile and Alibaba Cloud started cooperation on gQUIC in 2018, mainly in scenarios such as image and short video delivery in Taobao Mobile. In early 2019, they had a consensus to standardize the protocol. From the perspective of commercial products, private protocol solutions are more difficult to be recognized by users. On the other hand, the design and security of standardized protocol are more comprehensively considered.
When the specifications were released, there were no mature or suitable implementations of the IETF QUIC for mobile devices in the industry. Therefore, Taobao Mobile started the proprietary XQUIC project. After one and a half years of development and optimization, XQUIC was launched in June 2020. In early 2021 Taobao Mobile integrated with IETF QUIC of Alibaba Cloud CDN, and gradually applied IETF QUIC technologies in short video scenarios. In September 2021, Alibaba Cloud CDN implemented the large-scale application of the IETF QUIC protocol stack in short video scenarios. After that, Alibaba Cloud CDN was subject to the actual stress of handling the Double 11 Shopping Festival in the same year. XQUIC and Alibaba Cloud CDN delivered amazing results in terms of performance and stability. Shortly after that, Alibaba Cloud CDN open sourced XQUIC on January 7, 2022, and supported the release of the new IETF QUIC product for Alibaba Cloud CDN.
Alibaba Cloud CDN is mainly uses QUIC for short video scenarios in Taobao Mobile. The best practice solution is to use the combination of XQUIC protocol stack on the devices and QUIC of Alibaba Cloud CDN. The improvements of network experience in short video scenarios in Taobao Mobile include 20% shorter time for downloading short videos and 10% less stuttering. Due to the satisfying improvements, the Alibaba Cloud CDN team will further apply the acceleration technologies in more scenarios such as images. The team will also provide the best practice to bring a better experience to customers of cloud products.
Best practice of using the XQUIC library on devices
The XQUIC library is a lightweight, high-performance, standardized cross-platform protocol library.
The complied XQUIC library on Android and iOS devices is smaller than 400 KB, which eases the installation for new users and minimizes the package size of mobile apps. Therefore, XQUIC is suitable for mobile apps that require high performance but are sensitive to package size.
In terms of high performance, XQUIC has been widely implemented for shopping guides and short videos on Taobao Mobile. For example, when you search for products in Taobao Mobile or browse videos in Taobao Time, XQUIC provides faster network data transmission services in these scenarios.
In terms of standardization, XQUIC implements a complete set of standard IETF QUIC protocols, including the protocol stack for the transport layer, encryption layer, and application layer.
As for cross-platform capabilities, our network library supports Linux, Android, iOS, and macOS, and will also support Windows in the future. Clients can easily access and use the library through SDKs.
XQUIC provides the three-layer protocol stack included in IETF QUIC. XQUIC runs on the client as an SDK. On the server, it can be used by connecting the module to the Tengine or NGINX framework. In addition, for scenarios where content distribution networks are used on mobile devices, XQUIC is optimized in terms of protocol interoperability, 0-RTT ratio improvement, and compatibility of plaintext and ciphertext modes. For example, in terms of compatibility of plaintext and ciphertext modes, Alibaba Cloud CDN not only supports the cipher suite recommended by standard TLS 1.3, but also provides the plaintext mode. In addition, adaptive negotiation can be realized by using application layer protocol negotiation (ALPN) parameters in the handshake phase, and compatibility with standard ciphertext mode is guaranteed. In terms of 0-RTT ratio improvement, Alibaba Cloud CDN optimizes the cache policies of server config and token. The 0-RTT ratio can reach more than 68% on mobile devices.
The combination of the XQUIC library and QUIC of Alibaba Cloud CDN can deliver better experience to users. For more information about how to configure QUIC , see Configure the QUIC protocol.