wireshark抓包来看下TCP协议

wireshark抓包来看下TCP协议

关于wireshark会显示什么协议的问题

wireshark抓包时，protocol列会显示什么样的协议给用户看？

Wireshark 的 Protocol 列会显示它能够识别的、数据包封装栈中"最上层"的那个协议名称。

下面详细拆解这个逻辑。

一、核心原则：显示"最上层"的协议

Wireshark 在解析一个数据包时，会从链路层（L2）开始，一层一层地往上剥。Protocol 列显示的，就是这个剥洋葱过程最终到达的、它所能识别的最高层协议。

如果包里没有应用层数据 ：它就显示传输层协议（如 TCP, UDP）。

如果包里是控制或管理协议 ：它就显示该协议本身（如 ARP, ICMP）。

如果包里有标准的应用层数据 ：它就显示应用层协议（如 HTTP, DNS）。

Protocol 列显示的，是"这个包是干什么的"的答案，而不是"这个包属于哪一层"。

二、通过一个递进例子来理解

下图是一个常见的 HTTP 请求包在 Wireshark 中的样子。我们可以对比"协议栈"和"Protocol 列显示"的区别：

实际的协议栈（从下到上） Wireshark 的显示逻辑 Protocol 列最终显示

链路层：以太网 (Ethernet) Wireshark 会解析，但认为这是基础，会继续往上找。 不显示

网络层：IP (Internet Protocol) Wireshark 会解析，但发现里面还有东西，会继续往上找。 不显示

传输层：TCP (Transmission Control Protocol) Wireshark 会解析，并且发现 TCP 段里携带了数据。它会分析这些数据，看看能不能识别出更高层的协议。 不显示

应用层 ：HTTP (Hypertext Transfer Protocol) Wireshark 发现 TCP 里的数据符合 HTTP 协议的格式（比如以 GET / 开头），于是成功识别。 显示 HTTP

结论：你看到 HTTP，是因为 Wireshark 足够聪明，能看穿 TCP 这个"外壳"，直接识别出里面的"货物"是 HTTP。

三、几种典型情况下的显示

数据包类型协议栈（下→上） Wireshark Protocol 列显示原因

Web 请求 Ethernet → IP → TCP → HTTP HTTP 或 HTTP/JSON 等成功识别了应用层协议。

安全网页 Ethernet → IP → TCP → TLS TLSv1.2 或 TLSv1.3 数据是加密的，Wireshark 看不到加密层里面的 HTTP，只能看到 TLS 协议本身。

DNS 查询 Ethernet → IP → UDP → DNS DNS 成功识别了应用层的 DNS 协议。

Ping 命令 Ethernet → IP → ICMP ICMP ICMP 是网络层协议，但它是这个包的"主要用途"，没有应用层了。

TCP 握手或挥手 Ethernet → IP → TCP (无应用层数据) TCP 包里只有 TCP 头，没有数据可以识别出更高层协议。

UDP 广播 Ethernet → IP → UDP (无应用层数据) UDP 同上，只有传输层头部。

ARP 查询 Ethernet → ARP ARP ARP 直接封装在以太网帧里，没有 IP 层和传输层，它就是最上层。

TCP 重传 Ethernet → IP → TCP (数据) TCP [TCP Retransmission] 虽然可能携带数据，但 Wireshark 的分析专家 识别出这是一个重传包，Protocol 列仍以主要协议 TCP 为主，并在 Info 列给出详细说明。

IP 分片 Ethernet → IP (分片，无 TCP/UDP 头) IPv4 因为分片，Wireshark 找不到传输层的端口信息，也无法判断上层协议，所以只能显示到网络层 IPv4。

四、关于 ARP 和 ICMP 的特别说明

你可能会问："ARP 和 ICMP 不是网络层或数据链路层的吗？为什么它们直接显示在协议列？"

因为它们是"功能主角" ：Wireshark 的 Protocol 列是一个"功能标识符"，而不是"层级标识符"。

一个 HTTP 包，它的主角是"网页浏览"。

一个 ICMP 包，它的主角是"网络诊断和控制"。

所以，ARP、ICMP、TCP 和 HTTP 一起出现在这一列，是因为它们都清晰地定义了这个包的核心功能，而不是因为它们在同一层级。

Wireshark 的设计哲学是：让你一眼就知道这个包是干嘛的 。看到 HTTP，是网页；看到 DNS，是域名查询；看到 ICMP，是 ping；看到 TCP，可能是连接握手。这种设计极大地提高了分析效率。

实际的协议栈（从下到上）	Wireshark 的显示逻辑	`Protocol` 列最终显示
链路层：以太网 (Ethernet)	Wireshark 会解析，但认为这是基础，会继续往上找。	不显示
网络层：IP (Internet Protocol)	Wireshark 会解析，但发现里面还有东西，会继续往上找。	不显示
传输层：TCP (Transmission Control Protocol)	Wireshark 会解析，并且发现 TCP 段里携带了数据。它会分析这些数据，看看能不能识别出更高层的协议。	不显示
应用层：HTTP (Hypertext Transfer Protocol)	Wireshark 发现 TCP 里的数据符合 HTTP 协议的格式（比如以 `GET /` 开头），于是成功识别。	显示 `HTTP`

