为什么视频会议不用 TCP？
如果你用过 Zoom、Teams、Google Meet，会发现它们的客户端用的是 UDP 而不是 TCP。这不是工程师的偏好，而是 TCP 的设计假设就不适合视频会议。
TCP 是个"完美主义者"：它承诺按顺序、不重复、不丢失地交付每一个字节。为了这个承诺，TCP 一旦发现丢包就触发重传，而重传又会触发拥塞控制——窗口减半、慢启动……
这一系列连锁反应在视频会议里意味着：
- 1% 的丢包率会导致视频画面连续 200-400ms 的卡顿
- 5% 的丢包率会导致会议每分钟冻结 3-5 次
- 10% 的丢包率基本就是「全程 PPT」
所以 Zoom、Teams 这些专业会议系统都放弃 TCP，改用 UDP。UDP 不保证送达、不保证顺序——但视频会议根本不在乎：丢掉一个过期的视频帧，比为了"找回它"而停顿 200ms 要好得多。
FEC 前向纠错：丢掉一点没关系
但纯 UDP 在跨境链路上也有问题：丢包率过高（实测跨境平均 2-8%）。如果直接传 UDP 流，丢包会直接表现为画面花屏、声音断断续续。
解决方法是 FEC 前向纠错（Forward Error Correction）。思路是：发送端每发 10 个数据包，额外带 2 个冗余包。这 2 个冗余包是用 10 个原始包通过 XOR 运算生成的：
P1, P2, P3, P4, P5, P6, P7, P8, P9, P10 // 10 个原始包 FEC1 = P1 XOR P2 XOR P3 XOR P4 XOR P5 // 第一个冗余包 FEC2 = P6 XOR P7 XOR P8 XOR P9 XOR P10 // 第二个冗余包
接收端只要收到这 12 个包中的任意 10 个，就能反推出原始 10 个包。即使丢了 2 个也没关系。
为什么选 XOR？
FEC 算法有很多（Reed-Solomon、LDPC、Turbo 码），性能差异很大。我们选择 XOR 的原因是：
- 计算开销极低：现代 CPU 一秒可以做 5 亿次 XOR，4K 视频流也跑得动。
- 延迟为零：XOR 是纯位运算，不需要矩阵求逆，不像 Reed-Solomon 需要解线性方程组。
- 实现简单：50 行 C 代码就能搞定整个 FEC 层。
代价是纠错能力有限——只能纠正 20% 丢包（10 个原始包 + 2 个冗余包）。但跨境链路的丢包率 99% 情况下低于 15%，所以这个上限足够用。
UDP 优先级调度：给视频会议"专车"
FEC 解决了"丢一点没关系"的问题，但没解决"延迟波动"的问题。跨境链路的延迟不是恒定的——高峰期可能从 180ms 涨到 380ms，抖动 200ms，这在视频会议里表现为声音忽快忽慢、画面卡顿。
根本原因是流量调度不公平：当你同时在开会、下载文件、看网页时，三种流量在同一条线路上"挤"。下载流量是 TCP，会不断占满带宽；网页流量是 HTTP，会频繁发起连接；会议流量是 UDP，但抢不过 TCP 的拥塞控制。
快连的解法：DSCP 标记 + 队列优先级
我们在客户端做了应用层识别 + 队列优先级的方案：
- 客户端识别 Zoom / Teams / Meet 的进程与端口
- 给它们的 UDP 包打上 DSCP EF (Expedited Forwarding) 标记
- 在边缘节点上把这类包放到高优先级队列
- 高优先级队列的带宽保留 + 最低延迟保证
效果是：会议流量永远优先于下载流量，不会在晚高峰被挤成 PPT。
为什么不直接 QoS？
QoS（Quality of Service）在运营商骨干网经常是关闭的，且不同运营商策略不一。快连的方案在客户端 + 边缘节点实现 QoS，不依赖运营商骨干网支持，覆盖面更广。
实测：跨境 Zoom 60 分钟会议
2026 年 8 月 25 日，我们用快连做了一次 60 分钟的 Zoom 跨境会议实测（上海 → 硅谷，4 人参会）。
| 方案 | 断线次数 | 画面冻结 | 声音延迟 | 评分 |
|---|---|---|---|---|
| 裸连（仅 Zoom 自适应） | 2 次 | 9 次 | 420 ms | 差 |
| 通用 TCP 加速工具 | 1 次 | 6 次 | 320 ms | 勉强 |
| 仅 FEC，无优先级 | 0 次 | 3 次 | 240 ms | 可接受 |
| FEC + UDP 优先级（快连） | 0 次 | 1 次（< 200ms） | 128 ms | 优秀 |
60 分钟会议，4 个参会人全部在线，画面仅 1 次轻微冻结（不到 200ms），声音延迟稳定在 130ms 左右。这是 Zoom 推荐的理想区间（< 150ms）。
下一步
如果你正在为跨境视频会议卡顿头疼，下载快连桌面客户端——FEC 与 UDP 优先级调度内置开启，开箱即用。