会中切换网络总掉线？腾讯会议用这种方案让你好好开会

👉腾小云导读

也许你有这样的体验：当你加入腾讯会议开会，老板正在发布重要任务时，你恰好要进电梯时 wifi 切换成了 cellular，画面开始「转菊花」，网络断开重连却需要好久，最终老板的指示你一个字都没听清楚!。这个问题，要从会议的传输协议开始说起。会议团队遇到了网络切换的难题，是怎么解决的呢？欢迎继续往下阅读，看看腾讯会议团队的思路。

👉看目录，点收藏

1 传统 TCP+TLS 套装有哪些弊端

2 QUIC 带着一大堆 buff 来了：条件分析

3 尝试吃掉 QUIC 这只大螃蟹：解决方案

4 蟹钳厉害，务必小心：难点挑战

5 螃蟹果然美味：未来展望

6 路漫漫其修远兮：优化成果

01、传统 TCP+TLS 套装有哪些弊端

腾讯会议的业务特性决定了客户端和服务器需要建立长连接，而且要保证安全可靠，因此我们在选择传输层协议时采用了传统 TCP+TLS 套装。TCP 协议提供了可靠传输通道，TLS 加密协议为通道提供了安全保障。TCP 连接建立需要经过三次握手，在此基础上TLS 握手协议又需要四次握手。

因此，在正式开始数据通信之前，建立 TCP 连接需要 1.5 个 rtt，完成通道的 TLS 加密需要 1 个 rtt (TLS1.3)，会议业务整个握手总体流程如图 1 所示：

图 1 基于 TCP+TLS 技术的长链接建立流程

从图 1 可以看到：统计数据表明，所有登录失败的用户中，有 41.53% 的用户是因为连接建立超时导致登录失败。因为弱网情况下rtt 较大，如果连接建立的流程复杂的话必然导致完成握手的耗时较多，超时的可能性更大。也就是文中开头提到的：重新连接耗时比较久。因此，简化握手环节，减少登录耗时，提高登录成功率和弱网抗性是需要解决的问题。

那为什么目前的机制下，wifi 和 cellular 之间互相切换需要断开重连呢？因为 TCP 协议使用一个四元组来标识一个长链接、源 IP 地址、目的 IP 地址、源端口、目的端口。当用户设备网络在 wifi 和 cellular 之间切换时，源 IP 会发生变化。因此 TCP 天然无法支持在 wifi 和 cellular 之间无缝切换，也就导致一旦用户切换网络，整个长链接必须断开重连，否则数据无法继续传输。表现在会议产品上就是会出现「转菊花」场景，等待重连成功，见图 2：

图 2 TCP连接情况下 cellular/wifi 切换表现

在断开重连期间，所有指令数据都无法发送接收。日常会议过程中，当用户进出电梯或者偶现 wifi 信号不好，导致 wifi 和 cellular 互相频繁切换的场景是非常常见的。也就是文中开头说到的场景了。这样的体验其实非常影响用户会议有效性。因此让数据通道能够实现在 wifi 和 cellular 之间无缝切换，更是亟待解决的问题。

02、QUIC 带着一大堆 buff 来了！

QUIC 协议与 TCP 相比，本身就具有快速建立连接的优势（0/1-rtt），而且同样是可靠传输通道，自带加密通信 buff，省略了 TLS 的握手步骤。QUIC 协议的握手流程见图 3：

图 3 QUIC 握手流程

如图 3 所示，QUIC 在初次建立连接时， 只需要 1 个 rtt。客户端收到服务端发送的 Rejection 之后，会在下次发送数据时带上客户端的加密信息，跟应用数据一起发送到服务端，从而在一个 rtt 里完成握手和数据加密动作。相较于 TCP+TLS，它减省了 1.5 个 rtt。结合会议业务长连接握手流程，又能省掉 TLS 握手之前的协商过程。应用 QUIC 协议的长链接建立流程如图 4 所示：

图 4 基于 QUIC 技术的长链接建立流程

结合会议长连接建立的整体过程，理论上连接建立耗时能够减少 40%~50%。这其中还没有包括 QUIC 协议本身比 TCP 在某些场景下传输效率更高带来的收益。

