Linux服务器网络丢包场景及解决办法

一、Linux网络丢包概述

在数字化浪潮席卷的当下，网络已然成为我们生活、工作与娱乐不可或缺的基础设施，如同空气般，无孔不入地渗透到各个角落。对于 Linux 系统的用户而言，网络丢包问题却宛如挥之不去的 “噩梦”，频繁干扰系统的稳定运行。

设想一下，当你满心期待地加载网页时，进度条却如蜗牛爬行般迟缓，图片久久无法显示，文字也变得断断续续；或是在传输重要数据的关键时刻，文件传输突然中断，进度瞬间归零，一切都需重新开始。这些令人崩溃的场景，背后往往是网络丢包在作祟。

网络丢包所带来的影响不容小觑，它不仅会造成网络延迟急剧上升，使实时通信变得卡顿不堪，还可能严重降低数据传输的准确性，引发各类错误，极大地影响用户体验与工作效率。尤其在企业级应用中，诸如线上交易、视频会议、云计算等场景，丢包问题甚至可能直接导致经济损失。

因此，深入了解 Linux 内核中常见的网络丢包场景，就如同为网络进行精准 “把脉问诊”。只有明确病因，才能 “对症下药”，确保网络恢复畅通，重新为用户提供高效、稳定的服务。

 linux 系统接收网络报文的过程

在 Linux 系统的网络数据传输过程中，网络报文的旅程始于物理网线。当数据在网络中传输时，首先通过物理网线将网络报文发送到网卡。网卡作为连接计算机与网络的硬件设备，起到了数据接收与发送的关键作用。

接下来，网络驱动程序发挥重要功能。它会把网络中的报文从网卡读出来，并放置到 ring buffer（环形缓冲区）中。这一过程采用了 DMA（Direct Memory Access，直接内存访问）技术。DMA 的优势在于它能够在不占用 CPU 资源的情况下，实现外部设备与内存之间的数据直接传输。这使得 CPU 无需参与数据搬运工作，可以继续执行其他重要任务，从而大大提高了系统的整体性能和效率。

随后，内核开始介入。内核会从 ring buffer 中读取报文，进而进行一系列复杂的处理。在此过程中，内核需要执行 IP 和 TCP/UDP 层的逻辑。IP 层负责处理网络层的地址解析、路由选择等功能，确保报文能够准确无误地在网络中传输到目标地址。而 TCP/UDP 层则负责处理传输层的任务，如建立连接、数据分段与重组、流量控制、差错校验等。完成这些处理后，内核将报文放置到应用程序的 socket buffer（套接字缓冲区）中。

最后，应用程序从 socket buffer 中读取报文，进行最终的处理。应用程序根据自身的业务逻辑，对接收到的报文进行解析、执行相应的操作，从而实现用户所需的功能，比如显示网页内容、处理文件传输等。

在这一整个过程中，任何一个环节出现问题，都有可能导致网络丢包现象的发生，进而影响网络的正常运行和用户体验。深入了解这一过程，有助于我们在面对网络丢包问题时，能够更准确地定位问题所在，采取有效的解决措施。

二、Linux内核收发包的逻辑流程

收包流程：数据包的进入服务器。

当网卡感知到报文的抵达瞬间，标志着数据包在 Linux 系统中的复杂接收进程正式启动。最初阶段，网卡凭借 DMA（Direct Memory Access）技术，以极低的 CPU 开销和极高的数据传输速率，将接收到的数据包高效拷贝至 RingBuf（环形缓冲区）。此缓冲区作为数据暂存区域，为后续系统处理提供了缓冲空间，其作用类似物流运输中的临时仓储环节，有效协调了不同处理阶段的速率差异。

紧接着，网卡通过向 CPU 发送硬中断信号，及时告知 CPU 有新数据到达。该硬中断信号如同计算机系统内部的紧急事件通知机制，促使 CPU 立即暂停当前正在执行的非关键任务，转而执行与网卡硬中断相对应的处理例程。在这个例程中，CPU 将数据包的关键元数据，如源地址、目的地址、数据长度等信息，准确无误地存入每 CPU 变量 poll_list 中。这一操作旨在为后续的网络包处理流程提供必要的数据索引和准备工作。完成此步骤后，CPU 随即触发一个收包软中断，将网络包的后续处理任务，尤其是那些对实时性要求相对较低但需要精细处理的部分，转交给软中断机制处理。

