TCP拥塞控制

原文出处：http://blog.sina.com.cn/s/blog_75d405ab01010v4v.html

当网络中存在过多的数据包时，网络的性能就会下降，这种现象称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发生“拥塞崩溃”（congestion collapse）现象。一般来说，拥塞崩溃发生在网络负载的增加导致网络效率的降低的时候。

对于拥塞现象，当网络负载较小时，吞吐量基本上随着负载的增长而增长，呈线性关系，响应时间增长缓慢。当负载达到网络容量 时，吞吐量呈现出缓慢增长，而响应时间急剧增加，这一点称为Knee。如果负载继续增加，路由器开始丢包，当负载超过一定量时，吞吐量开始急剧下降，这一 点称为Cliff。拥塞控制机制实际上包含拥塞避免（congestion avoidance）和拥塞控制（congestion control）两种策略。前者的目的是使网络运行在Knee附近，避免拥塞的发生；而后者则是使得网络运行在Cliff的左侧区域。前者是一种“预防” 措施，维持网络的高吞吐量、低延迟状态，避免进入拥塞；后者是一种“恢复”措施，使网络从拥塞中恢复过来，进入正常的运行状态。

拥塞现象的发生和前面提到的互联网的设计机制有着密切关系，我们对这种设计机制作一个简单的归纳：

1. 数据包交换（packet switched）网络：与电路交换（circuit switched）网络相比，由于包交换网络对资源的利用是基于统计复用（statistical multiplexing）的，因此提高了资源的利用效率。但在基于统计复用的情况下，很难保证用户的服务质量（quality of service，QoS），并且很容易出现数据包“乱序”的现象，对乱序数据包的处理会大大增加拥塞控制的复杂性。
2. 无连接（connectionless）网络：互联网的节点之间在发送数据之前不需要建立连接，从而简化了网络的设 计，网络的中间节点上无需保留和连接有关的状态信息。但无连接模型很难引入接纳控制（admission control），在用户需求大于网络资源时难以保证服务质量；此外，由于对数据发送源的追踪能力很差，给网络安全带来了隐患；无连接也是网络中出现乱序 数据包的主要原因。
3. “尽力而为”的服务模型：不对网络中传输的数据提供服务质量保证。在这种服务模型下，所有的业务流被“一视同仁”地公 平地竞争网络资源，路由器对所有的数据包都采用先来先处理（First Come First Service，FCFS）的工作方式，它尽最大努力将数据包包送达目的地。但对数据包传递的可靠性、延迟等不能提供任何保证。这很适合Email、 Ftp、WWW等业务。但随着互联网的飞速发展，IP业务也得到了快速增长和多样化。特别是随着多媒体业务的兴起，计算机已经不是单纯的处理数据的工具。 这对互联网也就相应地提出了更高的要求。对那些有带宽、延迟、延迟抖动等特殊要求的应用来说，现有的“尽力而为”服务显然是不够的。

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

拥塞虽然是由于网络资源的稀缺引起的，但单纯增加资源并不能避免拥塞的发生。例如增加缓存空间到一定程度时，只会加重拥塞，而不是减轻拥 塞，这是因为当数据包经过长时间排队完成转发时，它们很可能早已超时，从而引起源端超时重发，而这些数据包还会继续传输到下一路由器，从而浪费网络资源， 加重网络拥塞。事实上，缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路带宽及提高处理能力也不能解决拥塞问题，例如，四个节点之间的链路带宽都是19.2kbps，传输某个文件需要用时5分钟；当第一个节点和第二个节点之间的链路带宽提高到1Mbps时，传输完该文件所需时间反而大大增加到了7个小时！这是因为在路由器R1中，数据包的到达速率远远大于转发的速率，从而导致大量数据包被丢弃，源端的发送速度被抑止，从而使得传输时间大大增加。即使所有链路具有同样大的带宽也不能解决拥塞问题。所有链路带宽都是1Gbps，如果A和B同时向C以1Gbps的速率发送数据，则路由器R的输入速率为2Gbps，而输出速率只能为 1Gbps，从而产生拥塞。

