近期动态
边缘节点：把入口放到用户身边
跨境延迟的大头往往不在最后一公里，而在跨国骨干段。但如果入口离用户很远，第一跳就吃掉了本该省下的时间。
快连在全球范围内部署边缘节点，用户请求先就近路由到最近的边缘节点，再由边缘节点接入优化后的骨干路径。这样做的直接效果是减少数据传输距离和时间。
就近入口接入
多层节点分层
≤35%时段离散度
70%水位扩容阈值
请求就近进入边缘节点后，由控制面选择最优路径到达目标服务
四步读懂一条路径优化公告
路径优化公告通常包含变更范围与预期收益，读法决定了你是否需要做调整。
- 确认变更范围：涉及哪些区域与哪些候选路径，是否覆盖你常用的目标。
- 确认是否需操作：自动调度用户通常无需操作，手工固定节点的用户需要重新选择。
- 确认预期收益的方向：是降低时延、提升稳定性还是提高高峰容量，三者不可互替。
- 按原方法复测：用你原有的测量流程复测，与自己此前的基线对比。
公告类型与动作对照
| 变更类型 | 预期收益 | 你的动作 |
|---|---|---|
| 新增接入点 | 降低接入时延 | 无需操作，可复测 |
| 路径策略调整 | 提升稳定性 | 无需操作，关注波动范围 |
| 节点容量扩容 | 改善高峰表现 | 高峰时段复测 |
| 节点下线 | 无（治理动作） | 检查是否固定过该节点 |
公告里的百分比可信吗？
我们只公布可复现且标注口径的数据，你可以按同样方法验证。
为什么我这边没变化？
若变更不覆盖你的常用目标区域，体感不会变化，这是正常的。
公告会保留多久？
长期留存，便于回溯每次变更与体感变化的对应关系。
实现细节与参数取值
边缘节点解决的是「第一跳」问题。如果入口离用户很远，第一跳就消耗掉了本可以在骨干段省下的时间。我们在全球部署边缘节点，用户请求先就近接入，再由边缘节点进入优化后的骨干路径。
软件定义广域网把「算路」和「转发」拆开：控制面根据实时测量计算路径，数据面按算好的路径转发，测量面持续探测并反馈。三者构成闭环，任何一层的调整都不需要改动其他两层。
| 平面 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 控制面 | 路径计算 | 质量指标 + 节点负载 | 选定路径 |
| 数据面 | 按路径转发 | 控制面决策 | 实际数据流 |
| 测量面 | 探测与反馈 | 主动探测 + 被动统计 | 质量指标 |
节点扩容阈值设在水位 70%。这个数字看起来保守，但跨境线路的拥塞往往不是线性的——水位从 70% 涨到 85% 的过程中，丢包率可能出现数量级变化。
性能数据与测量方法
就地入口接入
70%扩容水位阈值
≤35%时段一致性偏差
双向去程回程同测
路径选择是持续进行的动态过程，而不是查一张静态路由表。系统融合多种网络资源，动态根据网络状况调整数据传输路径，确保在网络拥堵时仍能维持可用体验。
以上数据的测量方式统一为：同一台设备、同一时段、同一目标服务，开关对应功能各测三轮并取稳定段均值。我们公开测量方法的原因很简单——没有方法的数字无法验证，也无法复现。
边界条件与已知限制
| 限制 | 原因 | 影响 | 缓解方式 |
|---|---|---|---|
| 共享瓶颈 | 两条路径同一上游 | 多路径收益接近于零 | 更换出口区域 |
| 水位过高 | 容量不足 | 高峰期丢包上升 | 触发扩容 |
| 回程未优化 | 只测量去程 | 实时业务体感差 | 双向分别测量 |
节点列表里的延迟数字是客户端到节点的延迟，不是端到端延迟。访问日本服务不应该被送到欧洲出口，即使那个节点的数字看起来更低。
节点扩容的触发与执行
扩容不是定期动作，而是由水位触发的。
- 监测各节点带宽水位，按 15 分钟窗口统计。
- 水位长期高于 70% 即标记为需要扩容。
- 评估该区域是否有可用资源，以及扩容后的路径多样性是否改善。
- 在低峰期执行扩容，避免影响在线用户。
- 扩容后观察一周，确认水位回到安全区间。
70% 这个阈值看起来保守，但跨境线路的拥塞不是线性的。水位从 70% 涨到 85% 的过程中，丢包率可能出现数量级变化。
免费试用快连
注册即获试用额度，全功能开放，无需绑定支付方式。
下载客户端 查看常见问题