Linux实例常用内核网络参数介绍与常见问题处理

TCP基本知识

(1) TCP的三次握手和四次挥手

• TCP状态转移要点
  TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中，最值得注意的状态有两个：CLOSE_WAIT和TIME_WAIT。

• 1、LISTENING状态 　　
  FTP服务启动后首先处于侦听（LISTENING）状态。

• 2、ESTABLISHED状态 　　
  ESTABLISHED的意思是建立连接。表示两台机器正在通信。

• 3、CLOSE_WAIT

  对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭。

• 4、TIME_WAIT

  我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情况下，尽量不要主动断开连接，以减少TIME_WAIT状态造成的资源浪费。

  目前有一种避免TIME_WAIT资源浪费的方法，就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的，在某些情况下这个操作可能会带来错误。

(2) TCP的三次握手和四次挥手状态说明

状态	详解
CLOSED	没有使用这个套接字[netstat 无法显示closed状态]
LISTEN	套接字正在监听连接[调用listen后]
SYN_SENT	套接字正在试图主动建立连接[发送SYN后还没有收到ACK]
SYN_RECEIVED	正在处于连接的初始同步状态[收到对方的SYN，但还没收到自己发过去的SYN的ACK]
ESTABLISHED	连接已建立
FIN_WAIT_1	套接字已关闭，正在关闭连接[发送FIN，没有收到ACK也没有收到FIN]
CLOSE_WAIT	远程套接字已经关闭：正在等待关闭这个套接字[被动关闭的一方收到FIN]
CLOSING	套接字已关闭，远程套接字正在关闭，暂时挂起关闭确认[在FIN_WAIT_1状态下收到被动方的FIN]
LAST_ACK	远程套接字已关闭，正在等待本地套接字的关闭确认[被动方在CLOSE_WAIT状态下发送FIN]
FIN_WAIT_2	套接字已关闭，正在等待远程套接字关闭[在FIN_WAIT_1状态下收到发过去FIN对应的ACK]
TIME_WAIT	这个套接字已经关闭，正在等待远程套接字的关闭传送[FIN、ACK、FIN、ACK都完毕，这是主动方的最后一个状态，在过了2MSL时间后变为CLOSED状态]

(3) Linux内核参数说明