单纯地增加网络资源之所以不能解决拥塞问题，是因为拥塞本身是一个动态问题，它不可能只靠静态的方案来解决，而需要协议能够在网络出现拥 塞时保护网络的正常运行。目前对互联网进行的拥塞控制主要是依靠在源端执行的基于窗口的TCP拥塞控制机制。网络本身对拥塞控制所起的作用较小，但近几年 这方面的研究已经成了一个新的热点。
早期的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制，因而易导致网络拥塞。1988年Jacobson针对TCP在网络拥塞控制方面的不足，提出了“慢启动” （Slow Start）和“拥塞避免”（Congestion Avoidance）算法。1990年出现的TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过度减小发送窗口尺寸的现象，这样TCP的拥塞控制就主要由这4个核心算法组成。

TCP协议的目的是为上层应用提供可靠的服务，其主要特征在于：

1. 确保各流享用带宽的公平性。
2. 动态发现当前可利用的带宽。
3. 拥塞避免及控制机制以避免拥塞崩溃（congestion collapse）的发生。

标准版本的TCP使用基于窗口的的和式增加积式减小（Additive Increase Multiplicative Decrease，AIMD）方式控制发送速率，以保证稳定性及带宽享用的公平性。

错误控制机制是一个可靠传输协议的关键部分。它对协议的性能有很大的影响，包括吞吐量、能量消耗及可靠性。错误控制通常包括错误检测和错 误恢复两部分。为了保证数据传输的可靠性，TCP要求接受端在正确接收到数据段（data segment）后向发送端发送一个确认包，确认包中包含了期望接收到的下一个数据段的序号。TCP发送端通过监测确认包的序号来检测是否发生了错误。如 果发生超时或者发送端收到一定数量（通常是3个）重复的确认包，则认为传输过程中发生了错误，数据段被丢弃。由于有线网络的位出错率很低（例如光纤的 BER通常只有10－12[22]），因此TCP假设丢包是由于网络拥塞引起的。在错误恢复处理过程中，TCP重传丢弃的数据段、减小发送端窗口大小并且 在超时情况下重置超时时钟。

最初的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制。流控制作为接受方管理发送方发送数据的方式，用来防止接受方可用的数据缓存空间的溢出。流控制是一种局部控制机 制，其参与者仅仅是发送方和接收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制则注重于整体，其考虑的是整个网络的传输能力， 是一种全局控制机制。正因为流控制的这种局限性，从而导致了拥塞崩溃现象的发生。

拥塞控制的问题主要集中在效率和公平性（fairness）上。网络资源的使用效率是指源端要求的总资源与网络所能提供的资源之间的关系。如果二者刚好相 等或者很接近，那么这种算法的效率就是高的，否则都是效率不高的表现。

公平性是指在网络发生拥塞时各连接能公平地共享网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数 据流之间为争抢有限的网络资源发生竞争，竞争能力强的数据流将到更多网络资源，从而损害了其他流的利益。所以说没有拥塞，也就没有公平性问题。公平性问题 表现在两方面：一是拥塞响应的TCP流和非拥塞响应的UDP流之间资源享用不公平；二是TCP流之间资源享用的不公平。前者主要是在发生拥塞时对拥塞指示 作出的不同反应造成的。由于TCP流具有拥塞控制机制，在收到拥塞指示后，源端会主动降低发送速率；而UDP流由于没有端到端的拥塞控制机制，因此在收到 拥塞指示后，UDP不会降低数据发送速率。结果在网络拥塞时，拥塞适应的TCP流得到的资源越来越少，非拥塞适应的UDP得到的资源越来越多，从而导致了 网络资源分配的不公平。网络资源分配的不公平反过来会加重拥塞情况，甚至可能导致拥塞崩溃。对于第二个不公平性问题，研究表明，不同的窗口大小、RTT值 及数据包的尺寸都会影响TCP流对带宽的占用。窗口较大，或者RTT较小，或者数据包较大的流往往能占用更多的带宽。

1 针对对不必要的超时重传和快速重传

