tcp性能及拥塞控制研究论文

在计算机网络中的链路容量（即带宽）、交换节点（如路由器）中的缓存和处理机等，都是网络的资源。在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，从而导致吞吐量将随着输入负荷增大而降低。这种情况就叫做 拥塞 。通俗来说，就跟交通拥堵性质一样。

网络拥塞的原因有很多，如交换节点的 缓存容量太小、输出链路的容量和处理机的速度 。

拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致于过载 。拥塞控制是一个 全局性的过程 。涉及网络中所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

拥塞控制和流量控制的关系密切，但是 流量控制往往是指点对点的通信量控制 ，是个 端对端 的问题。流量控制所要做的就是抑制发送方发送数据的速率，以便使接收端来得及接收。

TCP进行拥塞控制的算法有四种，即 慢开始（slow-start）、拥塞避免（congestion-avoidance）、快重传（fast retransmit）、快恢复（fast recovery） 。

为了讨论问题方便，提出以下假定：

拥塞控制也叫做 基于窗口 的拥塞控制。为此，发送方维持一个叫作 拥塞窗口cwnd （congestion window）的状态变量。 拥塞窗口的大小取决于网络的用谁程度，并且动态的变化。发送方让自己的发送窗口等于拥塞窗口 。

接收方窗口值rwnd和拥塞窗口值cwnd的区别：

发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再扩大一些，以便让更多的分组发送出去，如果网络出现了拥塞，就必须将拥塞窗口减小一些，以减少分组的发送。 判断网络拥塞的依据就是出现了超时 。

慢开始算法的思路：刚开始发送数据时，不一下向网络中注入大量数据，而是先探测一下，即 由小到大逐渐增大发送窗口 ，也就是说， 由小到大逐渐增大拥塞窗口数值 。

慢开始算法具体规定：刚开始发送数据时，先把拥塞窗口cwnd根据 发送方的最大报文段SMSS （Sender Maximum Segment Size）数值的大小设置为不超过2-4个SMSS的数值。在 每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值 。用这样的方法逐步增大发送方的拥塞窗口rwnd，可以使分组注入到网络中的速率更加合理。

下面举例说明一下，虽然实际上TCP是用字节数作为窗口大小的单位，但为了方便描述，下面使用报文段的个数来作为窗口的大小的单位，并且假设所有的报文段大小相等。

所以， 慢开始算法每经过一个传输轮次（transmission round），拥塞窗口cwnd就加倍 。

注：在TCP实际运行时，发送方只有收到一个确认就可以将cwnd加1并发送新的分组，并不需要等一个轮次所有的确认都收到后再发送新的分组。

从上面可以看出，慢开始算法虽然起始的窗口很小，但是每过一个轮次，窗口大小翻倍，呈指数爆炸增长，所以必须要对其进行一个限制，防止其增长过大引起网络拥塞。这个限制就是 慢开始门限ssthresh 状态变量。慢开始门限ssthresh的用法如下：

拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有 “加法增大”AI （Additive Increase）的特点。这表明在拥塞避免阶段，拥塞窗口cwnd 按线性规律增长 ，比慢开始算法的拥塞窗口增长速率缓慢得多。

下面用一个具体的例子来说明拥塞控制的过程，下图假设TCP发送窗口等于拥塞窗口，慢开始初始门限设置为16个报文段，即ssthresh = 16。

在拥塞避免阶段，拥塞窗口是按照线性规律增大的，这常称为 加法增大AI 。无论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前拥塞窗口的一半，这叫做 乘法减小 MD （Multiplication Decrease）。

当网络频繁出现拥塞时，ssthresh 值就下降的很快，以大大减少注入网络中的分组数。

快恢复算法 ，如果发送方连续接收到3个冗余ACK，发送方知道现在只是丢失了个别的报文段，此时调整门限值 ssthresh为当前拥塞窗口的一半，同时设置拥塞窗口 cwnd为新的门限值（发生报文段丢失时拥塞窗口的一半），而不是从1开始。

TCP对这种丢包事件的行为，相比于超时指示的丢包，不那么剧烈 ，所以对于连续收到3个冗余ACK，拥塞窗口不会从1开始开始。

上文 浅谈TCP（1）：状态机与重传机制 介绍了TCP的状态机与重传机制。本文介绍 流量控制 （Flow Control，简称流控）与 拥塞控制 （Congestion Control）。TCP依此保障网络的 QOS （Quality of Service）。

根据前文对TCP超时重传机制的介绍，我们知道Timeout的设置对于重传非常重要：

