有些工具的网络需求，是「极小但极频繁」

写代码时的补全、语音合成的首包、生成任务的进度轮询 —— 像 ChatGPT 这类工具，回答是从第一个字开始一点点推过来的，背后就是这样的请求在跑。这一类请求有个共同点：单次只传几 KB，但一分钟要发几十次。

用带宽去衡量它们毫无意义。几十次几 KB 的请求加起来，一天也跑不满一条普通的线。所以带宽监控上看不出任何异常，而用起来就是不舒服。

真正决定体验的是每一次请求要走多久。这个时间由两段构成：数据在两端之间往返的时延，以及中间每一跳的处理与排队。请求量大的时候，后一段会变得很不稳定。悦播出海在给团队做出口方案时，会把这一段的波动单独拉出来看，而不是只看一个总体数字。

平均值会把问题藏起来

看一条线的质量，最常见的指标是平均时延。但平均这个数字有一个致命缺陷：它把大量很快的样本和少量很慢的样本混在一起，得出来一个看起来正常的数。

举个例子。一百次请求里有九十五次是六十毫秒，五次是八百毫秒。平均下来八十毫秒不到，看起来很漂亮。但对用的人来说，那五次的感受是「忽然卡了一下」，而这五次恰好在关键操作上时，就变成了一次失败。

所以判断这类场景，要看的是分布而不是均值 —— 具体说，看最慢那部分请求落在什么区间。行业里常用的说法是看九十分位、九十九分位，意思就是「最慢的那一成、那一成里的最慢那一成有多慢」。

这件事的实践含义很直接：两条线平均时延一样时，选尾部更短的那条。写代码、听语音、看进度这些场景里，体感差别全在这里。尾部怎么读，见四项关键指标。

丢包比时延更致命，原因在重传

时延多几十毫秒，人几乎察觉不到。丢一个包，代价却是以秒计的：等待重传的计时器、重发的往返、以及对上层窗口的影响，叠起来可能是几百毫秒到几秒的停顿。

更麻烦的是它对小请求的伤害是不成比例的。一个只有几 KB 的请求，如果其中的包丢了，整个请求都要等重传完成才有结果 —— 而它本身只需要几十毫秒就能传完。相当于用几秒钟换取几十毫秒的传输。

所以在这类场景里，第一优先是把丢包压到很低，而不是把平均时延再优化几十毫秒。很多团队花力气换了「更近的线路」，平均时延降了二十毫秒，但丢包没变，体感完全没改善。

并发一上来，抖动会自己放大

同一条线上，请求变多之后，两件事同时发生：每个请求要排队，队列长度会波动。队列一会儿长一会儿短，表现出来就是时延一会儿正常一会儿尖。

这一点常被忽略的原因，是它看起来像「网络时好时坏」。实际上链路本身没变，变的是这条线上有多少人在同时用。

所以「测得好的线用起来不好」经常不是测错了，而是测试时只有一个人在用，实际使用时是十几个人。这个差异必须补上：测试时应该模拟真实并发，或者至少记下测试时的并发情况。

解决办法通常是分开：一组人一条出口，单条上的并发降下来，队列不再剧烈波动。分组比升级带宽便宜，效果也更直接。分组的具体做法见按业务分流。

选线路时该问哪几个问题

第一问：这条线的丢包在什么水平，忙时会不会上升。丢包率是个平均值，忙时与闲时的差别往往比数字本身更重要。

第二问：时延的尾部有多长。不要接受「平均多少毫秒」这一个数字，要问最慢的那部分在什么区间。

第三问：一条出口打算承载多少人。如果对方给不出上限，那多半没有按并发算过。

第四问：出问题时能拿到什么数据。有逐时段的时延与丢包记录，排查才有依据；只有一句「我们线路很稳」，就只能靠猜。

这四个问题都不需要专业背景。问完拿不到答案，本身就是答案。这四个问题在悦播出海的方案里是逐条给的，不必反复追问。

自己怎么测出「抖不抖」

用一个持续的小请求做连续测试：每秒钟发一次小体积请求，连续跑半小时。记录每一次的耗时，然后把最慢的那一部分挑出来看。

如果最慢的一批远高于平均值，说明这条线有尖峰。尖峰出现的时刻与世界其他地方的高峰是否重合，也是一个重要线索 —— 重合说明是路径拥塞，不重合说明是本地这一侧的问题。

再换一个时段重复一次。早晚各测一轮，差别大说明忙时是主要变量；两轮都差不多，说明问题不在本地高峰，而在链路本身。

这类测试不需要任何专门的软件，一个循环发请求的小脚本就够。关键是连续、有记录，而不是偶尔 ping 一下看数字好不好看。

关于悦播出海

悦播出海做的是出海企业的跨境网络：SD-WAN 跨境专线、固定独享出口 IP、全球 200 多个节点，覆盖 TikTok 直播、跨境电商、海外办公与多办公点组网。通道经合规审核，线路与节点资源直采、不转手加价；计费按带宽、线路条数、节点三项算，不按账号数。自有技术团队负责配置与调优，出问题能定位到具体一段。月费订阅、带宽可增减，3 天 24 小时试用，用你自己的业务在真实时段测过再决定。上面这些原理，也是我们给方案做取舍时的依据。