数据包类型	协议栈（下→上）	Wireshark `Protocol` 列显示	原因
Web 请求	Ethernet → IP → TCP → HTTP	`HTTP` 或 `HTTP/JSON` 等	成功识别了应用层协议。
安全网页	Ethernet → IP → TCP → TLS	`TLSv1.2` 或 `TLSv1.3`	数据是加密的，Wireshark 看不到加密层里面的 HTTP，只能看到 TLS 协议本身。
DNS 查询	Ethernet → IP → UDP → DNS	`DNS`	成功识别了应用层的 DNS 协议。
Ping 命令	Ethernet → IP → ICMP	`ICMP`	ICMP 是网络层协议，但它是这个包的"主要用途"，没有应用层了。
TCP 握手或挥手	Ethernet → IP → TCP (无应用层数据)	`TCP`	包里只有 TCP 头，没有数据可以识别出更高层协议。
UDP 广播	Ethernet → IP → UDP (无应用层数据)	`UDP`	同上，只有传输层头部。
ARP 查询	Ethernet → ARP	`ARP`	ARP 直接封装在以太网帧里，没有 IP 层和传输层，它就是最上层。
TCP 重传	Ethernet → IP → TCP (数据)	`TCP` [TCP Retransmission]	虽然可能携带数据，但 Wireshark 的分析专家识别出这是一个重传包，`Protocol` 列仍以主要协议 `TCP` 为主，并在 `Info` 列给出详细说明。
IP 分片	Ethernet → IP (分片，无 TCP/UDP 头)	`IPv4`	因为分片，Wireshark 找不到传输层的端口信息，也无法判断上层协议，所以只能显示到网络层 `IPv4`。

抓包实战分析

下面通过实际操作，用Wireshark抓取TCP流量，详细分析TCP的三次握手、数据传输、窗口通告、重传、四次挥手等核心行为。

一、准备工作

1.1 启动抓包

打开Wireshark，选择正在使用的网卡（以太网或WLAN），开始抓包

1.2 常用TCP过滤器速查

过滤器表达式作用

tcp 显示所有TCP包

tcp.port == 80 显示HTTP流量（端口80）

tcp.port == 443 显示HTTPS流量（端口443）

tcp.flags.syn == 1 显示SYN包（握手开始）

tcp.flags.ack == 1 显示ACK包

tcp.flags.fin == 1 显示FIN包（挥手开始）

tcp.flags.reset == 1 显示RST包（连接重置）

tcp.analysis.retransmission 显示重传包

tcp.window_size < 1000 显示窗口小于1000的包

tcp.seq == 1 显示特定序列号的包

二、TCP头部结构回顾

TCP头部最少20字节，关键字段如下：
复制代码
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |       |C|E|U|A|P|R|S|F|                               |
| Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
|       |       |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if any)           |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

过滤器表达式	作用
`tcp`	显示所有TCP包
`tcp.port == 80`	显示HTTP流量（端口80）
`tcp.port == 443`	显示HTTPS流量（端口443）
`tcp.flags.syn == 1`	显示SYN包（握手开始）
`tcp.flags.ack == 1`	显示ACK包
`tcp.flags.fin == 1`	显示FIN包（挥手开始）
`tcp.flags.reset == 1`	显示RST包（连接重置）
`tcp.analysis.retransmission`	显示重传包
`tcp.window_size < 1000`	显示窗口小于1000的包
`tcp.seq == 1`	显示特定序列号的包

三次握手和四次挥手

访问 https://www.baidu.com/ 产生网络流量，然后找到一个看起来完整的交互过程，可以用ip.addr来过滤，如下所示：

这里有两轮交互过程，我们看其中一轮即可。

我们来一步步拆解图里的 TCP 连接过程，帮你看清楚三次握手和四次挥手。

1. 先看第一次连接（端口 57226）

✅ 三次握手（完整）

192.168.0.108 → 36.99.172.137：[SYN]，Seq=0（客户端发起连接请求）

36.99.172.137 → 192.168.0.108：[SYN, ACK]，Seq=0, Ack=1（服务器确认并回复 SYN）

192.168.0.108 → 36.99.172.137：[ACK]，Seq=1, Ack=1（客户端确认，握手完成）

✅ 四次挥手（完整）

192.168.0.108 → 36.99.172.137：[FIN, ACK]，Seq=1397, Ack=350（客户端主动关闭连接）

36.99.172.137 → 192.168.0.108：[ACK]（服务器确认收到 FIN）

36.99.172.137 → 192.168.0.108：[FIN, ACK]，Seq=350, Ack=1398（服务器也发起关闭）

