[tcp] WEB服务,Linux下的内核参数调优

青叶

前言:
web类应用一般会部署像nginx、tomcat、php等应用程序,使用默认的内核参数设置满足大部分场景,如果优化内核参数,也可以释放不少服务器性能,尤其是在高并发下

一.SYN状态的内核参数调优

大量SYN_SENT
这种是主动连接服务端,而未得到响应,也就是SYN超时,一般是服务端根本不存在或者无法访问
如,我随便telnet一个位置的IP和端口

telnet 172.18.11.110:90
[root@test bbs]# ss -an|grep SYN
SYN-SENT   0      1            172.16.196.145:55052        172.18.11.110:90

除了以上,还有种就是你的服务出现异常,比如mysql服务器宕机了,web服务去访问mysql数据库的时候就连不上,也会出现SYN_SENT状态,但无论哪种,都是主动发起连接导致的,因此业务上解决更好

net.ipv4.tcp_syn_retries = 2
新建连接如果无响应,内核要发送多少次SYN连接才放弃,默认值为5

在Linux下,默认重试次数为5次,该值不能大于255,重试的间隔时间从1s开始每次都翻倍(因为隔一秒重试后还会等待响应,因此实际上是从3秒开始),5次的重试时间间隔为3s, 7s, 15s, 31s, 63s,总共63s,TCP才会把断开这个连接。统计成公式2^(n+1) - 1,因此设置越大,翻倍越多,对应内网环境,这个值修改为2比较合适

大量SYN_RECV
大量的SYN出现有两种情况,可能是攻击,也可能是正常的业务请求,无论哪种,都大量的占用了服务器资源

net.ipv4.tcp_synack_retries = 2
跟参数net.ipv4.tcp_syn_retries一样,只是这个内核参数是控制回应SYN失败的重试次数,默认值也是5,和上面一样修改为2

其他内核参数调整
net.ipv4.tcp_syncookies = 1
开启SYN cookies,当出现SYN等待队列溢出时,启动cookies来处理

什么是SYN cookies?我们知道SYN攻击是一系列伪造IP源地址的SYN包,IP地址是随意选择且不提供攻击者任何的线索,SYN攻击持续直到服务的SYN队列被用满。如果启用该参数,此时SYN cookies会将TCP请求的SYN缓存起来,当服务器正常的时候,再处理,但是如果攻击并发很高很大,其实用处不大,因此只能少量防范

SYN cookies可参考:https://blog.csdn.net/chenmo1...

net.ipv4.tcp_max_syn_backlog = 65535
指定所能接受SYN同步包的最大客户端数量,即半连接上限,默认值为128,对于web服务,频繁大量的SYN同步包,应该放大这个值

注:这个值应该>=net.core.somaxconn,net.core.somaxconn后面会提到

二.FIN_WAIT_2状态的内核参数调优

FIN_WAIT_2是主动关闭端等待对端关闭连接的状态,如果被动关闭不发送FIN关闭连接,那么这个状态就会一直存在,当然Linux有针对该状态的超时时间,默认为60秒

net.ipv4.tcp_fin_timeout = 10

三.TIME_WAIT状态的内核参数调优

TIME_WAIT是主动关闭端的状态,也称为2MSL等待状态,也就是2倍的MSL时间。在RFC 793[Postel 1981c]指出MSL为2分钟,然而现实中的常用值是30秒,1分钟或者2分钟(Linux设置为30秒),Linux也没有提供能够修改TIME_WAIT状态时间的接口,除非重新编译系统内核

MSL的理解
MSL是英文Maximum Segment Lifetime的缩写,翻译为"最长报文段寿命",每个具体TCP实现必须选择一个报文段最大生存时间(Maximum Segment Lifetime),而这个最大生存时间是任何报文段被丢弃前在网络内的最长时间

MSL的时间是有限的,因为TCP报文段以IP数据报在网络内传输,而IP数据报则有限制其生存时间的TTL(time to live)字段,TTL可译为生存时间,IP数据报每经过一个路由器,它的值就减1,当这个值为0时,数据报则被丢弃

为什么等待2MSL
1.确保有足够的时间让服务端收到ACK,如没有收到,则会响应对方新的FIN+ACK封包。比如主动关闭端(客户端)发送了最后一个ACK报文段给被动关闭端(服务端),但这个ACK报文段有可能丢失,如果服务端没有收到这个ACK,那么处于LAST_ACK的服务端在超时后回重发FIN+ACK报文段,这样客户端就能在2MSL时间内收到这个重发的FIN+ACK报文段。如果客户端发送了最后的ACK报文不进入TIME_WAIT而是立即释放连接,那么就无法收到客户端重发的FIN+ACK报文段。因此等待2MSL是为了更安全的断开连接

2.有足够的时间让处于TIME_WAIT状态的连接不会跟后面的连接混在一起。比如一些延迟的包发过来,但是如果没有TIME_WAIT,那么就发到了新连接上,这样就混为一团,而如果是TIME_WAIT,则会丢弃这些延迟的包

