TCP 是通过序列号、确认应答、重发控制、连接管理（三次握手、四次挥手）以及滑动窗口、流量控制、拥塞控制等机制实现可靠传输的

一、重传机制

????????TCP实现可靠传输的基础，是通过序列号与确认应答。

????????当发送端的数据到达接受主机时，接收端主机会返回一个确认应答消息，表示已经收到消息。

?????重传机制是为了解决TCP数据包丢失的情况，具有2种重传机制和2种应答机制：

1. 超时重传：
2. 快速重传：
3. SACK（Selective Acknowledgment，选择性确认）：
4. D-SACK（Duplicated ）：

1.1 超时重传：

????????重传机制的一个方式，以时间为驱动就是在发送数据时设定一个定时器，当超过指定的时

间RTO后，没有收到对方的ACK确认报文，就会重发该数据，也就是超时重传。

????????以下两种情况会发生超时重传：

• ?数据包（data）丢失
• ?确认应答（ACK）丢失

????????那么，首先解决 超时时间 应当怎么设置？

• RTT（Round-Trip Time，往返时延）
• RTO（Retransmission Timeout，超时重传时间）

• RTO较大：丢了老半天才重发，没有效率，性能差
• RTO较小：可能没有丢就重发，于是重发的快，增加网络拥塞，导致更多的超时，导致更多的重发，浪费资源

综上：超时重传时间RTO应当略大于报文往返时间RTT

????????如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。

也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。

????????它存在的问题是：超时重传的周期可能相对较长，也就引出了快速重传机制。

1.2 快速重传

????????TCP还有快速重传（Fast Retransmit）机制，不以时间为驱动，而是以数据驱动重传：当收

到三个相同的ACK报文时，会在定时器过期之前重传丢失的报文段。

（短时间内，比超时重传快，但是堵塞时间长了，则是快速重传更快，因为前者策略是：下一次超时时间间隔设置为先前值的两倍）

????????快速重传只解决了超时时间的问题，但是仍然面临另一个问题：重传的时候，是重传之前

的一个，还是所有的数据包？（说明这是双刃剑）

比如是重传Seq2，还是Seq2，3，4，5呢？因为发送端并不清楚这连续的三个Ack2是谁传回来的

????????为了解决不知道该重传哪些报文，就有了SACK方法。

1.3 SACK方法

在TCP头部【选项】中加一个SACK的东西，它可以将缓存的地图 应答 给发送方，这样发送方就知道哪些数据受到了，哪些没收到，知道了这些信息就可以只重传丢失的数据。

????????如果要支持?SACK，必须双方都要支持。在 Linux 下，可以通过?net.ipv4.tcp_sack?参数打开这个功能（Linux 2.4 后默认打开）。

1.4 Duplicate SACK

????????D-SACK，主要使用了SACK来告诉【发送方】有哪些数据被重复接受了。

????????原因1：ACK丢包：（基于超时重发）

????????原因2：网络延时（基于快速重发）：

? ? ? ?可见，D-SACK?有这么几个好处：

• 可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;
• 可以知道是不是「发送方」的数据包被网络延迟了;
• 可以知道网络中是不是把「发送方」的数据包给复制了;

????????在 Linux 下可以通过?net.ipv4.tcp_dsack?参数开启/关闭这个功能（Linux 2.4 后默认打开）。

二、滑动窗口

2.1 窗口的引入

????????TCP每发送一个数据，都要进行一次确认应答，上一个数据包受到了应答信号，再发送下

一个。这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。

????????因此，TCP引入窗口的概念，不会被降低网络通信的效率。有了窗口，就可以指定窗口的

大小，窗口大小是指无需等待确认应答，因而可以据需发送数据的最大值。

????????窗口实际上就是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必

须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

2.2 窗口大小由接收方决定

????????TCP头里有一个字段叫Window，也就是窗口大小。

????????这个字段是接收端告诉发送端自己还有多少缓冲区可以接受数据。于是发送端就可以根据

