网络传输协议之QUIC(音视频基础知识篇)

据非官方说法，2015年被定义为中国互联网视频直播元年，笔者有幸在当年响应互联网大潮，试水了视频直播业务，但当时的关注点主要是如何让直播内容吸引眼球，获取更大的用户群来融资，内容为王；至于技术方案，是能work就好。采集端用OBS，然后用Qt对UI和功能进行了适配和封装，变成了我们的独家直播软件；直播内容在OBS端 RTMP推流后，采用了第三方厂商提供的视频处理转码以及CDN分发服务，选了几家当时业内比较出名的视频云供应商，在全国东西南北中五个地方抽样人工测试了一下直播的点播的效果就敲定了；最后一公里接入到我们的手机App播放端，然后开始唱戏。结局是做了接近一年之后发现无法盈利，于是业务转向了更热门的智能投顾业务，我的互联网视频工作经历暂时告一段落。

短短三年过去，互联网视频现已如日中天，成为互联网生态的重要组成部分，而且依然处在上升势头。但是，行业的关注焦点已经发生转移，大浪淘沙后，焦点已从初期所关心的从0到1的业务及内容创新，转变为现在的精品内容制作下的高质量输出和感官体验。

当提供的视频内容的品牌和利益范围经过市场的充分竞争而趋于平衡后，互联网视频大厂讨论的最多的就是体验，绞尽脑汁想要留住客户的就是如何提升用户体验，引用同事的一句精辟观点就是如何做到“清晰”+“流畅”。清晰，强调的是画面效果、高分辨率，高帧率等等；流畅，强调的是低延迟，天下武功，唯快不破，不要去挑战用户的耐心。

视频传输的流畅度划分

说到流畅度或者延迟，如果直接问什么是流畅，什么是延迟，延迟多久是极限？这让人很难回答。虽然都是延迟，不同场景下的用户对延迟的忍耐度其实是不一样的，下表粗略列出了延时程度的划分：

既然不同场景下人们对延迟的忍耐程度是不一样的，考虑延迟优化方案时就要具体场景具体分析。

上图会让人联想到很多类似的有关质量制衡的三角关系，比如：

• 项目质量管理常拿来做挡箭牌的质量守恒定律：时间、人力、需求的制衡关系

• 分布式架构领域里的CAP原则：一致性、高可用、可扩展之间的制衡关系

视频质量的制衡关系也类似：低延迟、高可扩展性和高质量三者都同时实现显著提升是不大现实的。在研发投入成本一定的情况下，具备某两种特点，则需要在另外一点上做少许妥协，每个企业需要根据自己的业务场景来选择应该提升那些，应该妥协哪个。

如当延迟至关重要的时，例如视频会议或视频安全监控，可以牺牲扩展性或质量；另一方面，在线性广播中大规模传送高质量媒体内容时，延迟通常会略微增加。因此，平衡三角形的理想位置取决于具体场景。在大多数情况下，可以通过配置媒体管道中的不同组件参数来移动三角形的平衡位置。

降低传输延迟的方法论

一个视频从采集到播放主要经历以下几个步骤。若想提升视频体验，除高清度之外，就要考虑从各个阶段来降低它的延迟，然后再根据二八原则分而治之。

• 采集延迟

主要是各种高性能摄像头、硬件芯片等，要求高性能低功耗，属于硬件设计的范畴，它不是优化延迟的主战场。

• 编解码延迟

优化延迟的主战场之一，编解码算法越高效，压缩率越高，单位传输内容信息量就越大。当然，编码除了为降低延迟，还要为画面质量而战，不能因为高压缩而过多损失画帧的质量。所以编解码技术一直是视频研究领域的一颗明珠，得标准者得天下。另外除了算法和标准，如何实现也有高低之分，有的利用软件实现，即主要使用CPU计算来做编解码；有的直接用专门的编解码硬件芯片来做，使速度得到进一步提升。

• 传输延迟

优化延迟的绝对主战场。大家在为编解码每一寸进步打得头破血流的时候，有人发现性价比最高的降低延迟的地方是传输。CDN本不是为视频而生，但视频重度使用了CDN。CDN网络覆盖率越广，带宽越大，访问就越快。CDN的方案只需要有钱就行，技术壁垒并不高。然后有人意识到，在花了同样的钱的情况下，如何更高效的利用CDN，可否边缘计算？再比如，如果换成这个传输协议，速度是不是更快？于是大家展开了对深层技术的调研与创新，这时的技术壁垒开始展现，只有大厂才能出大成果。