随后，与触发软中断的 CPU 核对应的软中断线程 ksoftirqd 开始执行其既定任务。该线程主要负责处理网络包接收软中断，具体通过执行 net_rx_action () 函数实现。在 net_rx_action () 函数的严格调度下，数据包从 RingBuf 中按顺序被提取出来，随后进入网络协议栈的处理流程。

数据包首先进入链路层进行处理。在此层级，系统会严格依据链路层协议规范，对报文进行完整性和合法性校验，同时剥离链路层的帧头和帧尾信息，这些信息主要用于数据在链路层的传输控制，如 MAC 地址寻址、数据校验等。经过链路层的处理后，数据包进入网络层。在网络层，系统依据 IP 协议对数据包的目的 IP 地址进行解析和路由判断，确定数据包的最终传输方向。若判断数据包的目标地址为本机 IP 地址，则将数据包继续传递至传输层。

在传输层，系统依据 TCP 或 UDP 协议对数据包进行进一步处理，如 TCP 协议中的连接管理、流量控制、数据校验等操作。经过传输层的处理后，数据包被准确无误地放置到 socket 的接收队列中。至此，数据包完成了从网卡接收、经内核协议栈处理，到最终进入应用层接收队列的完整流程，等待应用程序按照自身的逻辑和需求进行后续处理。

发包流程：数据包的发出服务器。

当应用程序准备发送数据时，数据包的 “出境之旅” 随即开启。最初，应用程序通过调用 Socket API，如 sendmsg 函数，来发起网络包的发送请求。这一调用触发系统陷入内核态，实现数据从用户空间到内核空间的高效拷贝。在此过程中，内核会为数据包分配一个 skb（sk_buff 结构体），该结构体作为数据包在内核中的 “载体”，负责承载诸如源地址、目的地址、协议类型等关键信息。

随后，承载数据的 skb 进入网络协议栈，开启自上而下的处理流程。在传输层，根据应用需求和协议选择，为数据添加 TCP 头或 UDP 头。这一过程涉及到复杂的传输控制机制，如 TCP 协议中的拥塞控制、滑动窗口管理等，旨在确保数据在网络中的可靠传输和高效利用网络带宽。

当数据包进入网络层，系统会依据目标 IP 地址，在路由表中进行精确查找，以确定数据包的下一跳转发路径。同时，系统会填充 IP 头中的关键信息，包括源 IP 地址、目标 IP 地址以及生存时间（TTL）等。若数据包大小超过网络链路的最大传输单元（MTU），则会对 skb 进行切分操作，以确保数据包能够顺利通过网络。此外，数据包还需经过 netfilter 框架的严格 “安检”，即依据预先设定的过滤规则，判断数据包是否符合网络安全策略和访问控制要求。

经过网络层的处理后，数据包进入邻居子系统。在该子系统中，通过地址解析协议（ARP）或其他相关机制，将目标 IP 地址解析为对应的目标 MAC 地址，并填充到数据包中。此后，数据包进入网络设备子系统，skb 被放置到发送队列 RingBuf 中，等待网卡进行发送。

当网卡成功发送数据包后，会向 CPU 发送一个硬中断信号，以通知 CPU “发送任务已完成”。该硬中断进一步触发软中断，在软中断处理函数中，系统会对 RingBuf 进行清理操作，移除已成功发送的数据包的残留信息，为后续的数据包发送做好准备。至此，数据包顺利完成了从应用程序发起请求到网卡发送的整个发包流程，成功 “出境”。

三、硬件网卡相关丢包场景

Ring Buffer 满：“拥堵” 的数据包入口

<doubaocanvas identifier="linux-network-packet-loss-optimization" type="text/markdown" genre="技术说明优化稿" title="Linux系统网卡丢包问题分析与解决方案优化阐述">
当网卡接收流量超出一定阈值，而 CPU 处理能力无法与之匹配时，网络状况就如同高速公路入口车流量严重饱和，然而收费站处理速度却极为缓慢。在这种情况下，数据包会在 RingBuf（环形缓冲区）这个数据接收的关键节点处大量积压。随着时间推移，RingBuf 最终会被填满，进而导致丢包现象发生。

