netstat 不记录状态变迁过程，仅显示某时刻的静态连接状态；需通过连续监控（如 netstat -tunapc 1）捕捉 syn_sent→established 等变化，并结合 tcp 状态机逻辑解读。
netstat 本身不记录状态变迁过程，它只呈现某一时刻连接所处的静态状态。要理解状态机变迁，关键不是“让 netstat 显示变化”，而是用它捕捉不同阶段的瞬时状态，并结合 TCP 协议逻辑去串联解读。
从 netstat 输出识别典型状态节点
运行 netstat -tunap（Linux）或 netstat -ano（Windows），你会看到类似这样的字段：Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name。其中 State 列就是当前连接在 TCP 状态机中的落点。常见且有诊断意义的状态包括：
- LISTEN：服务端 socket 正在等待入站连接，是三次握手的起点；
- SYN_SENT：客户端已发出 SYN，但尚未收到服务端的 SYN+ACK；
- SYN_RECV：服务端收到 SYN，已回复 SYN+ACK，正等待客户端 ACK（该状态极短暂，常需高频刷新或抓包才能捕获）；
- ESTABLISHED：三次握手完成，数据可双向传输；
- FIN_WAIT1 / FIN_WAIT2：主动关闭方已发 FIN，分别处于等待对方 ACK 和等待对方 FIN 的阶段；
- CLOSE_WAIT：被动关闭方收到 FIN 后进入此状态，表示应用层尚未调用 close()；
- TIME_WAIT：主动关闭方收到对方 FIN 并发送 ACK 后进入，持续 2MSL，防止旧连接报文干扰新连接。
用连续监控观察状态流动
单次 netstat 是一张快照，要看到“变迁”，就得制造变化并持续观察：
- 在终端执行 netstat -tunapc 1 | grep :端口号（如
:8080），每秒刷新一次； - 此时发起一次 curl 或 telnet 连接，你将依次看到：
SYN_SENT → ESTABLISHED（客户端侧），SYN_RECV → ESTABLISHED（服务端侧）； - 断开连接后，客户端可能快速走过
FIN_WAIT1 → FIN_WAIT2 → TIME_WAIT，服务端则先出现CLOSE_WAIT，待应用关闭后才转为LAST_ACK或消失。
结合状态数量判断异常模式
大量特定状态堆积，往往指向具体问题：
- 大量 SYN_RECV：可能遭遇 SYN 洪水攻击，或服务端 backlog 队列溢出；
- 大量 CLOSE_WAIT：服务端应用未及时关闭 socket，存在连接泄漏；
- 大量 TIME_WAIT：短连接频繁，或系统未启用
net.ipv4.tcp_tw_reuse等优化参数； - 无 LISTEN 但服务声称已启动：端口未绑定、绑定地址错误（如只绑 127.0.0.1）、权限不足或被其他进程抢占。
状态机不是孤立的——关联进程与地址
netstat 的价值在于把状态和真实世界挂钩：
- 加 -p 参数（需 root 权限）可看到 PID/Program name，确认是哪个进程在维持该状态；
- 看 Local Address 字段：若显示
127.0.0.1:3306，说明 MySQL 只接受本地连接；0.0.0.0:3306才对外网开放； - 对比 Foreign Address 与业务日志，能定位异常 IP 或爬虫行为。
