服务器几万 TIME_WAIT 要紧吗：4 个参数与 3 类真实影响

我不会起名字322· 后端 / 算法 / 数据库 技术栈 力扣 Hot100 Go 项目 Redis MySQL文章目录服务器几万 TIME_WAIT 要紧吗4 个参数与 3 类真实影响一、先给结论二、TIME_WAIT 为什么存在三、3 类真实影响影响 1端口资源耗尽唯一真正致命的影响 2内存与连接跟踪表影响 3对长连接网关的实际影响四、4 个参数以及各自的副作用参数 1net.ipv4.ip_local_port_range参数 2net.ipv4.tcp_tw_reuse参数 3net.ipv4.tcp_tw_recycle参数 4net.ipv4.tcp_max_tw_buckets五、真正该做的三件事六、带走物服务器几万 TIME_WAIT 要紧吗4 个参数与 3 类真实影响一、先给结论线上看到netstat里几万条TIME_WAIT绝大多数情况下不用管。它不占文件描述符、不占内存多少、也不会让服务变慢。真正需要处理的只有一种情况这台机器是主动发起连接的一方并且端口快被占满了。判断标准很简单——看你这几万条 TIME_WAIT 的本地端口是哪一侧# 看 TIME_WAIT 里本地地址的一端ss-tanstate time-wait|awk{print $4}|awk-F:{print $NF}|sort|uniq-c|sort-rn|head如果本地端口集中在一个或少数几个端口比如 8080、3306说明你是服务端被动关闭方 → 无害如果本地端口散落在 32768~60999 这个范围说明你是客户端主动发起方 → 需要关注。二、TIME_WAIT 为什么存在TCP 是全双工的关闭时每个方向都要单独关。主动关闭方发完最后一个 ACK 之后不会立刻释放而是进入TIME_WAIT等2MSLRFC 793 定义 MSL 为 2 分钟Linux 实际固化成 60 秒所以 TIME_WAIT 约 60 秒。它有两个不可替代的作用作用 1保证最后一个 ACK 能到对端。如果这个 ACK 丢了对端会重发 FIN。此时主动关闭方必须还记得这条连接才能重发 ACK。如果直接释放对端重发的 FIN 会被回一个 RST对端就会认为这次关闭是异常终止——日志里会冒出Connection reset by peer而实际上只是一次正常的关闭。作用 2让旧连接的残留报文在网络里自然消失。TCP 连接由四元组唯一标识。如果没有 TIME_WAIT旧连接关闭后立刻用同一个四元组建新连接那么旧连接迟到的数据包会被新连接当作正常数据收上来造成数据错乱。等 2MSL 就是为了让这些旧报文在路上死掉。所以 TIME_WAIT 不是垃圾状态它是协议正确性的一部分。看到就想清掉是典型的把症状当病因。三、3 类真实影响影响 1端口资源耗尽唯一真正致命的作为客户端时每建一条连接都要占一个本地临时端口。范围是cat/proc/sys/net/ipv4/ip_local_port_range# 32768 60999 → 约 28231 个如果这台机器短连接发得很凶比如压测、爬虫、没有连接池的 HTTP 客户端、每次请求都新建的数据库连接TIME_WAIT 会在这个范围里堆积。堆满之后新连接会直接失败Cannot assign requested address connect: Cannot assign requested address (errno 99)注意服务端监听的那一个端口比如 8080不会被占满。服务端一个端口可以接受几万条连接因为连接是按四元组区分的。所以服务端 TIME_WAIT 多和客户端 TIME_WAIT 多是两件完全不同的事。影响 2内存与连接跟踪表每条 TIME_WAIT 连接大约占几百字节到几 KB 的内核内存。几万条加起来也就几十 MB一般不构成问题。但如果开了nf_conntrack比如机器上有 iptables NAT、或者跑着 Kubernetes每条连接还会在 conntrack 表里占一项。表满时内核会直接丢包dmesg|grep-inf_conntrack: table full# nf_conntrack: table full, dropping packet这种情况要调的是 conntrack 表大小不是 TIME_WAIT。影响 3对长连接网关的实际影响在 Nginx 这类反代上如果上游是短连接Nginx 侧会积累大量 TIME_WAIT。它本身不会让请求变慢但会放大影响 1 和影响 2。解决办法通常是把上游改成 keepalive而不是调内核参数。四、4 个参数以及各自的副作用参数 1net.ipv4.ip_local_port_rangesysctl-wnet.ipv4.ip_local_port_range1024 65535把临时端口范围拉到最大可用端口从 ~28k 涨到 ~64k。副作用1024 以下的端口是特权端口建议从 10000 起另外范围太大可能和你自己监听的端口冲突。这是四个参数里最安全的一个值得先做。参数 2net.ipv4.tcp_tw_reusesysctl-wnet.ipv4.tcp_tw_reuse1允许内核在新建连接时复用处于 TIME_WAIT 状态的连接前提是新的时间戳严格大于旧连接tcp_timestamps必须开默认就是开的。这只对客户端主动发起方生效对服务端监听端口无效——这正好符合我们的场景。副作用很小值得一开。参数 3net.ipv4.tcp_tw_recycle# 不要开sysctl-wnet.ipv4.tcp_tw_recycle0这个参数在Linux 4.12 之后已经被移除原因是它会基于 per-host 的时间戳缓存做判断在 NAT 环境下比如公司出口、容器 SNAT会把大量正常连接判为旧连接而直接丢弃。表现为一部分用户死活连不上而且现象和地域、运营商相关极难排查。结论不要开也不需要开。tcp_tw_reuse已经够用了。参数 4net.ipv4.tcp_max_tw_bucketssysctl-wnet.ipv4.tcp_max_tw_buckets262144这是 TIME_WAIT 数量的上限超了之后内核会直接销毁多余的 TIME_WAIT 并打日志TCP: time wait bucket table overflow它是个保险丝不是优化项。把它调小来减少 TIME_WAIT是错误用法——那只是让内核更早地破坏协议正确性省下的内存远不如引入的问题多。五、真正该做的三件事调参数永远是第二选择先做这三件1. 短连接改长连接。这是根本解法。HTTP 客户端开 keepalive、数据库连接用连接池、gRPC 本身就是长连接。一次改造抵得上所有内核参数。// Go 的 http.Transport 默认就是 keepalive但默认值偏保守tr:http.Transport{MaxIdleConns:1000,MaxIdleConnsPerHost:100,// 默认只有 2高并发下会疯狂建新连接IdleConnTimeout:90*time.Second,}client:http.Client{Transport:tr,Timeout:5*time.Second}MaxIdleConnsPerHost默认值是 2这是 Go 服务在压测时 TIME_WAIT 暴涨的最常见原因。2. 让对端主动关闭。如果你是服务端能设计成由客户端主动关闭TIME_WAIT 就落在客户端身上。HTTP 里对应的是Connection: close由谁发。3. 监控端口使用率而不是 TIME_WAIT 数量。# 真正该告警的是这个ss-tanstate time-wait( sport :32768 and sport :60999 )|wc-l# 对比cat/proc/sys/net/ipv4/ip_local_port_range六、带走物现象要不要处理做什么服务端端口上几万 TIME_WAIT不用管无害服务端不消耗临时端口客户端临时端口段大量 TIME_WAIT要调ip_local_port_rangetcp_tw_reuse出现Cannot assign requested address立刻上述两个参数 改长连接出现conntrack table full立刻调nf_conntrack_max不是调 TIME_WAIT单纯看着多不用管TIME_WAIT 是协议正确性的一部分一句话记住TIME_WAIT 本身不可怕可怕的是主动关闭方 短连接 临时端口耗尽这三点同时成立。