• 渲染延迟

到达终端播放，如何缓冲排队，如何自适应，是减少用户延迟体验的最重要场所，但此阶段其实没有真正降低延迟，只是把视频包装得更合理一些，卖相更好一点，因为用户面对的只有终端，必须重视。

降低传输延迟的几种不同思路

提到视频流的传输，就需要提到两个应用最广泛的协议：RTMP和HLS。其它传输协议如DASH等在国内非主流，不做介绍。

RTMP全称是Real Time Messaging Protocol，实时消息传输协议，由Adobe开发。它基于TCP协议，特点是低延迟，3到5秒，速度快，但只能用于直播，在国内应用十分广泛，尤其互联网视频刚刚兴起的时候。但它作为推流技术，可扩展能力较弱，同样的硬件设备，改用拉流的模式能够承载的流量和访问量会更大。

HLS 全称是HTTP Live Streaming，是Apple开发的动态码率自适应技术，与RTMP相反，它采用拉流方式。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。HLS的局限是因为切片需要时间，所以延迟相对RTMP这种把视频直接推送出去的技术相比，要延迟更多，有时候整个延迟达到几十秒。

大厂在一边采用RTMP和HLS将视频应用落地商用，一边又在探索更先进的技术和方案来提高自己的投入产出比。基于TCP和HTTP的连接太耗时，TCP创建连接3握手，关闭4次，之上还要构建TLS就需要再来3次握手，什么正事还没做4、5个RTT就用完了，还有重试等待和拥塞控制等策略把TCP传输搞得很稳定，也很低效。开发Web前端JavaScript的同学都知道，前端技术经历了几次升级，主要是为了和TCP/HTTP频繁创建连接的成本作斗争，提升渲染速度，如从JSP这种页面跳转，改为单页面Ajax模式，再改为长轮询longPolling来复用HTTP连接通道，再改为使用WebSocket建立长连接等等。但哪那么容易？技术归技术，市场这么大，不同浏览器的不同版本对不同技术和协议的支持的都不一样，没有一种技术能独步天下兼容绝大多数终端。我年轻时学习前端技术时一直盼着等来一种占绝对优势前端框架包含统一的技术或协议，一统天下，以减少花更多时间去学习和掌握各种很快流行但很快就要面临被淘汰的技术，这个目标到现在也没实现。玩笑归玩笑，除了Web应用关注TCP连接，对于视频传输和CDN分发来说，TCP和HTTP传输的优化也是同样要考虑的。如何降低连接带来的延迟，如何做到与当前技术的高兼容性，大厂做了很多研究和讨论，其中WebRTC，CMAF和QUIC代表了当前的最新技术动向和热门，这三个热点正好代表了三种解决问题的不同思路，值得我们思考和借鉴。

• 化整为零法 – CMAF

比如公路宽度不变，与其让一辆体积庞大臃肿的满载货物的重型卡车挡住了去路，造成交通拥堵，还不如把它的东西拆下来，分装到其它小车上陆续运走，CMAF就是这种。

CMAF是Common Media Application Format的缩写，由微软、苹果联合MLBAM、思科、Akamai和Comcast在2016年2月向MPEG提出，于2017年7月成为国际标准。它主要基于HLS和DASH，技术特点是化整为零，把视频内容切成等份的小块来传输，从而降低延迟。问题来了，既然HLS就是搞切片的，为什么还要多此一举？把HLS的segment切得更小不就行了？10秒的切片太大就5秒，再不行就1秒切一个。答案是切片也是要考虑均衡的，这涉及到图像编解码的理论：每个视频切片里都必须有一个关键帧，然后在此关键帧上做编码压缩，关键帧上的压缩率很低，对非关键帧的压缩才是重点，编解码的设计者恨不得把那些非关键帧压成0字节才罢休，然后一起传输。如果切片太小，太细，反而增加了关键帧的数量，这意味着反而增大了传输量。而基于chunk的CMAF，则不需考虑关键帧，一律切碎，大小相等，压缩传输，哪里有缝隙就往哪里钻，把连接通道尽量铺得满满的，从而提升利用率。这就是CMAF的思路。

• 另起炉灶法 – QUIC

当落后的生产关系已经无法满足生产力的发展，而生产关系又不是通过变革就能解决的，就需要重新打天下。TCP协议就属于这种相对稳妥但已经开始落后的协议，由于整个生态系统对它的支持已经渗透到OS级别，想要动它改它太难了，于是有人说咱们重新开发一套协议，TCP有的优点它都有，TCP没有的优点它也有，这个人是谷歌，这个新协议就是QUIC。

