在Wireshark中,你会看到一个标记为"TCP Dup ACK"的事件,它表示接收方已经收到了重复的确认,这通常暗示着之前的某个数据包丢失了。 总结: TCP Retransmission 是发送方为了确保数据的可靠传输而重发丢失的数据包。 TCP Dup ACK 是接收方为了指示发送方它需要丢失的数据包而发送的重复确认。 wireshark抓包中TCP Ret...
2.TCP Dup ACK + TCP Retransmission 一个看起来实际像是丢包,实际为乱序的场景。该数据包为客户端所抓取,No.33 和 No.34 为客户端所发送的数据分段,但在收到服务器端所返回的 No.36 Ack Num 11217 以及 SACK SLE=12168 SRE=12239 说明未收到 No.33,而收到了 No.34 数据包段,因此在客户端由 RACK ...
重传场景的复杂性,在 TCP 分析中对于TCP Spurious Retransmission是与TCP Out-Of-Order、TCP Fast Retransmission、TCP Retransmission等在一起判断标记乱序或重传类型,而在不少场景还会有判断出错的问题,当然 Wireshark 考虑到这种情况,也有手动修正的选项,这正好也侧面证明了上面的说法,关于 TCP 乱序、重传的复杂性。
这里需要引入 RTT 和RTO 的概念:RTT(Round Trip Time) 指一个数据包从发出去到回来的时间,RTO(Retransmission TimeOut) 指的是重传超时的时间。很显然,只有比较精确地评估出来对端接收到数据包并 ACK 回包的时间,才能准确地评估 RTO 的初始值。 RTO 评估的过大会导致通信效率降低,RTO 评估的过小会导致没有必...
3.1.1.2 TCP Retransmission原因分析: 很明显是上面的超时引发的数据重传。 3.1.1.3 TCP dup ack XXX#X原因分析: 就是重复应答#前的表示报文到哪个序号丢失,#后面的是表示第几次丢失。 3.1.1.4 tcp previous segment not captured原因分析 意思就是报文没有捕捉到,出现报文的丢失。
4、TCP Retransmission TCP超时重传。当同时抓到2次同一数据报文,且没有抓到初传包的反馈ack,wireshark就会判断发生了重传,标记为TCP Retransmission。 如果一个包丢了,又没有后续包可以在接收方触发Dup Ack,或者Dup Ack也丢失的话就不会快速重传。这种情况下发送方只能等到超时再重传。
328包,服务端向客户端发送了seq=137031的数据包,仍然与客户端期望不符,客户端在329包再次重传ack=133251的包。 330包,服务端收到3次重复ack,触发快速重传,重传了seq=133251的TCP分片。 7)TCP Retransmission 如果一个包真的丢了,又没有后续包可以在接收方触发【Dup Ack】就不会快速重传。
3.Tcp Dup Ack 12345#1 4.Tcp Spurious Retransmissiion 5.Tcp Retransmission 其中1、2、3会相伴出现,3、4、5会相伴出现。对应第一种情况是由于由于TCP数据被分块后,传输过程中经过不同的路径,到达目的端时乱序,出现后发而先至的情况,此时目的端会显示【Tcp Previous Segment Not captured】,并且用【Tcp Dup...
TCP Retransmission原因分析:很明显是上面的超时引发的数据重传 • nginx上的抓包内容如下 nginx上抓包就更简单了,上面物理机发送的http报文,在nginx上居然没有捕获到,难道是偶然的?然后又重新试了几次,在nginx上都没有捕获到。到这里,就能确定了,物理机到阿里云的网络链路有问题,出现丢包了。
No123和No124: 服务器向客户端发送握手数据,包标记的是TCP Retransmission,两个包的seq分别为1461和2921,由于服务端认为已经发了这两个包(实际seq=1461的包没发,由No105可看出,seq=2921的包发了,但是客户端没有响应响应的ACK包),然后长时间收不到客户端的ACK包,因此服务端会重发这两个包。