7ACE-优快云博客

原创 Wireshark TS | 关闭连接和超时重传

本文探讨了TCP超时重传过程中上层应用主动关闭连接的行为。测试了两种关闭方式：优雅关闭(FIN)和强制关闭(RST)。实验表明，在优雅关闭时，未确认的数据包会继续重传，而FIN包不会进入重传队列；若数据包先被确认，FIN包则会开始重传。强制关闭则直接终止连接，跳过重传过程。通过packetdrill脚本和tcpdump抓包验证了这些现象，揭示了TCP连接关闭与重传机制的交互关系。

2025-12-11 21:39:59 934

原创 Wireshark TS | 接收数据超出接收窗口续

TCP 弯弯绕绕的知识点真是多，再次感叹。

2025-11-01 10:42:18 1056

文章摘要：本文探讨了TCP接收端在接收窗口满时仍能接收超量数据的现象。通过实验发现，当接收窗口设置为2920字节时，客户端连续发送三个1460字节的数据段后，服务端不仅确认了第二个数据段，还确认了第三个数据段，且应用层能读取全部4380字节数据。分析表明，这是由于第三个数据包触发了内核TCP快速路径处理（tcp_rcv_established），该路径简化了校验流程，未严格检查接收窗口剩余空间，导致窗口限制被绕过。该现象揭示了Linux内核在特定条件下对TCP协议的宽松处理机制。（字数：150）

2025-09-09 21:37:24 630

原创 Wireshark TS | 发送数据超出接收窗口

摘要：本文探讨了一个TCP接收窗口未按预期生效的案例。通过packetdrill脚本模拟发现，当服务器写入4000字节数据时，尽管客户端通告窗口为2000，服务器仍发送了4个数据包。分析发现，接收窗口更新依赖tcp_may_update_window()函数，需满足ACK序号更新、窗口序号更新或新窗口更大三个条件之一。实验调整窗口值为3000和2000后，服务器仅发送3个数据包，证实窗口更新机制导致2000窗口未生效。该案例揭示了TCP窗口更新的关键条件，帮助理解实际网络行为与理论预期的差异。

2025-07-27 22:09:47 716

原创 Wireshark TS | 诡异的光猫网络问题

摘要：用户反馈通过光猫WiFi无法访问特定公网域名，而有线网络正常。通过多节点抓包分析发现，客户端发送的ACK数据包在光猫出口处被额外填充54字节全0数据，导致长度异常被中间防火墙阻断，服务器端因未收到ACK持续重传，最终表现为网页无法打开。问题根源在于光猫对TCP ACK数据包的异常填充行为。该案例展示了网络设备异常行为可能导致的隐蔽性故障。（150字）

2025-07-01 20:51:24 1012

原创 Wireshark TS | 浅谈直播丢帧问题

限于知识面，确实只能浅谈下数据包现象，实际上反映在直播应用上，是否一定能对应问题现象，还需要进一步的测试，但像是应用上反馈的丢帧，从数据包上来说，实际上是乱序（此处较真）~

2025-05-11 11:09:37 947

原创 Wireshark TS | 异常 ACK 数据包处理

存在即合理，数据包分析也会有这样的一个观点，不是嘛。

2025-04-17 21:56:08 1421

原创 Wireshark TS | 再谈虚假的 TCP Spurious Retransmission

所以仅仅是捕获数据包的问题，实际的生产交互完全不会有这样的问题，因此类似这样的案例学习了解原因即可，也就完全没必要在 Wireshark 中手动修改该重传数据包为乱序，没有意义。

2025-02-11 08:18:27 1789

原创 Wireshark TS | 虚假的 TCP Spurious Retransmission

如何高效的分析 TCP 乱序、重传，确实是一个很值得探讨的问题。

2025-01-21 09:07:31 1743

原创 Wireshark TCP 分析标志位说明汇总

在 Wireshark 网络数据包分析中，比较常见的一些 TCP 分析标志位的说明和案例汇总如下：

2025-01-10 08:36:34 481

原创 TCP Analysis Flags 之 TCP Retransmission

文档中关于的定义看起来简单，但实际考虑到 TCP 乱序、重传场景的复杂性，在 TCP 分析中对于是与等在一起判断标记乱序或重传类型，而在不少场景还会有判断出错的问题，当然 Wireshark 考虑到这种情况，也有手动修正的选项，这正好也侧面证明了上面的说法，关于 TCP 乱序、重传的复杂性。不是 Keep-Alive 数据包TCP 段大小大于零或设置了 SYN/FIN同方向之前下一个期望的 Seq Num 大于当前数据包的 Seq Num。

2025-01-05 15:41:30 1190

原创 TCP Analysis Flags 之 TCP Out-Of-Order

文档中关于的定义看起来简单，但实际考虑到 TCP 乱序、重传场景的复杂性，在 TCP 分析中对于是与等在一起判断标记乱序或重传类型，而在不少场景还会有判断出错的问题，当然 Wireshark 考虑到这种情况，也有手动修正的选项，这正好也侧面证明了上面的说法，关于 TCP 乱序、重传的复杂性。不是 Keep-Alive 数据包TCP 段大小大于零或设置了 SYN/FIN同方向之前下一个期望的 Seq Num 大于当前数据包的 Seq Num。

2024-12-28 14:18:01 1770

原创 TCP Analysis Flags 之 TCP Fast Retransmission

文档中关于的定义看起来简单，但实际考虑到 TCP 乱序、重传场景的复杂性，在 TCP 分析中对于是与等在一起判断标记乱序或重传类型，而在不少场景还会有判断出错的问题，当然 Wireshark 考虑到这种情况，也有手动修正的选项，这正好也侧面证明了上面的说法，关于 TCP 乱序、重传的复杂性。不是 Keep-Alive 数据包同方向 TCP 段大小大于零或设置了 SYN/FIN 标志位同方向之前下一个期望的 Seq Num 大于当前数据包的 Seq Num反方向至少有两个重复 ACK。

