从TCP三次握手到TIME_WAIT：抓包与防火墙排障实战解析

最近在整理网络基础相关的学习笔记，把 TCP、抓包、TIME_WAIT 和防火墙这四块内容串在一起做了个复盘。说实话，单独看每个知识点都不难，但实际排障的时候它们往往是一起出现的：客户端报连接超时，你第一反应是抓包确认三次握手是否完成；握手包发出去了没有应答，你又要去翻防火墙策略；调完防火墙问题确实缓解了，过两天又冒出来大量 TIME_WAIT 导致端口不够用。这篇文章就是我这次从原理到实操的完整记录，适合刚接触网络排查的运维、开发同学，也适合想系统补一遍 TCP 状态、抓包分析思路的老朋友。我会结合真实的抓包截图场景（用文字还原）、命令输出和配置案例，把每一步为什么这样做讲清楚。

1. TCP三次握手：抓包才看得见的“三次”

1.1 三次握手里的“语义交换”

TCP 三次握手这件事，教科书上讲的是 SYN、SYN-ACK、ACK 三个报文，但我在实际抓包之前，其实一直没真正理解为什么必须是这三个报文，缺一个会怎样。后来自己用 Wireshark 抓了一次本地回环报文，才把这里面的逻辑看透。

三次握手表面上是“建立连接”，本质上是在交换三个关键信息：双方的初始序列号（ISN）、双方的接收窗口大小、以及双方是否愿意收发数据。

• 第一次握手：客户端发送 SYN，携带客户端初始序列号 client_isn，同时告诉服务器“我想建立连接”。
• 第二次握手：服务器回复 SYN-ACK，携带 server_isn，同时确认客户端的 client_isn（ACK = client_isn + 1），表示“收到你的请求，我也愿意建立连接”。
• 第三次握手：客户端回复 ACK，确认服务器的 server_isn，表示“我也收到你的确认了”。

为什么第三次是必需的？因为如果不发这个 ACK，服务器无法确认客户端是否收到了自己的 SYN-ACK。如果服务器误以为客户端收到了，它就会进入 ESTABLISHED 状态，然后开始给客户端发送数据，但客户端其实还在 SYN_SENT 状态，两边状态对不上，数据就会乱套。

这里有个细节我一开始忽略了：序列号不是从 0 开始的，操作系统会用一套算法生成一个随机初始序列号。抓包时看到的 seq 值往往很大，比如 4234567890，这是正常的。三次握手完成之后，双方就以这两个序列号作为起点，开始为后续每个字节编号。

1.2 用 Wireshark 实际抓一次握手

我在自己电脑上用 Wireshark 抓本地回环（loopback）流量，命令是启动一个简单的 HTTP 服务，然后用 curl 访问它。抓包时先设置过滤条件，只关注 TCP 流量：

code复制tcp.port == 8080

把 HTTP 服务跑起来后，在 Wireshark 里就能看到一系列 TCP 报文。最前面三个就是三次握手：

code复制Frame 1: 客户端 → 服务端  [SYN] Seq=0 Win=65535
Frame 2: 服务端 → 客户端  [SYN, ACK] Seq=0 Ack=1 Win=65535
Frame 3: 客户端 → 服务端  [ACK] Seq=1 Ack=1 Win=65535

注意这里的 Seq=0 是 Wireshark 做了“相对序列号”显示优化，实际线上的绝对序列号不是 0。如果你单击一个 TCP 报文，在中间面板展开 Transmission Control Protocol 字段，能看到 Sequence Number (raw) 才是真实值。这个显示优化默认开启，如果想关掉，在 Wireshark 的 Preferences → Protocols → TCP 里取消 Relative sequence numbers 即可。

过滤三次握手有一种更精确的写法：

code复制tcp.flags.syn == 1

这个表达式会把 SYN 和 SYN-ACK 都过滤出来，因为这两个报文的 SYN 位都是 1。再配合 tcp.flags.ack == 0，就能只看第一次握手的纯 SYN 包：

code复制tcp.flags.syn == 1 && tcp.flags.ack == 0

通过握手时延可以初步判断网络质量。第一次握手到第二次握手的间隔是 RTT（往返时延），本地回环通常是 0.1 毫秒以内；如果是跨机房、跨公网，这个值会明显变大，甚至上百毫秒。我在排查慢请求问题时，第一步就是看这个间隔，如果 RTT 本身就很高，那基本跟应用代码没关系，是网络链路的问题。

