" /> " />
侧边栏壁纸
博主头像
Life博主等级

鲜花与荆棘相伴！

  • 累计撰写 266 篇文章
  • 累计创建 95 个标签
  • 累计收到 5 条评论

目 录CONTENT

文章目录
IaaS

网络连接数：CT

Administrator
Administrator
2024-02-18 / 0 评论 / 0 点赞 / 15 阅读 / 19647 字

问题

服务器负载正常，当请求量稍微大时就出现超时现象，服务器上面看不到请求日志，但通过dmesg 或 cat var/log/messages 发现看到大量内核错误日志如下：

kernel: nf_conntrack: table full, dropping packet.

2.6.15 之前的版本，Linux 内核抛出：

ip_conntrack: table full, dropping packet.

本文主要从 nf_conntrack 的角度来总结，而ip_conntrack 只有较老的内核版本才单独支持。

连接跟踪

先说下上面问题的原因，当访问量大时，内核 netfilter 模块 conntrack 相关参数配置不合理，导致 IP 包被丢掉，连接无法建立时，就会报上面的错误，后面给出相关参数配置，那么什么是 连接跟踪状态呢？

conntrack 就是跟踪并且记录连接的状态，Linux 为每一个经过网络堆栈的数据包，生成一个新的连接记录项（Connection entry），此后，所有属于此连接的数据包都被唯一地分配给这个连接，并标识连接的状态，连接跟踪是防火墙模块的状态检测的基础，同时也是地址转换中实 现SNAT和DNAT的前提。

注意 nf_conntrack 模块在 kernel 2.6.15 被引入，支持 IPv4 和 IPv6，取代之前只支持 IPv4 的 ip_connktrack，它主要用来跟踪连接的状态，方便一些问题的定位。

如果 Linux 服务器上面需要使用 NAT 功能，可以使用它记录一些连接跟踪的状态，比如经常使用 iptables 的 NAT 功能 。

NAT 即根据转发规则修改 IP 包的源/目标地址，靠 conntrack 记录才能让返回的数据包能路由到发送请求的机器上面，经常使用的地址伪装功能。

连接跟踪是由 iptables 的 state 选项来实现的，它可以记录并检测每个连接的状态并在内存中维护一个跟踪状态表，这个表即连接跟踪状态表。

state：这个模块能够跟踪每个分组的连接状态，通过它把连接状态记录到 conntrack 表中（连接跟踪状态表）。

状态选项含义
INVALID表示分组对应的连接是未知的；
ESTABLISHED表示分组对应的连接已经进行了双向分组传输，也就是说连接已经建立；
NEW表示这个分组需要发起一个连接，或者说，分组对应的连接在两个方向上都没有进行过分组传输；
RELATED表示分组要发起一个新的连接，但这个连接和一个现有的连接有关；例如：FTP 的数据传输连接和控制连接之间就是 RELATED 关系。

接跟踪状态如何工作

我们知道 Linux 服务器的每个数据包分组将以以下的顺序：PREROUTING -- FORWARD -- POSTROUTING 。

企业微信截图_20240218100304.png

(图片来源于网络)

先经过 PREROUTING 链，此时如果必要的话，就对这个分组进行目的网络地址转换 (DNAT) 和 mangle 处理，同时， iptables 的状态检测机制将重组分组，并且以以下某种方式跟踪其状态：

\1. 分组是否匹配状态表中的一个已经实现 (ESTABLISHED) 的连接；

\2. 分组是否是和状态表中某个 UDP/TCP 连接相关(RELATED) 的一个 ICMP 分组；

\3. 分组是否为发起的新 (NEW) 连接；

\4. 如果分组和任何连接状态选项无关，就被认为是无效(INVALID)的。

再经过 FORWARD 链把分组的状态和过滤表中的规则进行匹配，如果分组状态与相应规则都无法匹 配，就使用默认的策略进行处理；

