音视频直播清晰度、画面质量、流畅度如何保障呢?
3月30日下午，以“视频技术的演进与实践”为主题的保利威第18期视频极客沙龙在广州·贝塔空间完美收官。本期视频极客沙龙由保利威主办，珠三角技术沙龙社区、安卓巴士技术社群，CSDN、51CTO、APICloud等合作伙伴对本次活动给予了大力支持。
华南师范大学经济与管理学院副院长徐向龙、保利威技术副总裁梁瑛玮、保利威前端技术专家罗礼权、搜狐千帆直播高级技术经理金昊、大牛教育教学传媒部负责人黄思源等5位视频技术大咖和教育专家在本次视频极客沙龙中，对网络视频技术的演进、新一代互联网传输协议QUIC及高校在线教育的探索与需求等话题做了精彩分享。
在活动现场，金昊给大家分享了QUIC协议在音视频直播领域的应用探讨。
金昊
毕业于华南理工大学数学系，10年互联网开发经验，多年团队管理与项目管理经验。2011年至2013年在广州千钧科技(搜狐视频56网)任职高级Web开发工程师，2014年任搜狐千帆直播技术主管，管Web开发团队。2015年年任技术经理，负责移动端开发。
以下是金老师在沙龙上的分享实录整理：
现在比较火的一个话题就是5G，因为5G可以带来很多应用上的突破，比如说AR、VR，特别是视频和直播领域需要5G的落地。在我们直播应用方面，5G带宽更大，更大的带宽能解决清晰度、画面质量，但是流畅度如何保障呢?
我个人的观点，我们做直播开发的，更关注的是如何提升直播推流的流畅度。长久以来，RMTP 跟 TCP 一直工作得很好，市面上99%的视频直播都在这上面跑。而且在现有软硬件条件、以及应用需求下，无论是推流还是拉流工作都非常好(至少网络不丢包情况下，非常流畅)。但是，TCP协议也有一些缺点，例如：
3次握手，TLS 2次握手，握手严重影响秒开；
队头阻塞，拥塞不可控；
网络切换需要重连；
ARG不可控，还有歧义；
Header首部没有加密认证；
TCP很老旧，是老的内核和老设备，升级很困难。
TCP协议不是从实时语音视频的角度进行设计的，更多是考虑网络传输的公平性，内嵌的传输控制策略比较中庸。RTMP是基于TCP协议，而TCP是通用的IP网络协议，不是为实时媒体传输而设计的，在弱网环境下延迟会增大。那么为什么会选择UDP呢?
UDP的特点：
轻量、无连接；
错误校验少、效率高；
速度快，占用资源少；
弱网下(开发)可控性好；
定制度高，由开发掌控。
而UDP也允许开发者有更多的操作性，例如：
1、UDP允许端到端全链条进行信道策略控制(FEC、ARQ、ABC etc.)，在弱网环境下可控性更强；
2、UDP的延迟时间的大小取决于丢包时候的 ARQ 和 FEC 策略，在实际开发中，允许开发者深度控制 ARQ 和 FEC 策略；
3、UDP是适合用来设计实时语音视频的通讯机制，根据网络状况自适应地选取 ARQ 和 FEC 策略，以及调整传输码率和报文的数量；
在网络好的时候，RTMP无论走在TCP还是UDP传输效率是相当的。但是，网络差的时候UDP可以定制流控、码控、ARG、FEC、抖动缓冲等对抗。
QUIC是什么？
QUIC 全称 quick udp internet connection，“快速UDP互联网连接”。QUIC 位于应用层(比如 Http)和网络层(UDP)之间，是在UDP上实现的一个多路复用的协议。
QUIC的总体特点：
一是可靠性改进，QUIC为了保持TCP的可靠性，几乎继承了TCP所有的特性，比如说序列号改进、拥塞控制、重传机制优化，安全保密性；
二是并发上的改进，为了保持并发性，把减少队首阻塞，流量控制可控，多路复用，基于单条点上多路复用，传输优先级优化；
三是QUIC部署在客户端级别，并不是部署在操作系统，所以开发自由度很大；
四是QUIC迭代速度很快，谷歌内部自称以每一个星期迭代一版为标准，实际开发中，基本上也是一两个星期就会更新一个版本，迭代速度很快。
QUIC有什么优点?
第一，精细流量控制。基于Connection和stream级别，多个stream之间互不影响。主要是依赖于三种关键幀，才能达到流控，一是 window_update 帧，告诉对端自己“可以且最多可以”接收的字节数绝对偏移量。blocked 帧，告诉对端数据发送，由于流量控制被阻塞了，暂时无法发送，对调试很有用。stop_waiting 帧，用于通知对端，它不应该继续等待包小于特定值的包。对于直播来说，可以保障服务可用性，直播发起的时候，转码跟不上的时候，可以告诉服务端停止发送直播流或者做出一些应急，推动我们定制的幀去做，保证服务可用性。
第二，无队头阻塞的多路复用。QUIC 的多路复用，在一条 QUIC 连接上可以发送多个请求 (stream)，一个连接上的多个请求(stream)之间没有依赖。比如说这个packet丢失了，不会影响其他的stream。这个特性对于直播来说，弱网下推流更流畅。
第三，ORTT连接。QUIC的连接将版本协商、加密、和传输握手交织在一起以减少连接建立延迟。这个特性对于直播来说，使首幀更快，延迟更小。
第四，连接迁移。传统NAT遇到的问题，比如说这个小区运营商切换端口，就导致设备端判断不了新的连接标识，需要重联。而QUIC使用公共包头和连接ID，好处就是可以在网络切换的时候不重连，在室内到室外，理论上可以做到连接不断网。
第五，加密认证的报文。QUIC把TLS(1.3)等效加密，几乎每个UDP包都加密，报文body都经过加密，从头到脚几乎无死角，对证书也有一些压缩优化，每一个加密包独立认证。这个特性对直播来说，防盗链、盗播、劫持是有好处的，至少在客户端是这样的。
第六，向前纠错。QUIC采用向前纠错(FEC)方案，即每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。对于直播来说可以减少ARG、减少卡顿、提升秒开成功率。
第七，改进的拥塞控制。这个是QUIC最重要的一个特性，TCP的拥塞控制包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。QUIC 协议当前默认使用了TCP协议的Cubic拥塞控制算法，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。同时QUIC拥有完善的数据包同步机制，在应用层做了很多网络拥塞控制层面的优化，能有效降低数据丢包率，这有助降低复杂网络下的直播卡顿率，提升传输效率，可是使推流更流畅。
QUIC和音视频直播交叉点在哪里？
QUIC替换掉了TCP在应用层和传输层中间的角色，作用总结起来，就是两点：
一是弱网推流，帮助用户在弱网上推流，对于视频直播来说，主播端推流效果是最影响观看体验的；
二是推流过程中减少卡顿，卡顿一直是困扰视频直播最大的困扰。
当然，QUIC也不是完美的，它也有一些缺点，例如：
1、太复杂
QUIC 协议非常复杂，因为它做了太多事情：
为了实现传输的可靠性，它基本上实现并且改进了整个 TCP 协议的功能，包括序列号，重传，拥塞控制，流量控制等;
为了实现传输的安全性，它又彻底重构了 TLS 协议，包括证书压缩，握手消息，0RTT 等。虽然后续可能会采用 TLS1.3 协议，但是事实上是 QUIC 推动了 TLS1.3 的发展;
为了实现传输的并发性，它又实现了 HTTP2 的大部分特性，包括多路复用，流量控制等。
2、需要更强大的编码效率
因为携带大量的包，还有冗余数据、全程加密，对后端服务器编码压力很大。
3、传统环境限制多
比如说，为了对抗 DDoS，一般防火墙都比较严格地过滤 UDP，一定程度上限制了 UDP 在广域网的发展。运营商对 UDP 的通道支持不足，极不稳定。
4、开发环境不成熟
开发工具不完善，开发调试成本高，只能看到前期明文握手信息。链路调试抓包目前都还没有工具，一般都是 wireshark + 日志输出进行debug。
QUIC未来可优化的地方有哪些?
1、“如何提升 0RTT 成功率”：需要实现 ServerConfig ID 进程间共享和分布式集群的 Cache，即使用全局公共缓存;
2、“加密性能优化”：减少服务端本地的 CPU 消耗量，对 ServerConfig 的内容签名和校验(RSA、ECDSA 签名)等，使用 SSL硬件加速卡集群;
3、“实现连接迁移”：QUIC Connection ID - 同一台服务器保存了相同的 Stream 及 Connection 处理上下文，能够将该请求继续调度到相同业务的机器，这个需要开发功底;
4、“动态的流量控制、拥塞控制”：对 Connection 和 Stream 级别设置不同的窗口数，对于如何通过流量控制和拥塞控制，来保障业务可用性，需要实际开发下功夫;在实际应用中，需要对线上使用情况进行很多的变量统计和分析，依赖大数据，包括 0RTT握手成功率、握手时间、密码套件 使用分布，QUIC 协议的版本，stream并发数量 等等等等。根据这些数据进行流量的动态控制。
5、使用 UDP 不一定比 TCP 更快，至少现阶段还无法100%保证。客户端最好是竞速挑选 TCP or QUIC 方案。
