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

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

方法一、通过 /proc/sys/ 目录

查看内核参数：使用 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 -a 查看当前系统中生效的所有参数，如下所示：

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

修改内核参数：

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 使配置生效。 

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

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

Linux 实例 NAT 哈希表满导致 ECS 实例丢包

此处涉及的内核参数：

• net.netfilter.nf_conntrack_buckets 

• net.nf_conntrack_max 

问题现象

ECS Linux 实例出现间歇性丢包，无法连接实例，通过 tracert、mtr 等工具排查，外部网络未见异常。同时，如下图所示，在系统日志中重复出现大量（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.
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. 使用管理终端登录实例。 

2. 执行命令 # vi /etc/sysctl.conf 编辑系统内核配置。 

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

4. 修改超时参数：net.netfilter.nf_conntrack_tcp_timeout_established = 1200，默认情况下 timeout 是 432000（秒）。 

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

Time wait bucket table overflow 报错

此处涉及的内核参数：

• 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.

执行命令 netstat -ant|grep TIME_WAIT|wc -l 统计处于 TIME_WAIT 状态的 TCP 连接数，发现处于 TIME_WAIT 状态的 TCP 连接非常多。

原因分析

参数 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. 执行命令 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 实例中 FIN_WAIT2 状态的 TCP 链接过多

此处涉及的内核参数：

• net.ipv4.tcp_fin_timeout

问题现象

FIN_WAIT2 状态的 TCP 链接过多。

原因分析

• 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 连接。

解决思路

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.  

3. 执行命令 # sysctl -p 使配置生效。

   注意：由于 FIN_WAIT2 状态的 TCP 连接会进入 TIME_WAIT 状态，请同时参阅 time wait bucket table overflow 报错。

Linux 实例中出现大量 CLOSE_WAIT 状态的 TCP 连接

问题现象

执行命令 netstat -atn|grep CLOSE_WAIT|wc -l 发现当前系统中处于 CLOSE_WAIT 状态的 TCP 连接非常多。

原因分析

关闭 TCP 连接时，TCP 连接的两端都可以发起关闭连接的请求，若对端发起了关闭连接，但本地没有关闭连接，那么该连接就会处于 CLOSE_WAIT 状态。虽然该连接已经处于半开状态，但是已经无法和对端通信，需要及时的释放掉该链接。建议从业务层面及时判断某个连接是否已经被对端关闭，即在程序逻辑中对连接及时关闭检查。

解决思路

编程语言中对应的读、写函数一般包含了检测 CLOSE_WAIT TCP 连接功能，例如：

Java 语言：

1. 通过 read 方法来判断 I/O 。当 read 方法返回 -1 时则表示已经到达末尾。

2. 通过 close 方法关闭该链接。

C 语言：

1. 检查 read 的返回值。

• 若等于 0 则可以关闭该连接。

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

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

此处涉及的内核参数：

• net.ipv4.tcp_tw_recycle

• net.ipv4.tcp_timestamps

问题现象

客户端配置 NAT 后无法访问远端 ECS、RDS，包括配置了 SNAT 的 VPC ECS 。同时无法访问连接其他 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。

文档涉及的 Linux 内核参数说明

转载于    https://dude6.com/article/2970.html