最后 POSTROUTING 链如果有必要的话，就会对分组进行源网络地址转换(SNAT)等。

数据包分组都必须和过滤表的规则进行匹配比较，如果规则进行了修改，要拒绝所有的网络流量，那么即使数据包的分组状态匹配状态表中的某一个，如：ESTABLISHED，那么连接状态跟踪表中，也不会被记录，也将被拒之门外。

安装查看连接跟踪状态工具

yum -y install conntrack

注意需要先开启记录功能才可以使用连接跟踪表，默认是没有开启的，下面我们对 TCP 、UDP、ICMP 三个协议分别进行分析。

TCP 实验分析

TCP 开启连接状态跟踪

[root@vm-os-centos7 ~]# iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
[root@vm-os-centos7 ~]# iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

TCP 测试

[root@vm-os-centos7 ~]# curl http://www.baidu.com
<!DOCTYPE html>
<!--STATUS OK--><html> <head><meta http-equiv=content-type content=text/html;charset=utf-8><meta http-equiv=X-UA-Compatible content=IE=Edge><meta content=always name=referrer><link rel=stylesheet type=text/css href=http://s1.bdstatic.com/r/www/cache/bdorz/baidu.min.css><title>百度一下，你就知道</title></head> <body link=#0000cc> <div id=wrapper> <div id=head> <div class=head_wrapper> <div class=s_form> <div class=s_form_wrapper> <div id=lg> <img hidefocus=true src=//www.baidu.com/img/bd_logo1.png width=270 height=129> </div> <form id=form name=f action=//www.baidu.com/s class=fm> <input type=hidden name=bdorz_come value=1> <input type=hidden name=ie value=utf-8> <input type=hidden name=f value=8> <input type=hidden name=rsv_bp value=1> <input type=hidden name=rsv_idx value=1> <input type=hidden name=tn value=baidu><span class="bg s_ipt_wr"><input id=kw name=wd class=s_ipt value maxlength=255 autocomplete=off autofocus></span><span class="bg s_btn_wr"><input type=submit id=su value=百度一下 class="bg s_btn"></span> </form> </div> </div> <div id=u1> <a href=http://news.baidu.com name=tj_trnews class=mnav>新闻</a> <a href=http://www.hao123.com name=tj_trhao123 class=mnav>hao123</a> <a href=http://map.baidu.com name=tj_trmap class=mnav>地图</a> <a href=http://v.baidu.com name=tj_trvideo class=mnav>视频</a> <a href=http://tieba.baidu.com name=tj_trtieba class=mnav>贴吧</a> <noscript> <a href=http://www.baidu.com/bdorz/login.gif?login&amp;tpl=mn&amp;u=http%3A%2F%2Fwww.baidu.com%2f%3fbdorz_come%3d1 name=tj_login class=lb>登录</a> </noscript> <script>document.write('<a href="http://www.baidu.com/bdorz/login.gif?login&tpl=mn&u='+ encodeURIComponent(window.location.href+ (window.location.search === "" ? "?" : "&")+ "bdorz_come=1")+ '" name="tj_login" class="lb">登录</a>');</script> <a href=//www.baidu.com/more/ name=tj_briicon class=bri style="display: block;">更多产品</a> </div> </div> </div> <div id=ftCon> <div id=ftConw> <p id=lh> <a href=http://home.baidu.com>关于百度</a> <a href=http://ir.baidu.com>About Baidu</a> </p> <p id=cp>&copy;2017&nbsp;Baidu&nbsp;<a href=http://www.baidu.com/duty/>使用百度前必读</a>&nbsp; <a href=http://jianyi.baidu.com/ class=cp-feedback>意见反馈</a>&nbsp;京ICP证030173号&nbsp; <img src=//www.baidu.com/img/gs.gif> </p> </div> </div> </div> </body> </html>
[root@vm-os-centos7 ~]#

TCP 连接跟踪查看

