TCP协议的拥塞控制策略及改进

TCP是针对固定网络设计的一种传输协议，其错误控制机制是基于将所有丢包原因都归结于网络拥塞的假设。这种错误控制机制在有线网络上获得了很大的成功；但由于移动计算环境有着明显不同于有线网络环境的特点，如较高的位出错率、可用带宽小、衰减信道等，因此针对传统有线网络设计的TCP协议，其性能受到了很大影响。本文对目前移动计算环境下TCP协议的一些主要改进方案进行了综述，在对这些方案进行分类的基础上，对其优缺点进行了分析，并且对这些方案进行了比较。最后，提出了进一步研究的方向。

TCP, 移动计算，无线网络，错误控制

1. 引言

互联网最初源于美国国防部的ARPANET计划。在上世纪60年代中期，正是冷战的高峰，美国国防部希望有一个命令和控制网络能够在核战争的条件下幸免于难，而传统的电路交换的电话网络则显得太脆弱。国防部指定其下属的高级研究计划局（ARPA）解决这个问题，此后诞生的一个新型网络便称为ARPANET，其最大特点是采用无连接的端到端包交换服务。随后ARPANET开始与美国国家科学基金会（NSF）建成的NSFNET及加拿大、欧洲和太平洋地区的网络互联。到了80年代中期，人们开始把互联的网络称为互联网。

早在70年代中期，ARPA为了实现异种网络之间的互联与互通，推出了TCP/IP体系结构和协议规范。时至今日，TCP/IP协议也成为最流行的网际互联协议，并由单纯的TCP/IP协议发展成为一系列以IP为基础的TCP/IP协议簇。TCP／IP协议簇为互联网提供了基本的通信机制。

互联网采用的是无连接的端到端数据包交换，提供“尽力而为”（best effort）服务模型的设计机制。这种机制的最大优势是设计简单，可扩展性强。互联网在过去的十几年中经历了爆炸式的增长，这已经充分证明了这种设计机制的成功。然而这种优势并不是没有代价的，随着互联网用户数量的膨胀，网络的拥塞问题也越来越严重。例如由于队列溢出，互联网路由器会丢弃约10%的数据包。据统计，互联网上95%的数据流使用的是TCP/IP协议，因此，互联网上主要的互连协议TCP/IP的拥塞控制（congestion control）机制对控制网络拥塞具有特别重要的意义。拥塞控制是确保互联网鲁棒性（robustness）的关键因素，也是各种管理控制机制和应用（如多媒体通信中QoS控制、区分服务（differentiated services））的基础，因此关于互联网的拥塞控制问题一直是网络研究的一个热点。

TCP是目前Internet上使用最广泛的一种传输协议，根据MCI的统计，Internet上总字节数的95％及总数据包数的90％使用TCP协议传输[25]。TCP的目的是为了解决Internet的稳定性、异质性（接受端缓冲区大小、网络带宽及延迟等）、各流之间享用带宽的公平性、使用效率及拥塞控制等问题，从而为Internet提供可靠、健壮（robust）的端到端通讯。Internet近十年来的迅猛发展已证明TCP协议在设计上是成功的。

但是，TCP是为固定主机及有线网络设计的一种滑动窗口协议，它在位出错率（bit rate error，BER）很低、丢包的主要原因是网络拥塞的传统网络上的成功在移动计算环境下受到了巨大的挑战。移动计算带来的新问题主要是无线链路传输的可靠性、移动操作的特点以及对效率进行评估的性能尺度等。因此，对TCP协议的改进已经成为近几年网络通讯领域的一个研究热点。

本文第二部分对网络拥塞的基本概念进行了简要介绍；第三部分TCP的拥塞控制机制及有线网络环境下的改进进行了介绍；第四部分分析了TCP在移动计算环境下的缺点及其需要增加的功能；第五部分对增强移动环境下TCP的技术方案进行了分类介绍，分析了各自的优缺点，并对这些方案进行了比较。最后进行了总结，并提出了有待进一步研究的一些热点方向。

2. 网络拥塞的基本概念

2.1 拥塞的基本概念和互联网模型

当网络中存在过多的数据包时，网络的性能就会下降，这种现象称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发生“拥塞崩溃”（congestion collapse）现象。一般来说，拥塞崩溃发生在网络负载的增加导致网络效率的降低的时候。最初观察到这种现象是在1986年10月，在这个过程中，LBL与UC Berkeley之间的吞吐量从32kbps下降到了40bps。Floyd总结出拥塞崩溃主要包括以下几种：传统的崩溃、未传送数据包导致的崩溃、由于数据包分段造成的崩溃、日益增长的控制信息流造成的崩溃等。

图1：网络负载与吞吐量及响应时间的关系

