一、直播为什么需要QUIC?
众所周知，决定直播观看体验的因素有很多，比如：卡顿、首屏时间、延时、清晰度等等。而卡顿被称为直播体验的头号痛点，从“主播推流端”→“CDN”→“观众拉流端”，整个流媒体传输链路中，任何一个环节出现丢包都可能导致卡顿。尤其是主播推流端的推流流畅度更是决定了原流的质量，如果主播推流时网络丢包较高、延时较大，将会出现推流卡顿，那么所有观众在观看这路流时都会出现卡顿。那么拉流端是否存在痛点呢?拉流端同样存在痛点，因为在移动互联网时代，大量观众是使用手机观看直播视频的，移动蜂窝网络在不同地区、不同位置的覆盖质量是不同的，在信号覆盖不好的地区就会出现弱网问题，弱网的显著特点是丢包率和延时都很高，在这些弱网地区使用传统的TCP拉流体验是很差的。
而QUIC具有弱网环境下抗丢包、缩短首屏时间等优势，因此可以用QUIC来解决直播业务上存在的上述痛点。不了解QUIC的小伙伴别着急，我们下文将会为您详细介绍QUIC的技术原理和优势。
二、金山视频云直播QUIC+解决方案概要
为了解决直播业务上存在的痛点，金山视频云直播推出了QUIC+解决方案，该方案不仅支持RTMPoverQUIC推流，同时还支持RTMPover QUIC/ HTTP-FLVover QUIC/ HLSover QUIC拉流功能，真正实现了端到端支持QUIC，此外金山云直播QUIC+解决方案采用了最新的BBR拥塞控制算法，在弱网环境下的表现更出色。
相比而言，有些友商的直播产品不支持QUIC，少数厂商仅支持overQUIC推流，不支持overQUIC拉流，无法做到端到端支持QUIC，并且需要使用他们的推流SDK，这会导致SDK对接繁琐，并且头部客户因为有顾虑一般不愿意使用云厂商的SDK，而是选择自己开发SDK;还有友商的直播QUIC方案中没有集成BBR拥塞控制算法，在弱网环境下抗丢包的能力不如采用BBR算法的金山视频云直播QUIC+解决方案，这一点我们可以从测试数据中得到证实，从友商公布的测试数据来看，overQUIC推流，当丢包率20%时，流畅度只有30-40%;而金山视频云直播QUIC+解决方案在丢包率达到30%时流畅度还有96.51%。可见，金山视频云直播QUIC+解决方案是率先真正完美支持直播推拉流overQUIC的云厂商。
我们下文将会为大家呈现金山视频云QUIC+解决方案在直播业务上与传统TCP方案的实际测试对比，大家能够在下文的测试报告中看到金山视频云QUIC+解决方案的优势：传统的RTMP over TCP推流在5%丢包率时就已经非常卡了，当丢包率超过10%时，RTMP over TCP直接无法推拉流，而金山视频云QUIC+解决方案采用RTMP over QUIC推流在30%丢包率时持续5分钟的播放过程中只出现了7次卡顿，流畅度为96.51%，这样的流畅度还是不影响观看体验的，大多数的观众还能接受。
追求无止境，除了在直播场景下率先真正端到端完美支持直播推拉流overQUIC外，金山云CDN还支持直播多流择优方案，通过稳定的性能、透明的数据服务体制，金山云成功保障国庆70周年庆典直播、建军90周年阅兵、“十九大”、全国两会、香港回归20周年、G20峰会、金砖国家峰会、央视春晚、世界互联网大会、世界杯、亚运会等大型活动和体育赛事。作为云计算行业的领导者，金山云将致力于为用户打造高品质的直播体验而保驾护航。选用视频云，就选金山云!选用CDN，就选金山云!
三、QUIC介绍
1、QUIC简介
QUIC(Quick UDP Internet Connection，发音'quick')是一种互联网传输协议，最初由Google的Jim Roskind设计，并于2012年被应用和部署，随后在2013年随着实验的扩大而开始对外公开，并于同年向IETF(Internet Engineering Task Force，国际互联网工程任务组)递交了协议草案。
互联网人士都知道，TCP/IP协议簇是互联网的基础，任何数据在互联网中传输都依赖它。TCP/IP四层模型中输层协议只有两种：TCP和UDP协议，其中TCP协议是面向连接的协议，是一种可靠的协议，TCP保证数据的正确性和数据包的顺序;而UDP协议是非连接的协议，也就是说传输数据时不需要建立连接，是不可靠的协议，UDP不保证数据的正确性和数据包的顺序。因为TCP和UDP各有优缺点，TCP的优点是可靠、稳定，但是也有明显的缺点：建连需要经过3次握手，繁琐、效率低、占用系统资源高。UDP的优点是效率高、快、轻量占用系统资源少，但是缺点很明显：不可靠、无序。
QUIC其实是在UDP协议之上提供一种可靠的、可建立面向连接的服务，它继承了UDP的优点，同时基于UDP之上加入了拥塞控制、多路复用、前向纠错等特性，从而弥补了UDP的缺点，使得QUIC既提高了数据的传输效率，也变得可靠了。
如下图所示，QUIC所处的网络层次如下。从功能上看，HTTP-over-QUIC ≈ TCP + TLS + HTTP2，但是基于UDP之上实现的。
2、QUIC的优势
前面咱们聊到QUIC是基于UDP实现的，在UDP之上加入了一些新特性从而弥补了UDP的缺点，这些优势有哪些呢?
1）极短的建连时间
QUIC的建连时间中大部分为0 RTT，极少部分是1 RTT。分为以下两种情况：
a) 若客户端与服务器未建连，则第一次建连时需在客户端生成证书和协议栈相关的配置并生成ConnectionID，这些数据会保存在服务端;
b)若客户端与服务器已建连过，服务端已保存了客户端的证书和ConnectionID等数据，服务端会直接进行校验，校验通过后直接向客户端发送数据，从而实现0RTT极短的建连时间。
TCP的一个建连包含三次握手，而如果是HTTPS，则还需包含TLS层的一次握手，同时增加1RTT的时间;因此，就TCP+TLS而言，已完成建连的连接需要2RTT，而首次建连的则需3RTT。相比而言，QUIC0~1 RTT的建连时间就显得极短了，因此直播业务支持QUIC推拉流后，能够显著缩短首屏时间，至少能将首屏时间降低一半。
2）改进的拥塞控制
金山视频云直播QUIC方案采用了BBR拥塞控制算法，其中BBR算法是先在QUIC中试验，由于效果很好，后来还被移植到TCP内核中了。可见QUIC在弱网环境下的拥塞控制方面是很优秀的，金山云直播QUIC方案在推流和拉流上都实现了BBR算法，并且经过对BBR算法的适配和优化，能保证在弱网环境下丢包30%时仍然能流畅推流和拉流。
3）避免队头阻塞的多路复用
HTTP1.1中，每条数据流基于一个TCP连接，每个TCP连接都单独传输数据，但此TCP连接方案会明显增加服务端与客户端的并发负载，浪费服务端和客户端的资源;
HTTP/2中，对此问题进行了有效优化也就是采用多路复用的传输策略，通过一条TCP连接传输多路数据，但此方案容易造成队首阻塞问题。队首阻塞(Head-of-Line Blocking)是指因为队首的数据流丢失而重传造成其他队首之后的多条数据流被阻塞的现象。
如下图所示，以HTTP/2 over TCP数据流为例，若Stream 3丢失那么Stream 1与Stream 2都会被阻塞，直到丢失的Stream 3数据重传完成之后Stream 1与Stream 2才能被继续传输。
而在QUIC中，改善了HTTP/2中的队首阻塞问题，实现了避免队首阻塞的多路复用，具体实现是把每个重传过程安排在每条Stream中单独完成，由于Stream本质上是一个基于UDP的小数据包，所以这种方案并不会造成队首阻塞问题。如下图所示，Stream 3 是队首数据，当Stream 3中出现丢包后，不影响Stream 2和Stream 1的数据传输，Stream 2可以独立传输，不用等Stream 3丢失的数据重传完成。
4）前向纠错
前向纠错算法(FEC，Forward Error Correction)是一种对抗网络丢包的算法，具体实现是当弱网环境下出现丢包时，可以通过未丢失的报文和FEC报文将丢包恢复出来，减少了不必要的重传，从而实现在弱网环境下丢包率较高时不影响数据接收端的体验。金山视频云直播QUIC+方案，在丢包30%时主播端仍然能流畅推流，观众端仍能流畅观看，具体数据可继续看下面的TCP与QUIC测试对比。
5）连接转移
假设用户在家中使用WiFi观看直播视频，这时突然有事需要出门，一边刷着直播视频一边下电梯，当用户进入电梯时手机连接的WiFi将会断开，手机网络自动切换到移动蜂窝网络，在网络从WiFi到蜂窝网络切换的瞬间，TCP连接会断开重连，这是因为TCP采用四元组(源IP、目标IP、源端口、目标端口)的方式来标识一个连接;而QUIC是用数据包中一个64位的数值ConnectionID来标识一个连接，无论WiFi与蜂窝网络之间如何切换，只要发送给的服务端的ConnectionID没变，服务端就会认为是同一个连接，从而避免出现切换网络需要重连的问题。
QUIC优势总结：
以上这些优点将帮助互联网内容服务商实现更快的连接建立、弱网环境抗丢包、切换网络无需重新连接等特性，因此业内越来越多的厂商开始拥抱QUIC，发展前景一片光明。金山云作为云计算行业的领导者、金山云云直播产品作为行业内的旗舰产品，现已率先推出金山视频云直播QUIC+解决方案。
四、金山视频云直播QUIC+解决方案效果测试
上文说到了直播为什么需要QUIC，以及QUIC的优势，那么金山云直播over QUIC推拉流的效果相较于传统的over TCP推拉流如何呢，我们通过长期的线上验证，并通过头部客户使用后的反馈来看，效果非常好。我们将用数据说话，告诉大家金山云直播支持QUIC推拉流后带来哪些改善。
测试方法：
1)使用同一个媒资，推流分辨率、码率、编码格式都相同;
2)使用ATC工具模拟弱网环境，分别采用RTMP over TCP和RTMP overQUIC推拉流，用srs播放器持续播放5 mins，记录流畅度和卡顿次数。
推流视频
测试结果：
弱网环境1：delay 100ms loss 1%
1)RTMP over TCP测试截图：
2)RTMP over QUIC测试截图：
弱网环境2：delay 150ms loss 5%
1)RTMP over TCP测试截图：
2)RTMP over QUIC测试截图：
弱网环境3：delay 200ms loss 10%
在这种弱网环境下，RTMP over TCP推流非常卡，播放器拉流35秒后被断开连接;而RTMP over QUIC推流和播放都很流畅，在持续5分钟的播放过程中0次卡顿，流畅度100%，效果非常好。
1)RTMP over TCP测试截图：
2)RTMP over QUIC测试截图：
弱网环境4：loss 20%
在这种弱网环境下，RTMP over TCP推流非常卡无法正常推流，播放器拉流马上就被断开;而RTMP over QUIC推流和播放都很流畅，在持续5分钟的播放过程中0次卡顿，流畅度100%，效果非常好。
RTMP over QUIC测试截图：
弱网环境5：delay 500ms，loss 30%
在这种弱网环境下，RTMP over TCP直接无法推流，而RTMP over QUIC推流和播放仍然还是流畅的，在持续5分钟的播放过程中只出现7次卡顿，流畅度96.51%，这样的流畅度大多数观众还是能接受的。
RTMP over QUIC测试截图：
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
