中文摘要
摘要：拥塞控制是TCP ( Transmission Control Protocol) 协议中重要的一个部分，被不断的改进与完善。本文对网络拥塞的出现原因和情况进行分析的同时，总结了现有的隐式拥塞控制算法的基本思路以及拥塞控制在当下面临的问题。
关键词：拥塞控制；互联网
英文摘要
Abstraction: Congestion control is an important part of TCP protocol and has been improved gradually all these times. This Passage is going to make a brief summary about the cause of congestive collapse, the main idea of congestion control algorithm and the problem it faces nowadays.
Keywords：Congestion control; Internet
1. 概述
拥塞崩溃是互联网的发展之路上必须面对的一个问题。随着互联网的发展与互联网用户的激增，互联网用户对于互联网的需求量超过了互联网设备（如路由器）的承载能力。这将会导致网络拥塞崩溃的发生。一旦拥塞崩溃的发生，这条链路便会陷入一个恶性循环，严重影响了网络的性能。本文将围绕网络拥塞出现的原因，拥塞控制的基本思路以及拥塞控制面临的问题展开讨论。
2. 拥塞的出现与拥塞控制
1. 网络拥塞的出现条件
当网络存在过多的数据分组以至于超过了网络设备所能提供的极限时，网络的性能就会下降，这种现象就叫为拥塞[1]。网络拥塞主要出现在网络资源相对短缺的部分，比如一个网络的瓶颈链路。例如在互联网中的某一个路由器节点上，有过多的数据分组同时请求通过同一个端口进行存储转发。
1. 若该路由器缓存空间足够大，所有的数据分组能够被缓存并等待被转发。由于此时数据分组数量较多，故排队时延非常大。当发送发定时器超时后，便会重发该分组，最终网络上会有多个相同的冗余分组[2]。
2. 若该路由器的缓存空间有限，故多余的数据分组会被这个路由器丢弃。之前存储转发该分组所消耗的传输容量被浪费掉了[2]。
3. 若端设备没有拥塞处理机制，在经历超时事件之后，会选择以原来的速度重发该分组及其后内容。但是路由器的拥塞状态没有得到改善，新发来的分组仍然不能得到有效处理，反而造成了更多的冗余数据。最终会陷入恶性循环。
2. 拥塞控制的基本思路
在讨论具体的拥塞控制方法之前，先明确期望通过拥塞控制得到的结果。
拥塞是由于当前的网络中存在过多的数据分组，超出了网络设备的处理能力导致的。我们期望通过某种方法能够控制用户发送分组的速度，从而避免某一时刻在某一网络设备中的数据分组过多，也就从根本上解决了拥塞的出现。如何告知用户当前的网络状态则使得拥塞控制分成了两个不同的方向。
显式的通过网络设备告知端设备控制发送速度。
当路由器发现当前网络的流量大于某个阀值时，可以预判可能出现的拥塞，并通过显式发送标志信息告知端设备当前路由器状态。端设备根据该信息控制发送速度，便可达到控制甚至避免拥塞的出现。隐式的通过丢包以及超时事件对发送速度进行控制。
显式的通知需要网络设备的配合，而路由器不一定都支持这个功能。隐式的拥塞控制则完全由端设备完成。由上面的分析可以发现，拥塞的出现会导致分组的丢包或者超时事件的发生。当端设备检测到超时或者丢包事件标志着当前的链路出现了拥塞。此时根据不同的事件控制发送速度即可达到拥塞控制的目的。本文主要讨论隐式的拥塞控制。
3. 拥塞控制核心算法及思路
上文分析了拥塞的出现原因以及能从端设备检测的特征。本节主要依据这些特征，描述拥塞控制算法的基本设计思路以及原因。
传统的隐式拥塞控制主要有四种工具来降低拥塞出现的可能。这些方法所遵循的原则有两条：响应并处理当前出现的问题与尽量避免同样问题的出现
1. 当前网络处于正常状态
慢启动
当一个新的TCP连接建立并开始传输分组的时候，并不知道当前的拥塞窗口的大小。我们期望传输速度能够稳定在拥塞窗口，最大程度的利用网络。但是由于选择隐式的拥塞控制，端设备无法知道当前网络状态，需要尝试才能知道拥塞窗口大致值。
慢启动便是从一个较低的窗口大小开始增长并尝试，在如Tahoe和Reno拥塞控制中，这个初始值设置为1。但是线性增长尝试非常浪费时间，快速增长到可能的拥塞窗口是一个比较明智的选。Tahoe和Reno选择指数增长也是这个原因。
拥塞避免
当窗口增长到一个可能的拥塞窗口大小时，我们既希望能窗口大小够维持在真实拥塞窗口附近以保证较高的利用率，但是又不能确定当前猜测的拥塞窗口就是真实的拥塞窗口，期望能够继续增长逼近真实的拥塞窗口。
拥塞避免则是用来处理这种情况的。当窗口增长到一个可能的拥塞窗口的大小时，放慢增长速度，并同时更新拥塞窗口。在Tahoe和Reno中选择线性增长。而现在最主要的问题是这个可能的拥塞窗口是如何得出来的，以及如何去维护它。在出现拥塞之前，由于一直在尝试当前窗口是否会导致拥塞，预估的拥塞窗口大小便随着尝试而增大。
2. 当出现重复ACK或者超时
在讨论具体出现拥塞的两个处理算法之前，先讨论重复ACK或超时对拥塞控制系统意味着什么以及需要怎么处理这种情况。
正如上文所说，拥塞控制系统需要先响应并处理这个事件：一旦重复ACK或者超时出现，说明当前的链路出现了拥塞。发送方需要立即减小发送速度，防止拥塞恶化。然后拥塞控制系统需要避免当前的情况再次发生：其需要适当的减少可能的拥塞窗口，并再次从减小的窗口向可能的拥塞窗口增加，开始新的一轮试探。
出现丢包或超时对于发送方，有两种可能的反馈，分别对应拥塞的两种不同的状态。
第一种情况是出现了多次重复的ACK。这说明网络中丢失了分组，但是网络情况还没特别糟糕，因为收到了其后的ACK代表着后面的分组能够正常的传输到接收方。
另一种情况是发生了超时事件。这一种情况就比较令人担忧了。因为若不是传输的最后一个分组的情况下，没有收到任何ACK代表着其后所有的分组均发生丢包或者极其严重的时延。这代表着当前的网络状态非常糟糕。
针对第一种情况，衍生出了快速重传以及快速恢复算法，用来针对网络拥塞还不是特别严重的情况。对于第二种情况，由于网络状况已经非常糟糕了，拥塞控制系统应选择慢启动的方法，重新从一个较小的窗口开始尝试。
快速重传
快速重传是将第一种情况具体化了，不同算法可能选择不同的事件作为快速重传的标志。快速重传不必等待定时器超时从而提高了信道利用率和吞吐率[3]。当触发快速重传时，代表着网络已经出现了拥塞，但是还没有那么严重，需要适当的减少速度。Tahoe算法就选择一视同仁，令其进行慢启动。而Reno之后就稍微进行了优化，使用了快速恢复算法。
快速恢复
快速恢复算法则是针对第一种情况的适当优化。若当前网络状态还没有那么糟糕，无需从一个很低的窗口重新开始尝试，而是选择一个合适的窗口大小开始增长。Reno就选择当前拥塞窗口的一半作为尝试的起点。
传统的拥塞控制系统主要参考重复ACK和超时事件作为拥塞事件的标记。但是除了这两个因素，还有其他的因素可以用于观测当前网络状态。
RTT作为一次往返的时延，可以粗略观测到当前拥塞程度的变化。可以通过机器学习训练其根据RTT的大小自动调节流量大小。
对于一些特殊的站点，一天当中某一时刻访问的流量是具有统计规律的。同样可以通过机器学习训练其依照这种规律来预测拥塞窗口，减少尝试的开销。
4. 拥塞控制面临的问题
当今网络日益复杂，拥塞控制面临着很多需要解决的问题。
1) 异质性
当今的网络是种各样不同的子网络构成，而每个子网络包含不同的子拓扑，这就导致了不同的网络包含不同的链路特性。从带宽的角度来讲，链路质量可能是非常慢速如移动网络，或者是非常高速的链路如核心网络，数量级从Kbps到Gbps。从时延的角度来讲，场景的变化从本地网络通信到卫星通信，数量级从毫秒到秒。这就导致了现实的网络场景的多样性，这种多样性随着网络的快速发展，而变得越来越复杂[4]。传统的拥塞控制没有考虑不同网络环境下的处理，导致其性能和效率可能会受损。
2) 公平性
公平性也是拥塞控制系统需要特别注意的一点。如没有拥塞控制的UDP协议对于有拥塞控制的TCP协议，就是不公平的。而TCP协议中各个拥塞控制的算法也存在不公平的现象。如何在不同拥塞控制协议下保持公平性，是拥塞控制需要解决的一个问题。如果一个拥塞控制算法无法保证数据流的公平性，最终则会导致网络流量的侵略性以及造成得此失彼的结果。
3) 无线网络的拥塞控制
在传统的拥塞控制中，重复ACK和超时往往是由于拥塞所导致的，而在无线网络中，这种错误可能只是由于信号问题而非拥塞。这时无需降低发送窗口。对于拥塞控制系统来说，如何分清这种由于信号问题还是拥塞导致重复ACK或超时，是一个需要解决的问题。
5. 总结
拥塞控制从提出到今日已四十年有余，但是仍然没有提出完美的解决方案。这是由于网络用户日益增长的网络需求与有限的网络资源的基本矛盾所导致的。我们所期望最优的拥塞控制系统是在保证公平性前提下最高效率地利用网络资源并避免丢包的发生。随着人工智能的发展以及端设备计算能力的增加，未来的拥塞控制可能会向智能化的方向发展。
参考文献
[1]. 孔金生, 任平英, “TCP网络拥塞控制研究,” 计算机技术与发展, Volume 1, 2014, pp43-46
[2]. James F. Kurose, and Keith W. Ross, 计算机网络-自顶向上方法与Internet特色(第六版), 机械工业出版社, Oct. 2016, pp.177-178
[3]. Kevin Fall, and Sally Floyd, “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP,” ACM SIGCOMM Computer Communication Review, Volume 26 Issue 3, July. 1996, pp.5-21.
[4]. Welson, “TCP网络拥塞控制的困境,” [EB/OL] http://wetest.qq.com/lab/view/246.html, Jan. 2017