QUIC 全称 Quick UDP Internet Connection，基于UDP的上层协议，可供HTTP使用，由Google于2013年提出，最近HTTP over QUIC 已正式成为HTTP/3标准。QUIC的缺点是什么，东西是好东西，但是另起炉灶的东西需要被认可才行，被市场利益相关方认可才行，而且当前的技术生态还不能完全兼容它，需要时间。

• 去中心化法 – WebRTC

去中心化的思想无处不在，不是区块链独有。视频领域很早就有这种去中心化的P2P应用。当前最火的WebRTC就是基于此种模式。既然中转成本这么高，咱们点对点单聊吧，每个点都建立发送和接收的双通道，这样就再也不重度依赖中心了。

WebRTC全称Web Real-Time Communication，网页即时通讯，它最初是由Google开发并于2011年6月加入W3C标准，作为基于浏览器的实时通信的开源解决方案发布。它使用UDP来进行媒体推流，但它不是一个单纯的传输协议，而是一种框架性的标准，涵盖多个协议层。它的优缺点都很明显。优点是点对点，速度最快，延迟最小，仅为毫秒量级；局限是这种点对点数量不能太多，如果太多，就成为风暴。所以尽管WebRTC号称延迟史上最低，但不能包治百病，只适用于观众人数较小的业务场景：如20人以下的课堂或视频会议，交互要求高，但人数规模小，这是为什么当前很多教育机构都纷纷准备采用WebRTC的原因。如果想直播一场春晚，那会被砍头的。

本文的重点是介绍QUIC协议是如何降低延迟的，先回顾一下网络传输协议的加速简史作为铺垫。

网络传输及应用协议进化史

传输和应用协议的进化史大体如下，每一次进化都带来新的功能和改善。

• HTTP/1.x

HTTP（HyperText Transfer Protocol）超文本传输协议，建立在TCP协议之上，所以HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性，如TCP三次握手四次挥手建立连接带来的RTT延迟时间等。HTTP/1.1进一步完善了HTTP/1.0的功能。协议关系如下：

• HTTPS

基于SSL/TLS的HTTPS解决了安全问题。但HTTP + SSL + TCP 的结合同时也将应用成本又提高了一层。协议关系如下：

• SPDY

SPDY 是 Google 开发的基于传输控制协议 (TCP) 的应用层协议，是英文Speedy的寓意，于2012年提出，旨在通过压缩、多路复用和优先级来缩短网页的加载时间和提高安全性。因此得到了众多浏览器和Web服务器支持如Apache等，以至于在HTTP/2出现之前，阿里等大厂已经开始使用SPDY做一些前端应用的尝试。SPDY与各协议层关系如下：

• HTTP/2

Google的SPDY协议被HTTP标准收纳，成为HTTP/2。最主要的成果是包含和完善了SPDY，提供更大的兼容性，如SPDY只能在SSL上，但HTTP/2可以支持非HTTPS。协议关系如下：

• QUIC & HTTP/3

Google的技术领导力实在是太强大了！WebRTC，SPDY，现在又是QUIC，都进入标准了。QUIC (Quick UDP Internet Connection) 是Google是由2012年提出开发的，于2013年亮相，于本月（2018年11月）被吸纳为HTTP正式标准。它基于UDP协议，可以作为TCP + TLS的替代，但是更高效。QUIC分两部分：QUIC和HTTP over QUIC。

HTTP/3 的标准的曾用名是HTTP over QUIC，二者等价。所以HTTP/3的出现并不代表QUIC协议被吞并了，这点与SPDY的命运不同。QUIC与其它主要协议的关系如下：

QUIC的核心特性

• 快速建立连接

基于传统的HTTPS连接的完全建立需要个4个RTT（往返时间），而基于UDP协议的QUIC则不需要往返时间就可以进行数据传输。甚至号称0-RTT，偶尔1-RTT。

• 改进的多路复用

在SPDY协议出现以前，每个HTTP请求都需要建立一条TCP连接，如果希望请求并行，就需要同时开启多条TCP连接。SPDY协议提出的多路复用，让所有请求基于一条TCP连接，解决了上述的问题但同时引入了新的问题 – 队头阻塞（HOL），如果某个资源的某个包丢失了，因为TCP是保证时序的，就会在接收端形成队头阻塞，TCP此时无法区分各个资源的包是否关联，因此会停止处理所有资源直到丢包恢复。

