云南龙网

  1. 首页 > 云知道 > >

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

云知道


发送方使交换节点和网关超负荷之前抑制发送方重发 。我们的交换节点在缓冲区
耗尽之前能很好地发送ICMP源抑制报文；直到它们在发送ICMP源抑制报文之前
必须丢弃报文时才等待 。正如我们在短数据报问题的分析中演示的 ， 仅仅提供大
量的缓冲是不能解决问题的 。通常 ， 我们的经验是 ， 当用了缓冲区的一半左右 ，
源抑制报文就应该发送了；这不是基于广泛的实验 ， 但似乎是个合理的技术决定 。
可以讨论一个自适应方案 ， 这个方案可以调整基于近期经验的抑制产生边界；到
目前为止我们还没有发现这个必要性 。
还有其他的网关实现算法 ， 仅在不只一个包被丢弃之后才产生源抑制报文 。
我们认为这种方法是不好的 ， 因为任何基于包丢弃的拥塞控制系统浪费带宽 ， 且
可能在负荷重时轻易受拥塞崩溃的影响 。我们理解的是 ， 被动地产生源抑制报文
的方案基于这样的担心 ， 害怕确认传输将被抑制以及这将导致连接失败 。正如下
面将要展示的 ， 在主机实现中的恰当的源抑制控制排除了这种可能性 。
在收到ICMP源抑制报文时做什么
当ICMP收到一个源抑制报文时我们通知TCP或者该层上的任意其他协议 。
我们的TCP具体实现的基本行为是减少与源抑制报文中所指出的主机的连接上
未处理的数据的数量 。使发送端TCP的反应就象远端主机窗口大小已经减少,从
而实施这个控制 。我们的第一个实现过于简单化但却有效；一旦收到源抑制报文 ，
只要窗口不为空 ， 我们的TCP就认为窗口大小为0并做相应处理 。这个行为将持
续到收到一定数量（现在是10）的ACK为止 ， 到那时 ， TCP回到正常的运行状态
。Linkabit公司的DavidMills在他的DCN系统中实现了一个类似的但更具体
的对未处理的数据包的节流控制 。这个附加的复杂性好象提供了一个获得吞吐量
的方式 ， 但我们没有做过正式的测试 。两个实现都有效地防止了交换节点的拥塞
崩溃 。
这样 ， 源抑制方法有效地限制了到有限数量（可能为1）的未处理报文的连
接 。因此 ， 通信能继续但是速率降低 ， 那正是期望的效果 。
这个方案有个重要的性质 ， 源抑制不能禁止确认和重传的发送 。源抑制在
IP层上的完全实现通常是不成功的 ， 因为IP缺少足够的信息来正确地控制一个
连接的流量 。抑制确认信息往往产生重传和不必要的传输 。抑制重传可能因重传
超时而使连接丢失 。我们的方案将在服务器超负荷下保持活动连接但减少每个连
接的带宽 。
在同一层与TCP一样的其他协议也应该响应源抑制 。在每种情况下 ， 我们建
议应该控制新的传输流量但正常对待确认 。唯一严重的问题来自于用户数据报协
议 ， 而通常不的主要传输发生器 。我们仍未在这些协议中实现任何流量控制 。
网关的自防御
正如我们已经显示的 ， 网关易受拥塞治理不善的主机的攻击 。由于产生过多
通信量而引起的主机错误行为不仅防止了主机自身的传输而且能影响了其他不
相关的传输 。这个问题可以在主机级处理 ， 但既然一台有故障的主机能影响其他
主机 ， 将来的网关应该有防御能力使它们自己不被那些可恶可憎的主机的这种行
为所影响 。我们提供了一些基本的自防御技术 。
曾经在1983年下半年 ， 一个在ARPANT主机中的TCP故障使主机以ARPANET
所能接受的速度疯狂地产生相同数据报的重发报文 。通过ARPANET连接到我们网

推荐阅读


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

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