TCP抓包实验：从三次握手到重传与挥手逐帧分析

1. 这个实验真正练的是什么：从“能抓到”到“会读”

第一次接触 TCP 抓包实验的人，十有八九会把注意力放在“怎么把包抓下来”上，觉得抓到 pcap 文件就算完成任务。我当年也是这么想的，结果把文件拖进分析工具之后，面对满屏的黑色背景和密密麻麻的十六进制数字，完全不知道从哪一行看起。后来在真实项目里排查一次接口偶发超时，我才明白这类实验的核心价值根本不在抓包动作本身，而在于建立一条完整的因果链：应用层的一次请求，是怎么在传输层被切成若干段、每段带什么序号、对端怎么确认、窗口怎么变化、最后连接怎么关闭的。这条链条打通之后，你看到任何一个 TCP 段，脑子里都能自动补出它在这条链上的位置。

所以这篇文章不打算写成一份“按钮在哪里、菜单叫什么”的操作手册，那种东西官方文档比我写得全。我更想还原的是：一个干了几年网络排障的人，拿到一个 TCP 抓包任务时会怎么设计实验、怎么选抓包点、怎么过滤、怎么从字段读出故事，以及哪些坑是只有亲自踩过才知道的。内容会围绕一个经典实验框架展开，但补充大量原始实验手册里不会写的判断依据和操作细节。适合刚学完 TCP 报文结构、想把它落到实处的同学，也适合工作里需要经常看抓包但一直没系统梳理过的同行。

1.1 实验目标不是背字段，而是建立因果链

很多人做这个实验的方式是：打开题目，照着问题一条条找答案，比如“SYN 段的序号是多少”“MSS 是多少”“窗口尺寸是多少”，找到就填上去，实验结束。这种做法能拿分，但拿不到能力。字段是静态的，因果是动态的。真正要练的是：看到某个字段的异常取值，能推断出上游发生了什么。

举个具体的例子。你在抓包里看到一个 ACK 号突然回退，重复确认了同一个序号三次，紧接着发送方重传了那一段。如果只是背字段，你只知道“这是重复 ACK”；如果能建立因果链，你会立刻意识到这是快速重传的触发条件，说明中间有一段丢了但后续段到达了，接收方在用重复 ACK 催促重发。这个判断直接决定了你下一步是去查链路丢包，还是去查接收端缓冲区。

我在带新人的时候，通常要求他们做完实验后不看抓包文件，只用文字复述一遍“这次连接从建立到关闭发生了什么”。能复述清楚，说明因果链建立了；复述不出来，说明只是抄了一遍字段值。

实验的目标清单我一般这么定：

• 能从一段混杂流量里，准确切出目标 TCP 连接（按四元组或流索引）
• 能逐帧说明三次握手每个包的标志位、序号、选项含义
• 能解释数据传输阶段 seq 与 ack 的推进关系，以及窗口在其中扮演的角色
• 能识别重传、乱序、零窗口、RST 这几类典型异常
• 能根据时间戳和字节数粗略估算吞吐与 RTT
• 能说清楚四次挥手每个状态迁移的触发点

这份清单看起来是六条，实际上是一条：把协议状态机映射到具体的包序列上。字段只是状态机的快照。

1.2 一套最小可行的实验拓扑

实验拓扑不需要复杂，越简单越好定位问题。最省事的方案是同一台机器上跑客户端和服务端，走回环接口；稍微真实一点的是两台机器在同一局域网，中间经过一台普通交换机；再想观察中间设备影响，可以加一台能做端口转发的设备。我个人推荐从“本机回环 + 一台局域网对端”这个组合开始，原因很实在：回环接口不经过物理网卡，能排除网卡卸载、驱动缓冲带来的干扰，适合先把协议本身看明白；局域网对端则能让你看到真实的分段、窗口协商和 RTT，适合第二阶段。

拓扑里几个角色要提前想清楚：

流量发生器这块我强烈建议用命令行工具而不是浏览器。浏览器会并发建一堆连接、加载静态资源、走连接复用，抓下来之后你分不清哪个流是主请求。用一条curl或者一次文件传输，只产生一条干净的 TCP 流，实验效率能提高好几倍。等基础分析熟练了，再去啃浏览器那种多流混杂的场景，循序渐进。