192.168.0.108 → 36.99.172.137：[ACK]，Seq=1398, Ack=351（客户端确认，挥手完成）

2. 再看第二次连接（端口 57227）

这是客户端发起的新的 TCP 连接，过程和第一次完全一样：

三次握手：SYN → SYN+ACK → ACK（完整）

四次挥手：FIN+ACK → ACK → FIN+ACK → ACK（完整）

结论

✅ 图里不仅有完整的三次握手和四次挥手，而且有两组完全独立、完整的 TCP 连接过程，分别对应两个不同的客户端端口（57226 和 57227）。

把第一次的过程梳理下

我们把第一次 TCP 连接（客户端端口 57226，目标端口 80）的完整过程，按「三次握手 → 数据传输 → 四次挥手」一步步梳理清楚👇

一、三次握手（建立连接）

序号方向标志位 Seq/Ack 作用

1 192.168.0.108 → 36.99.172.137 [SYN] Seq=0 客户端发起连接请求，告诉服务器：我想建立连接，初始序号是 0

2 36.99.172.137 → 192.168.0.108 [SYN, ACK] Seq=0, Ack=1 服务器回复：同意连接，我的初始序号是 0，同时确认收到了你的 SYN（Ack=Seq+1=1）

3 192.168.0.108 → 36.99.172.137 [ACK] Seq=1, Ack=1 客户端确认收到服务器的 SYN，连接正式建立

二、数据传输阶段

握手完成后，双方开始 HTTP 请求 / 响应交互：

客户端发送 HTTP 请求 ：192.168.0.108 → 36.99.172.137，POST /api/bowl/hit?...，Len=1450（携带请求数据）

服务器确认收到请求 ：36.99.172.137 → 192.168.0.108，[ACK]，Ack=1397（确认收到了 1396 字节的数据，Ack=1+1396=1397）

服务器返回 HTTP 响应 ：36.99.172.137 → 192.168.0.108，HTTP/1.1 200 OK，JSON 响应

客户端收到响应后，准备关闭连接

三、四次挥手（断开连接）

序号方向标志位 Seq/Ack 作用

1 192.168.0.108 → 36.99.172.137 [FIN, ACK] Seq=1397, Ack=350 客户端主动关闭连接，告诉服务器：我没有数据要发了，请求断开

2 36.99.172.137 → 192.168.0.108 [ACK] Ack=1398 服务器确认收到 FIN，此时服务器还可以继续向客户端发送剩余数据

3 36.99.172.137 → 192.168.0.108 [FIN, ACK] Seq=350, Ack=1398 服务器也没有数据要发了，发起关闭请求

4 192.168.0.108 → 36.99.172.137 [ACK] Seq=1398, Ack=351 客户端确认收到服务器的 FIN，连接正式关闭

💡 补充说明：

为什么挥手是四次？因为 TCP 是全双工协议，读和写是独立的通道：客户端先关写通道（发 FIN），服务器先确认；等服务器自己的写通道也没数据了，再发 FIN，客户端再确认，所以需要 4 个步骤。

这里的 Seq/Ack 序号都是按 TCP 规则自增的，每收到一个字节数据，Ack 就会 +1；每发送一个 FIN/SYN，序号也会 +1。

好像四次挥手过程不完整啊，只有三次？

你这个观察非常敏锐！我们对着抓包数据，把第一次连接（端口 57226）的挥手过程一行一行拆开看，就能发现问题了👇

先把第一次连接的挥手相关包列出来

按顺序看这几行：

192.168.0.108 → 36.99.172.137：[FIN, ACK] Seq=1397 Ack=350

36.99.172.137 → 192.168.0.108：[FIN, ACK] Seq=350 Ack=1398

192.168.0.108 → 36.99.172.137：[ACK] Seq=1398 Ack=351

问题出在哪？------ 服务器的 ACK 和 FIN 合并了

标准的四次挥手，应该是：

客户端发 FIN

服务器先回 ACK（确认收到 FIN）

服务器再发 FIN（自己也关闭发送通道）

客户端回 ACK（确认收到服务器的 FIN）

但在你这个抓包里，第 2 步和第 3 步被合并成了一个包 ：服务器直接发了 [FIN, ACK]，这个包同时完成了两件事：

ACK=1398：确认收到了客户端的 FIN（完成了标准流程的第 2 步）

FIN：发起服务器自己的关闭请求（完成了标准流程的第 3 步）

所以整个挥手过程在抓包里就只看到了3 个包，但逻辑上仍然是完整的四次挥手，只是中间两步合并了，这是 TCP 中非常常见的优化。

完整逻辑对应表

标准四次挥手步骤抓包里的实际包标志位说明

1. 客户端关闭发送通道包 1 FIN, ACK 客户端发起关闭请求

