虚拟网络运维------ Linux 内核配置相关问题记录

我不是女神ヾ 2023-02-21 12:52 5阅读 0赞

### 文章目录 ###

*  虚拟网络运维------ Linux 内核配置相关问题记录
 *   *  前言
     *  内核配置的查看和修改
     *  重点内核参数配置详述
     *   *  nf\_conntrack
         *  tcp\_max\_tw\_buckets
         *  tcp\_fin\_timeout
     *  其他内核参数配置概述
     *  运维问题记录
     *   *  问题1：client port 耗尽无法发起请求，概率性连接失败
         *  问题2：Linux OS NAT哈希表满导致丢包(nf\_conntrack)
         *  问题3：报“Time wait bucket table overflow”错误（tcp\_max\_tw\_buckets）
         *  问题4：Linux实例中FIN\_WAIT2状态的TCP链接过多
         *  问题5：Linux实例中出现大量CLOSE\_WAIT状态的TCP连接
         *  问题6：客户端配置NAT后仍无法访问ECS或RDS远端服务器
         *  问题7：存在大量处于TIME\_WAIT状态的连接
         *  问题8：服务端断开连接后客户端仍然可以看到是建立连接的
         *  问题9：无法在本地网络环境通过SSH连接Linux实例

# 虚拟网络运维------ Linux 内核配置相关问题记录 #

## 前言 ##

云计算网络方向运维时，经常会遇到各类网络场景问题，其中受到Linux内核配置的影响是存在一定的比例的， 此类问题相对比较复杂，不易排查，这里长期更新，将遇到的涉及Linux内核配置影响的运维问题记录；

另外，涉及调整内核配置时，需要从实际需要出发，最好有相关数据的支撑，不建议随意调整内核参数。需要了解参数的具体作用，且注意同类型或版本环境的内核参数可能有所不同。并做好备份，方便回滚；

Linux 内核相关官方文档：https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

[https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt][https_www.kernel.org_doc_Documentation_networking_ip-sysctl.txt]

ip-sysctl.txt

## 内核配置的查看和修改 ##

**查看内核参数**：使用 `cat` 查看对应文件的内容，例如执行命令 `cat /proc/sys/net/ipv4/tcp_tw_recycle` 查看 `net.ipv4.tcp_tw_recycle` 的值。

**修改内核参数**：使用 `echo` 修改内核参数对应的文件，例如执行命令 `echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle` 将 `net.ipv4.tcp_tw_recycle` 的值修改为 0。

*  `/proc/sys/` 目录是 Linux 内核在启动后生成的伪目录，其目录下的 `net` 文件夹中存放了当前系统中开启的所有内核参数、目录树结构与参数的完整名称相关，如 `net.ipv4.tcp_tw_recycle`，它对应的文件是 `/proc/sys/net/ipv4/tcp_tw_recycle`，文件的内容就是参数值。
 *  修改的参数值仅在当次运行中生效，系统重启后会回滚历史值，一般用于临时性的验证修改的效果。若需要永久性修改，需要修改sysctl.conf 文件；可以使用sysctl 命令管理；

**查看内核参数**：执行命令 `sysctl -a` 查看当前系统中生效的所有参数；

**修改内核参数**：

1.  执行命令 `/sbin/sysctl -w kernel.parameter="example"` 修改参数，如`sysctl -w net.ipv4.tcp_tw_recycle="0"`。
2.  执行命令 `vi /etc/sysctl.conf` 修改 `/etc/sysctl.conf` 文件中的参数。
3.  执行命令 `/sbin/sysctl -p` 使配置生效。

> **注意**：调整内核参数后内核处于不稳定状态，请酌情重启实例。

## 重点内核参数配置详述 ##

### nf\_conntrack ###

*  `net.netfilter.nf_conntrack_buckets`
 *  `net.nf_conntrack_max`

nf\_conntrack(在老版本的 Linux 内核中叫 ip\_conntrack)是一个内核模块,用于跟踪一个连接的状态的。连接状态跟踪可以供其他模块使用,最常见的两个使用场景是 iptables 的 nat 的 state 模块。 iptables 的 nat 通过规则来修改目的/源地址,但光修改地址不行,我们还需要能让回来的包能路由到最初的来源主机。这就需要借助 nf\_conntrack 来找到原来那个连接的记录才行。而 state 模块则是直接使用 nf\_conntrack 里记录的连接的状态来匹配用户定义的相关规则。

