共计 4758 个字符，预计需要花费 12 分钟才能阅读完成。
👉腾小云导读
兴许你有这样的体验：当你退出腾讯会议散会，老板正在公布重要工作时，你恰好要进电梯时 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」领作者举荐的连贯迁徙学习材料