2. 服务器确认收到 FIN 包 2 的ACK部分 ACK=1398 服务器确认客户端的 FIN，这一步和服务器自己的 FIN 合并发送了

3. 服务器关闭发送通道包 2 的FIN部分 FIN, ACK 服务器发起自己的关闭请求，和 ACK 合并为一个包

4. 客户端确认收到服务器 FIN 包 3 ACK=351 客户端确认服务器的 FIN，挥手完成

为什么会合并？

因为在服务器收到客户端的 FIN 时，它自己也没有数据要发送了，所以可以直接把「确认 ACK」和「自己的 FIN」放在同一个包里发送，这样既减少了一次网络往返，也不影响 TCP 的可靠性。

所以结论是：逻辑上的四次挥手是完整的，只是抓包里因为服务器合并了 ACK 和 FIN，看起来只有 3 个包。
TCP连接建立后，数据传送过程，还有ACK吗？是否携带数据？

这是一个很深入的问题。简单直接的答案是：有，而且非常多。 在数据传送过程中，ACK包几乎无处不在 ，并且ACK标志位通常会和数据（PSH）合并发送，也可以单独发送（纯ACK）。

以下结合你提供的抓包文件和TCP机制详细拆解：

1. 数据传送过程中一定有ACK吗？

是的，除了第一个数据包外，几乎每个包都带有ACK。

核心规则 ：TCP规定，一旦连接建立（三次握手完成），除了握手阶段最后一个纯ACK包外，后续所有发送的TCP报文段（无论是请求还是响应）都必须将ACK标志位置为1。

原因：因为连接建立后，双方都需要持续确认对方发来的数据。ACK标志位告诉对方"我已收到你发的数据，请继续发送下一个"。

你抓包中的证据（第二轮交互）：

包号方向标志位是否带ACK？说明

2921 客户端→服务器 [ACK] 是（纯ACK）确认收到服务器的SYN+ACK（握手最后一步，无数据）

2922 客户端→服务器 PSH, ACK 是 发送HTTP请求 + 确认（常见情况）

2923 服务器→客户端 [ACK] 是 单独确认收到了HTTP请求（无数据）

2924 服务器→客户端 PSH, ACK 是 发送HTTP响应 + 确认

2925 客户端→服务器 FIN, ACK 是关闭连接 + 确认

可见，2922、2923、2924、2925全部带有ACK标志。没有ACK的包只在连接建立前（纯SYN）或RST复位包中出现。

2. ACK包是否携带数据？

分两种情况：

情况A：携带数据（最常见）

表现形式 ：[PSH, ACK]（推送 + 确认）

含义：这个包一方面在发送新数据（如HTTP请求/响应），另一方面同时确认了对方之前发来的数据。

好处：捎带确认，不需要单独发一个空包做确认，节省网络资源。

你的例子：

包2922 ：客户端发送HTTP POST请求（数据长度约91字节）的同时，也通过ACK确认了服务器之前发的数据（Ack=1）。

包2924 ：服务器返回HTTP 200 OK响应（数据约350字节）的同时，也确认了客户端的请求（Ack=1397）。

情况B：不携带数据（纯ACK包）

表现形式 ：[ACK]（只有ACK标志，没有PSH或FIN）

含义：这个包只负责确认对方的数据，自身不携带任何应用层数据（Len=0）。通常出现在接收方处理较慢，或遵循"延迟确认"策略时。

你的例子：

包2923 ：服务器发回一个纯ACK包（Len=0），告诉客户端"我已经收到你的请求了，我正在处理（或已处理完）"。这个包没有携带HTTP响应数据（响应在下一个包2924中才发）。

3. 为什么需要纯ACK包（无数据）？

既然可以捎带确认，为什么还要单独发[ACK]？

接收方没有数据要发 ：当服务器收到客户端的HTTP请求后，它还需要时间处理（查数据库、生成响应）。如果这个处理时间较长，服务器会先发一个纯ACK告诉客户端"收到了，别超时重传"，等处理完再单独发PSH,ACK返回数据。

操作系统策略（延迟确认）：Linux等系统通常不会立即发送ACK，而是等待200毫秒左右，希望在这段时间内有数据可以一起发送。如果等待时间内没有数据，就单独发一个纯ACK。

窗口更新：当接收方应用程序读走了数据、TCP接收缓冲区有空间了，有时会发一个纯ACK来告知对方"窗口变大了，可以继续发了"。

总结对照表

特征连接建立阶段 数据传送阶段

是否带ACK？ 第二个包（SYN+ACK）有；第一个（SYN）没有 几乎所有包都有（PSH+ACK 或纯ACK）

是否携带数据？ 不携带（Len=0） 经常携带（PSH+ACK），也可以不携带（纯ACK）

你的抓包例子 2892(SYN), 2893(SYN+ACK) 2922(PSH+ACK带请求)，2923(ACK不带数据)，2924(PSH+ACK带响应)

