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，算短了（特殊情况）
该算法的最大特点：忽略重传，不把重传作为采样
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 缓冲空间
其实类似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）发送方滑动窗口示意图：
#1 已收到ACK确认的数据
#2 已发送到未收到ACK确认的数据
#3 在窗口中未发出的（接收方还有空间）
#4 窗口以外的数据（接收方没有空间）
其中#2 + #3的黑框就是滑动窗口
（2）发送方滑动后的滑动窗口示意图：
红色是已经新收到ACK的数据
绿色是新加入滑动窗口的数据
（3）接收端控制发送端的图示：
（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时，就会进入“拥塞避免算法”
3.3 阻塞避免算法
一般来说ssthresh的值是65535，单位是字节，当cwnd达到这个值时后
算法流程：
收到一个ACK时，cwnd = cwnd + 1/cwnd
每过一个RTT时，cwnd = cwnd + 1
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。
支付宝扫一扫
微信扫一扫
.png)
.png)