关于抓包点，有个原则值得记住：你能看到什么，取决于包经过你抓包位置时的样子。在客户端抓，看到的是本机发出去的原始包和收到的包；在服务端抓，看到的是经过网络之后的样子；在中间镜像，看到的是双向流量但可能缺少本机协议栈的处理信息。三种位置各有用途，实验阶段优先在客户端抓，因为客户端往往是你唯一有权限操作的机器。

2. 环境准备与抓包参数：细节决定数据质量

抓包工具本身安装没什么门槛，真正影响实验质量的是几个容易被忽略的参数：网卡选择、混杂模式、抓包过滤器、缓冲区、时间戳精度。这几项任何一项没设对，后面分析都会难受。我见过太多人抓了半天发现抓的是错误网卡，或者抓下来的包时间戳全是同一毫秒，根本没法算 RTT。

2.1 抓包位置与网卡选择

打开抓包工具后第一件事不是点开始，而是确认接口列表。列表里通常有一堆名字奇怪的虚拟接口，什么桥接、什么虚拟网卡、什么容器网络，这些都是本机各种虚拟化组件生成的。选错了接口，你会看到大量莫名其妙的广播包，唯独看不到你要的目标流量。

判断方法很直接：先在不抓包的情况下做一次目标操作，比如访问一下对端服务，然后看系统网络连接状态里这条连接走的是哪个本地地址，再回到接口列表找对应地址的接口。回环流量走的是回环接口，这个接口在部分系统上默认不显示，需要在接口列表里主动展开或者用命令行参数指定。

提示：如果目标流量是走回环的，务必确认抓包工具已经启用了回环接口的捕获能力。有些环境默认过滤掉回环，抓半天一个包没有，排查方向全错。

混杂模式这个选项也值得说一下。它的作用是让网卡接收所有经过的帧，而不只是发给本机的帧。在交换式网络里，混杂模式对看到别人的流量帮助有限，因为交换机不会把别人的单播帧转发给你。但在集线器环境或者做了端口镜像的环境里，它能让你看到更多。实验阶段如果只关心本机流量，保持默认关闭反而更干净，避免无关广播干扰。

2.2 抓包过滤器与显示过滤器，别混着用

这是新手最容易混淆的一对概念，我用一句话概括：抓包过滤器决定哪些包被存下来，显示过滤器决定哪些包被显示出来。前者在抓包开始前生效，语法是 BPF 风格；后者在抓包结束后生效，语法是工具自己的表达式语言。两者不能互换。

为什么要区分？因为抓包过滤器一旦设错，漏掉的包就永久丢了，只能重抓；显示过滤器设错，改一下表达式就行，原始数据还在。所以我的习惯是：抓包过滤器尽量放宽，只做粗粒度筛选（比如限定端口或主机），把精细筛选留给显示过滤器。

几个常用的抓包过滤写法：

# 只抓目标端口为 8080 的 TCP 流量 tcp port 8080 # 抓某台主机的所有 TCP 流量 tcp and host 10.0.0.12 # 排除某个端口的干扰 tcp and not port 22

对应的显示过滤写法差异明显，功能也更强：

tcp.port == 8080 ip.addr == 10.0.0.12 && tcp !(tcp.port == 22) tcp.flags.syn == 1 && tcp.flags.ack == 0 tcp.analysis.retransmission

最后两条是这个实验里用得最多的。第一条筛出所有发起连接的 SYN 包，方便你在一堆流里快速定位；第二条把所有被判定为重传的包标出来，做异常分析时几乎必用。这些分析字段是工具根据前后包关系推断出来的，不是协议头里真实存在的位，这点要清楚，别在报告里写成“TCP 头部的重传标志位”。

2.3 时间戳、缓冲区与丢包自查

时间戳精度直接决定你能不能算准 RTT。默认情况下很多系统的时间戳精度是毫秒级，对于局域网内亚毫秒级的往返，这个精度不够用。在抓包设置里把时间精度调到微秒甚至纳秒级（取决于系统支持），会让后续的时序图顺眼很多。

缓冲区设置是另一个容易踩的坑。抓包工具默认的环形缓冲区大小有限，高速流量下如果写入磁盘的速度跟不上，内核就会丢包。丢了包你还不一定知道，直到分析时发现序号不连续、握手包缺失，才回头怀疑是抓包环节出的问题。所以开始抓之前，先看一眼丢包统计，抓完再看一眼，两个数字对得上才说明数据可信。