一句话总结：数据传送过程中，确认机制从未停止，ACK标志一直存在；但它经常"搭便车"和数据一起发送，偶尔也会单独跑一趟。

序号	方向	标志位	Seq/Ack	作用
1	`192.168.0.108 → 36.99.172.137`	`[SYN]`	Seq=0	客户端发起连接请求，告诉服务器：我想建立连接，初始序号是 0
2	`36.99.172.137 → 192.168.0.108`	`[SYN, ACK]`	Seq=0, Ack=1	服务器回复：同意连接，我的初始序号是 0，同时确认收到了你的 SYN（Ack=Seq+1=1）
3	`192.168.0.108 → 36.99.172.137`	`[ACK]`	Seq=1, Ack=1	客户端确认收到服务器的 SYN，连接正式建立

序号	方向	标志位	Seq/Ack	作用
1	`192.168.0.108 → 36.99.172.137`	`[FIN, ACK]`	Seq=1397, Ack=350	客户端主动关闭连接，告诉服务器：我没有数据要发了，请求断开
2	`36.99.172.137 → 192.168.0.108`	`[ACK]`	Ack=1398	服务器确认收到 FIN，此时服务器还可以继续向客户端发送剩余数据
3	`36.99.172.137 → 192.168.0.108`	`[FIN, ACK]`	Seq=350, Ack=1398	服务器也没有数据要发了，发起关闭请求
4	`192.168.0.108 → 36.99.172.137`	`[ACK]`	Seq=1398, Ack=351	客户端确认收到服务器的 FIN，连接正式关闭

标准四次挥手步骤	抓包里的实际包	标志位	说明
1. 客户端关闭发送通道	包 1	`FIN, ACK`	客户端发起关闭请求
2. 服务器确认收到 FIN	包 2 的`ACK`部分	`ACK=1398`	服务器确认客户端的 FIN，这一步和服务器自己的 FIN 合并发送了
3. 服务器关闭发送通道	包 2 的`FIN`部分	`FIN, ACK`	服务器发起自己的关闭请求，和 ACK 合并为一个包
4. 客户端确认收到服务器 FIN	包 3	`ACK=351`	客户端确认服务器的 FIN，挥手完成

包号	方向	标志位	是否带ACK？	说明
2921	客户端→服务器	`[ACK]`	是（纯ACK）	确认收到服务器的SYN+ACK（握手最后一步，无数据）
2922	客户端→服务器	`PSH, ACK`	是	发送HTTP请求 + 确认（常见情况）
2923	服务器→客户端	`[ACK]`	是	单独确认收到了HTTP请求（无数据）
2924	服务器→客户端	`PSH, ACK`	是	发送HTTP响应 + 确认
2925	客户端→服务器	`FIN, ACK`	是	关闭连接 + 确认

特征	连接建立阶段	数据传送阶段
是否带ACK？	第二个包（SYN+ACK）有；第一个（SYN）没有	几乎所有包都有（PSH+ACK 或纯ACK）
是否携带数据？	不携带（Len=0）	经常携带（PSH+ACK），也可以不携带（纯ACK）
你的抓包例子	2892(SYN), 2893(SYN+ACK)	2922(PSH+ACK带请求)，2923(ACK不带数据)，2924(PSH+ACK带响应)

数据传输

过滤器设置
复制代码
tcp.port == 80 and tcp.len > 0
抓包结果示例
复制代码
No.  Time    Source            Destination       Seq    Ack    Len   Flags  Window  Info
4    0.025   192.168.1.2       110.242.68.66     1      1      154   PSH    64240   HTTP GET
5    0.048   110.242.68.66     192.168.1.2       1      155    1460  ACK    8192    TCP segment
6    0.048   110.242.68.66     192.168.1.2       1461   155    1460  ACK    8192    TCP segment
7    0.049   110.242.68.66     192.168.1.2       2921   155    560   ACK    8192    TCP segment
8    0.050   192.168.1.2       110.242.68.66     155     1      0     ACK    64240   TCP ACK
关键分析点

1. PSH标志（Push）
复制代码
Flags: 0x018 (PSH, ACK)
    .... 0... = Push: Set
PSH=1表示通知接收方立即将数据交给应用层，不要等缓冲区满了再交

通常HTTP请求/响应的最后一个包会设置PSH

2. 序列号和确认号追踪

包 Seq Len 覆盖范围 Ack 说明

4 1 154 1-154 1 客户端发送154字节HTTP请求

5 1 1460 1-1460 155 服务器响应第一个数据段

6 1461 1460 1461-2920 155 第二个数据段

7 2921 560 2921-3480 155 最后一个数据段

8 155 0 - 3481 客户端确认收到所有数据

3. 窗口通告
复制代码
Window: 64240    # 客户端窗口
Window: 8192     # 服务器窗口
窗口值告诉对方：我还有多少缓冲区可用

发送方必须保证已发未确认的数据量 ≤ 对方窗口

