云南龙网

  1. 首页 > 云知道 > >

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

云知道


长距离连接上 。假如没有任何机制防止短数据包拥塞 ， 25个数据包将在5秒内
被送出 。这儿开销是4000% 。用典型的定时器方案且同样是每秒2个数据包的限
制 ， 将仍有10个数据包不能处理并引起拥塞 。当然往返时间将不会因传送很多
的数据包而得到改善；通常 ， 它会因数据包竞争行时间而变得更糟 。这时开销降
到了1500% 。然而 ， 用我们的方案 ， 来自用户的第一个字符将发现空闲的TCP连
接且立即传送 。接下来的24个字符 ， 以200ms的间隔从用户端到来 ， 将等待远
端主机来的报文 。当一个对第一个数据报的确认ACK在5秒末到来时 ， 这24个
等待的字符封装到数据包中被传送出去 。这样 ， 我们的方案导致了在没有损失响
应时间的情况下开销减少到320% 。用我们的方案响应时间通常因为数据包开销
减少而得到改善 。拥塞将减少且往返时间延迟将显著下降 。在这个情况中 ， 我们
的方案明显优于其他方法 。
我们对所有的TCP连接使用我们的方案 ， 不仅仅是Telnet连接 。让我们看
看用我们的方法为文件传输建立数据连接时将会发生什么 。我们将再一次考虑到
这两个极端的情况 。
象前面所提的一样 ， 我们首先考虑以太网的情况 。用户现在以512字节块的
大小按TCP所能接受的速度向TCP写数据 。用户第一次向TCP写的数据启动传输；
我们的第一个数据报的大小将是512 40字节或552字节 。用户的第二次写数据
不会引起传送但会使这个块被缓冲 。设想用户在第一个确认到来之前填充TCP的
输出缓冲区 。然后 ， 当ACK到来时 ， 满足窗口大小的所有排队数据将被送出 ， 从
那时起 ， 窗口保持为满 ， 每个ACK开始一个传送循环 ， 等待的数据被送出 。这样,
在一个往返时间初始周期以后 ， 只有一个块要传送时 ， 我们的方案解决了最大吞
吐量的情况 。由于启动延迟在以太网上只有50ms ， 因此 ， 启动的瞬时延迟是无
关重要的 。三种方案都对这种情况提供了等价的性能 。
最后 ， 让我们看看在有5秒往返时间的连接上的文件传输 。在第一个确认回
来之前只有一个数据包被发送；窗口将被填充并填满 。因为往返时间是5秒 ， 只
有512字节的数据在第一个5秒被发送 。假定有一个2k的窗口 ， 一旦第一个确
认来到 ， 2K的数据将被发送 ， 之后 ， 将保持每5秒2K的稳定速率 。只有在这种
情况下我们的方案才比定时器方案差 ， 差别只在启动瞬时 。稳定状态下的吞吐量
是相同的 。朴素的方案和定时器方案在上面所提的情况下都要花250秒来传输
100K字节的文件 ， 我们的方案将花254秒 ， 1.6%的差别 。

带ICMP的拥塞控制
解决了短数据报问题以及在我们自己网络中的极端的短数据报拥塞问题 ， 我
们把注重力转向通常的拥塞控制 。既然我们的网络是没有点对点流量控制的纯数
据报网络 ， 对我们而言 ， 在IP标准下可获得的唯一机制是ICMP源抑制报文 。在
精心的控制下 ， 我们发现这足以防止严重的拥塞问题 。我们发现留心主机或交换
节点对源抑制报文的行为是必要的 。
何时发ICMP源抑制报文
当前的ICMP标准规定 ， 无论何时包丢失 ， ICMP源抑制报文就应该被发送 ，
此外 ， 当网关发现自己资源不足时也应发送源抑制报文 。这里有些二义性 ， 但很
明显,没有送ICMP报文而丢弃数据包违反了的标准 。
我们的基本假设是 ， 在网络正常运行时数据包不应该被丢弃 。因此我们想在

推荐阅读


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

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