TCP拥塞控制机制

 研究TCP的拥塞机制，不仅仅是想了解TCP如何的精巧，更多的是领悟其设计思想，即在一般情况下，我们该怎样处理问题。

 

一.拥塞的发生与其不可避免   

拥塞发生的主要原因：在于网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力。由于互联网的设计机制导致其缺乏“接纳控制”能力，因此在网络资源不足时不能限制用户数量，而只能靠降低服务质量来继续为用户服务，也就是“尽力而为”的服务。

拥塞其实是一个动态问题，我们没有办法用一个静态方案去解决，从这个意义上来说，拥塞是不可避免的。

• 静态解决问题办法1：
• 例如：增加缓存空间到一定程度时，只会加重拥塞，而不是减轻拥塞，这是因为当数据包经过长时间排队完成转发时，它们很可能早已超时，从而引起源端超时重发，而这些数据包还会继续传输到下一路由器，从而浪费网络资源，加重网络拥塞。事实上，缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路带宽及提高处理能力也不能解决拥塞问题。
• 静态解决问题办法2：
•  例如：我们有四台主机ABCD连接路由器R，所有链路带宽都是1Gbps，如果A和B同时向C以1Gbps的速率发送数据，则路由器R的输入速率为2Gbps，而输出速率只能为1Gbps，从而产生拥塞。避免拥塞的方法只能是控制AB的速率，例如，都是0.5Gbps，但是，这只是一种情况，倘若D也向R发送数据，且速率为1Gbps，那么，我们先前的修正又是不成立的，

 

二.流量控制   

• 早期的TCP协议只有基于窗口的流控制（flow control）机制，我们简单介绍一下，并分析其不足。   在TCP中，为了实现可靠性，发送方发出一个数据段之后要等待接受方相应的确认信息，而不是直接发送下一个分组。
• 具体的技术是采用滑动窗口，以便通信双方能够充分利用带宽。滑动窗口允许发送方在收到接收方的确认之前发送多个数据段。窗口大小决定了在收到目的地确认之前，一次可以传送的数据段的最大数目。窗口大小越大，主机一次可以传输的数据段就越多。当主机传输窗口大小数目的数据段后，就必须等收到确认，才可以再传下面的数据段。例如，若视窗的大小为 1，则传完数据段后，都必须经过确认，才可以再传下一个数据段；当窗口大小等于3时，发送方可以一次传输3个数据段，等待对方确认后，再传输下面三个数据段。  
•  窗口的大小在通信双方连接期间是可变的，通信双方可以通过协商动态地修改窗口大小。在TCP的每个确认中，除了指出希望收到的下一个数据段的序列号之外，还包括一个窗口通告，通告中指出了接收方还能再收多少数据段（我们可以把通告看成接收缓冲区大小）。如果通告值增大，窗口大小也相应增大；通告值减小，窗口大小也相应减小。但是我们可以发现，接收端并没有特别合适的方法来判断当前网络是否拥塞，因为它只是被动得接收，不像发送端，当发出一个数据段后，会等待对方得确认信息，如果超时，就可以认为网络已经拥塞了。
• 所以，改变窗口大小的唯一根据，就是接收端缓冲区的大小了。   
• 流量控制作为接受方管理发送方发送数据的方式，用来防止接受方可用的数据缓存空间的溢出。
• 流控制是一种局部控制机制，其参与者仅仅是发送方和接收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；
• 而拥塞控制则注重于整体，其考虑的是整个网络的传输能力，是一种全局控制机制。正因为流控制的这种局限性，从而导致了拥塞崩溃现象的发生。  

三.重传

1、一旦收到确认，发送方关闭重发定时器并且将数据片的备份从重发队列中删除。发送方如果在规定的时间内没有收到数据确认，就重传该数据。

2、当TCP超时并重传时，它不一定要重传同样的报文段，相反，TCP允许进行重新分组而发送一个较大的报文段，这将有助于提高性能(当然，这个较大的报文段不能够超过接收方声明的MSS)。在协议中这是允许的，因为TCP是使用字节序号而不是报文段序号来进行识别它所要发送的数据和进行确认。

3、重发定时器

(1)  每一次一个包含数据的包被发送（包括重发），如果该定时器没有运行则启动它，使得它在RTO秒之后超时（按照当前的RTO值）。

(2)  当所有的发出数据都被确认之后，关闭该重发定时器。

(3)  当接收到一个ACK确认一个新的数据，重新启动该重发定时器，使得它在RTO秒之后超时（按照当前的RTO值）

 

四.TCP拥塞控制机制   

TCP的拥塞控制由4个核心算法组成：“慢启动”（Slow Start）、“拥塞避免”（Congestion voidance）、“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）。

具体的流程图可以参见：http://www.eventhelix.com/RealtimeMantra/Networking/，这里我会把自己的理解尽可能详细的列出来。为了方便起见，把发送端叫做client，接收端为server，每个segment长度为512字节，阻塞窗口长度为cwnd（简化起见，下面以segment为单位），sequence number为seq_num，acknowledges number为ack_num。通常情况下，TCP每接收到两个segment，发送一个ack。

 

－－ 慢启动   

早期开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样很容易导致路由器缓存空间耗尽，网络发生拥塞，使得TCP连接的吞吐量急剧下降。由于TCP源端一开始并不知道网络资源当前的利用状况，因此新建立的TCP连接不能一开始就发送大量数据，而只能逐步增加每次发送的数据量，以避免上述现象的发生，这里有一个“学习”的过程。   假设client要发送5120字节到server，