包	Seq	Len	覆盖范围	Ack	说明
4	1	154	1-154	1	客户端发送154字节HTTP请求
5	1	1460	1-1460	155	服务器响应第一个数据段
6	1461	1460	1461-2920	155	第二个数据段
7	2921	560	2921-3480	155	最后一个数据段
8	155	0	-	3481	客户端确认收到所有数据

重传

过滤器设置
复制代码
tcp.analysis.retransmission
观察重传

如果网络有丢包，会看到类似这样的信息：

这张抓包截图里，出现了几种典型的 TCP 重传 / 异常标记，我帮你逐个拆解清楚👇

一、先搞懂这几个标记分别是什么

标记含义场景说明

TCP Retransmission 标准重传发送方在设定的超时时间内，没有收到对方的 ACK 确认，于是重发该报文

TCP Fast Retransmission 快速重传发送方连续收到3 个重复的 ACK，不等超时就主动重传丢失的报文

TCP Spurious Retransmission 虚假重传发送方重传了一个其实已经被接收方确认过的报文，只是因为 ACK 延迟到达，导致发送方误以为丢包了

二、逐个分析你抓包里的现象

TCP Retransmission（超时重传）

比如 443 → 57183 的 Seq=100 报文，说明发送方发了数据后，一直没收到 ACK，超时后触发了重传。

这种情况通常意味着网络存在丢包、延迟过大，或者接收方处理缓慢。

TCP Fast Retransmission（快速重传）

比如 443 → 57181 的 Seq=4300 报文，发送方收到了 3 个重复的 ACK，不等超时就重传了，说明网络中出现了乱序或轻微丢包，但延迟不算特别严重。

TCP Spurious Retransmission（虚假重传）

截图里大量出现了这个标记，比如 443 → 57187、443 → 57197 的多个报文。

本质原因：发送方的重传定时器触发时，接收方的 ACK 还在路上，发送方误以为丢包，重发了一遍，结果 ACK 很快就到了，Wireshark 就会标记为 "虚假重传"。

常见诱因：网络延迟抖动、ACK 延迟、发送方的 RTO（重传超时）设置过短。

三、为什么会出现这么多异常？

从抓包来看，你的连接同时出现了三种重传，通常意味着：

网络不稳定：存在延迟抖动、ACK 包延迟到达，导致大量虚假重传。

存在丢包：部分报文超时未确认，触发了超时重传和快速重传。

发送方的拥塞控制 / 定时器配置：如果 RTO 设置得太短，ACK 稍微慢一点就会误判丢包，产生虚假重传。

四、这些异常会带来什么影响？

虚假重传 ：本身不会影响数据正确性，但会浪费带宽和 CPU 资源，加重网络负载。

超时 / 快速重传：会导致传输速度下降，延迟增加，严重时会让 TCP 进入拥塞控制，降低发送速率。

当大量异常出现时，就会导致你的连接变慢、卡顿，甚至出现应用超时、断开连接的情况。

💡 补充说明：你看到的 [TCP PDU reassembled in ...] 是 Wireshark 的提示，说明这些分段的 TCP 报文，会被重组为上层的 PDU（比如 TLS/HTTP 数据）。

快速重传

收到3个重复ACK时触发的重传：
复制代码
No.  Time    Source            Destination       Info
15   0.100   110.242.68.66     192.168.1.2       [TCP Dup ACK] ACK=1
16   0.101   110.242.68.66     192.168.1.2       [TCP Dup ACK] ACK=1
17   0.102   110.242.68.66     192.168.1.2       [TCP Dup ACK] ACK=1
18   0.103   192.168.1.2       110.242.68.66     [TCP Fast Retransmission] Seq=1

标记	含义	场景说明
`TCP Retransmission`	标准重传	发送方在设定的超时时间内，没有收到对方的 ACK 确认，于是重发该报文
`TCP Fast Retransmission`	快速重传	发送方连续收到3 个重复的 ACK，不等超时就主动重传丢失的报文
`TCP Spurious Retransmission`	虚假重传	发送方重传了一个其实已经被接收方确认过的报文，只是因为 ACK 延迟到达，导致发送方误以为丢包了

专业分析技巧

1 追踪TCP流

右键点击任意TCP包 → Follow → TCP Stream

Wireshark会：

重构整个TCP会话的所有数据

在一个窗口中显示完整的请求和响应

自动过滤出该流的所有包

2 查看TCP流量图

Statistics → TCP Stream Graph → 多种图表：

Time-Sequence (Stevens)：观察序列号随时间变化，发现重传

Throughput：吞吐量变化

RTT：往返时间

3 使用图形化窗口分析

Statistics → TCP Stream Graph → Window Scaling

可以直观看到窗口通告的变化趋势。

常见TCP问题排查

1 连接超时

观察是否有SYN包但没有SYN+ACK响应：
复制代码
tcp.flags.syn == 1 and tcp.flags.ack == 0
如果看到连续的SYN重传，可能是：