我一般会做一次简单的自检：抓包结束后查看捕获文件的统计信息，重点看“已捕获”和“已丢弃”两个计数。丢弃数不为零，结论就要打折扣。高速场景下可以加大缓冲区、缩短单次抓包时长、把捕获文件写成环形多文件，这几种手段组合使用。

注意：分析之前先确认抓包本身是否完整。很多“协议异常”最后查下来是抓包丢了包，白折腾半天。

3. 三次握手：逐帧拆开看才有的信息量

三次握手是 TCP 实验里信息密度最高的部分。表面上看就三个包，但每个包里藏着的选项协商、窗口通告、初始序号，决定了整条连接后续的行为。我在实际排查里遇到连接建立慢、连接被拒、首包延迟这类问题，第一眼都是看握手阶段。

3.1 SYN、SYN-ACK、ACK 的字段推进关系

先看第一个包，客户端发出的 SYN。标志位上只有 SYN 被置 1，ACK 为 0。序号字段是一个随机初始值，记作 x。这个随机化设计是为了降低连接被伪造的风险，也让不同连接的序号空间互相独立。窗口字段通告的是客户端当前能接收的字节数，注意这个值在握手阶段往往不代表真实能力，因为窗口缩放选项还没生效。

第二个包，服务端回的 SYN-ACK。SYN 和 ACK 同时置 1，序号是服务端的初始值 y，确认号是 x+1。这里的加一是因为 SYN 本身消耗一个序号，虽然它不携带应用数据。这个细节经常被忽略，导致有人算不对后续数据段的序号。

第三个包，客户端回的 ACK。只有 ACK 置 1，序号是 x+1，确认号是 y+1。到这里连接建立，双方都确认了对方的初始序号，也确认了对方能收到自己的包。

用显示过滤器筛出这三个包：

tcp.flags.syn == 1 || (tcp.flags.ack == 1 && tcp.len == 0 && frame.time_relative < 1)

更简单的方式是先筛出目标流，再按帧号顺序看。工具里有个“跟踪 TCP 流”的功能，能把一条连接的所有包单独拎出来，序号还会自动转成相对值，读起来轻松很多。

相对序号这个功能值得单独说。默认情况下工具会把初始序号减掉，显示成 0、1、2 这样的相对值，好处是直观，坏处是你对照原始报文时会发现对不上。做实验写报告时我建议先关掉相对序号，看清楚真实值，理解之后再打开，方便阅读。切换位置在协议的 TCP 设置里。

3.2 选项字段：MSS、窗口缩放、SACK 才是重点

三个握手包里真正有信息量的是选项字段，很多人直接跳过，其实这里决定了后续传输的效率上限。

MSS（最大段长度）：双方各自通告自己能接收的最大段大小，实际发送时取两者较小值。以太网环境常见值是 1460，算法是 MTU 1500 减去 IP 头 20 字节再减去 TCP 头 20 字节。如果中间经过隧道封装，MSS 会被相应调小，这时候如果你看到 MSS 明显小于 1460，就要意识到路径上可能有额外封装。

窗口缩放：TCP 头里的窗口字段只有 16 位，最大 65535 字节。在高带宽高延迟链路上这个窗口太小，所以握手时通过窗口缩放选项协商一个移位因子。实际窗口大小等于头部窗口值左移这个因子位。这个选项只在握手阶段协商一次，后续不再出现。计算实际窗口时忘了移位，是实验报告里最常见的错误之一。

SACK 允许：双方通告自己支持选择性确认。开启之后，接收方可以告诉发送方“我收到了哪些不连续的段”，发送方就只需要重传真正丢失的部分，而不是把丢失点之后的全部重发。这个选项对丢包场景下的性能影响很大。

把三个选项串起来看，你就能理解一条连接的性能天花板大概在哪：MSS 决定单段载荷，窗口决定在途数据量，SACK 决定丢包后的恢复效率。三者共同约束了吞吐。

3.3 握手阶段的异常信号

正常握手三个包，间隔很短。实际抓包里握手阶段出问题的情况不少，我整理了几类典型信号：

