TCP滑动窗口

TCP Sliding Window Acknowledgment System For Data Transport, Reliability and Flow Control（用于数据传输，提供可靠性和流量控制的TCP滑动窗口）**

1.传输控制协议与简单传输协议（如UDP）的不同之处在于它在设备之间发送数据的方式的质量。 TCP不会直接将数据放在消息中并说“好了，你可以发送了”，而是会仔细跟踪它发送的数据及其发生的情况。需要对数据进行管理以促进协议的两个关键要求：
(1)可靠性：确保发送的数据实际到达目的地，如果没有，则检测到并重新发送数据。
(2)数据流控制：管理数据的发送速率，使其不会淹没接收数据的设备。
为了完成这些任务，协议的整个操作都围绕称为滑动窗口确认系统的东西。可以毫不夸张地说，理解滑动窗口的工作方式对于理解TCP中的其他所有内容至关重要。

概述
1.不可靠协议的问题：缺乏反馈
像IP这样简单的“发送和遗忘”协议是不可靠的，主要因为其中发送器不接收来自接收者的反馈。数据报被发送，它可能会或可能不会到达那里，但是发送器永远不会有任何知道的方式，因为没有反馈机制存在。如下图所示：

2. 使用PAR（带有重传的确认）提供基本可靠性

在IP之类的不可靠协议上运行的协议的基本可靠性可以通过关闭循环来实现，以便接收者向发送者提供反馈。使用简单的确认系统最容易做到这一点。设备A向设备B发送一条数据。接收数据的设备B发回一个确认消息，说“设备A，我收到了你的消息”。然后，设备A知道其传输成功。
当然，由于IP不可靠，因此该消息实际上可能永远无法到达目的地。设备A将等待确认，并且永远不会收到它。在任何一种情况下，我们都不希望设备A永远等待不会到达的确认。
为防止这种情况发生，设备A在首次向设备B发送消息时启动计时器，这允许有足够的时间让消息到达B并返回确认，加上一些合理的时间以允许可能的延迟。如果计时器在收到确认之前到期，则A假定存在问题并重新发送其原始消息。

3.通过消息识别和发送限制提高PAR的效用
PAR是一种广泛用于网络和通信的技术，用于交换相对少量数据或不经常交换数据的协议。基本方法是功能性的，但由于两个原因，它不适合像TCP这样的协议。首先是效率低下。设备A发送消息，然后等待确认。设备A在听到其原始消息被接收之前不能向设备B发送另一条消息，这非常浪费并且会使协议极其缓慢。

我们可以对该系统进行的第一项改进是为发送的消息和确认提供一些识别方法。例如，我们可以在消息头中放置一个消息ID字段。发送消息的设备将唯一地识别它，并且接收者将在确认中使用该标识符。例如，设备A可能会在消息ID为＃1的消息中发送一段数据。设备B将接收消息，然后将其自己的消息发送回设备A，说“设备A，我收到了您的消息＃1”。该系统的优点是设备A可以一次发送多个消息。它必须跟踪发送的每一个，以及它是否被确认。每个还需要一个单独的计时器，但这不是一个大问题。

当然，我们还需要从设备B的角度考虑这种交换。之前，它只需要一次处理来自设备A的一条消息。现在它可能有几个同时出现。如果它已经忙于其他设备（或十个）的传输怎么办？我们需要一些机制让设备B说“我只愿意一次处理来自你的一定数量的消息”。我们可以通过使确认消息包含一个字段来指定允许一次传输到B的最大未确认消息数。

设备A将使用此发送限制字段来限制它向设备B发送消息的速率。设备B可以根据其当前负载和其他因素调整此字段，以便在与设备A的讨论中最大化性能。此增强型系统将因此提供可靠性，效率和基本数据流控制。

TCP滑动窗口
1 TCP的面向流的滑动窗口确认系统
实际上，TCP滑动窗口系统在概念上非常类似于这种方法，这就是为什么它对我们来说很重要。但是，它需要一些调整。主要原因与TCP处理数据的方式有关：与前一主题中讨论的消息方向相比，流方向问题。我们概述的技术涉及明确的确认和消息的重传。因此，它可以很好地用于在相当不频繁的基础上交换相当大的消息的协议。

另一方面，TCP将各个字节的数据作为流处理。一次传输一个字节并一次确认每个字节显然是荒谬的。它需要太多的工作，即使有重叠的传输（在发送下一条数据之前不等待确认），结果也会非常缓慢，这就是TCP不单独发送字节的原因。
它将它们分成段。段中的所有字节一起发送并一起接收，因此一起确认。 TCP使用我们上面描述的方法(PAR)的变形，其中使用我们在前一主题中讨论的序列号来完成发送和确认的数据的识别。我们使用段中数据的最后一个字节的序列号来确认数据，而不是确认使用消息ID字段之类的内容。因此，我们在每种情况下处理一系列字节，该范围表示段中所有字节的序列号。