目标端口未监听

防火墙拦截

网络不通

2 端口中了（CLOSE_WAIT堆积）

在抓包中找：
复制代码
tcp.flags.fin == 1
如果大量连接只有单向FIN，说明一方没有正确关闭。

3 零窗口
复制代码
tcp.window_size == 0
窗口为0表示接收方缓冲区满了，发送方停止发送。

4 端口扫描
复制代码
tcp.flags.syn == 1 and tcp.flags.ack == 0
大量来自同一IP的SYN包，可能是端口扫描。

网络好和网络不好时对比

在网络好和网络不好时，这些协议各有什么表现？

我们分两种场景，把 TCP 的核心机制（三次握手 / 数据传输 / 重传 / 流量控制 / 拥塞控制）的表现，给你梳理得明明白白👇

一、网络好（低延迟、低丢包、无拥塞）

1. 三次握手 / 四次挥手

表现：一次往返就完成，几乎没有额外延迟

细节：SYN、SYN+ACK、ACK 都能顺利送达，RTO（重传超时）还没触发，握手就完成了；挥手也不会出现延迟，FIN/ACK 都一次送达。

2. 数据传输

表现：连续高效发送，无乱序、无重复

细节：发送方可以把拥塞窗口（cwnd）快速放大，发送速率接近接收窗口（rwnd）和链路带宽的上限，数据几乎都是按序到达，没有乱序重组的开销。

3. 重传相关

表现：几乎没有任何重传标记

细节：不会出现 Retransmission/Fast Retransmission/Spurious Retransmission，ACK 都按时到达，RTO 永远不会触发。

4. 流量控制

表现：接收窗口（rwnd）稳定，几乎不成为瓶颈

细节：接收方处理速度跟得上发送方，rwnd 保持较大值，发送方的发送窗口由拥塞窗口（cwnd）主导，传输效率拉满。

5. 拥塞控制

表现：慢启动快速完成，长期处于 "拥塞避免" 阶段

细节：没有丢包信号，cwnd 持续线性增长，发送速率平稳提升，充分利用带宽，不会触发 "快速恢复" 或 "超时降窗"。

二、网络不好（高延迟、高丢包、拥塞）

1. 三次握手 / 四次挥手

表现：可能出现 SYN 重传，连接建立 / 断开变慢

细节：

SYN 包丢包时，会触发 SYN 重传，需要等待超时时间（比如 1 秒、3 秒）才会重发，导致连接建立延迟增加。

挥手时 FIN/ACK 丢包，也会导致挥手流程被拉长，甚至出现连接长时间处于 TIME_WAIT 状态。

2. 数据传输

表现：传输断断续续，乱序、重复包多，整体速率上不去

细节：

数据乱序到达，接收方需要缓存乱序包，等缺失的序号补齐，增加了延迟和重组开销。

发送方不敢放大窗口，实际发送速率远低于接收窗口和链路的理论上限。

3. 重传相关（你之前抓包看到的现象）

标记表现原因

TCP Retransmission 大量出现丢包导致 ACK 超时，触发超时重传

TCP Fast Retransmission 频繁出现丢包导致接收方连续发重复 ACK，触发快速重传

TCP Spurious Retransmission 大量出现 ACK 延迟到达，发送方误以为丢包，误触发重传

额外影响：重传会占用额外带宽，进一步加重网络拥塞，甚至形成 "越丢越传、越传越堵" 的恶性循环。

4. 流量控制

表现：接收窗口（rwnd）可能变小，甚至出现零窗口

细节：

接收方处理速度跟不上（比如设备性能差、上层应用卡顿），接收缓冲区被占满，会在 ACK 里发送 rwnd=0，让发送方暂停发送。

这种情况下，发送方会进入 "零窗口探查" 状态，定期发窗口探测包，直到接收方恢复窗口。

5. 拥塞控制

表现：频繁降窗，发送速率剧烈波动

细节：

一旦出现丢包信号，cwnd 会被大幅降低（比如超时降为 1 个 MSS，快速重传降为一半），发送速率瞬间暴跌。

网络稍微恢复，cwnd 又开始增长；再次丢包，又立刻暴跌，形成 "锯齿状" 的速率波动，整体传输效率极低。

严重时会进入 "拥塞崩溃" 状态，大量重传包挤占带宽，正常数据传输几乎停滞。

三、一张表对比核心差异

场景握手 / 挥手数据传输重传流量控制拥塞控制

网络好 快速完成，无延迟连续高效，无乱序无任何重传 rwnd 大，无零窗口 cwnd 持续增长，速率平稳

网络不好 重传延迟，流程拉长断断续续，乱序多大量各类重传 rwnd 可能变小 / 归零 cwnd 频繁升降，速率剧烈波动

💡 补充：你之前抓包里的大量 Spurious Retransmission，就是典型的网络延迟抖动 + 拥塞的表现：ACK 延迟到达，发送方误以为丢包，误触发了重传。