同时，QUIC 协议的设计是可以支持连接迁移（Connection Migration），因为 QUIC 是使用 connectionID 来唯一标识一个链接。当客户端网络在wifi 和 cellular 之间切换时，即使源 IP 发生改变，这个长链接的 connectionID 不变，数据通道就不会断。连接迁移流程如图 5 所示：

图 5 连接迁移UML序列图

概括如下：

• 连接迁移之前，客户端的 IP1，使用非探测包（non-probing packet）和服务端进行通信。
• 客户端的 IP 变成 2，它可以发送包含非探测帧（non-probing frames）的包，将连接迁移到新的地址。
• 客户端在新路径启动路经验证，验证新路径的可达性。

• 客户端发送包含 path_challenge 帧的探测包（probing packet），path_challenge 帧里面包含一个不可预测的随机值。

  服务端在 path_response 帧里面包含前一步 path_challenge 接收到的随机值，响应探测包（probing packet）。

  客户端接收到服务端的 path_response，验证 payload 里面的值是否正确。

  同样的，服务端也需要使用路经验证，验证客户端对其新IP地址的所有权。

因此，引入 QUIC 协议之后的长链接能够做到在 wifi 和 cellular 之间的无缝切换，而不必重新建立连接。用户在会议中发生网络切换场景时，音视频数据和开关麦克风/摄像头等等网络操作都可以直接续传，用户是完全无感知的。

03、尝试吃掉 QUIC 这只大螃蟹：解决方案

QUIC 目前只有 http 协议的应用，那么它对于长链接的适用性怎么样呢？ 理论上完全可行，实际上我们一无所知，业界之前也没有做过这方面的尝试。但既然它如此满足需求，为什么不试一试呢？我们考察了业内比较完善的 quic 组件方案，详见图 6：

图 6 QUIC 方案选型

*注：cronet 仅暴露应用层 http 接口，无法满足传输层接口封装需求。QuicTransport 仅支持 TLS1.3 加密实现，无法与 stgw 互通，后者还停留在 quic 私有加密算法版本。

综合接入成本、使用广泛性和其他各方面考虑， TQUIC 是较优的选择。TQUIC 是由腾讯公司 stgw(secure tencent gateway) 团队提供的与其后台架构相辅相成的 sdk。它只封装了原始的 quic 功能接口，轻便易用。如果使用 stgw 的 quic 接入层服务，TQUIC 应该是首选。我们将 TQUIC sdk 集成到客户端，打造了新的客户端服务器交互架构。如图 7 所示：

图 7 QUIC 协议传输网络

接入之后，业务数据包传输没有任何问题。但是 tquic 基于 goolge 的 cronet 库实现，google 只实现了 android 端的连接迁移， 而腾讯会议的网络层是跨平台的设计。因此我们面临的一个重要问题是需要将连接迁移的特性扩展到全平台，通过分析 google 的 android 平台实现。该技术方案如图 8 所示：

图 8 cronet里实现的连接迁移

其中实现了对 android 平台的物理网络监听。 在网络切换时，会收到系统通知，由于 ip 已经切换了， 原始 ip 绑定的 socket 已经无法继续通信。因此需要新建一个 socket 跟新的 ip 绑定，继续进行网络收发包，并且对原始socket 缓存中发送失败的包进行重发，从而完成网络通道的迁移。

通过对连接迁移的原理和 google 的代码分析，结合系统 socket 编程技术，引入跨平台通用的连接迁移技术方案，真正实现了移动端 wifi 和 cellular 的无缝切换！

04、蟹钳厉害，务必小心：难点挑战

2020 年开始投入 QUIC 预研时， QUIC 还没有在业界成为主流，主要的原因有以下几点：

• 中间件为了保证 TCP 网络链路通畅，强制丢弃 UDP 包；
• 机构和企业设置拦截防火墙，关闭了 QUIC 的通用端口。

而切换到新的建连方式，又面临了如下挑战：

• 提供 QUIC 服务的服务器集群发生故障，导致 QUIC 大规模连接失败；
• 引入 TQUIC 的 sdk，做的改造还没有经过外网的大量验证，可能带来crash，在长连接建立路径上发生 crash 将直接导致登录失败，会议所有功能都无法使用，这是致命的。

为了避免这些问题导致的 QUIC 不通，或者会议服务不可用的情况，在正式上线前，我们从四个方面进行了预防，规避和补救。

