快连：把关键业务的带宽优先保障到位

2024 年下半年起，跨境网络场景对「关键任务优先保障」的需求出现了质变：金融交易员的回报延迟从「能忍」变成「亏损」、远程手术辅助的画面从「略微卡」变成「不能做」、跨国视频会议从「偶有花屏」变成「决策会延期」。我们和 120 多家企业客户深聊后发现，他们要的不是更快的带宽，而是「在带宽有限时，把对的那条流量放在最快的路径上」。这就是我们做智能动态流量调度的初心——不是为所有流量找一条最快的路，而是为关键任务找一条永远不慢的路。

过去这一年里，我们把自研的调度引擎重写了三版，节点从 24 个扩到 40+ 个国家和地区，引入了基于 WF2Q+（最坏情况公平排队）的优先级队列模型，把传统代理厂商普遍忽视的「实时带宽需求」做成了核心信号。下面是这次重构的关键 7 个章节。

1. 快连关键任务不是一两个 App，而是「时延敏感 + 带宽敏感 + 完整性敏感」的混合体

在调度引擎眼里，「关键任务」必须被精确定义。我们的分类方式和普通代理类工具完全不一样——

1. 时延敏感类（必须 < 80ms RTT）：金融交易订单提交、远程手术遥操作指令、VoIP 通话、远程桌面键鼠回传。这类任务对抖动比均值更敏感，宁可慢 5ms 也不能抖 30ms。
2. 带宽敏感类（下行 ≥ 8Mbps 持续 60 秒以上）：4K 视频会议推流、医学影像 DICOM 上传、AI 推理 batch 回传。带宽一旦跌破阈值，业务直接不可用。
3. 完整性敏感类（零丢包要求）：电子签名同步、代码仓库 push、合同传输的最后一公里、跨境文件归档。丢一个包就重传整段。
4. 混合类：最常见——远程医疗会诊同时要低延迟视频 + 稳定上传影像 + 偶尔的电子处方签名；跨国会议同时要语音低延迟 + 1080p 视频带宽 + 协作白板同步。

我们的客户端在用户登录后，会基于以上四类做一次轻量画像——你常用 Teams、Zoom、TradingView、Epic、Citrix 哪几个？用了哪些医学影像 PACS、代码托管平台？被识别为「关键任务」的应用会被打上 priority 标签，后续调度统统按这个标签走。

2. 快连调度不是「选最近节点」，而是「在同一时间窗里同时跑 5 条候选路径」

早期我们也用过「选最低延迟节点」这种朴素做法，结果是当一个节点拥塞时，所有用户同时被打挂。现在我们在客户端本地维护一个 实时候选集：每次关键任务发起时，调度器会向同一区域里的 5 个候选节点同时发出 RTT 探测包，间隔 100ms 取 10 个样本的滑动窗口中位数，而不是瞬时值。决策依据从单点延迟升级为「延迟 + 抖动 + 丢包率 + 带宽利用率」四维评分。

我们把这个评分模型叫做 KQ-Score（Kuailian Quality Score），它的核心思想是：你不需要知道哪条路径「理论最快」，你只需要在每一秒都选此刻最稳的那一条。下面是 4 个公开指标在 KQ-Score 里的权重（研发部 v5.0 内部文档，已脱敏）：

这个评分让「关键任务优先」不再是一句口号——它会持续地、可量化地影响每一次路径选择。同一秒里，可能 Zoom 走东京、GitHub push 走法兰克福、文件备份走新加坡，三条线互不抢带宽。

3. 快连优先级队列：从 SP（严格优先级）到 WFQ（加权公平排队）的工程取舍

教科书里讲 QoS 队列会先讲 SP（Strict Priority），简单粗暴——关键流量永远先发。问题是：一旦关键流量突发 5 秒，背景流量全部饿死。我们的金融客户就吃过这个亏——交易通道跑满时，邮件和工单系统全卡死，最后交易员误以为「订单没提交成功」重复点击，触发风控。

后来我们切到基于 WF2Q+（Worst-case Fair Weighted Fair Queueing 的改进版）的实现：关键流量保证最低权重 6，普通流量保证最低权重 1，剩余带宽按权重比例分配。这套设计带来的实际效果是：

• 关键任务延迟在 P99 上保持 < 65ms（测试条件：上海 → 法兰克福，跨太平洋）
• 普通下载任务被限速到 50% 链路容量，但不会饿死，平均吞吐仍可达到 18Mbps
• 切换窗口（critical task 突发 → 退出）≤ 200ms，TCP 重传几乎不可见