SYN 重传的间隔是有规律的，通常从一秒左右开始逐次翻倍。看到这个模式，基本可以确定是没收到对端回应，而不是应用层的问题。这个判断在排障时非常有用，能帮你把问题范围从应用层缩到网络层。

还有一种情况是握手看起来完成了，但连接立刻被 RST 关闭。这种多半是服务端应用层主动拒绝，或者中间有设备做了连接拦截。区分方法看 RST 是谁发的、带的序号是多少，结合服务端日志一起看。

4. 数据传输：序号、确认、窗口与重传的联动

握手之后的传输阶段才是实验的主体。这一段包多、字段变化频繁，如果没有清晰的观察框架，很容易看花眼。我的做法是先抓一条可控的、单向大流量传输，把注意力集中在发送方的序号推进和接收方的确认节奏上，等这条线看明白了，再去看双向交互和异常。

4.1 seq 与 ack 的推进逻辑

理解这一段的关键是记住一条规则：序号标识的是字节流中的位置，不是包的编号。发送方第一个数据段的序号等于握手时初始序号加一（SYN 消耗了一个序号），假设发了 1000 字节，那么下一个段的序号就是初始序号加 1001。接收方回的 ACK 号表示“我期望收到的下一个字节位置”，也就是已确认字节数加一。

这个设计带来一个直观的推论：确认号是累积的。接收方确认了 5000，意味着 5000 之前的所有字节都收到了，不需要逐段确认。这也解释了为什么丢包时会出现重复 ACK，接收方在反复告诉发送方“我还在等那个缺失的段”。

抓包里观察这个推进关系，最有效的方式是看工具的序号分析列。它会标出每个段相对于流的序号和确认号，还会提示“这是第几段数据”“这是对哪个段的确认”。配合时间列，你能画出一条阶梯状的发送曲线和一条滞后的确认曲线。

我自己习惯同时打开三个列：相对序号、相对确认号、段长度。这三个数字放在一起，任何异常都会自己跳出来。比如某一段长度是 0 但序号没变，那是纯 ACK；某一段序号跳变超过预期，那中间有段没抓到或者真的丢了。

4.2 窗口与吞吐：算一遍比看十遍管用

窗口字段决定了发送方在收到确认之前最多能发多少未确认数据。这个值由接收方通告，会随着应用层读取速度动态变化。窗口越大，管道里能塞的数据越多，吞吐上限越高。

吞吐的理论上限可以用一个很简单的公式估算：

吞吐上限 ≈ 窗口大小 / RTT

假设窗口是 64 KB，RTT 是 50 ms，那么上限大约是 1.3 MB/s，换算下来十兆比特每秒左右。这个数字经常让人惊讶：明明链路是千兆的，为什么实际传输只有这么点？答案就是窗口和 RTT 共同构成了瓶颈。要让吞吐上去，要么加大窗口（靠窗口缩放），要么降低 RTT。

实际抓包里验证这个公式，需要拿到三个数：有效窗口、往返时间、实际传输字节数。有效窗口要记得做缩放移位，RTT 可以用确认包和对应数据包的时间差来算，实际字节数看一段固定时间内的段长度之和。三个数一对比，就知道当前连接是卡在窗口上还是卡在链路上。

提示：计算吞吐时注意区分“应用层字节”和“链路上的字节”。TCP 段长度只算载荷，不含头部开销。做容量评估时要把头部和链路层开销也算进去，否则会低估实际占用。

工具的统计功能里有一个吞吐图表，能直接画出每秒字节数曲线。这条曲线配合窗口变化看，能很直观地看出窗口受限和带宽受限的区别：窗口受限时吞吐曲线呈锯齿状，跟着窗口涨落；带宽受限时曲线贴着某个水平线走。

4.3 重传、乱序与重复 ACK 的识别

重传是传输阶段最有分析价值的事件。工具会自动标记几类重传，理解它们的触发条件比记住标记名称更重要。

超时重传：发送方等确认超时，主动重发。触发条件是 RTT 估算值加上一定的余量之后仍未收到确认。抓包里表现为某个段在很长时间之后被原样重发，且中间没有任何重复 ACK 铺垫。

快速重传：接收方连续发出多个针对同一序号的重复 ACK，发送方收到三个就立即重发，不等超时。这是对超时机制的重要补充，能显著缩短恢复时间。抓包里表现为“重复 ACK 三连”紧跟一个重传段。