参数	描述
net.core.rmem_default	默认的TCP数据接收窗口大小（字节）。
net.core.rmem_max	最大的TCP数据接收窗口（字节）。
net.core.wmem_default	默认的TCP数据发送窗口大小（字节）。
net.core.wmem_max	最大的TCP数据发送窗口（字节）。
net.core.netdev_max_backlog	当内核处理速度比网卡接收速度慢时，这部分多出来的包就会被保存在网卡的接收队列上，而该参数说明了这个队列的数量上限。在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
net.core.somaxconn	该参数定义了系统中每一个端口最大的监听队列的长度，是个全局参数。该参数和net.ipv4.tcp_max_syn_backlog有关联，后者指的是还在三次握手的半连接的上限，该参数指的是处于ESTABLISHED的数量上限。若您的ECS实例业务负载很高，则有必要调高该参数。listen(2)函数中的参数backlog 同样是指明监听的端口处于ESTABLISHED的数量上限，当backlog大于net.core.somaxconn时，以net.core.somaxconn参数为准。
net.core.optmem_max	表示每个套接字所允许的最大缓冲区的大小。
net.ipv4.tcp_mem	确定TCP栈应该如何反映内存使用，每个值的单位都是内存页（通常是4KB）。第一个值是内存使用的下限。第二个值是内存压力模式开始对缓冲区使用应用压力的上限。第三个值是内存使用的上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的BDP可以增大这些值（其单位是内存页而不是字节）。
net.ipv4.tcp_rmem	为自动调优定义Socket使用的内存。第一个值是为Socket接收缓冲区分配的最少字节数。第二个值是默认值（该值会被rmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值。第三个值是接收缓冲区空间的最大字节数（该值会被rmem_max覆盖）。
net.ipv4.tcp_wmem	为自动调优定义Socket使用的内存。第一个值是为Socket发送缓冲区分配的最少字节数。第二个值是默认值（该值会被wmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值。第三个值是发送缓冲区空间的最大字节数（该值会被wmem_max覆盖）。
net.ipv4.tcp_keepalive_time	TCP发送keepalive探测消息的间隔时间（秒），用于确认TCP连接是否有效。
net.ipv4.tcp_keepalive_intvl	探测消息未获得响应时，重发该消息的间隔时间（秒）。
net.ipv4.tcp_keepalive_probes	在认定TCP连接失效之前，最多发送多少个keepalive探测消息。
net.ipv4.tcp_sack	启用有选择的应答（1表示启用），通过有选择地应答乱序接收到的报文来提高性能，让发送者只发送丢失的报文段，（对于广域网通信来说）这个选项应该启用，但是会增加对CPU的占用。
net.ipv4.tcp_fack	启用转发应答，可以进行有选择应答（SACK）从而减少拥塞情况的发生，这个选项也应该启用。
net.ipv4.tcp_timestamps	TCP时间戳（会在TCP包头增加12B），以一种比重发超时更精确的方法（参考RFC 1323）来启用对RTT的计算，为实现更好的性能应该启用这个选项。
net.ipv4.tcp_window_scaling	启用RFC 1323定义的window scaling，要支持超过64KB的TCP窗口，必须启用该值（1表示启用），TCP窗口最大至1GB，TCP连接双方都启用时才生效。
net.ipv4.tcp_syncookies	该参数表示是否打开TCP同步标签（SYN_COOKIES），内核必须开启并编译CONFIG_SYN_COOKIES，SYN_COOKIES可以防止一个套接字在有过多试图连接到达时，引起过载。默认值0表示关闭。当该参数被设置为1，且SYN_RECV队列满了之后，内核会对SYN包的回复做一定的修改，即在响应的SYN+ACK包中，初始的序列号是由源IP+Port、目的IP+Port及时间这五个参数共同计算出一个值组成精心组装的TCP包。由于ACK包中确认的序列号并不是之前计算出的值，恶意攻击者无法响应或误判，而请求者会根据收到的SYN+ACK包做正确的响应。启用net.ipv4.tcp_syncookies后，会忽略net.ipv4.tcp_max_syn_backlog。
net.ipv4.tcp_tw_reuse	表示是否允许将处于TIME-WAIT状态的Socket（TIME-WAIT的端口）用于新的TCP连接。
net.ipv4.tcp_tw_recycle	能够更快地回收TIME-WAIT套接字。
net.ipv4.tcp_fin_timeout	对于本端断开的Socket连接，TCP保持在FIN-WAIT-2状态的时间（秒）。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。
net.ipv4.ip_local_port_range	表示TCP/UDP协议允许使用的本地端口号。
net.ipv4.tcp_max_syn_backlog	该参数决定了系统中处于SYN_RECV状态的TCP连接数量。SYN_RECV状态指的是当系统收到SYN后，作为SYN+ACK响应后等待对方回复三次握手阶段中的最后一个ACK的阶段。对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字。默认值大小会受实例内存的影响，默认值最大为2048。
net.ipv4.tcp_low_latency	允许TCP/IP栈适应在高吞吐量情况下低延时的情况，这个选项应该禁用。
net.ipv4.tcp_westwood	启用发送者端的拥塞控制算法，它可以维护对吞吐量的评估，并试图对带宽的整体利用情况进行优化，对于WAN通信来说应该启用这个选项。
net.ipv4.tcp_bic	为快速长距离网络启用Binary Increase Congestion，这样可以更好地利用以GB速度进行操作的链接，对于WAN通信应该启用这个选项。
net.ipv4.tcp_max_tw_buckets	该参数设置系统的TIME_WAIT的数量，如果超过默认值则会被立即清除。tcp_max_tw_buckets默认值大小会受实例内存的影响，最大值为262144。
net.ipv4.tcp_synack_retries	指明了处于SYN_RECV状态时重传SYN+ACK包的次数。
net.ipv4.tcp_abort_on_overflow	设置该参数为1时，当系统在短时间内收到了大量的请求，而相关的应用程序未能处理时，就会发送Reset包直接终止这些链接。建议通过优化应用程序的效率来提高处理能力，而不是简单地Reset。默认值为0。
net.ipv4.route.max_size	内核所允许的最大路由数目。
net.ipv4.ip_forward	接口间转发报文。
net.ipv4.ip_default_ttl	报文可以经过的最大跳数。
net.netfilter.nf_conntrack_tcp_timeout_established	在指定之间内，已经建立的连接如果没有活动，则通过iptables进行清除。
net.netfilter.nf_conntrack_max	哈希表项最大值。