1.3 握手失败时的典型异常报文

抓包最核心的价值不是看正常的握手过程，而是看失败时的报文形态。常见的几种异常：

第一，SYN 重传。客户端发出 SYN 后，如果一直没有收到 SYN-ACK，会隔一段时间重新发送 SYN，间隔指数退避（1 秒、2 秒、4 秒……），重传超过一定次数才放弃。抓包的时候会看到同一个源端口、同一个序列号的 SYN 反复出现，这时候首选的怀疑对象就是中间链路或防火墙把 SYN 包丢了，或者服务端根本没有进程监听该端口。

第二，RST 直接拒绝。如果服务端收到了 SYN，但对应端口没有进程监听，内核会直接回一个 RST 报文把连接打断。客户端的表现是 connection refused，秒失败，不需要等超时。这个现象其实可以帮我们快速区分问题类别：秒拒通常是端口没监听或者防火墙主动 RST；久久没反应才是包被静默丢弃。

第三，TCP Keep-Alive 导致的半开连接探测。在实际运维中，还会在抓包里看到其实是连接已经建立后，某一端因为长时间没数据通信，主动发送 Keep-Alive 探测包。但这已经超出握手范畴，放到后面的状态分析里再说。

2. TIME_WAIT：主动关闭方绕不开的“收尾状态”

2.1 TIME_WAIT 到底在等什么

TIME_WAIT 这个状态，是 TCP 连接主动关闭方在发送最后一个 ACK 之后进入的状态，持续时间为 2MSL（Maximum Segment Lifetime，报文最大生存时间）。MSL 在 Linux 下的默认值是 30 秒到 60 秒，所以 TIME_WAIT 一般会维持 60 秒左右。

为什么不能立刻把连接从状态表中彻底删除？两个原因：

第一个原因是保证最后一个 ACK 能被对方收到。如果这个 ACK 在网络中丢了，被动关闭方会重新发 FIN，主动关闭方只有在 TIME_WAIT 状态下才能再次响应这个 FIN。如果连接已经删除，收到 FIN 后内核会回一个 RST，这会让对方认为连接异常，导致数据可靠性受损。

第二个原因是让旧连接的报文在网络中自然消亡。一个 TCP 连接由四元组唯一标识：源 IP、源端口、目的 IP、目的端口。如果刚关闭的连接立刻被一个新连接复用同样的四元组，网络中可能还残留着旧连接的迟到报文，新连接会把这些乱序报文误认为是自己的数据。TIME_WAIT 的等待时间正好覆盖报文在网络中的最大存活时间，把这个风险降到最低。

2.2 我开始以为 TIME_WAIT 多就需要调参，后来发现要先分清角色

在这个问题上我走过弯路。有段时间我发现服务器上 TIME_WAIT 连接特别多，netstat -ant | grep TIME_WAIT | wc -l 统计出来有几万个，当时第一反应就是要去改内核参数。后来查了资料、问了前辈才知道，TIME_WAIT 只会出现在主动关闭连接的一方。

如果服务器是纯粹的被动方，比如只提供 HTTP 服务，通常客户端主动断开连接，服务器不会积累 TIME_WAIT，反而是客户端的机器上大量堆积 TIME_WAIT。

那为什么我的服务器上会堆积大量 TIME_WAIT？真实场景是：服务器作为一个 RPC 客户端去调用其他服务，每次调用都新建短连接，调用完立刻主动关闭，于是自己变成了主动关闭方，TIME_WAIT 都堆在自己身上。

判断角色很简单，抓包看最后一轮挥手是谁先发的 FIN，或者直接看服务器上的连接状态分布。短连接场景下，只要主动关闭，TIME_WAIT 必然出现，这是正常的，关键看数量是否影响到了后续连接的建立。

2.3 端口耗尽才是 TIME_WAIT 堆积的真实风险

TCP 客户端主动发起连接时，需要占用一个本地端口。如果大量连接进入 TIME_WAIT，端口就会被这些连接占着。Linux 默认的本地端口范围可以通过这个命令查看：

code复制sysctl net.ipv4.ip_local_port_range

我机器上的输出是：