这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

????????所以，通常窗口的大小是由接收方决定的。

发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

2.3?发送的滑动窗口

????????在下图，当发送方把数据「全部」都一下发送出去后，可用窗口的大小就为 0 了，表明可

用窗口耗尽，在没收到 ACK 确认之前是无法继续发送数据了。

2.4 接收方的滑动窗口

2.5? 接收窗口的大小是约等于发送窗口

当接收方有空闲窗口的时候，会发送windows字段告诉发送方，但因为时延，发送方不知道，故并没有发送数据。那么理想情况下，是可以发送的，也就是发送窗口可以略大于接受窗口，这样虽然没接受到windows信号，仍然发送一点儿数据。

三、流量控制：

????????TCP通过让接收方指明希望从发送方接受的数据大小（窗口大小）来进行流量控制。

3.1? 流量控制机制（基于窗口）

????????如果发送方无脑发送数据，会导致重发机制，导致网络流量的无端浪费。为了解决这种现

象，TCP提供了流量控制机制：

????????【发送方】根据【接收方】的实际接受能力控制发送的数据量，这就是流量控制。

3.2? 操作系统缓冲区与滑动窗口的关系

????????实际上，发送窗口和接受窗口中所存放的字节数，都是放在操作系统内存缓冲区中的，而

操作系统的缓冲区会被操作系统调整。

????????当应用进程没办法及时读取缓冲区的内容时，也会对我们的缓冲区造成影响。

3.3? 操作系统的缓冲区如何影响发送窗口和接收窗口呢？

????????情况1：

????????服务端接收窗口初始值为200，服务端收到 140 字节数据，但是服务端非常繁忙，应用进程只读取了 40 个字节，还有 100 字节占用着缓冲区，于是接收窗口收缩到了 100 （200 - 100）。

????????情况2：

? ? ? ?当接收方系统资源非常紧张时，操作系统可能直接减少了接受缓冲区大小，这是应用程序又无法及时读取缓存数据，故收缩窗口，（导致发送数据会超过接收窗口大小），那么更严重的情况就发生了，会出现数据丢失现象。

????????

????????所以，如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象。

????????为了防止这种情况发生，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间在减少缓存，这样就可以避免了丢包情况。

3.4? 窗口关闭

????????情况1：死锁

????????TCP通过让接收方指明希望从发送方接受的数据大小（窗口大小）来进行流量控制。

????????如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。

????????（如果接收方向发送方发送的窗口非0的ACK报文在网络中丢失了，会造成死锁）

????????这会导致发送方一直等待接收方的非 0 窗口通知，接收方也一直等待发送方的数据，如不不采取措施，这种相互等待的过程，会造成了死锁的现象。

????????情况2：定时发送窗口探测报文

????????只要TCP一方受到了对方的零窗口通知，就启动持续计时器。计时器超时引起窗口探测报文，对方ACK信号会给出现在的接收窗口大小。（一般设置探测3次，每次30—60s，超次数则RST中断连接）

3.6? 糊涂窗口综合征（小数据量，大发送次数）

????????如果接收方腾出几个字节并告诉发送方现在有几个字节的窗口，而发送方会义无反顾地发送这几个字节，这就是糊涂窗口综合症（数据量非常小，但是发送次数非常多，极其耗费网络通信资源）

????????两个策略解决：

????????策略1：接收方不通告小窗口

????????小于min(MSS, 缓存空间/2)，向发送方通告窗口为0

????????策略2：发送方不发送小数据

????????Nagle算法（属于延迟处理，是默认打开的，在交互性比较强的场景中，如游戏、在线聊天，则需要关闭Nagle算法），满足下面两个条件则发送数据：

• 窗口大小>=MSS，或者数据大小>=MSS
• 收到之前发送数据的ack回包（之前发送的也是大数据，说明此时接受窗口较大）

四、拥塞控制

4.1? 拥塞控制与流量控制区别