标记	表现	原因
`TCP Retransmission`	大量出现	丢包导致 ACK 超时，触发超时重传
`TCP Fast Retransmission`	频繁出现	丢包导致接收方连续发重复 ACK，触发快速重传
`TCP Spurious Retransmission`	大量出现	ACK 延迟到达，发送方误以为丢包，误触发重传

场景	握手 / 挥手	数据传输	重传	流量控制	拥塞控制
网络好	快速完成，无延迟	连续高效，无乱序	无任何重传	rwnd 大，无零窗口	cwnd 持续增长，速率平稳
网络不好	重传延迟，流程拉长	断断续续，乱序多	大量各类重传	rwnd 可能变小 / 归零	cwnd 频繁升降，速率剧烈波动

网络差的实例

看一个网络差时的抓包实例：

我们结合你这张抓包截图，来分析一下当前网络和 TCP 连接的状态👇

一、先看你抓包里的关键异常标记

我把图里最典型的几个问题点列出来：

TCP Retransmission（超时重传）

多个连接（比如 59085 → 443、59153 → 443）都出现了超时重传，说明发送方发出去的包，长时间收不到 ACK 确认，触发了超时重传。

这是网络丢包 / 延迟过大的直接证据。

TCP Out-Of-Order（乱序包）

比如 59085 → 443 的报文出现乱序，说明数据包到达接收方的顺序和发送顺序不一致，这通常意味着网络存在路径差异、抖动或者轻微丢包。

[RST, ACK] 重置包

59094 → 7826 这个包，发送了 RST, ACK，Win=0。RST 是 TCP 的 "强制重置" 信号，说明：

要么是端口 7826 没有进程在监听，收到了意外的连接请求；

要么是当前连接出现了严重错误，被强制关闭了。

这通常意味着有连接异常断开，或者端口被拒绝访问。

SYN 重传

59153 → 443、59160 → 443 都出现了 SYN 包的重传，说明客户端发起的 TCP 连接请求（SYN 包）没有收到服务器的 SYN+ACK 响应，连接建立失败，触发了 SYN 重传。

这是网络层的连接建立阶段就出现了丢包 / 阻塞。

二、结合场景分析：你现在的网络状况

从这些标记来看，你的网络当前处于 **「丢包 + 延迟抖动 + 部分连接被重置」的不良状态 **，这和你正在看 B 站视频的体验是直接相关的：

视频卡顿、加载慢：因为大量重传和乱序，TCP 的传输速率被拥塞控制限制住了，有效数据传输效率很低。

连接频繁断开 / 重连：RST 重置包和 SYN 重传，说明部分连接无法正常建立或维持，会导致视频加载失败、需要重新缓冲。

三、这些问题会怎么影响你的视频观看体验？

抓包现象对应的用户体验底层原因

TCP Retransmission 视频卡顿、缓冲转圈数据丢包，TCP 重传等待 ACK，传输速率被拉低

TCP Out-Of-Order 画面花屏、加载不连续数据包乱序到达，接收方需要缓存重组，延迟增加

SYN 重传视频无法加载、连接失败连接建立阶段就丢包，无法和服务器正常通信

RST 重置包视频突然中断、需要重新加载连接被强制关闭，需要重新建立连接

四、给你的排查建议

先排除本地网络问题

重启路由器和电脑，减少设备长时间运行导致的网络卡顿。

检查是否有其他设备在占用带宽（比如下载、在线游戏），减少网络竞争。

排查无线信号干扰

如果你用的是 WiFi，尝试靠近路由器，或者切换到有线网络，排除信号弱导致的丢包和乱序。

检查是否是服务器 / 运营商问题

可以打开其他网站 / 视频平台，看看是否同样卡顿。如果只有 B 站卡顿，可能是运营商到 B 站服务器的链路存在问题。

抓包过滤，定位具体连接

在 Wireshark 里，过滤 B 站视频的 IP / 端口，只看和视频相关的 TCP 流，这样能更精准地判断是哪个环节出了问题。

💡 补充：你之前的抓包里也出现了大量的虚假重传和超时重传，结合这次的乱序和 RST 重置，说明你的网络不是偶尔波动，而是持续存在丢包和延迟问题，这会直接影响 TCP 的所有可靠性机制，导致传输效率大幅下降。

抓包现象	对应的用户体验	底层原因
`TCP Retransmission`	视频卡顿、缓冲转圈	数据丢包，TCP 重传等待 ACK，传输速率被拉低
`TCP Out-Of-Order`	画面花屏、加载不连续	数据包乱序到达，接收方需要缓存重组，延迟增加
`SYN` 重传	视频无法加载、连接失败	连接建立阶段就丢包，无法和服务器正常通信
`RST` 重置包	视频突然中断、需要重新加载	连接被强制关闭，需要重新建立连接