理解 TCP（五）：可靠性交付的实现

更好阅读体验：《理解 TCP 和 UDP》— By Gitbook

TCP 是一种提供可靠性交付的协议。
也就是说，经过 TCP 链接传输的数据，无差错、不丢失、不重复、而且按序到达。
可是在网络中相连两端之间的介质，是复杂的，并不确保数据的可靠性交付，那么 TCP 是怎么样解决问题的？
这就须要了解 TCP 的几种技术：

1. 滑动窗口
2. 超时重传
3. 流量控制
4. 拥塞控制

下面来分别讲一下这几种技术的实现原理。

超时重传

重传时机

TCP 报文段在传输的过程当中，下面的状况都是有可能发生的：

1. 数据包中途丢失；
2. 数据包顺利到达，但对方发送的 ACK 报文中途丢失；
3. 数据包顺利到达，但对方异常未响应 ACK 或被对方丢弃；

当出现这些异常状况时，TCP 就会超时重传。
TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到了，但尚未收到确认，就重传这一报文段，这个就叫作「超时重传」。

重传算法

先认识两个概念

RTO ( Retransmission Time-Out ) 重传超时时间

指发送端发送数据后、重传数据前等待接收方收到该数据 ACK 报文的时间。
大白话就是，须要等待多长时间还没收到确认，就从新传一次。

RTO 的设置对于重传很是重要：

1. 设长了，重发就慢，没有效率，性能差；
2. 设短了，重发得就快，会增长网络拥塞，致使更多的超时，更多的超时致使更多的重发。

RTT ( Round Trip Time ) 链接往返时间

指发送端从发送 TCP 包开始到接收它的 ACK 报文之间所耗费的时间。
而在实际的网络传输中，RTT 的值每次都是随机的，没法事先预预知。
TCP 经过测量来得到链接当前 RTT 的一个估计值，并以该 RTT 估计值为基准来设置当前的 RTO。
这就引入了一类算法的称呼：自适应重传算法（Adaptive Restransmission Algorithm）
这类算法的关键就在于对当前 RTT 的准确估计，以便适时调整 RTO。

关于自适应重传算法，经历过屡次的迭代和修正。
从 1981 年的 RFC793 说起的经典算法，到 1987 年 Karn 提出的 Karn/Partridge 算法，再到后来的 1988 年的 Jacobson / Karels 算法。
最后的这个算法在被用在今天的 TCP 协议中（Linux的源代码在：tcp_rtt_estimator）。

自适应重传算法的发展读者有兴趣能够参考其余资料，在这里我拎一个如今在用的算法出来说讲，随意感觉一下。

Jacobson / Karels 算法

1988年，有人推出来了一个新的算法，这个算法叫 Jacobson / Karels Algorithm（参看RFC6298）。
其计算公式：

SRTT = SRTT + α ( RTT – SRTT ) —— 计算平滑 RTT

DevRTT = ( 1-β ) DevRTT + β ( | RTT - SRTT | ) ——计算平滑 RTT 和真实的差距（加权移动平均）

RTO= µ SRTT + ∂ DevRTT

其中：

• α、β、μ、∂ 是能够调整的参数，在 RFC6298 中给出了对应的参考值，而在Linux下，α = 0.125，β = 0.25， μ = 1，∂ = 4；

• SRTT 是 Smoothed RTT 的意思，是 RTT 的平滑计算值，即根据每次测量的 RTT 和旧的 RTT 进行运算，得出新的 RTT。SRTT 的值，会在每一次测量到 RTT 以后进行更新；

• DevRTT 是 Deviation RTT 的意思，根据每次测量的 RTT 和旧的 SRTT 值进行运算，得出新的 DevRTT；

由算法能够知道 RTO 的值会根据每次测量的 RTT 值变化而变化，基本要点是 TCP 监视每一个链接的性能，由每个 TCP 的链接状况推算出合适的 RTO 值，根据不一样的网络状况，自动修改 RTO 值，以适应负责的网络变化。

拥塞控制

滑动窗口 Sliding Window

滑动窗口协议比较复杂，也是 TCP 协议的精髓所在。

TCP 头里有一个字段叫 Window，叫 Advertised-Window，这个字段是接收端告诉发送端本身还有多少缓冲区能够接收数据。因而发送端就能够根据这个接收端的处理能力来发送数据，而不会致使接收端处理不过来。

滑动窗口分为「接收窗口」和「发送窗口」
由于 TCP 协议是全双工的，会话的双方均可以同时接收和发送，那么就须要各自维护一个「发送窗口」和「接收窗口」。

发送窗口

大小取决于对端通告的接受窗口。
只有收到对端对于本端发送窗口内字节的 ACK 确认，才会移动发送窗口的左边界。

下图是发送窗口的示意图：

tcps-send-wwindows.png

对于发送窗口，在缓存内的数据有四种状态：

• #1 已发送，并获得接收方 ACK 确认；
• #2 已发送，但还未收到接收方 ACK；
• #3 未发送，但接收方容许发送，接收方还有空间
• #4 未发送，且接收方不容许发送，接收方没有空间

若是下一刻，收到了接收方对于 32-36 字节序的数据包的 ACK 确认，那么发送方的窗口就会发生「滑动」。
而且发送下一个 46-51 字节序的数据包。

tcps-send-wslide.png

滑动窗口的概念，描述了 TCP 的数据是怎么发送，以及怎么接收的。
TCP 的滑动窗口是动态的，咱们能够想象成小学常见的一个数学题，一个水池，体积 V，每小时进水量 V1, 出水量 V2。
当水池满了就不容许再注入了，若是有个液压系统控制水池大小，那么就能够控制水的注入速率和量了。
应用程序能够根据自身的处理能力变化，经过 API 来控制本端 TCP 接收窗口的大小，来进行流量控制。

接收窗口

大小取决于应用、系统、硬件的限制。

下图是接收窗口的示意图（找不到图，惟有本身画了）：

tcps-receive-wwindows.png

相对于发送窗口，接受窗口在缓存内的数据只有三种状态：

• 已接收已确认；
• 未接收，准备接收；
• 未接收，并未准备接收；

下一刻接收到来自发送端的 32-36 数据包，而后回送 ACK 确认报，而且移动接收窗口。

tcps-receive-wslide.png

另外接收端相对于发送端还有不一样的一点，只有前面全部的段都确认的状况下才会移动左边界，
在前面还有字节未接收但收到后面字节的状况下，窗口不会移动，并不对后续字节确认，以此确保对端会对这些数据重传。
假如 32-36 字节不是一个报文段的，而是每一个字节一个报文段的话，那么就会分红了 5 个报文段。
在实际的网络环境中，不能确保是按序收到的，其中会有一些早达到，一些迟到达。

tcps-receive-disorder.png

如图中的 3四、35 字节序，先收到了，接收窗口也不会移动。
由于有可能 3二、33 字节序会出现丢包或者超时，这时就须要发送端重发报文段了。

参考

The TCP/IP Guide
TCP 的那些事儿（下）
《后台开发 核心技术与应用实践》
《计算机网络》