TCP的稳定性：滑动窗口和流速控制是怎么回事？

TCP利用发送字节数和接收字节数，这个二元祖的唯一性保证顺序，那么如何在保证顺序的基础上，同时追求更高的吞吐量。

TCP 作为一个传输层协议，最核心的能力是传输，

传输需要保证可靠性，还需要控制流速，这两个核心能力均有滑动窗口提供。

请求和响应模型

TCP中每个发送请求都需要响应，如果一个请求没有收到响应，发送方就会认为这次发送出现了故障，会触发重发。

每一个请求收到响应之后在发送下一个请求，吞吐量会很低，会产生网络的空闲时间，说白了就是浪费宽带，意味着可以同时发送更多的请求，接收更多的响应。

TCP 请求/响应模型（吞吐量低）

一种改进的方式就是让发送方有请求发送出去，而不是等待响应。通过这样的处理方式，发送的数据连接在一起了，响应的数据也连接在一起。吞吐量就提升了。

但是如果可以同时发送的数据真的非常多呢？比如成千个TCP段都需要发送，这个时候宽带可能不足，如下图，很多个数据封包都需要发送，该如何处理呢？

排队

这种情况下我们通常会考虑排队机制。

考虑这样一个模型，TCP实现一个队列，

1.新元素从队列的一端排队，作为一个未发送的数据封包。

2.开始发送数据封包，从队列的右侧离开，

3.这样就需要多个队列，我们将未发送的数据从队列中取出，加入发送中的队列，

4.然后将发送中的数据，收到ACK的部分取出，放入已接收的队列，而发送中的封包，

何时收到ACK是一件不确定的事情，这样使用队列似乎有一定的问题。

滑动窗口 算法

数组，少量的指针

如图所示

不同类型封包的顺序

假设我们最多同时发送5个封包，也就是窗口的大小 = 5，窗口中被同时发送出去，然后等待ACK。如果一个封包ACK到达，我们标记位绿色。

这时候滑动窗口可以向右滑动，如图所示

重传

发送过程中，部分数据没能收到ACK会怎么样呢？重传

如果发生下图这样的情况，段4迟迟没有收到ACK

滑动窗口右移一个位置

在这个过程中，

快速重传

如果接收方想丢弃某一个段，可以选择不发ACK。发送端超时后，会重发这个TCP段。

而有时候希望催促发送方尽快补发某个TCP段，可以使用快速重传能力。

例如段1，段2，段4到了，但是段3没到，接收方可以发送多次段3的ACK，如果发送方收到多个段3的ACK，就会重发段3，这个机制快速重传。

窗口大小的单位？

窗口大小是TCP段的数量。

在实际操作中，每个TCP段的大小不同，限制数量会让接收方的缓冲区不好操作，因此实际操作窗口大小单位是字节数。

流速控制

发送，接收窗口的大小可以用来控制TCP协议的流速。窗口越大，如果数据发生错误，损失越大，因为需要重传越多的数据。

总结

为了提高传输速率，TCP协议选择将多个段同时发送，为了让这些段不至于被接收方拒绝服务，在发送前，双方要协商好发送的速率。但是我们不可能完全确定网速，所以协商的方式，就变成确定窗口大小。

滑动窗口的实现只需要数组和少量的指针即可，是一个非常高效的算法

滑动窗口和流速控制是怎么回事？

滑动窗口是TCP协议控制可靠性的核心，

发送方将数据拆包，变成多个分组，然后将数据放入一个拥有滑动窗口的数组，依次发出，仍然遵循先入先出的原则，但是窗口的分组是一次性发送，窗口中序号最小的分组如果收到ACK，窗口会发生滑动如果最小序号分组长时间没有收到ACK，就会触发整个窗口的数据重新发送。

在多次传输中，网络的平均延迟往往是相对国定的，这样TCP协议可以通过协商窗口大小控制流速。