等待2MSL的缺点
TCP连接在2MSL等待期间,这个处于TIME_WAIT状态的连接(客户端的IP地址和端口编号,服务器的IP地址和端口号)不能再被使用,它只能在2MSL结束后才能再被使用,而这些TIME_WAIT状态占用大量服务资源,对于web服务来说是不合理的

修改内核参数防止因为2MSL导致TIME_WAIT过多
对于web服务器,由于我们需要经常去连接mysql、redis或者一些RPC调用等,会有大量的主动关闭状态(TIME_WAIT),因此可以修改内核参数限制TIME_WAIT的数量

net.ipv4.tcp_max_tw_buckets = 20000
限制timewait 的数量,防止大量timewait导致系统负载升高,一旦达到限定值,则强制清理TIME_WAIT状态的连接并在打印系统日志(time wait bucket table overflow),该参数官方文档说明主要用来对抗DDos攻击

net.ipv4.tcp_tw_recycle= 1
启用timewait快速回收

net.ipv4.tcp_timestamps = 0
时间戳,0关闭,1开启。不能和net.ipv4.tcp_tw_recycle参数同时开启,因为一旦开启net.ipv4.tcp_tw_recycle,服务器就会检查包的时间戳,如果对方发来的包的时间戳是乱跳或者说时间戳是滞后的,这样服务器就不会回复,服务器会把带了"倒退"的时间戳包当作是"recycle"的tw连接的重传数据,不是新的请求,于是丢掉不回包,就容易出现syn不响应

net.ipv4.tcp_tw_reuse = 1
开启重用,允许将TIME-WAIT sockets 重新用于新的TCP 连接

TIME_WAIT总结
其实TIME_WAIT是主动断开连接,所以如果让对方主动断开连接的话,那么这个TIME_WAIT问题就对方的了。所以如果这个问题出现过多,多从业务着手,比如HTTP服务,NGINX设置keepalive参数(浏览器会重用一个TCP连接来处理多个HTTP请求),然后让客户端断开连接,当然这个要设置好keepalive_timeout的超时时间,因为有些浏览器可能不会主动断开连接

而如果是主动连接mysql、redis等后端调用,可以考虑使用长连接来避免TIME_WAIT过多的问题

四.长连接(keepalive)的内核参数调整

Linux下,keepalive不是默认开启,也无内核参数控制,它需要在TCP的socket中单独开启,Linux内核影响keepalive的参数目的仅仅是探测TCP连接是否存活,然后处理异常连接

net.ipv4.tcp_keepalive_time = 120 单位秒,表示TCP连接在多少秒没有数据报文传输时启动探测报文,探测连接是否正常
net.ipv4.tcp_keepalive_intvl = 5 单位秒,前后探测报文之间的时间间隔
net.ipv4.tcp_keepalive_probes = 3 探测次数,超过设置后丢弃

五.TCP/UDP内存参数调整

(1)TCP内存使用设置

针对TCP socket buffer
net.ipv4.tcp_mem = 94500000 915000000 927000000
指定TCP内存的整体使用状况,单位为页。这3个值为TCP整体内存【低、压力、高】,在web服务中,放大这个值即可
第一个值tcp_mem[0]:当TCP全局分配的页数低于此数时,TCP不调整其内存分配
第二个值tcp_mem[1]:当TCP分配的内存量超过这个页数,进入内存压力模式,TCP调节内存消耗
第三个值tcp_mem[2]:TCP全局使用的最大页数分配,这个会值覆盖任何其他限制,如超过,所有的新的TCP的buffer(缓冲区)内存分配都会失败

其实我们可以设置这个值较大,只要不限制系统分配内存,然后以监控来应对内存问题,一般来说,根据业务所选配置,很难将内存耗尽,否则优化的就不仅仅是这个参数了

net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
上面两组参数表示单个TCP连接上的读写buffer(缓冲)内存上限,单位字节,这三个值分别为最小值、默认值(会覆盖rmem_default、wmem_default配置)、最大值

最小值:TCP socket的发送缓冲区(tcp_rmem)/接收缓冲区(tcp_wmem)的内存,默认1页(4K)

默认值:TCP socket使用的发送缓冲区(tcp_rmem)/接收缓冲区(tcp_wmem)初始大小,这个值会覆盖(net.core.wmem_default/net.core.rmem_default),一般设置要低于(net.core.wmem_default/net.core.rmem_default)这个值,默认值为16K

最大值:TCP socket使用的发送缓冲区(tcp_rmem)/接收缓冲区(tcp_wmem)的最大大小,这个值不会覆盖(net.core.wmem_max/net.core.rmem_max),默认为4M

这两个内核参数的设置主要是针对每一个TCP连接来说的,使用默认设置就差不多了,如果设置太大,单个TCP连接占用过多内存也是有问题的