为了判断是否是由于接收 RingBuf 溢出导致的丢包问题，可以通过ethtool -S命令查看网卡的统计信息。如果rx_no_buffer_count（无缓冲区接收计数）持续增长，基本可以确定是接收 RingBuf 满溢引发的丢包。

导致这种网络拥塞状况的原因主要有以下几方面：

• 硬中断分发不均衡：硬中断分发不均是导致丢包的重要因素之一。在多核 CPU 系统中，若网卡产生的硬中断集中分配到某一个 CPU 核心进行处理，就如同大量快递包裹都由一个快递员派送，该核心必然会因处理压力过大而不堪重负。要查看网卡硬中断在各 CPU 核心上的分配情况，可使用cat /proc/interrupts命令。若发现网络报文处理任务过度集中于某一个核心，就需要进行硬中断的重新分配。具体操作是先关闭irqbalance服务（该服务负责自动分配硬件中断），然后利用set_irq_affinity.sh脚本，手动将硬中断均匀绑定到多个 CPU 核心上，从而实现多个核心协同处理，有效缓解单个核心的处理压力，改善网络拥塞状况。
• 会话分发不均衡：即便硬中断在各个 CPU 核心上的分配看似均衡，但某些网络流量所触发的中断量过大，且集中在少数几个核心上，依然会导致 CPU 处理能力不足而丢包。对于支持多接收队列的网卡，其具备 RSS（Receive Side Scaling，接收端缩放）功能。该功能类似于智能分拣系统，能够根据数据包的源 IP、目的 IP、源端口、目的端口等信息，通过哈希算法将数据包分发到不同的接收队列，再由不同的 CPU 核心分别处理。可以通过ethtool -l eth0命令查看网卡是否支持多队列。若支持，还能使用ethtool --show-ntuple eth0 rx - flow - hash udp4命令查看 UDP 会话分发所使用的哈希关键字。若发现当前的哈希关键字导致会话分发不合理，可通过ethtool --config-ntuple命令修改分发所使用的哈希关键字，使数据包的分发更加科学合理，提升 CPU 处理效率。
• 应对网卡多队列局限性：如果网卡不支持多队列，或者其支持的队列数量远少于 CPU 核心数量，Linux 内核提供了 rps（Receive Packet Steering，接收数据包导向）机制。该机制通过软件方式实现软中断的负载均衡，类似于交通协管员在软件层面进行流量疏导。例如，通过echo ff > /sys/class/net/eth0/queues/rx - 0/rps_cpus命令，可以指定某个接收队列由特定的 CPU 核心进行处理。不过需要注意的是，由于 rps 是基于软件模拟实现的，与硬件层面的硬中断均衡相比，性能上存在一定差距。因此，在一般情况下，若无特殊需求，不建议启用该机制。
• 应对间歇性突发流量：当网络中出现间歇性突发流量时，就如同节假日景区突然涌入大量游客，网络处理能力会面临巨大挑战。此时，可以通过ethtool -g命令查看当前 RingBuf 的配置情况，再使用ethtool -G命令适当增大 RingBuf 的大小。扩大 RingBuf 相当于为数据包提供了一个更大的临时存储空间，有助于减少因突发流量导致的丢包现象，提高网络的稳定性和可靠性。

通过对以上几种常见导致丢包原因的分析和相应解决方案的实施，可以有效提升 Linux 系统在网络流量复杂情况下的稳定性和数据处理能力。

利用 ntuple 保证关键业务：流量中的 “优先级通道”

在复杂多变的网络架构中，网络流量的规模与动态性犹如汹涌澎湃的洪流，持续冲击着网络传输的稳定性与高效性。其中，关键业务所产生的数据包对于传输的时效性与稳定性要求极高，它们如同身负紧急任务、急需赶赴重要行程的 VIP 旅客，迫切需要在网络传输过程中获得优先处理的特权，以保障其能够在最短时间内、以最稳定的方式抵达目的地。

在默认配置下，网卡通常采用 RSS（Receive Side Scaling，接收端缩放）技术来处理数据包。这一技术基于数据包的源 IP 地址、目的 IP 地址、源端口号、目的端口号等特定属性，通过哈希算法进行计算，从而将数据包分配至相应的队列进行后续处理。尽管 RSS 技术在提升网络整体处理能力方面卓有成效，但它无法对承载关键业务的控制报文等特殊数据包进行有效识别与区分。

