wireshark 抓包提示

TCP Previous segment not captured

在TCP的传输阶段,同一台主机发出的数据段应该是连续的,即后一个包的Seq等于前一个包的Seq+Len(三次握手和四次挥手是个例外)。如果wireshark发现后一个包的Seq号大于前一个包的Seq+Len,就知道中间缺失了一段数据(丢包),就会提示这个。

TCP ACKed unseen segment

这应该是Wireshark中最常见的提示,这种提示一般也不需要在意。

这种提示一般是说,被ACK 的包,wireshark没有抓到阿。。。其实既然有ACK 了,这个包一定是被确认了,至于没抓到,那是wireshark的问题。

TCP Out-of-Order

一个包的Seq号等于其前一个包的Seq+Len。但是当发现后一个包的Seq号小于前一个包的Seq+Len时,就会认为是乱序了,因此提示[TCP Out-of-Order] 。

TCP Dup ACK

这个最好理解了。如果发生了乱序,比如服务端发送1,2,3,4,5 号包,客户端收到的是1,2,5 ,4。迟迟收不到3号包,那么客户端就会发Dup Ack 问服务端要 3号包,而不是发来5和4 。

至于为什么客户端没收到3号包,有可能是网络堵塞3号包传的有些慢。也有可能真丢了。当服务端连续3次收到客户端的Dup Ack。服务端就会认为应该是传丢了,那我从3号包开始重传吧。如果收到不满3次,服务端会认为,应该只是传的有些慢,客户端现在应该收到了,那我就不重传了。

TCP Fast Retransmission

这个也好理解,就是上面的Dup Ack 后的快重传。

下图看到 三次 Dup Ack 都是要求服务端(114)发Seq=44289的包 20183#1 就是对20183 号的包重新发送,也就是让客户端发来44289 号包。后面的1 代表这是第几次发送。满3次就会触发服务端的快重传。

TCP Retransmission

如果真的有一个包丢了,有没有后续的包可以让接收端触发Dup Ack。那么就只能等待超时重传,一般会等待100ms。

TCP Spurious Retransmission

虚假重传。发送端认为我发送的数据包丢失了,然后开始重传。但是实际上接收端已经收到了,而且也回了确认包。而接收端又收到一样的包的时候,就会导致发送端出现 [TCP Spurious Retransmission] 提示。

导致虚假超时重传的原因有很多种:

(1)对于部分移动网络,当网络发生切换时会导致网络延时突

(2)当网络的可用带宽突然变小时,网络rtt会出现突增的情况,这会导致虚假超时重传

(3)网络丢包(原始和重传的包都有可能丢包)会导致虚假重传超时。

TCP zerowindow

当接收方的 win=0 的时候,就会带上 TCP zerowindow。表示缓存区已满,不要再发数据了,我接收不了了。很好理解。

TCP window Full

这个很容易和 TCP zerowindow混淆。

这表示,把对方所声明的接受窗口耗尽了。

TCP zerowindow 表示没法接收数据了,TCP window Full 表示没有办法再发数据了。

相关推荐
~山有木兮1 小时前
LiteHub中间件之限流实现
网络·http·中间件
cui_win1 小时前
【网络】Linux 内核优化实战 - net.core.flow_limit_table_len
linux·运维·网络
BD_Marathon2 小时前
虚拟机网络检查
网络
cocologin3 小时前
RIP 技术深度解析
运维·网络·网络协议
GalaxyPokemon4 小时前
RPC-Client模块
网络·网络协议·rpc
chirrupy_hamal5 小时前
如何避免 SYN 攻击?
网络·tcp
怦然星动_6 小时前
ip网络基础
网络·智能路由器
数据与人工智能律师6 小时前
数字资产革命中的信任之锚:RWA法律架构的隐形密码
大数据·网络·人工智能·云计算·区块链
yanwushu6 小时前
10分钟搭建 PHP 开发环境教程
php·laravel
菜包eo7 小时前
二维码驱动的独立站视频集成方案
网络·python·音视频