导语：QUIC (Quick UDP Internet Connection，快速UDP互联网连接) 是新的基础UDP多路复用安全传输协议。它从头开始设计，完全弃用TCP，使用UDP作为底层传输协议。QUIC提供等价于HTTP/2 多路复用和流控等于 TLS 安全机制和等价 TCP连接语义、可靠性和拥塞控制。根据国际互联网工程任务组（The Internet Engineering Task Force，简称 IETF ）消息，HTTP-over-QUIC 实验协议将被重命名为 HTTP并有望成为/3 HTTP 第三个正式版本的协议。
本文将介绍QUIC协议在CDN与技术相比，腾讯多媒体的应用落地，TCP试着分析它带来的快速优化体验QUIC快在哪里？
1、背景
在现有物理资源的情况下，CDN海外机房回源、回传延迟极高，RTT最高将近500ms，TCP丢包率和成功率表现不尽如人意，上传下载大视频片需要2秒。而QUIC与网络传输特性相比，特别是在弱网的情况下TCP好很多。多段256 NACK、更加激进的Loss Detection以及零-RTT与之相比，建立了握手TCP传输延迟大大降低。
2、封装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。
2、QUIC Client在MCP++框架上的应用
MCP++框架主要是DCC模块负责下载外部请求等。CDN上应用，Front节点的回源和回传都需要通过DCC下载和上传。
1)、QUIC由于其复杂的特性，在应用层中运行的协议栈需要大量的协议CPU计算。2)和QUIC Client自成一体的UDP Socket收发，DCC原本的epoll_wait单线程模型线程模型，难以改造。所以决定采用 DCC线程 + QUIC线程 的模型支持QUIC协议，QUIC Client线程保持高度自治，要求和响应自我完善。DCC原连接管理，CRawCache等待自己实现。
图2所示，DCC与QUIC交互主要有两个过程，不破坏现有DCC框架：
1、send_mq_request_by_quic负责将来自mq的请求发给QUIC，由quic创建UDP socket发出去。handle_network_recive_quic负责从队列queue里取出QUIC接收处理后的响应信息。QUIC请求流程和失败返回TCP机制由于QUIC底层通过UDP在大规模服务场景下，数万台机器生活在不同的运营商和网络环境中，无法保证各种中间设备UDP可以使用端口。因此，设计不能完全依赖。UDP可信，要考虑失败的回归TCP机制。
DCC与QUIC的交互有send_mq_request_by_quic， handle_network_recive_quic发送和接收分为发送失败和接收失败。
DCC->QUIC请求流程：
QUIC->DCC响应流程：
1、 QUIC接收校验后check_complete之后，将响应消息列入队列queue。
2、DCC线程send_mq_request_by_quic从队列Dequeue 取出响应信息。
a. QUIC_SUCCESS，将响应消息enqueue 发给mcd。b. CONN_ERROR，中断连接，将quic消息传来TCP重发，flow连接回退到TCP。0-RTT场景下，quic_connect()发出去CLHO后client端是连接成功，调用quic_send()发送数据(数据缓存QUIC底层buff）， 实际握手可能会超时失败。OnConnectionClose 失败后需要通过queue通知DCC相应处理线程。
4、0-RTT
QUIC比TCP快速握手的一个很大特点就是握手少了。RTT，甚至达到0-RTT握手，直接传输数据，与TCP三次握手的等待时间大大减少。CDN更进一步的应用，front->zone除了第一次，分布式集群中所有机器之间的要求可以在未来实现0-RTT建链。
背景：QUIC handshake服务端握手阶段REJ时会下发server_config和token给客户端。下次客户端握手时，如果携带上次发布的产品server_config和token到服务端，服务端验证通过实现0-RTT。
在当前的CDN在架构上实现0-RTT，有几个问题需要解决：
问题：
问题1. 服务端front有多个ccd过程，每个过程生成server_config都不一样，客户端最后一次携带server_config请求到其他ccd过程中，服务端验证失败，无法0-RTT？问题2. 客户端ip不固定，4G/WIFI每次切换都会改变ip，服务端发布token整合客户端ip，客户端的ip变化时，携带token服务端验证失败，无法0-RTT？问题3. 服务端ip客户端不是固定的，服务端是，要求新服务器ip如果是现在client没有要求这个server_id，本地没有新的缓存server的cache(server_config等等)，0能实现-RTT。解决方案：
解决方案1：所有服务端front固定生成相同的集群server_config_id。解决方案2：关闭服务端token验证开关，QUIC提供关闭验证的开关可闭验证的开关。解决方案3：每次客户端构建新的请求连接时，使用相同的请求连接server_id(host,port)。Server_id用于引导客户端本地缓存cache的key， 对于客户端来说，这相当于把所有对端server集群被视为同一个server，对同一个server下次握手会直接启动full CLHO消息。验证服务端server_config通过，可以建立新的连接。5、QUIC对比TCP的优化效果
在线灰度观察效果，QUIC优化效果明显。特别是在弱网下，传输延迟大大降低：
a)、以长沙电信为例，回源延迟219ms -> 88ms，优化效果可达59.8%，回传延迟较低，延迟优化效果可达25%。
b)、海外以美国点为例，RTT高场景196ms，QUIC回源回传效果更明显1.3s->339ms，73.9%的优化率。
6、QUIC快在哪里？
QUIC提升效果这么好，到底比TCP快在哪里？TCP经过几十年的发展，协议可以说构建了整个互联网的基础。Google为了开发QUIC我做了很多工作，基本上完成了整个工作TCP协议栈重新实现(取其精华，修复缺陷)。试着分析一下:
1. 0-RTT
TCP三次握手带来一定的1-RTT消费，在网络条件较好的情况下，大部分消费可能来自业务，不觉得RTT这需要很多时间。但在网络条件差的情况下(如上述美国)，一个RTT就带来196ms延迟，使用QUIC经过优化，可以看出整体耗时只有339ms，所以0-RTT是秒开业务的重要特点。
2. QUIC Stream多路复用 — TCP 队头阻塞
QUIC支持多路复用，QUIC的底层UDP不进行排序和确认，只负责传输，ACK、确认、排序等QUIC进行。TCP当多个流量同时传输时，如果一个流量丢失，其他流量需要等待重传排序完成才能继续传输，因为TCP只有一个滑动窗口，无法避免队头堵塞。而QUIC的多个Stream重传、排序等互不干扰stream水平流控窗，真正从传输层解决队头堵塞的问题。
从客户端和CDN根据服务器的统计，同一连接多个Stream与此同时，传输场景非常频繁。除了队头的阻塞QUIC延时比TCP低很明显，在弱网丢包率高的情况下表现更好。
3. Up to 256 NACK ranges，支持256分段ACK
TCP每次只会ACK当滑动窗口耗尽时，一个数据包只能等待新的ACK新数据包只有到了才能继续发送。即使打开了SACK，最多也只能ACK三个包。
QUIC最大支持ACK 支持分段的256个数据包ACK。就算某个ACK包丢了，后续其他包丢了。ACK也可以带上以前ACK过的包号。
4. Loss Detection丢包探测
QUIC在TCP在经验的基础上，重建了一种新的丢包探测机制：FR快重传、ER早期重传、RTO、TLP、F-RTO，和TCP与众不同。表现为更激进的丢包发现和重传策略:例如，如果你收到最多的ACK如果包号大于3，则判断丢包FR重传；而TCP需要连续三次收到重复ACK判断丢包快速重传。
7、总结
本文介绍了当前主流的基础chromium的QUIC Client SDK腾讯及其在腾讯的架构MCP++框架上的工程落地。详细介绍了MCP++框架上的 DCC+QUIC 多线程lib方案，和QUIC回退到TCP此外，简要介绍了保障机制 0-RTT 在 Front->zone 实现存在的问题和解决方案。在线使用QUIC与TCP实际对比效果，QUIC多路复用、256NACK国内各大厂商都在研究和应用优秀的特点QUIC协议，证明QUIC是一项潜力巨大的技术。IETF已经将HTTP over QUIC重命名为HTTP三、下一代HTTP三是协议的普及，QUIC应用更广泛。
欢迎关注微信官方账号:昭景成（id：zhaojc10），BAT大厂攻城狮，和你聊职场，聊技术，聊互联网上的事情。
