7ACE-优快云博客

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

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

2025-02-11 08:18:27 1585

原创 Wireshark TS | 虚假的 TCP Spurious Retransmission

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

2025-01-21 09:07:31 1539

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

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

2025-01-10 08:36:34 375

原创 TCP Analysis Flags 之 TCP Retransmission

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

2025-01-05 15:41:30 943

原创 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 1299

原创 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 1151

原创 TCP Analysis Flags 之 TCP Spurious Retransmission

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

2024-12-04 20:19:17 1049

原创 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 1368

原创 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 1225

原创 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 1659 1

原创 TCP Analysis Flags 之 TCP ZeroWindowProbe

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

2024-10-03 21:54:17 1354

原创 TCP Analysis Flags 之 TCP ZeroWindow

TCP Analysis Flags 之 TCP ZeroWindow

2024-09-15 22:25:32 1517

原创 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 2312

原创 TCP Analysis Flags 之 TCP ACKed unseen segment

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

2024-08-24 15:53:32 2168

原创 TCP Analysis Flags 之 TCP Window Full

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

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