服务器自身性能瓶颈、网络链路质量问题、以及外部攻击或策略限制，排查时应按“从内到外”的顺序逐一排除。
很多站长半夜爬起来处理故障,第一反应就是ping一下服务器，丢包数据一出来，脑子就嗡嗡的，别急，丢包不是玄学，它背后必定有迹可循，这篇文章不聊虚的，直接带你按顺序拆解服务器丢包有哪些原因，顺便把对应的排查路子走一遍。
丢包问题的第一站：先看服务器自己扛不扛得住
业内专家指出,相当一部分丢包问题，根源其实出在服务器本机，而不是网络，这是最容易忽略、也最容易被冤枉的一个环节。
CPU过载导致软中断丢包
服务器处理网卡收到的数据包,靠的是CPU中断，网卡每收到一个包，就会触发一次中断请求，CPU停下来处理完再去干别的活，如果流量极大，比如遭遇突发流量或者业务高峰，CPU软中断占用会飙升。
进程里有个名字叫ksoftirqd的线程，专门干这个，你用top看一眼，如果这个家伙占了很高的百分比，说明CPU已经忙不过来了，这时候数据包会积压在网卡环形缓冲区里，缓冲区满了，后面的包直接丢弃。
网卡环形队列被塞满
这个可以理解成网卡的停车场,网卡接收数据先停进一个队列缓冲区，再由CPU拉走，如果你的网卡队列长度设置太小，或者中断处理速度跟不上，队列一满新包就被丢掉。
验证方法：确认网卡型号ethtool -i eth0，然后查看丢包统计ethtool -S eth0 | grep -i drop，能看到rx_dropped这类计数在疯狂增长，解决路径一般是调大队列长度或开启多队列网卡特性（RSS）。
防火墙规则和连接追踪表爆炸
iptables/nftables是服务器最后一道防线，但有时候它会误伤，如果规则里有DROP策略，而且命中率很高，那丢包就是设计如此。
Linux的conntrack连接追踪模块有个上限,默认值通常在几十万，如果你的服务器TCP短连接非常多，conntrack满了之后，新连接的数据包直接无法处理，表现为丢包加重，看这块用dmesg | grep nf_conntrack，如果刷屏全是“table full, dropping packet”，问题就定位了。
网络链路：丢包大户都在这一段
排除完本机自身的毛病,接下来就要面对最复杂的链路问题，这里也和长尾词“服务器丢包和延迟高有什么区别”有很强关联延迟高是路远，丢包是路断或者路堵。
机房上行/下行带宽被打满
行业共识认为,带宽耗尽导致的丢包，是最常见、也最冤枉的丢包原因，你服务器买了10M独享，结果某天一个备份任务把流量占满，此时所有业务客户端都会看到丢包，但服务器本机和交换机端口可能显示一切正常。
注意一个坑：IDC后台看到的出方向流量，和你服务器网卡上的eth0出方向流量，如果不一致，通常是带宽限速策略在丢包，让机房查一下你的端口discards计数即可验证。
物理链路故障与设备脏污
这个属于低频高破坏型问题,一根光纤弯折半径过大，或者光模块积灰、激光器老化，都会造成光衰过大，光衰到一定程度，信号误码率飙升，网络表现出忽好忽坏，丢包呈现间歇性特征。
用mtr或者traceroute去打一个稳定IP，你会发现丢包集中在某一个中间节点，或者干脆从自己的网关就开始丢，操作路径是让机房看链路光功率（注意接收光功率，不是发光），参数低于-25dBm时问题通常就出在这里。
运营商互联互通不让步
国内跨运营商访问,比如电信访问联通服务器、或者用户在移动网络下访问电信机房，多走一段复杂的互联链路，高峰期运营商间存在过度拥塞是公开的秘密，这种丢包通常表现为：白天好、晚高峰20点-23点开始波动，非高峰恢复。
这种问题你只能换BGP机房或者上CDN,通过技术手段在本地反复调整几乎毫无办法，国内某热门省份的跨网ping数据，丢包率长期在5%-15%之间波动，这就是典型的运营商互联质量问题。
公共层面：攻击、穿透和未知流量
如果服务器是暴露在公网上的,被扫描、被攻击几乎是常态，这类丢包特征非常明显，一看就知道不是误伤。
DDoS攻击与流量穿透
流量型的DDoS是直接把带宽打满,发生最高频的其实就是UDP反射放大攻击，当你发现带宽莫名其妙被突到极高水位，并且防火墙状态表里全是半连接时，攻击已经在发生了。
清零的路径：接高防IP，或者让机房封端口、黑洞清洗。不要在攻击期间手忙脚乱地重启防火墙或者加规则，意义不大，重点是把攻击流量引走。
策略误杀与IP封禁
不少管理员自己写的iptables规则,或者云平台的安全组，规则顺序错了就会把正常IP挡在外面，比如一条禁ping的规则写在了允许的前面，ICMP请求就没了响应，表现为ping丢包，但TCP业务完全正常，如果遇到“服务器丢包严重怎么排查”这类需求，先用
iptables -L -n -v看清楚每一条规则的计数。
深入排查：解决问题的可复制操作路径
下面这套顺序,是处理服务器ping不通但业务没挂这类问题时的标准操作顺序，可以直接照着敲。
第一步，跑一个基础链路测试，目标是隔离出故障段：
- 本机ping自身内网IP,丢包说明服务器网卡或驱动故障
- 服务器ping网关,丢包说明局域网内物理链路或交换机端口故障
- 本地电脑ping服务器公网IP,丢包说明跨互联网链路有问题
第二步，用MTR看一下具体路径。
Linux里输入mtr -n --report x.x.x.x，Windows用winmtr，重点看最后一跳之前的中间节点丢包率。
多个中间节点同时丢包,且末段也丢包，是后端路由器或机房链路压力过大；只有某一两个中间节点丢包，后面恢复，那通常只是中间路由器的ICMP限速策略，并非真丢包，这里有个老生常谈的坑：很多路由器的ICMP响应有优先级限制，mtr里显示的丢包是假的，判断真丢包的依据是看最终目标节点的丢包率。
第三步，抓包看重传情况。
用tcpdump -i eth0 host 目标IP抓包，如果TCP窗口快速收缩、大量Dup ACK出现，说明双向链路存在真实的包丢失，这比ping结果更准确，因为TCP更敏感，它是靠回复确认判定丢包的。
第四步，检查网卡中断均衡，多核CPU服务器上，网卡中断如果全落到一个核，那个核一打满其他核闲着，同样丢包，绑定一下中断到多个CPU核心，用/proc/irq/下的smp_affinity设置即可。
| 排查方向 | 关键工具 | 核心判定指标 |
|---|---|---|
| 服务器CPU过载 | top/htop | ksoftirqd占比高 |
| 网卡缓冲不足 | ethtool -S | rx_dropped持续增高 |
| 连接追踪满 | dmesg | nf_conntrack table full |
| 链路光衰 | 看网管系统 | 收光功率低于阈值 |
| 运营商互联拥塞 | mtr | 固定时间点特定节点丢包 |
按场景拆解：服务器丢包和延迟高有什么区别
很多新手把延迟和丢包混为一谈,这是两个完全不同的概念，延迟高说明数据包往返时间长，但每一帧数据都完好无损地到达了；丢包则是有去无回，数据根本没到或没回来，玩游戏的玩家经常遇到“延迟良好但瞬移”的情况，这就是轻微的丢包而不是延迟高。
游戏服务器丢包原因其实和普通Web服务器差不多,区别在于游戏场景下UDP流量占比高，而UDP没有重传机制，丢一个包就是一次肉眼可见的卡顿瞬移，行业内部有个普遍经验：游戏服务器如果出现周期性丢包，优先考虑的问题是包量太大导致CPU软中断过载，其次再看跨网链路。
常规Web服务器遇到丢包,页面会加载变慢、图片反复刷新，症状不如游戏明显，容易被误认为是“服务器配置不够”。
如何从源头设计上规避丢包
与其整天排查,不如在架构阶段就做几件抗丢包的事。
- 网络架构层面,高可用业务务必用BGP多线机房，避免单线运营商晚高峰拥塞
- 服务器调优层面,把内核参数
net.core.rmem_max调大、开启tcp_tw_reuse，可以缓解部分连接堆积问题 - 防御层面,购买基础防护之外的DDoS高防包，别等到被打才临时抱佛脚
另一个办法是把业务放在内网,对外只暴露入口，服务器内网通信一般不会丢包，出问题也只会出在机房到用户的最后一段，排查范围一下子缩小了很多。
丢包本身不致命，致命的是不懂排查顺序
服务器丢包的原因,绝大多数逃不出本机性能过载、物理链路劣化、运营商拥塞和攻击封禁这四类，先查本机再查链路，先看数据再看规则，就能避免被表象带偏，只要方向对了，丢包问题通常半天之内就能查出端倪。
常见问题速答
服务器ping不稳定怎么解决？
先观察丢包是否带规律性,如果只在特定时段丢，多半是运营商晚高峰拥塞；如果全天候随机丢，检查本机连接追踪表和网卡丢包计数，用ping -f模式满包测试网关，丢包为零说明本机出口正常，问题一定出在中间链路。
ping通但服务器丢包严重怎么排查？
直接用mtr同时盯丢包率和TCP建连情况，TCP业务正常但ping丢包，优先怀疑中间设备的ICMP限速策略，反过来ping正常但TCP频繁断流，则重点查防火墙规则和并发连接数限制。
游戏服务器丢包原因和普通网站不一样吗？
机制完全一样,区别只是在流量模型上，游戏使用UDP长连接、小包高频发包，服务器只要软中断处理不过来，立刻表现成玩家瞬移，网站是TCP短连接为主，内核TCP栈的容错能力掩盖了部分丢包，看起来没有那么明显而已。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8%e4%b8%a2%e5%8c%85%e5%8f%af%e8%83%bd%e6%9c%89%e5%93%aa%e4%ba%9b%e5%8e%9f%e5%9b%a0%ef%bc%8c%e5%a6%82%e4%bd%95%e6%8e%92%e6%9f%a5%e8%a7%a3%e5%86%b3%ef%bc%9f/
