TCP 协议（五）异常报文

TCP 协议（一）报文结构
TCP 协议（二）连接与断开
TCP 协议（三）十种核心机制
TCP 协议（四）重传与超时
TCP 协议（五）异常报文

1.[TCP Dup ACK xxx#y]（重复应答）
2.[TCP Fast Retransmission]（快速重传）
3.[TCP Retransmission]（超时重传）
4.[TCP Out-Of-Order]（报文乱序）
5.[TCP Previous segment not captured]（报文缺失）
6.[TCP Spurious Retransmission]
7.[TCP segment of a reassembled PDU]
8.[TCP Keep-Alive]
9.[TCP Keep-Alive ACK]
10.[TCP ZeroWindow]
11.[TCP window update]
12.[TCP window Full]

名词解释

RTO（重新发送超时时间）

重新发送的机制：
1.发送方发送数据：当发送方送出一个 TCP 片段后，将开始计时，等待该 TCP 片段的 ACK 回复。
2.接收方返回ACK：如果接收方正确接收到符合次序的片段，接收方会利用 ACK 片段回复发送方。
3.发送方接收ACK：发送方得到 ACK 回复后，继续移动窗口，发送接下来的 TCP 片段。
如果直到计时完成，发送方还是没有收到 ACK 回复，那么发送方推断之前发送的 TCP 片段丢失，因此重新发送之前的TCP片段。这个计时等待的时间叫做重新发送超时时间(RTO, retransmission timeout)。

RTT（往返时间）

发送方应该在等待多长时间之后重新发送呢？这是重新发送的核心问题。上述过程实际上有往返两个方向：1. 发送片段从发送方到接收方的传输，2. ACK片段从接收方到发送方的传输。整个过程实际耗费的时间称做往返时间(RTT, round trip time)。

如果RTT是固定的，比如1秒，那么我们可以让 RTO 等于 RTT。但实际上，RTT 的上下浮动很大。比如某个时刻，网络中有许多交通，那么 RTT 就增加。在 RTT 浮动的情况下，如果我们设置了过小的 RTO，那么 TCP 会等待很短的时间之后重新发送，而实际上之前发送的片段并没有丢失，只是传输速度比较慢而已，这样，网络中就被重复注入 TCP 片段，从而浪费网络传输资源。另一方面，如果 RTO 时间过长，那么当 TCP 片段已经实际丢失的情况下，发送方不能及时重新发送，会造成网络资源的闲置。所以，RTO 必须符合当前网络的使用状况。网络状况越好，RTO 应该越短；网络状况越差，RTO 应该越长。

SRTT（采样往返时间）

TCP 协议通过统计 RTT，来决定合理的 RTO。发送方可以测量每一次 TCP 传输的 RTT (从发送出数据片段开始，到接收到ACK片段为止)，这样的每次测量得到的往返时间，叫做采样RTT(srtt, sampling round trip time)。建立连接之后，每次的 SRTT 作为采样样本，计算平均值(mean)和标准差(standard deviation)，并让 RTO 等于 SRTT 平均值加上四倍的 SRTT 标准差。
RTO = mean + 4 std(该算法有多个变种，根据平台不同有所变化)
平均值反映了平均意义上的 RTT，平均往返时间越大，RTO 越大。另一方面，标准差越大也会影响 RTO。标准差代表了 RTT 样本的离散程度。如果 RTT 上下剧烈浮动，标准差比较大。RTT 浮动大，说明当前网络状况相对不稳定。因此要设置更长的 RTO，以应对不稳定的网络状况。

1.[TCP Dup ACK xxx#y]（重复应答）

[TCP Dup ACK xxx#y] 表示第y次重新请求第xxx包，
xxx表示第几个包（不是Seq），
y表示第几次请求。
丢包或者乱序的情况下，会出现该标志。
下图中：第26548第0次 请求 seq=4468792 的包，重复申请了4次；

2.[TCP Fast Retransmission]（快速重传）

一般快速重传算法在收到三次冗余的 ACK，即三次[TCP Dup ACK xxx#y]后，发送端进行快速重传。
为什么是三次呢？因为两次 duplicated ACK 肯定是乱序造成的，丢包肯定会造成三次 duplicated ACK。
如上图重复应答：26548的包请求 4468792（即Ack），重复请求4次后，发送端快速重传。至于为什么是4次，可能因为 ACK 包也有丢失。

3.[TCP Retransmission]（超时重传）

如果一个包的丢了，又没有后续包可以在接收方触发[Dup ACK]，或者**[Dup ACK]也丢失**的情况下，TCP 会触发超时重传机制。

4.[TCP Out-Of-Order]（报文乱序）

[TCP Out-Of-Order]指的是 TCP 发送端传输过程中报文乱序了。
例子： 继续上面的包分析，因为208142包序号为Seq=148514，而前一个序号为Seq=149874，故有此错误标志。 Seq=148514实际是208139包的响应，因为网络拥塞的情况下，TCP包不能按顺序到达，所以出现[TCP Previous segment not captured] 和 [TCP Out-Of-Order]标志。

5.[TCP Previous segment not captured]（报文缺失）

未捕获 TCP 先前的段，意思就是出现报文的丢失，报文没有捕捉到。
在 TCP 发送端传输过程中，该 Seq 前的报文缺失了。一般在网络拥塞的情况下，造成 TCP 报文乱序、丢包时，会出现该标志。需要注意的是，[TCP Previous segment not captured] 解析文字是 wireshark 添加的标记，并非 TCP 报文内容。
TCP 连接建立后，针对同一台主机的发包情况进行叙述。正常情况下，后一个package的seq等于前一个package的seq+len。而在实际传输过程中经常会产生数据丢失的问题，这种情况下，后一个Package的seq会大于前一个package的seq+len，实际的网络包的显示效果就是”TCP Previous segment not captured”。
重点：later package’s seq > previous package’s seq + data len

6.[TCP Spurious Retransmission]

TCP 虚假重传
发送端认为发送的 package 已经丢失了，所以重传了，尽管此时接收端已经发送了对这些包的确认。
指实际上并没有超时，但看起来超时了，导致虚假超时重传的原因有很多种：
（1）对于部分移动网络，当网络发生切换时会导致网络延时突增
（2）当网络的可用带宽突然变小时，网络rtt会出现突增的情况，这会导致虚假超时重传
（3）网络丢包（原始和重传的包都有可能丢包）会导致虚假重传超时。
实例参考：https://blog.csdn.net/weixin_41585557/article/details/103914469

7.[TCP segment of a reassembled PDU]

[TCP segment of a reassembled PDU]，字面意思是要重组的协议数据单元（PDU：Protocol Data Unit）的 TCP 段。比如由多个数据包组成的 HTTP 协议的应答包，如下：
这里的分段是指：上层协议 HTTP 的应答由多个分段组成，每个分段都是 TCP 协议的。TCP 本身没有分段的概念，它的 sequence number和 acknowledge number 是使 TCP 是基于流的协议的支撑，[TCP segment of a reassembled PDU] 的出现是因为 Wireshark 分析了其上层的 HTTP 协议而给出的摘要，如果配置 Wireshark 不支持 HTTP 协议解析，那么，同样的数据包就会变成下面的样子
每个 TCP 数据包都是这条流中的自身完整的一部分，TCP segment 应该表述为分段是 TCP 协议，而不应该是 TCP 分段。
实例参考：https://www.cnblogs.com/yinghao-liu/p/7532889.html

8.[TCP Keep-Alive]

9.[TCP Keep-Alive ACK]

以下是 windows 部分：

10.[TCP ZeroWindow]

作为接收方发出现的标志，表示接收缓冲区已经满了，此时发送方不能再发送数据，一般会做流控调整。接收窗口，也就是接收缓冲区win=xxx ，告诉对方接收窗口大小。
传输过程中，接收方TCP窗口满了，win=0，wireshark会打上[TCP ZeroWindow]标签。

11.[TCP window update]

接收方消耗缓冲数据后，更新TCP窗口， 可以看到从win=0逐渐变大，这时**wireshark会打上[TCP window update]**标签

12.[TCP window Full]

作为发送方的标识，当前发送包的大小已经超过了接收端窗口大小，wireshark会打上此标识，标识不能在发送。