速读原著-TCP/IP(拥塞举例)
第21章 TCP的超时与重传
21.5 拥塞举例
现在观察一下数据报文段的传输过程。图 2 1 - 6显示了报文段中数据的起始序号与该报文段发送时间的对比图。它提供了一种较好的数据传输的可视化方法。通常代表数据的点将向上和向右移动，这些点的斜率就表示传输速率。当这些点向下和向右移动则表示发生了重传。在2 1 . 4节开始时，我们曾提到整个传输的时间约为 4 5秒，但在本图中只显示了 3 5秒钟。
这3 5秒只是数据报文段发送的时间。因为第 1个S Y N看来是丢失了并被重传（见图 2 1 - 5），因此第1个数据报文段是在第 1个S Y N发送6 . 3秒后才发送的。而且，在发送最后一个数据报文段和F I N（图2 1 - 6中的3 4 . 1秒）之后，在接收方的 F I N到达之前，又花费了另外的 4 . 0秒接收来自接收方的最后1 4个A C K。
可以立即看到图 2 1 - 6中发生在时刻 1 0，1 4和2 1附近的3个重传。我们还可以看到在这 3个点中只进行了一次报文段的重传，因为只有一个点下垂低于向上的斜率。
仔细检查一下这几个下垂点中的第 1个点（在1 0秒标记处的附近）。整理t c p d u m p的输出结果可以得到图2 1 - 7。
在这个图中，除了下面将要讨论的报文段 7 2，已经去掉了其他所有的窗口通告。主机s l i p总是通告窗口大小为 4 0 9 6，而主机v a n g o g h则通告窗口为 8 1 9 2。该图中报文段的编号可以看作是图 2 1 - 2的延续，在那里报文段的编号从 1开始。与图2 1 - 2一样，报文段根据在 s l i p上发送和接收的顺序进行编号， t c p d u m p在主机s l i p上运行。我们还去掉了一些与讨论无关的段（第44, 47和4 9以及所有来自v a n g o g h的A C K）
看来报文段4 5丢失或损坏了，这一点无法从该输出上进行辨认。能够在主机 s l i p上看到的是对第6 6 5 7字节（报文段5 8）以前数据的确认（不包括字节 6 6 5 7在内）。紧接着的是带有相同序号的8个A C K。正是接收到报文段 6 2，也就是第3个重复A C K，才引起自序号6 6 5 7开始的数据报文段（报文段 6 3）进行重传。的确，源于伯克利的 T C P实现对收到的重复 A C K进行计 数，当收到第3个时，就假定一个报文段已经丢失并重传自那个序号起的一个报文段。这就是J a c o b s o n的快速重传算法，该算法通常与他的快速恢复算法一起配合使用。我们在第 2 1 . 7节中介绍这两个算法。
注意到在重传后（报文段 6 3），发送方继续正常的数据传输（报文段 6 7、6 9和7 1）。T C P\不需要等待对方确认重传。
现在检查一下在接收端发生了什么。当按序收到正常数据（报文段 4 3）后，接收 T C P将2 5 5个字节的数据交给用户进程。但下一个收到的报文段（报文段 4 6）是失序的：数据的开始序号（6 9 1 3）并不是下一个期望的序号（ 6 6 5 7）。T C P保存2 5 6字节的数据，并返回一个已成功接收数据的最大序号加 1（6 6 5 7）的A C K。被v a n g o g h接收到的后面 7个报文段（ 48, 50,52, 54, 55, 57和5 9）也是失序的，接收方T C P保存这些数据并产生重复A C K。
目前T C P尚无办法告诉对方缺少一个报文段，也无法确认失序数据。此时主机 v a n g o g h所能够做的就是继续发送确认序号为 6 6 5 7的A C K。
当缺少的报文段（报文段 6 3）到达时，接收方T C P在其缓存中保存第 6 6 5 7 ~ 8 9 6 0字节的数据，并将这2 3 0 4字节的数据交给用户进程。所有这些数据在报文段 7 2中进行确认。请注意此时该A C K通告窗口大小为5 8 8 8（8 1 9 2-2 3 0 4），这是因为用户进程没有机会读取这些已准备好的2 3 0 4字节的数据。
如果仔细检查图21-6 中t c p d u m p的输出中第1 4和2 1秒附近的下垂点，我们会看到它们也是由于收到了3个重复A C K引起的，这表明一个分组已经丢失。在这些例子中只有一个分组被重传。
在介绍完拥塞避免算法后，将在第 2 1 . 8节中继续讨论这个例子。