code复制net.ipv4.ip_local_port_range = 32768    60999

这意味着可用的客户端端口大约只有 28000 多个。如果每秒新建的连接数很高，TIME_WAIT 又要存活 60 秒，端口迟早会被占满。端口占满后，新连接会报 Cannot assign requested address，这是非常典型的 TIME_WAIT 堆积引发的故障。

要查看当前端口占用情况，可以用：

code复制ss -s

它会把 TCP 的各种状态统计列出来。如果 TIME_WAIT 数量长时间处于端口数量的量级，那就要处理了。

2.4 怎么调整 TIME_WAIT 相关内核参数

关于 TIME_WAIT 的参数，网上资料很多，但版本差异导致很多说法早已过时。这里整理一下我实际在用的方案和注意点。

以 Linux 系统为例，涉及 TIME_WAIT 的内核参数主要有这几个：

tcp_tw_recycle 这个参数我要多说一句。它在设计上是为了更快回收 TIME_WAIT，但它依靠时间戳来判定报文的新旧，在 NAT 后面的场景极不靠谱——同一公网 IP 后面如果有多台内网机器，各自的时间戳节奏不一致，很容易导致新连接的 SYN 包被内核丢弃。当年很多公网环境出现过“某些用户连不上、其他人正常”的诡异故障，最后定位来分析就是有人开了 tcp_tw_recycle。现在的新内核直接删掉这个参数，也算是一种态度。

我的建议是：不要为了消灭 TIME_WAIT 而消灭 TIME_WAIT。它只要不影响端口分配，就不是故障。业务量大的服务，优先考虑使用连接池或者长连接，从根上减少主动关闭的次数；实在改不了业务，再考虑调整 tcp_fin_timeout 和 tcp_tw_reuse。

3. Wireshark实战：把一次连接延迟拆开看

3.1 再忙也要记住的过滤语法

Wireshark 的强项在于可视化和过滤分析，我日常最常用的过滤表达式不超过十个，一个个列出来：

最后这类 tcp.stream eq 数字 是我最常用的，它可以把一条完整连接从握手到挥手的所有报文全部过滤出来，无论是排查问题还是复盘流程都很方便。Wireshark 里还有一个很顺手的功能：右键任意 TCP 报文 → Follow → TCP Stream，它会自动按这个过滤式把整个流提取出来，十六进制窗口里可以直接看到应用层数据内容。

3.2 从抓包里能读出哪些“弦外之音”

抓包不只是看有没有包，更要理解报文里的字段含义。我通常关注几个重要字段：

第一，Sequence Number 和 Acknowledgment Number。它们决定了数据的组装顺序。如果抓包里出现大量乱序包（Out-of-Order），说明网络路径上有拓扑变化或者负载均衡策略问题。

第二，Window Size。这个字段是接收方告诉发送方“我还有多少缓冲区空间”。如果接收方处理不过来，会发一个窗口为 0 的报文，发送方收到后就必须停止发送数据，直到接收方发出窗口更新（Window Update）。我在排查“连接建立但数据传输很慢”的问题时，一旦发现抓包里有 Zero Window 或 Window Full，问题的根因基本就锁定在接收方的应用处理能力上，而不是网络丢包。

第三，TCP Options 里的 Timestamps。它有两个作用，一是计算 RTT，二是配合序列号做 PAWS（Protection Against Wrapped Sequences）保护。抓包里如果看到时间戳异常跳跃（比如回调），说明对端机器的时间可能被调整过，这在排障时需要留意。

第四，TTL（Time To Live）。它反映报文经过了几个路由跳数。如果抓包看到的 TTL 和预期不符，说明报文走的路径可能和拓扑设计不一致，比如发生了路由绕路。

这些信息都可以在 Wireshark 的中间面板一层层展开查看，建议不要只看上面的摘要列表，最多花十秒钟点开字段看看，能省下很多猜测时间。

3.3 重传、乱序、零窗口：三类高频异常

第一类，TCP Retransmission。当发送方发出报文后，在超时时间内没有收到对应的 ACK，就会重传。重传次数过多，说明网络中存在丢包，丢包可能是链路质量问题，也可能是防火墙或交换机策略丢弃。遇到重传，我的排查顺序是：先看重传间隔是否规律，再顺着路径逐段 ping 或 MTR 看丢包率，最后抓包确认是仍在中间被丢弃还是对端没回 ACK。