nf\_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`，且根据系统的情况而定。

运维过程中，如果tcp连接数满后，就会导致Linux OS 出现丢包、高时延或断连等问题；具体表现是在`/var/log/message`

会打印类似：`kernel: nf_conntrack: table full, dropping packet.`

规避修改方案：

**修改内核配置`net.nf_conntrack_max`将配置参数调大；或 停止iptables(或 firewalld)服务，或添加iptables 规则禁止连接跟踪；**

lsmod | grep nf
    sysctl -a | grep nf_conntrack
    systemctl status firewalld
    # iptables 规则类似这样
    iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
    iptables -t raw -A OUTPUT -p tcp --sport 80 -j NOTRACK

下列截图配置项都是依赖于模块 nf\_conntrack，以及 如果iptables服务(或firewalld) 服务状态 active (running) ，iptables 会自动拉起nf\_conntrack 模块；当stop 服务后，模块即会停用；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1][]

### tcp\_max\_tw\_buckets ###

`net.ipv4.tcp_max_tw_buckets`

该字段的的官方说明

> tcp\_max\_tw\_buckets - INTEGER  
> Maximal number of timewait sockets held by system simultaneously.  
> If this number is exceeded time-wait socket is immediately destroyed  
> and warning is printed. This limit exists only to prevent  
> simple DoS attacks, you *must* not lower the limit artificially,  
> but rather increase it (probably, after increasing installed memory),  
> if network conditions require more than default value.

系统同时持有的最大timewait套接字数。如果超过此数量，则等待时间插座将立即销毁并打印警告。此限制的存在只是为了防止简单的DoS攻击，不建议人为地降低了极限，而是增加它（可能，增加安装的内存后），如果网络条件需要超过默认值。

sysctl -a | grep tcp_max_tw_buckets

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2][]

**TIME\_WAIT状态原理**  
通信双方建立TCP连接后，主动关闭连接(即在tcp四次断开时，先发送fin报文的一方)的一方就会进入TIME\_WAIT状态。  
客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME\_WAIT状态，再停留2个MSL时间(maximum segment lifetime 最大分节生命期)，进入CLOSED状态。

如果环境中time\_wait连接数超过了内核配置tcp\_max\_tw\_buckets 配置数据数量，则不会有新的time\_wait 状态连接出现，

可能会出现两种异常情况：  
① 对端服务器发完最后一个 Fin 包，没有收到当前服务器返回最后一个 Ack，又重发了 Fin 包，因为新的 TimeWait 没有办法创建 ，这个连接在当前服务器上就消失了，对端服务器将会收到一个 Reset 包。因为这个连接是明确要关闭的，所以收到一个 Reset 也不会有什么大问题。(但是违反了 TCP/IP 协议)  
② 因为这个连接在当前服务器上消失，那么刚刚释放的端口可能被立刻使用，如果这时对端服务器没有释放连接，当前服务器就会收到对端服务器发来的 Reset 包。如果当前服务器是代理服务器，就可能会给用户返回 502 错误。(这种异常对服务或者用户是有影响的)

当Linux实例的time\_wait 连接数大于或等于配置参数时，Linux 实例 `/var/log/message` 日志全是类似 `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.

通过netstat -anptu 会查看到大量的处于TIME\_WAIT 状态的链接，未关闭的连接；

实际运维时，遇到过TIME\_WAIT状态的连接数量过多，导致耗尽请求port数，进而无法发起新链接请求，出现访问失败的情况；(下面有案例)；

**原因分析**

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

在 TIME\_WAIT 数量等于 tcp\_max\_tw\_buckets 时，不会有新的 TIME\_WAIT 产生。

**解决思路**

1.  执行命令 `netstat -anp |grep tcp |wc -l` 统计 TCP 连接数。
2.  执行命令 `vi /etc/sysctl.conf`，查询 `net.ipv4.tcp_max_tw_buckets` 参数。如果确认连接使用很高，容易超出限制。
3.  **根据实际情况调整配置参数** `net.ipv4.tcp_max_tw_buckets`。
4.  执行命令 `sysctl -p` 使配置生效。

