提速 40%，融云基于 QUIC 深度优化通信协议

 8 月 17 日（本周四），融云直播课从排查问题到预警风险，社交产品如何更好保障体验、留住用户？欢迎点击报名~

各分位（P99、P95、P50）连接速度提升 30%~50%；关注【融云全球互联网通信云】了解更多

网络延迟低连接耗时终端占比提升 50%，高连接耗时终端占比压缩至 1% 以内；

在基础设施受限的弱网地区和连接效果难保证的跨网场景下，均可获得与正常网络相当的顺畅体验。

——这些都是融云基于 QUIC 深度优化通信协议的实践效果。

作为中国互联网出海浪潮中最重要的基建公司之一，融云一直致力于提升全球网络的“最后一公里体验”。

基于 QUIC 深度优化通信协议，融云实现了多链路智能竞速选路，进一步降低连接时长，保证链路不仅连得快，而且连得稳。

---

关于 QUIC

QUIC（Quick UDP Internet Connection）是 Google 提出的一个基于 UDP 的传输协议，因其高效的传输效率和多路并发的能力，成为下一代互联网协议 HTTP/3 的底层传输协议。

2021 年 IETF（Internet Engineering Task Force，互联网工程任务组）发布 RFC 9000，标志着该协议正式成为一个标准协议。

伴随着移动互联网的发展，网络交互场景越来越丰富并对及时性提出更高要求，传统 TCP 固有的性能瓶颈越来越不能满足这一需求，需要引入 UDP。两者的特性分别为：

UDP（User Datagram Protocol）用户数据报协议于 1980 年在 RFC 768 中定义，主要特性是数据传输效率快。

TCP（Transmission Control Protocol）传输控制协议于 1981 在 RFC 793 中定义，主要特性是数据传输可靠性。

基于 UDP 与 TCP 的特性，如果要实现可靠数据传输，TCP 是较为简单的选型，但是在网络传输通道质量较差的情况下，如丢包、延迟率较高、带宽受限等，会产生建立连接的握手延迟大、队头阻塞、网络拥塞等问题。

为了解决移动端场景常见的弱网和网络切换问题，同时兼容互联网上已经运转多年的网络设备，Google 提出了应用层的 QUIC 协议。

QUIC 融合了 UDP 协议的速度、性能与 TCP 的安全、可靠，具备安全、高效、可靠等传输特性。

建连更快

相比于 TCP+TLS，QUIC 建联速度提升了 1~3 倍。其客户端第一次建连的握手协商需 1-RTT（Round-Trip Time，往返时延）。

已建连的客户端重新建连时，通过应用数据和协商参数合并的方式，QUIC 重用在先前的连接中协商的参数，可以做到 0-RTT，使得客户端能够在握手完成前就发送应用数据。

对比来看：

TCP 需要 1-RTT；
TCP+TLS1.2 需要 3-RTT；
TCP+TLS1.3 需要 2-RTT。

TCP 为了可靠性设计了一系列的规则，比如建立 TCP 连接时需要进行三次握手，这会造成更多的 RTT 花费及很多字节的额外开销。

◾ TCP 1-RTT 流程图：

◾ TCP 1-RTT 交互数据流：

TLS1.2 通过 KeyExchange 进行密钥协商，即 ServerKeyExchange、ClientKeyExchange，密钥交换本身就需要一个交互来回，所以总共有四次握手交互，详细参考 RFC 5246。

◾ TLS1.2 2-RTT 流程图：

◾ TLS1.2 2-RTT 交互数据流：

TLS1.3 借助扩展进行密钥交换，只需要三次握手交互，详细参考 RFC 8446。

◾ TLS1.3 1-RTT 流程图：

◾ TLS1.3 1-RTT 交互数据流：

QUIC 基于 UDP，只需花费 0~1-RTT 就可以建立连接。

客户端第一次建连的握手协商需 1-RTT，建联完成后即可发送数据。

◾ QUIC 1-RTT 流程图：

◾ QUIC 1-RTT 交互数据流：

已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复连接，仅需 0-RTT 时间。

◾ QUIC 0-RTT 流程图：

◾ QUIC 0-RTT 交互数据流：

可插拔的拥塞控制

QUIC 协议默认使用了 TCP 协议的 Cubic 拥塞控制算法，作为应用层协议，它也支持 CubicBytes、Reno、RenoBytes、BBR、PCC 等拥塞控制算法，用户可以插拔式选择。

