Linux服务器网络性能调优：从内核参数到BBR的实战指南

我做了几年Linux服务器运维，经手过不少业务上线前的网络调优，也踩过一些现在回头看很基础的坑。有时候业务方反馈“接口慢”“下载速度上不去”“连接时不时超时”，第一反应是加带宽、换机器，但其实很多时候问题出在系统默认的网络参数上。Linux默认配置偏向“保守兼容”，而不是“高性能”，尤其是对服务器这种高并发、大流量场景，默认值往往不够用。这篇文章从基础参数讲到进阶优化手段，既适合刚接触服务器运维的新手，也适合已经能熟练处理日常业务、想系统性提升网络性能的同学。我尽量把每个参数为什么这么调、调整后有什么效果、实测会有什么变化都讲清楚，方便你直接照着参考。

1. 网络优化前必须想清楚的三件事

1.1 先定目标再动手：延迟、吞吐、还是并发？

很多教程上来就贴一串sysctl参数让人照着改，这是不负责任的。网络优化第一件事是想清楚业务的目标究竟是哪种。

延迟敏感型场景，比如实时通信、RPC调用、数据库读写，核心指标是往返延迟RTT，这时候要关注TCP_NODELAY、快速打开、拥塞控制算法的选择，避免因为Nagle算法和延迟ACK导致的小包积压。吞吐敏感型场景，比如视频点播、文件传输、CDN回源，核心指标是带宽利用率和窗口大小，这时候要调整TCP缓冲区、窗口缩放、队列长度，让数据能够尽量“装满管道”。高并发短连接场景，比如Web服务、API网关，核心指标是每秒新建连接数和端口复用率，这时候要关注文件描述符上限、TIME_WAIT状态连接的处理、syn backlog队列长度。

如果不区分场景就盲目调参数，可能出现吞吐优化让延迟变差，或者并发优化导致连接不稳定。我见过有人在延迟敏感的业务上开了BBR，结果小包场景反而抖动更明显，因为他没意识到BBR更适合大带宽、长肥网络。先定义目标，后面所有操作才有评估标准。

1.2 基线数据是唯一标准：优化前先测量

没有基线数据就谈不上优化。很多时候你觉得网络慢，只是“感觉”，没有数据支撑，改完也不知道有没有效果。优化之前一定要先量化，把优化前的指标记录下来，再和优化后的数据进行对比。

最常用的是iperf3测吞吐，命令很简单：

bash复制# 服务端
iperf3 -s -p 5201

# 客户端，测10秒并输出结果
iperf3 -c <服务端IP> -p 5201 -t 10

测延迟用ping统计RTT，测并发可以用wrk或者ab压一下本机端口应用。另外要记录系统层面的监控数据，比如用sar -n DEV 1观察网卡吞吐量和丢包率，用ss -s查看当前socket状态统计，用mpstat -P ALL 1看CPU软中断分布。这组数据就是你的“出发起点”，没有它，后面调优很容易变成玄学。

我习惯把优化前的数据存成一个文本文件，比如baseline_network.txt，里面放吞吐、延迟、重传率、socket连接数分布、软中断CPU占用等关键指标。后续每做一项调整，都回到相同场景重新测一遍，对照基线才能确认每项改动到底带来了什么。

1.3 了解瓶颈在哪一层：硬件、内核、还是应用？

网络链路是一条完整的管道，从物理网卡、驱动、内核协议栈、socket接口到应用程序，每一层都可能成为瓶颈。优化前先定位瓶颈层，否则容易做无用功。

硬件层瓶颈的典型表现是网卡利用率长期接近100%，但CPU占用不高，或者ethtool看到大量rx_dropped丢包。这种情况要考虑升级网卡、调整队列、启用硬件卸载特性。内核层瓶颈的表现是CPU软中断占用高、socket队列堆积、重传率高，这时候调内核参数才有意义。应用层瓶颈表现为网卡和内核利用率都不高，但业务响应就是慢，比如连接池设置太小、线程阻塞、业务代码里做了串行请求，这时候调系统参数纯属隔靴搔痒。

区分方法也很简单：用top看CPU使用率分类，如果sy和si（内核态和软中断）占比高，问题在内核协议栈。用ss -lnt看accept队列是否溢出，用ethtool -S eth0看rx_dropped、tx_dropped等计数器，这些指标能快速告诉你瓶颈大致位置。

提示：优化动作要一次只改一个变量，改完立即验证，否则多个参数混在一起改，出了问题你根本不知道是哪个参数导致的。

2. 基础层：内核网络参数调优，把默认值改成适合服务器的样子

2.1 文件描述符与连接队列：撑住高并发的前提

Linux里一切皆文件，socket也是文件，所以文件描述符上限直接决定了服务器能同时维持多少连接。默认的1024上限平时够用，一旦并发一上来马上会报“Too many open files”。

检查当前上限：

bash复制ulimit -n
# 临时调大
ulimit -n 655350

永久修改在/etc/security/limits.conf里加：

code复制* soft nofile 655350
* hard nofile 655350

这只是第一步。真正容易被忽略的是连接队列。TCP三次握手过程中，请求先进入syn队列（半连接队列），完成握手后进入accept队列（全连接队列）。如果accept队列满了，新的连接会被内核丢弃，客户端表现就是“连接超时”或“连接被重置”。

查看accept队列溢出：

bash复制ss -lnt

如果看到`Send