TCP协议探究(三):RTT、滑动窗口和阻塞处理

1 RTT算法

1.1 概述

上一节说了重传机制需要设置一个重传超时值(RTO,Retransmission TimeOut),RTO设长了,重发太慢;设短了,可能导致包没有丢,就重发了,可能导致雪崩效应(重发多,失败多,失败多,导致更多的重发…请参考: 暴风门事件)。

那么该值怎么设置?

由于一开始无法确定设置某个值,所以需要程序自动适应,动态地去设置
RTT,Round Trip Time,设置的参考值为数据报来回所需要的时间

1.2 经典算法

采样最近几次的RTT

SRTT计算(Smoothed RTT):α (加权移动平均)取值在0.8 到 0.9之间
$$
SRTT = ( α * SRTT ) + ((1- α) * RTT)
$$

计算RTO:UBOUND为最大RTT(上限值),LBOUND为最小RTT(下限值),β 值一般在1.3到2.0之间
$$
RTO = min [ UBOUND, max [ LBOUND, (β * SRTT) ] ]
$$

1.3 Karn / Partridge 算法(SRTT算法的优化)

经典算法的问题:

原始 + 重传 + ACK = 总时间作为RTO,算长了(特殊情况)
重传 + ACK = 总时间作为RTO,算短了(特殊情况)

img

该算法的最大特点:忽略重传,不把重传作为采样

1.4 Jacobson / Karels 算法

忽略重传的问题:

在某一时间,网络闪动,突然变慢了,产生了比较大的延时,这个延时导致要重传所有的包(RTO设置的比较小)
但是由于重传不会重新更新RTO,导致一直丢包,一直重试了。

SRTT算法以及优化都逃不出RTT有一个大的波动的话,很难被发现,所以需要综合考虑。

公式:

SRTT = SRTT + α (RTT – SRTT) —— 计算平滑RTT
DevRTT = (1-β)DevRTT + β(|RTT-SRTT|) ——计算平滑RTT和真实的差距(加权移动平均)
RTO= µ * SRTT + ∂ *DevRTT —— 神一样的公式
# 在Linux下,α = 0.125,β = 0.25, μ = 1,∂ = 4 —— nobody knows why, it just work.

2 滑动窗口

2.1 概述

第一节说过TCP可靠性的保证之一就是流量控制(Flow Control)
TCP需要知道现在网络的数据处理速度,才能更好防止丢包,而流量控制就是为了测量现在的网络数据处理速度的。
TCP报头有一个字段:窗口,该字段是接收端告知发送端自己的缓冲空间,防止发送端发送太快缓冲区溢出。

2.2 缓冲空间

img

其实类似java的NIO中的ByteBuffer
发送端

LastByteWritten:上层应用可写入的位置
LastByteSent:正在发送的位置
LastByteAcked:已经收到ACK的位置
LastByteAcked ~ LastByteSent区间:表示已经发送但是未收到ACK的数据
LastByteSent ~ LastByteWritten区间:表示未发送出去的数据

接收端

LastByteRead:TCP缓冲区中读到的位置
NextByteExpected:收到的连续包的最后一个位置
LastByteRcved:收到的包的最后一个位置
NextByteExpected ~ LastByteRcved区间:未到达的数据区间
LastByteRead ~ NextByteExpected区间:已收到的数据区间

接收端回复

ACK中会汇报自己的Window = MaxRcvBuffer – LastByteRcvd – 1(只剩下这么多的空间能装新的数据)
发送方会根据窗口来控制发送数据的大小,以保证接收方可以处理

2.3 滑动窗口

(1)发送方滑动窗口示意图:

img

#1 已收到ACK确认的数据
#2 已发送到未收到ACK确认的数据
#3 在窗口中未发出的(接收方还有空间)
#4 窗口以外的数据(接收方没有空间)
其中#2 + #3的黑框就是滑动窗口

(2)发送方滑动后的滑动窗口示意图:

img

红色是已经新收到ACK的数据
绿色是新加入滑动窗口的数据