QUIC的多路复用基于UDP，UDP不需要保证包的时序，只会在接收包的时候对包进行重组，因而不存在等待丢包恢复的队头阻塞问题，这样某个资源的包丢失只会影响自身不会影响到其他资源的继续传输，所以是改进的多路复用。

• 丢包恢复

类似拥塞控制，除了基于TCP的一些丢包恢复机制，如：TLP，FACK。QUIC的丢包恢复也在一些方面做了改进。比如：通过引入严格递增的sequence number使得计算RTT更加精确。更精确的RTT也意味更精确的RTO和超时重传机制。还比如我们知道TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。

• 拥塞控制

TCP传统的拥塞控制实际包含了：慢启动、拥塞避免、快重传和快恢复，TCP的拥塞控制算法是固定的。QUIC协议目前默认使用TCP的Cubic拥塞控制算法，但同时还可插拔支持Reno, BBR, PCC 等其它拥塞控制算法。它还采用了packet pacing来探测网络带宽，通过追踪包的到达时间来预测当前带宽的使用情况，以决定是否提高、保持或者减少发送包的速率来避免网络拥塞。

• 灵活的流控

QUIC是多路复用的，多条stream可以建立在一条connection上，所以QUIC的流量控制不仅基于单个stream，还基于connection。

stream级别的流控能够控制单stream的数据发送情况。另外，接收窗口的收缩取决于最大接收字节的偏移而不是所有已接受字节的总和，它不像TCP流控，不会受到丢失数据的影响。connection级别流控算法和stream一致，各项数值是所有stream的总和。connection级别的流控存在的必要是，即使做好了stream流控，但如果stream过多也会导致connection过度消耗带宽和系统资源；而且即使某一条stream过慢，其他stream依然能触发。

• 连接迁移

TCP使用四元组（源IP，源端口，目的IP，目的端口）来标识一条连接，当四元组中的IP或端口任一个发生变化了连接就需要重新建立，从而不具备连接迁移的能力。

而QUIC使用了connection id对连接进行唯一标识。即使网络从4G变成了WIFI，只要两次连接中的connection id不变，并且客户端或者服务器能通过校验，就不需要重新建立连接，连接迁移就能成功。

• 前向纠错

QUIC使用了FEC（前向纠错码）来恢复数据，FEC采用简单异或的方式，每发送一组数据，包括若干个数据包后，并对这些数据包依次做异或运算，最后的结果作为一个FEC包再发送出去。接收方收到一组数据后，根据数据包和FEC包即可以进行校验和纠错，这种算法类似RAID4。比如：10个包，编码后会增加2个包，接收端丢失第2和第3个包，仅靠剩下的10个包就可以解出丢失的包，不必重新发送，但这样也是有代价的，每个UDP数据包会包含比实际需要更多的有效载荷，增加了冗余和CPU编解码的消耗。

• 安全加密

TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击。

QUIC 除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。这样只要对 QUIC 报文任何修改，接收端都能够及时发现，有效地降低了安全风险。QUIC 还能实现证书压缩，减少证书传输量，针对包头进行验证等。

QUIC性能对比

目前的针对QUIC的性能测试报告在网上比较零散，像样的报告并不多。总体结果是正面的，但由于受应用规模所限，说服力还不是太强，只找到寥寥几个相对详细有数字的报告，汇总如下：

市场应用现状

市面上已有的QUIC实现

除了Google 在自己的chronium的项目中提供了一个示例客户端和服务器实现，以及当前的Chrome浏览器已经支持QUIC之外，还有其它组织或机构也实现了对QUIC的支持。IETF QUIC Working Group 在GitHub 上跟踪了当前所有已知的基于IETF 版本QUIC的各种技术应用和实现，目前大概有29个，仅列出部分如下供参考：

• ats – 对CDN 的ATS服务器的QUIC实现

• ngx_quic – 实现NGINX 对QUIC的支持

• f5 – F5 TMOS 的QUIC 实现

• lsquic – LiteSpeed 客户端库

• caddyserver – go语言开发的支持QUIC的Web服务器

• AppleQUIC – 提供Apple的客户端和服务器对QUIC的实现

参与评估和应用的知名企业

除了Google应用，当前网上可以查到的参与评估或已经实现部分灰度应用的企业列举如下，其中腾讯的评估规模较大，涉及多个应用。