电子商务网站建设系统seogw

[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 表示没有办法再发数据了。