云南龙网

  1. 首页 > 云知道 > >

TCP/IP互联网上的拥塞控制( 二 )

云知道


的某个时间上限已到 。通常 ， 这个机制足以防止严重的拥塞问题 。虽然有更好的
自适应主机重传算法 ， 但是网络上的意外负载能使往返时间的增长速度比发送方
估计的往返时间的更新更快 。当一个新的大量数据传输时 ， 这样的负载就产生了 ，
这样的文件传输开始填充一个大的窗口 。假如这个往返时间超过了所有主机的最
大重传间隔 ， 那么主机将开始向网络产生越来越多的同一数据报的副本 。这时,
这个网络有了严重问题 。最终在交换节点中所有可获得的缓冲将饱和 ， 于是必须
丢失数据报 。这时,被传送的这个数据报的往返时间到达它的最大值 。主机多次
发送每个报文 ， 最终每个报文的某个拷贝到达它的目的地 。这就是拥塞崩溃 。
这个状态是稳定的 。一旦到达饱和点 ， 假如选择包丢弃算法良好 ， 网络将继
续运行在性能降低了的状态下 。在这种状态下 ， 每个包被传输几次 ， 吞吐量将降
低到正常情况的几分之一 。我们实验性地迫使我们的网络处于这样的状态并且观
察它的稳定性 。往返时间可能变得很大以致于由于主机超时造成连接中断 。
拥塞崩溃和不正常的拥塞通常不出现在ARPANET/MILNET系统中 ， 因为这
些网络有足够大的超额容量 。只要连接不经过IP网关 ， 增强的主机流量控制机
制通常能防止拥塞崩溃 ， 非凡是自从针对和纯ARPANET网情况相关的时间常量
很好地调整了TCP实现以来 。然而 ， 当TCP运行在ARPANET/MILNET上数据
报在网关被丢弃时 ， 除了ICMP的源抑制报文外 ， 没有什么基本的机制来防止拥
塞崩溃 。一些运行不好的主机通过它们自身使网关拥塞并阻止其他主机通过是没
价值的 。我们已经在ARPANET上的某些主机上（我们已私下与这些主机的治理
员交流过）重复观察到这个问题 。
给网关添加额外的内存不能解决这个问题 。添加的内存越多 ， 在数据报被丢
弃之前往返时间变得越长 。这样 ， 拥塞崩溃的发生将被延迟 ， 但当崩溃发生时 ，
网络中的更大的数据报分片将被复制 ， 吞吐量将变得更糟 。
两个问题
和TCP实现的技术有关的两个要害问题已经被观察到；我们称它们为短数
据报问题和源抑制问题 。第二个问题正由几个实现方案着手解决 ， 第一个问题通
常被（不正确地）认为已经被解决了 。我们发现 ， 一旦短数据报问题解决 ， 源抑
制问题就变得更加轻易处理 。因此 ， 我们首先提出短数据报问题及其解决方案 。
短数据报问题
这里有一个与短数据报相关的具体问题 。当TCP用来传输来自键盘的单字
符信息时 ， 典型的结果是为了传输一个字节的有用数据传输了41个字节的数据
报（1个字节的数据 ， 40个字节的头文件） 。这4000%的开销是令人讨厌的 ， 但
在轻负载的网络里是可以容忍的 。然而 ， 在负荷过重的网络中 ， 由这个开销引起
的拥塞能导致数据报的丢失和重传 ， 以及在交换节点和网关中由于拥塞而造成传
输时间过大 。事实上 ， 吞吐量可能降低以致于TCP连接被异常中断 。
这个典型的问题在20世纪60年代下半期在Tymnet网络中第一次被提出并
被广泛熟悉 。那里所采用的解决办法是强行对每单位时间里所产生的数据报的数
量给定一个限制 。这个限制是通过对短数据报延迟一个短的时间（200-500ms）
后再传输来实施的 ， 以期可以在定时器到时之前另一个或两个字符到来并附加在
同一个数据报中 。为了增加用户的可接受性 ， 一个附加的特性是当一个控制字符

推荐阅读


上一篇：果然的意思 果然什么意思

下一篇：家里的大厚毛毯可以干洗吗