第二类，Out-of-Order。报文到达顺序和发送顺序不一致，接收方会打乱序列号重新排序。轻微乱序影响不大，但如果乱序程度严重，会导致接收方连续触发重复 ACK（TCP Dup ACK），发送方误判为丢包进而重传，吞吐量骤降。我在公网链路和专线切换的场景里遇到过这种问题，最后定位是负载均衡设备把同一个流分到了两条不同时延的链路上。

第三类，Zero Window。前面提过这是接收方缓冲区满的信号。如果抓包中发现持续 Zero Window，配合应用进程的 CPU 和内存占用，通常能快速定位到接收方应用卡死或 GC 停顿等问题。

3.4 抓不到包的尴尬时刻

再好的工具也有抓不到包的时候。我总结了几种常见情况和应对思路。

第一种是没有权限。Linux 上普通用户跑 tcpdump 会提示权限不足，需要用 root 或者 sudo 执行。Windows 上 Wireshark 安装时附带安装 WinPcap/Npcap，如果只装了 Wireshark 而没有装底层驱动，同样抓不到包。

第二种是混杂模式没开。默认情况下网卡只接收发给自己的包，如果要在交换机的镜像端口上分析别人的流量，必须打开网卡的混杂模式。Wireshark 的 Capture Options 里有个 "Enable promiscuous mode on all interfaces" 选项，记得勾上。

第三种是 HTTPS 加密流量。现在绝大多数应用层流量都是 TLS 加密的，抓包看到的是密文，只能分析 TCP 层状态，看不到 HTTP 内容。想进一步看内容，可以在客户端配置 SSLKEYLOGFILE 环境变量导出会话密钥（Chrome/Firefox 支持），然后在 Wireshark 的 TLS 协议设置里加载 key log 文件。这个方法只对支持密钥导出的浏览器和 curl 有效，移动端 App 往往需要 hook 手段才能拿到，复杂度会高很多。

4. 防火墙：流量经过的“隐形安检门”

4.1 状态防火墙为什么能记住连接

很多刚开始排查网络问题的人会忽略防火墙的存在，因为“能 ping 通”不代表“端口能通”，这就和防火墙的工作机制有关。

现代防火墙基本都是状态防火墙（Stateful Firewall），它不像传统包过滤那样逐个报文独立判断，而是维护一张状态表，记录每个 TCP/UDP 连接的五元组、连接状态和超时时间。当 TCP 三次握手中的 SYN 包到达防火墙时，如果策略允许，防火墙会在状态表里新建一条记录；之后的报文如果匹配已有状态表项，就直接放行，不再逐条匹配规则。

这就解释了为什么“入站默认拒绝、出站默认允许”的防火墙配置下，已经建立的连接可以双向通信：因为出方向的报文创建了状态表项，回来的报文会匹配到这条记录。反过来，ping 走的是 ICMP，如果防火墙没有配置允许 ICMP 类型的规则，即使 TCP 端口是开放的，ping 不通也是正常现象。

4.2 防火墙拦截连接的几种典型表现

防火墙丢包是最让人头疼的一类故障，因为从客户端看，只是“连不上”，没有明确报错。但抓包能看到明显的特征。

• 特征一：SYN 发出后无响应，随后出现 SYN 重传，最终客户端报 connect timed out。
• 特征二：SYN 发出后收到 RST，连接秒断，这个可能是防火墙主动 RST，也可能是端口未监听。
• 特征三：TCP 连接能建立，但长时间无数据传输后连接被防火墙静默拆除，应用层下一次读写时报错。

如果是防火墙静默丢弃，tcpdump 在客户端能看到 SYN 发出，但对端永远没有响应；如果怀疑链路问题，要在对端机器上也抓一次包，看看 SYN 是否到达了目标主机。这里有个很关键的排障技巧：

在服务端执行：

code复制tcpdump -i eth0 tcp port 8080 -nn

如果服务端抓不到 SYN，说明报文在中间链路（包括防火墙）被丢了；如果能抓到 SYN 但应用无响应，那就不是防火墙丢包，而是服务本身的问题，比如进程挂了、监听 backlog 满了、或者内核 accept 队列溢出。

