Linux UDP严重丢包问题的解决

最新推荐文章于 2025-10-27 14:55:05 发布
转载 最新推荐文章于 2025-10-27 14:55:05 发布 · 1.3k 阅读 · 6

本文针对Linux环境下严重的丢包问题进行深入分析与解决，通过调整内核参数和防火墙设置显著提升了网络性能。

 

测试系统在Linux上的性能发现丢包率极为严重，发210000条数据，丢包达110000之巨，丢包率超过50%。同等情形下Windows上测试，仅丢几条数据。形势严峻，必须解决。考虑可能是因为协议栈Buffer太低所致，于是先看看默认情况：

sysctl -a |grep net.core

发现

net.core.rmem_max = 131071

net.core.rmem_default = 112640

修改吧，变大一点，变成10M，然后reboot（应该重启某个服务即可）

然后查网卡收包情况：

netstat -su

结果如下：

Udp:

97690 packets received

112310 packets to unknown port received.

0 packet receive errors

20 packets sent

发现数据在网卡就丢了，判断可能是防火墙引起的，于是执行命令：

iptables -L

结果如下：

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

证明iptables启动，于是停止防火墙：

service iptables stop

这个命令即时生效，开启防火墙的命令：

service iptables start

如果要彻底关闭防火墙，则需要重启后生效

开启： chkconfig iptables on

关闭： chkconfig iptables off

在开启了防火墙时，做如下设置，开启相关端口，

修改/etc/sysconfig/iptables 文件，添加以下内容：

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT

重新测试，没丢一条数据。

linux 内核参数调整说明

所有的TCP/IP调优参数都位于/proc/sys/net/目录。例如, 下面是最重要的一些调优参数, 后面是它们的含义:

1. /proc/sys/net/core/rmem_max — 最大的TCP数据接收缓冲。

2. /proc/sys/net/core/wmem_max — 最大的TCP数据发送缓冲。

3. /proc/sys/net/ipv4/tcp_timestamps — 时间戳在(请参考RFC 1323)TCP的包头增加12个字节。

4. /proc/sys/net/ipv4/tcp_sack — 有选择的应答。

5. /proc/sys/net/ipv4/tcp_window_scaling — 支持更大的TCP窗口. 如果TCP窗口最大超过65535(64KB), 必须设置该数值为1。

6. rmem_default — 默认的接收窗口大小。

7. rmem_max — 接收窗口的最大大小。

8. wmem_default — 默认的发送窗口大小。

9. wmem_max — 发送窗口的最大大小。

/proc目录下的所有内容都是临时性的, 所以重启动系统后任何修改都会丢失。

建议在系统启动时自动修改TCP/IP参数:

把下面代码增加到/etc/rc.local文件, 然后保存文件, 系统重新引导的时候会自动修改下面的TCP/IP参数:

echo 256960 > /proc/sys/net/core/rmem_default

echo 256960 > /proc/sys/net/core/rmem_max

echo 256960 > /proc/sys/net/core/wmem_default

echo 256960 > /proc/sys/net/core/wmem_max

echo 0 > /proc/sys/net/ipv4/tcp_timestamps

echo 1 > /proc/sys/net/ipv4/tcp_sack

echo 1 > /proc/sys/net/ipv4/tcp_window_scaling

TCP/IP参数都是自解释的, TCP窗口大小设置为256960, 禁止TCP的时间戳(取消在每个数据包的头中增加12字节), 支持更大的TCP窗口和TCP有选择的应答。

上面数值的设定是根据互连网连接和最大带宽/延迟率来决定。

注: 上面实例中的数值可以实际应用, 但它只包含了一部分参数。

另外一个方法: 使用 /etc/sysctl.conf 在系统启动时把参数配置成您所设置的值:

net.core.rmem_default = 256960

net.core.rmem_max = 256960

net.core.wmem_default = 256960

net.core.wmem_max = 256960

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_sack =1

net.ipv4.tcp_window_scaling = 1

设置Linux内核参数

配置 Linux 内核参数(2种方法),修改后不用重启动更新: /sbin/sysctl -p

第一种:打开/etc/sysctl.conf 复制如下内容

kernel.shmall = 2097152

kernel.shmmax = 2147483648

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

