计算机系统（七）：运输层（特别篇）——TCP拥塞控制

目录

7.5 TCP滑动窗口与拥塞控制

7.6 TCP拥塞控制 

7.6.1 慢启动

7.6.2 拥塞避免

7.6.3 快速恢复——拥塞控制优化

7.6.4 进一步优化 

7.7 拥塞控制补充

7.7.1 宏观模型 

7.7.2 窗口大小

7.7.3 Rate, fairness

---

7.5 TCP滑动窗口与拥塞控制

我们假设一个场景，发送方发送了滑动窗口内的所有段，但是段21在传输过程中丢失；31最先到达，被接收方顺利接收；41，51，61随后到达，未在一个RTT内被接收方接收。

此时接收方会发送并将接收窗口剩余的大小发送给接收方，即。

随后，段41和51逐步到达：

由于在定时器时间内发生了三次冗余的接收（没有收到21，但31，41和51都已收到）。会立刻触发快速重传：。

---

原始数据流+丢包控制

 在单一的点对点链路上已经存在了很长时间。TCP最初借鉴了链路层拥塞控制的经验，但这导致了一些不好的设计决定。

---

两种类型的流量控制

Go-back-N（回退N步）
当一个数据包丢失时，回到它被传送的地方，并（重新）传送从该点开始的所有内容。
优势：接收者不需要存储/重新排序数据包。

Selective Repeat（选择性重传）

只重传丢失的数据包。
数据包不按顺序到达。接收者必须存储失序的数据包，以便将其按顺序发送给应用程序。 

更复杂，只有在数据包损失比较普遍的时候才有帮助。但是由于链路层对错误是有修复的，数据包损失并不普遍。

---

继续上面的滑动窗口情景，当快速重传发生时：

此时，相当于一个死锁：

• 发送方不会再发送任何数据（窗口大小为0）。
• 接收方不会收到任何数据，所以发送方不会发送任何ACK来增加窗口。

随后通过接收方滑动窗口内的段被上传给应用程序解除死锁状态：

接收者可以通过发送WindowUpdate来启动更新：

---

发送者可以通过发送一个ZeroWindowProbe来监控和启动更新： 

收到0大小的窗口时，发送方：

• 启动持久化定时器
• 持久计时器将定期发送ZeroWindowProbe段

7.6 TCP拥塞控制 

TCP所采用的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。如果一个TCP发送方感知从它到目的地之间的路径上没什么拥塞，则TCP发送方增加其发送速率；如果发送方感知沿着该路径有拥塞，则发送方就会降低其发送速率。

但是这种方法提出了三个问题：

• 一个TCP发送方如何限制它向其连接发送流量的速率呢？
• 一个TCP发送方如何感知从它到目的地之间的路径上存在拥塞呢？
• 当发送方感知到端到端的拥塞时，采用何种算法来改变其发送速率呢？

---

TCP发送方是如何限制向其连接发送流量的：

TCP连接的每一端都是由一个接收缓存、一个发送缓存和几个变量（LastByteRead、RWND等）组成。运行在发送方的TCP拥塞控制机制跟踪一个额外的变量，即拥塞窗口（congestion window）。拥塞窗口表示为CWND，它对一个TCP发送方能向网络中发送流量的速率进行了限制。特别是，在一个发送方中未被确认的数据量不会超过CWND与RWND中的最小值，即

拥塞窗口

额外的窗口是根据网络性能动态调整的，以帮助高效传输。   

滑动窗口由接收方控制，而拥塞窗口的大小由发送方维护。

并且拥塞窗口只在发送方使用。

拥塞窗口发送额外的字段不改变数据包格式，这曾经是一个重要的考虑，但现在是一个很大的问题。

为了关注拥塞控制（与流量控制形成对比），我们后面假设TCP接收缓存足够大，以至可以忽略接收窗口的限制；因此在发送方中未被确认的数据量仅受限于EWND。我们还假设发送方总是有数据要发送，即在拥塞窗口中的所有报文段要被发送。

上面的约束限制了发送方中未被确认的数据量，因此间接地限制了发送方的发送速率。为了理解这一点，我们来考虑一个丢包和发送时延均可以忽略不计的连接。因此粗略地讲，在每个往返时间（ RTT）的起始点，上面的限制条件允许发送方向该连接发送CWND个字节的数据，在该RTT结束时发送方接收对数据的确认报文。因此，该发送方的发送速率大概是CWND/RTT字节/秒。通过调节CWND的值，发送方因此能调整它向连接方发送数据的速率。

---

TCP发送方是如何感知在它与目的地之间的路径上出现了拥塞的：

“丢包事件” == 拥塞指示

当出现过度的拥塞时，在沿着这条路径，上的一台（或多台）路由器的缓存会溢出，引起一个数据报（包含一个TCP报文段）被丢弃。丢弃的数据报接着会引起发送方的“丢包事件”。