4.3 Linux / Windows 防火墙查日志与实操

先说 Linux。firewalld 是 RHEL/CentOS 系列的默认防火墙管理工具，iptables 则是底层的规则框架。查看当前防火墙状态和已放行端口：

code复制firewall-cmd --state
firewall-cmd --list-all

放行一个 TCP 端口：

code复制firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --reload

如果你用的是纯 iptables，放行端口的命令是：

code复制iptables -A INPUT -p tcp --dport 8080 -j ACCEPT

不过直接编辑 iptables 规则往往重启后会丢失，CentOS 7 以后更推荐使用 firewalld 统一管理。

查防火墙日志也是排障的关键一步。firewalld 的拒绝日志在 /var/log/messages 里能看到，打开方式比较繁琐，我通常直接临时关闭防火墙做对照测试来判断是不是防火墙引起的：

code复制systemctl stop firewalld

如果停掉防火墙后问题立刻消失，基本可以确定是防火墙规则导致的。做完对照要记得把防火墙重开，不要图省事一直关着。

再说 Windows 环境。Windows 自带高级安全防火墙，对应的命令行工具是 netsh。查看所有入站规则：

code复制netsh advfirewall firewall show rule name=all

添加一条入站放行 TCP 8080 的规则：

code复制netsh advfirewall firewall add rule name="Allow 8080" dir=in action=allow protocol=TCP localport=8080

Windows 防火墙默认禁止入站、允许出站，所以在 Windows 上排查“服务端口连不上”时，重点关注入站规则；而“程序不能联网”则要看出站规则。

4.4 屏蔽某个程序出站联网的完整操作

顺着出站规则说一个很常见的需求：不想让某个软件自动联网，但不想改程序文件本身，用 Windows 防火墙建一条出站规则就能做到。一次在给喜欢用绿色软件的朋友解决弹窗和静默下载问题时，我给的方案就是出站阻止规则。

操作路径是：控制面板 → Windows Defender 防火墙 → 高级设置 → 出站规则 → 新建规则 → 程序 → 浏览选择 exe 路径 → 选择“阻止连接” → 命名规则完成。

命令行方式更快：

code复制netsh advfirewall firewall add rule name="Block GeekUninstaller" dir=out action=block program="C:\Tools\GeekUninstaller.exe"

建好之后，这个程序发出的所有 TCP/UDP 连接请求都会被防火墙直接丢弃。其实在出站方向上，防火墙同样维持状态表，程序发出去的 SYN 包在防火墙这一层就被拦下来，网络层根本到不了对端。

如果你发现建了规则但程序还能联网，排查方向有两个：一是确认 exe 路径是否正确，很多程序的主程序和更新程序是分开的，需要把更新进程也禁用；二是检查是不是存在更早建立的允许规则，规则优先级会受匹配顺序影响。

这里要补充一句：防火墙黑白名单不是万能的。对于使用系统服务或其他进程代为联网的软件，单靠客户端防火墙不一定能完全阻断，需要结合 hosts、本地策略等手段综合处理。

5. 一个真实排障案例：从“连不上”到定位防火墙

5.1 问题现象与初步判断

上周收到一个反馈：内网某台机器上的业务服务，从外部无论如何都连不上，但在这台机器本机上用 localhost 访问端口却是通。这个现象本身就很有信息量——说明服务进程本身是正常的，问题出在“外部到本机”这条链路上。

我脑子里立刻排出三个候选：服务只监听了 127.0.0.1 导致外部访问不到；中间网络设备（防火墙/交换机）拦截；服务器本地防火墙问题。

先用 ss 确认监听地址：

code复制ss -lnt

输出显示监听地址是 0.0.0.0:8080，说明服务监听在所有网卡上，排除了监听地址的问题。

5.2 抓包对照定位防火墙

接着在客户端机器上发起连接并抓包：

code复制tcpdump -nn host 192.168.1.20 and port 8080

抓到的结果就是反复出现的 SYN：

code复制14:23:01.000001 IP 192.168.1.30.50123 > 192.168.1.20.8080: Flags [S] seq 1000, win 64240
14:23:02.000001 IP 192.168.1.30.50123 > 192.168.1.20.8080: Flags [S] seq 1000, win 64240
14:23:04.000001 IP 192.168.1.30.50123 > 192.168.1.20.8080: Flags [S] seq 1000, win 64240

