文章目录
Pre
Internet - TCP 的封包格式：TCP 为什么要粘包和拆包？ 中提到了 TCP 利用发送字节数和接收字节数，这个二元组的唯一性保证顺序。
那接着来看下保证顺序的具体算法以及TCP是如何实现的吧。 ——TCP 的滑动窗口算法。
TCP 作为一个传输层协议，最核心的能力是传输。传输需要保证可靠性，还需要控制流速，这两个核心能力均由滑动窗口提供。
而滑动窗口中解决的问题，我们在今后的工作中可以长期使用的，比如设计一个分布式的 RPC 框架、实现一个消息队列或者分布式的文件系统等。
请求/响应模型
TCP 中每个发送的请求都需要响应。如果一个请求没有收到响应，发送方就会认为这次发送出现了故障，会触发重发。
大体的模型，和下图很像。但是如果完全和下图一样，每一个请求收到响应之后，再发送下一个请求，吞吐量会很低。因为这样的设计，会产生网络的空闲时间，说白了，就是浪费带宽。带宽没有用满，意味着可以同时发送更多的请求，接收更多的响应。
一种改进的方式，就是让发送方有请求就发送出去，而不是等待响应。通过这样的处理方式，发送的数据连在了一起，响应的数据也连在了一起，吞吐量就提升了。
但是如果可以同时发送的数据真的非常多呢？比如成百上千个 TCP 段都需要发送，这个时候带宽可能会不足。像下图这样，很多个数据封包都需要发送，该如何处理呢？
排队（Queuing）机制 ？？？
在这种情况下，通常我们会考虑排队（Queuing）机制。
考虑这样一个模型，如上图所示，在 TCP 层实现一个队列。
新元素从队列的一端（左侧）排队，作为一个未发送的数据封包。开始发送的数据封包，从队列的右侧离开。
思考一下，这个模型有什么问题吗？
这样做就需要多个队列，我们要将未发送的数据从队列中取出，加入发送中的队列。然后再将发送中的数据，收到 ACK 的部分取出，放入已接收的队列。而发送中的封包，何时收到 ACK 是一件不确定的事情，这样使用队列似乎也有一定的问题。
滑动窗口（Sliding Window）
在上面的模型当中，我们之所以觉得算法不好设计，是因为用错了数据结构。有个说法叫作如果程序写复杂了，那就是写错了。这里其实应该用一种叫作滑动窗口的数据结构去实现。
如上图所示：
-
深绿色代表已经收到 ACK 的段
-
浅绿色代表发送了，但是没有收到 ACK 的段
-
白色代表没有发送的段
-
紫色代表暂时不能发送的段
下面我们重新设计一下不同类型封包的顺序，将已发送的数据放到最左边，发送中的数据放到中间，未发送的数据放到右边。假设我们最多同时发送 5 个封包，也就是窗口大小 = 5。窗口中的数据被同时发送出去，然后等待 ACK。如果一个封包 ACK 到达，我们就将它标记为已接收（深绿色）。
如下图所示，有两个封包的 ACK 到达，因此标记为绿色。
这个时候滑动窗口可以向右滑动，如下图所示：
重传
如果发送过程中，部分数据没能收到 ACK 会怎样呢？这就可能发生重传。
如果发生下图这样的情况，段 4 迟迟没有收到 ACK。
这个时候滑动窗口只能右移一个位置，如下图所示：
在这个过程中，如果后来段 4 重传成功（接收到 ACK），那么窗口就会继续右移。如果段 4 发送失败，还是没能收到 ACK，那么接收方也会抛弃段 5、段 6、段 7。这样从段 4 开始之后的数据都需要重发。
快速重传
在 TCP 协议中，如果接收方想丢弃某个段，可以选择不发 ACK。发送端超时后，会重发这个 TCP 段。而有时候，接收方希望催促发送方尽快补发某个 TCP 段，这个时候可以使用快速重传能力。
例如段 1、段 2、段 4 到了，但是段 3 没有到。 接收方可以发送多次段 3 的 ACK。如果发送方收到多个段 3 的 ACK，就会重发段 3。这个机制称为快速重传。这和超时重发不同，是一种催促的机制。
为了不让发送方误以为段 3 已经收到了，在快速重传的情况下，接收方即便收到发来的段 4，依然会发段 3 的 ACK（不发段 4 的 ACK），直到发送方把段 3 重传。
窗口大小的单位是 — 字节数
思考另一个问题，窗口大小的单位是多少呢？在上面所有的图片中，窗口大小是 TCP 段的数量。实际操作中，每个 TCP 段的大小不同，限制数量会让接收方的缓冲区不好操作，因此实际操作中窗口大小单位是字节数。
流速控制
发送、接收窗口的大小可以用来控制 TCP 协议的流速。窗口越大，同时可以发送、接收的数据就越多，支持的吞吐量也就越大。当然，窗口越大，如果数据发生错误，损失也就越大，因为需要重传越多的数据。
举个例子：我们用 RTT 表示 Round Trip Time，就是消息一去一回的时间。
假设 RTT = 1ms，带宽是 1mb/s。如果窗口大小为 1kb，那么 1ms 可以发送一个 1kb 的数据（含 TCP 头），1s 就可以发送 1mb 的数据，刚好可以将带宽用满。
如果 RTT 再慢一些，比如 RTT = 10ms，那么这样的设计就只能用完 1/10 的带宽。 当然你可以提高窗口大小提高吞吐量，但是实际的模型会比这个复杂，因为还存在重传、快速重传、丢包等因素。
而实际操作中，也不可以真的把带宽用完，所以最终我们会使用折中的方案，在延迟、丢包率、吞吐量中进行选择，毕竟鱼和熊掌不可兼得。
总结
为了提高传输速率，TCP 协议选择将多个段同时发送，为了让这些段不至于被接收方拒绝服务，在发送前，双方要协商好发送的速率。但是我们不可能完全确定网速，所以协商的方式，就变成确定窗口大小。
有了窗口，发送方利用滑动窗口算法发送消息；接收方构造缓冲区接收消息，并给发送方 ACK。滑动窗口的实现只需要数组和少量的指针即可，是一个非常高效的算法。像这种算法，简单又实用，比如求一个数组中最大的连续 k 项和，就可以使用滑动窗口算法。
QA
Question: 滑动窗口和流速控制是怎么回事？
滑动窗口是 TCP 协议控制可靠性的核心。
发送方将数据拆包，变成多个分组。然后将数据放入一个拥有滑动窗口的数组，依次发出，仍然遵循先入先出（FIFO）的顺序，但是窗口中的分组会一次性发送。窗口中序号最小的分组如果收到 ACK，窗口就会发生滑动；如果最小序号的分组长时间没有收到 ACK，就会触发整个窗口的数据重新发送。
另一方面，在多次传输中，网络的平均延迟往往是相对固定的，这样 TCP 协议可以通过双方协商窗口大小控制流速。补充下，上面我们说的分组和 TCP 段是一个意思。
既然发送方有窗口，那么接收方也需要有窗口吗
我们一起思考下，接收方收到发送方的每个数据分组（或者称为 TCP Segment），接收方肯定需要缓存。举例来说，如果发送方发送了：1, 2, 3, 4。 那么接收方可能收到的一种情况是：1，4，3。注意，没有收到 2 的原因可能是延迟、丢包等。这个时候，接收方有两种选择。
选择一：什么都不做（这样分组 2 的 ACK 就不会发送给发送方，发送方发现没有收到 2 的 ACK，过一段时间就有可能重发 2,3,4,5）。 当然具体设计还需要探讨，比如不重发整个分组，只重发已发送没有收到 ACK 的分组。
这种方法的缺陷是性能太差，重发了整个分组（或部分）。因此我们可以考虑另一种选择。
选择二：如果重发一个窗口，或部分窗口，问题就不会太大了。虽然增加了网络开销，但是毕竟有进步（1 进步了，不会再重发）。
性能方面最大的开销是等待超时的时间，就是发送方要等到超时时间才重发窗口，这样操作性能太差。因此，TCP 协议有一个快速重传的机制——接收方发现接收到了 1，但是没有接收到 2，那么马上发送 3 个分组 2 的 ACK 给到发送方，这样发送方收到多个 ACK，就知道接收方没有收到 2，于是马上重发 2。
无论是上面哪种方案，接收方也维护一个滑动窗口，是一个不错的选择。接收窗口的状态，可以和发送窗口的状态相互对应了。
还没有评论，来说两句吧...