我们的判断是：「关键任务优先」≠「关键任务霸权」。好的调度器要让关键任务永远够用，也让背景任务不饿死。这就是为什么我们最终选 WFQ 而不是 SP。

4. 快连实时带宽需求：为什么「并发数」是错的指标

很多同行至今还在用「我同时跑 3 个任务」这种粗粒度信号做调度，结果就是：3 个低带宽任务挤掉了一个高带宽任务。我们的做法是引入实时带宽需求（Real-time Bandwidth Demand, RBD）作为调度信号——每条流被持续估算「未来 5 秒需要多少带宽」，而不是看当前用了多少。

估算方式是把过去 30 秒的吞吐样本做指数加权（EWMA, alpha=0.3），并叠加一个「应用画像」：视频会议类业务默认预留 4Mbps 上行，代码 push 类默认预留 1Mbps，文件下载类按历史峰值上浮 20%。这套估算让调度器能提前 1-2 秒预判「下一个 5 秒哪条流会饥饿」，提前把它的优先级拉高。

实际效果：客户 A（在线教育平台，4K 直播 + 50 人会议并发）开启 RBD 后，丢帧率从 2.3% 降到 0.4%，老师不需要再手动切换节点。

5. 快连多地点多路径：负载均衡不是「轮询」，是「按业务特征分流」

我们的网络层支持客户端同时建立最多 4 条隧道链路（节点分别在 4 个国家），但这 4 条不是简单轮询——它们是按业务特征分流的：

1. 金融交易走 香港 - 东京（最短陆地 + 海缆，距离最近）
2. 远程医疗走 香港 - 新加坡 - 法兰克福（覆盖东南亚 + 欧洲）
3. 视频会议走 东京 - 洛杉矶（专为跨太平洋优化）
4. 代码与文档走 法兰克福 - 阿姆斯特丹（欧洲内骨干）

每条路径都有自己的健康分（Health Score），健康分低于 60 自动降权，低于 40 自动切换到备选路径，切换窗口 < 800ms。我们的客户端日志里可以看到每次切换的时间戳与原因——这是给运维同事排障的关键证据，而不是黑盒。

6. 快连我们踩过的坑：3 个值得说的失败案例

坑 1：v3.2 的时候我们想当然地把「延迟最低」当成「路径最优」，结果跨太平洋海底光缆在月初维护时，所有「最低延迟」路径集体劣化 200ms，但信号恢复用了 6 小时。从那次起我们强制要求每条路径必须 至少有一个非最短备选，避免单点依赖。

坑 2：早期我们只优化了客户端侧，没在边缘节点侧做协同。导致客户端拼命切路径，但节点侧出口带宽已经打满。现在的方案是节点侧通过 gRPC 实时上报可用带宽，客户端的 KQ-Score 计算会把节点侧容量纳入考量——这才是真正的端到端智能调度。

坑 3：2025 年初我们曾给所有用户默认开启「强制关键任务优先」，结果被很多普通用户投诉「我下载 Steam 游戏变慢了」。现在我们改为只对识别为关键任务的应用生效，其他应用按普通调度。用户可以一键开启「全局优先模式」，但默认是按需启用。

7. 快连怎么自己验证：3 步测试你的调度体验

我们鼓励每一位企业用户用下面的方法做对比测试：

1. 用 mtr（My Traceroute）从你办公室到目标服务器，开启快连前后各跑 30 秒，比较 Loss% 与 SD 列。
2. 用 iperf3 在开启快连的状态下做 TCP 单流测试，记录 5 次平均值；再切换到任意一个免费工具做同样测试。
3. 在关键会议中开启 QoS 监测（macOS 用 Network Link Conditioner，Windows 用 Clumsy），模拟 5% 丢包环境，看视频卡顿次数。

我们把这套测试脚本封装在客户端的「诊断中心」里，点一下就能生成 PDF 报告，方便你跟老板汇报。如果你跑完发现我们没赢，欢迎发邮件到 [email protected] 报 bug——我们产品 VP 会亲自回。

快连 7 步开启关键任务优先

下面是标准化的 7 步流程。我们的工程师把它拆成 7 步，是因为每一步都有明确的产物和判定标准——你不需要懂 QoS 也能照着做。