技术条目 05
关键指标
| 指标 | 目标值 | 说明 |
|---|---|---|
| 切换中断时长 | ≤200ms | 低于视频会议卡顿感知阈值 |
| 通道可用性 | 99.95% | 单通道月度目标 |
| 节点质量一致性 | ≤35% 偏差 | 同时段 P95 延迟离散度 |
| 链路预测准确率 | ≥85% | 强化学习模型对劣化路径的预判 |
2协议栈并行
4切换层兜底
<50ms主备通道切换
24 / 7节点健康探测
技术聚焦
四个最常被问到的问题：通道如何冗余、切换有多快、回退怎么兜底、以及这些指标怎么被测量。
技术条目 06
全球接入区域
| 区域 | 覆盖 | 面向场景 | 选型依据 |
|---|---|---|---|
| 亚太 | 日本、新加坡、韩国、中国香港 | 跨境会议、日常办公 | 物理距离近 |
| 北美 | 美西、美东、加拿大 | SaaS 协作、代码托管 | 目标服务聚集 |
| 欧洲 | 德国、荷兰、英国、法国 | 欧洲内业务 | 互联密度高 |
| 东南亚 | 马来西亚、泰国、越南 | 跨境电商 | 本地互联改善 |
| 大洋洲 | 澳大利亚、新西兰 | 南半球协作 | 海缆路径单一，需专线备份 |
选节点的方法：先看目标服务在哪个区域，再选该区域的出口。不要只看客户端列表里的延迟数字——那是到节点的延迟，不是端到端延迟。
技术条目 07
常见问题
切换时会断线吗？
典型中断在 200 毫秒以内，低于视频会议卡顿的感知阈值。UDP 业务使用连接迁移，应用层完全无感。
双协议栈需要手动配置吗？
不需要，客户端默认维护两条路径。状态页可以查看两条通道的实时质量。
为什么我这条线路还是偶尔卡？
先看状态页确认是否发生过切换。若切换频繁，说明当前网络波动较大，可尝试固定到更稳定的出口。
强化学习调度会不会侵犯隐私？
不会。模型只使用链路质量指标（延迟、抖动、丢包、带宽），不涉及用户访问内容。
支持几台设备？
同账号多设备同时在线，各设备通道独立调度。
试用覆盖全部功能吗？
覆盖，含双协议栈与全部节点。
技术条目 08
上手步骤
- 下载并安装按系统选择对应版本。
- 登录账号首次启动加载节点与规则。
- 确认通道状态在状态页查看双通道是否均已就绪。
- 按需配置实时业务选稳定性优先，大文件选吞吐优先。
技术条目 09
切换时序的逐毫秒拆解
「毫秒级切换」是结果指标。实现它需要在时序上做精确安排，也要接受明确的代价。
| 时刻 | 动作 | 耗时 | 说明 |
|---|---|---|---|
| T+0ms | 检测到主通道质量下降 | — | 滚动窗口评分 |
| T+8ms | 评分跌破阈值 | 8ms | 带迟滞，避免抖动误判 |
| T+12ms | 切换决策下达 | 4ms | 控制面决策 |
| T+30ms | 数据面重定向 | 18ms | 新包改走备用通道 |
| T+180ms | 在途包清空 | 150ms | 等待旧通道在途包回程 |
| T+200ms | 切换完成 | 20ms | 状态收敛 |
T+30ms 到 T+180ms 是关键区段。重定向是瞬时的，但旧通道上还有在途数据包，立即丢弃会造成乱序。200 毫秒是权衡结果，不是技术极限。
技术条目 10
平均值陷阱：为什么只看尾部指标
网络质量报告里最常见的是平均值，但平均值恰恰最没有信息量。
假设一次会议平均延迟 80 毫秒，看起来很健康。但如果这 80 毫秒由大部分 40 毫秒和少数 500 毫秒组成，参会者感受到的是持续卡顿——因为人对最差的那几百毫秒极其敏感。
| 指标 | 数值 | 说明 |
|---|---|---|
| 平均值 | 80ms | 掩盖尾部问题 |
| P50 中位数 | 42ms | 一半时间好于此 |
| P95 | 210ms | 5% 时间差于此 |
| P99 | 480ms | 1% 时间差于此 ← 体感来源 |
所以我们的质量报告同时给出平均值与 P95、P99，决策基于尾部指标。
技术条目 11
节点选择的常见误区
| 误区 | 为什么会这样想 | 实际情况 |
|---|---|---|
| 节点越多越好 | 覆盖广等于质量高 | 关键是入口近、出口准、路径可分辨 |
| 延迟数字最低就是最优 | 列表里的数字直观 | 那是到节点的延迟，不是端到端延迟 |
| 固定一个节点最稳 | 避免切换带来的波动 | 区域性故障时无法规避 |
| 出口放在服务所在地最好 | 物理距离最近 | 还要考虑回程质量与互联质量 |
第一条和第二条是最常见的。我们建议先用智能优选跑一轮，看客户端选出的结果，再决定是否固定。
技术条目 12
企业为什么要冗余而不是更高带宽
企业客户最常提的需求是「带宽再大一点」，但实际影响业务的是中断而不是带宽。
- 金融交易：一次超时可能导致订单失败，带宽充足无法弥补。
- 远程医疗：中断意味着会话重建，患者体验直线下降。
- 视频会议：中断会造成参会者掉线，重新加入需要时间。
- 代码提交：中断会让长事务回滚，损失已完成的传输。
这四类场景的共同点是：它们对「不中断」的需求远高于对带宽的需求。这也是我们把资源优先投在冗余与切换上的原因。
技术条目 13
Select a location to find more information
亚太
日本 / 新加坡 / 韩国 / 中国香港
跨境会议、日常办公北美
美西 / 美东 / 加拿大
SaaS 协作、代码托管欧洲
德国 / 荷兰 / 英国 / 法国
欧洲内业务、合规通道东南亚
马来西亚 / 泰国 / 越南
跨境电商大洋洲
澳大利亚 / 新西兰
南半球协作
技术条目 15
相关阅读
新闻动态
版本发布、节点扩容与服务公告都会在此留存记录，便于回溯每个变更点。
- 版本关键指标查看条目详情
- 节点全球接入区域查看条目详情
- 技术常见问题查看条目详情
- 公告上手步骤查看条目详情
- 安全切换时序的逐毫秒拆解查看条目详情
- 版本平均值陷阱：为什么只看尾部指标查看条目详情