乱序：段到达顺序和发送顺序不一致，但最终都到了。抓包里表现为序号跳跃，随后又补上。乱序本身不一定触发重传，但如果乱序严重到让发送方误判丢包，就会引发不必要的重传。区分乱序和真丢包，看后续有没有补上那个缺口。

这几类事件在显示过滤器里都有对应字段，做异常统计时可以直接筛：

tcp.analysis.retransmission tcp.analysis.fast_retransmission tcp.analysis.out_of_order tcp.analysis.duplicate_ack

跑一遍这些过滤器，数一下各自的数量，再结合总段数，就能对这条连接的健康度有个大致判断。重传率超过百分之一，就值得进一步查了。

4.4 拥塞窗口的估算思路

拥塞窗口是发送方内部维护的变量，不在报文头里，所以抓包看不到直接值。但经典实验里有一种估算方法：在一个发送窗口内，找到第一个丢包事件之前连续被确认的字节数，就近似等于当时的拥塞窗口。

具体做法是：盯住发送方连续发送、接收方连续确认的那一段，从某个确认点开始，累计已被确认的字节数，直到出现丢包或重复 ACK 为止，这个累计值就是估算的拥塞窗口。然后观察它在慢启动阶段如何翻倍增长，在拥塞避免阶段如何线性增长，在丢包后如何回落。

这个估算不精确，受接收窗口、应用层写入节奏影响，但足以让你在抓包里“看到”拥塞控制的行为。做实验时把估算值画成曲线，和教科书上的图形对照，理解会深很多。我第一次画出这条曲线的时候才真正明白，为什么慢启动叫“慢”启动，它其实增长得一点都不慢，只是起点低。

5. 四次挥手与连接收尾：状态迁移的现场

挥手阶段经常被实验忽略，因为大家觉得连接关了就没啥可看的。实际排障中，连接关闭异常导致的端口耗尽、连接堆积问题非常常见，值得认真对待。

5.1 FIN 与 ACK 的交替节奏

正常关闭是四次交互：主动关闭方发 FIN，被动方回 ACK，被动方应用层处理完再发自己的 FIN，主动方回 ACK。之所以是四次而不是两次，因为 TCP 是全双工的，两个方向要分别关闭。

抓包里看这四个包，重点看序号和确认号的对应关系。第一个 FIN 携带的序号是主动方最后一个数据字节的下一个位置，虽然 FIN 不携带数据，但它消耗一个序号。对端的 ACK 号就是 FIN 序号加一。第二个 FIN 同理。

这里有个细节：被动关闭方在收到 FIN 之后，应用层可能还有数据要发，所以 ACK 和 FIN 不一定同时发出。如果应用层很快就关闭了，你会看到 ACK 和 FIN 合并成一个包，四次挥手变成三次。这是正常的，不是异常。

5.2 TIME_WAIT、RST 与端口耗尽

主动关闭方在发出最后一个 ACK 之后会进入 TIME_WAIT 状态，持续一段时间（通常是两倍最大段生存时间）。这个状态存在的意义是：确保最后一个 ACK 能到达对端，以及让旧连接的残留包在网络中消散，不至于干扰新连接。

TIME_WAIT 本身是正常机制，但短连接高并发场景下会大量堆积，占用本地端口。抓包里表现为大量处于该状态的连接，源端口分布很广。判断是否成为问题，看端口范围和堆积速度。解决思路一般是从应用层改成长连接复用，或者调整系统的端口回收策略，而不是简单地把等待时间调短，那样会引入新的问题。

RST 则是另一回事。它表示连接被强制中断，不是正常关闭。抓包里看到 RST，要看是谁发的、在什么阶段发的：

• 握手阶段被 RST：对端端口没监听，或者中间设备拦截
• 传输阶段被 RST：应用层异常退出，或者收到了无法处理的数据
• 关闭阶段被 RST：对端已经关闭，本方还在发数据

RST 的序号字段也有讲究。如果是响应一个未知连接，RST 的序号通常是对端 ACK 号；如果是中断当前连接，序号是当前发送位置。看这个细节能判断 RST 是“拒绝”还是“中止”。

6. 常见问题与排查技巧实录