查看和修改Linux实例内核参数

• 从实际需求出发，尽量有相关数据的支撑，不建议随意调整内核参数。
• 了解参数的具体作用，需注意同类型或版本的环境中，内核参数可能有所不同。
• 备份ECS实例中的重要数据。关于如何备份数据请参见

提供以下两种修改Linux实例内核参数的方法。

方法一：通过/proc/sys/目录查看和修改内核参数

• 查看内核参数：使用cat命令查看对应文件的内容，执行以下命令，查看net.ipv4.tcp_tw_recycle的值。

 cat /proc/sys/net/ipv4/tcp_tw_recycle 

• 修改内核参数：使用echo命令修改内核参数对应的文件，执行以下命令，将net.ipv4.tcp_tw_recycle的值修改为0。

 echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle 

方法二：通过sysctl.conf文件查看和修改内核参数

net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_challenge_ack_limit = 1000
net.ipv4.tcp_limit_output_bytes = 262144
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.cipso_cache_enable = 1
net.ipv4.cipso_cache_bucket_size = 10
net.ipv4.cipso_rbm_optfmt = 0
net.ipv4.cipso_rbm_strictvalid = 1

通过以下两种方式，修改内核参数。

说明：调整内核参数后，内核处于不稳定状态，请务必重启实例。

执行以下命令，临时修改内核参数。

/sbin/sysctl -w kernel.parameter="[$Example]"

说明：[$Example]为参数值，如sysctl -w net.ipv4.tcp_tw_recycle="0"命令，将参数值改为0。

通过修改配置文件的方式修改内核参数。
执行以下命令，修改/etc/sysctl.conf文件中的参数。

vi /etc/sysctl.conf 
#执行以下命令，使配置生效。
/sbin/sysctl -p

Linux网络相关内核参数引发的常见问题及处理

问题一：Linux实例NAT哈希表满导致ECS实例丢包

注意：此处涉及的内核参数如下。

• net.netfilter.nf_conntrack_buckets
• net.nf_conntrack_max

问题现象
Linux实例出现间歇性丢包，无法连接实例。请参见ping 丢包或不通时链路测试说明，通过tracert、mtr等工具排查，外部网络未见异常。同时，在系统日志中重复出现大量类似以下错误信息。

Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.

原因分析
Linux实例出现间歇性丢包，无法连接实例。请参见ping 丢包或不通时链路测试说明，通过tracert、mtr等工具排查，外部网络未见异常。同时，在系统日志中重复出现大量类似以下错误信息。

Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.
Feb  6 16:05:07 i-*** kernel: nf_conntrack: table full, dropping packet.

原因分析
ip_conntrack是Linux系统内NAT的一个跟踪连接条目的模块。ip_conntrack模块会使用一个哈希表记录TCP协议“established connection”记录，当这个哈希表满之后，便会导致“nf_conntrack: table full, dropping packet”错误。Linux系统会开辟一个空间，用于维护每一个TCP链接，这个空间的大小与nf_conntrack_buckets、nf_conntrack_max参数相关，后者的默认值是前者的4倍，所以一般建议调大nf_conntrack_max参数值。

说明：系统维护连接比较消耗内存，请在系统空闲和内存充足的情况下调大nf_conntrack_max参数，且根据系统的情况而定。

解决方法

1. 登录Linux实例，如何登录Linux实例请参见使用管理终端连接Linux实例。

2. 执行以下命令，编辑系统内核配置。

   vi /etc/sysctl.conf
   

3. 修改哈希表项最大值参数net.netfilter.nf_conntrack_max为655350。

4. 修改超时参数net.netfilter.nf_conntrack_tcp_timeout_established为1200，默认情况下超时时间是432000秒。

5. 执行sysctl -p命令，使配置生效。

问题二：报“Time wait bucket table overflow”错误

注意：此处涉及的内核参数为net.ipv4.tcp_max_tw_buckets。

问题现象

• Linux实例的/var/log/messages日志信息全是类似“kernel: TCP: time wait bucket table overflow”的报错信息，提示“time wait bucket table”溢出，系统显示类似如下。