[root@vm-os-centos7 ~]# conntrack -E -o ktimestamp
    [NEW] tcp 6 120 SYN_SENT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 [UNREPLIED] src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770
 [UPDATE] tcp 6 60 SYN_RECV src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770
 [UPDATE] tcp 6 432000 ESTABLISHED src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 120 FIN_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 60 CLOSE_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 30 LAST_ACK src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 120 TIME_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
。。。

连接的协议是 TCP (TCP 协议号 6)，第四列是一个倒计时的秒数，是超时时间，接下来是当前时间点的状态，然后是请求方向上的源、目的地址和源、目的端口，响应方向上的源、目的地址和源、目的端口。

第一行 NEW 代表初始请求进入 OUTPUT 链，并且规则允许通过，此时就记录在这个连接跟踪表中，TCP 连接状态是 SYN_SENT，连接被标记为 UNREPLIED。[UNREPLIED] 表示这个连接还没有收到任何回应。

三次握手与连接跟踪状态分析

TCP 协议是有状态的协议，并且具有很多关于 iptables 状态机制的详细信息。

首先，客户端程序发出一个同步请求(发出一个 SYN 分组)，初始 SYN 分组进入到OUTPUT链，并且防火樯规则允许这个分组通过，所以状态表项为：

[NEW] tcp 6 120 SYN_SENT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 [UNREPLIED] src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770

TCP 连接状态是 SYN_SENT，连接被标记为 UNREPLIED。

其次，服务器端回应一个 SYN|ACK 分组，客户端一旦得到响应，这个TCP连接表项变为：

[UPDATE] tcp 6 60 SYN_RECV src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770

连接的状态变为 SYN_RECV，UNREPLIED 标志被清除。

最后，客户端返回一个ACK 分组，完成三次握手的过程，ACK 分组到达后，我们首先对其序

列号进行一些检查，如果正确，就把这个连接的状态变为 ESTABLISHED，并且使

用 ASSURED 标记这个连接，如下：

[UPDATE] tcp 6 432000 ESTABLISHED src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

四次挥手与连接跟踪状态分析

首先. 客户端发送了 FIN 后，客户端连接跟踪状态就变为了FIN_WAIT，如下：

[UPDATE] tcp 6 120 FIN_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

其次. 当客户端收到对方的ACK后，客户端连接跟踪状态变为了 CLOSE_WAIT,如下：

[UPDATE] tcp 6 60 CLOSE_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

再次. 当客户端再次收到对方的FIN时，客户端连接跟踪状态变为了LAST_ACK，如下：

[UPDATE] tcp 6 30 LAST_ACK src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

最后. 客户端发送最后的ACK后，客户端连接跟踪状态变为了TIME_WAIT。

[UPDATE] tcp 6 120 TIME_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

连接关闭后，主动关闭方（这里用例客户端）进入 TIME_WAIT 状态，缺省时间是2MSL（报文最大生存时间，2分钟），是为了让数据包能完全通过各种规则的检查，并且网络正常，不阻塞的情况下到达对方。为什么是2MSL？1. 最后一个ACK发出去之后，服务器端在超时时间内未收到，会重新发送 FIN，客户端再发送 ACK；2. 如果客户端没有TIME_WAIT状态，客户端直接进入CLOSE，客户端之前使用的源端口，就被释放掉，很有可能客户端的端口被新连接再次使用，此时如果先前发送的 ACK 在网络链路上面丢了，服务器端重新发送了FIN，会造成客户端异常关闭连接，所以TIME_WAIT必须存在。

如果连接是被RST包重置的，就直接变为CLOSE了。这意味着在关闭之前只有10秒的默认时间，RST包是不需要确认的，它会直接关闭连接。

UDP 实验分析

UDP 开启连接状态跟踪

[root@vm-os-centos7 ~]# iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
[root@vm-os-centos7 ~]# iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT

UDP 测试

