## 概念是什么
链路监测显示两台服务器之间丢包率千分之三，告警群在问严不严重。这个数字的解读依赖两个维度：丢包的形态与业务的敏感度。持续平稳的千分之三与每天集中爆发几次的千分之三，含义完全不同；承载文件下载与承载实时音画面的链路，耐受度也完全不同。
## 背后原理
TCP 自带重传修复，单个丢包只体现为吞吐波动：丢包触发拥塞窗口收缩，速率掉一截再爬回来。千分之三量级的持续丢包对大文件传输的影响可以感知但不致命，用户看下载速度偶尔一顿。真正怕丢包的是实时类流量：交互式会话、语音、游戏状态同步，没有重传机会，丢了就是卡顿与失真。另一个关键形态是突发：平均值千分之三但集中在几秒内爆发，意味着那几秒里成片的包丢失，长连接可能直接超时断开，比平均数字吓人得多。
mtr -rwzbc 1000 192.168.20.10 ping -c 1000 -i 0.1 -q 192.168.20.10
加大样本量才能区分形态：千个包以上的测试看出持续还是突发，mtr 报告顺带定位丢包发生的位置。
## 最小实操
判读三问：丢在中间哪一跳，持续还是突发，业务是否实时类。内网链路的任何可测丢包都不正常，值得追查到底；跨公网链路的千分之三属常见范围，非实时业务可接受，实时业务考虑换线路。决策顺序是先定位段再谈处置，中间节点限速造成的假丢包先排除。
## 常见错误
拿平均丢包率当唯一指标，漏掉突发才是元凶。顺云云服务器间内网互通质量按高标准要求，内网出现持续千分之三的丢包应结合 mtr 报告提交工单排查，公网链路则按业务敏感度分级对待。
最后补一个决策框架：先定性形态，突发型优先处理，持续型看业务敏感度；再定位位置，内网从严公网从宽；然后选择动作，换线路、调参数或接受现状。三步走完，数字变成决策，千分之三不再是一句要不要紧的空谈。