而且，这个超时时间在不同的网络环境下不同，必须动态设置。为此，TCP引入了 RTT （Round Trip Time，环回时间）：一个数据包从发出去到回来的时间。这样，发送端就大约知道正常传输需要多少时间，据此计算 RTO （Retransmission TimeOut，超时重传时间）。 听起来似乎很简单：在发送方发包时记下t0，收到接收方的Ack时记一个t1，于是RTT = t1 – t0。然而，这只是一个采样，不能代表网络环境的普遍情况。

RFC793 中定义了一个 经典算法 ：

经典算法描述了RTO计算的基本思路，但还有一个重要问题：RTT的采样取“ 第一次 发Seq+收Ack的时间”，还是“ 重传 Seq+收Ack的时间”？

如图：

问题的本质是： 发送方无法区分收到的Ack对应第一次发的Seq还是重传的Seq （进入网络就都一样了）。针对该问题， Karn / Partridge 算法选择回避重传的问题： 忽略重传的样本，RTT的采样只取未产生重传的样本 。

简单的忽略重传样本也有问题：假设当前的RTO很小，突然发生网络抖动，延时剧增导致要重传所有的包；由于忽略重传样本，RTO不会被更新，于是继续重传使网络更加拥堵；拥堵导致更多的重传，恶性循环直至网络瘫痪。Karn / Partridge算法用了一个取巧的办法： 只要一发生重传，就将现有的RTO值翻倍（指数回退策略），待网络恢复后再仿照经典算法逐渐平滑以降低RTO 。

该算法已经做到可用，然而网络抖动对性能的影响比较大。

前面两种算法均使用加权移动平均算法做平滑，这种方法的最大问题是：很难发现RTT值上的较大波动，因为被平滑掉了（1 - a比较小，即最新RTT的权重小）。针对该问题， Jacobson / Karels 算法引入了最新采样的RTT值和平滑过的SRTT值的差距做因子，即 DevRTT （Deviation RTT，RTT的偏离度），同时考虑SRTT带来的惯性和DevRTT带来的波动：

Linux 采用该算法计算RTO，默认取α = , β = , μ = 1, ∂ = 4（玄学调参，你懂的）。

TCP使用 滑动窗口 （Sliding Window）做流量控制与 乱序重排 。乱序重排在TCP的重传机制中已经介绍，下面介绍流量控制。

TCP头里有一个字段叫Window（或Advertised Window）， 用于接收方通知发送方自己还有多少缓冲区可以接收数据 。 发送方根据接收方的处理能力来发送数据，不会导致接收方处理不过来，是谓流量控制 。暂且把Advertised Window当做滑动窗口，更容易理解滑动窗口如何完成流量控制，后面介绍拥塞控制时再说明二者的区别。

观察TCP协议的发送缓冲区和接收缓冲区：

假设位置序号从左向右增长（常见的读、写缓冲区设计），解释一下：

据此在接收方计算 AdvertisedWindow ，在发送方计算 EffectiveWindow ：

AdvertisedWindow衡量接收方还能接收的数据量，发送方要根据AdvertisedWindow决定接下来发送的数据量上限，即EffectiveWindow（可能为0）。

由于乱序问题的存在，LastByteRcvd可能指向Seq(LastByteSent)，而Seq(LastByteAcked + 1)至Seq(LastByteSent - 1)都还在路上 ，即将到达接收方，最好的情况是不丢包（丢包后会重传）， 则LastByteRcvd之后、接收缓冲区边界之前的空间就是发送方下一次发送数据的长度上限 （重传不属于下一次发送），因此， AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead) 。

LastByteRcvd还可能指向Seq(LastByteAcked)（一个新包都没有收到） ，显然AdvertisedWindow的公式不变， 而Seq(LastByteAcked + 1)至Seq(LastByteSent)都还在路上 ，未来将到达接收方，进入接收缓冲区，则“还在路上的Seq(LastByteAcked + 1)至Seq(LastByteSent)”不应超过接收缓冲区的剩余空间AdvertisedWindow（目前等于MaxRcvBuffer），这要求的是上一次发送满足LastByteSent - LastByteAcked ≤ AdvertisedWindow， 那么LastByteSent之后、接收缓冲区剩余空间边界之前的空间就是发送方窗口内剩余可发送数据的长度上限 ，因此， EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) 。

以下是一个发送缓冲区的滑动窗口：

上图分为4个部分：

其中， #2 + #3 组成了滑动窗口，总大小不超过AdvertisedWindow，二者比例受到接收方的处理速度与网络情况的影响（如果丢包严重或处理速度慢于发送速度，则 #2:#3 会越来越大）。