对于拥塞现象，我们可以进一步用图1来描述。当网络负载较小时，吞吐量基本上随着负载的增长而增长，呈线性关系，响应时间增长缓慢。当负载达到网络容量时，吞吐量呈现出缓慢增长，而响应时间急剧增加，这一点称为Knee。如果负载继续增加，路由器开始丢包，当负载超过一定量时，吞吐量开始急剧下降，这一点称为Cliff。拥塞控制机制实际上包含拥塞避免（congestion avoidance）和拥塞控制（congestion control）两种策略。前者的目的是使网络运行在Knee附近，避免拥塞的发生；而后者则是使得网络运行在Cliff的左侧区域。前者是一种“预防”措施，维持网络的高吞吐量、低延迟状态，避免进入拥塞；后者是一种“恢复”措施，使网络从拥塞中恢复过来，进入正常的运行状态。

拥塞现象的发生和前面提到的互联网的设计机制有着密切关系，我们对这种设计机制作一个简单的归纳：

数据包交换（packet switched）网络：与电路交换（circuit switched）网络相比，由于包交换网络对资源的利用是基于统计复用（statistical multiplexing）的，因此提高了资源的利用效率。但在基于统计复用的情况下，很难保证用户的服务质量（quality of service，QoS），并且很容易出现数据包“乱序”的现象，对乱序数据包的处理会大大增加拥塞控制的复杂性。

无连接（connectionless）网络：互联网的节点之间在发送数据之前不需要建立连接，从而简化了网络的设计，网络的中间节点上无需保留和连接有关的状态信息。但无连接模型很难引入接纳控制（admission control），在用户需求大于网络资源时难以保证服务质量；此外，由于对数据发送源的追踪能力很差，给网络安全带来了隐患；无连接也是网络中出现乱序数据包的主要原因。

“尽力而为”的服务模型：不对网络中传输的数据提供服务质量保证。在这种服务模型下，所有的业务流被“一视同仁”地公平地竞争网络资源，路由器对所有的数据包都采用先来先处理（First Come First Service，FCFS）的工作方式，它尽最大努力将数据包包送达目的地。但对数据包传递的可靠性、延迟等不能提供任何保证。这很适合Email、Ftp、WWW等业务。但随着互联网的飞速发展，IP业务也得到了快速增长和多样化。特别是随着多媒体业务的兴起，计算机已经不是单纯的处理数据的工具。这对互联网也就相应地提出了更高的要求。对那些有带宽、延迟、延迟抖动等特殊要求的应用来说，现有的“尽力而为”服务显然是不够的。

2.2 拥塞产生的原因

拥塞发生的主要原因在于网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力。由于互联网的设计机制导致其缺乏“接纳控制”能力，因此在网络资源不足时不能限制用户数量，而只能靠降低服务质量来继续为用户服务，也就是“尽力而为”的服务。

图2（a） 图2（b）

拥塞虽然是由于网络资源的稀缺引起的，但单纯增加资源并不能避免拥塞的发生。例如增加缓存空间到一定程度时，只会加重拥塞，而不是减轻拥塞，这是因为当数据包经过长时间排队完成转发时，它们很可能早已超时，从而引起源端超时重发，而这些数据包还会继续传输到下一路由器，从而浪费网络资源，加重网络拥塞。事实上，缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路带宽及提高处理能力也不能解决拥塞问题，例如，图2（a）中，四个节点之间的链路带宽都是19.2kbps，传输某个文件需要用时5分钟；当第一个节点和第二个节点之间的链路带宽提高到1Mbps时（如图2（b）所示），传输完该文件所需时间反而大大增加到了7个小时！这是因为在路由器R1中，数据包的到达速率远远大于转发的速率，从而导致大量数据包被丢弃，源端的发送速度被抑止，从而使得传输时间大大增加。即使所有链路具有同样大的带宽也不能解决拥塞问题，例如图3中，

所有链路带宽都是1Gbps，如果A和B同时向C以1Gbps的速率发送数据，则路由器R的输入速率为2Gbps，而输出速率只能为1Gbps，从而产生拥塞。

单纯地增加网络资源之所以不能解决拥塞问题，是因为拥塞本身是一个动态问题，它不可能只靠静态的方案来解决，而需要协议能够在网络出现拥塞时保护网络的正常运行。目前对互联网进行的拥塞控制主要是依靠在源端执行的基于窗口的TCP拥塞控制机制。网络本身对拥塞控制所起的作用较小，但近几年这方面的研究已经成了一个新的热点。

3. TCP拥塞控制及其改进

3.1 TCP拥塞控制机制介绍

基于源端的拥塞控制策略中，使用最为广泛的是TCP协议中的拥塞控制策略，TCP协议是目前互联网中使用最为广泛的传输协议。根据MCI的统计，互联网上总字节数的95％及总数据包数的90％使用TCP协议传输。

早期的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制，因而易导致网络拥塞。1988年Jacobson针对TCP在网络拥塞控制方面的不足，提出了“慢启动”（Slow Start）和