• 从 TCP 切换到 QUIC 前，先进行嗅探，确认此路可通，才具备切换条件，而且连通性在使用过程中也会进行刷新；
• 通过云端配置 QUIC 开关，可以进行地区，版本，网段，具体用户等粒度的控制，进行 QUIC 功能的灰度和日常容灾；
• 使用 QUIC 过程中，一旦产生协议层面的错误，就降级成 TCP；
• 在 QUIC 长连接建立过程中设置 crash 保护，一旦发生 QUIC 引入的crash，降级成 TCP，避免连续 crash；

总结如下图：

图 9 QUIC 开启和在线降级策略

在正式灰度 QUIC 之前，我们统计了嗅探数据：外网的 QUIC 连通性达到98% 以上，所以理论上是可以全面铺开的。完成这一系列的防护措施之后，才开始灰度，2021 年已经完成全量。

关于 QUIC 的知识科普，官方的学习资料和一些科技大佬的解析都非常通俗易懂、值得学习。如果各位感兴趣的话，可以在公众号后台回复 QUIC 领取。

05、螃蟹果然美味：优化成果

通过将 QUIC 协议引入到建立客户端和服务器之间的长链接过程，并结合腾讯会议产品的登录握手协议，利用 QUIC 的快速握手同时通道加密的特性和连接迁移特性，取得了较大的优化效果。

根据线上数据统计，登录平均耗时优化效果达 48.6%。因为登录耗时高产生的超时问题也得到改善，进而提高了登录成功率，优化效果达 0.09%。

在实际会议场景中，大家用得最多的应该是开关麦和开关摄像头功能。有过会议体验的人应该有所感触，网络不是很好的时候，点击开麦按钮，半天都没有反应，令人捉急。或者要关麦的时候怎么都关不了......这些尴尬情况在使用QUIC 之后也得到了有效改善。

QUIC 协议的拥塞控制算法比 TCP 更加灵活。 因为加大了 sack，所以其丢包重传策略也比 TCP 更高效，可以有效增加弱网抗性。根据数据统计，会议中开关麦成功率，开关摄像头等等关键信令成功率都得到不同程度的提升。

在添加网络损伤场景下，QUIC 连接也表现出比 TCP 更好的网络抗性.通过专业网络损伤仪模拟不同的弱网场景，在加大丢包率和抖动的情况下，TCP 长链接的在线心跳在丢包率 70% 场景下会断开。而 QUIC 长链接，同样的心跳策略能扛住 80% 丢包率，如图 10 所示。

图 10 抗丢包率优化效果

从用户角度来说，最直观的感受是，网络切换再也不「转菊花」啦！

图 11 QUIC 连接情况下 cellular/wifi 切换表现

06、路漫漫其修远兮：未来展望

目前，QUIC 在会议业务长连接上的应用已经稳定运行 2 年多了。HTTP 切换QUIC 通道也基本部署完成、进入测试环节。QUIC 本来就是 google 为 HTTP 请求量身打造的。0-rtt、避免队头阻塞、多路复用等等黑魔法的加持，使 QUIC 在 HTTP 业务上更「得心应手」。升级版的腾讯会议将给用户带来网页秒开，资源秒加载的更棒的使用体验。

因为篇幅原因，这里对 QUIC 的知识科普有限。个人强烈推荐各位去看看 QUIC 官方的学习资料和一些科技大佬的解析，非常通俗易懂、值得学习。各位，可以在公众号后台回复 QUIC 领取（码住，别吃灰!）。

更多腾讯会议的优化 case，可直接点击腾讯会议10秒编译百万代码｜鹅厂编译加速标杆案例公开、企业微信零耦合集成腾讯会议和腾讯文档插件化架构实践。以上是本次分享全部内容，欢迎大家在评论区分享交流。

-End-

原创作者｜余一

技术责编｜余一

一直以来，性能优化是程序员面对的重要课题。页面功能、代码细节、数据库调优......你见过哪些令你「瞠目结舌」的优化？在工作中经历过哪些性能优化的项目？有什么经验分享？有哪些工具推荐？欢迎公众号评论区留言。

我们将选取1则最有创意的分享，送出腾讯云开发者-限定马克杯1个（见下图）。4月26日中午12点开奖。

关注腾讯云开发者并点亮星标

公众号回复「QUIC」领作者推荐的连接迁移学习材料