(3)接收端控制发送端的图示:

img

(4)Zero Window(坚持定时器实现):

上图一个处理缓慢的Server将Client的TCP 滑动窗口给降到0.
降到0之后,发送端发送Zero Window Probe包(ZWP)给接收方,让接收方ACK它的Window尺寸,一般发送3次,每次30~60秒。
连续3次为0,有些TCP Client将发送RST把连接断开。

(5)Silly Window Syndrome(糊涂窗口综合症)

由于处理缓慢的Server把TCP接收方的滑动窗口不断降低,导致滑动窗口很少(如:4个字节),此时发送端仍然义无反顾的发送。

MSS默认为536,有效数据才4个字节,带宽利用率1%不到,造成了巨大的浪费。

窗口是为了控制传输过程中的速度。而MSS是为了控制TCP报文段大小

MTU = MSS + TCP头(20字节) +IP头(20字节)。

解决方案:

问题由Receiver引起,那么Receiver收到的数据导致window size(rwnd,receiver window)小于某个值,可以直接ack window size为0给Sender,这样就把window关闭了,也阻止Sender再发数据过来,等到Receiver处理了一些数据后window size大于等于MSS时,或者Receiver Buffer有一般为空(具体策略有很多),可以把window 打开让Sender发送数据过来。
问题由Sender引起,使用延时处理,禁止大量小包发送。(打开之后无法使用telnet或者SSH这种交互性比较强的程序

等到Window Size >= MSS 或者 Data Size >= MSS
收到之前发送数据的ACK包,它才会发送数据,否者继续积攒数据

3 阻塞处理

3.1 概述

前面说过网络波动时,TCP报文超时,引起重传,但是重传导致网络负担更大,可能导致网络更加繁忙。
所以TCP不会这么自私,它在发现阻塞时,会主动让路(并不是直接停止发送TCP报文)。
阻塞控制算法

慢启动
阻塞避免
阻塞发生时快速重传(上一节说过)
快速恢复

3.2 慢启动算法

程序刚刚加入网络时,一点一点提升速度。
算法流程

连接建好的开始先初始化cwnd = 1(窗口),表明可以传一个MSS大小的数据
每当收到一个ACK,cwnd++,线性上升
每当过了一个RTT,cwnd = cwnd*2, 呈指数上升。
ssthresh(slow start threshold),是一个上限,当cwnd >= ssthresh时,就会进入“拥塞避免算法”

img

3.3 阻塞避免算法

一般来说ssthresh的值是65535,单位是字节,当cwnd达到这个值时后
算法流程

收到一个ACK时,cwnd = cwnd + 1/cwnd
每过一个RTT时,cwnd = cwnd + 1

img

3.4 阻塞状态时的算法

当丢包的时候,有两种情况

等到RTO超时,重传数据包,TCP认为该情况太糟糕了

sshthreash = swnd / 2
cwnd 重置为1
进入慢启动算法

快速重传算法,即收到3个重复的ACK就开始重传,无需等待RTO超时

TCP Tahoe(代表版本)的实现和RTO超时一样。
TCP Reno的实现:

cwnd = cwnd / 2
sshthresh = cwnd
进入快速恢复算法——Fast Recovery

3.5 快速恢复算法(TCP Reno)

这里就讲解TCP Reno版本的快速恢复算法,想了解更多请参考:TCP 的那些事儿(下)

算法流程

cwnd = sshthresh + 3 * MSS(3的意思是确认有3个数据包被收到了)
重传Duplicated ACKs指定的数据包
如果再收到 Duplicated ACKs,那么cwnd = cwnd +1
如果收到了新的Ack,那么,cwnd = sshthresh ,然后就进入了拥塞避免的算法了。

缺点:由于3个重复的ACKs,并不代表只丢了一个数据包;如果丢了多个数据包,将导致RTO。

img

参考:https://coolshell.cn/articles/11609.html

Published by

风君子

独自遨游何稽首 揭天掀地慰生平

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注