1 Feature Intro

1.1 Brief Introduction

QUIC (Quick UDP Internet Connection) is a UDP-based Internet transmission protocol which is developed by Google and is of lower latency. It is a new-round integration and utilization of the existing network transmission technologies between the application layer and the network layer, to improve the transmission efficiency and minimize latency. The core technologies of QUIC include: HTTP/2, TLS 1.3, TCP FAST OPEN and UDP.
QUIC protocol is originally used in the Chrome browser and YouTube video website. With the establishment of the IETF QUIC project team, and the IETF’s announcement in 2018 that QUIC protocol is going to be promoted as HTTP/3.0, QUIC has become widely discussed, applied and developed.
The development of CDNetworks QUIC is based on Google QUIC (gQUIC for short hereafter) version 39, 43 and 44, and it well solves the problems of bad access quality under weak network environments such as cross-ISP and cross-region network.

1.2 Applicable Product Lines

• Content Acceleration
• Dynamic Web Acceleration
• Media Acceleration
• Media Acceleration Live Broadcast

1.3 Application Scenarios

QUIC improves the performance of web application and streaming, especially under a weak network, it is applicable to the customers who have rigorous requirements on the quality and stability, such as real-time web application, cross-region live streaming, mobile live streaming/VoD customers.

2 Feature Detail

Standard gQUIC is functionally equivalent to HTTP/2 + TLS 1.3 + TCP, but implements on the top of UDP. It provides stream management equivalent to HTTP/2, security connection equivalent to TLS, and re-transmission, orderly transfer and traffic control mechanisms equivalent to TCP.

On the basis of the gQUIC protocol, CDNetworks developed the gQUIC scheme as below.

2.1 gQUIC scheme for CA/DWA/MA

In last mile, end-users can establish Quic connection with CDN edge PoPs, and there is no need for origin to change any configuration, CDN will go back to origin via TCP as normal.

2.2 gQUIC scheme for live stream pushing

gQUIC for live stream pushing uses an agent scheme of RTMP over QUIC, in which QUIC Agent plays the role of TCP agent to establish connection with client (Ingester) QUIC SDK, switches UDP to TCP and transfers the live-stream data transparently to the CDNetworks Media Center.
Note:
When using this scheme, customers need to use the port 1935/UDP to initiate push-stream requests.
QUIC SDK can be customer’s self-developed SDK or can be provided by CDNetworks. Customer’s self-developed QUIC SDK needs to be in compliance with standard QUIC protocol so as to work with CDNetworks QUIC feature.

2.3 gQUIC for live stream pulling

gQUIC live stream pulling scheme is available in two modes, which are RTMP over QUIC mode and HTTP over QUIC mode:

1. RTMP over QUIC mode
   It is similar to gQUIC live stream pushing, in which client (player) needs to integrate QUIC SDK. The QUIC Agent in the server side, playing the role of TCP agent, switches TCP to UDP and transfers the live video data transparently to the QUIC SDK of the player.
   Note:
   This mode only supports RTMP, HTTP/1.1 flv and HTTP/1.1 HLS transmission protocol;
   This mode also requires client to use port 443/UDP to initiate pull-stream requests.
   QUIC SDK can be customer’s self-developed SDK or can be provided by CDNetworks. Customer’s self-developed QUIC SDK need to be in compliance with standard QUIC protocol so as to work with CDNetworks QUIC feature.
2. HTTP over QUIC mode
   The QUIC Agent on the server side will establish the connection with the QUIC component of the player or browser (note: CDNetworks QUIC SDK integration is not involved under this mode), and change the formats of live streaming data at the CDNetworks edge server from HTTP/1.1 + TCP to QUIC HTTP/2.0 + UDP for the playback in the client browser or the player.
   Note:
   This mode supports HDL and HLS modes of standard gQUIC, which means the application transmission protocol should be the HTTP/2.0 stipulated by the standard gQUIC.
   This mode also requires client to use port 443/UDP to initiate pull-stream request.

3 Instructions

For Quic configuration of CA,DWA,MA, CSE/SRE can enable QUIC by changing domain configuration on CONF.
For HTTP over QUIC mode of MALB, CSE/SRE can enable QUIC by changing domain configuration on CONF.
For RTMP over QUIC mode of MALB, CSE will need to send an email with required info to product team for application. No extra CONF configurations are needed.

4 Notices

1. There is no Quic SDK for CA/DWA/MA, which means the customers’ app need support Quic as well.
2. QUIC protocol is a two-way acceleration protocol, which means that the client should also support QUIC protocol. For customers of Media Acceleration Live Broadcast, QUIC service can be enabled by embedding the QUIC SDK.
3. The difference of transmission quality between QUIC and TCP is not obvious when the network condition is good. However, the effect of QUIC protocol will become pronounced under the weak network environment.
4. Standard port is not defined in the QUIC protocol, so we need to make sure that the accessed client port is consistent with ours.
5. QUIC agent scheme has multiple implementation methods which are not necessarily compatible to each other. So, we need to confirm that the push-stream or pull-stream schemes used in client is compatible to ours.
6. gQUIC is still under updating, so please confirm that the gQUIC of client is in version 39, 43 or 44 before accessing.