无队头阻塞多 Stream

QUIC 给每一个 Stream 都分配了一个独立的滑动窗口，使得一个连接上的多个 Stream 之间没有依赖关系，都是相互独立的、各自控制的滑动窗口。

假如 Stream3 丢了一个 UDP 包，也只会影响 Stream3 的处理，不会影响其他 Stream。

◾ TCP 连接

◾ QUIC 连接

支持连接迁移

QUIC socket 采用 UDP 收发数据，一个连接用一个 ConnectionID 为唯一标识。

当用户设备在蜂窝网络和 Wi-Fi 等不同网络切换时，只要数据包中的 ConnectionID 不变，服务端都可以将不同的四元组关联到同一个连接上下文。

对用户来说，无需断线重连，可以无感知地完成信号切换，在越网情况下会有更好的表现。

◾ TCP 重连 VS. QUIC 连接迁移

安全性

相比于 TCP，QUIC 是 UDP 与 TLS 的结合，在保证连接速度的同时保证了安全性，而 TCP 需要额外增加 TLS 相关安全传输层协议封装。

◾ TCP+TLS VS. QUIC

---

融云优化实践及效果

移动互联网深化发展，我们的生活、工作已经全面实现移动化，各种移动端 App 成为了承载我们生活、工作场景的关键入口。

而移动端应用体验的一致性对网络有着更高要求，比如拿着手机进入电梯，就会遇到网络切换而重新建连的问题。亦或者，在融云服务中国互联网出海的广泛实践中，新兴市场参差不齐的网络基建是最令开发者头疼的难题之一。

而 QUIC 的更快建连和连接迁移等特性是解决以上问题的有效方案，因此融云基于 QUIC 对私有通信协议进行优化。

优化实践

为保证链路的平滑过渡以及通道链路的稳定性，在调整现有链路通道时，融云优化升级整体设计及实施依照 TCP/UDP 通道互补、业务无感知、多链路竞速等准则。

TCP/UDP 双通道

在原有 TCP 链路的基础上增加 QUIC 接入链路，可以在保证链路可靠性的同时提升速度。

QUIC 与全球加速链路结合，还可更好降低连接时延。

在网络状态不稳定的地区，当遇到网络抖动时，QUIC 有更友好的丢包重传策略，可以做到丢哪个包补哪个包，而不需要对所有的包进行重传。

无感知的通道升级

为保证对现有业务的无感升级，通过客户端与服务端动态协商确认客户端与服务端双向支持协议，下发 QUIC 接入地址，在保持现有协议层次不变的基础上对融云私有通信协议进行 QUIC 封装，上层业务无感知。

◾ 协议协商交互流程
客户端与服务端动态协商，在双方都支持 QUIC 链路的情况下开启 QUIC。

◾ 协议栈层次
为保证上层业务无感知，采用 QUIC 对通信协议进行封装，上层业务接口无变动。

多链路竞速选路更优

考虑到海外不同地区的网络特点，在某些地区，个别运营商可能对 UDP 进行 QoS 限速，融云采用 TLS 优先，TCP 为辅，QUIC 保底的方式进行链路接入。

多链路竞速在保证链路优先级的情况下择优选择。

这样，在保证接入链路稳定性的同时保证连通率、连接速度。

优化效果

连接耗时降低

QUIC 协议握手连接更快，允许客户端无需等待 TLS 握手完成就开始发送应用程序数据，从而达到快速建立连接的效果。

从客户端数据看，P50 降低 30%，P95 降低 45% 以上，P99 降低 50% 以上，越是长尾指标提升越明显。

从服务端看，Socket 低耗时占比提升 50%，高耗时的连接占比压缩在 1% 以内，服务器的吞吐量得到提升。

弱网质量与网络兼容性提升

在一些弱网丢包和延迟的混合场景下，QUIC 比 TCP 有 10% 左右的提升。

不过，在不同国家和地区，对 UDP 以及 TLS 加密的网络兼容策略不同，需要配合多通道探测和历史策略下发一起使用。

总之，针对“最后一公里体验”难题，融云不断优化服务、迭代产品，以更快连接、更高并发服务开发者丰富多样的业务探索。本次通信协议优化，是融云作为专业、简单、稳定的通信云服务商在用户体验和服务效率方面的又一次稳步跃升。