另Linux内核中，还有两个配置 `net.ipv4.tcp_tw_recycle` 和 `net.ipv4.tcp_tw_reuse`；这两个配置项的调整需要慎重，可能会导致数据面的问题，影响转发；

### tcp\_fin\_timeout ###

`net.ipv4.tcp_fin_timeout`

> tcp\_fin\_timeout - INTEGER  
> The length of time an orphaned (no longer referenced by any  
> application) connection will remain in the FIN\_WAIT\_2 state  
> before it is aborted at the local end. While a perfectly  
> valid “receive only” state for an un-orphaned connection, an  
> orphaned connection in FIN\_WAIT\_2 state could otherwise wait  
> forever for the remote to close its end of the connection.  
> Cf. tcp\_max\_orphans  
> Default: 60 seconds

*  HTTP 服务中，Server 由于某种原因会主动关闭连接，例如 KEEPALIVE 超时的情况下。作为主动关闭连接的 Server 就会进入 FIN\_WAIT2 状态。
 *  TCP/IP 协议栈中，存在**半连接**的概念，FIN\_WAIT2 状态不算做超时，如果 Client 不关闭，FIN\_WAIT\_2 状态将保持到系统重启，越来越多的 FIN\_WAIT\_2 状态会致使内核 Crash。

网络上资料有两种说法 ：

一种是：调小 `net.ipv4.tcp_fin_timeout` 参数，减少这个数值以便加快系统关闭处于 `FIN_WAIT2` 状态的 TCP 连接；

另一种是：`net.ipv4.tcp_fin_timeout`这个数值其实是输出用的，修改之后并没有真正的读回内核中进行使用，而内核中真正管用的是一个宏定义，在 $KERNEL/include/net/tcp.h里面，有下面的行：`#define TCP_TIMEWAIT_LEN (60*HZ)`

*目前这部分暂时没有条件验证确认；*

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 3][]

## 其他内核参数配置概述 ##

这里将其他的配置参数简单描述如下：

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

## 运维问题记录 ##

### 问题1：client port 耗尽无法发起请求，概率性连接失败 ###

**问题现象**

client 概率性连接db实例失败，报错：`ERROR 2003(HY000):Can't connect to Mysql server on '192.168.192.28' (99)`

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 4][]  
报错回显 google 后，发现是php相关回显，报错代码 99；

根据google 回显，判断是client 存在限制，另复测其他client 未出现该问题，server 端监控也未见异常；

**原因分析**

检查client 连接数端口 `netstat -anptu | wc -l`  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 5][]

查看发现有大量time\_wait状态连接，进一步检查client 端内核相关配置；  
![20200630212922785.png][]  
所以客户端 就是在 这个 范围 内，60999 - 32768 = 28231 满了之后就可能会导致无法分配新的客户端端口发起请求；

sysctl -a | grep port_range

由于大量time\_wait 状态连接占用连接数，修改内核参数中对 time\_wait 状态连接的最大数量，释放连接；

[root@c9c5b5d95-z7jlj /]# sysctl -a | grep tw
    net.ipv4.tcp_max_tw_buckets = 524288

**解决方案**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 6][]  
规避修改后，问题规避；

后续发现是由于db中缺少一张表，程序持续发起连接重试，导致有大量短连接请求，耗尽port，触发问题；

*另此次问题client 是kubernetes pod，内核配置是pod内配置，pod跨node节点访问db实例：*

*数据链路是pod -----> svc ----> LB ---- DB*

*另 kubernetes中，不能修改pod sysctl 内核配置中的tw参数，k8s 不能开 tw 参数，不能开tcp\_tw\_reuse 和tcp\_tw\_recycle，这两个参数开了后会影响nat转发；*

另外之前也遇到过，产品转发特性，会特定使用一些特定的端口，如果请求分配到这些端口时，就会出现请求报错或os 丢包；

### 问题2：Linux OS NAT哈希表满导致丢包(nf\_conntrack) ###

问题现象