我们知道，当前的TCP应用主要有两种重传机制－快速重传和超时重传。当TCP源端收到3个ACK副本时，就会触发快速重传机制，此时源 端重传丢失的数据包并且将拥塞窗口大小减半。这种情况下，TCP流往往能够很快从丢包中恢复过来，重新回到原先的发送速率。但如果TCP源端没有收到3个 ACK副本，例如拥塞窗口大小小于4，那么TCP源端则需要等待相当长时间，以便超时重发。这样，小窗口的TCP流就很容易陷入不必要的超时重发，使其吞 吐量大大下降。

为了避免这种不必要的超时重传，一种改进办法就是只要TCP源端收到一个或者两个ACK副本，并且如果通告窗口允许，便继续发送新的数据 包。这是因为只要收到ACK副本，就表明有数据包已经离开网络被接受端接收了，而此时源端还无法判断数据包是否被丢弃，根据“数据包守恒”原则，只要遵守 拥塞窗口的规范，也即同时在网络中传送的数据包数量不能超过拥塞窗口的大小（以数据包为单位），源端就可以继续发送新的数据包。这种机制称为限制传输机制 （Limited Transmit mechanism），这种机制对排序的数据包尤其有效。

限制传输机制可以使小窗口的TCP流很快从丢包中恢复过来。例如，对于拥塞窗口大小为4地TCP流，如果其第二个数据包丢失，那么按传统 地做法需要等待超时重传。而在限制传输机制下，当源端收到对第三个数据包确认的ACK副本时（ACK中要求源端发送第二个数据包），继续发送新的数据包， 最终源端可以收到三个ACK副本从而触发快速重传，从而减少了不必要的超时重传。
2 针对乱序包和延迟包引起的重传

在不少情况下，TCP源端推断认为数据包被丢弃了，从而导致重传及拥塞窗口的减小，而实际上数据包并没有被丢弃。如果超时时钟过早地到时 了（事实上数据包或者ACK并没有丢失，只要能够再等待一会儿并可收到ACK），源端便毫无必要地重发了数据包，更严重的是拥塞窗口的减小，而实际上并没 有数据包被丢弃。类似地，如果由于数据包的乱序导致源端接收到3个ACK副本，便会导致快速重传，TCP源端也毫无必要地重发了数据包，并且减小了拥塞窗 口。对于前者，虽然可以通过更为精确地调节超时时钟来减少不必要地超时重传，但要完全避免却是不可能的。同样，对于后者，虽然可以通过提高快速重传算法的 性能来减少不必要的快速重传，但也不可能完全避免。

对于拥塞窗口较大的流，比如大小为W，不必要地减小拥塞窗口会导致其至少花费W/2 RTT时间恢复到原来拥塞窗口的大小，从而使其性能大大下降，特别是在数据包持续出现乱序或者对RTT的估算不很精确的情况下。持续乱序的数据包往往是由 于路由的改变或者链路层重传受损的数据包引起的。

为了使得在出现不必要的超时重传和快速重传情况下，TCP性能能够更加健壮（robust），一种方法就是在出现这些情况时向TCP源端 发送有关的信息。这个工作已经由D-SACK扩展（duplicate-SACK extension）完成了。D-SACK扩展允许TCP接受端在利用SACK选项来通报收到重复的数据包，从而TCP源端能够正确地推断出接受端是否收 到了重复地数据包。因此，D-SACK扩展使得TCP源端在重发后一个RTT时间内正确地推断出重发是否必要。如果源端认为重发是不必要的，那么拥塞窗口 减半也就没必要了，源端就会将拥塞窗口大小和慢启动阈值分别恢复到原来的值，这样拥塞窗口恢复到原来的大小只需1RTT时间而不是W/2 RTT时间了。

3一种新的拥塞控制机制XCP

针对目前基于窗口的TCP拥塞控制机制的不足，最近MIT的D.Katabi、C.Rohrs和UC Berkeley的M.Handley共同提出了一种新的互联网拥塞控制机制XCP（eXplicit Control Protocol）。XCP源端维持有拥塞窗口cwnd和回路响应时间RTT并且通过数据包中的拥塞头（congestion header）将这两个值与路由器进行通信。当XCP连接刚刚建立时，与TCP一样，初始cwnd较小，XCP将其理想的发送速率填入到拥塞头中，如果链 路带宽允许，则在一个RTT后就以次速率发送数据；如果链路带宽不足，则网络会给出一个发送速率，在一个RTT后源端就以此速率发送数据。

