QUIC知识汇总及其在视频直播的应用调研

发布时间:18-11-1923: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

返回顶部