fs.file-max = 65536

net.ipv4.ip_local_port_range = 1024 65000

net.core.rmem_default=262144

net.core.wmem_default=262144

net.core.rmem_max=262144

net.core.wmem_max=262144

第二种:打开终端

cat >> /etc/sysctl.conf<

kernel.shmall = 2097152

kernel.shmmax = 2147483648

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

fs.file-max = 65536

net.ipv4.ip_local_port_range = 1024 65000

net.core.rmem_default=262144

net.core.wmem_default=262144

net.core.rmem_max=262144

net.core.wmem_max=262144

EOF

这里，对每个参数值做个简要的解释和说明。

（1）shmmax：该参数定义了共享内存段的最大尺寸（以字节为单位）。缺省为32M，对于oracle来说，该缺省值太低了，通常将其设置为2G。

（2）shmmni：这个内核参数用于设置系统范围内共享内存段的最大数量。该参数的默认值是 4096 。通常不需要更改。

（3）shmall：该参数表示系统一次可以使用的共享内存总量（以页为单位）。缺省值就是2097152，通常不需要修改。

（4）sem：该参数表示设置的信号量。

（5）file-max：该参数表示文件句柄的最大数量。文件句柄设置表示在linux系统中可以打开的文件数量。

修改好内核以后，执行下面的命令使新的配置生效。

[root @linux1 /root]# /sbin/sysctl -p

以 root 用户身份运行以下命令来验证您的设置：

/sbin/sysctl -a | grep shm

/sbin/sysctl -a | grep sem

/sbin/sysctl -a | grep file-max

/sbin/sysctl -a | grep ip_local_port_range

例如：

# /sbin/sysctl -a | grep shm

kernel.shmmni = 4096

kernel.shmall = 2097152

kernel.shmmax = 2147483648

kernel.shm-use-bigpages = 0

# /sbin/sysctl -a | grep sem

kernel.sem = 250 32000 100 128

# /sbin/sysctl -a | grep file-max

fs.file-max = 65536

# /sbin/sysctl -a | grep ip_local_port_range

net.ipv4.ip_local_port_range = 1024 65000

如果系统的参数设置的比上述参数值小，则编辑 /etc/sysctl.conf 文件，添加或更改这些参数。完成后，运行以下命令激活更改：

/sbin/sysctl -p

PS：通常用默认参数就可以了吧.

转载：http://www.360doc.com/content/14/0605/15/3300331_383895379.shtml

UnixFBI 运维特工 www.unixfbi.com

分类: linux运维

好文要顶 关注我 收藏该文  

unixfbi.com
关注 - 61
粉丝 - 21

+加关注

0

0

« 上一篇：Linux内核 TCP/IP、Socket参数调优
» 下一篇：服务器流量异常排查步骤（查看进程的流量）