为了填补这一空白，满足关键业务数据包的特殊传输需求，启用网卡的 ntuple 功能成为了一种行之有效的解决方案。ntuple 功能通过对数据包的多个字段进行精细匹配，为关键业务开辟了一条专属的 “优先级通道”。以 TCP 端口号为 23 的报文为例，这类报文通常用于 Telnet 控制通信，对网络响应速度和稳定性要求苛刻。借助 ntuple 功能，可将其定向引导至特定的 queue 9 队列进行处理，使其能够享受到 “专车式” 的快速、优先服务。与此同时，其他普通数据包则继续遵循 RSS 技术的规则，通过另外 8 个队列进行有条不紊的处理。这种分流机制不仅确保了关键业务数据包的高效传输，还维持了网络整体处理能力的均衡与稳定。

具体而言，实现这一功能的操作步骤如下：

1. 开启 ntuple 功能：通过执行ethtool -K eth0 ntuple on命令，可激活 eth0 网卡的 ntuple 功能。这一操作是后续精细流量控制的基础，为实现关键业务数据包的精准分流提供了可能。
2. 设置分流规则：运行ethtool -U eth0 flow - type tcp4 dst - port 23 action 9命令，该命令针对 TCP 协议第 4 版（tcp4）的流量进行配置，将目标端口号为 23 的 TCP 报文引导至 queue 9 队列。通过这一设置，关键业务的数据包能够被精准识别并分流至指定队列，确保其优先处理权。
3. 配置普通报文队列：使用ethtool -X eth0 equal 8命令，将剩余的普通数据包均匀分配至 8 个队列进行处理。这一操作在保障关键业务数据包优先传输的同时，充分利用了网卡的多队列处理能力，维持了网络整体的高效运行。

然而，需要特别强调的是，此方案的成功实施高度依赖于底层网卡的硬件支持。正如并非所有车站都配备了 VIP 通道设施一样，只有当网卡具备相应的硬件能力时，才能顺利启用 ntuple 功能，并实现对关键业务流量的精细化控制。因此，在部署该方案之前，必须仔细确认网卡的硬件规格与功能特性，确保其满足方案实施的要求，从而实现预期的网络优化效果，为关键业务的稳定运行提供坚实保障。

四、ARP丢包隐患

Neighbor table overflow：ARP 表的 “容量危机”

ARP（Address Resolution Protocol），它负责将 IP 地址转换为 MAC 地址，就像是网络世界里的 “翻译官”，让数据包能准确找到目标设备。但有时候，这个 “翻译官” 也会遇到麻烦，比如邻居表（neighbor table）满了，也就是 ARP 表溢出。这时候，内核会像个焦急的 “传令兵”，大量打印 “neighbour: arp_cache: neighbor table overflow!” 这样的报错信息，仿佛在大声呼喊：“出事啦，ARP 表装不下啦！” 咱们可以通过查看 /proc/net/stat/arp_cache 文件，要是发现里面的 table_fulls 统计值蹭蹭往上涨，那毫无疑问，ARP 表已经陷入了 “容量危机”。内核会大量打印如下的消息：

[22181.923055] neighbour: arp_cache: neighbor table overflow!
[22181.923080] neighbour: arp_cache: neighbor table overflow!
[22181.923128] neighbour: arp_cache: neighbor table overflow!

cat /proc/net/stat/arp_cache也能看到大量的 table_fulls 统计：

[root@centos ~]# cat /proc/net/stat/arp_cache 
entries  allocs destroys hash_grows  lookups hits  res_failed  rcv_probes_mcast rcv_probes_ucast  periodic_gc_runs forced_gc_runs unresolved_discards table_fulls
00000002  0000000d 0000000d 00000000  00000515 00000089  00000015  00000000 00000000  00000267 000003a1 00000023 0000039c
00000002  0000001c 0000001a 00000000  00001675 00000374  00000093  00000000 00000000  000003bf 00000252 00000046 00000240

为啥 ARP 表会满呢？

这通常是因为短时间内大量新的 IP-MAC 映射关系涌入，可旧的条目又没及时清理出去，垃圾回收机制没跟上节奏。想象一下，一个小仓库，不停地进货，却很少出货，空间不就越来越小嘛。

