QUIC在CDN节点间的技术落地

背景

在现有物理资源的情况下，CDN海外机房回源、回传延迟较高，RTT最高有几百毫秒，TCP丢包率和成功率表现也不尽人意，一个大视频分片的上传下载需要几秒时间。而QUIC的特性在网络传输，尤其是弱网情况下，效果相比TCP好很多。多段256 NACK、更加激进的Loss Detection丢包探测和重传机制、以及0-RTT的握手建立，使其相比TCP的传输延迟大大降低。

1.封装QUIC Client SDK

QUIC运行在用户空间，底层使用UDP作为传输协议。客户端侧主要涉及QuicConnection、QuicStream、QuicSession三个核心功能类。

◎QuicConnection：负责管理QUIC连接，创建Connectionid，完成QUIC的握手（1-RTT/0-RTT），确保连接建立。

◎QuicSession：会话管理，管理QUIC整个会话的生命周期。包括QuicConnection、各种定时器Alarm、以及多Stream的生命周期等。

◎QuicStream：QUIC真正进行数据传输的媒介，支持多个QuicStream并发传输，Stream之间的数据丢包重传等互不影响，真正消除TCP协议的队头阻塞缺陷。

QUIC协议在应用层实现了原本TCP几乎所有的特性：传输窗口、ACK、多路复用、Loss Detecion、流量控制、拥塞控制等等，非常复杂。

所以在工程实现上我抽取了chromium的net库等

重载QuicStream、QuicSession等，封装成易于理解的QUIC Client SDK，提供quic_socket、quic_connect、quic_send、quic_recv等开发者比较习惯的socket使用方式API。

图1. QUIC Client SDK

2. QUIC Client 在MCP++框架上的应用

MCP++框架主要是DCC模块负责对外的请求下载等，在CDN上的应用的话，Front节点的回源、回传都需要通过DCC去下载和上传。

◎ QUIC由于其复杂的特性实现，运行在应用层的协议栈，需要大量的CPU计算。

◎ 以及QUIC Client自成一体的UDP Socket收发，DCC原本的epoll_wait单线程模型无法支持，很