可靠性交付的实现
TCP 是一种提供可靠性交付的协议。
也就是说，通过 TCP 连接传输的数据，无差错、不丢失、不重复、并且按序到达。
但是在网络中相连两端之间的介质，是复杂的，并不确保数据的可靠性交付，那么 TCP 是怎么样解决问题的？
这就需要了解 TCP 的几种技术：
- 滑动窗口
- 超时重传
- 流量控制
- 拥塞控制
下面来分别讲一下这几种技术的实现原理。
超时重传
重传时机
TCP 报文段在传输的过程中，下面的情况都是有可能发生的：
- 数据包中途丢失；
- 数据包顺利到达，但对方发送的 ACK 报文中途丢失；
- 数据包顺利到达，但对方异常未响应 ACK 或被对方丢弃；
当出现这些异常情况时，TCP 就会超时重传。
TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到了，但还没有收到确认，就重传这一报文段，这个就叫做「超时重传」。
重传算法
先认识两个概念
RTO ( Retransmission Time-Out ) 重传超时时间
指发送端发送数据后、重传数据前等待接收方收到该数据 ACK 报文的时间。
大白话就是，需要等待多长时间还没收到确认，就重新传一次。
RTO 的设置对于重传非常重要：
- 设长了，重发就慢，没有效率，性能差；
- 设短了，重发得就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
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 值，以适应负责的网络变化。
拥塞控制
慢启动（Slow Start） 与 拥塞避免（Congestion Avoidance）
- [ ] TODO
快速重传（Fast Retransmit） 与 快速恢复（Fast Recovery）
- [ ] TODO
滑动窗口 Sliding Window
滑动窗口协议比较复杂，也是 TCP 协议的精髓所在。
TCP 头里有一个字段叫 Window，叫 Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
滑动窗口分为「接收窗口」和「发送窗口」
因为 TCP 协议是全双工的，会话的双方都可以同时接收和发送，那么就需要各自维护一个「发送窗口」和「接收窗口」。
发送窗口
大小取决于对端通告的接受窗口。
只有收到对端对于本端发送窗口内字节的 ACK 确认，才会移动发送窗口的左边界。
下图是发送窗口的示意图：
对于发送窗口，在缓存内的数据有四种状态：
- #1 已发送，并得到接收方 ACK 确认；
- #2 已发送，但还未收到接收方 ACK；
- #3 未发送，但接收方允许发送，接收方还有空间
- #4 未发送，且接收方不允许发送，接收方没有空间
如果下一刻，收到了接收方对于 32-36 字节序的数据包的 ACK 确认，那么发送方的窗口就会发生「滑动」。
并且发送下一个 46-51 字节序的数据包。
滑动窗口的概念，描述了 TCP 的数据是怎么发送，以及怎么接收的。
TCP 的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积 V，每小时进水量 V1, 出水量 V2。
当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量了。
应用程序可以根据自身的处理能力变化，通过 API 来控制本端 TCP 接收窗口的大小，来进行流量控制。
接收窗口
大小取决于应用、系统、硬件的限制。
下图是接收窗口的示意图（找不到图，唯有自己画了）：
相对于发送窗口，接受窗口在缓存内的数据只有三种状态：
- 已接收已确认；
- 未接收，准备接收；
- 未接收，并未准备接收；
下一刻接收到来自发送端的 32-36 数据包，然后回送 ACK 确认报，并且移动接收窗口。
另外接收端相对于发送端还有不同的一点，只有前面所有的段都确认的情况下才会移动左边界，
在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认，以此确保对端会对这些数据重传。
假如 32-36 字节不是一个报文段的，而是每个字节一个报文段的话，那么就会分成了 5 个报文段。
在实际的网络环境中，不能确保是按序收到的，其中会有一些早达到，一些迟到达。
如图中的 34、35 字节序，先收到了，接收窗口也不会移动。
因为有可能 32、33 字节序会出现丢包或者超时，这时就需要发送端重发报文段了。