云南龙网

  1. 首页 > 云知道 > >

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

云知道


（比如回车字符）到来时 ， 禁止时间延迟 。
这个技术已经在NCPTelnet ， X.25PADs和TCPTelnet中使用 。它的优点是
易于理解和不难实现 。它的缺点是很难给出一个使每个人满足的时限 。一个在
10Mbps以太网上提供高速应答服务的时限太短以致于不能防止在有5秒往返时
间的高负荷的网络上的拥塞崩溃；相反 ， 处理高负荷的网络的时限太长又会给以
太网的用户造成挫折感 。
短数据报的解决方案
显然,一个自适应的方法是不难想到的 。我们期望为自适应交互包的时限提
出一个建议方案 ， 这个时限是在TCP所观察到的往返时间延迟的基础上的 。然而
虽然这样一个机制确实能被实现 ， 但它是不必要的 。我们发现了一个简单且优化
的解决方案 。
这个解决方案是 ， 假如任何先前在连接上传输的数据仍没有被确认 ， 那么来
自用户的输出数据到来时 ， 禁止传输TCP数据段 。这个限制是无条件的 ， 没有定
时器 ， 不需要测试收到的数据的大小 ， 不需要其他条件 。典型的实现只需要TCP
程序中的一两行程序 。
乍看 ， 这个解决方案好象意味着TCP行为的剧烈改变 。但并非如此 。最终它
很好地工作 。让我们看看为什么是这样 。
当一个用户向一个TCP连接写数据时,TCP收到一些数据 。它可以保持这些
数据以便以后传送或者也可以立即送出一个数据包 。假如它不立即传送 ， 它将在
一个传入的数据包到来且改变了系统状态之后传送数据 。可以有两种方式之一来
改变这种状态；这个到来的数据包确认远端主机收到数据 ， 或者通告远端主机为
新数据提供的可用缓冲空间大小 。（后者指“更新窗口”） 。每次 ， 此连接上的数
据到来时 ， TCP必须重新检查它的当前状态并可能会送出一些数据包 。这样 ， 当
我们忽略送出来自用户端的数据时 ， 我们只是简单地延迟传输直到下一个来自远
端的主机的报文到来 。报文总是很快就到来 ， 除非这条连接之前是空闲的或者与
另一端的通信丢失 。在第一种情况 ， 即空闲连接 ， 我们的方案将使用户在任何时
候向TCP连接写数据时送出数据包 。这样 ， 我们就不会在空闲连接时死锁 。第二
种情况 ， 远端主机失败 ， 传送更多的数据都是无效的 。注重 ， 我们没有采取任何
措施来禁止正常的TCP重传逻辑 ， 因此 ， 丢失报文不是问题 。
这个方案在不同条件下的性能测试表明这个方案可以在所有情况下工作 。第
一个测试的情况是我们想解决面向字符的Telnet连接问题 。让我们想象一下 ，
用户每200ms向TCP输出一个新的字符 ， 并且这个连接要经过以太网 ， 此以太网
的往返时间包括了50ms的软件处理时间 。假如没有任何机制来防止短数据报的
拥塞 ， 与每个字符对应的数据包将被送出 ， 响应是最佳的 。开销将是4000% ，
但在以太网上可以接受的 。而典型的定时器方案 ， 每秒两个数据包的限制 ， 将使
两个或三个字符在一个数据包中被传送 。响应性能将降低 ， 即使在高带宽的以太
网上也是没有用的 。开销降到1500% ， 但在以太网上这是个不太好的替换方案 。
而我们的方案 ， 用户所敲击的每个字符将找到一条空闲的TCP连接 ， 字符将马上
被传送 ， 正如在无控制的情况一样 。用户将不会感觉到延迟 。这样 ， 我们的方案
既可作为无控制的方案运行又可以提供比定时器方案更好的响应 。
第二个测试的情况是同样的Telnet测试 ， 但是测试是在有5秒往返时间的

推荐阅读


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

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