TCP(四)

1．介绍

TFTP使用了一种停等（stop-and-wait）协议。数据块的发送者需要等待当前块的确认后才能发送下一块。而TCP使用了一种叫做滑动窗口的协议（sliding window protocol）来进行流量控制。它允许发送者在停等一个确认前，发送多个包（package）。因为发送者在每次发送包后不必停等确认，所以这种协议可以加快数据的传输。

2．正常数据流

课本使用了sock程序在两个主机bsdi和svr4之间单向传输8192字节。具体做法P275，我们只看段交换的时间线（time line），见图一

前三段是建立连接的三次握手。

Svr4首先发送3个数据段（4-6），段7确认的顺序号是2049，而非3073，从中我们可以看出这是对段4、段5的确认。下面是对此现象的解释。当一个包（注：关于包和段我是看课本直译的，看其意思，应该所指相同）到达时，它首先被设备驱动的中断服务程序（interrupt service routine）所处理，然后放置到IP的输入队列。根据接收到的顺序，三个段4、5、6依次放入IP输入队列。IP将以同样的顺序交给TCP。当TCP处理段4时，连接被标识产生一个延迟确认。TCP处理下一个段（段5），因为此时TCP有两个未完成的段需要确认，因此产生一个确认号为2049的确认（段7），并将连接的延迟确认标志关闭。TCP处理下一输入段（段6），连接重新被标识延迟确认。在段9到来之前，恰巧延迟确认定时器触发（go off），于是确认3073产生。段8通告窗口大小是3072字节，暗示着在TCP接收缓冲区还有1024字节的数据未被应用程序读取。

段11-16显示了常用的“每隔一个段确认”的策略。段11、12、13到达并被放置到IP输入队列。当段11处理完成后，连接被标识延迟确认。等到段12处理完成后，产生对段11和段12的确认（即段14），连接的延迟确认标志也被关闭。段13再次引起连接被标识延迟确认，但在计时器触发之前，段15也被处理完毕，于是立即发送对它们两个的确认（段16）。

注意到段7，14和16都确认了两个收到的段。使用TCP的滑动窗口协议，接收者不必确认每个收到的包。在TCP中，这些确认是累积（cumulative）的：它们确认接收者已经正确接收了（确认顺序号-1）之前的所有字节。

我们使用tcpdump看到的是TCP的动态活动。我们所看到的线路上的包的顺序取决于许多因素，而其中的绝大多数都不是我们所能控制的：发送TCP实现机制，接收TCP的实现机制，由接收进程完成的数据读取（依赖于操作系统的进程调度），网络的动态特征（dynamics）（比如以太网的冲突和补偿（backoffs））。对于一个TCP连接的两端，没有单一的正确方法来交换给定数量的数据。

图二显示了交换过程的一些改变。是相同主机的相同数据交换，只不过抓包延迟几分钟。

有一些事件发生了改变。这一次接收者没有发送确认3073，取而代之的是确认2097。接收者只发送了4个确认信号（段7，10，12，15）：其中3个确认2048字节，一个确认1024字节。对最后1024个字节的确认连同对FIN的确认出现在段17。

快发送者，慢接收者（Fast Sender ，Slow Receiver）

图三显示了从一个快的发送者（Sparc）到慢接收者（使用低速以太网卡的80386）的时间线。它也存在动态性（即在不同时刻抓获的交换包不同）。

发送者传输4个背靠背的数据段（4-7）来填充接收者的窗口。然后发送者停止并等待确认。接收者发出确认（段8），但通告窗口大小是0。这就意味着接收者已经得到所有数据，但这些数据还都在其缓冲区中——应用程序还没有机会去读取数据。在17.4毫秒之后，另一个确认发出（称为窗口更新（window update）），声称接收者现在可以再接收4096字节。尽管看起来像是一个确认信号，但因为它不确认任何新数据，只是将窗口右移，所以称其为窗口更新。

发送者传输其最后4个段，再次将接收者的窗口填满。注意段13包含了两个标志位：PUSH和FIN。在其之后是接收者的两个确认，确认最后4096个字节的数据（从4097到8192）和FIN（标号8193）。

3．滑动窗口（Sliding Window）

滑动窗口协议可以用图四来形象表示。

图中我们已经将字节进行了1到11的编号。由接收者通告的窗口称为提议窗口（offered window），它覆盖了第4到第9个字节，意味着接收方已经确认了第3字节之前（包括第3字节）的数据，并且通告窗口的大小是6。窗口大小与确认的顺序号（acknowledged sequence number）有关。发送者计算它的可用窗口（usable window），用以度量它可以立即发送多少数据。

随着接收者对收到数据的确认，滑动窗口随时向右移动。窗口两端的相关运动增加或减少着窗口大小。我们使用3个术语来描述窗口边缘（edge）的左右运动。

1．              当窗口左边缘靠近右边缘时称窗口闭合（window closes）。窗口闭合发生在数据已经发送并被确认的情况下。

2．              当窗口右边缘向右移动时称窗口打开（window opens）。窗口打开发生在另一端的接收进程读取已确认数据的时候，它释放了TCP接收缓冲区的空间。

3．              当窗口右边缘向左移动时称窗口收缩（window shrinks）。Host Requirement RFC强烈不鼓励这种做法，但TCP必须能够在一端发生这种情况时进行处理。

 

     图五表示了这三个术语。由于窗口的左边缘是受从连接另一端收到的确认号来控制的，因此它不会向左移动。如果收到一个ACK要求将左边缘向左移动，那么它是一个重复的（duplicate）的确认，并被丢弃。

如果窗口左边缘重合了右边缘，就称它为零窗口（zero window）。它将停止发送者传输任何数据。

示例

图六显示了图一数据传输中TCP滑动窗口的动态变化

 

以此图为例，我们可以总结几个要点：

1．  发送者不必传送满窗口大小的数据。

2．  收到接收者对数据的确认后，窗口向右滑动。这是由于窗口大小与确认顺序号相关。

3．  从段7到段8的变化，可以看出窗口可以减小，但窗口右边缘不能向左移动。

4．  接收者不必等待窗口被填满才发送确认。在许多实现中，接收者每收到两个段发送一个确认。