什么是TCP读写buffer(缓冲)?
实际上,TCP连接所用内存的多少是由读写buffer大小决定,对读buffer来讲,当收到对端连接的TCP报文时,会导致读buffer内存增加,如果这个报文加上当前读buffer内存超过tcp_rmem[3]上限,那么该报文将被丢弃。只有当调用read、recv这样的方法读取TCP流时,读buffer内存就会减少,因此读buffer内存是一个动态变化的,用多少就分配多少buffer,如果这个连接空闲时,而用户进程已经把连接上收到的数据都消费了,那么读buffer使用的内存就为0了

对于写buffer也是一样的,在socket编程中,当调用send或者write时,就会造成写buffer增大,那么什么时候减少?就是当接收到对端TCP连接发来的ACK确认了报文成功发送时,写buffer就会减少,类似于我给你发一个文件,我先拷贝出来发给你,我确认你收到了,我就把这个源文件删除,以免占用空间,如果确认没收到,那么我会重发

所以读写buffer是一直不停变化的,那么怎样的场景会导致读写buffer达到上限呢?就读buffer而言,比如接收TCP对端报文,对端发了很多很多报文,我读取后无法及时读取(read和recv),导致读buffer堆积越来越多,最终达到上限,最后丢弃报文,写buffer也一样,send或者write大量的报文时,如果TCP对端不能及时read和recv就会导致写buffer堆积。

针对系统的读写buffer参数调整
net.core.rmem_default = 4194304 默认读buffer大小,单位字节
net.core.wmem_default = 4194304 默认写buffer大小,单位字节
net.core.rmem_max = 4194304 最大读buffer大小,单位字节
net.core.wmem_max = 4194304 最大写buffer大小,单位字节
看到其定义,是不是觉得跟net.ipv4.tcp_mem、net.ipv4.tcp_rmem、net.ipv4.tcp_wmem含义很重合呢?

其实(net.ipv4.tcp_mem、net.ipv4.tcp_rmem、net.ipv4.tcp_wmem)这几个参数只控制TCP socket的内存大小,而且如果遇到TCP socket申请内存,(net.core.rmem_default、net.core.wmem_default)会被(net.ipv4.tcp_rmem、net.ipv4.tcp_wmem)覆盖

所以(net.core.rmem_default、net.core.wmem_default、net.core.rmem_max、net.core.wmem_max)控制系统所有协议的读写buffer大小

(2)UDP协议内存使用设置

net.ipv4.udp_mem = 752832 1003776 1505664
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_wmem_min = 4096
这几个参数针对UDP协议,则跟上面TCP的含义一致

六.其他内核参数

net.ipv4.ip_local_port_range = 1024 65000
表示用于向外连接的临时端口范围。缺省情况下很小:32768到61000,因为主动连接需要用到很多临时端口(如连接mysql、redis),而临时端口最大值为(2^16-1)65535,1000之前一般为系统保留端口,所以建议设置为1024到65000的较大范围

net.core.somaxconn = 65535
net.core.somaxconn表示socket监听(listen)的backlog上限,backlog是socket的监听队列,也就是服务端所能accept(socket编程中accpet()函数为建立TCP连接接受连接状态)即处理数据的最大客户端数量队列,默认值为128,如果队列满了的时候新来一条建立连接,该连接会被拒绝

该值应当小于等于net.ipv4.tcp_max_syn_backlog,因为net.ipv4.tcp_max_syn_backlog参数控制的SYN队列客户端的数量,还在建立连接之前,因此设置为65535一样比较合适

fs.file-max = 6553600
设置系统所有进程一共可以打开多少个文件句柄,这是一个系统级的设置,管控的是所有进程总共可以同时打开多少文件句柄,如果多个进程打开了较多文件就会导致文件句柄不足,因此设置较大值,不过要注意程序打开的文件越多,就占用更多的内存,因此要根据业务和服务器配置起来设置

如果想单独对某个进程设置可以打开多少文件句柄,那么可以使用ulimit -n命令设置,但该命令只对当前session生效,默认值为1024
ulimit -n 655350

也可以写入文件永久生效,对每个进程的打开文件数量限制
vim /etc/security/limits.conf
* soft nofile 655350
* hard nofile 655350

总结

现在多数线上业务,服务器很少暴露在外网了,前端一般有负载均衡、防火墙等代理。甚至服务器已经变成VPC(虚拟内网)环境,将这些服务器隔离在外网环境之外,这样就减少了像DDOS等攻击,这些攻击一般都让外部代理承受了。

对于服务器的一些内核性能参数范围,如果网络环境及架构设计好,一些范围参数可以设置的偏大,性能偏极限一些,这样能最大释放服务器的性能,其他的就用系统默认的参数配置即可。对于WEB服务的优化,是多方面的,内核参数仅仅是释放了服务器本该有的性能,而更高的承载能力,需要从服务器配置、网络、架构、数据库及缓存和实际业务应用等多方面着手,不同的调整满足不同的需求

RT:以上有些地方可能会解释得不对,还望指正,一起学习

阅读 2.6k

运维学习之路
记录运维工作的学习
421 声望
41 粉丝
0 条评论
你知道吗?

421 声望
41 粉丝
宣传栏