2024-12-17 08:15:19 1312

原创 TCP Analysis Flags 之 TCP Spurious Retransmission

文档中关于的定义看起来简单，但实际考虑到 TCP 乱序、重传场景的复杂性，在 TCP 分析中对于是与等在一起判断标记乱序或重传类型，而在不少场景还会有判断出错的问题，当然 Wireshark 考虑到这种情况，也有手动修正的选项，这正好也侧面证明了上面的说法，关于 TCP 乱序、重传的复杂性。SYN 或者 FIN 标志位设置不是 Keep-Alive 数据包TCP 段长度大于零该 TCP 流的数据已被确认，也就是说，反方向之前的 LastACK Num 已被设置。

2024-12-04 20:19:17 1425

原创 TCP Analysis Flags 之 TCP Dup ACK

TCP 段大小为 0窗口大小非零且没有改变，或者有有效的 SACK 数据下一个期望的 Seq Num 和 LastACK Num 是非 0 的（即连接已经建立）没有设置 SYN、FIN、RST具体的代码如下，总的来说这段代码的用于准确检测 TCP 重复 ACK 的情况，并记录相关信息以支持后续的重传机制分析，是 TCP 可靠传输的重要组成部分。这段代码的主要逻辑如下，如果所有下述条件均满足，则认为该数据包是一个重复确认包。检查 TCP 段大小是否为 0；检查窗口大小是否不为 0；

2024-11-16 10:47:34 1850

原创 TCP Analysis Flags 之 TCP Keep-Alive

实际在 TCP 分析中，关于和当 TCP 数据段大小为 0 或 1 时设置，当前序列号比下一个期望的序列号小 1 字节，并且没有设置 SYN、FIN 或 RST。替代。next expected sequence number，为 nextseq，定义为 highest seen nextseq。具体的代码如下，总的来说这段代码的作用是检测出 TCP 保活包，并对其进行适当的标记，以便 Wireshark 能够正确识别和显示这种特殊的 TCP 控制数据包，帮助分析长连接的保活状态。

2024-11-02 16:44:18 1534

原创 TCP Analysis Flags 之 TCP Window Update

实际在 TCP 分析中，关于TCP 段大小为零窗口大小非零，不等于之前的窗口大小，并且没有有效的 SACK 数据Seq Num 等于之前下一个期望的 Seq NumACK Num 等于之前的 LastACK Num，或者等于在响应 ZeroWindowProbe 时的下一个期望的 Seq NumSYN、FIN、RST 均未设置next expected sequence number，为 nextseq，定义为 highest seen nextseq。

2024-10-16 22:09:25 2224 1

原创 TCP Analysis Flags 之 TCP ZeroWindowProbe

实际在 TCP 分析中，关于TCP ZeroWindowProbe 和 ZeroWindowProbeAck当 Seq Num 等于之前下一个期望的 Seq NumTCP 段大小为 1反方向最后一次看到的接收窗口大小为零时设置影响或。具体的代码如下，总的来说这段代码的作用是检测零窗口探测包，并对其做出适当的标记，以便 Wireshark 进行后续的分析和显示。主要检测以下三个条件，如果都满足，则认为是一个零窗口探测数据包。检查 TCP 段长度是否为 1 字节；

2024-10-03 21:54:17 1596

原创 TCP Analysis Flags 之 TCP ZeroWindow

TCP Analysis Flags 之 TCP ZeroWindow

2024-09-15 22:25:32 1948

原创 TCP Analysis Flags 之 TCP Port numbers reused

实际在 TCP 分析中，关于的定义非常简单，如下，针对 SYN 数据包(而不是SYN+ACK)，如果已经有一个使用相同 IP+Port 的会话，并且这个 SYN 的序列号与已有会话的 ISN 不同时设置。注意：官方文档此处说明的是 SYN，而非 SYN/ACK，和实际代码实现的却不一样，下述展开说明。具体的代码如下，主要作用是处理 SYN 以及 SYN/ACK 数据包，判断是新连接还是已有连接的重传，并相应地创建新会话或更新会话的序列号等，并设置相关标志位。

2024-09-04 10:43:58 3269

原创 TCP Analysis Flags 之 TCP ACKed unseen segment

实际在 TCP 分析中，关于的定义非常简单，当为反方向设置了期望的下一个确认号并且它小于当前确认号时设置。具体的代码如下，涉及到 TCP 分析逻辑还是稍复杂，毕竟涉及到不同方向的 Seq 和 Ack Num 计算，其中还涉及零窗口恢复时候的的一个特殊场景。总之，代码通过识别和处理 TCP 数据流中的 “被 ACK 的丢失数据包” 情况，并调整变量来反映被 ACK 的最大序列号，从而准确跟踪分析 TCP 连接的状态。else {

2024-08-24 15:53:32 3045

原创 TCP Analysis Flags 之 TCP Window Full

实际在 TCP 分析中，关于的定义非常简单，如下，为本端发送端所发的 TCP 段大小超过对端接收端的接收窗口大小，受到对端接收窗口大小的限制，需注意的是这个标记是在发送端标记，而不是在接收端标记。具体的代码如下，总的来说这段代码的作用是检测 TCP 数据流中的“窗口已满”情况，即当前数据段刚好达到接收端宣告的窗口边界，检测到这种情况时，会设置相应的标志以供后续处理使用。*/=-1if(!lastack，定义为 Last seen ack for the reverse flow。

2024-08-03 11:06:28 2416 1