Feb 18 12:28:38 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:44 i-*** kernel: printk: 227 messages suppressed.
Feb 18 12:28:44 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:52 i-*** kernel: printk: 121 messages suppressed.
Feb 18 12:28:52 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:53 i-*** kernel: printk: 351 messages suppressed.
Feb 18 12:28:53 i-*** kernel: TCP: time wait bucket table overflow
Feb 18 12:28:59 i-*** kernel: printk: 319 messages suppressed.

• 执行以下命令，统计处于TIME_WAIT状态的TCP连接数，发现处于TIME_WAIT状态的TCP连接非常多。

 netstat -ant|grep TIME_WAIT|wc -l

原因分析
参数net.ipv4.tcp_max_tw_buckets可以调整内核中管理TIME_WAIT状态的数量。当实例中处于TIME_WAIT状态，及需要转换为TIME_WAIT状态的连接数之和超过net.ipv4.tcp_max_tw_buckets参数值时，messages日志中将报“time wait bucket table” 错误，同时内核关闭超出参数值的部分TCP连接。您需要根据实际情况适当调高net.ipv4.tcp_max_tw_buckets参数，同时从业务层面去改进TCP连接。

解决方法

1. 执行以下命令，统计TCP连接数。
   netstat -anp |grep tcp |wc -l
2. 执行以下命令，查询net.ipv4.tcp_max_tw_buckets参数。如果确认连接使用很高，则容易超出限制。
   vi /etc/sysctl.conf
3. 根据现场情况，增加net.ipv4.tcp_max_tw_buckets参数值的大小。
4. 执行sysctl -p命令，使配置生效。

问题三：Linux实例中FIN_WAIT2状态的TCP链接过多

注意：此处涉及的内核参数为net.ipv4.tcp_fin_timeout。

问题现象
FIN_WAIT2状态的TCP链接过多。

原因分析

• 在HTTP服务中，Server由于某种原因会主动关闭连接，例如KEEPALIVE超时的情况下。作为主动关闭连接的Server就会进入FIN_WAIT2状态。
• 在TCP/IP协议栈中，存在半连接的概念，FIN_WAIT2状态不算超时，如果Client不关闭，FIN_WAIT2状态将保持到系统重启，越来越多的FIN_WAIT2状态会致使内核Crash。
• 建议调小net.ipv4.tcp_fin_timeout参数的值，以便加快系统关闭处于FIN_WAIT2状态的TCP连接。

解决方法

1. 执行vi /etc/sysctl.conf命令，修改或增加以下内容。

   net.ipv4.tcp_syncookies = 1
   net.ipv4.tcp_fin_timeout = 30
   net.ipv4.tcp_max_tw_buckets = 262144
   

2. 执行sysctl -p命令，使配置生效。

注意：由于FIN_WAIT2状态的TCP连接会进入TIME_WAIT状态，请同时参见问题二：报“Time wait bucket table
overflow”错误。

问题四：Linux实例中出现大量CLOSE_WAIT状态的TCP连接

问题现象
执行以下命令，发现当前系统中处于CLOSE_WAIT状态的TCP连接非常多。

netstat -atn|grep CLOSE_WAIT|wc -l

原因分析
根据实例上的业务量判断CLOSE_WAIT数量是否超出了正常的范围。TCP连接断开时需要进行四次挥手，TCP连接的两端都可以发起关闭连接的请求，若对端发起了关闭连接，但本地没有关闭连接，那么该连接就会处于CLOSE_WAIT状态。虽然该连接已经处于半开状态，但是已经无法和对端通信，需要及时的释放该连接。建议从业务层面及时判断某个连接是否已经被对端关闭，即在程序逻辑中对连接及时关闭，并进行检查。

解决方法
编程语言中对应的读、写函数一般包含了检测CLOSE_WAIT状态的TCP连接功能，可通过执行以下命令，查看当前实例上处于CLOSE_WAIT状态的连接数。

netstat -an|grep CLOSE_WAIT|wc -l

Java语言和C语言中关闭连接的方法如下：
Java语言

1. 通过read方法来判断I/O 。当read方法返回-1时，则表示已经到达末尾。
2. 通过close方法关闭该连接。

C语言

• 若等于0，则可以关闭该连接。
• 若小于0，则查看error，若不是AGAIN，则同样可以关闭连接。

问题五：客户端配置NAT后仍无法访问ECS或RDS远端服务器

说明：此处涉及的内核参数如下。 net.ipv4.tcp_tw_recycle net.ipv4.tcp_timestamps