实验做多了，问题见得也多了。这一节把高频问题和判断思路整理成速查形式，都是实际踩过的坑。

6.1 抓不到包或者抓到的包不完整

这是最高频的问题，原因通常集中在几个点：

权限这块补充一句：捕获原始报文通常需要较高权限，普通用户运行可能只能看到部分接口或者直接失败。遇到权限报错，先确认运行身份，再考虑给捕获程序单独授权，不要图省事直接用最高权限跑一切。

6.2 校验和显示错误不等于真的错了

这个问题特别容易误导人。抓包里看到大量“校验和错误”的标记，第一反应是链路有问题，其实很可能是网卡的校验和卸载功能导致的。发送端把校验和计算交给网卡，协议栈里填的是占位值，抓包工具在网卡之前就把包截走了，看到的自然是不正确的校验和。

判断方法：如果错误只出现在本机发出的包上，收到的包都正常，基本可以确定是卸载导致的。处理方式有两种，一是临时关闭网卡的校验和卸载功能再抓，二是在分析工具里关掉校验和验证。做实验时我更倾向第一种，因为能看到真实的校验和值，对理解协议有帮助。

6.3 大包被拆成小段，不一定是分片

看到一个大请求被拆成很多个小段，不要急着判断是 IP 分片。TCP 本身就会根据 MSS 把应用层数据切成段，这是正常的分段行为，和 IP 层的分片是两回事。区分方法看协议层级：TCP 分段在传输层完成，每个段都有自己的 TCP 头；IP 分片在网络层完成，只有第一个分片带完整传输层头。

还有一种情况是网卡的段聚合卸载，把多个小段合并成一个大包再发出去，抓包时看到的段长度会超过 MSS。这种包在分析工具里可能显示为异常，实际是卸载特性造成的。做实验时如果对段长度有严格要求，建议临时关闭相关卸载功能。

6.4 时间相关的分析总是不准

算 RTT、算吞吐、看间隔，都依赖时间戳。时间不准的原因有几个：抓包点的时钟和参照时钟有偏差、时间戳精度不够、多份抓包文件时钟不同步。单机抓包一般不存在同步问题，多机抓包对比时就要特别注意。

我的习惯是：单机分析用相对时间（从第一个包开始计时），跨机对比前先找一对相同的包做时钟对齐，比如同一个 SYN 包在两端的时间差，把这个差值补偿掉再看。不做对齐直接对比两端的时序，结论很容易反。

7. 几个让我少走弯路的操作习惯

最后分享几个纯个人习惯，都是被坑出来的，谈不上规范，但确实省时间。

第一个习惯是先看流列表再看包。打开捕获文件不急着往下翻，先用会话统计功能把所有 TCP 流列出来，按字节数或包数排序，找到目标流再点进去。这样能避免在无关流量里大海捞针，尤其是抓了整机流量的时候。

第二个习惯是每条结论都回到原始字节验证。分析工具给的推断很方便，但偶尔也会因为抓包不完整而误判。重要结论我一般会展开原始字节，手动核对一下关键字段，确认无误再写进报告。这个动作花不了几秒，但能避免把错误结论传递下去。

第三个习惯是保存过滤表达式。常用的几个过滤器设好之后存成按钮，下次一键切换，比每次手敲快得多。尤其是重传、重复 ACK、零窗口这几个，排查时来回切换频率很高。

第四个习惯是抓包前先想好要回答什么问题。漫无目的地抓一大堆流量，最后往往什么都分析不出来。先明确“我要确认握手是否正常”还是“我要看重传发生在哪个段”，带着问题去抓，抓完立刻分析，效率完全不一样。

第五个习惯是做完实验写一份复盘。不用长，就记三件事：这次抓包的位置和参数、遇到的异常和判断过程、下次要改进的地方。积累十几份之后，你会发现大部分问题的排查路径是重复的，这份记录就是自己的排障手册。

TCP 这个东西，看多少遍教材都不如亲手抓一次、逐帧读一次。字段会忘，工具会换，但那条从应用到链路、从序号到状态的因果链一旦建立起来，换什么工具都能很快上手。实验的意义也就在这，它不是让你记住某个包的确认号是多少，而是让你在面对一条陌生的连接时，知道从哪里开始看、看完能得出什么。