TCP拥塞控制

发布网友 发布时间：2022-05-01 10:25

我来回答

共3个回答

懂视网 时间：2022-04-15 03:02

解决传统TCP缺陷： 1、窗口太小，最大65535。 TCP利用了选项功能，其头部存在预留项，用于扩展等用途。窗口扩大选项增加了额外的16位来表示窗口大小，窗口的由首部的16位大小和选项的16位共同组成。 不过不是用加法组成的，而是利用 移位窗口的幂 来表示的，

解决传统TCP缺陷：

1、窗口太小，最大65535。

TCP利用了选项功能，其头部存在预留项，用于扩展等用途。窗口扩大选项增加了额外的16位来表示窗口大小，窗口的值由首部的16位大小和选项的16位值共同组成。

不过不是用加法组成的，而是利用移位窗口值的幂来表示的，也就是说如果移位窗口值为 10，那么窗口的最大值就是65535*210，这个值就比较大了，足够表示窗口的大小了。

2、数据包丢失，即认定为网络出现了拥塞

在高速网络中，这种假设是不成立的。如果笼统地认为分组丢失就是拥塞所引起的，从而降低一半的速率，这是对网络资源的极大浪费。拥塞的判断需要两个连续的分组丢失。

于是乎，就有了HSTCP和BI-TCP等一系列拥塞控制方法。

HSTCP

High-Speed TCP是由Floyd提出，基于AIMD准则的一种新的拥塞控制算法，能在高速度和大时延的网络中更有效地提高网络的吞吐率。它通过对标准TCP拥塞避免算法的增加和减少参数进行修改，从而实现了窗口的快速增长和慢速减少，但是它存在严重的RTT不公平性。

HSTCP提出的窗口增加和减小方法，先看拥塞控制中的两个公式：

cwnd = cwnd+a(cwnd)/cwnd ............................ （1)

cwnd = (1-b(cwnd)) * cwnd ............................ (2)

式 (1)是拥塞避免时的窗口增长方式，式(2)是发生了丢包后的窗口下降方式，其中a，b为两个函数，cwnd为其自变量，在标准TCP中a(cwnd)=1，b(cwnd)=0.5，也就是加法增大，乘法减小。

为了达到TCP的友好性，在窗口较低的情况下，也就是说非BDP的网络环境下，HSTCP采用的是和标准TCP相同的a和b，也就是一样的方式来保证两者之间的友好性。当BDP大时，也就是w较大时(HSTCP设定的临界值为38)，采取新的a和b来达到高吞吐的要求：

根据不同的网络环境下使用不同的TCP窗口增长和降低参数，具体可以看RFC3649文档。

BIC-TCP

HSTCP，它通过简单的修改标准TCP的增长方式，从而达到了高吞吐。方法很简单，但是缺点在于，它存在严重的RTT不公平性. 公平性指共享同一网络瓶颈的多个流之间占有的网络资源相等。

BIC-TCP由North Carolina State University的网络研究实验室提出，该算法在提出不久后就成为了当时Linux内核中的TCP默认拥塞算法，使用非常广泛.（是linux采用cubic之前的默认算法）

BIC-TCP的本质：

BIC- TCP的提出者们发现了TCP拥塞窗口调整的一个本质：那就是找到最适合当前网络的一个发送窗口，为了找到这个窗口值，TCP采取的方式是(拥塞避免阶 段)每RTT加1，缓慢上升，丢包时下降一半，接着再来慢慢上升。BIC-TCP的提出者们看穿了事情的本质，其实这就是一个搜索的过程，而TCP的搜索方式类似于逐个遍历搜索方法，可以认为这个值是在1和一个比较大的数(large_window)之间，既然在这个区间内需要搜索一个最佳值，那么显然最好的方式就是二分搜索思想。

BIC- TCP就是基于这样一个二分思想的：当出现丢包的时候，说明最佳窗口值应该比这个值小，那么BIC就把此时的cwnd设置为max_win，把乘法减小后 的值设置为min_win，然后BIC就开始在这两者之间执行二分思想--每次跳到max_win和min_win的中点。

具体实现还有其他问题，比如防止传输的抖动，因而BIC-TCP选取了另外取了两个参考值Smax和Smin。BIC-TCP的具体实现可以参考内核代码/net/ipv4/tcp_bictcp.c