问题现象
若远端服务器的内核参数net.ipv4.tcp_tw_recycle和net.ipv4.tcp_timestamps的值都为1，则远端服务器会检查每一个报文中的时间戳（Timestamp），若Timestamp不是递增的关系，不会响应这个报文。配置NAT后，远端服务器看到来自不同客户端的源IP相同，但NAT前每一台客户端的时间可能会有偏差，报文中的Timestamp就不是递增的情况。

解决方法

• 远端服务器为ECS时，修改net.ipv4.tcp_tw_recycle参数为0。
• 远端服务器为RDS等PaaS服务时。RDS无法直接修改内核参数，需要在客户端上修改net.ipv4.tcp_tw_recycle参数和net.ipv4.tcp_timestamps参数为0。

问题六：存在大量处于TIME_WAIT状态的连接

说明：此处涉及的内核参数如下：
net.ipv4.tcp_syncookies
net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout

问题现象
云服务器中存在大量处于TIME_WAIT状态的连接。

原因分析
首先通过调用close()发起主动关闭，在发送最后一个ACK之后会进入time_wait的状态，该发送方会保持2MSL时间之后才会回到初始状态。MSL值是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组（客户端IP地址和端口，服务端IP地址和端口号）不能被使用。

解决方法

1. 通过netstat或ss命令，可以看到大量处于TIME_WAIT状态的连接。
   执行以下命令，查看TIME_WAIT状态的连接数量。

   netstat -n | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}'
   

   说明：或者执行ss -tan state time-wait命令，查看TIME_WAIT连接信息。

2. 执行以下命令，编辑系统内核配置。

vi /etc/sysctl.conf

修改或加入以下内容。

net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

警告：对于服务端来说，在NAT环境中，开启net.ipv4.tcp_tw_recycle =1:配置可能导致校验时间戳递增，从而影响业务，不建议开启该功能。关于这四个内核参数的更多介绍，请参考以下内容：
net.ipv4.tcp_syncookies=1：开启SYN的cookies，当出现SYN等待队列溢出时，启用cookies进行处理。
net.ipv4.tcp_tw_reuse=1：允许将TIME-WAIT的socket重新用于新的TCP连接。如果新请求的时间戳，比存储的时间戳更大，则系统将会从TIME_WAIT状态的存活连接中选取一个，重新分配给新的请求连接。
net.ipv4.tcp_tw_recycle=1：开启TCP连接中TIME-WAIT的sockets快速回收功能。需要注意的是，该机制也依赖时间戳选项，系统默认开启tcp_timestamps机制，而当系统中的tcp_timestamps和tcp_tw_recycle机制同时开启时，会激活TCP的一种行为，即缓存每个连接最新的时间戳，若后续的请求中时间戳小于缓存的时间戳时，该请求会被视为无效，导致数据包会被丢弃。特别是作为负载均衡服务器的场景，不同客户端请求经过负载均衡服务器的转发，可能被认为是同一个连接，若客户端的时间不一致，对于后端服务器来说，会发生时间戳错乱的情况，因此会导致数据包丢失，从而影响业务。
net.ipv4.tcp_fin_timeout=30：如果socket由服务端要求关闭，则该参数决定了保持在FIN-WAIT-2状态的时间。

3. 执行命令以下命令，使配置生效。

/sbin/sysctl -p 

4. TIME_WAIT状态的连接较多时，会导致各种问题，除了直观的减少TIME_WAIT状态的连接，也可以通过扩大端口范围和对TIME_WAIT的bucket进行扩容等手段优化系统性能。

问题七：服务端断开连接后客户端仍然可以看到是建立连接的

注意：此处涉及的内核参数为net.ipv4.tcp_fin_timeout。

问题现象
服务端A与客户端B建立了TCP连接，之后服务端A主动断开了连接，但是在客户端B上仍然看到连接是建立的。

原因分析
通常是由于修改了服务端默认的net.ipv4.tcp_fin_timeout内核参数所致。

解决方法

1. 执行以下命令，修改配置，设置

   net.ipv4.tcp_fin_timeout=30。
    vi /etc/sysctl.conf
   

2. 执行以下命令，使配置生效。

   sysctl -p
   

参考1：https://blog.csdn.net/zzhongcy/article/details/38851271
参考2：https://help.aliyun.com/knowledge_detail/41334.html