Linux网络性能优化实战：从内核参数调整到tcpdump抓包排查

某个深夜线上接口的P99延迟从60ms一路冲到700ms我第一时间就想做一轮Linux网络性能优化与监控于是把网上那套内核参数调优脚本挨个灌进去tcp_tw_reuse、tcp_max_syn_backlog全都改了。结果延迟没降反而有机器连接池先撑不住了。后来冷静下来用监控和抓包一步步排查才发现问题是网卡软中断全压在一个CPU上再加上对端接收窗口频繁降零跟我改的那些参数关系不大。这篇指南想把Linux网络性能优化与监控这条链路完整串起来从内核参数调优到用ss、sar、iftop、ethtool看清网络状态再到用tcpdump和Wireshark围绕一次请求做深入分析。它不是一份参数速查表而是一套可复现的排查方法适合正在跟网络性能死磕的运维、后端开发以及SRE同学按图索骥。我尽量把为什么这样判断、为什么这样调参、为什么这样抓包都讲透遇到问题你能直接照做。1. 别急着改内核参数先回答网络慢到底慢在哪1.1 网络性能的四层定位思路处理网络性能问题我最怕看到的就是一上来就调内核参数。网络链路很长从应用代码发出请求到对端返回会依次经过应用层、系统调用、内核协议栈、驱动、网卡硬件再到物理链路。任何一个环节掉链子表现可能都是同一个字慢。如果你不看数据就动手很容易把某个无关参数改掉然后背上一口大锅。我习惯把排查分成四层应用层业务代码处理慢、线程池阻塞、GC停顿、数据库慢查询。TCP/UDP层握手延迟、重传、零窗口、乱序、分片。内核网络栈接收队列溢出、Socket缓冲区不足、backlog队列积压。硬件与驱动层网卡丢包、中断不均衡、速率协商异常、ring buffer太小。快速定位可以先用一小套命令把网络栈和网卡的状态拉出来看# 网络栈丢包与重传统计 netstat -s | egrep retrans|overflow|drop|reset|listen # 内核软中断与网卡接收队列状态 cat /proc/net/softnet_stat # 网卡驱动层面的丢包计数 ethtool -S eth0 | egrep rx_dropped|rx_missed|rx_no_buffer|tx_dropped这些输出会告诉你问题是否值得去动内核参数。如果应用层处理耗时本身就高你调整一万个sysctl也帮不上忙。比如说接口里有一个数据库慢查询每次要等300ms这时你再去调网络缓冲区纯属南辕北辙。先分层再动手是网络排查的第一原则。1.2 网上最佳实践为什么不能直接抄现在搜索Linux网络性能优化很容易找到一大段现成的sysctl参数看着很专业但直接抄到自己的机器上很可能翻车。我见过一个案例有人照着脚本把tcp_tw_recycle打开结果网络出口做了NAT线上客户端瞬间出现大量连接失败半夜灰溜溜回滚。这个参数在较新的内核里已经被移除了因为它在大规模网络环境下带来的问题远大于收益。另一个容易翻车的是无限调大Socket缓冲区。tcp_rmem/tcp_wmem的第三个值是上限看着诱人但连接数到了几十万时每个连接只要稍微逼近max内存就会以肉眼可见的速度消耗。正确做法是结合并发连接数、延迟和带宽来计算而不是打开一个越大越好的开关。盲目复制配置的本质问题是你根本不知道每个参数解决什么问题也不知道当前瓶颈在哪。所以我的原则是先量化问题再选参数。后面所有章节都围绕这个原则展开。监控工具是量化问题的手段抓包是确认问题根因的手段调参只是最后临门一脚。2. 内核网络参数调优哪些sysctl值得动哪些别乱碰2.1 连接建立的入口SYN队列与accept队列在Linux中TCP连接建立会经过两个队列。客户端SYN到达后先进入半连接队列也就是SYN队列三次握手完成后连接进入全连接队列也就是accept队列等待应用调用accept()取走。这两个队列都有上限超出后内核会丢弃新连接表现就是客户端连续SYN重传或者连接直接收到RST。相关的参数有三个但很多人只记住了一个net.core.somaxconnaccept队列上限默认值因发行版而异有的128有的4096。应用调用listen(fd, backlog)时实际队列长度取backlog和somaxconn的较小值。很多应用框架默认的listen backlog很小即使你这边把somaxconn调到一万应用侧不放大也没用。net.ipv4.tcp_max_syn_backlogSYN队列上限默认通常是1024或4096高并发场景可以调到4096以上。net.core.netdev_max_backlog网卡收包后协议栈来不及处理的积压上限默认1000。高PPS场景建议调大但需要结合RPS和软中断情况一起看。怎么判断队列溢出最简单的办法是看监听Socket的积压情况# 查看监听队列积压Recv-Q 持续接近 Send-Q ss -lnt # 直接看协议栈累计溢出次数 netstat -s | grep -i listen queue如果某个服务的Recv-Q长期顶着Send-Q说明应用处理连接的速度跟不上建连速度。这时候优先排查应用为什么慢比如线程池不够、fd耗尽、accept循环效率低然后再考虑加大队列。队列加大只是缓冲治标不治本。我见过有人把somaxconn调到65535问题反而更严重因为积压的连接把内存吃光了应用根本来不及处理。2.2 吞吐量瓶颈TCP缓冲区与带宽时延积高带宽业务调完参数后吞吐还是上不去十有八九是Socket缓冲区小于BDP。BDP就是网络管道的容量计算公式是带宽 × 往返时间RTT。举个例子一条10Gbps的链路RTT是50ms管道里能承载的数据量是10×10⁹ × 0.05 ÷ 8 62.5MB。如果发送缓冲区只有默认的几百KB发送窗口再大也填不满管道实际吞吐会被限制在窗口大小除以RTT附近。对应参数是net.ipv4.tcp_rmem和net.ipv4.tcp_wmem每个都有三个值分别代表最小、默认、最大sysctl -w net.ipv4.tcp_rmem4096 131072 6291456 sysctl -w net.ipv4.tcp_wmem4096 16384 6291456min是每个连接至少分配的下限default是初始默认值max是上限。Linux实际会根据压力和内存自动调整并不代表所有连接都会占满max。但你要心里有数如果连接数很多一个连接几MB乘起来总内存会非常可观。可以用ss -m看当前Socket实际内存占用。另外大缓冲区会放大延迟。发送缓冲区里堆积大量数据时一个报文丢了重传恢复的时间变长应用层感知的延迟可能上升。所以追求超低延迟的场景缓冲区不能一味贪大。这也解释了为什么有些参数在A业务上是珍宝在B业务上就是毒药。2.3 TIME_WAIT与端口资源调优前先想清楚TIME_WAIT是主动关闭连接的一方会停留的状态持续2MSL通常60秒。短连接一多TIME_WAIT连接可能成千上万。它本身不是多大的问题除非内存或端口不够。很多人习惯调小tcp_fin_timeout实际上这个参数只影响FIN_WAIT_2状态和TIME_WAIT没有直接关系。真正的关联参数是net.ipv4.tcp_max_tw_buckets超过这个数量后内核会加快清理TIME_WAIT连接。tcp_tw_reuse经常被误解。它可以在发起新的出站连接时复用TIME_WAIT连接前提是开启了tcp_timestamps而且对入站连接无效。它的作用是解决客户端高并发短连接时端口枯竭的问题不是服务端的银弹也不会让TIME_WAIT数量凭空消失。比TIME_WAIT更值得关注的其实是源端口范围sysctl -w net.ipv4.ip_local_port_range1024 65535默认范围通常从32768到60999也就3万个可用端口。如果某个客户端到同一服务端的短连接每秒超过这个量级就会出现Cannot assign requested address表现为连接建立失败。调大端口范围立竿见影但也要留意和系统保留端口冲突。说句实在话TIME_WAIT的最佳解决方案是少创建短连接用连接池或长连接内核参数只是兜底手段。2.4 中断要多队列让收包能力跟上流量很多人只盯软硬件参数忽略网卡中断。现在主流网卡都支持RSS多队列理论上可以将网络包分散到多个CPU处理但如果队列和中断没有绑好流量会全部压在一个核上。判断方法很简单高流量时看top里的si软中断是不是单核打满再看/proc/interrupts里各网卡中断号在CPU上的分布。# 查看网卡中断分布 cat /proc/interrupts | egrep eth0|CPU # 调整网卡队列数量需要驱动和硬件支持 ethtool -L eth0 combined 4 # 查看当前队列配置 ethtool -l eth0如果网卡不支持RSS也可以启用RPS让内核通过哈希将收包分发到多个CPU软中断配置路径在/sys/class/net/eth0/queues/rx-*/rps_cpus。但RPS会增加CPU开销适合网卡队列少而CPU核数多的场景。还有一个常见默认值很保守的参数是net.core.netdev_max_backlog。如果协议栈处理不过来这个队列就会丢包。我见过一个网关机把它从1000调到3000掉包率肉眼可见下降原因就是网卡队列和协议栈终于能缓冲更多突发包。这一节的落点是内核网络优化是系统性工程参数会互相影响。改一个参数之前先问自己我要解决的是建连积压、吞吐带宽、连接耗尽还是包处理能力不同目标对应不同参数。3. 网络监控工具组合拳用ss/sar/iftop/ethtool定位问题层级3.1 连接状态分布把ss用出花ss是netstat的现代替代品输出更快、信息更全。拿到一台网络有问题的机器我第一件事是看ss -sss -s它会显示总连接数以及TIME_WAIT、SYN_RECV、ESTAB等状态的数量。SYN_RECV如果暴涨说明有大量新连接在排队可能是CPU处理不过来也可能遭受SYN洪水CLOSE_WAIT在上升说明业务代码没有及时关闭对端关闭的连接TIME_WAIT数量高如果配合的是短连接场景一般不用太惊慌。看具体连接用ss -antp | grep :8080-p可以带出进程名和PID方便直接锁定是哪个应用在维持连接。-lnt看监听Socket时Recv-Q是当前accept队列积压的连接数Send-Q是backlog上限两个数一对比队列溢出立刻现形。我不太推荐再回去记一堆netstat参数ss的语法更直观。但netstat -s仍然有用因为内核协议栈的累计计数很全比如重传率、listen队列溢出次数、丢弃的重复SYN这些都是历史证据。如果只看瞬态你很可能错过一个只在某秒出现的丢包瞬间。3.2 趋势与瞬时sar和iftop的配合监控网络问题只有瞬时快照永远不够。sar -n DEV 1 5可以每秒采样一次网卡流量连续5秒既能看速率也能看pps。真正定位问题的时候我喜欢翻带时间戳的历史sar记录对比异常时刻前后的流量趋势。很多故障是两点多流量突增导致的没有历史数据就只能靠猜。# 查看历史某天网卡数据 sar -n DEV -f /var/log/sa/sa$(date %d) # 查看TCP层的连接数与重传 sar -n TCP,ETCP 1 5前一条命令翻历史网卡数据后一条看TCP层统计包括每秒新建连接、重传数、当前连接数。如果重传率从0.1%跳到5%高度怀疑链路丢包或TCP缓冲区不足。再说iftop它适合查谁在占用带宽这类问题。iftop -i eth0 -nP可以在终端实时列出各连接IP的收发速率按流量排序。遇到内网某两台机器之间流量异常或者某个IP疯狂下载导致拥塞用它最快。一个组合套路是先用sar确认问题出现的时间窗口和粒度再用iftop锁定连接方向最后用ss确认是哪些端口/进程层层缩小范围。3.3 网卡层与驱动层ethtool把玻璃擦亮有时候应用层和协议栈看起来都正常但网络就是不稳定那就要往下看网卡。ethtool eth0看速率和双工是否正常ethtool -S eth0是一堆计数器重点看这几个rx_dropped驱动或硬件丢包。rx_missedDMA ring满导致的丢包。rx_no_buffer内存不足或ring buffer不够。rx_crc_errors链路层错误通常暗示网线或对端网卡有问题。tx_dropped发送失败可能和交换机或流量控制有关。很多人看到rx_dropped就会说丢包了其实不一定致命。要算比例如果每秒收100万包丢了100个占比万分之一通常可以无视如果持续增长且占比超过0.1%就要处理。处理套路是ethtool -G eth0 rx 4096 tx 4096增大ring buffer再观察drop是否下降。还不行可能驱动有bug看看固件版本。到这里我们已经有了完整的工具链ss看连接状态sar看趋势iftop看实时流量ethtool看网卡健康。下一步是真正到协议层里去看请求是怎么一步步走完的。4. 请求分析的关键证据tcpdump抓包与TCP状态机解读4.1 抓包前心里要有数如果说前面的工具是体检报告tcpdump就是显微镜。线上抓包不是随便跑一条命令就完事抓不好反而干扰判断。我通常这样抓tcpdump -i eth0 -nn -s 0 -B 4096 -c 100000 -w /tmp/cap.pcap host 10.0.0.5 and tcp port 8080-i选网卡-nn不要反解域名和端口-s 0抓完整帧-B把内核抓包缓冲区调到4MB避免高流量下丢包-c限定抓10万包防止文件爆炸最后的BPF过滤帮你只关心目标流量。文件别直接丢在/tmp有时候/tmp挂载会影响写入速度我会放到专门的磁盘路径。如果担心抓包本身影响业务可以只抽样-c 50000抓完就停或者抓完快速回放判断。抓包是CPU密集操作生产环境尽量短平快。抓完先做一层快速检查用capinfos看pcap基本信息或者直接tcpdump -r回放过滤。如果抓包文件里一半是乱序和重传问题基本就坐实在网络层而不是应用层。4.2 三次握手与重传的时间线拿到抓包文件第一眼看三次握手。正常流程是客户端发SYN到服务端服务端回SYN/ACK客户端回ACK完成握手。如果在客户端发出SYN后超过几十毫秒才看到SYN/ACK甚至看到客户端重发SYN间隔通常是1s、2s、4s、8s说明中间的包丢了或者服务端SYN队列溢出。这时候再回头看netstat -s里的listen queue overflow通常能对上。握手完成后的重传分析更复杂。Wireshark会自动标注TCP Retransmission、Spurious Retransmission、Out-of-Order、Zero Window、TCP Dup ACK这些事件。我的习惯是先用过滤器把所有异常事件拎出来统计tcp.analysis.retransmission tcp.analysis.fast_retransmission tcp.analysis.zero_window tcp.analysis.duplicate_ack看它们集中在哪个IP方向、哪个时间段。如果重传都发生在同一跳IP上说明链路层丢包如果集中在某一段时间说明那段时间有拥塞或网卡中断异常。如果某个TCP流里连续出现Zero Window说明接收端应用读取太慢发送方只能暂停。零窗口尤其要小心第一时间想到的是应用消费能力不足而不是网络丢包。4.3 一个模拟抓包复盘从重传到定位网卡瓶颈为了让你直观看到抓包的威力我复述一个典型的排查过程细节已经脱敏。模拟项目X运行在某机房某天上午10点开始接口P99从60ms涨到500ms高峰持续半小时。我先抓了30秒流量过滤出该接口IP和端口发现两个特征一是客户端发出的SYN在某个内网网段内出现了几次重传间隔约1s二是服务端返回数据时客户端频繁回复Dup ACK服务端触发了Fast Retransmission。再结合当天监控服务端机器在10点整的si软中断CPU使用率冲到接近100%/proc/interrupts显示两张网卡的中断都压在CPU0上ethtool -S里rx_dropped开始增长。到这里链条闭合了网卡中断不均衡导致单个CPU软中断丢包SYN和正常收包被随机丢弃客户端只能重传重传又加剧CPU压力形成一个恶性循环。处理办法不复杂把两张网卡的中断分别绑到CPU0和CPU1调整irqbalance为per-cpu再把ring buffer从256扩到2048。重新抓包后SYN重传消失P99回到60ms以内。如果没有抓包这一步看到P99高就盲目加大somaxconn问题会永远留在那里每次高峰期准时发作。5. 从调优到验证一套可复现的压测对比流程5.1 基线记录是硬指标调优最忌讳的是改完参数凭感觉说好像快了。正确做法是先记录完整基线。我的基线清单是这样的类别指标记录方式业务侧P50/P99延迟、吞吐QPS、错误率压测工具或监控系统侧平均负载、CPU使用率、si占比top/sarTCP侧连接状态分布、重传数、listen队列溢出ss/netstat网卡侧rx/tx丢包计数、ring buffer大小、中断分布ethtool内核侧所有涉及参数的原值sysctl -a每次压测开始前把这些记下来压测后同样采集一次。只有对比表才能告诉你某个参数到底带来多少收益而不是自我安慰。顺便提一句基线时间窗口单次30秒压测往往不够至少跑3轮每轮持续5分钟看趋势稳定性。如果结果在抖动说明压测方式本身有问题参数调优要往后放。5.2 每次只改一组并且保证能回滚一组参数改完压测一轮记录结果再改下一组。不要一次把所有参数都配上出了问题你根本不知道是哪一行引起的。这是我在蹚过浑水后最深刻的教训。# 保存当前配置 sysctl -a /tmp/sysctl.bak # 临时生效测试 sysctl -w net.core.somaxconn10240 # 压测后对比满意则写配置文件 echo net.core.somaxconn10240 /etc/sysctl.conf sysctl -p临时生效参数在重启后会丢失适合A/B稳定后再持久化。回滚也很简单从备份恢复或者删掉sysctl.conf里新增行再sysctl -p。如果是在生产环境最好写成脚本保留每次变更的原因、时间、操作人和前后指标能省去很多扯皮。5.3 让优化可持续告警与定期复查建议把网络关键指标都接进监控并设置合理的告警阈值。我个人比较看重这几个TCP重传率超过1%持续5分钟ss -lnt监听队列积压持续超过50%ethtool -S里的rx_dropped/rx_missed持续增长top里si占比超过80%持续10分钟。这些指标比单纯的带宽使用率更能体现网络健康的真相。带宽高不一定有问题但重传率高、软中断打满、队列溢出通常意味着资源已经到了极限。最后提醒一句Linux内核参数不是一劳永逸的配置业务流量模型、机器规格、网卡驱动都会变。建议每季度抽时间重新拉一次基线和参数清单看看有没有过时或不再适用的项。网络优化是一个持续的循环参数调优、监控、抓包三者缺一不可。写了这么多最后分享一点个人感受每次调网络参数我都默认自己是最不懂的那个人先用监控和抓包把问题缩小到最小范围再动刀。tcpdump和ethtool的输出看起来冷冰冰但它们比任何所谓的最佳实践都诚实。希望这套从参数调优到请求分析的思路能让你下次面对网络性能问题时少一点急于改参数的冲动多一点按图索骥的笃定。