TCP 连接数打满怎么办?深入理解 Linux 内核网络参数调优

监控系统突然报警：核心API服务大面积超时。登上服务器一看，netstat输出的TIME_WAIT连接数已经突破20万，新连接根本建立不起来。整个团队的周末计划泡汤了，而我在机房待到了凌晨三点。

那次事故让我彻底搞清楚了Linux内核网络栈的工作原理。这篇文章会把TCP连接的各种状态、内核参数的调优逻辑、以及生产环境的监控方案讲透。

TCP连接状态快速回顾

在深入调优之前，必须先理解TCP的状态机。很多人对TIME_WAIT、CLOSE_WAIT这些状态似懂非懂，调参时就容易出问题。

                              +---------+                              |  CLOSED |                              +---------+                                   |                   主动打开         | 被动打开                 (SYN发送)          | (收到SYN)                    |               |                    v               v              +-----------+   +-----------+              |  SYN_SENT |   | SYN_RCVD  |              +-----------+   +-----------+                    |               |           (收到SYN+ACK)      (收到ACK)                    |               |                    v               v              +-----------+   +-----------+              |           |   |           |              |       ESTABLISHED          |              |                            |              +----------------------------+                           |            主动关闭        |        被动关闭           (发送FIN)       |       (收到FIN)                |          |          |                v          |          v          +-----------+    |    +-----------+          | FIN_WAIT1 |    |    | CLOSE_WAIT|          +-----------+    |    +-----------+                |          |          |           (收到ACK)       |     (发送FIN)                |          |          |                v          |          v          +-----------+    |    +-----------+          | FIN_WAIT2 |    |    | LAST_ACK  |          +-----------+    |    +-----------+                |          |          |           (收到FIN)       |     (收到ACK)                |          |          |                v          |          v          +-----------+    |    +-----------+          | TIME_WAIT |----+    |  CLOSED   |          +-----------+         +-----------+                |           (等待2MSL)                |                v          +-----------+          |  CLOSED   |          +-----------+

环境信息

操作系统：CentOS 7.x / RHEL 8.x / Ubuntu 20.04+内核版本：3.10+ / 4.x / 5.x适用场景：高并发Web服务、API网关、微服务架构

快速诊断命令

当你怀疑TCP连接有问题时，第一步是搞清楚当前的连接分布：

# 统计各状态连接数netstat -ant | awk '/^tcp/ {++state[$NF]} END {for(k in state) print k, state[k]}' | sort -k2 -rn# 使用ss命令（更快）ss -ant | awk 'NR>1 {++state[$1]} END {for(k in state) print k, state[k]}' | sort -k2 -rn# 典型输出示例：# TIME_WAIT 185234# ESTABLISHED 12456# CLOSE_WAIT 3421# SYN_RECV 234# FIN_WAIT2 567# LAST_ACK 89

TIME_WAIT问题深度分析

TIME_WAIT是我遇到最多的问题。这个状态存在的意义是确保网络中残留的数据包不会被新连接误收。标准等待时间是2MSL（Maximum Segment Lifetime），Linux默认是60秒。

问题来了：如果你的服务每秒有1万个短连接，60秒就会积累60万个TIME_WAIT。而Linux默认的本地端口范围是32768-60999，只有28000多个端口，很快就会耗尽。

# 查看当前本地端口范围cat /proc/sys/net/ipv4/ip_local_port_range# 默认输出：32768  60999# 查看TIME_WAIT数量ss -ant state time-wait | wc -l# 查看TIME_WAIT连接详情ss -ant state time-wait | head -20

CLOSE_WAIT问题诊断

CLOSE_WAIT比TIME_WAIT更危险，因为它意味着应用程序bug。当对端发送FIN后，本地进入CLOSE_WAIT状态等待应用层调用close()。如果应用层有bug不调用close，连接就会一直卡在这个状态。

# 查看哪个进程持有CLOSE_WAIT连接ss -antp state close-wait# 输出示例：# CLOSE-WAIT  1      0      10.0.0.100:8080   10.0.0.50:45678   users:(("java",pid=12345,fd=89))# 根据进程ID进一步分析lsof -p 12345 | grep CLOSE | wc -l