Linux UDP丢包问题的解决方案
YpysHtml的博客
10-02 779
调整套接字缓冲区大小、使用可靠的应用层协议、检查网络设备和配置，以及使用多播或广播传输，都是有效的方法。根据具体情况选择合适的解决方案，可以提高UDP传输的可靠性和性能，减少丢包问题的发生。然而，在某些情况下，Linux系统上的UDP套接字可能会遇到丢包问题，这可能导致数据传输的不完整或延迟。如果应用程序对数据的可靠传输有较高的要求，可以考虑在应用层实现可靠性，例如使用自定义的重传机制或使用可靠的应用层协议（如TCP）。通过增加套接字缓冲区大小，可以提高UDP传输的性能和可靠性，从而减少丢包的可能性。
linux查看udp丢包数量,Linux下UDP丢包问题分析思路
weixin_35990295的博客
05-15 3151
最近工作中需要为PHP服务提供存储prometheus指标数据的UDP服务器。然后就用Netty实现了一个简单地UDP服务。但是在压测的过程中发现有严重的丢包现象。下面我们就来分析一下丢包发生的原因以及解决办法1.linux 系统接收网络报文的过程接收数据包是一个复杂的过程，涉及很多底层的技术细节，但大致需要以下几个步骤：网卡收到数据包。将数据包从网卡硬件缓存转移到服务器内存中。通知内核处理。经过...
linux 内核参数调整说明
weixin_33834075的博客
01-11 1057
所有的TCP/IP调优参数都位于/proc/sys/net/目录。例如, 下面是最重要的一些调优参数, 后面是它们的含义: 1. /proc/sys/net/core/rmem_max — 最大的TCP数据接收缓冲。 2. /proc/sys/net/core/wmem_max — 最大的TCP数据发送缓冲。 3. /proc/sys/net/ipv4/tcp_timesta...
《为什么 Linux UDP 会丢包？从网络层到应用层的排查思路》
2501_93928749的博客
10-27 502
UDP（用户数据报协议）是一种无连接、不可靠的传输协议，在 Linux 系统中容易发生丢包问题。这通常源于网络拥塞、缓冲区溢出或应用处理延迟。下面我将从网络层到应用层逐步分析原因，并提供清晰的排查思路。排查时，建议从底层开始向上层推进，以定位根本问题。通过以上步骤，90% 的丢包问题可定位解决。如果问题持续，考虑硬件升级或网络架构优化。排查时，使用 Linux 内置工具逐步检查。
【Linux中UDP服务丢包率过高排查思路】
分布式后浪的博客
07-19 4341
Linux中监控排查UDP服务，不同并发的丢包率和优化方案分析
Linux内核网络参数
weixin_34100227的博客
12-05 199
Linux系统内核中网络参数的意义及其应用 在Linux中，我们可以根据不同的需求来调整/proc/sys/net/ipv4/目录下的内核网络参数，通过合理的配置这里内核网络参数，从而达到提高网络的安全性和系统的稳定性的目的。 在Linux中，我们可以根据不同的需求来调整/proc/sys/net/ipv4/目录下的内核网络参数，通过合理...
linux udp接收不到数据,无法接收udp数据包
weixin_29245767的博客
05-13 4275
我不知道是网络配置的问题还是我的软件出了问题。在我有一个地址为192.168.4.83的设备。这个设备直接连接到我的pc linux服务器，它的地址是192.168.4.11。在我想用python从服务器向设备发送UDP包。服务器也在监听响应。我有一个简单的python脚本来实现这一点。我用以下方式发送：self.sendSocket = socket.socket(socket.AF_INET,...
linux 虚拟机大量udp请求失败_Linux UDP严重丢包问题的解决
weixin_42213784的博客
12-29 887
测试系统在Linux上的性能发现丢包率极为严重，发210000条数据，丢包达110000之巨，丢包率超过50%。同等情形下Windows上测试，仅丢几条数据。形势严峻，必须解决。考虑可能是因为协议栈Buffer太低所致，于是先看看默认情况：sysctl -a |grep net.core发现net.core.rmem_max = 131071net.core.rmem_default = 1126...
linux系统UDP丢包问题分析思路
嵌入式技术在路上
03-05 1588
（1）UDP 本身就是无连接不可靠的协议，适用于报文偶尔丢失也不影响程序状态的场景，比如视频、音频、游戏、监控等。对报文可靠性要求比较高的应用不要使用 UDP，推荐直接使用 TCP。当然，也可以在应用层做重试、去重保证可靠性（2）如果发现服务器丢包，首先通过监控查看系统负载是否过高，先想办法把负载降低再看丢包问题是否消失（3）如果系统负载过高，UDP 丢包是没有有效解决方案的。如果是应用异常导致 CPU、memory、IO 过高，请及时定位异常应用并修复；
linux 系统 UDP 丢包问题分析思路
qfxx_优快云的博客
03-10 3660
本文转载： 原文地址：https://cizixs.com/2018/01/13/linux-udp-packet-drop-debug/ 最近工作中遇到某个服务器应用程序 UDP 丢包，在排查过程中查阅了很多资料，总结出来这篇文章，供更多人参考。 在开始之前，我们先用一张图解释 linux 系统接收网络报文的过程。 首先网络报文通过物理网线发送到网卡 网络驱动程序会把网络中的报文读出来放到 ring buffer 中，这个过程使用 DMA（Direct Memory Access），不需要 CPU 参与
Linux丢包故障的解决与思路
热门推荐
yunlianglinfeng的专栏
04-24 1万+
前言 ​ 本文为大部分内容是转载:原文地址，和之前一样，在原文的基础上进行了一些格式的调整，包括一些错别字的修正，以及进行了一些博文链接的插入，以便于读者或者我自己更好的理解。 ​ 我们使用Linux作为服务器操作系统时，为了达到高并发处理能力，充分利用机器性能，经常会进行一些内核参数的调整优化，但不合理的调整常常也会引起意想不到的其他问题，本文就一次Linux服务器丢包故障的处理过程，结合Linux内核参数说明和TCP/IP协议栈相关的理论，介绍一些常见的丢包故障定位方法和解决思路。 ​ 在开始之前
Linux网络编程-UDP接收数据丢包解决方案
shuaixio的博客
07-30 9950
linux，socket通信，udp，接收缓冲区，recvfrom
Linux服务器丢包故障的解决思路及引申的TCP IP协议栈理论
2401_84254196的博客
04-15 310
如上图所示，客户端发送的序列号为A的数据包A1因某些原因在网络中“迷路”，在一定时间没有到达服务端，客户端超时重传序列号为A的数据包A2，接下来假设带宽足够，传输用尽序列号空间，重新使用A，此时服务端等待的是序列号为A的数据包A3，而恰巧此时前面“迷路”的A1到达服务端，如果服务端仅靠序列号A就判断数据包合法，就会将错误的数据传递到用户态程序，造成程序异常。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，Ring Buffer很快会被填满，新来的数据包将被丢弃。
linux 下 iperf 对 UDP 丢包率测试
大道之行，始于足下
06-06 2541
linux 下 iperf 对 UDP 丢包率测试
Linux UDP 丢包问题
weixin_34184561的博客
01-21 176
每个UDP包680字节左右，同时发送1500个包到服务器，发现大多被内核丢掉：修改 /etc/sysctl.conf中关于socket缓冲区的配置 :net.core.rmem_default = 256960net.core.rmem_max = 256960net.core.wmem_default = 256960net.core.wmem_max = 256960用sysctrl -p命...
linux内核网络参数全解析（一）
sskywatcher的博客
02-24 5286
本文收录在我的博客  http://www.sskywatcher.com/blog/archives/50Chapter 1. 如何设置参数linux内核的网络参数可以有俩个不同的方法设置. 第一个方法是通过现在大多数linux发行版默认安装的 sysctl 工具. 另一个方法就是利用 /proc文件系统,这个方法应该是自从有了/proc文件系统以来所有的linux内核都支持的. 使用sysct...
Linux丢包故障的定位与解决
qq_43401815的博客
04-11 1730
如何排查？怎样解决？服务器能正常接收到数据包，问题可以限定在两种可能：部分客户端发出的数据包本身异常；服务器处理部分客户端的数触发了某种机制丢弃了数据包。因为出问题的客户端能够正常访问公网上其他服务，后者的可能性更大。那么，有哪些情况会导致Linux服务器丢弃数据包？
linux系统UDP接收丢包有什么办法
最新发布
10-30
<think>嗯，用户这次问的是Linux系统下解决UDP接收丢包问题的具体方法。从用户给出的引用材料来看，问题很具体，而且引用内容质量较高，都是针对Linux UDP丢包的专业分析。 用户引用的四篇资料基本覆盖了UDP丢包的核心原因和解决方案。引用1提到Windows和Linux的对比测试，说明是系统性问题；引用2明确指出缓存区溢出和报文过大两个关键因素；引用3补充了应用层解决方案；引用4则涉及多核负载均衡这种高级优化。 看来用户应该是个系统运维工程师或者网络开发人员，正在处理实际的UDP性能问题。从提问方式看很专业，直接聚焦在“接收端”的解决方案，说明已经排除了发送端和网络链路的问题。用户可能正在面临生产环境下的严重丢包，语气中透着急切。 需要特别注意几个技术要点：首先是内核参数调整，这是见效最快的方法；然后是队列处理和多核负载，这对高性能场景很关键；最后才是应用层的补救措施。用户引用的资料里提到RFS(Receive Flow Steering)技术效果显著，这个要重点说明。 在组织回答时，应该按照从系统层到应用层的顺序：先解决内核缓存这种基础问题，再处理多核优化，最后考虑应用层方案。每个方案都要给出具体操作命令，像sysctl参数和ethtool设置这种，用户可以直接拿去用。 特别要强调mtu检查和缓存区计算的关系。引用2和3都提到大报文分片问题，但没具体说明计算方法，这里需要补充1500字节mtu下实际udp载荷1472字节这个关键数字。 最后关于CPU亲和性和中断均衡的部分，考虑到用户引用4里提到软中断负载问题，需要详细说明irqbalance和手动绑核两种方案的取舍。用户既然能测试丢包率，应该具备服务器权限，可以建议他尝试RPS/RFS这类高级特性。 </think>在Linux系统中解决UDP接收丢包问题，需从系统配置、网络参数、硬件优化及应用层设计多维度入手。以下是关键解决方案： --- ### **1. 扩大Socket接收缓冲区** - **问题根源**：默认缓冲区过小导致报文溢出（引用[2]）。 - **解决方案**： ```bash # 临时调整（单位：字节） sysctl -w net.core.rmem_max=67108864 # 最大64MB sysctl -w net.core.rmem_default=4194304 # 默认4MB # 永久生效：写入 /etc/sysctl.conf net.core.rmem_max = 67108864 net.core.rmem_default = 4194304 ``` 应用层需同步设置： ```c int recv_buf_size = 64 * 1024 * 1024; setsockopt(sock_fd, SOL_SOCKET, SO_RCVBUF, &recv_buf_size, sizeof(recv_buf_size)); ``` --- ### **2. 优化多核负载均衡** - **问题根源**：单核处理软中断成为瓶颈（引用[4]）。 - **解决方案**： - **启用RPS/RFS**（需内核≥2.6.35）： ```bash # 分配所有CPU核心处理网卡队列 echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus # f代表4核系统 ``` - **配置IRQ均衡**： ```bash apt-get install irqbalance # 安装中断均衡服务 systemctl start irqbalance # 启动服务 ``` - **手动绑定网卡中断到多核**： ```bash # 查看中断号 grep eth0 /proc/interrupts # 绑定中断0到CPU0~3 echo 0-3 > /proc/irq/128/smp_affinity_list ``` --- ### **3. 调整网络栈参数** - **减少处理延迟**： ```bash # 增大积压队列 sysctl -w net.core.netdev_max_backlog=100000 # 提升NAPI处理权重（避免饥饿） sysctl -w net.core.dev_weight=512 ``` --- ### **4. 应用层优化** - **减少拷贝开销**： - 使用`recvmmsg()`批量接收报文（减少系统调用）。 - 启用零拷贝技术（如`SO_ZEROCOPY`，需内核≥4.15）。 - **异步处理机制**： ```c // 示例：epoll异步接收 struct epoll_event ev; ev.events = EPOLLIN; epoll_ctl(epfd, EPOLL_CTL_ADD, sock_fd, &ev); ``` --- ### **5. 硬件与驱动优化** - **开启网卡特性**： ```bash # 启用多队列（需网卡支持） ethtool -L eth0 combined 4 # 增大Ring Buffer ethtool -G eth0 rx 4096 ``` - **卸载校验和计算**： ```bash ethtool -K eth0 rx on tx on ``` --- ### **6. 冗余与重传机制** - **前向纠错（FEC）**：添加冗余数据包抗丢包（引用[3]）。 - **应用层重传**：对关键数据实现ACK/重传逻辑。 ```python # 伪代码示例 while timeout_not_reached: send_packet(packet) if receive_ack(packet.id): break ``` --- ### **验证与监控** 1. **实时丢包统计**： ```bash watch -n 1 "netstat -su | grep 'receive errors'" ``` 2. **队列溢出检测**： ```bash ethtool -S eth0 | grep rx_dropped ``` 3. **软中断负载**： ```bash mpstat -P ALL 1 # 监控各核软中断占用 ``` --- > **关键陷阱**: 若MTU设置不当（如＞1500未启用巨帧），分片重组失败将直接丢包。检测命令： > ```bash > ping -M do -s 1472 192.168.1.1 # 测试有效MTU（1472+28=1500） > ``` 通过上述组合策略，可显著降低UDP丢包率。实际部署需结合`netperf`、`iperf`等工具压测验证[^2][^4]。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值