TCP传输流分类的概念划分
想象一下，设备A和设备B之间新建立的TCP连接。设备A有一个很长的字节流要传输，但设备B不能同时接受它们。因此，它限制设备A在段中一次发送特定数量的字节，直到已经确认已发送的段中的字节为止。然后允许设备A发送更多字节。每个设备都会跟踪哪些字节已发送，哪些未发送，哪些已被确认。

我们可以在概念上将发送TCP在其缓冲区中具有的字节划分为四个类别。
(1) 发送和确认字节数
(2) 已发送但尚未确认字节数
(3) 未发送但是接收方已经准备好接收的字节数：这些是尚未发送的字节，但是收件人可以根据其最近与发件人的通信，其愿意立即处理多少字节。发件人将尝试立即发送这些内容
(4) 未发送且接收方未准备好接收的字节数

2 序列号分配和同步
发送方和接收方必须就对要分配给流中字节的序列号达成一致。这称为同步，在建立TCP连接时完成。为简单起见，我们假设第一个字节是使用序列号1发送的（通常情况并非如此）。因此，在我们的示例中，四个类别的字节范围是：
已发送和已确认的字节数：字节1到31。
发送的字节但尚未确认：字节32到45。
尚未发送收件人准备好的字节：字节46到51。
尚未发送收件人未准备好的字节：字节52到95。

发送窗口和可用窗口

整个过程操作的关键是接收方允许发送器一次未被确认的字节数。这称为发送窗口，或者通常称为窗口。该窗口决定了允许发送方传输的字节数，并且等于类别＃2和类别＃3中的字节数之和。因此，通过将窗口添加到流中第一个未确认字节的字节数来确定最后两个类别（接收者准备好的字节和未准备好的字节）之间的分界线。在上面的示例中，第一个未确认的字节是＃32。总窗口大小为20。

3. 在可用窗口中发送字节后对TCP类别和窗口大小的更改
现在，让我们假设在上面的例子中，没有什么能阻止发送者立即发送类别＃3（可用窗口）中的6个字节。 当它这样做时，6个字节将从类别＃3转移到类别＃2。 字节范围现在如下图：
已发送和已确认的字节数：字节1到31。
发送的字节但尚未确认：字节32到51。
尚未发送但收件人准备好字节：无。
尚未发送且收件人未准备好的字节：字节52到95

4 处理确认并滑动发送窗口
一段时间之后，目标设备向发送方发回消息以提供确认。它不会特别列出已经确认的字节，因为正如我们之前所说的那样，这样做效率很低。相反，它将确认一系列字节，这些字节表示自先前已确认之后接收的最长连续字节序列。

例如，假设已经发送但在示例开始时尚未确认的字节（32到45）是在四个不同的段中传输的。这些段分别携带字节32至34,35至36,37至41和42至45。第一，第二和第四部分到达，但第三部分没有。接收器将仅返回字节32到36（32-34和35-36）的确认。它将保持字节42到45但不确认它们，因为这意味着接收到尚未显示的字节37到41。这是必要的，因为TCP是一个累积确认系统，它只能使用一个数字来确认数据，即成功接收的流中最后一个连续字节的数量。我们还要说目标保持窗口大小相同，为20个字节。

当发送设备收到此确认时，它将能够将一些字节从类别＃2传输到类别＃1，因为它们现在已被确认。由于已确认了五个字节，并且窗口大小没有改变，因此允许发送方再发送五个字节。 实际上，窗口在时间轴中向右移动或滑动。 同时，五个字节从类别＃2移动到类别＃1，五个字节从类别＃4移动到类别＃3，为后续传输创建新的可用窗口。 因此，收到确认后，这些组将如下所示：

已发送和已确认的字节数：字节1到36。
发送的字节但尚未确认：字节37到51。
尚未发送但收件人准备好接收的字节：字节52到56。
尚未发送且收件人未准备好接收的字节：字节57到95。

每次收到确认时都会发生此过程，导致窗口在要传输的整个流上滑动。为简单起见，上面的示例使窗口大小保持不变，但实际上可以调整它以允许接收者控制数据发送的速率，从而实现流量控制和拥塞处理。

那在上面的例子中42-45的部分怎么办？
好吧，直到段＃3（包含字节37到41）出现，接收设备才会发送对这些字节的确认，也不会发送其后显示的任何其他字节。