(2) wireshark一些特性

1. 相对seq切换实际seq

Seq的初始值理论上是一个随机值，但是wireshark可以把它设置为从0开始的相对值：

在编辑-首选项-protocols-TCP 取消相对seq:

2. TCP确认号

TCP 发出的确认号 = 上一个接收报文的seq + 上一个接收报文的len。

三次握手不套用这条公式(需要seq+1)。

但是，len == 0 并不代表没有意义，该Len并不包括tcp的头部信息，其实也表示有一个报文。

3. Tcp接收窗口

TCP接收窗口表示发送该窗口的设备还有多少TCP缓存空间。

当发送ACK确认时，ACK序号报文之前占用的缓存被清空处理，可继续再使用，于是接收窗口扩展该被清空的空间。

但是接收窗口字段只有16bit，最大只支持65535大小，但是现在的网络环境已经可以支持大于该窗口的带宽，那么在三次握手时，双方各自申明一个window scale, 该值乘以报文中声明的接收窗口大小，得到实际的接收窗口。

而接收窗口大小受发送窗口和网络影响（拥塞窗口），报文没有字段直接体现。

4. TCP MTU协商

在TCP三次握手时，双方会告知自己的MSS，而MTU则为MSS + TCP Len + IP Len.

但是如果双方MSS大小不一致，则以较小的决定。

MTU与MSS关系：

MSS为TCP报文中的载荷数据。

MTU为MAC报文中的载荷数据。

5. TCP延迟确认

理论上收到报文之后，会在短暂时间内回复ACK, 但是若开启的延迟确认（windows默认为200ms）,在收到一个包之后暂时没有数据发送给对方，就延迟一段时间再发送ACK进行确认。但是假如在这段等待的时间内有其他报文要发送，那么会顺便一起带过去，虽然减轻网络负荷，但是降低了性能。

6. 选择重传SACK

SACK的开启，需要在三次握手的时候，双方都协商同意，即SACK_PEEM=1.

若有一方没有同意，则后续并不会启用SACK.

报文中选择重传字段带有ACK期待的报文序号，比期待的大的一段已经接收的报文区间序号，这样可以判断出缺少了哪一段报文序号。

7. TCP previous segment not capture

收到报文291的seg 18940 + len 1412 == 20352, 理论上下一个收到seq 20352的报文，但是实际上收到大于该值的seq 23176 报文，中间有报文缺失，则wireshark提示。

8. TCP out of order

TCP在传输过程中，（不包括3次握手、4次挥手），理论上同一主机发出的数据报文应该数连续的，即的  当前seq + 当前len == 下一个seq, 但是当wireshark收到的下一个报文的seq小于该值，则标志 TCP Out-Of-Order，说明报文出现了乱序。

9. TCP Dup ACK

当乱序或者丢包发生，接收方会收到一些seq比期望大的值，每收到一个这种包，就会ACK一次期望的seq，因此就产生的重复的ACK。

10. TCP fast Retransmission

当收到3个或以上重复ACK的时候，就意识到之前的报文被丢了，就快速重传该期待的报文。

11. TCP Retransmission

当发出一个报文，在超时时间RTO内没有收到ACK回应，则重传该报文。

12. TCP zerowindow

报文中的“win=”表示告诉对端，自己还有多少缓存区可以接收数据，当为0时，wireshark则会打上TCP zerowindow标签, 表示缓存区满，不能再接收数据，通知对端不要再发了。

13. TCP window Full

当wireshark 在某个包打上TCP window Full标签时，表示该包已经把对方声明的接收窗口耗尽了。

关于“耗尽”的个人理解：对端声明的窗口为100，我向对端发送seq为40的报文，若对端没有回应ACK 40, 则对端窗口还有60缓存空间；若对端回应了ACK 40, 表示处理完了，那么对端还有100缓存空间。

TCP window Full表示我不能再发送数据了；

TCP zerowindow 表示我不能再接收数据了；

14. IP层中的identification

每发一个报文，IP层中的identification字段就要加1。

对于接收方，若收到的是分片报文，则属于同一报文的每一片的identification都相同。