丢包是什么意思？丢包率怎么算、怎么测与常见原因

丢包是什么意思？数据在网络上被切成一个个“包”来传输，一个包从发送端出发，要经过网卡、交换机、路由器，最后到达接收端；途中任何一处把它丢弃或损坏，接收端就收不到它，这就是丢包，英文是 packet loss。丢包率是丢失的包占发出总数的百分比，英文是 packet loss rate，计算公式是：丢包率 =（发送数 − 接收数）÷ 发送数 × 100%。网络设备本来就不保证每个包都送达：队列满了要丢，校验出错要丢，超过限速要丢，被安全策略拦下也要丢。少量丢包由 TCP 重传补回来，代价是变慢；丢包多了，网页加载卡顿、下载速度上不去、游戏和语音断断续续。

丢包率怎么算：公式和三种统计口径

公式本身很简单。用 ping 向一台服务器发 500 个包，收到 493 个回复：

丢包率 = (500 − 493) ÷ 500 × 100% = 1.4%

麻烦在于，“丢包率”在不同地方统计的东西并不一样。运维排障时常见三种口径：

口径	在哪里看	怎么算	说明什么
ping、mtr 的丢包率	发起测试的客户端	（发送 − 收到回复）÷ 发送	端到端的一来一回是否完整，去程、回程任一方向丢了都算丢
接口丢弃率	服务器网卡、交换机端口	丢弃包数 ÷ 收（或发）总包数	这一台设备、这一个端口自己有没有丢
TCP 重传率	服务器	重传段数 ÷ 发送段数	业务连接实际遇到的丢包，最接近用户的感受

接口口径在 Linux 上这样看：

ip -s link show eth0

    RX:  bytes  packets errors dropped  missed   mcast
    9876543210 12500000      0    2500       0     120
    TX:  bytes  packets errors dropped carrier collsns
    8765432100 11000000      0       0       0       0

接收方向丢弃了 2,500 个包，接收丢弃率 = 2,500 ÷ 12,500,000 = 0.02%。这些计数从开机（或驱动加载）起累计，要隔一段时间看两次，用差值算才是当前的情况。各版本 iproute2 的列名略有不同，含义一致。

TCP 重传率用内核计数器算：

nstat -az TcpOutSegs TcpRetransSegs
# TcpOutSegs       2000000
# TcpRetransSegs   6000

重传率 = 6,000 ÷ 2,000,000 = 0.3%。同样是累计值，按两次采样的差值计算更准确。

三个数字不能直接互相比较：ping 的丢包包含两个方向、只代表 ICMP；接口计数只代表这一台设备；TCP 重传里还包含超时误判造成的“多余重传”。判断丢没丢、丢在哪，通常要把它们放在一起看。

丢包的英文和相关术语对照

查资料、看设备输出时，下面这些词指的都是丢包或与它相关的现象：

中文	英文	常出现在
丢包	packet loss	通用说法
丢包率	packet loss rate、loss rate；ping 统计里写作 % packet loss 或 % loss	ping、监控系统、SLA 条款
请求超时	Request timed out	Windows ping 中某个包没收到回复
丢失	Lost	Windows ping 的统计行
丢弃	drop、discard	网卡、交换机计数，多为队列满或策略主动丢弃
错误包	error、CRC error、FCS error	帧校验失败，多为网线、光模块等物理层问题
重传	retransmission	TCP 发现丢包后重新发送
往返时延	latency、RTT	ping 每一行的 time=
抖动	jitter	延迟的波动，mtr 的 StDev 列可以近似反映

用 ping 看丢包：Windows 和 Linux 的输出怎么读

Windows 默认只发 4 个包，用 -n 指定数量；Linux 默认一直发，用 -c 指定数量：

ping -n 100 203.0.113.10

请求超时。
来自 203.0.113.10 的回复: 字节=32 时间=36ms TTL=52

