CentOS 6.5 作为一个经典的操作系统版本，尽管已进入生命周期末期（EOL），但在许多遗留环境中仍在稳定运行，对于承载关键业务的服务器而言，对其进行合理的网络优化，以挖掘其最后潜力，依然具有重要的现实意义，本文旨在系统性地介绍针对 CentOS 6.5 的网络优化策略，涵盖内核参数、网卡配置、系统限制等多个层面，力求为系统管理员提供一份详实、可操作的参考指南。
在进行任何优化操作之前,必须强调：所有更改都应在测试环境中充分验证，并记录原始配置，以便在出现问题时能够快速回滚，优化是一个持续的过程，而非一次性的任务，需要结合业务实际流量和性能监控数据进行动态调整。
内核参数调优
Linux 内核提供了丰富的网络协议栈参数，通过调整这些参数可以显著提升网络性能和并发处理能力，这些参数主要集中在 /etc/sysctl.conf 文件中，修改后，使用 sysctl -p 命令使其立即生效。
以下是一些关键的优化参数及其建议值,适用于高并发连接的场景：
| 参数 | 推荐值 | 说明 |
|---|---|---|
net.ipv4.tcp_tw_reuse |
1 | 允许将TIME_WAIT状态的 sockets 重新用于新的TCP连接，对于高并发服务器，能有效减少TIME_WAIT套接字数量。 |
net.ipv4.tcp_tw_recycle |
0 | （谨慎使用） 快速回收TIME_WAIT套接字，但在NAT环境下可能导致连接异常，通常建议设为0，依赖tcp_tw_reuse。 |
net.ipv4.tcp_syncookies |
1 | 开启SYN Cookies功能，当SYN队列溢出时，通过Cookies方式处理SYN请求，有效防范SYN Flood攻击。 |
net.core.somaxconn |
4096 | 定义了监听队列的最大长度，对于高并发应用（如Nginx、Tomcat），应适当调大此值，避免连接请求被丢弃。 |
net.ipv4.tcp_max_syn_backlog |
8192 | 记录那些尚未收到客户端确认信息的SYN请求队列的最大长度，与somaxconn配合，提升抗SYN Flood能力。 |
net.ipv4.tcp_fin_timeout |
15 | TCP连接在FIN-WAIT-2状态的超时时间，适当减小可以加快资源回收。 |
net.core.rmem_max |
16777216 | 接收套接字的缓冲区最大值（字节）。 |
net.core.wmem_max |
16777216 | 发送套接字的缓冲区最大值（字节）。 |
net.ipv4.tcp_rmem |
4096 87380 16777216 | TCP接收缓冲区的最小、默认、最大值。 |
net.ipv4.tcp_wmem |
4096 65536 16777216 | TCP发送缓冲区的最小、默认、最大值。 |
操作示例：
将上述参数追加到 /etc/sysctl.conf 文件末尾，然后执行 sysctl -p 即可，增大缓冲区可以提升数据吞吐量，但也会消耗更多内存，需根据服务器实际情况权衡。
网卡队列与中断优化
现代服务器通常配备多核CPU和多队列网卡,合理配置它们可以极大提升网络处理效率。
-
开启多队列（RSS）： 多队列网卡可以将网络流量分散到多个硬件接收队列，再由不同的CPU核心处理，避免单一核心成为瓶颈，可以使用
ethtool命令查看和设置。
# 查看当前网卡队列数 ethtool -l eth0 # 设置网卡队列数（设置为CPU核心数） ethtool -L eth0 combined 4
注意：此设置需要网卡驱动支持，且重启后可能失效，需将其写入开机启动脚本。
-
绑定中断亲和性： 默认情况下，网卡中断可能由CPU 0处理，导致其负载过高，可以将中断均匀地分配到各个CPU核心。 查看网卡对应的中断号：
cat /proc/interrupts | grep eth0
将中断号（如45）绑定到指定的CPU核心（如CPU 2和3，掩码为1100二进制，即C十六进制）：
echo C > /proc/irq/45/smp_affinity
同样,此操作也需要写入脚本以实现开机自动配置。
文件描述符与连接数限制
在高并发场景下,每个TCP连接都会消耗一个文件描述符，CentOS 6.5 默认的 ulimit 值（通常为1024）往往不够用，需要手动调高。
编辑 /etc/security/limits.conf 文件，在末尾添加以下内容：
* soft nofile 65535
* hard nofile 65535这表示将所有用户的软限制和硬限制都设置为65535,修改后，用户需要重新登录才能生效，可以通过 ulimit -n 命令验证是否设置成功。
其他优化建议
- DNS解析优化：确保
/etc/resolv.conf中配置了响应速度快、稳定的DNS服务器，如公共DNS（114.114.114.114或8.8.8.8），可以减少域名解析带来的延迟。 - 精简防火墙规则：
iptables规则越复杂，数据包处理的延迟就越高，定期审查并优化规则，减少不必要的模块和跳转，可以提升转发效率。 - 保持系统时间同步：使用
ntpd服务确保服务器时间准确，这对于日志分析和分布式系统协同至关重要。
相关问答 (FAQs)
问题1：为什么我的服务器在按照上述步骤优化后，性能提升并不明显，甚至没有变化？
解答：网络优化是一个系统性工程，瓶颈可能不在网络层面，需要确认服务器的实际瓶颈所在，可以使用 top, vmstat, sar, iftop 等工具进行监控，分析是CPU、内存、磁盘I/O还是应用程序本身的问题，如果应用程序是单线程的，那么多核CPU的优势就无法发挥，如果磁盘I/O已经饱和，那么网络再快也无济于事，优化参数的值并非一成不变，需要根据实际的业务负载（如长连接多还是短连接多）进行针对性调整，优化后没有效果，很可能是因为当前瓶颈并非网络，或者参数调整未触及真正的瓶颈点。
问题2：tcp_tw_recycle 参数在网上看到很多推荐开启，但你的表格里建议设为0，这是为什么？
解答：这是一个非常好的问题，也反映了网络优化的复杂性。tcp_tw_recycle 的设计初衷是快速回收处于TIME_WAIT状态的连接，以释放系统资源，在纯粹的服务器对服务器或客户端对服务器的环境中，开启它确实能带来好处，在存在NAT（网络地址转换）的环境中，开启 tcp_tw_recycle 会引发严重问题，NAT设备会修改来自不同内网主机的连接的源端口，当这些连接到达开启了tcp_tw_recycle的服务器时，服务器可能会因为时间戳校验问题而错误地丢弃来自同一NAT设备后的其他正常连接，导致连接随机失败或超时，现代网络环境几乎处处是NAT（如公司网关、云服务器的浮动IP等），为了系统的稳定性和兼容性，强烈建议将 tcp_tw_recycle 设置为0，转而使用更安全的 tcp_tw_reuse 来复用TIME_WAIT连接。