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

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，就会触发整个窗口的数据重新发送。