慢启动过程如下：   

1.初始状态，cwnd=1,seq_num=1；client发送第一个segment;   

2.server接收到512字节（一个segment），回应ack_num=513;   

3.client接收ack(513)，cwnd＝1+1=2;现在可以一次发送2个数据段而不必等待ack   

4.server接收到2个segment，回应ack_num=513+512*2=1537   

5.client接收ack(1537)，cwnd=2+1;一次发送3个数据段   

6.server接收到3个segment，回应2个ack，分别为ack_num=1537+1024=2561和ack_num=2561+512=3073   

7.client接收ack(2561)和ack(3073),cwnd=3+2=5；一次可以发送5个数据段，但是只用4个就满足要求了   

8.server接收到4个segment，回应2个ack，分别为4097,5121   9.已经发送5120字节，任务完成！

总结一下： 当建立新的TCP连接时，拥塞窗口（congestion window，cwnd）初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量。  

－－ 拥塞避免   可以想象，如果按上述慢启动的逻辑继续下去而不加任何控制的话，必然会发生拥塞，引入一个慢启动阈值ssthresh的概念，当cwnd<ssthresh的时候，tcp处于慢启动状态，否则，进入拥塞避免阶段。通常，ssthresh初始化为 64 Kbytes。   当cwnd = 64947 + 512 = 65459，进入拥塞避免阶段，假设此时seq_num = _101024：   

1.client一次发送cwnd，但是先考虑头两个segment  

 2.server回应ack_num = 102048   

3.client接收到ack(102048),cwnd = 65459 + [(512 * 512) /65459] = 65459 + 4 = 65463，也就是说，每接到一个ack，cwnd只增加4个字节。   

4.client发送一个segment，并开启ack timer,等待server对这个segment的ack，如果超时，则认为网络已经处于拥塞状态，则重设慢启动阀值ssthresh=当前cwnd/2＝65463/2=32731，并且，立刻把cwnd设为1，很极端的处理！

 5.此时，cwnd<ssthresh，所以，恢复到慢启动状态。

总结一下： 如果当前cwnd达到慢启动阀值，则试探性的发送一个segment，如果server超时未响应，TCP认为网络能力下降，必须降低慢启动阀值，同时，为了避免形势恶化，干脆采取极端措施，把发送窗口降为1，个人感觉应该有更好的方法。

 

－－ 快速重传和快速恢复   

前面讲过标准的重传，client会等待RTO时间再重传，但有时候，不必等这么久也可以判断需要重传，

快速重传

例如：client一次发送8个segment，seq_num起始值为100000，但是由于网络原因，100512丢失，其他的正常，则server会响应4个ack(100512)(为什么呢，tcp会把接收到的其他segment缓存起来，ack_num必须是连续的)，这时候，client接收到四个重复的ack，它完全有理由判断100512丢失，进而重传，而不必傻等RTO时间了。  

快速恢复

我们通常认为client接收到3个重复的ack后，就会开始快速重传，但是，如果还有更多的重复ack呢，如何处理？这就是快速恢复要做的，事实上，我们可以把快速恢复看作是快速重传的后续处理，它不是一种单独存在的形态。   

以下是具体的流程：  

假设此时cwnd=70000,client发送4096字节到server,也就是8个segment，起始seq_num = _100000：   

1.client发送seq_num = _100000   

2.seq_num =100512的segment丢失   

3.client发送seq_num = _101024   

4.server接收到两个segment，它意识到100512丢失，先把收到的这两个segment缓存起来   

5.server回应一个ack(100512),表示它还期待这个segment  

 6.client发送seq_num = _101536   

7.server接收到一个segment，它判断不是100512，依旧把收到的这个segment缓存起来，并回应ack(100512)   。   。   。  

 8.以下同6、7,直到client收到3个ack(100512)，进入快速重发阶段：   

9.重设慢启动阀值ssthresh=当前cwnd/2＝70000/2=35000   

10.client发送seq_num = 100512     以下，进入快速恢复阶段：   

11.重设cwnd = ssthresh + 3 segments =35000 + 3*512 = 36536，之所以要加3，是因为我们已经接收到3个ack(100512)了，根据前面说的，每接收到一个ack，cwnd加1   

12.client接收到第四个、第五个ack(100512)，cwnd=36536+2*512=37560  

 13.server接收到100512,响应ack_num = _104096   14.此时，cwnd>ssthresh，进入拥塞避免阶段。

 

【思考】：为什么通常clieng每接收到一个ack，会把cwnd增加一个segment呢？  这是基于“管道”模型（pipe model）的“数据包守恒”的原则（conservation of packets principle），即同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网络。如果发送方收到一个ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。如果“数据包守恒”原则能够得到严格遵守，那么网络中将很少会发生拥塞；本质上，拥塞控制的目的就是找到违反该原则的地方并进行修正。

 

五.联想   想想看，能不能把TCP解决拥塞的方法应用到交通拥塞呢？   我们有两个原则：一是拥塞不可避免，单纯增加资源并不能避免拥塞的发生，只能用动态的方法加以解决；二是数据包守恒原则。政府花费很大资金修路，并不能避免堵车，只能从源头控制，例如首先限制车辆进入主路，根据实际情况，再慢慢增加每一个路口的车流量，但是，当达到一个阀值，增加速度要放缓，并不时探测整个主路的拥堵情况，如果情况危急，立刻封闭半个路口，并将车流量降到最低，也就是重新回复到慢启动状态。   呵呵，有趣！