怎么解决呢？

调整内核参数是个 “妙招”。在 /proc/sys/net/ipv4/neigh/default/ 目录下，有几个关键的参数：gc_thresh1、gc_thresh2、gc_thresh3，它们就像是仓库的 “库存管理员”，掌控着 ARP 表的大小。gc_thresh1 是最小条目数，当缓存中的条目数少于它，垃圾回收器就 “睡大觉”，不干活；gc_thresh2 是软最大条目数，要是实际条目数超过它 5 秒，垃圾回收器就会被 “叫醒”，赶紧清理；gc_thresh3 是硬最大条目数，一旦缓存中的条目数越过这条 “红线”，垃圾回收器就得马不停蹄地一直工作。
一般来说，咱们可以适当提高这些阈值，给 ARP 表 “扩容”。比如，执行 “echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1”，这就相当于跟系统说：“嘿，把最小库存标准提高到 1024 吧。” 要是想让设置永久生效，还得编辑 /etc/sysctl.conf 文件，把 “net.ipv4.neigh.default.gc_thresh1 = 1024” 之类的配置项加进去，保存后执行 sysctl -p，就大功告成啦。不过得注意，调整参数要结合实际网络环境，别调得太大，不然占用过多内存，反而可能引发其他问题，得拿捏好这个 “度”。

unresolved drops

当发送报文时，如果还没解析到 arp，就会发送 arp 请求，并缓存相应的报文。当然这个缓存是有限制的，默认为 SK_WMEM_MAX（即与 net.core.wmem_default 相同）。当大量发送报文并且 arp 没解析到时，就可能超过 queue_len 导致丢包，cat /proc/net/stat/arp_cache可以看到unresolved_discards 的统计：

[root@centos ~]# cat /proc/net/stat/arp_cache
entries  allocs destroys hash_grows  lookups hits  res_failed  rcv_probes_mcast rcv_probes_ucast  periodic_gc_runs forced_gc_runs unresolved_discards table_fulls
00000004  00000006 00000003 00000000  0000008f 00000018  00000000  00000000 00000000  00000031 00000000 00000000 00000000
00000004  00000005 00000004 00000000  00000184 0000003b  00000000  00000000 00000000  00000053 00000000 00000005 00000000

可以通过调整 /proc/sys/net/ipv4/neigh/eth0/unres_qlen_bytes 参数来缓解该问题。

五、Conntrack丢包困境

nf_conntrack: table full：连接跟踪表的 “超载难题”

nf_conntrack 模块就像是网络连接的 “管家”，负责跟踪每个网络连接的状态，像连接何时建立、何时传输数据、何时结束，它都记得清清楚楚。可有时候，这个 “管家” 也会遇到大麻烦，那就是连接跟踪表满了，内核会频繁打印 “nf_conntrack: table full, dropping packet” 的报错信息，就像管家着急地大喊：“不行啦，装不下啦，要丢包啦！” 这时候，通过 cat /proc/sys/net/netfilter/nf_conntrack_count 查看当前连接数，再和 cat /proc/sys/net/netfilter/nf_conntrack_max 显示的最大连接数对比，如果发现当前连接数飙升，直逼甚至超过最大连接数，那基本就能断定是连接跟踪表满导致的丢包。

为啥连接跟踪表会满呢？

当服务器遭遇突发的高并发连接，像电商大促、热门游戏开服，大量新连接瞬间涌入，可旧连接又没及时清理，就像高峰期的火车站，人只进不出，候车大厅不就爆满了嘛。还有一种情况，某些应用程序存在连接泄漏问题，不停地创建新连接，却忘记关闭旧连接，时间一长，连接跟踪表也吃不消了。

那怎么解决呢？

调整内核参数是个关键招法。首先，加大 nf_conntrack_max 参数，就像给连接跟踪表 “扩容”。理论上，它的最大值可以按照 CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32) 这个公式来计算，比如 32G 内存的服务器，大概可以设置为 1048576。咱们可以通过 sysctl -w net.netfilter.nf_conntrack_max = 1048576 即时生效，要是想让设置永久生效，就得编辑 /etc/sysctl.conf 文件，把 “net.netfilter.nf_conntrack_max = 1048576” 写进去，保存后执行 sysctl -p。不过要注意，不能盲目调得太大，毕竟内存资源有限，得根据服务器实际业务量、内存大小等因素综合考量，找到一个平衡点，不然可能会引发系统内存不足，导致其他更严重的问题。