TCP发送方的“丢包事件”定义

• 出现超时。
• 收到来自接收方的3个冗余ACK。

所有报文段的确认ACK==一切正常

当没有出现丟包事件的情况。在此情况下，在TCP的发送方将收到对于以前未确认报文段的确认。如我们将看到的那样，TCP 将这些确认的到达作为一切正常的指示，即在网络上传输的报文段正被成功地交付给目的地，并使用确认来增加窗口的长度（及其传输速率）。

使用确认增加窗口长度的速率：

注意到如果确认以相当慢的速率到达（例如，如果该端到端路径具有高时延或包含一段低带宽链路），则该拥塞窗口将以相当慢的速率增加。在另一方面，如果确认以高速率到达，则该拥塞窗口将会更为迅速地增大。因为TCP使用确认来触发（或计时）增大它的拥塞窗口长度, TCP被说成是自计时（self-clocking）的。

通过调节CWND值控制发送速率的问题：

TCP发送方怎样确定它应当发送的速率呢？如果众多TCP发送方总体上发送太快，会导致拥塞崩溃。然而，如果TCP发送方过于谨慎，发送太慢，它们不能充分利用网络的带宽。

那么TCP发送方如何确定它们的发送速率，既使得网络不会拥塞，与此同时又能充分利用所有可用的带宽？TCP发送方是显式地协作，或存在一种分布式方法使TCP发送方能够仅基于本地信息设置它们的发送速率？TCP使用下列指导性原则回答这些问题：

• 一个丢失的报文段表意味着拥塞，因此当丢失报文段时应当降低TCP发送方的速率。
• 一个确认报文段指示该网络正在向接收方交付发送方的报文段，因此，当对先前未确认报文段的确认到达时，能够增加发送方的速率。
• 带宽探测。给定ACK指示源到目的地路径无拥塞，而丢包事件指示路径拥塞，TCP调节其传输速率的策略是增加其速率以响应到达的ACK，除非出现丢包事件，此时才减小传输速率。因此，为探测拥塞开始出现的速率，TCP发送方增加它的传输速率，从该速率后退，进而再次开始探测，看看拥塞开始速率是否发生了变化。注意到网络中没有明确的拥塞状态信令，即ACK和丢包事件充当了隐式信号，并且每个TCP发送方根据异步于其他TCP发送方的本地信息而行动。

递增的拥塞控制

起初，CWND的最大分段大小

• 发送方发送1个网段

对于每个被确认的网段

• 
• 发送方再传输2个段

每一个完整的确认窗口都会使拥塞窗口增加一倍——它一直增长到

• 超时
• 它达到一个阈值，

概述了TCP拥塞控制后，现在是我们考虑广受赞誉的TCP拥塞控制算法细节的时候了。该算法包括3个主要部分：①慢启动;②拥塞避免;③快速恢复。
慢启动和拥塞避免是TCP的强制部分，两者的差异在于对收到的ACK做出反应时增加CWND长度的方式。我们很快将会看到慢启动比拥塞避免能更快地增加CWND的长度。

7.6.1 慢启动

当一条TCP连接开始时，EWND的值通常初始置为一个MSS的较小值，这就使得初始发送速率大约为。由于对TCP发送方而言，可用带宽可能比MSS/RTT大得多，TCP发送方希望迅速找到可用带宽的数量。因此，在慢启动（slow-start）状态，CWND的值以1个MSS开始并且每当传输的报文段首次被确认就增加1个MSS。在下图所示的例子中：

TCP向网络发送第一个报文段并等待一个确认。当该确认到达时，TCP发送方将拥塞窗口增加一个MSS，并发送出两个最大长度的报文段。这两个报文段被确认，则发送方对每个确认报文段将拥塞窗口增加一个MSS，使得拥塞窗口变为4个MSS，并这样下去。这一过程每过一个RTT，发送速率就翻番。因此，TCP发送速率起始慢，但在慢启动阶段以指数增长。

---

但是，何时结束这种指数增长呢？

慢启动对这个问题提供了几种答案。首先，如果存在一个由超时指示的丢包事件（即拥塞），TCP发送方将CWND设置为1并重新开始慢启动过程。它还将第二个状态变量的值ssthresh（“慢启动阈值”的速记）设置为，即当检测到拥塞时将ssthresh置为拥塞窗口值的一半。慢启动结束的第二种方式是直接与ssthresh的值相关联。因为当检测到拥塞时ssthresh设为CWND的值一半，当到达或超过ssthresh的值时，继续使CWND翻番可能有些鲁莽。因此，当CWND的值等于ssthresh时，结束慢启动并且TCP转移到拥塞避免模式。我们将会看到，当进人拥塞避免模式时，TCP更为谨慎地增加CWND。最后一种结束慢启动的方式是，如果检测到3个冗余ACK，这时TCP执行一种快速重传，并进入快速恢复状态。慢启动中的TCP行为总结在下图中的TCP拥塞控制的FSM描述中：

