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会打上此标识,标识不能在发送。