01简介QUIC协议从传输层面相比TCP有几个优势：0-RTT连接建立QUIC协议基于UDP，本身不需要握手，使用Diffie-Hellman或ECC算法，只在1-RTT中完成对等密钥协商。QUIC协议的0-RTT连接建立使用TLS1.3，通过early_data完成加密数据的透传。多路复用/无头对头阻塞与HTTP/2多路复用相比，QUIC不受头对头阻塞的影响，每个流更加独立，多路复用的效果更好。连接迁移不同于TCP使用四元组来标识唯一连接。QUIC使用64位的ConnectionID来标识连接。基于这个特性，QUIC使用了连接迁移机制。当四元组发生变化时（比如客户端从WIFI切换到蜂窝网络时），尝试“保留”之前的连接，从而保持数据传输不中断。可定制的拥塞控制QUIC协议没有定义拥塞控制算法的使用。这部分在应用层实现，方便开发者自行优化迭代。02QUIC协议和TCP从协议层面的区别SeparatePacketNumberSpacesQUIC协议定义了4种不同的加密级别，每个加密级别使用不同的包序号空间。包序号单调递增相同包序号空间中的包序号单调递增，避免重传歧义。QUIC协议的包序号空间只标识传输顺序，数据包内容的顺序由STREAM帧中的偏移量（offset）标识。ClearerLossEpoch当一个QUIC数据包被声明为丢失时，QUIC开始一个丢失检测周期，任何在确认之后发送的QUIC数据包都会刷新检测周期的时间。与TCP不同，TCP将始终等待序列号空间中??的间隙被填充，尽管同一个数据包在传输过程中可能会丢失多次。这样做的意义在于，QUIC可以在每个往返时间（RTT）内更准确地更新拥塞窗口的大小。不食言不能食言。一旦数据包被对等方确认，修改后的数据包就不能再被声明为丢失。这样的设置大大简化了双端传输协议的设计，也减轻了发送端的内存压力。与TCP的SACK相比，MoreACKRanges只能确认三个段（范围），而QUIC协议的ACK帧支持多段（范围）确认。在高丢包情况下，加快重传恢复速度，避免距离确认分散造成传输中断。DelayedAcknowledgements的显式校正QUIC协议会计算接收到数据包和发送该数据包的ACK之间的延迟时间，并将其显式写入ACK帧。此设置旨在更准确地计算网络的往返时间。ProbeTimeoutReplacesRTO和TLPQUIC协议使用PTO（probetimeout）检测超时机制，其中包括对端预期的最大确认延迟，而不是固定的最小超时。与TCP的RTO超时不同，QUIC协议不会在PTO到期时尝试崩溃拥塞窗口，因为尾部数据丢失并不表示网络持续拥塞。只要有剩余的拥塞窗口，发送方就可以不受限制地发送更多的数据包，即使此时已经发生了PTO超时。与TCP的RTO机制相比，PTO机制更为激进。TheMinimumCongestionWindowisTwoPacketsTCP使用一个数据包作为最小拥塞窗口。如果此数据包丢失，则意味着需要等待RTO重传，这很可能远大于往返时间(RTT)。QUIC协议推荐使用两个包作为最小拥塞窗口，虽然这样做会增加流量，但也算安全。03QUIC协议在网易云信中的应用在网易云信的音视频业务框架中，信令用于SDP交互、会议室的创建和管理、用户信息的上传和传递等，其传输稳定性和时效性很关键。传统的WEBRTC推荐使用WebSocket作为信令传输协议，受限于TCP协议的缺陷，其在连接建立时间、传输效率、抗弱网等方面的效果并不理想。这些问题直接影响音视频业务的首帧时长、链路稳定性、弱网阻等基线指标。云信QUIC加速服务设计：网易云信使用QUIC协议代替WebSocket协议进行信令传输，并在应用层和协议层做了一些优化实践：复用：根据不同信令的特点，对请求进行分类分级。对于Request/Response类型的消息，可靠性和实时性要求最高，采用高优先级的STREAM进行传输。对于用于链路保活的心跳消息，使用优先级较低的STREAM进行传输。不可靠传输扩展：有一种不需要接收端回复的Notify报文，常用于广播各端用户的网络状态或其他信息。它对实时性要求高，但对可靠性要求不高。对于这个信令，我们可以利用QUIC协议的不可靠传输特性进行传输。这种特殊的传输使用了DATAGRAM帧。要传输这种特殊的帧，需要在Initialpacket(name=max_datagram_frame_size,value=0x20)的CH模块的QUIC传输参数表中声明，以通知对端DATAGRAM帧支持。max_datagram_frame_size传输参数是一个整数值（表示为可变长度整数），表示端点愿意接收的DATAGRAM帧的最大大小（包括帧类型、长度和有效载荷），以字节为单位。DATAGRAM帧用于以不可靠的方式传输应用程序数据。帧中Type字段的形式为0b0011000X（或取值0x30和0x31），最低位为LEN位（0x01），表示是否有Length字段：如果该位设置为0，则Length域不存在，DatagramData域扩展到包尾；如果此位设置为1，则存在长度字段。DATAGRAM帧结构如下：虽然DATAGRAM帧在检测到丢失时不会重传，但也需要ack。数据包压缩：云信在传输层引入Deflate算法对STREAM帧进行压缩，旨在减少信令传输的带宽占用。动态冗余策略：由于信令不是流数据，FEC不适合间歇性数据传输。动态增加RTT、丢包率等指标的冗余保护，对于改善传输的弱网抗性也是相当积极的。角色。04云信QUIC网络性能弱首屏耗时和登录耗时上图是云信音视频服务信令和连接建立使用TCP和QUIC的对比。在第一帧的耗时指标上，QUIC有20%的提升。在登录耗时指标方面，QUIC有近30%的提升。主要原因是QUIC的连接建立相对于TCP+TLS有2~3个RTT优化，尤其是在高RTT场景下握手时间缩短。在直播场景中，云信QUIC优化了私有化的0RTT握手，使得连接建立更快。抗丢包上图为云信令数据在QUIC和TCP链路下所能承受的最大丢包率。QUIC在上行丢包率达到70%时依然可以提供服务，下行边界甚至可以抵抗75%的丢包。TCP链路将断开连接并在丢包45%时重新连接。与TCP的信令链路相比，QUIC链路有50%的提升。主要原因：云信实现了动态冗余，在检测到丢包后会增加冗余，这样冗余包可以用来弥补高丢包，带来抗丢包性能。QUIC改进的流量控制和拥塞控制算法，让QUIC在弱网下获得更大的传输优势。对于带宽限制，我们也做了QUIC在带宽受限情况下的带宽利用率。基本上QUIC的带宽利用率可以达到90%以上，但是TCP就差很多了。05Prospect&Summary网易云信在可靠数据加速方面，对可靠数据传输有很大的提升，但仍有一些地方需要优化：一旦出现单向丢包，会导致服务端和端增加双向冗余。冗余，导致不必要的冗余增加。后面会检测到单向丢包，只对有丢包的链路增加冗余。针对高RTT、高丢包场景，QUIC拥塞控制算法需要不断优化。网易云信将在各种极端情况下，继续为用户提供音视频领域的优质服务。作者介绍董相成，网易云信高级音视频引擎开发工程师，负责网易云信低延迟直播业务和音视频媒体引擎开发，在音视频数据传输和网络方面有丰富的经验数据转发。