我曾经遇到过一个Java应用，因为HttpClient连接池配置错误，导致连接不被复用也不被关闭，一周累积了10万个CLOSE_WAIT，最终OOM。

TIME_WAIT调优

# /etc/sysctl.conf# 1. 开启TIME_WAIT重用（重要！）# 允许将TIME_WAIT的socket用于新的TCP连接net.ipv4.tcp_tw_reuse = 1# 2. TIME_WAIT快速回收（慎用！）# 在NAT环境下会导致连接问题，已在内核4.12中移除# net.ipv4.tcp_tw_recycle = 1  # 不推荐# 3. 调整TIME_WAIT bucket数量# 超过这个数量的TIME_WAIT会被直接销毁net.ipv4.tcp_max_tw_buckets = 200000# 4. 减少FIN_TIMEOUT（影响FIN_WAIT2和TIME_WAIT）net.ipv4.tcp_fin_timeout = 15# 5. 扩大本地端口范围net.ipv4.ip_local_port_range = 102465535

关于tcp_tw_recycle的血泪教训：这个参数会记录每个对端IP的时间戳，如果新连接的时间戳小于记录值，就会拒绝连接。在NAT环境下，多个客户端共享一个IP，它们的时间戳不一致，导致部分连接莫名其妙被拒绝。我们曾经因为这个参数，让一个大客户无法访问服务长达两天。

连接建立阶段调优

# SYN队列（半连接队列）# 收到SYN后，连接进入SYN_RECV状态，存储在这个队列net.ipv4.tcp_max_syn_backlog = 65535# Accept队列（全连接队列）# 三次握手完成后，连接进入ESTABLISHED，等待accept()net.core.somaxconn = 65535# SYN重试次数（客户端）net.ipv4.tcp_syn_retries = 2# SYN+ACK重试次数（服务端）net.ipv4.tcp_synack_retries = 2# 开启SYN Cookies防护# 在SYN队列满时启用，防止SYN Floodnet.ipv4.tcp_syncookies = 1

这里有个常见误区：很多人以为设置了tcp_max_syn_backlog就万事大吉了，却忘了somaxconn。实际上全连接队列的大小是min(backlog, somaxconn)，backlog是应用程序listen()时传入的参数。

如何确认队列是否溢出：

# 查看SYN队列溢出次数netstat -s | grep -i "syn"# 或cat /proc/net/netstat | grep -i syn# 查看Accept队列溢出次数netstat -s | grep -i "listen"# 输出：XXX times the listen queue of a socket overflowed# 查看当前队列状态ss -lnt | head# Recv-Q: 当前在accept队列中的连接数# Send-Q: accept队列大小

连接保活参数

# TCP Keepalive配置# 空闲多久后开始发送探测包net.ipv4.tcp_keepalive_time = 600# 探测包发送间隔net.ipv4.tcp_keepalive_intvl = 15# 探测失败多少次判定连接失效net.ipv4.tcp_keepalive_probes = 3

注意：这些参数只对开启了SO_KEEPALIVE选项的socket生效。应用层通常会自己实现心跳机制，这些内核参数是兜底方案。

内存和缓冲区

# TCP内存使用限制（单位：page，通常4KB）# 三个值分别是：最小值、默认值、最大值net.ipv4.tcp_mem = 2621445242881048576# 单个socket接收缓冲区net.ipv4.tcp_rmem = 40968738016777216# 单个socket发送缓冲区net.ipv4.tcp_wmem = 40966553616777216# 系统级别的接收/发送缓冲区最大值net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.core.rmem_default = 262144net.core.wmem_default = 262144

完整的生产配置

根据多年实践，下面是一套适用于高并发服务的内核参数配置：