CUBIC

BIC-TCP的缺点：首先就是抢占性较强，它在探测阶段相当于是重新启动一个慢启动算法，而TCP在处于稳定后窗口就是一直是线性增长的，不会再次执行慢启动的过程。其次，BIC-TCP的窗口控制阶段增加了算法上的实现和性能分析复杂度。

CUBIC在设计上简化了BIC-TCP的窗口调整算法，CUBIC使用一个立方函数取代BIC-TCP的增长曲线。来看下具体细节：当某次拥塞事件发生时，Wmax设置为此时发生拥塞时的窗口值，然后把窗口进行乘法减小，乘法减小因子设为β， 当从快速恢复阶段退出然后进入到拥塞避免阶段，此时CUBIC的窗口增长开始按照“凹”式增长曲线进行增长，该过程一直持续直到窗口再次增长到Wmax， 紧接着，该函数转入“凸”式增长阶段。该方式的增长可以使得窗口一直维持在Wmax附近，从而可以达到网络带宽的高利用率和协议本身的稳定性。

鉴于CUBIC比BIC-TCP更出色的表现，在Linux2.6.18版本后，CUBIC取代了BIC-TCP，内核代码请参考/net/ipv4/tcp_Cubic.c。

TCP拥塞的优化算法还有N多多，比如

Fast TCP：从TCP vegas的思想发展而来，利用网络延时进行拥塞判断。

ECN：显式拥塞通知，该算法的思想是想借助路由器。路由器在发现有拥塞现象时在连接的TCP或者IP头里面打上拥塞的标记，让终端自己去根据标记进行处理。

UDT：UDT是一个开源的基于UDP实现的可靠传输协议，但是在UDT的拥塞算法与UDP或TCP没有关系，UDT采用的是一种带宽估计的算法。发送端的拥塞算法就是把拥塞窗口利用一个函数无限逼近于带宽值，这种思想对于传输的稳定性非常好，因为是一个无限逼近，所以永远不会超过带宽的值，而不是像TCP一样在平衡状态后继续一直往上增大窗口，从而在平衡状态能够维持比较久。

完成一个TCP的可用版本很容易，要实现一个高性能版本需要考虑的因素就多了去了。

不同环境：局域网、异构网、卫星网等等，每种网络的要求千差万别。

不同应用：有一直只发送小包(发送的包长度小于MSS)的应用，也有不停的发送大包的应用，还有两边同时发送和接收数据的应用。

传输效率，公平性，平稳性等等

参考;http://www.cnblogs.com/fll/archive/2011/11/15/2250437.html

热心网友 时间：2022-04-15 00:10

