(转)协议森林12 天下为公 (TCP堵塞控制)
2014-03-09 14:41
274 查看
协议森林12 天下为公 (TCP堵塞控制)
作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明。谢谢!在TCP协议中,我们使用连接记录TCP两端的状态,使用编号和分段实现了TCP传输的有序,使用advertised window来实现了发送方和接收方处理能力的匹配,并使用重复发送来实现TCP传输的可靠性。我们只需要将TCP片段包装成IP包,扔到网络中就可以了。TCP协议的相关模块会帮我们处理各种可能出现的问题(比如排序,比如TCP片段丢失等等)。最初的TCP协议就是由上述的几大块构成的。
然而进入上世纪八十年代,网络开始变的繁忙。许多网络中出现了大量的堵塞(congestion)。堵塞类似于现实中的堵车。网络被称为“信息高速公路”。许多汽车(IP包)在网络中行驶,并经过一个一个路口 (路由器),直到到达目的地。一个路由器如果过度繁忙,会丢弃一些IP包。UDP协议不保证传输的可靠性,所以丢失就丢失了。而TCP协议需要保证传输的可靠性,当包含有TCP片段的IP包丢失时,TCP协议会重复发送TCP片段。于是,更多的“汽车”进入到公路中,原本繁忙的路由器变得更加繁忙,更多的IP包丢失。这样就构成了一个恶性循环。这样的情况被称为堵塞崩溃(congestion collapse)。每个发送方为了保证自己的发送质量,而不顾及公共领域现状,是造成堵塞崩溃的主要原因。当时的网络中高达90%的传输资源可能被堵塞崩溃所浪费。
为了解决这一缺陷,从八十年代开始,TCP协议中开始加入堵塞控制(congestion control)的功能,以避免堵塞崩溃的出现。多个算法被提出并实施,大大改善了网络的交通状况。直到今天,堵塞控制依然是互联网研究的一个活跃领域。
公德 |
我们先来说明堵塞是如何探测的。在TCP重新发送中,我们已经总结了两种推测TCP片段丢失的方法:ACK超时和重复ACK。一旦发送方认为TCP片段丢失,则认为网络中出现堵塞。
另一方面,TCP发送方是如何控制发送速率呢?TCP协议通过控制滑窗(sliding window)大小来控制发送速率。在TCP滑窗管理中,我们已经见到了一个窗口限制,就是advertised window size,以实现TCP流量控制。TCP还会维护一个congestion window size,以根据网络状况来调整滑窗大小。真实滑窗大小取这两个滑窗限制的最小值,从而同时满足两个限制 (流量控制和堵塞控制)。
我们将专注于congestion window。(Hulk,smash!)
Congestion Window |
上图是概念性的。实际的实施要比上图复杂,而且根据算法不同会有不同的版本。cwnd代表congestion window size。我们以片段的个数为单位,来表示cwnd的大小 (同样是概念性的)。
Congestion window从slow start的状态开始。Slow start的特点是初始速率低,但速率不断倍增。每次进入到slow start状态时,cwnd都需要重置为初始值1。发送方每接收到一个正确的ACK,就会将congestion window增加1,从而实现速率的倍增(由于累计ACK,速率增长可能会小于倍增)。
当congestion window的大小达到某个阈值ssthresh时,congestion进入到congestion avoidance状态。发送速率会继续增长。发送方在每个窗户所有片段成功传输后,将窗口尺寸增加1(实际上就是每个RTT增加1)。所以在congestion avoidance下,cwnd线性增长,增长速率慢。
如果在congestion avoidance下有片段丢失,重新回到slow start状态,并将ssthresh更新为cwnd的一半。
我们看到,sshthresh是slow start到congestion avoidance的切换点。而片段丢失是congestion avoidance到slow start的切换点。一开始sshthresh的值一般比较大,所以slow start可能在切换成congestion avoidance之前就丢失片段。这种情况下,slow start会重新开始,而ssthresh更新为cwnd的一半。
总的来说,发送速率总是在增长。如果片段丢失,则重置速率为1,并快速增长。增长到一定程度,则进入到慢性增长。快速增长和慢性增长的切换点(sshthred)会随着网络状况(何时出现片段丢失)更新。通过上面的机制,让发送速率处于动态平衡,不断的尝试更大值。初始时增长块,而接近饱和时增长慢。但一旦尝试过度,则迅速重置,以免造成网络负担。
总结 |
互联网利用“公德”来实现效率。“公德”和效率似乎可以并存。
到现在为止,TCP协议的介绍就可以告一段落了。可以回想一下TCP的几大模块:分段与流,滑窗,连接,流量控制,重新发送,堵塞控制。
相关文章推荐
- 协议森林12 天下为公 (TCP堵塞控制)
- 协议森林12 天下为公 (TCP堵塞控制)
- 协议森林12 天下为公 (TCP堵塞控制)
- 协议森林12 天下为公 (TCP堵塞控制)
- 协议森林12 天下为公 (TCP堵塞控制)
- 协议森林12 天下为公 (TCP堵塞控制)
- 天下为公:TCP堵塞控制
- TCP/IP之TCP协议(3):流量控制(滑动窗口协议)
- QUIC 协议中涉及的TCP流量控制和拥塞控制的问题
- 协议森林10 魔鬼细节 (TCP滑窗管理)
- TCP堵塞控制
- 【网络协议】TCP的拥塞控制机制
- 协议森林09 爱的传声筒 (TCP连接)
- TCP/IP之TCP协议(3):流量控制(滑动窗口协议)
- TCP/IP学习(TCP传送控制协议)
- TCP流量控制协议
- 协议森林09 爱的传声筒 (TCP连接)
- TCP协议的滑动窗口具体是怎样控制流量的?
- TCP -- 传输控制协议
- 协议森林09 爱的传声筒 (TCP连接)