wireshark 的使用小技巧。
wireshark 在抓包过程中经常有一些英文提示，通常以醒目的颜色标注，让人注意。下面将解释常见的一些提示的作出详细解释。
[TCP Previous segment not captured]
在TCP的传输阶段，同一台主机发出的数据段应该是连续的，即后一个包的Seq等于前一个包的Seq+Len（三次握手和四次挥手是个例外）。如果wireshark发现后一个包的Seq号大于前一个包的Seq+Len，就知道中间缺失了一段数据(丢包)，就会提示这个。
这里可以看到第653 是 一个提示 TCP Previous segment not captured 的数据包。在其651号包的Seq是50664,而Len为1452 。那么应该其653号包为 50664+1452 = 52116 。但是事实上653号包为63158（见下面的黄色部分），证明中间有数据包没有抓到。
出现这种提示一般有两种情况。一种是数据包真的丢了。另一种是没有丢，但被wireshark给漏掉了。如果该确认包包含了没抓到的那个数据包，那就是wireshark漏掉了。
上图在 TCP Previous segment not captured 后跟上了客户端回复的DUP ACK ,证明这真是数据包丢了，和wireshark没关系。。。
[TCP ACKed unseen segment]
这应该是Wireshark中最常见的提示，这种提示一般也不需要在意。
这种提示一般是说，被ACK 的包，wireshark没有抓到阿。。。其实既然有ACK 了，这个包一定是被确认了，至于没抓到，那是wireshark的问题。
[TCP Out-of-Order]
一个包的Seq号等于其前一个包的Seq+Len。但是当发现后一个包的Seq号小于前一个包的Seq+Len时，就会认为是乱序了，因此提示[TCP Out-of-Order] 。
这里可以看到，114（服务端）给我发来一个 TCP Previous 疑似丢包，Seq 是 44294（下面的黄色区域）。而接下来来发过来的包的Seq就是41556 和43008 。都比44294 小，证明，乱序了。
小跨度的乱序没有影响，比如原本的1，2，3，4，5 号包被打乱成2，1，3，4，5就没事，但是大幅度的乱序就可能导致出发快重传，比如打乱为2，3，4，5，1时，就会触发很多Dup ACK，从而导致1号包重传。（没有SACK或new reno的话。可能1以后的全部都需要重传）
[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 表示没有办法再发数据了。
