简单来说,是在数据包跟踪文件中已经被 ACK 确认过的数据分段,又再一次被重传发送,那么这个重传的数据分段会被标记为 [TCP Spurious Retransmission]。 但本案例既然说是虚假的 [TCP Spurious Retransmission],那么就意味着说是 Wireshark 判断错误。 问题信息 数据包跟踪文件基本信息如下: λ capinfos SR.pcapng Fil...
重传场景的复杂性,在 TCP 分析中对于TCP Spurious Retransmission是与TCP Out-Of-Order、TCP Fast Retransmission、TCP Retransmission等在一起判断标记乱序或重传类型,而在不少场景还会有判断出错的问题,当然 Wireshark 考虑到这种情况,也有手动修正的选项,这正好也侧面证明了上面的说法,关于 TCP 乱序、重传的复杂性。
Wireshark's Expert can detect "Spurious Retransmissions." What triggers these types of retransmissions and should you be worried about them? We'll analyze a trace to identify the most likely cause of these types of retransmissions.
Wireshark中常见的TCP Info Retransmission。基于软件的判定机制,如果抓包点在客户端的话,TCP重传一般为上行包,因为这时,客户端并没有收到服务端的ack,无从知晓服务端是否收到了初传包,RTO超时后触发客户端重传。此时存在2...wireshark抓到,但很有可能服务端未收到此反馈ack,RTO超时,触发服务端重传。如下图,红...
call “needless retransmission” in our own expert system. “Needless” probably doesn’t sound technically weird enough, so in papers about those retransmissions they were labeled “spurious”. There is a bug report where the patch was mentioned athttps://bugs.wireshark.org/bugzilla/show_bug....
对于第一种情况,如果抓包点在服务端的话,wireshark很有可能就会把来自客户端的重传包标记为TCP Spurious Retransmission。 如下图,红线的TCP包为重传包,wireshark为该包添加了重传原因,是由于TRO超时导致,以及初传包序号45,并给出了当前的RTO超时时间。
本案例所说的虚假的[TCP Spurious Retransmission],虽然也指的是 Wireshark 判断错误,但真实的问题并不是 Wireshark 所产生。 问题信息 数据包跟踪文件基本信息如下: λ capinfos "SR 02.pcapng" File name: SR 02.pcapng File type: Wireshark/... - pcapng ...