一. 视频直播的痛点：卡顿
卡顿是最影响直播体验的因素之一，也是最难解决的问题之一。在流媒体的传输链路中，任何一个环节丢包都可能导致用户观看卡顿。
其中，主播端的推流卡顿最影响观看体验，会直接影响到所有观看直播的最终用户。主播推流卡顿在部分场景会特别显著，比如户外直播就非常考验在网络状况复杂的情况下推流的稳定性。
减少卡顿一直是开发者重大的技术挑战，那么继续看看我们又有什么样的对策呢？
Google 从 2014 年推出 QUIC 协议后一直在音视频产品上实践该协议。现在，经过一年多的探索和实践，我们的直播云产品已经拥抱 QUIC，最新推出的直播 QUIC 推流方案可以大幅度的降低直播的卡顿问题，可以在各种复杂网络环境下给客户提供优秀的直播体验。（关于QUIC协议的详细介绍请阅读《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》）
二. QUIC 是什么，为什么可以降低卡顿？
既然 QUIC 可以解决如此重要的直播体验问题，那么我们先从整体了解一下 QUIC 协议（关于QUIC协议的详细介绍请阅读《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》）。
2.1 QUIC 协议的定义
QUIC 全称 Quick UDP Internet Connection, 是谷歌公司制定的一种基于 UDP 协议的低时延互联网传输协议。
我们知道，TCP/IP 协议族是互联网的基础。其中传输层协议只有两种： TCP 和 UDP 协议。与 TCP 协议相比，UDP 更为轻量，但是错误校验也要少得多。由于 UDP 是不可靠协议，不保证按序送达，所以其可靠性比不上 TCP 协议。
QUIC 传输层基于 UDP 协议但却是一种可靠的传输协议，因为它将很多可靠性的验证策略从系统层转移到应用层来做，这样可以使用更适合现代流媒体传输的拥塞控制策略。
关于TCP和UDP的差异，以下文章可以给您一些答案：
2.2 QUIC 在网络传输中所处的位置
从图上可以看出，QUIC 传输层用 UDP 协议替代了 TCP。（另外，更深入的计算机网络协议关系图请见《计算机网络通讯协议关系图（中文珍藏版）[附件下载]》）
2.3 QUIC 在传输上为什么有优势
从上面所有对 QUIC 的定义上来看，很明显 QUIC 的对比对象是 TCP。所以下面所有的优势的枚举都是基于 QUIC 和 TCP 的比较。
【QUIC优势1：更出色的拥塞控制】
虽然例如 HTTP/2 或者 SPDY 协议现在都支持将页面的多个数据通过一个数据链接进行传输，该特性也确实能够加快数据的传输速度。但是由于 TCP 协议在处理包时是有严格顺序的，所以还是会遇到队首阻塞的问题。
比如发生如下图所示场景下的问题时，当其中一个数据没有发送成功，TCP 连接需要等待这个包完成重传之后才能继续进行。因此，即使逻辑上一个 TCP 连接上并行的在进行多路数据传输，其他毫无关联的数据也会因此阻塞：
QUIC 协议直接通过传输层使用 UDP 协议就可以避免该问题的发送。由于 UDP 协议没有严格的顺序要求，当一个数据包遇到问题需要重传时只会影响该数据包对应的资源，其他独立的资源不会受到影响而阻塞传输：
【QUIC优势2：更加灵活】
TCP 协议栈通常由操作系统层面来实现，例如如 Linux、Windows、iOS、Android 操作系统。因此如果要修改 TCP 协议需要从操作系统层面去做很多事情，这是一项复杂的工程。相对来说 UDP 协议在操作系统层面实现更为简单，QUIC 基于 UDP 在应用层做了很多网络拥塞控制层面的优化，帮助用户减少复杂网络下的卡顿率，提高流畅度，这是 TCP 无法做到的。
2.4 QUIC小结
从以上所有的介绍中可以看出，如果我们需要使用 QUIC 改善直播体验，就是用它来代替直播中 TCP 协议所扮演的角色。大家都清楚目前直播所使用的协议都基本是 RTMP 协议,而 RTMP 协议的传输层是基于 TCP 协议。所以我们的 QUIC 推流方案就是把 RTMP 当中的传输层协议换成 QUIC，从而达到推流卡顿率下降的效果。
三. 使用 QUIC 后的效果
上面说了那么多基于 QUIC 做媒体传输的理论优势，那么有没有实际的实验测试作为理论的支撑呢？下面一起来看看测试数据吧。
测试的参数配置：
测试方式：
使用 ATC 模拟的弱网环境下，用 srs 播放器播放 5 mins，记录流畅度和卡顿次数。
3.1 测试场景之弱网配置一
ATC配置：delay 100ms loss 1%
结果分别如图所示：
3.2 测试场景之弱网配置二
ATC配置：delay 200ms loss 10%
测试结果如图所示：
而在 TCP 这种网络配置下，推不起来，或者推一会就会断开。