[root@vm-os-centos7 ~]# dig -t A www.baidu.com @114.114.114.114

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> -t A www.baidu.com @114.114.114.114
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63201
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.baidu.com.INA

;; ANSWER SECTION:
www.baidu.com.543INCNAMEwww.a.shifen.com.
www.a.shifen.com.214INA180.101.49.11
www.a.shifen.com.214INA180.101.49.12

;; Query time: 25 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: 四 8月 20 11:18:06 CST 2020
;; MSG SIZE rcvd: 101

[root@vm-os-centos7 ~]#

UDP 连接跟踪查看

[root@vm-os-centos7 ~]# conntrack -E -o ktimestamp
    [NEW] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 [UNREPLIED] src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768
 [UPDATE] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768
[DESTROY] udp 17 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768
。。。

UDP 连接跟踪状态分析

UDP (用户数据包协议)是一种无状态协议，虽然协议没有序列号，但是我们还可以使用其它的一些信息跟踪 UDP 连接的状态。

第一行，UDP 代表UDP协议，17 是 UDP 协议编号，30是超时时间，单位是秒，接下来是请求方向上的源、目的地址和源、目的端口，响应方向上的源、目的地址和源、目的端口，这个连接使用 UNREPLIED 标记，表示还没有收到应答；

[NEW] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 [UNREPLIED] src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768

注意一个UDP请求应答的时间是30秒，如果在这个时间内没有收到下面的应答响应，这个表项就会被删除，一旦收到第一个包的回应，[UNREPLIED]标记就会被删除，连接就被认为是 ESTABLISHED 的，但在记录里并不显示ESTABLISHED标记。

[UPDATE] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768

接收到数据后，此连接就此销毁，如下：

[DESTROY] udp 17 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768

ICMP 实验分析

ICMP 开启连****接状态跟踪

[root@vm-os-centos7 ~]# iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED, RELATED
-j ACCEPT
[root@vm-os-centos7 ~]# iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j
ACCEPT

ICMP 测试

[root@vm-os-centos7 ~]# ping -c 3 www.baidu.com
PING www.baidu.com (180.101.49.12) 56(84) bytes of data.
64 bytes from www.baidu.com (180.101.49.12): icmp_seq=1 ttl=50 time=25.8 ms
64 bytes from www.baidu.com (180.101.49.12): icmp_seq=2 ttl=50 time=26.3 ms
64 bytes from www.baidu.com (180.101.49.12): icmp_seq=3 ttl=50 time=25.6 ms

--- www.baidu.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 25.622/25.931/26.305/0.338 ms
[root@vm-os-centos7 ~]#

ICMP 连接跟踪查看

[root@vm-os-centos7 ~]# conntrack -E -o ktimestamp|grep 180.101.49.12
    [NEW] icmp 1 30 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18849 [UNREPLIED] src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18849
 [UPDATE] icmp 1 29 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18849 src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18849
[DESTROY] icmp 1 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18840 src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18840
[DESTROY] icmp 1 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18849 src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18849
。。。
[root@vm-os-centos7 ~]#

ICP 连接跟踪分析

ICMP 也是一种无状态协议，它只是用来控制而不是建立连接。

ICMP 包有很多类型，但只有四种类型有应答包，它们是回显请求和应答（Echo request and reply），时间戳请求和应答（Timestamp request and reply）（这种类型已经废除），信息请求和应答（Information request and reply），还有地址掩码请求和应答（Address mask request and reply），这些包有两种状态，NEW和ESTABLISHED ，回显请求是经常使用的，比如ping命令就用的到，地址掩码请求也有时会使用。

连接跟踪查看

查看方式

/proc/net/nf_conntrack 文件中的内容与使用 conntrack 命令是一样的：

conntrack -L -o extended 或cat proc/net/nf_conntrack