SYN 重传间隔是 1 秒、2 秒，典型的未收到 SYN-ACK。这意味着报文要么没到服务器，要么到了但被丢弃。

马上在服务器本机抓包：

code复制tcpdump -nn -i eth0 port 8080

结果发现服务器上根本抓不到任何来自 192.168.1.30 的 SYN 包。这时问题范围就缩小了：不是服务器本机防火墙的问题，而是中间某个网络设备把包丢了。如果服务器本机抓到了 SYN 但没有 SYN-ACK 出去，那才需要查本机防火墙和进程状态。

继续排查中间链路，登录前置防火墙设备查看会话和规则，发现入方向对 8080 端口的策略只放行了一部分网段，客户端所在网段不在白名单里。加上放行规则后，连接立刻恢复。

5.3 连上之后又冒出大量 TIME_WAIT

问题解决后，我习惯性地看了一眼服务器的连接状态，发现这个服务虽然是标准的请求-响应模式，但客户端每次请求结束都会主动断开连接。短时间内并发一上来，服务器的 TIME_WAIT 数量迅速攀升，虽然没有立刻出现端口耗尽，但趋势不对。

这时我明白了为什么要先抓包、再看状态：TIME_WAIT 的产生源头是客户端主动关闭，服务端只是被动经历这个状态。如果服务端每处理一个请求就主动关闭连接，那 TIME_WAIT 会全堆在服务端自己身上，问题会更严重。

这个场景下我建议客户端应用改用连接池，保持长连接复用，避免每次请求都重新建立 TCP。连接建立本身有握手开销，频繁建立连接既增加 CPU 消耗，又积累 TIME_WAIT。后续观察并持续验证，调整后端口占用情况明显好转。

5.4 这个案例里最值得记住的一件事

回顾整个排障过程，最有价值的不是最后加了一条防火墙规则，而是“每一步判断必须有对应的抓包依据”这个思路。

网络排障最忌讳的就是凭感觉改配置。客户端连不上，先别急着开防火墙、改内核参数，一步步抓包确认：

1. 客户端是否发出 SYN？（没发就是客户端问题）
2. 服务端是否收到 SYN？（没收到就是中间链路问题）
3. 服务端是否回 SYN-ACK？（没回就是服务端防火墙或进程问题）
4. 客户端是否收到 SYN-ACK？（没收到就是回程链路问题）

每一步都能在抓包里找到对应证据，问题定位就快很多。TIME_WAIT 的观察也一样，先判断主动关闭方是谁、连接是否频繁新建，再决定改什么参数，顺序很重要。

6. 自己动手做一次联合实验

理论说多了还是容易忘，我更推荐你把上面提到的内容在各个环境下亲手验证一遍。下面是我尝试过的一套联合实验流程，十几分钟就能完整走一遍，加深理解很有帮助。

准备两台机器（虚拟机也可以），一台当客户端，一台当服务端。服务端用 Python 起一个简单的 HTTP 服务：

python复制from http.server import HTTPServer, SimpleHTTPRequestHandler
HTTPServer(('0.0.0.0', 8080), SimpleHTTPRequestHandler).serve_forever()

客户端用 curl 发起请求：

code复制curl -v http://服务端IP:8080/

同时在服务端用 tcpdump 抓包：

code复制tcpdump -nn -i any tcp port 8080

观察请求过程的 FIN 在哪一端发出，TIME_WAIT 状态出现在哪一端。然后故意做错误配置：比如在服务端不加规则的情况下，用 iptables 加一条 REJECT 规则拒绝 8080 端口，再观察客户端抓包的 SYN 重传行为：

code复制iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with tcp-reset

这时候客户端报错应该是 connection refused 而不是超时，因为 REJECT 会主动回 RST。把规则改成 DROP：

code复制iptables -A INPUT -p tcp --dport 8080 -j DROP

客户端就会变成一直重传 SYN 直到超时。这个对比特别直观，能帮你想明白防火墙“丢弃”和“拒绝”两种行为的本质区别。

继续实验，用 Windows 防火墙阻止一个 exe 出站，再用 Wireshark 抓包看它发出去的 SYN 是被本地防火墙拦住的。这类实验做一次，比看十篇文档都管用。