在随后的数据包传输过程中，根据数据流入速率和链路带宽之间的关系，路由器通知每个流是要增加还是减少拥塞窗口并将有关信息填入到拥塞头 中。如果在后面的传输过程中，有路由器拥塞更加严重，则该路由器将拥塞头中的有关信息改写。最终该数据包将获得传输过程中的瓶颈链路信息，并将传送给接收 端。接收端再将次信息写入到确认包中传送给源端，源端依此信息对拥塞窗口进行调整。通过将拥塞状态信息放入数据包中，XCP无需路由器维持每流状态信息， 扩展性较好。

与传统的TCP拥塞控制机制相比，XCP具有链路利用效率高、公平性好、可扩展性强、排队时延小的优点，并且路由器的开销也非常小。

TCP的版本：（区别：拥塞控制的方法不同）

       TCP Tahoe     TCP Reno      TCP NewReno     TCP Vegas   TCP Sack 等。
经过十多年的发展，目前TCP协议主要包含有四个版本：TCP Tahoe、TCP Reno、TCP NewReno和TCP SACK。TCP Tahoe是早期的TCP版本，它包括了3个最基本的拥塞控制算法－“慢启动”、“拥塞避免”和“快速重传”。TCP Reno在TCP Tahoe基础上增加了“快速恢复”算法。TCP NewReno对TCP Reno中的“快速恢复”算法进行了修正，它考虑了一个发送窗口内多个数据包丢失的情况。在Reno版中，发送端收到一个新的ACK后旧退出“快速恢复” 阶段，而在NewReno版中，只有当所有的数据包都被确认后才退出“快速恢复”阶段。TCP SACK关注的也是一个窗口内多个数据包丢失的情况，它避免了之前版本的TCP重传一个窗口内所有数据包的情况，包括那些已经被接收端正确接收的数据包， 而只是重传那些被丢弃的数据包。

另外，在1994年，L.S.Brakmo等提出了一种新的拥塞控制策略－TCP Vegas。由于RTT值与网络运行情况有密切关系，因此，TCP Vegas通过观察TCP连接中RTT值改变感知网络是否发生拥塞，从而控制拥塞窗口大小。如果发现RTT值变大，Vegas就认为网络正在发生拥塞，于 是开始减小拥塞窗口；另一方面，如果RTT变小，Vegas就认为网络拥塞正在解除，于是再次增加拥塞窗口。这样，拥塞窗口在理想情况下就会稳定在一个合 适的值上。TCP Vegas的最大优点在于拥塞机制的触发只与RTT的改变有关，而与包的具体传输时延无关。由于TCP Vegas不是利用丢包来判断网络可用带宽，而是以RTT的变化来判断，因此能更精确地预测网络的可利用带宽，其公平性、效率都较好。但TCP Vegas之所以未能在互联网上大规模使用，主要是因为使用TCP Vegas的流在带宽竞争能力方面不及未使用TCP Vegas的流，从而导致网络资源享用不公平，而不是算法本身的问题。

（1）概述：

      TCP/IP是目前使用最为广泛的一组通信协议；

      TCP所负责的功能包括：1）. 将来自应用程序的信息（数据）分割成报文段；2）. 提供面向连接的可靠服务；3）. 提供应用程序之间的流量控制；4）. 依照网络的状况提供拥塞控制。

      为了提供可靠的数据传输，TCP依赖于以下基本原理: 差错检测、 重传、 累计确认、 定时器以及用于序号和确认号的首部字段；

       TCP由RFC793、RFC1122、RFC1323、RFC2001、RFC2018以及RFC2581定义。 

      当应用程序需要通过网络传输数据时，为了和网络上其他的TCP联机公平地共享频宽比且避免造成网络拥塞， TCP通过拥塞控制机制来控制允许传送到网络上的数据量。因此， TCP的拥塞控制机制直接影响TCP的传输效率。