以下资料参考：为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制。最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion avoidance)”组成，后来TCP Reno版本中又针对性的加入了“快速重传(Fast retransmit)”、“快速恢复(Fast Recovery)”算法，再后来在TCP NewReno中又对“快速恢复”算法进行了改进，近些年又出现了选择性应答( selective acknowledgement,SACK)算法，还有其他方面的大大小小的改进，成为网络研究的一个热点。TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制，在之前我们还讨论过TCP还有一个对端通告的接收窗口(rwnd)用于流量控制。窗口值的大小就代表能够发送出去的但还没有收到ACK的最大数据报文段，显然窗口越大那么数据发送的速度也就越快，但是也有越可能使得网络出现拥塞，如果窗口值为1，那么就简化为一个停等协议，每发送一个数据，都要等到对方的确认才能发送第二个数据包，显然数据传输效率低下。TCP的拥塞控制算法就是要在这两者之间权衡，选取最好的cwnd值，从而使得网络吞吐量最大化且不产生拥塞。由于需要考虑拥塞控制和流量控制两个方面的内容，因此TCP的真正的发送窗口=min(rwnd, cwnd)。但是rwnd是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑rwnd的值，我们暂时只讨论如何确定cwnd值的大小。关于cwnd的单位，在TCP中是以字节来做单位的，我们假设TCP每次传输都是按照MSS大小来发送数据的，因此你可以认为cwnd按照数据包个数来做单位也可以理解，所以有时我们说cwnd增加1也就是相当于字节数增加1个MSS大小。慢启动：最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。具体来说，当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(Round Trip Time,RTT)呈指数级增长，事实上，慢启动的速度一点也不慢，只是它的起点比较低一点而已。我们可以简单计算下： 开始 ---> cwnd = 1 经过1个RTT后 ---> cwnd = 2*1 = 2 经过2个RTT后 ---> cwnd = 2*2= 4 经过3个RTT后 ---> cwnd = 4*2 = 8如果带宽为W，那么经过RTT*log2W时间就可以占满带宽。拥塞避免：从慢启动可以看到，cwnd可以很快的增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个*。TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。上面讨论的两个机制都是没有检测到拥塞的情况下的行为，那么当发现拥塞了cwnd又该怎样去调整呢？首先来看TCP是如何确定网络进入了拥塞状态的，TCP认为网络拥塞的主要依据是它重传了一个报文段。上面提到过，TCP对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：1.把ssthresh降低为cwnd值的一半2.把cwnd重新设置为13.重新进入慢启动过程。从整体上来讲，TCP拥塞控制窗口变化的原则是AIMD原则，即加法增大、乘法减小。可以看出TCP的该原则可以较好地保证流之间的公平性，因为一旦出现丢包，那么立即减半退避，可以给其他新建的流留有足够的空间，从而保证整个的公平性。其实TCP还有一种情况会进行重传：那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传，快速重传做的事情有：1.把ssthresh设置为cwnd的一半2.把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)3.重新进入拥塞避免阶段。后来的“快速恢复”算法是在上述的“快速重传”算法后添加的，当收到3个重复ACK时，TCP最后进入的不是拥塞避免阶段，而是快速恢复阶段。快速重传和快速恢复算法一般同时使用。快速恢复的思想是“数据包守恒”原则，即同一个时刻在网络中的数据包数量是恒定的，只有当“老”数据包离开了网络后，才能向网络中发送一个“新”的数据包，如果发送方收到一个重复的ACK，那么根据TCP的ACK机制就表明有一个数据包离开了网络，于是cwnd加1。如果能够严格按照该原则那么网络中很少会发生拥塞，事实上拥塞控制的目的也就在修正违反该原则的地方。具体来说快速恢复的主要步骤是：1.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络。 2.再收到重复的ACK时，拥塞窗口增加1。3.当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。快速重传算法首次出现在4.3BSD的Tahoe版本，快速恢复首次出现在4.3BSD的Reno版本，也称之为Reno版的TCP拥塞控制算法。可以看出Reno的快速重传算法是针对一个包的重传情况的，然而在实际中，一个重传超时可能导致许多的数据包的重传，因此当多个数据包从一个数据窗口中丢失时并且触发快速重传和快速恢复算法时，问题就产生了。因此NewReno出现了，它在Reno快速恢复的基础上稍加了修改，可以恢复一个窗口内多个包丢失的情况。具体来讲就是：Reno在收到一个新的数据的ACK时就退出了快速恢复状态了，而NewReno需要收到该窗口内所有数据包的确认后才会退出快速恢复状态，从而更一步提高吞吐量。SACK就是改变TCP的确认机制，最初的TCP只确认当前已连续收到的数据，SACK则把乱序等信息会全部告诉对方，从而减少数据发送方重传的盲目性。比如说序号1，2，3，5，7的数据收到了，那么普通的ACK只会确认序列号4，而SACK会把当前的5，7已经收到的信息在SACK选项里面告知对端，从而提高性能，当使用SACK的时候，NewReno算法可以不使用，因为SACK本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包，而不需要重传哪些包。

热心网友 时间：2022-04-15 01:28

TCP拥塞控制主要有三个问题：1.一个TCP发送方是如何控制它向其连接发送流量的速率；2.一个TCP发送方是如何感知从它到目的地之间的路径上存在拥塞；3.当发送方感知拥塞时利用什么策略（算法）来改变其发送速率。以TCP Reno拥塞控制算法来研究TCP拥塞控制：首先解决第一个问题，TCP连接的每一端都由一个接受缓存，一个发送缓存和几个变量组成，TCP拥塞控制机制让连接的每一端都记录一个额外的变量，即拥塞窗口，表示为CongWin。第二个问题：定义一个TCP发送“丢包事件”为：出现超时，或者收到来自接收方的3个冗余ACK。当拥塞发生时，会触发丢包事件。第三个问题：控制算法，这个是重点。1.加性增，乘性减；2.慢启动；3.对超时事件作出反应。