# /etc/sysctl.d/99-tcp-tuning.conf# 文件描述符fs.file-max = 2000000fs.nr_open = 2000000# 连接跟踪（如果用iptables）net.netfilter.nf_conntrack_max = 2000000net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30net.netfilter.nf_conntrack_tcp_timeout_established = 1200# 队列大小net.core.somaxconn = 65535net.core.netdev_max_backlog = 65535net.ipv4.tcp_max_syn_backlog = 65535# TIME_WAITnet.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_max_tw_buckets = 200000net.ipv4.tcp_fin_timeout = 15# 端口范围net.ipv4.ip_local_port_range = 102465535# 缓冲区net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.core.rmem_default = 262144net.core.wmem_default = 262144net.ipv4.tcp_rmem = 40968738016777216net.ipv4.tcp_wmem = 40966553616777216net.ipv4.tcp_mem = 78643210485761572864# TCP选项net.ipv4.tcp_syncookies = 1net.ipv4.tcp_syn_retries = 2net.ipv4.tcp_synack_retries = 2net.ipv4.tcp_keepalive_time = 600net.ipv4.tcp_keepalive_intvl = 15net.ipv4.tcp_keepalive_probes = 3# 路由缓存net.ipv4.route.gc_timeout = 100# 窗口缩放net.ipv4.tcp_window_scaling = 1net.ipv4.tcp_sack = 1net.ipv4.tcp_timestamps = 1

应用配置：

# 加载配置sysctl --system# 验证配置sysctl -a | grep -E "tcp_tw_reuse|somaxconn|tcp_max_syn"

场景一：短连接服务（API网关）

短连接场景TIME_WAIT问题最严重。除了内核参数，还需要从架构层面优化：

# 1. 尽可能使用长连接# Nginx配置upstream backend {    keepalive 1000;}# 2. 客户端主动关闭改为服务端主动关闭# 谁主动关闭谁承担TIME_WAIT# 可以通过调整keepalive_timeout让服务端先关闭keepalive_timeout 0;  # 让客户端先关闭# 3. 使用连接池# 各语言的HTTP Client都支持连接池

场景二：微服务架构（大量内部调用）

微服务间调用频繁，容易出现连接问题：

# 监控每对服务间的连接数ss -ant | awk '{print $4, $5}' | sort | uniq -c | sort -rn | head -20# 如果某对服务间连接数异常多，检查：# 1. 是否使用了连接池# 2. 连接池大小是否合理# 3. 是否有连接泄漏

场景三：代理服务器（两端都有连接）

Nginx、HAProxy这类代理，既是客户端又是服务端，端口消耗double：

# 查看代理服务器的端口使用ss -ant | awk '{print $4}' | cut -d: -f2 | sort -n | uniq -c | sort -rn | head# 如果本地端口耗尽，可以：# 1. 扩大端口范围# 2. 使用多个本地IP# 3. 后端使用长连接# 使用多个本地IP连接后端upstream backend {    server 10.0.0.1:8080;    server 10.0.0.2:8080;}# Nginx会自动轮询使用多个本地IP

关键监控指标

#!/bin/bash# tcp_monitor.sh - TCP连接监控脚本whiletrue; do    timestamp=$(date '+%Y-%m-%d %H:%M:%S')    # 各状态连接数    established=$(ss -ant state established | wc -l)    time_wait=$(ss -ant state time-wait | wc -l)    close_wait=$(ss -ant state close-wait | wc -l)    syn_recv=$(ss -ant state syn-recv | wc -l)    fin_wait=$(ss -ant state fin-wait-1 | wc -l)    fin_wait2=$(ss -ant state fin-wait-2 | wc -l)    # SYN队列溢出    syn_overflow=$(netstat -s | grep "SYNs to LISTEN" | awk '{print $1}')    # Accept队列溢出    accept_overflow=$(netstat -s | grep "listen queue" | awk '{print $1}')    # 输出    echo"$timestamp ESTABLISHED=$established TIME_WAIT=$time_wait CLOSE_WAIT=$close_wait SYN_RECV=$syn_recv"    # 告警检查    if [ $time_wait -gt 100000 ]; then        echo"ALERT: TIME_WAIT exceeds 100000!"    fi    if [ $close_wait -gt 1000 ]; then        echo"ALERT: CLOSE_WAIT exceeds 1000, check application!"    fi    sleep 10done

