死锁及其防止
拥塞的极端后果是死锁。
死锁是网络中最容易发生的故障之一，即使在网络负荷不很重时也会发生。死锁发生时，一组节点由于没有空闲缓冲区而元法接收和转发分组，节点之间相互等待，既不能接收分组也不能转发分组，并一直保持这一僵局，严重时甚至导致整个网络的瘫痪。此时，只能靠人工干预来重新启动网络，解除死锁。但重新启动后并未消除引起死锁的隐患，所以可能再次发生死锁。死锁是由于控制技术方面的某些缺陷所引起的，起因通常难以捉摸、难以发现，即使发现，也常常不能立即修复。因此，在各层协议中都必须考虑如何避免死锁的问题。
(1) 存储转发死锁及其防止。最常见的死锁是发生在两个节点之间的直接存储转发死锁。例如，A节点的所有缓冲区装满了等待输出到B节点的分组，而B节点的所有缓冲区也全部装满了等待输出到A节点的分组;此时，A节点不能从B节点接收分组，B节点也不能从A节点接收分组，从而造成两节点间的死锁。这种情况也可能发生在一组节点之间，例如，A节点企图向B节点发送分组、B节点企图向C节点发送分组、而C节点又企图向A节点发送分组，但此时每个节点都无空闲缓冲区用于接收分组，这种情形称做间接存储转发死锁。当一个节点处于死锁状态时，所有与之相连的链路将被完全拥塞。
一种防止存储转发死锁的方法是，每个节点设置M+1个缓冲区，并以0到M编号。M为通信子网的直径，即从任一源节点到任一目的节点间的最大链路段数。每个源节点仅当其0号缓冲区空时才能接收源端系统来的分组，而此分组仅能转发给1号缓冲区空闲的相邻节点，再由该节点将分组转发给它的2号缓冲区空闲的相邻节点……最后，该分组或者顺利到达目的节点并被递交给目的端系统，或者到了某个节点编号为M的缓冲区中再也转发不下去，此时一定发生了循环，应该将该分组丢弃。由于每个分组都是按照编号递增规则分配缓冲区，所以节点之间不会相互等待空闲缓冲区而发生死锁现象。这种方法的不足之处在于，当某节点虽然有空闲缓冲区，但正巧没有所需要的特定编号的缓冲区时，分组仍要等待，从而造成了缓冲区和链路的浪费。
另一种防止存储转发死锁的方法是，使每个分组上都携带一个全局性的惟一的"时间戳"，每个节点要为每条输入链路保留一个特殊的接收缓冲区，而其它缓冲区均可用于存放中转分组。在每条输出链路的队列上分组按时间戳顺序排队。例如，节点A要将分组送到节点B，若B节点没有空闲缓冲区，但正巧有要送到A节点的分组，此时A、B节点可通过特殊的接收缓冲区交换分组;若B节点既没有空闲缓冲区，也没有要送往A节点的分组，B节点只好强行将一个出路方向大致与A节点方向相同的分组与A节点互相交换分组，但此时A节点中的分组必须比B节点中的分组具有更早的时间戳，这样才能保证子网中某个最早的分组不受阻挡地转发到目的地。由此可见，每个分组最终总会成为最早的分组，并总能被一步一步地发送到目的节点，从而避免了死锁现象的发生。
(2) 重装死锁及其防止。死锁中比较严重的情况是重装死锁。假设发给一个端系统的报文很长，被源节点拆成若干个分组发送，目的节点要将所有具有相同编号的分组重新装配成报文递交给目的端系统，若目的节点用于重装报文的缓冲区空间有限，而且它无法知道正在接收的报文究竟被拆成多少个分组，此时，就可能发生严重的问题:为了接收更多的分组，该目的节点用完了它的缓冲空间，但它又不能将尚未拼装完整的报文递送给目的端系统，而邻节点仍在不断地向它传送分组，但它却无法接收。这样，经过多次尝试后，邻节点就会绕道从其它途径再向该目的节点传送分组，但该目的节点已被死锁，其周边区域也由此发生了拥塞。下面几种方法可用以避免重装死锁的发生:
①允许目的节点将不完整的报文递交给目的端系统;
②一个不能完整重装的报文能被检测出来，并要求发送该报文的源端系统重新传送;
③为每个节点配备一个后备缓冲空间，用以暂存不完整的报文。
①、②两种方法不能很满意地解决重装死锁，因为它们使端系统中的协议复杂化了。一般的设计中，网络层应该对端系统透明，也即端系统不该考虑诸如报文拆、装之类的事。③方法虽然不涉及端系统，但使每个节点增加了开销。
拥塞控制的当前标准
端到端拥塞控制的IETF标准关注的方面包括集中在特定的协议(例如TCP协议[RFC2581]，可靠的多点传送协议[RFC2357]);终端节点和路由器之间的拥塞信息(例如明确的拥塞通告[RFC2481])交换的句法和语义;不同服务的服务质量的期望值。端到端的拥塞控制的作用也在一个关于“Internet中的队列管理和避免拥塞的建议”[参见RFC2309]的RFC报告中进行了讨论。RFC2309提出了在路由器中活跃的队列管理机制的配置和对路由器机制设计的延续来处理对拥塞通告无回应的流。我们能够轻松地从RFC2309中借用一些端到端的拥塞控制的概括性的讨论。
与上面提到的RFCs资料相比，本文档对拥塞控制的原理进行更一般性的讨论。Internet成功的一个关键因素就是TCP协议的避免拥塞机制。当前TCP协议在Internet中仍然是占主导地位的传输协议，但它不是适用于任何地方，有越来越多的应用由于某种原因没有选择使用TCP协议。通信不仅包括多点传送通信，而且包括单点传送通信，诸如不需要可靠性的流化的多媒体，以及包括象DNS(DomainNameServer域名服务器)或路由信息的通信，它们带有被认为对网络运行至关重要的短信息。许多通信并不使用任何形式的预留带宽或端到端拥塞控制。为了保持最优传输量，端到端的拥塞控制的继续使用对保持Internet的稳定至关重要。
完成拥塞控制时，确定拥塞窗口大小的过程
确定拥塞窗口的大小的过程：在刚建立连接时，将拥塞窗口的大小初始化为该连接所需的最大连接数据段的长度值，并发送一个最大长度的数据段(当然必须是接收窗口允许的)。如果在定时器超时前得到确认，将拥塞窗口的大小增加一个数据段的字节数，并发送两个数据段，如果每个数据段在定时器超时前都得到确认，就再在原基础上增加一倍，即为4个数据段的大小，如此反复，每次都在前一次的基础上加倍。当定时器超时或达到发送窗口设定值，停止拥塞窗口尺寸的增加。这种反复称为慢速启动，所有的TCP协议都支持这种方法。
目前拥塞控制的研究热点：
拥塞控制不仅是网络稳定、高效运行的关键，同时又是实现各种服务质量的基础和前提。实际的网络是一个不断发展的系统，网络拥塞控制研究也是一个非常困难、有挑战性的研究领域。对网络拥塞控制的研究仍有许多工作要做，进一步的工作包括：
(1) 拥塞控制基于端主机的控制策略和路由器的队列管理策略存在相互影响、相互作用的关系，如何在网络模型描述的基础上，从控制系统的角度将两者结合起来，设计出最优的拥塞控制策略，是网络拥塞控制研究的一个方向。
(2) 主动队列管理技术通过丢包积极响应拥塞，来达到拥塞避免和缓解的目的，是网络拥塞控制最重要的手段。如何实现AQM高级策略，引入新的人工智能算法和遗传算法与模糊逻辑的综合应用是目前研究的一个热点问题。
(3) 以往的工作主要采用局部线性化方法，缺乏对系统全局动力学的理论分析。此外，在多种源端拥塞控制策略和路由器避免策略并存时，如何分析整个网络的稳定性，如何分析各种不确定因素对稳定性的影响等，也是需要认真考虑的问题。
(4) TCP/IP 拥塞控制的设计和实现面临着众多的折中，不可能有一种设计和实现在所有环境中都是“最好的”。现有的拥塞控制思路、方法和技术在多目标的不同环境中面临着挑战，它们还有许多要改进的地方。
(5) 目前已经有越来越多的移动用户通过无线系统接入互联网，由于无线通信固有的特点，使得拥塞控制机制的研究更加困难，极具挑战。