UDP 接收 buffer 满：UDP 数据的 “接收瓶颈”

UDP（User Datagram Protocol）作为一种无连接的传输协议，虽然传输高效，但也伴随着丢包的风险。当 UDP 接收 buffer 满时，那些后续抵达的 UDP 数据包就像迷失方向的 “孤雁”，找不到落脚之地，只能无奈被丢弃。

怎么判断是不是 UDP 接收 buffer 满导致的丢包呢？

咱们可以使用 netstat -su 这个命令，它就像是一个 “数据包侦探”，能帮咱们查看 UDP 的错包信息。要是发现 “packet receive errors” 这一项的数值在不断攀升，那就得当心了，很可能是 UDP 接收 buffer 满引发的丢包 “警报”。

通过netstat查看 receive buffer errors 的统计就可以获知是否存在这种情况：

[root@centos ~]# netstat -su
...
Udp:690124 packets received3919 packets to unknown port received.0 packet receive errors694556 packets sent0 receive buffer errors0 send buffer errors
UdpLite:
IpExt:InNoRoutes: 2InMcastPkts: 37301InOctets: 2711899731OutOctets: 2207144577InMcastOctets: 1342836InNoECTPkts: 14891803InECT1Pkts: 2339

一般通过修改 /proc/sys/net/core/rmem_max，并且设置 SO_RCVBUF 选项来增加 socket buffer 可以缓解该问题。

为啥 UDP 接收 buffer 会满呢？

一方面，可能是应用程序处理 UDP 数据包的速度太慢，就像快递员送货，仓库收货速度远远赶不上送货速度，货物自然就堆积如山了。比如说，某个应用程序忙于复杂的数据处理，无暇及时从接收 buffer 中取出 UDP 数据包，导致 buffer 被填满。另一方面，UDP 接收 buffer 的大小设置不合理，默认的 buffer 空间太小，面对大量涌入的 UDP 数据包，很快就不堪重负。

那怎么解决这个问题呢？

调整内核参数是关键一招。咱们可以通过 sysctl 命令来增大 UDP 接收 buffer 的大小。比如，执行 sysctl -w net.core.rmem_max=8388608，这就相当于给 UDP 数据包的 “仓库” 扩容，让它能容纳更多的数据。同时，还可以调整 net.core.rmem_default 参数，像执行 sysctl -w net.core.rmem_default=8388608，让默认的接收 buffer 也变大，双管齐下，为 UDP 数据包提供更充足的 “栖息之所”，减少丢包的发生。

六、dropwatch 查看丢包：精准定位丢包

当网络出现丢包问题时，dropwatch 堪称一位专业 “侦探”，助力我们迅速锁定问题根源。它基于 kfree_skb 事件，实时监控内核丢包状况，确保任何一个 “逃逸” 数据包都无所遁形。

使用 dropwatch 前，需先安装相关依赖。在基于 Debian 的系统上，可执行命令sudo apt-get install -y libnl-3-dev libnl-genl-3-dev binutils-dev libreadline6-dev完成安装。随后，通过GitHub - nhorman/dropwatch: user space utility to interface to kernel dropwatch facility下载工具。下载完成后，进入/src目录，执行make命令进行编译。

运行时，先执行sudo./dropwatch -l kas启动工具，接着输入start指令开启监控。此时，dropwatch 便如尽职 “卫士”，实时展示丢包数量、发生位置等关键信息。例如，当出现 “1 drops at icmp_rcv+11c (0xffffffff8193bb1c) [software]” 提示，这表明有一个数据包在 icmp_rcv 函数偏移 11c 处被丢弃。根据此线索，深入剖析该函数相关代码逻辑，便能精准找出丢包原因，有效解决网络问题，保障网络顺畅运行。

上面也可以用docker来安装

docker build -t dropwatch .
docker run -it --rm -v /usr/src:/usr/src:ro -v /lib/modules/:/lib/modules:ro -v /sys/:/sys/:rw --net=host --pid=host --privileged dropwatch