QUIC知识汇总及其在视频直播的应用调研
IT金队长2018-11-19 23:35
都是之前对 QUIC 调研的一些记录！
TCP 协议的缺陷：
* TCP 有内嵌的 重传策略ARQ，但不允许开发者对 ARQ 策略进行控制，也没有 FEC，不能实现 FEC；
* TCP 需要进行 三次握手 才能建立连接，具有一定的连接等待时延，如果用了 TLS 加密，还会有其他的步骤，进一步增加时延；
* TCP 采用重传机制，而 QUIC 采用纠错机制。单流情况下如果发生丢包的话，TCP 首先需要一个等待延时来判断发生了丢包，然后再启动重传机制，在此期间会对连接造成一定的阻塞；
* 普通基于 TCP 连接，是基于两端的 IP 和端口和协议来建立的。在网络切换场景，例如手机端切换了无线网，使用4G网络，会改变本身的 IP，这就导致 TCP 连接必须重新创建；
* TCP 重传 segment 的 Sequence Number 和原始的 segment 的 Sequence Number 保持不变，也正是由于这个特性，引入了 TCP 重传的歧义问题；
* TCP 协议头部没有经过任何加密和认证，所以在传输过程中很容易被中间网络设备篡改，注入和窃听。比如 修改序列号、修改滑动窗口。这些行为有可能是出于性能优化，也有可能是主动攻击；
* TCP 协议栈通常由操作系统层面内核来实现，例如 Linux、Windows、iOS、Android 操作系统。除非所有的服务器和客户端的操作系统都能支持，并且都更新到能支持的版本才行。所以可能这辈子都不行，就像 HTTP1 也支持单连接承载多请求但还没有哪个浏览器支持的；
* TCP 不是从实时语音视频的角度进行设计的，更多是考虑网络传输的公平性，内嵌的传输控制策略比较温和（中庸）；
* RTMP 基于 TCP 协议，而 TCP 是通用的 IP 网络协议，不是为实时媒体传输而设计的，在弱网环境下延迟会增大；
UDP 协议的特点：
* UDP 协议是无连接方式的协议，所以它的效率高，速度快，占资源少；
* UDP 与 TCP 协议相比更为轻量，但是错误校验也要少得多，这意味着 UDP 往往效率更高；
* UDP 适合实时语音视频通讯，允许端到端全链条进行信道策略控制（FEC、ARQ、ABC etc.），在弱网环境下可控性更强；
* UDP 的延迟时间的大小取决于丢包时候的 ARQ 和 FEC 策略，在实际开发中，允许开发者深度控制 ARQ 和 FEC 策略；
* UDP 是适合用来设计实时语音视频的通讯机制，根据网络状况自适应地选取 ARQ 和 FEC 策略，以及调整传输码率和报文的数量；
Http2 缺点：
* Http2 存在 segment 队头阻塞 和 TLS 层面的队头阻塞；
* Http2 在传输层仍然遇到了一些问题，没办法有效地利用网络传输，我们需要一个协议用更少的延迟和更少的重传时间消耗去传递请求，减少因丢包造成的队首阻塞，然而又要保证安全性，QUIC 在这种背景下诞生了；
* Http2 的限制，在我看来就像排队过关，纵使开了再多的队列，最终过关速度，也还是受审核员的制约，而 TCP 就像那审核员；
总结 RTMP（TCP）和 UDP 对网络好坏的依赖：
* 在网络环境好的情况下，只要语音视频编解码器相同，RTMP 协议和基于 UDP 的私有协议的传输效率是相当的，都可以实现低延迟、低卡顿和高品质的实时通讯效果；
* 在网络环境较差的情况下，特别是在跨网，甚至跨国的情况下，基于 UDP 的私有协议对端到端全链条可控，包括 流控、码控、ARQ、FEC 和抖动缓冲等，对抗恶劣网络环境会更有保障；
QUIC 简介：
* QUIC 是 Quick UDP Internet Connection 的简称
* 谷歌制定的一种基于 UDP 的低时延的互联网传输层协议，位于应用层（Http）和网络层（UDP）之间
* 开源于 Chromium 项目中
QUIC 总体特点：
* 为了实现传输的可靠性，它基本上实现并且改进了整个 TCP 协议的功能，包括 序列号，重传机制，拥塞控制，流量控制 等；
* 为了实现传输的并发性，它又实现了 Http2 的大部分特性，包括 多路复用，流量控制，优先级 等等；
* QUIC 是部署在客户端级别，而不是在操作系统内核级别，这样就能以更快的速度进行迭代，其迭代周期由（TCP）以年计算加速为以周计算。适合快速迭代的移动端开发；
* QUIC 能够处理 传输可靠性、丢包、无序数据包 等一系列 UDP 默认未处理的问题，使之适合移动音视频的应用；
QUIC 协议优点：
1）多路复用传输 - 无队头阻塞：
* QUIC 拥有 Connection 和 Stream 两种流量控制，在一条 Connetion 上会同时存在多条 Stream 流。可以在内存不足或者上游处理性能出现问题时，通过流量控制来限制传输速率，保障服务可用性；
* QUIC 使用基于 UDP 的多路传输协议（单连接下）来传输数据，所以当其中一个数据流丢包时，其他的通道并不会因此阻塞等待丢失的数据包。QUIC 的方法解决了 TCP 传输的线端阻塞问题；
* QUIC 最基本的传输单元是 Packet，不会超过 MTU 的大小，整个加密和认证过程都是基于 Packet 的，不会跨越多个 Packet。这样就能缓解 TLS 协议存在的队头阻塞问题；特别是在传输大量数据是，比如 视频、直播流，受队头阻塞的影响很小；
* QUIC 拥有没有队头阻塞的多路复用：QUIC 的多路复用和 Http2 类似。在一条 QUIC 连接上可以并发 发送多个 Http 请求 (stream)。但是 QUIC 的优势在于，一个连接上的多个 stream 之间没有依赖。这样假如 stream2 丢了一个 udp packet，也只会影响 stream2 的处理。不会影响 stream2 之前及之后的 stream 的处理；
2）零往返时间连接 - 无握手、秒开：
* 零往返时间连接（0RTT）技术是等待时延优化，使得 QUIC 拥有极低的等待时延（相比于TCP的三次握手）；
* 0RTT 是指，如果双方此前通信过的话，那么在客户端和服务器下次连接时不需要握手步骤；
3）连接转移 - 无感网络切换：
* QUIC 的连接不再以 IP 及端口四元组标识，而是以一个 64 位的随机数作为 ID 来标识每一次连接，这样就算 IP 或者端口发生变化时，只要 ID 不变，这条连接依然维持着，上层业务逻辑感知不到变化，不需要重新握手，不会中断，也就不需要重连，继续传输数据。对移动端 WiFi、4G 各种复杂的网络环境，比较友好，特别适合 移动端音视频传输！（比如大家使用公共 NAT 出口时，有些连接竞争时需要重新绑定端口，导致客户端的端口发生变化，此时如果是 TCP，则需要重新建立连接！）；
* QUIC 通信通道的定义基于 ID 而不是 IP+端口，这使得切换网络后继续转发连接成为可能，在 IP地址和端口 变化的情况下，可以无需重新建立连接，继续通信。对移动设备的用户体验较为友好；
4）加密技术 - 盗链、盗播、劫持：
* QUIC 在安全性上，拥有与 TLS 等效的加密措施，且推动了 TLS1.3 的发展；
* QUIC 对 SSL 证书进行压缩，减少了证书传输量，且针对包头进行验证。有利于音视频秒开；
* QUIC 对每个散装的 UDP 包都进行了加密和认证的保护，并且避免使用前向依赖的处理方法（如CBC模式），这样每个 UDP 包可以独立地根据IV进行加密或认证处理；
* QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO，所有报文头部都是经过认证的，报文 Body 都是经过加密的。这对音视频安全性更有保障；
* QUIC 采用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后会马上再协商会话密钥，这样可以保证密钥的前向安全性，之后可以在通信的过程中就实现对密钥的更新。接收方意识到有新的密钥要更新时，会尝试用新旧两种密钥对数据进行解密，直到成功才会正式更新密钥，否则会一直保留旧密钥有效；
5）向前纠错 - 减少ARQ、无卡顿：
* QUIC 采用前向纠错（FEC）方案，即每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。具体实现类似于RAID5，将N个包的校验和（异或）建立一个单独的数据包发送，这样如果在这N个包中丢了一个包可以直接恢复出来。除此之外还可以用来校验包的正确性。完全不需要重传，有利于保证高速性，N可以根据网络状况动态调整；
* 在重要的包，比如 握手消息 发生丢失时，能够根据冗余信息还原出握手消息，提升握手成功率，这对提升直播秒开成功率有帮助；
6）自适应拥塞控制 - 降低丢包、流畅：
* QUIC 拥有完善的数据包同步机制，在应用层做了很多 网络拥塞控制 层面的优化，能有效降低 数据丢包率，这有助降低复杂网络下的直播卡顿率，提高流畅度；
* QUIC 拥有 “自适应” 拥塞控制（对TCP友好），有效减少移动客户端重新连接的次数，对移动直播有利；
* QUIC 应用程序不需要停机和升级，就能实现拥塞控制的变更，我们在服务端只需要修改一下配置，reload 一下，完全不需要停止服务就能实现拥塞控制的切换；
* QUIC 的数据段落编号，使用 Packet Number 代替了 TCP 的 sequence number，并且每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。这使得它的重传没有歧义性（对比 TCP）；
* QUIC 的流量控制，是通过 window_update 帧 告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据。通过 BlockFrame 告诉对端由于流量控制被阻塞了，无法发送数据；
* QUIC 具有热插拔特性，可以针对不同业务，不同网络制式，甚至不同的 RTT，使用不同的拥塞控制算法；
* 不允许 Reneging：一个 Packet 只要被 Ack，就认为它一定被正确接收，减少重传干扰；
* 更多的 Ack 块：Quic Ack Frame 可以同时提供 256 个 Ack Block，在丢包率比较高的网络下，更多的 Sack Block 可以提升网络的恢复速度，减少重传量；
* QUIC 算上了 服务端的 Ack Delay 时间，从而拥有更准确的 RTT；
信道保护 各种技术：
* 根据网络环境采用合适的 QoS 信道保护 技术，采用 “向前保护”FEC、“丢包重传”ARQ、“码率自适应”ABC - 多管齐下；
* 使用 FEC 编码算法的时候要根据丢包率（PLR, Packet Lost Rate）来设置冗余度；
* 使用 前向纠错 FEC 算法，优点是数据包只需要传输一次，传输延迟不会受到 RTT(Round Trip Time) 的影响，不会增加额外的延迟时间；缺点是需要增加冗余数据包，降低了传输信道的利用率。总的来说是一种“空间换时间”的策略；
* 具体地来说，发送端给每一个数据包都植入顺序号码和时间戳，顺序号码代表被发送数据包的顺序，允许接收端可以通过监测顺序号码来发现丢包事件；发送端维护一个缓冲队列，当收到重传请求的时候将会重传数据包。接收端也会维护一个缓冲队列，等待尚未收到的数据包以及对已经收到的数据包进行排序；
* ABC 全称 Adaptive Bit-rate Control，中文意译为 码率自适应，是服务端和推流端协作控制码率来自动适应网络环境变化的技术。码率自适应的目的是为了对抗弱网环境。在网络好的情况下，适当提高码率，提高语音视频的质量和降低延迟；在网络差的情况下，适当降低码率，保障语音视频通话的可用性和流畅性，适当牺牲音画质量；
QUIC on Web 的一些数据：
* QUIC 的优势非常明显，即使在元素比较少（12个元素）的情况下，相比 HTTP 也能提升 9%，相比 HTTP2 提升 42%，相比 HTTPS 提升 52%；
* 在页面元素增多的情况下，QUIC 的优势就更加明显，相比 HTTP 提升 36%，相比 HTTP2 提升 47%，相比 HTTPS 提升 64%；
* QUIC 请求的首字节时间（rspStart）比 Http2 平均减少 326ms，性能提升约 25%，这主要得益于 QUIC 的 0RTT 和 1RTT 握手时间，能够更早的发出请求；
* 另外 QUIC 请求页面加载完成的时间（loadEnd）平均减少 2s，由于整体页面比较复杂，很多其它的资源加载阻塞，导致整体加载完成的时间比较长约 9s，性能提升比例约 22%；
QUIC 缺点：
* QUIC 协议非常复杂，甚至比 Http2 更复杂，因为它做了太多事情。客户端实现起来比较复杂；
* 为了对抗 DDoS，一般防火墙都严格过滤 UDP，一定程度上限制了 UDP 在广域网的发展；
* QUIC 需要在包头打入 流ID（flowid），这个特性可能会使不少场景无法使用 QUIC；
QUIC 实现时还需优化的地方：
* “如何提升 0RTT 成功率”：需要实现 ServerConfig ID 进程间共享和分布式集群的 Cache，即使用全局公共缓存；
* “减少服务端本地的 CPU 消耗量”：对 ServerConfig 的内容签名和校验（RSA、ECDSA 签名）等，使用 SSL硬件加速卡集群，对加密签名的计算，进行异步代理；
* “实现连接迁移”：QUIC Connection ID - 同一台服务器保存了相同的 Stream 及 Connection 处理上下文，能够将该请求继续调度到相同业务的机器，这个需要开发功底；
* “动态的拥塞控制算法”：在实际应用中，需要对线上使用情况进行很多的变量统计和分析，包括 0RTT握手成功率、握手时间、密码套件 使用分布，QUIC 协议的版本，stream并发数量 等等等等。根据这些数据进行流量的动态控制；
QUIC 与 直播推流：
1）直播痛点-卡顿
* 卡顿是最影响直播体验的因素之一，也是最难解决的问题之一。在流媒体的传输链路中，任何一个环节丢包都可能导致用户观看卡顿；
* 主播端的推流卡顿最影响观看体验，会直接影响到所有观看直播的最终用户。主播推流卡顿在部分场景会特别显著，比如户外直播就非常考验在网络状况复杂的情况下推流的稳定性；
* QUIC 的众多特性，都仿佛是专门为了解决卡顿而存在！
2）QUIC 是什么？为什么可以减少卡顿？
* QUIC 传输层基于 UDP 协议，但却是一种可靠的传输协议，因为它将很多可靠性的验证策略从系统层转移到应用层来做，这样可以使用更适合现代流媒体传输的拥塞控制策略；
* 使用 QUIC 改善直播体验，就是用它来代替直播中 TCP 协议所扮演的角色
References：
QUIC 协议初探 - iOS 实践 - https://www.jianshu.com/p/bd173abd591a
关于 QUIC 比 Http2 慢的讨论 - https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/6DxYp9UxkYQ
《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》 - http://www.52im.net/thread-1309-1-1.html
举报/反馈
0
0
收藏
分享