Prometheus监控配置

使用node_exporter可以获取TCP连接指标：

# prometheus告警规则groups:-name:tcp_alerts    rules:      -alert:HighTimeWaitConnections        expr:node_netstat_Tcp_TimeWait>100000        for:5m        labels:          severity:warning        annotations:          summary:"TIME_WAIT连接数过高"          description:"当前TIME_WAIT: {{ $value }}"      -alert:CloseWaitAccumulation        expr:node_netstat_Tcp_CloseWait>1000        for:10m        labels:          severity:critical        annotations:          summary:"CLOSE_WAIT连接积压"          description:"可能存在连接泄漏，当前CLOSE_WAIT: {{ $value }}"      -alert:SynFloodSuspected        expr:rate(node_netstat_Tcp_SynRecv[1m])>10000        for:2m        labels:          severity:critical        annotations:          summary:"疑似SYN Flood攻击"

快速诊断checklist

当TCP连接出问题时，按以下顺序排查：

# 1. 查看连接状态分布ss -ant | awk 'NR>1 {++state[$1]} END {for(k in state) print k, state[k]}'# 2. 查看队列溢出netstat -s | grep -E "overflow|prune|SYN"# 3. 查看端口使用情况ss -ant | awk '{print $4}' | grep -oP ':\d+$' | sort | uniq -c | sort -rn | head -10# 4. 查看文件描述符使用cat /proc/sys/fs/file-nr# 5. 查看conntrack使用（如有）cat /proc/sys/net/netfilter/nf_conntrack_countcat /proc/sys/net/netfilter/nf_conntrack_max# 6. 查看内核参数当前值sysctl -a | grep -E "somaxconn|tcp_max_syn_backlog|tcp_tw|tcp_fin"

核心调优参数速查

调优原则

🔹先监控后调优，有数据支撑

🔹每次只改一个参数，观察效果

🔹保留调优前的配置备份

🔹不同内核版本参数行为可能不同，需要测试

🔹应用层优化（长连接、连接池）比内核调优更重要

进阶方向

🔹eBPF进行深度TCP分析

🔹TCP拥塞控制算法调优（BBR、CUBIC）

🔹DPDK等用户态协议栈

🔹容器网络的特殊调优

柯普瑞企业IT学院

      南京柯普瑞信息技术有限公司长期专注于推动政府和企业数字化建设与发展，为客户提供包括：数字化培训、IT运维服务、信息安全服务、商业智能服务、OA应用服务及人力资源外包等专业化服务。经过多年的发展，柯普瑞形成了以南京公司为核心，另设杭州公司、上海公司布局华东，辐射全国的业务服务形态，服务超过5000家客户，覆盖运营商、金融、电力、石化、烟草、税务、公安、社保、财政等诸多行业，获得了广泛的客户认可！

      柯普瑞企业IT学院创始于2002年，隶属南京柯普瑞信息技术有限公司。致力于为政府及企业客户提供数字化专业人才培养服务解决方案，帮助客户进行持续性专业化人才梯队建设和培养。公司拥有一支由业内资深专家、厂商资深认证讲师组成的百人专家型职业讲师团队，以数字化赋能为核心，围绕全球知名IT厂商及国内信创生态主流厂商的产品和技术，提供包括 网络、主机、软件开发、大型数据库、中间件、虚拟化、信息安全、云计算、大数据、IT管理及IT应用等不同专业方向百余门数字化系列课程。

      基于客户日趋层次化、多元化的数字化转型需求，柯普瑞企业IT学院 围绕企业数字化转型的痛点，以数字化驱动业务、数字化创新业务、数字化赋能业务为核心，通过专业化沟通、咨询及评估，设计出合理有效的数字化专业人才培养方案，强调课程的针对性、实用性和高效性，依托数字化专家讲师团队提供优质高效的培训服务，帮助客户完成数字化转型的最佳实践！   

企业使命：

为员工创造价值，为客户创造价值，为社会创造价值！

企业愿景：

成为中国一流的企业级数字化人才培养解决方案提供商！