Feature Overview

Quick UDP Internet Connections (QUIC) is an experimental transport layer network protocol. It provides the same security protection level as TLS/SSL and reduces the connection and transmission latencies. QUIC mainly applies to HTTP. HTTP/3 defined in RFC 9114 is based on QUIC. HTTP/3 provides all advantages that HTTP/2 has and stronger performance than HTTP/2 in poor network conditions because of QUIC features. QUIC was developed by Google. It was released in 2012 and submitted to the Internet Engineering Task Force (IETF) in 2013. In May 2021, IETF published QUIC as RFC 9000.

QUIC provides the following advantages:

Faster handshakes and connection establishment

QUIC-based connection establishment requires zero or one round trip time (RTT). QUIC improves handshake and connection establishment speed from the following aspects:

• QUIC uses UDP as its transport layer protocol, reducing the handshake latency in one RTT because UDP does not require a three-way handshake.

• QUIC uses Transport Layer Security (TLS) 1.3, the latest version of TLS. Compared with TLS 1.1 and TLS 1.2, TLS 1.3 allows clients to send application data without waiting for TLS handshakes to be completed. In addition, TLS 1.3 supports the 1-RTT and 0-RTT handshake modes.

When QUIC is used, TLS handshake negotiation completes in one RTT the first time a client connects to the server. When the client reconnects to the server, it uses the cached information to resume the TLS connection, requiring 0 RTT. Therefore, with connection establishment that mostly requires 0 RTT and rarely requires 1 RTT, QUIC has great advantages over HTTPs that requires 3 RTT for connection establishment.

Multiplexing that helps avoid head-of-line blocking

QUIC supports multiplexing. Compared with HTTP/2, streams in QUIC are isolated and independent from each other. If packet loss occurs on a QUIC stream, data transmission of other streams and data processing in the application layer are not blocked. Therefore, QUIC does not cause head-of-line blocking.

Connection migration

If you use your phone to join a remote meeting over a cellular network, the meeting client immediately tries to reconnect to the meeting server and instant video stalling occurs after you switch the network to a wireless local-area network (WLAN). Reconnection and stalling occur because TCP uses a combination of four items, including the source IP address, source port, destination IP address, and destination port, to identify a connection. After you change the network, the IP address of your client changes, and the TCP connection is instantly closed and then reestablished. Connection migration can help maintain the connection and your business uninterrupted when the value of an item changes. QUIC supports connection migration. QUIC uses a connection ID, a 64-digit random number, to identify a connection. Even if the source IP address or source port changes, the connection ID remains unchanged. Therefore, the connection remains, and disconnection and reconnection do not occur.

Pluggable congestion control

QUIC is a protocol that operates in the application layer. You can select pluggable congestion control algorithms such as Cubic, Bottleneck Bandwidth and Round-trip propagation time (BBR), and Reno. You can also customize private algorithms based on specific scenarios.

Forward error correction (FEC)

QUIC supports FEC. In a poor network environment in which packet loss may occur, QUIC dynamically sends FEC packets. This reduces the number of transmission retires and increases the transmission efficiency.

How It Works

eSurfing Cloud CDN uses QUIC in the 7-level Open Systems Interconnection (OSI) model to implement interactions between clients and CDN edge nodes. QUIC is suitable for transmission optimization in poor network conditions. The following figure shows how QUIC works.

Client Requirements

QUIC is a bilateral protocol and requires support from the client to initiate. The client requirements are as follows:

Browser: If you are accessing via a browser, please use a browser that supports the QUIC protocol, such as Chrome, Microsoft Edge, etc.
Custom App: If you are accessing via a custom app, the app needs to implement the QUIC protocol stack itself or integrate a network library that supports the QUIC protocol, such as quic-go, ngtcp2, quiche, quant, kwik, aioquic, picoquic, etc.

Applicable Scenarios

If you aim to achieve higher performance in weak network environments, such as faster first screen loading, faster initial data transmission, and higher transmission efficiency, you can use QUIC to access the CDN acceleration platform.

Configuration Instructions

This feature does not currently support self-service configuration by customers. If you need to use it, please contact our customer support team via hotline (852)31000000 or email global.noc@chinatelecomglobal.com, and they will manually enable it.

Please provide the following info:

Parameter	Description
QUIC version number	The version need to be cofigured, for example, H3-v1

Additional Considerations

eSurfing Cloud CDN supports IETF QUIC (iQUIC) and Google QUIC (gQUIC). This facilitates users to access CDN.

• eSurfing Cloud CDN supports Q043, Q046, and Q050 of gQUIC.

• eSurfing Cloud CDN supports H3-29 and IETF-v1 (H3) of iQUIC. It is recommended that you use iQUIC because it is the standard edition of QUIC.

Content Delivery Network