203.0.113.10 的 Ping 统计信息:
    数据包: 已发送 = 100，已接收 = 96，丢失 = 4 (4% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 33ms，最长 = 118ms，平均 = 37ms

ping -c 100 203.0.113.10

--- 203.0.113.10 ping statistics ---
100 packets transmitted, 96 received, 4% packet loss, time 99153ms
rtt min/avg/max/mdev = 33.118/37.402/118.247/9.611 ms

读结果时注意五点：

1. 看超时的分布，不只看总数。连续十几个“请求超时”后恢复，是一次短暂中断，常见于链路切换、路由收敛、端口闪断；零星分散的超时，是持续性的小比例丢包，常见于拥塞或误码。两种情况的丢包率可能一样，原因完全不同。
2. 样本量决定精度。100 个包丢 1 个就是 1%，这个测试分辨不出 0.1% 级别的丢包；要看千分之几的丢包，至少发上千个包，并且在出问题的时段测。
3. Windows 会把“无法访问目标主机”算作已接收。本机（同网段内 ARP 解析不到目标时）或沿途的路由器返回“目标不可达”，Windows 也把这次回复计入已接收：

来自 192.168.1.1 的回复: 无法访问目标主机。
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，

统计显示 0% 丢失，实际上一个包都没到达目标。所以要看回复来自哪个地址，回复地址不是目标 IP，就不算通。

4. ping 分不出丢在哪个方向。请求在去程丢了，和回复在回程丢了，结果一样都是“超时”。要区分方向，需要在两端分别测，或者用 iperf3 这类工具在一端发、另一端统计。
5. 换大包再测一次。默认的 32 字节（Windows）或 56 字节（Linux）小包正常，不代表大包也正常。Windows 用 ping -n 100 -l 1400 203.0.113.10，Linux 用 ping -c 100 -s 1400 203.0.113.10。大包丢得明显更多，要怀疑 MTU 不匹配，或者链路有误码，因为包越长，碰上比特错误的概率越高。

用 mtr 看丢包丢在哪一段

ping 只给出终点的结果，mtr 对路径上每一跳持续探测，每一跳的 Loss% 就是“这一跳没有回应的探测包比例”。下面这份报告的特点是只有最后一跳丢包：

mtr -rwn -c 200 203.0.113.10

HOST: office-gw               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.10.1           0.0%   200    0.6   0.7   0.4   2.1   0.2
  2.|-- 100.64.12.1            0.0%   200    3.2   3.5   2.8   9.7   0.8
  3.|-- 198.51.100.33          0.0%   200    5.9   6.3   5.1  14.2   1.3
  4.|-- 198.51.100.90          0.0%   200   28.4  28.9  27.6  35.0   1.1
  5.|-- 203.0.113.1            0.0%   200   30.1  30.6  29.8  38.3   1.2
  6.|-- 203.0.113.10           6.5%   200   31.0  31.4  30.2  40.1   1.4

到第 5 跳（机房网关）为止都不丢，只有服务器本身丢了 6.5%。问题范围被缩小到最后一段：服务器网卡、服务器所接的交换机端口和网线，或者服务器自己对 ICMP 做了限速。再用 TCP 方式（mtr -T -P 端口）复测一次：TCP 也丢，就查网卡和端口；TCP 不丢，多半是服务器对 ICMP 做了限速，对 TCP 业务没有影响。

不同的丢包形态，对应不同的含义：

丢包形态	含义
中间某一跳丢，后面各跳恢复为 0	那台路由器对发给它自己的探测包限速，不是业务丢包
从某一跳开始，后面每一跳都丢	真丢包，问题在这一跳或它前面那段链路
只有最后一跳丢	目标本身或它的接入端口，或者目标对 ICMP 限速
丢包出现的同时，延迟从某一跳起整体抬高	拥塞的典型表现：队列先变长、延迟升高，队列满了才开始丢包

还要记住 mtr 只能测出去的路径。回程可能走另一条线路，去程看不出问题时，要从服务器向你这一端再测一次。

丢包的常见原因

原因	典型特征	怎么确认
线路或出口拥塞	晚高峰出现、凌晨消失，丢包时延迟同步抬高	链路利用率曲线是否贴顶；mtr 中丢包从拥塞段开始一直延续到终点
端口或套餐限速	流量低时不丢，超过某个速率就丢；下载速度贴着一个固定值	交换机端口限速配置、服务商的带宽套餐
网线、光模块故障或光衰	全天按大致固定的比例丢，和流量大小关系不大；大包更明显	交换机端口的 CRC、错误计数持续增长；光模块收光功率低于厂商规定的下限
速率或双工协商异常	一端全双工、一端半双工，流量一大就丢	ethtool eth0 看 Speed 与 Duplex，与交换机端口状态对照
设备 CPU 过高	ping 设备本身丢包；纯硬件转发的设备转发通常不受影响，软路由、软件防火墙 CPU 打满时转发也会丢	对比 ping 设备本身和 ping 设备后面的主机；查看设备 CPU 利用率
ICMP 限速被误判	只有 ping、mtr 显示丢包，TCP 业务正常	用 TCP 方式复测，或看业务的 TCP 重传率
服务器来不及接收	流量大时服务器网卡的丢弃计数增长，交换机端口不丢	ip -s link、ethtool -S eth0 中的 drop、miss、fifo 类计数；dmesg 中是否有 nf_conntrack: table full, dropping packet
遭受攻击或被清洗	突发，伴随入方向流量暴涨	流量图、服务商的攻击和清洗记录
MTU 不匹配	小包正常，大包丢；网页能打开，大文件下载或 HTTPS 握手卡住	Linux 用 ping -M do -s 1472 目标，Windows 用 ping -f -l 1472 目标，逐步减小包长找出能通过的上限

拥塞和限速是“设备主动丢”，物理层故障是“包坏了被丢”，ICMP 限速则是“看起来丢了、其实没丢”。先分清是哪一类，再去找对应的设备。

丢包和延迟有什么区别

对比项	丢包	延迟
定义	包没有到达	包到达了，花了多长时间
单位	百分比	毫秒（ms）
主要成因	拥塞、限速、物理故障、策略丢弃	物理距离、路由绕行、排队
怎么看	ping 统计行、mtr 的 Loss%、接口计数、TCP 重传率	ping 的 time=、mtr 的 Avg 与 StDev
用户的感受	时好时坏、断续、偶尔卡住几秒、下载速度上不去	每次操作都慢半拍，但稳定

两者又是连在一起的。对 TCP 业务来说，丢包最终会以“延迟”的形式出现，因为丢掉的数据要等发现之后重发：

• 收到连续 3 个重复确认触发快速重传，大约多花一个往返时间；
• 等不到确认只能靠超时重传，Linux 上重传超时最短也是 200 毫秒；
• 建立连接的 SYN 包丢了，按 RFC 6298 的建议要等 1 秒才重发，用户看到的是“偶尔点一下要卡一秒”；
• DNS 查询走 UDP，查询包丢了，Linux 上 glibc 解析器默认（/etc/resolv.conf 的 timeout）要等 5 秒才重试，表现为“偶尔打开网页要等好几秒”。

所以看到偶发的 1 秒、5 秒停顿，先查丢包，而不是延迟。

丢包还会直接压低单个 TCP 连接的速度，因为 Reno、CUBIC 这类基于丢包的拥塞控制把丢包当成拥塞信号而降速。按常用的 Mathis 公式估算（吞吐上限 ≈ MSS ÷ RTT × 1.22 ÷ √丢包率），在 50 ms 往返时延、MSS 1,460 字节的链路上，丢包率 0.01% 时单连接上限约 28.5 Mbps，0.1% 时约 9 Mbps，1% 时只剩约 2.85 Mbps。丢包率从 0.01% 升到 1%，单连接的速度上限降到原来的十分之一，所以 1% 的丢包损失的远不止 1% 的速度。

UDP 业务没有重传。语音、视频会议、实时游戏丢一个包就少一帧画面或一段声音，程序只能靠插值、补偿来掩盖，丢包多了就会出现卡顿、画面跳跃、人物瞬移。

在管理系统里怎么落地

在 IDC 机房里，丢包最常见的两个源头是端口或出口拥塞，以及接入链路的物理故障。拥塞常由个别服务器引起：某台机器被攻击或滥用，把同一上联的其他客户挤到丢包。带宽自动限速 在它最近几分钟的平均带宽超过阈值时，自动把它的交换机端口限到设定速率，流量回落并持续稳定后再恢复原速率；按平均值判断，偶发的尖峰不会误触发。物理故障要从端口入手：Toplink DCIM 的服务器列表里能直接看到每台机器接在哪台交换机的哪个端口，在 交换机管理 里打开浏览器终端，执行 display interface 或 show interface 查看 CRC 和错误计数是否在增长，整个排障会话会被录像并记录命令日志，事后可以回看当时看到的计数。