云南龙网

  1. 首页 > 云知道 > >

TCP拥塞控制( 四 )

云知道


（在接收端有了次序紊乱的数据段的情况下，它可能一会儿就到达） 。
另外，此ACK应该确认丢失数据段和第三个ACK副本期间的数据段，假如它们一个也没
有丢失的话 。
注重：当包的一个传送期间就有很多丢失时，这个算法不能够有效地恢复[FF96] 。为解
决这个问题而提出的一系列修正可以在[FH98]中找到 。
4．附加考虑
4．1闲置后重启连接
上面描述的TCP拥塞控制算法有一个众所周知的问题，就是TCP闲置了相当长一段时间
后，上述算法答应潜在的大量数据爆发性地传送 。在一段闲置期之后，TCP不能使用ACK　时
钟过滤新进入网络的数据段，因为所有的ACK都已经从网络中丢失 。因此，正如上面所述，
在一段闲置期之后TCP可能暗地里发送大量的cwnd尺寸的数据到网络 。
[Jac88]推荐TCP在一段相当长的闲置期之后使用慢启动来重新开始传输 。慢启动负责重
启ACK时钟，正如它在传输开始时所做的那样 。这种机制广泛地通过下面的方式来使用 。当
TCP在长于一个超时重传时间里没有收到一个数据段，cwnd就在传输之前被减小为重启窗口
（RW）的值 。为了实现这个标准，我们定义RW=IW 。
我们注重到非标准的实验性的TCP扩充在[AFP98]定义RW=min(IW,cwnd)，其中IW的定
义经过等式（1）调整过 。使用最后一次收到数据段的时间来决定是否减小cwnd不能够在常
见的HTTP永久连接情况下缩减cwnd[HTH98] 。在这种情况下，WWW服务器在传输数据到WWW
浏览器之前接收一个请求 。这个请求的接收导致一个对闲置连接的测试失败，并且答应TCP
使用可能的不恰当大的cwnd开始传输 。
因此，假如TCP在超过超时重传的时间里没有发送数据的话，TCP应该在开始传输之前
设置cwnd小于RW 。
4．2确认生成
TCP接收端应该使用[Bra89]中描述的ACK延迟算法 。使用时，TCP接收端不能过分延迟
确认 。可以明确的是，至少应该每隔一个满尺寸数据段生成一个ACK，而且应该在第一个没有
确认的包到达后500毫秒内生成 。
ACK“应该”每隔一个满尺寸数据段生成一个的要求在[Bra89]的一个地方显示为“应该”，
另一个地方为“必须” 。这里我们明确地说它是“应该” 。我们也强调这是一个“应该”，它意
味着一个实现在仔细考虑了它的含意之后可以而且只能“偏离”此要求 。参见[PAD 98]里的
“StretchACKviolation”和那里对比每隔一个满尺寸数据段更频繁生成ACK可能带来的性
能问题的讨论 。
在某些情况下，发送端和接收端可能对一个满尺寸数据段的组成没有达成一致意见 。如
果一个实现每从发送端接收到2*RMSS字节数据就发送至少一个确认的话，那么此实现就被认
为符合要求（达成一致意见），RMSS是接收端向发送端指定的最大数据段尺寸（据[Bra89]，
假如接收端没有在连接期间指定一个MSS选项，就是默认的536字节） 。发送端可能被迫使用
尺寸小于RMSS的数据段，由于最大传输单元（MTU），MTU路径发现算法或其它因素的缘故 。
比如，考虑如下情况：接收端通知RMSS为X字节，但是发送端因为MTU路径发现算法（或者
发送端的MTU尺寸）而以一个尺寸为Y字节的数据段结束 。在一个ACK发送之前假如接收端
等待2*X字节到达，那么它将生成扩展ACK 。很明显这将占据多于两个的尺寸大于Y字节的数
据段 。因此，当一个特定的算法没有定义时，接收端最好是试着阻止这种情况，比如通过至
少每隔一个数据段进行确认，不管尺寸 。最后，我们重申，ACK不能被延迟长于500毫秒来等

推荐阅读


上一篇：硝酸银和氯化钾反应方程式硝酸银和氯化钾的化学方程式

下一篇：港版iPhone6支持电信4G/3G/2G信号吗