本文根据一些文档中的网络调优建议，以及本人在日常运维中积累的一些经验，提出了在多个方面对Linux的网络进行优化的一些建议，或许能够进一步的改善Linux的网络吞吐与并发性能。
一、Linux内核调优
为了让系统能够支持更大的并发，优化linux内核是重中之重，通过对Linux内核中有关网络的一些参数的修改，能够整体的提升网络性能。
打开文件 /etc/sysctl.conf，增加以下设置
#该参数设置系统的TIME_WAIT的数量，如果超过默认值则会被立即清除 net.ipv4.tcp_max_tw_buckets = 20000 #定义了系统中每一个端口最大的监听队列的长度，这是个全局的参数 net.core.somaxconn = 65535 #对于还未获得对方确认的连接请求，可保存在队列中的最大数目 net.ipv4.tcp_max_syn_backlog = 262144 #在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目 net.core.netdev_max_backlog = 30000 #能够更快地回收TIME-WAIT套接字。此选项会导致处于NAT网络的客户端超时，建议为0 net.ipv4.tcp_tw_recycle = 0 #系统所有进程一共可以打开的文件数量 fs.file-max = 6815744 #防火墙跟踪表的大小。注意：如果防火墙没开则会提示error: "net.netfilter.nf_conntrack_max" is an unknown key，忽略即可 net.netfilter.nf_conntrack_max = 2621440
运行 sysctl -p 即可生效。
说明：
/etc/sysctl.conf 可设置的选项很多，其它选项可以根据自己的环境需要进行设置
同时需要注意的是，有些IDC（如腾讯云、阿里云）的原始Linux系统镜像中，已经添加了一些优化参数，或许上述的配置文件中有重复的地方，要根据实际情况进行覆盖或修改。
二、最大打开文件数参数的优化
在Linux下，高并发的情况下有时会遇到“Can't open so many files”或者“too many open files”的问题，这是因为Linux默认的句柄限制值一般在1024，也就是说你不能打开超过1024个文件。通过修改系统打开文件参数设置，能够解决高并发下的生产环境中容易遇到的这个瓶颈。
Soft open files 是Linux系统参数，影响系统单个进程能够打开最大的文件句柄数量，这个值会影响到长连接中单个进程能够维持的用户连接数， 运行ulimit -n能看到这个参数值，如果是1024，就是代表单个进程只能同时最多只能维持1024甚至更少（因为有其它文件的句柄被打开）。如果开启4个进程维持用户连接，那么整个应用能够同时维持的连接数不会超过4*1024个，也就是说最多只能支持4x1024个用户在线。可以通过增大这个设置以便服务能够维持更多的TCP连接。
修改Linux系统中最大打开文件数的参数，主要有以下的几种办法：
（1）ulimit -HSn 102400
在终端中执行这个命令后，再次执行 “ulimit -n” 命令进行查询，可以看到最大打开文件数已经修改为102400。但是这个修改是临时的，只会在当前终端有效，退出之后，open files limit 又变为默认值。
（2）在/etc/profile文件末尾添加一行ulimit -HSn 102400
这样每次登录终端时，都会自动执行/etc/profile中的这条命令，修改文件数。
（3）要想硬性地使得最大打开文件数的修改永久生效，不用每次重新设置，可以通过修改配置文件的方式来实现。
在 /etc/security/limits.conf 这个文件最后加上如下的参数即可：
* soft nofile 1024000 * hard nofile 1024000 root soft nofile 1024000 root hard nofile 1024000
需要注意的是，这种方法需要重启机器才能生效。
三、使用TCP BBR 拥塞控制算法
Google 开源了其 TCP BBR 拥塞控制算法，并提交到了 Linux 内核，从 4.9 开始，Linux 内核已经用上了该算法。使用BBR算法在内核级别上改善网络的收发性能，Titan笔记所在的服务器也默认开启了BBR。
BBR的类型有很多种，有Linux内核的官版BBR，也有民间大佬的各种修改与改进版，如@cx9208编译的基于@dog250提供的思想的bbrplus，@Yankee优化的bbr等等。但是，这些第三方修改参数的内核在不同的网络条件，不同的地区，甚至不同的服务器配置上将会有着不同的表现，或许不能保证在任何条件下都能有着平稳的性能提升，因此，我个人建议还是直接开启官版的BBR为好。
但是，也有人对开启BBR与否提出了不同的观点，认为Web服务器开启BBR会造成TTFB延时而拖慢访问速度的情况。但是在我的长期使用过程中，不同地区的开启BBR的服务器都比使用传统CUBIC算法的服务器有着些许的网络性能提升的表现，我认为这可能是一个特例。当然，在生产环境中，还是应该根据具体的情况来决定是否开启BBR，不过想想谷歌都用了好多年了，何必那么担心呢？
Linux一键安装最新内核并开启 BBR 脚本
这里提供@Teddysun大佬提供的一键安装最新内核并开启 BBR 的脚本。
本脚本适用环境
系统支持：CentOS 6+，Debian 8+，Ubuntu 16+
虚拟技术：OpenVZ 以外的，比如 KVM、Xen、VMware
内存要求：≥128M
日期 ：2020 年 6 月 23 日
关于本脚本
1、本脚本已在自己的 VPS 上全部测试通过。
2、当脚本检测到 VPS 的虚拟方式为 OpenVZ 时，会提示错误，并自动退出安装。
3、脚本运行完重启发现开不了机的，打开 VPS 后台控制面板的 VNC, 开机卡在 grub 引导, 手动选择内核即可。
4、由于是使用最新版系统内核，最好请勿在生产环境安装，以免产生不可预测之后果。
使用方法
使用root用户登录，运行以下命令：
wget --no-check-certificate -O /opt/bbr.sh https://github.com/teddysun/across/raw/master/bbr.sh chmod 755 /opt/bbr.sh /opt/bbr.sh
安装完成后，脚本会提示需要重启 VPS，输入 y 并回车后重启。
重启完成后，进入 VPS，验证一下是否成功安装最新内核并开启 TCP BBR，输入以下命令：
uname -r
查看内核版本，显示为最新版就表示 OK 了
sysctl net.ipv4.tcp_available_congestion_control
返回值一般为：
net.ipv4.tcp_available_congestion_control = bbr cubic reno
或者为：
net.ipv4.tcp_available_congestion_control = reno cubic bbr
sysctl net.ipv4.tcp_congestion_control
返回值一般为：
net.ipv4.tcp_congestion_control = bbr
sysctl net.core.default_qdisc
返回值一般为：
net.core.default_qdisc = fq
lsmod | grep bbr
返回值有 tcp_bbr 模块即说明 bbr 已启动。注意：并不是所有的 VPS 都会有此返回值，若没有也属正常。
文章评论