????????流量控制：避免【发送方】数据填满【接收方】的缓存，但不知道网络中发生了什么。

????????拥塞控制：避免【发送方】数据填满【整个网络】。

????????网络中出现拥塞时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时TCP就会重传数据，

????????但是一重传就会导致网络的负担更重，于是会导致更大的延时以及更多的丢包，从而进入恶性循环。

????????当TCP发现网络出现拥塞时，会自我牺牲，降低发送的数据量。

????????为了在发送方调节所要发送数据的量，定义了拥塞窗口的概念。

4.2? 拥塞窗口与发送窗口

????????拥塞窗口cwnd是发送方维护的一个状态变量，根据网络的拥塞程度动态变化的。

????????之前的发送窗口swnd和接受窗口rwnd是约等于的关系。现在发送窗口为：

????????swnd=min(cwnd, rwnd)，是拥塞窗口和接受窗口中的最小值。

????????规则：

• 只要网络中没有出现拥塞，cwnd增大；
• 反之，减少

????????发生了超时重传，就会认为网络出现了拥塞。

4.3??拥塞窗口的4个控制算法

• 慢启动
• 拥塞避免
• 拥塞发生
• 快速恢复

（1）慢启动算法：

• 规则：当发送方每收到一个 ACK，就拥塞窗口 cwnd 的大小就会加 1，基本上是指数增长的（与嵌入式差不多）

????????IF? ACK++? THEN? cwnd++

• 指数原因：当发送方每收到一个 ACK，就拥塞窗口 cwnd 的大小就会加 1，发送数据也会加1。即1->2->4->8->16
• cwnd达到了慢启动门限（ssthresh，slow start threshold），就会使用拥塞避免算法

?

（2）拥塞避免算法：

• 规则：当发送方每收到一个 ACK，就拥塞窗口 cwnd 的大小就会加 1/cwnd（线性增长）
• IF? ACK++? THEN? cwnd += 1/cwnd;

????????始终增长，网络会慢慢进入拥塞情况，出现丢包现象，这时候要进行重传（超时重传、快速重传）。

????????当触发了重传机制，也就进入了【拥塞发生算法】

（3）拥塞发生算法：

????????超时重传和快速重传的拥塞发生算法是不同的：

• 超时重传：此时拥塞算法很激进，容易造成网络卡顿，类似于急刹车

  • 慢启动门限（ssthresh）设置为：ssthresh? <---? cwnd/2（变为1半）
  • 拥塞窗口cwnd重置为1

  • 进入了慢启动阶段（不会进入快速恢复，因为进不去）

• 快速重传：TCP认为这种情况不严重，因为大部分没丢，只丢了小部分

  • 慢启动门限（ssthresh）设置为：ssthresh? <---? cwnd/2（变为1半）
  • 拥塞窗口cwnd：cwnd? <--- cwnd/2 （变为1半）

  • 立即进入快速恢复算法（cwnd立即被更新）

（4）快速恢复算法：

????????快速重传和快速恢复算法一般同时使用。快速恢复算法认为，TCP还能收到3个重复ACK，说明网络不是非常糟糕，不用像RTO超时（超时重传）那么强烈（快速恢复后，仍然呈线性增长）。

????????在进入快速恢复之前cwnd和ssthresh已经被更新：

• 慢启动门限（ssthresh）设置为：ssthresh? <---? cwnd/2（变为1半）
• 拥塞窗口cwnd：cwnd? <--- cwnd/2 （变为1半）

然后，进入快速恢复算法：

• 拥塞窗口cwnd = ssthresh + 3（3的意思是确认有3个数据包被接收到了）
• 重传丢失的包
• 如果再次收到重复的ACK，那么cwnd++（认为还能收到ACK，网路不算差）
• 如果收到新数据的ACK后，设置cwnd为ssthresh（超过门限，进入拥塞避免算法），接着进入拥塞避免算法（认为此时网络已经不堵塞了，很快的恢复）