01 / BEFORE YOU BUY

选型前的 6 个问题

不需要先记住各种产品缩写。先回答业务与体验层面的问题，技术方案会自然收敛。

01
要传的是内容，还是实时状态？可缓存内容优先考虑 CDN；实时操作优先关注路径与抖动。
02
瓶颈在本地、公网还是服务器？本地无线、终端性能和源站处理，不能全部交给加速网络。
03
用户与服务器主要分布在哪里？跨区越多，入口位置与骨干覆盖越值得评估。
04
最在意平均延迟，还是波动？实时交互通常更看重稳定分布和故障切换。
05
能否做同条件 A/B 测试？不能测量，就只能为不确定的改善付费。
06
是否符合业务与游戏规则？安全、数据合规与服务条款应先于技术收益。
02 / A FAIR TEST

一套简单、可重复的测试流程

  1. 确定一个明确问题

    例如“同一区服晚高峰下，加速路径是否能把 95 分位 RTT 或抖动降低 20%？”

  2. 固定所有可控变量

    相同设备、网络、服务器、场景和测试时段。有线与无线不要混在一起比较。

  3. 采集足够长时间

    至少覆盖普通时段与高峰时段，并记录平均值、最高值、分位数与丢包。

  4. 交替进行 A/B

    直连、加速、直连、加速多轮交叉，减少服务器状态变化造成的偏差。

  5. 同时观察体感

    统计回拉次数、技能延迟、语音断续等主观事件，避免只看一个漂亮数值。

  6. 形成退出条件

    预先定义何时判定无效：例如收益不稳定、故障增多或成本超过业务承受范围。

什么是“95 分位”RTT？

把延迟样本从小到大排列后，95% 的样本低于这个值。它比平均值更容易暴露偶发高延迟，适合观察实时体验中的“坏时刻”。

03 / SCORECARD

把“值不值”拆成五项

01

效果

平均 RTT、抖动、丢包与主观卡顿是否在相同条件下改善？改善覆盖多少时间与地区？

02

稳定性

节点故障时是否能切换？高峰时段是否仍然可用？一次失效会持续多久？

03

覆盖范围

目标地区、目标运营商和目标游戏或业务是否真的有节点与合适出口？

04

可观测性

能否看到节点、延迟、丢包、切换记录与故障说明？出了问题时能否定位？

05

总成本

价格之外，还要计入部署、配置、排障、迁移与用户支持成本。

06

合规与信任

数据流向、隐私策略、服务条款与安全边界是否清晰，是否与使用场景相符？

04 / FAQ

常见问题

不能。改善取决于原路径有多绕、加速网络覆盖是否合适、服务器与本地网络状态。距离过远、服务器本身拥塞或本地终端性能不足时，结果可能很小。

05 / SOURCES & NOTES

参考资料

本站内容以概念科普和原创改写为主，重点综合以下三篇公开资料，并补充了通俗化的指标解释与测试方法。产品实现会随架构变化，具体能力应以服务商当前文档为准。

阅读提示

参考文章中的部分内容来自云服务厂商产品说明或二次转载。本站保留通用原理，不把厂商示例当成所有加速器的统一实现；Anycast、专线和代理层级都可能因产品而异。