7.6.2 拥塞避免

一旦进入拥塞避免状态，CWND的值大约是上次遇到拥塞时的值的一半，即距离拥塞可能并不遥远！因此，TCP无法每过一个RTT再将EWND的值翻番，而是采用了一种较为保守的方法，每个RTT只将EWND的值增加一个MSS。这能够以几种方式完成。一种通用的方法是对于TCP发送方无论何时到达一个新的确认，就将EWND增加一个MSS（MSS/EWND）字节。例如，如果MSS是1460字节并且CWND是14,600字节，则在一个RTT内发送10个报文段。每个到达ACK（假定每个报文段一个ACK）增加的拥塞窗口长度，因此在收到对所有10个报文段的确认后，拥塞窗口的值将增加了一个MSS。

---

但是何时应当结束拥塞避免的线性增长（每RTT1MSS）呢？

当出现超时时，TCP的拥塞避免算法行为相同。与慢启动的情况一样，cwnd 的值被设置为1个MSS，当丢包事件出现时，ssthresh 的值被更新为EWND值的一半。然而，前面讲过丢包事件也能由一个三个冗余ACK事件触发。在这种情况下，网络继续从发送方向接收方交付报文段（就像由收到冗余ACK所指示的那样）。

---

因此TCP对这种丢包事件的行为，相比于超时指示的丢包，应当不那么剧烈：TCP将CWND的值减半（为使测量结果更好，计及已收到的3个冗余的ACK要加上3个MSS），并且当收到3个冗余的ACK，将ssthresh的值记录为CWND的值的一半。接下来进入快速恢复状态。

---

例子：

---

7.6.3 快速恢复——拥塞控制优化

在快速恢复中，对于引起TCP进入快速恢复状态的缺失报文段，对收到的每个冗余的ACK，EWND 的值增加一个MSS。最终，当对丟失报文段的一个ACK到达时，TCP在降低EWND后进入拥塞避免状态。如果出现超时事件，快速恢复在执行如同在慢启动和拥塞避免中相同的动作后，迁移到慢启动状态：当丢包事件出现时，EWND的值被设置为1个MSS，并且ssthresh的值设置为CWND值的一半。

触发快速重传时的快速恢复

• 从新的ssthresh开始，而不是原来的起始值，有效地避免了缓慢的启动阶段，直接进入加法增加。

快速恢复是TCP推荐的而非必需的构件。有趣的是，一种称为TCPTahoe的TCP早期版本，不管是发生超时指示的丢包事件，还是发生3个冗余ACK指示的丟包事件，都无条件地将其拥塞窗口减至1个MSS，并进入慢启动阶段。TCP的较新版本TCPReno,则综合了快速恢复。

下图示了Reno版TCP与Tahoe版TCP的拥塞控制窗口的演化情况。在该图中，阈值初始等于8个MSS。在前8个传输回合，Tahoe和Reno采取了相同的动作。拥塞窗口在慢启动阶段以指数速度快速爬升，在第4轮传输时到达了阈值。然后拥塞窗口以线性速度爬升，直到在第8轮传输后出现3个冗余ACK。注意到当该丢包事件发生时，拥塞窗口值为12 x MSS。于是ssthresh的值被设置为0.5 xcwnd =6xMSS。在TCP Reno下，拥塞窗口被设置为ewnd = 9MSS，然后线性地增长。在TCP Tahoe下，拥塞窗口被设置为1个MSS，然后呈指数增长，直至到达ssthresh值为止，在这个点它开始线性增长。

表示了TCP拥塞控制算法( 即慢启动、拥塞避免和快速恢复)的完整FSM描述。该图也指示了新报文段的传输或重传的报文段可能出现的位置。尽管区分TCP差错控制/重传与TCP拥塞控制非常重要，但是注意到TCP这两个方面交织链接的方式也很重要。

---

例子： 

7.6.4 进一步优化 

SACK（选择性确认）通过允许指定所收到的字节的3个范围，提供了更大的能力来跟踪飞行中的段。

7.7 拥塞控制补充

7.7.1 宏观模型 

这些数据包级的规则影响到我们关心的许多事情

• 流量之间的公平性
• 对长往返时间（RTT）的响应
• 对随机丢包的反应

有一个与这些数量相关的代数表达式是很有用的 

7.7.2 窗口大小

W在每个窗口增加一次

• 近似值。每一个到达的数据包使W增加

当损失发生时（概率为p），W减半

• 在概率为p的情况下，

窗口大小的平均增加是：

为了达到平衡，平均增幅必须为，

7.7.3 Rate, fairness

Rate 是 

对于一个给定的丢包率，较长的RTT得到较少的速率

• "RTT的不公平性"

如果RTT很小，TCP就会迫使丢包率变高。

这个公式是非常近似的

• 窗口只对每个RTT的一个丢包做出反应
• 数据包丢失是集群性的