速读原著-TCP/IP(串行线路吞吐量计算)

72 阅读 0 评论 48 点赞

我是靠谱客的博主合适凉面，最近开发中收集的这篇文章主要介绍速读原著-TCP/IP(串行线路吞吐量计算)，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

2.9 路径MTU

当在同一个网络上的两台主机互相进行通信时，该网络的 M T U是非常重要的。但是如果两台主机之间的通信要通过多个网络，那么每个网络的链路层就可能有不同的 M T U。重要的不是两台主机所在网络的 M T U的值，重要的是两台通信主机路径中的最小 M T U。它被称作路径M T U。

两台主机之间的路径 M T U不一定是个常数。它取决于当时所选择的路由。而选路不一定是对称的（从A到B的路由可能与从B到A的路由不同），因此路径M T U在两个方向上不一定是一致的。

RFC 1191[Mogul and Deering 1990]描述了路径M T U的发现机制，即在任何时候确定路径M T U的方法。我们在介绍了 I C M P和I P分片方法以后再来看它是如何操作的。在 11 . 6节中，我们将看到I C M P的不可到达错误就采用这种发现方法。在 11 . 7节中，还会看到，t r a c e r o u t e程序也是用这个方法来确定到达目的节点的路径 M T U。在11 . 8节和2 4 . 2节，将介绍当产品支持路径M T U的发现方法时，U D P和T C P是如何进行操作的。

2.10 串行线路吞吐量计算

如果线路速率是9600 b/s，而一个字节有8 bit，加上一个起始比特和一个停止比特，那么线路的速率就是960 B/s（字节/秒）。以这个速率传输一个1 0 2 4字节的分组需要1066 ms。如果用S L I P链接运行一个交互式应用程序，同时还运行另一个应用程序如 F T P发送或接收1 0 2 4字节的数据，那么一般来说就必须等待一半的时间（ 533 ms）才能把交互式应用程序的分组数据发送出去。

假定交互分组数据可以在其他“大块”分组数据发送之前被发送出去。大多数的 S L I P实现确实提供这类服务排队方法，把交互数据放在大块的数据前面。交互通信一般有 Te l n e t、R l o g i n以及F T P的控制部分（用户的命令，而不是数据）。这种服务排队方法是不完善的。它不能影响已经进入下游（如串行驱动程序）队列的非交互数据。同时，新型的调制解调器具有很大的缓冲区，因此非交互数据可能已经进入该缓冲区了。

对于交互应用来说，等待 533 ms是不能接受的。关于人的有关研究表明，交互响应时间超过1 0 0～200 ms就被认为是不好的 [Jacobson 1990a]。这是发送一份交互报文出去后，直到接收到响应信息（通常是出现一个回显字符）为止的往返时间。

把S L I P的M T U缩短到2 5 6就意味着链路传输一帧最长需要 266 ms，它的一半是 133 ms（这是一般需要等待的时间）。这样情况会好一些，但仍然不完美。我们选择它的原因（与 6 4或1 2 8相比）是因为大块数据提供良好的线路利用率（如大文件传输）。假设C S L I P的报文首部是5个字节，数据帧总长为 2 6 1个字节，2 5 6个字节的数据使线路的利用率为 9 8 . 1 %，帧头占
了1 . 9 %，这样的利用率是很不错的。如果把 M T U降到2 5 6以下，那么将降低传输大块数据的最大吞吐量。

在图2 - 5列出的M T U值中，点对点链路的M T U是2 9 6个字节。假设数据为2 5 6字节，T C P和I P首部占4 0个字节。由于M T U是I P向链路层查询的结果，因此该值必须包括通常的 T C P和I P首部。这样就会导致I P如何进行分片的决策。I P对于C S L I P的压缩情况一无所知。

我们对平均等待时间的计算（传输最大数据帧所需时间的一半）只适用于 S L I P链路（或P P P链路）在交互通信和大块数据传输这两种情况下。当只有交互通信时，如果线路速率是9600 b/s，那么任何方向上的 1字节数据（假设有 5个字节的压缩帧头）往返一次都大约需要12.5 ms。它比前面提到的100~200 ms要小得多。需要注意的是，由于帧头从 4 0个字节压缩到5个字节，使得1字节数据往返时间从85 ms减到12.5 ms。

不幸的是，当使用新型的纠错和压缩调制解调器时，这样的计算就更难了。这些调制解调器所采用的压缩方法使得在线路上传输的字节数大大减少，但纠错机制又会增加传输的时间。不过，这些计算是我们进行合理决策的入口点。在后面的章节中，我们将用这些串行线路吞吐量的计算来验证数据从串行线路上通过的时间。