Linux 实例出现丢包、断连等网络异常现象；根据抓包等网络排查方案，定界丢包为该实例时；在系统日志中重复出现大量类似以下错误信息。

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`参数，且根据系统的情况而定。

解决方法

**修改内核配置`net.nf_conntrack`对应配置参数；**

**或 停止iptables(或 firewalld)服务，或添加iptables 规则禁止连接跟踪；**

如果选择修改内核配置`net.nf_conntrack`对应配置参数，可参考如下操作：

1.  执行以下命令，编辑系统内核配置。
    
        vi /etc/sysctl.conf
2.  修改哈希表项最大值参数`net.netfilter.nf_conntrack_max`为`655350`。
3.  修改超时参数`net.netfilter.nf_conntrack_tcp_timeout_established`为`1200`，默认情况下超时时间是432000秒。
4.  执行`sysctl -p`命令，使配置生效。

### 问题3：报“Time wait bucket table overflow”错误（tcp\_max\_tw\_buckets） ###

> 此处涉及的内核参数为`net.ipv4.tcp_max_tw_buckets`。

问题现象

*  Linux实例的`/var/log/message`日志信息全是类似`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`参数值时，message日志中将报“`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`命令，使配置生效。

### 问题4：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_syn_backlog = 8192
        net.ipv4.tcp_max_tw_buckets = 5000
2.  执行
    
        sysctl -p
    
    命令，使配置生效。
    
    > **注意**：由于`FIN_WAIT2`状态的TCP连接会进入`TIME_WAIT`状态，请同时参见报“Time wait bucket table overflow”错误这个问题。

### 问题5：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状态的连接数。Java语言和C语言中关闭连接的方法如下。

netstat -an|grep CLOSE_WAIT|wc -l

**Java语言**

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

**C语言**

检查`read`的返回值。

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

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

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

问题现象

客户端配置NAT后无法访问远端ECS、RDS，包括配置了SNAT的VPC中的ECS实例。同时无法访问其他ECS或RDS等云产品，抓包检测发现远端ECS和RDS对客户端发送的SYN包没有响应。

原因分析

若远端服务器的内核参数`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。

### 问题7：存在大量处于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地址和端口号）不能被使用。

解决方法

通过`netstat`或`ss`命令，可以看到大量处于TIME\_WAIT状态的连接。

1.  执行以下命令，查看TIME\_WAIT状态的连接数量。
    
        netstat -n | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}'
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
3.  执行命令以下命令，使配置生效。
    
        /sbin/sysctl -p

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

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

问题现象

服务端A与客户端B建立了TCP连接，之后服务端A主动断开了连接，但是在客户端B上仍然看到连接是建立的。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 7][]  
![20200630213301698.png][]

原因分析

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

解决方法

1.  执行以下命令，修改配置，设置
    
        net.ipv4.tcp_fin_timeout=30
    
    。
    
        vi /etc/sysctl.conf
2.  执行以下命令，使配置生效。
    
        sysctl -p

### 问题9：无法在本地网络环境通过SSH连接Linux实例 ###

> **说明**：此处涉及的内核参数如下。
> 
>  *  net.ipv4.tcp\_tw\_recycle
>  *  net.ipv4.tcp\_timestamps

问题现象

无法在本地网络环境通过SSH连接Linux实例，或者访问该Linux实例上的HTTP业务出现异常。Telnet测试会被reset。

原因分析

如果您的本地网络是NAT共享方式上网，该问题可能是由于本地NAT环境和目标Linux相关内核参数配置不匹配导致。尝试通过修改目标Linux实例内核参数来解决问题。

1.  远程连接目标Linux实例。
2.  执行如下命令，查看当前配置。
    
        cat /proc/sys/net/ipv4/tcp_tw_recycle
        cat /proc/sys/net/ipv4/tcp_timestamps
3.  查看上述两个配置的值是否为**0**，如果为**1**，NAT环境下的请求可能会导致上述问题。

解决方法

通过如下方式将上述参数值修改为0。

1.  执行如下命令，修改配置文件。
    
        vi /etc/sysctl.conf
2.  添加如下内容。
    
        net.ipv4.tcp_tw_recycle=0
        net.ipv4.tcp_timestamps=0
3.  执行如下命令，使配置生效。
    
        sysctl -p
4.  重新SSH登录实例，或者进行业务访问测试。

[https_www.kernel.org_doc_Documentation_networking_ip-sysctl.txt]: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200630212625235.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200630212646317.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200630212720421.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200630212757731.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200630212842615.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/2020063021290245.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[20200630212922785.png]: https://img-blog.csdnimg.cn/20200630212922785.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200630213100420.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20200630213232448.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[20200630213301698.png]: https://img-blog.csdnimg.cn/20200630213301698.png