网络层协议名、网络层协议编号、传输层协议名、传输层协议编号、记录失效前剩余秒数、连接状态（不是所有协议都有），[ASSURED] 代表请求和响应都有流量， [UNREPLIED] 表示没收到响应，哈希表满的时候这些连接先扔掉，下面几种常用查看方式，都给出两种查看方式，并且结果是一样的。

TCP/UDP 连接数统计

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '{sum[$3]++} END {for(i in sum) print i, sum[i]}' && echo "-----------" && cat proc/net/nf_conntrack | awk '{sum[$3]++} END {for(i in sum) print i, sum[i]}'
conntrack v1.4.4 (conntrack-tools): 2752 flow entries have been shown.
udp 121
tcp 2631
-----------
udp 121
tcp 2631
[root@k8s-master-1 ~]#

TCP 连接状态统计

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}' && echo "-----------" && cat proc/net/nf_conntrack | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}'
conntrack v1.4.4 (conntrack-tools): 2115 flow entries have been shown.
CLOSE_WAIT 11
CLOSE 18
ESTABLISHED 1401
SYN_SENT 13
TIME_WAIT 496
-----------
CLOSE_WAIT 11
CLOSE 18
ESTABLISHED 1401
SYN_SENT 13
TIME_WAIT 496
[root@k8s-master-1 ~]#

IP层协议统计

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '{sum[$1]++} END {for(i in sum) print i, sum[i]}' && echo "-----------" && cat proc/net/nf_conntrack | awk '{sum[$1]++} END {for(i in sum) print i, sum[i]}'
conntrack v1.4.4 (conntrack-tools): 2822 flow entries have been shown.
ipv4 2822
-----------
ipv4 2822
[root@k8s-master-1 ~]#

连接数最多的10个IP

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10 && echo "-----------" && cat proc/net/nf_conntrack | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
conntrack v1.4.4 (conntrack-tools): 2821 flow entries have been shown.
    385 100.72.16.4
    149 100.71.57.51
    149 100.71.57.21
    149 100.71.57.14
    148 100.71.57.46
    148 100.71.57.31
    142 127.0.0.1
    139 100.71.57.62
    134 100.71.57.57
    119 100.72.128.2
-----------
    385 100.72.16.4
    149 100.71.57.51
    149 100.71.57.21
    149 100.71.57.14
    148 100.71.57.46
    148 100.71.57.31
    142 127.0.0.1
    139 100.71.57.62
    134 100.71.57.57
    119 100.72.128.2
[root@k8s-master-1 ~]#

参数详情

回到文章的开头，当 Linux 内核报 nf_conntrack: table full, dropping packet. 错误时，这是因为服务器开启了 iptables 防火墙并设置了连接状态跟踪，当服务器收到大量的连接时，iptables 会把所有的连接都做链接跟踪处理，iptables 它会产生一个链接状态跟踪表，当这个表满时，就会出现上面的错误，可以通过修改以下参数解决。

[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_tcp_timeout_established
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
[root@vm-os-centos7 ~]# sysctl -a |grep net.nf_conntrack_max
net.nf_conntrack_max = 262144
[root@vm-os-centos7 ~]#

上面的nf_conntrack_tcp_timeout_established 默认是5天（432000/86400=5），建议修改小一些，比如1天或者10个小时36000秒，这种状态多的话，会占用端口和连接数；net.nf_conntrack_max 状态表满时，及时调整这个值即可，下面这些都是连接跟踪中的TCP状态的超时参数，可以根据需要进行设置；

[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_tcp_timeout
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
[root@vm-os-centos7 ~]#

下面是udp及icmp的超时参数，如有需要，也可以自行调整。

[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_udp_timeout
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_icmp_timeout
net.netfilter.nf_conntrack_icmp_timeout = 30
[root@vm-os-centos7 ~]#
0
网络

  1. 支付宝打赏

    qrcode alipay

  2. 微信打赏

    qrcode weixin
版权归属： Administrator
本文链接： https://funkygod.vip/archives/1708221753094
许可协议： 本文使用《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》协议授权

评论区