以下是一个AdvertisedWindow的调整过程，EffectiveWindow随之变化：

上图，我们可以看到一个处理缓慢的Server（接收端）是怎么把Client（发送端）的发送窗口size给降成0的。对于接收方来说，此时接收缓冲区确实已经满了，因此令发送方的发送窗口size降为0以暂时禁止发送是合理的。那么，等接收方的接收缓冲区再空出来，怎么通知发送方新的window size呢？

针对这个问题，为TCP设计了ZWP技术（Zero Window Probe，零窗通告）：发送方在窗口变成0后，会发ZWP的包给接收方，让接收方来Ack他的Window尺寸；ZWP的重传也遵循指数回退策略，默认重试3次；如果3次后window size还是0，则认为接收方出现异常，发RST重置连接（ 部分文章写的是重试到window size正常？？？ ）。

注意：只要有等待的地方都可能出现DDoS攻击，Zero Window也不例外。一些攻击者会在和服务端建好连接发完GET请求后，就把Window设置为0，于是服务端就只能等待进行ZWP；然后攻击者再大量并发发送ZWP，把服务器端的资源耗尽。（ 客户端等待怎么耗服务端？？？ ）

为什么要进行拥塞控制？假设网络已经出现拥塞，如果不处理拥塞，那么延时增加，出现更多丢包，触发发送方重传数据，加剧拥塞情况，继续恶性循环直至网络瘫痪。可知，拥塞控制与流量控制的适应场景和目的均不同。

拥塞发生前，可避免流量过快增长拖垮网络；拥塞发生时，唯一的选择就是降低流量 。主要使用4种算法完成拥塞控制：

算法1、2适用于拥塞发生前，算法3适用于拥塞发生时，算法4适用于拥塞解决后（相当于拥塞发生前）。

在正式介绍上述算法之前，先补充下 rwnd （Receiver Window，接收者窗口）与 cwnd （Congestion Window，拥塞窗口）的概念：

介绍流量控制时，我们没有考虑cwnd，认为发送方的滑动窗口最大即为rwnd。实际上， 需要同时考虑流量控制与拥塞处理，则发送方窗口的大小不超过 min{rwnd, cwnd} 。下述4种拥塞控制算法只涉及对cwnd的调整，同介绍流量控制时一样，暂且不考虑rwnd，假定滑动窗口最大为cwnd；但读者应明确rwnd、cwnd与发送方窗口大小的关系。

慢启动算法 （Slow Start）作用在拥塞产生之前： 对于刚刚加入网络的连接，要一点一点的提速，不要妄图一步到位 。如下：

因此，如果网速很快的话，Ack返回快，RTT短，那么，这个慢启动就一点也不慢。下图说明了这个过程：

前面说过，当cwnd >= ssthresh（通常ssthresh = 65535）时，就会进入 拥塞避免算法 （Congestion Avoidance）： 缓慢增长，小心翼翼的找到最优值 。如下：

慢启动算法主要呈指数增长，粗犷型，速度快（“慢”是相对于一步到位而言的）；而拥塞避免算法主要呈线性增长，精细型，速度慢，但更容易在不导致拥塞的情况下，找到网络环境的cwnd最优值。

慢启动与拥塞避免算法作用在拥塞发生前，采取不同的策略增大cwnd；如果已经发生拥塞，则需要采取策略减小cwnd。那么，TCP如何判断当前网络拥塞了呢？很简单， 如果发送方发现有Seq发送失败（表现为“丢包”），就认为网络拥塞了 。

丢包后，有两种重传方式，对应不同的网络情况，也就对应着两种拥塞发生时的控制算法：

可以看到，不管是哪种重传方式，ssthresh都会变成cwnd的一半，仍然是 指数回退，待拥塞消失后再逐渐增长回到新的最优值 ，总体上在最优值（动态）附近震荡。

回退后，根据不同的网络情况，可以选择不同的恢复算法。慢启动已经介绍过了，下面介绍快速恢复算法。

如果触发了快速重传，即发送方收到至少3次相同的Ack，那么TCP认为网络情况不那么糟，也就没必要提心吊胆的，可以适当大胆的恢复。为此设计 快速恢复算法 （Fast Recovery），下面介绍TCP Reno中的实现。

回顾一下，进入快速恢复之前，cwnd和sshthresh已被更新：

然后，进入快速恢复算法：

下面看一个简单的图示，感受拥塞控制过程中的cwnd变化：