📚 课程目录第2章什么是丢包

2. 什么是丢包：定义、表现与业务影响

2.1 丢包的定义

丢包，说白了就是数据包在传输途中“失踪”了。你发出一个包，对端死活没收到。原因可以是链路拥塞、设备故障、队列溢出、路由黑洞，甚至光纤被挖断。协议栈眼里，丢了就重传；但重传本身也是有成本的。

我习惯把丢包分成两类：

硬丢包：物理层问题，比如网线松动、光模块光衰过大。这种丢包往往突发且持续。
软丢包：设备层或协议层问题，比如队列满、CRC校验错、ARP老化。这种丢包可能是间歇性的，甚至在很低的概率下隐藏在流量高峰中。

判断一个包到底算不算“丢”，得看它是否在合理时间内未被确认、未被对端接收。TCP层通过Retransmission判断，UDP层则依赖应用层超时或序列号检测。

关键点：丢包 ≠ 完全不可达。多数丢包是概率性的，比如1%丢包率，意味着100个包里可能丢1个。这个概率一旦超过应用容忍阈值，业务就会出问题。

我个人习惯用ping -f或iperf3 -u -b快速估算基础丢包率，但注意流量双向和对称性——我曾在一个项目中，只测了上行就断定没丢包，结果下行丢包3%，导致VoIP全挂。

2.2 丢包的表现

丢包不是“透明的”，它会在用户侧和网络侧留下痕迹。下面是我常用的观察维度：

层面	表现	常见现象
用户侧	应用层可感知	视频卡顿、语音断断续续、网页加载超时、游戏延迟抖动
网络侧	协议层和传输层	TCP重传、乱序、重复ACK、窗口为零、UDP丢包计数增加
设备侧	设备计数器	错包、CRC错误、丢弃队列满、FCS错误

为什么会这样？我给你掰扯几句：

TCP重传：这是最常见的丢包信号。你抓包看到大量TCP Retransmission，基本等于在告诉你“丢包正在发生”。但我遇到过极端情况，一次是接收窗口太小导致对端超时误判，不一定是真丢包——这个坑我后面会详细讲。
乱序与重复ACK：如果包没丢但延迟太大，TCP会触发快速重传（3个重复ACK）。这其实也是丢包的间接表现，因为包虽然没丢，但顺序乱了，接收端认为中间包丢了。
UDP层面：UDP没有重传机制，丢包就是一条线——应用层计数器看到序列号跳跃，就是证据。

避坑：我曾经在一个数据中心排查“间歇性丢包”，抓包看了半天TCP重传比例只有0.3%，但业务已经崩溃了。后来发现是VoIP流超时敏感度极高，哪怕只有0.1%的突发丢包，也会造成连续几十个包同时丢失（突变大长尾）。所以别光看平均丢包率，要关注丢包分布和最大连续丢包数。

我通常会用tcpdump抓5分钟pcap，然后用tcptrace或wireshark的IO图表看重传时间分布。下面是一个简化的检查脚本片段：

tshark -r capture.pcap -Y "tcp.analysis.retransmission" -T fields \
  -e frame.time_epoch -e ip.src -e ip.dst -e tcp.analysis.retransmission \
  | head -20

嗯，这样你能快速看到重传的源、目的和时间隔离。如果重传高度集中在某个时间段，多半是链路拥塞或设备处理瓶颈。

2.3 丢包对业务的影响

丢包的影响，完全取决于你的业务类型。我把它分成三个梯队：

实时交互类（VoIP、视频会议、云游戏、在线直播）：最敏感。1%丢包率就能让人明显感觉卡顿，3%以上基本不可用。这类业务通常使用UDP，丢包意味着信息直接丢失。
受控流类（TCP长连接、数据库同步、文件传输）：TCP的拥塞控制会通过重传和窗口缩减来补偿丢包，代价是吞吐量下降。丢包率每增加1%，有效带宽可能下降10%甚至更多（具体取决于RTT）。
批量/非实时类（日志上传、夜间备份）：对丢包容忍度高，只要不导致连接中断，重传就能搞定。但要注意大流量长RTT场景下，丢包可能导致重传风暴。

用一个实际案例让你感受一下。我之前帮一个游戏公司排查延迟抖动，他们用的是UDP+custom ACK，丢包率不到0.5%，但玩家投诉“闪回”和“掉线”。我进服务器抓包发现：丢包虽然少，但突发性极强——某10秒窗口内丢包率高达8%，然后迅速恢复。这就是典型的交换机队列瞬间打满（microburst），在平均统计下完全看不出来。

下面这张表格总结了常见应用对丢包的容忍度：

业务类型	典型协议	容忍丢包率	主要影响
VoIP（语音）	RTP/UDP	<1%	断续、杂音、丢字
视频会议	RTP/UDP	<0.5%	花屏、卡顿、不同步
云游戏	UDP + FEC	<0.1%	操作延迟、画面撕裂
Web 浏览	HTTP/TCP	2%~5%	页面加载慢、超时重试
文件传输	FTP/SCP/TCP	5%以下	吞吐剧烈下降

经验之谈：很多人只盯着平均丢包率。但你想想看，业务感知是瞬时的。如果你的丢包是均匀间隔的（比如每10秒掉1包），影响很小；但如果是突发的（比如1秒内掉20包），即使平均丢包率只有0.1%，也能让实时应用直接崩。所以排查时一定要看丢包的时间分布——我会用tshark -z io,stat,1按1秒粒度输出重传次数分布，一眼就能看出是否集中爆发。

最后，我画了张图把定义、表现和影响串起来。你看左边是丢包的两种类型（硬/软），中间是三种观察层面（用户/网络/设备），右边是三个敏感度等级的业务。箭头表示因果关系——丢包通过不同表现传导至不同业务，最终影响各不相同。

这张图也是我平时做快速回顾用的。遇到丢包问题，先看它的定义（是软还是硬），再对照表现层定位，最后评估业务受影响的程度。下一章我会讲怎么用工具定量测量丢包——从最基础的ping到专业的抓包分析。

这张图也是我平时做快速回顾用的。遇到丢包问题，先看它的定义（是软还是硬），再对照表现层定位，最后评估业务受影响的程度。心里有了这个框架，排查才不会乱。