对TCP的感性初识：TCP工作在传输层（第四层通信协议）， 为应用程序提供可靠的传输服务，并且具有流量控制及拥塞控制的机制。 TCP使用拥塞控制窗口 （Congestion Window, wnd）以控制允许被传送到网络上的数据包数量。在数据传输之前，TCP会在传送端和接收端之间建立起一条网络连接， 将要被传送到网络上的信息会被分割成为一定大小的报文段，并且按数据包序号通过网络层所提供的服务一次传送出去！当正确收到一个数据包时，TCP的接收端会返回一个ACK给传送端，以表示该数据包已被接收到。 TCP传送端则通过接收到的ACK来确认之前所送出的数据包是否被接收！在整个传送的过程中，TCP进行拥塞控制，以避免因为发送端传送得太快而是网络发生拥塞！ （流量控制: 由接收端作用于发送端，避免发送端传送的太快而把接收端“淹没”！）

 

（2）TCP 拥塞控制的基本方法（Congestion Control Mechanisms of TCP）

     TCP的拥塞控制方法主要分为以下五阶段： Slow-start, Congestion Avoidance, Fast Retransmission, Fast Recovery, Timeout Retransmission. TCP利用ACK检测网络的状况并提供可靠性的服务，在调整传送端的传送速度时，则以Slow-start threshold (ssthresh) 与 Congestion Window （cwnd）的值来区分 Slow-start 或 Congestion-avoidance。

1986年初，Jacobson开发了现在在TCP应用中的拥塞控制机制。运行在端节点主机中的这些机制使得TCP连接在网络发生拥塞时回退（back off），也就是说TCP源端会对网络发出的拥塞指示（congestion notification）（例如丢包、重复的ACK等）作出响应。1988年Jacobson针对TCP在控制网络拥塞方面的不足，提出了“慢启动” （Slow Start）和“拥塞避免”（Congestion Avoidance）算法。1990年出现的TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过大地减小发送窗口尺寸的现象，这样TCP的拥塞控制就由这4个核心部分组成。 近几年又出现TCP的改进版本如NewReno和选择性应答（selective acknowledgement，SACK）等。正是这些拥塞控制机制防止了今天网络的拥塞崩溃。

1. 慢启动阶段：早期开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样很容易导致路由器缓存空间耗尽，网络发生拥塞，使得TCP连 接的吞吐量急剧下降。由于TCP源端无法知道网络资源当前的利用状况，因此新建立的TCP连接不能一开始就发送大量数据，而只能逐步增加每次发送的数据 量，以避免上述现象的发生。具体地说，当建立新的TCP连接时，拥塞窗口（congestion window，cwnd）初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量，这样cwnd就 将随着回路响应时间（Round Trip Time，RTT）呈指数增长，源端向网络发送的数据量将急剧增加。事实上，慢启动一点也不慢，要达到每RTT发送W个数据包所需时间仅为 RTT×logW。由于在发生拥塞时，拥塞窗口会减半或降到1，因此慢启动确保了源端的发送速率最多是链路带宽的两倍。
2. 拥塞避免阶段：如果TCP源端发现超时或收到3个相同ACK副本时，即认为网络发生了拥塞（主要因为由传输引起的数据 包损坏和丢失的概率很小（<<1%））。此时就进入拥塞避免阶段。慢启动阈值（ssthresh）被设置为当前拥塞窗口大小的一半；如果超 时，拥塞窗口被置1。如果cwnd>ssthresh，TCP就执行拥塞避免算法，此时，cwnd在每次收到一个ACK时只增加1/cwnd个数据 包，这样，在一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd不是呈指数增长，而是线性增长。
3. 快速重传和快速恢复阶段：快速重传是当TCP源端收到到三个相同的ACK副本时，即认为有数据包丢失，则源端重传丢失 的数据包，而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半，并且将cwnd减为原先的一半。快速恢复是基于“管道”模型 （pipe model）的“数据包守恒”的原则（conservation of packets principle），即同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网络。如果发送方收到一个 重复的ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。如果“数据包守恒”原则能够得到严格遵守，那么网络中将很少会发生拥塞；本质上， 拥塞控制的目的就是找到违反该原则的地方并进行修正。

影响TCP效果的因素：
（1）RTT(Round-Trip Times)
（2）Timer Granularity
（3）Slow-start Threshold
其他的影响因素包括传送的封包大小、网络的队列管理机制、网络是否对TCP提供支持、有线或无线的环境等。