能发锚文本的网站,wordpress 获取当前page id,wordpress评论区美化,网站框架前言
默认情况下#xff0c;Wireshark 的 TCP 解析器会跟踪每个 TCP 会话的状态#xff0c;并在检测到问题或潜在问题时提供额外的信息。在第一次打开捕获文件时#xff0c;会对每个 TCP 数据包进行一次分析#xff0c;数据包按照它们在数据包列表中出现的顺序进行处理。可…前言
默认情况下Wireshark 的 TCP 解析器会跟踪每个 TCP 会话的状态并在检测到问题或潜在问题时提供额外的信息。在第一次打开捕获文件时会对每个 TCP 数据包进行一次分析数据包按照它们在数据包列表中出现的顺序进行处理。可以通过 “Analyze TCP sequence numbers” TCP 解析首选项启用或禁用此功能。
TCP 分析展示
在数据包文件中进行 TCP 分析时关于 “TCP Dup ACK” 一般是如下显示的包括
Packet List 窗口中的 Info 信息列以 [TCP Dup ACK #] 黑底红字进行标注Packet Details 窗口中的 TCP 协议树下在 [SEQ/ACK analysis] - [TCP Analysis Flags] 中定义该 TCP 数据包的分析说明。 TCP Dup ACK 定义
实际在 TCP 分析中关于 TCP Dup ACK 的定义也相对来说简单包括如下
TCP 段大小为 0窗口大小非零且没有改变或者有有效的 SACK 数据下一个期望的 Seq Num 和 LastACK Num 是非 0 的即连接已经建立没有设置 SYN、FIN、RST
Set when all of the following are true:The segment size is zero.
The window size is non-zero and hasn’t changed, or there is valid SACK data.
The next expected sequence number and last-seen acknowledgment number are non-zero (i.e., the connection has been established).
SYN, FIN, and RST are not set.具体的代码如下总的来说这段代码的用于准确检测 TCP 重复 ACK 的情况并记录相关信息以支持后续的重传机制分析是 TCP 可靠传输的重要组成部分。这段代码的主要逻辑如下如果所有下述条件均满足则认为该数据包是一个重复确认包。
检查 TCP 段大小是否为 0检查窗口大小是否不为 0检查窗口大小与同方向之前窗口大小是否相同检查 Seq Num 是否等于同方向之前下一个期望的 Seq Num检查 ACK Num 是否等于同方向之前的LastACK Num检查当前数据包是否不是 SYN/FIN/RST 数据包。 /* DUPLICATE ACK* It is a duplicate ack if window/seq/ack is the same as the previous* segment and if the segment length is 0*/if( seglen0 window windowtcpd-fwd-window seqtcpd-fwd-tcp_analyze_seq_info-nextseq acktcpd-fwd-tcp_analyze_seq_info-lastack (flags(TH_SYN|TH_FIN|TH_RST))0 ) {/* MPTCP tolerates duplicate acks in some circumstances, see RFC 8684 4. */if(tcpd-mptcp_analysis (tcpd-mptcp_analysis-mp_operations!tcpd-fwd-mp_operations)) {/* just ignore this DUPLICATE ACK */} else {tcpd-fwd-tcp_analyze_seq_info-dupacknum;if(!tcpd-ta) {tcp_analyze_get_acked_struct(pinfo-num, seq, ack, TRUE, tcpd);}tcpd-ta-flags|TCP_A_DUPLICATE_ACK;tcpd-ta-dupack_numtcpd-fwd-tcp_analyze_seq_info-dupacknum;tcpd-ta-dupack_frametcpd-fwd-tcp_analyze_seq_info-lastnondupack;}}next expected sequence number为 nextseq定义为 highest seen nextseq。lastack定义为 Last seen ack for the reverse flow。 Packetdrill 示例
根据上述 TCP Dup ACK 定义和代码说明通过 packetdrill 模拟丢包现象即可因缺失中间一段数据在收到后一段数据后就会触发产生 TCP Dup ACK 数据包。
# cat tcp_dup_ack.pkt
0 socket(..., SOCK_STREAM, IPPROTO_TCP) 3
0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) 0
0 bind(3, ..., ...) 0
0 listen(3, 1) 00 S 0:0(0) win 16000 mss 1460
0 S. 0:0(0) ack 1 ...
0.01 . 1:1(0) ack 1 win 160000 accept(3, ..., ...) 4
0 P. 1:21(20) ack 1 win 15000
0 P. 41:61(20) ack 1 win 15000
# 经 Wireshark 展示如下可以看到满足判断条件后No.7 标识 [TCP Dup ACK 5#1] 意味着 No.7 与 No.5 重复发生一次。 如果想触发多次重复的 Dup ACK可增加几次后续数据段即可如下
# cat tcp_dup_ack_02.pkt
0 socket(..., SOCK_STREAM, IPPROTO_TCP) 3
0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) 0
0 bind(3, ..., ...) 0
0 listen(3, 1) 00 S 0:0(0) win 16000 mss 1460
0 S. 0:0(0) ack 1 ...
0.01 . 1:1(0) ack 1 win 160000 accept(3, ..., ...) 4
0 P. 1:21(20) ack 1 win 15000
0 P. 41:61(20) ack 1 win 15000
0 P. 61:81(20) ack 1 win 15000
0 P. 81:101(20) ack 1 win 15000
# 经 Wireshark 展示如下No.7 标识 [TCP Dup ACK 5#1] No.9 标识 [TCP Dup ACK 5#2] No.11 标识 [TCP Dup ACK 5#3] 共重复三次。 实例
关于 TCP Dup ACK 的实例实际日常抓包中经常会看到是比较常见的一种 TCP 分析信息多数情况会发生在乱序或丢包场景中。在不同的场景中也会伴生着出现像是 TCP Previous segment not caputred 、TCP Fast Retransmission、TCP Spurious Retransmission 等信息当然有时也会单独出现。
TCP Dup ACK TCP Fast Retransmission
很常见的数据段丢包场景No.1969 Seq Num 为 1431提示 TCP 之前的数据分段未被捕获到也即丢失了一个长度为 1430 字节的数据分段Seq Num 1、Next Seq Num 1431因此在收到 No.1969-1971 三个数据分段后客户端会依次响应 No.1972-1974 三个 ACK 数据包包含 SACK 信息并标识为 [TCP Dup ACK]重复三次#1-#3这样服务器端触发产生了之前丢失分段的快速重传即 No.1975 数据包。 TCP Dup ACK TCP Retransmission
一个看起来实际像是丢包实际为乱序的场景。该数据包为客户端所抓取No.33 和 No.34 为客户端所发送的数据分段但在收到服务器端所返回的 No.36 Ack Num 11217 以及 SACK SLE12168 SRE12239 说明未收到 No.33而收到了 No.34 数据包段因此在客户端由 RACK 触发了重传了 No.33 数据包也就是 No.37 Seq Num 11217而在之后才收到了服务器端的 No.38 和 No.39 两个 Ack其中 No.39 标识 [TCP Dup ACK] No.38 Ack Num 为 12239 , 而 No.39 Ack Num 也为 12239 SACK SLE11217 SRE12168说明在服务器端收到了两个同样的分段 Seq 11217 Len 951 的数据段也就是说 No.38 ACK 确认的是 No.33 原始数据段而 No.39 ACK 确认的是 No.37 重传数据段。 TCP Dup ACK TCP Spurious Retransmission
一个 RTO 超时重传的场景该数据包为客户端所抓取对于服务器端所发送的 No.6 数据段客户端由于延迟确认等原因间隔 209ms 才发出 No.7 Ack 确认了该数据段但同时此时在服务器端又因为 RTO 超时重传对 No.6 进行了重传也就是 No.8 数据包标识 [TCP Spurious Retransmission]继而触发客户端发送了 No.9 ACK 数据包标识 [TCP Dup ACK]。 TCP Dup ACK TCP Out-Of-Order
一种数据包乱序的场景该抓包点在客户端本地服务器端所发送的数据分段在到达时即已发生了乱序No.5 标识为 [TCP Previous segment not captured]之前应该还有两个 Len1460 的分段No.6 为其中一个乱序数据段标识为 [TCP Out-Of-Order] 之后客户端 No.7 Ack 确认了 No.5标识为 [TCP Dup ACK]同时 SACK SLE2921 SRE4201No.8 Ack Num 1461 SACK SLE2921 SRE4201 确认了 No.6之后才收到另外一个乱序数据段 No.9最后回复 No.10 Ack Num 4201 。 看不到 TCP Out-Of-Order 的乱序
同样一种数据包乱序的场景但是看不到乱序标识这是正常的只是抓包点的问题。该数据包为客户端所抓取因为看到的客户端 No.3414 Len 1573 实际会大于 MTU 1380但是在出本地网卡后会变成两个数据包一个 Len 1380另一个 Len 193再加 No.3415 Len 213一共三个数据包到达了服务器此时可能在中间网络传输中发生了乱序数据分段顺序变成了 Len 193、Len 213、Len 1380这样前两个数据包会触发服务器产生 No.3416-3417 ACK 数据包标识为 [TCP Dup ACK]其中 No.3416 SLE17956 SRE18149 表明收到了 Len 193 的数据分段No.3417 SLE17956 SRE18362 表明又收到了 Len 213 的数据分段而在之后的 No.3420 ACK Num 18362 才表示收到了 Seq Num 18362 之前所有的数据分段。 总结
考虑到数据包会出现乱序、丢包、重传等各类不同的场景产生 TCP Dup ACK 的情形自然也是五花八门具体问题具体分析。
