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

《TCP协议的拥塞控制策略及改进》由会员分享，可在线阅读，更多相关《TCP协议的拥塞控制策略及改进（20页珍藏版）》请在装配图网上搜索。

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

2、RPANET计划。在上世纪60年代 中期，正是冷战的高峰，美国国防部希望有一个命令和控制网络 能够在核战争的条件下幸免于难，而传统的电路交换的电话网络 则显得太脆弱。国防部指定其下属的高级研究计划局(ARPA)解 决这个问题，此后诞生的一个新型网络便称为ARPANET，其最大 特点是采用无连接的端到端包交换服务。随后ARPANET开始与美 国国家科学基金会(NSF)建成的NSFNET及加拿大、欧洲和太平 洋地区的网络互联。到了80年代中期，人们开始把互联的网络 称为互联网。早在70年代中期，ARPA为了实现异种网络之间的互联与互通， 推出了 TCP/IP体系结构和协议规范。时至今日，TCP/I

3、P协议也 成为最流行的网际互联协议，并由单纯的TCP/IP协议发展成为 一系列以IP为基础的TCP/IP协议簇。TCP / IP协议簇为互联网 提供了基本的通信机 制。互联网采用的是无连接的端到端数据包交换，提供“尽力而为”(bes t effor t)服务模型的设计机制。这种机制的最大优势是 设计简单，可扩展性强。互联网在过去的十几年中经历了爆炸式 的增长，这已经充分证明了这种设计机制的成功。然而这种优势 并不是没有代价的，随着互联网用户数量的膨胀，网络的拥塞问 题也越来越严重。例如由于队列溢出，互联网路由器会丢弃约 10%的数据包。据统计，互联网上95%的数据流使用的是TCP/IP 协议，

4、因此，互联网上主要的互连协议TCP/IP的拥塞控制(congestion control)机制对控制网络拥塞具有特别重要的意 义。拥塞控制是确保互联网鲁棒性(robustness )的关键因素， 也是各种管理控制机制和应用(如多媒体通信中QoS控制、区 分服务(differen tia ted services)的基础，因此关于互联 网的拥塞控制问题一直是网络研究的一个热点。TCP是目前Internet上使用最广泛的一种传输协议，根据MCI 的统计，Internet上总字节数的95%及总数据包数的90%使 用TCP协议传输25。TCP的目的是为了解决Internet的稳定 性、异质性(接受端缓

5、冲区大小、网络带宽及延迟等)、各流之 间享用带宽的公平性、使用效率及拥塞控制等问题，从而为 Int erne t提供可靠、健壮(robus t)的端到端通讯。In terne t 近十年来的迅猛发展已证明TCP协议在设计上是成功的。但是，TCP是为固定主机及有线网络设计的一种滑动窗口协议， 它在位出错率(bit rate error， BER)很低、丢包的主要原因 是网络拥塞的传统网络上的成功在移动计算环境下受到了巨大 的挑战。移动计算带来的新问题主要是无线链路传输的可靠性、 移动操作的特点以及对效率进行评估的性能尺度等。因此，对 TCP协议的改进已经成为近几年网络通讯领域的一个研究热点。本文

6、第二部分对网络拥塞的基本概念进行了简要介绍；第三部分TCP的拥塞控制机制及有线网络环境下的改进进行了介绍；第四 部分分析了 TCP在移动计算环境下的缺点及其需要增加的功能； 第五部分对增强移动环境下TCP的技术方案进行了分类介绍，分 析了各自的优缺点，并对这些方案进行了比较。最后进行了总结， 并提出了有待进一步研究的一些热点方向。2. 网络拥塞的基本概念2.1 拥塞的基本概念和互联网模型当网络中存在过多的数据包时，网络的性能就会下降，这种现象 称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发 生“拥塞崩溃”(conges tion collapse )现象。一般来说，拥 塞崩溃发生在网

7、络负载的增加导致网络效率的降低的时候。最初 观察到这种现象是在1986年10月，在这个过程 中，LBL与UC Berkeley之间的吞吐量从32kbps下降到了 40bps。Floyd总结 出拥塞崩溃主要包括以下几种：传统的崩溃、未传送数据包导致 的崩溃、由于 数据包分段造成的崩溃、日益增长的控制信息流 造成的崩溃等。对于拥塞现象，我们可以进一步用图1来描述。当网络负载较小 时，吞吐量基本上随着负载的增长而增长，呈线性关系，响应时 间增长缓慢。当负 载达到网络容量时，吞吐量呈现出缓慢增长， 而响应时间急剧增加，这一点称为Knee。如果负载继续增加， 路由器开始丢包，当负载超过一定量时，吞吐量开

8、始 急剧下降， 这一点称为Cliff。拥塞控制机制实际上包含拥塞避免(congestion avoidance)和拥塞控制(congestion control) 两种策略。前者的目的是使网络运行在Knee附近，避免拥塞的 发生；而后者则是使得网络运行在Cliff的左侧区域。前者是一 种“预防”措施，维持网络的高吞吐量、低延迟状态，避免进入 拥塞；后者是一种“恢复”措施，使网络从拥塞中恢复过来，进 入正常的运行状态。拥塞现象的发生和前面提到的互联网的设计机制有着密切关系， 我们对这种设计机制作一个简单的归纳：1. 数据包交换(packet switched)网络：与电路交换(circuit s

9、wit ched )网络相比，由于包交换网络对资源的利用是基 于统计复用(statist ical mul tiplexing )的，因此提高 了资源的利用效率。但在基于统计复用的情况下，很难保 证用户的服务质量(quality of service， QoS)，并且很 容易出现数据包“乱序”的现象，对乱序数据包的处理会 大大增加拥塞控制的复杂性。2 .无连接( c o n n e c t i o n l e s s )网络：互联网的节点之间在发 送数据之前不需要建立连接，从而简化了网络的设计，网 络的中间节点上无需保留和连接有关的状态信息。但无连 接模型很难引入接纳控制(admission

10、control)，在用户 需求大于网络资源时难以保证服务质量；此外，由于对数 据发送源的追踪能力很差，给网络安全带来了隐患；无连 接也是网络中出现乱序 数据包的主要原因。3. “尽力而为”的服务模型：不对网络中传输的数据提供服 务质量保证。在这种服务模型下，所有的业务流被“一视 同仁”地公 平地竞争网络资源，路由器对所有的数据包都 采用先来先处理(First Come First Service， FCFS)的 工作方式，它尽最大努力将数据包包送达目的地。但对数 据包传递的可靠性、延迟等不能提供任何保证。这很适合Email、Ftp、WWW等业务。但随着互联网的飞速发展，IP 业务也得到了快速增

11、长和多样化。特别是随着多媒体业务 的兴起，计算机已经不是单纯的处理数据的工具。这对互 联网也就相应地提出了更高的要求。对那些有带宽、延迟、 延迟抖动等特殊要求的应用来说，现有的“尽力而为”服 务显然是不够的。2.2拥塞产生的原因拥塞发生的主要原因在于网络能够提供的资源不足以满足用户 的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处 理能力。由于互联网 的设计机制导致其缺乏“接纳控制”能力， 因此在网络资源不足时不能限制用户数量，而只能靠降低服务质 量来继续为用户服务，也就是“尽力而为”的服务。拥塞虽然是由于网络资源的稀缺引起的，但单纯增加资源并不能 避免拥塞的发生。例如增加缓存空间到一

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

13、转发的速率， 从而导致大量数据包被丢 弃，源端的发送速度被抑止，从而使 得传输时间大大增加。即使所有链路具有同样大的带宽也不能解 决拥塞问题，例如图3中，所有链路带宽都是lGbps，如果A和B同时向C以lGbps的速率 发送数据，则路由器R的输入速率为2Gbps，而输出速率只能为 lGbps，从而产生拥塞。单纯地增加网络资源之所以不能解决拥塞问题，是因为拥塞本身 是一个动态问题，它不可能只靠静态的方案来解决，而需要协议 能够在网络出现拥塞时保护网络的正常运行。目前对互联网进行 的拥塞控制主要是依靠在源端执行的基于窗口的TCP拥塞控制 机制。网络本身对拥塞控制所起的作用较小，但近几年这方面的 研

14、究已经成了一个新的热点。3. TCP拥塞控制及其改进3.1 TCP拥塞控制机制介绍基于源端的拥塞控制策略中，使用最为广泛的是TCP协议中的拥 塞控制策略,TCP协议是目前互联网中使用最为广泛的传输协议。 根据MCI的统计，互联网上总字节数的95%及总数据包数的90% 使用TCP协议传输。早期的TCP协议只有基于窗口的流控制(flow control)机制而 没有拥塞控制机制，因而易导致网络拥塞。1988年Jacobson针 对TCP在网络拥塞控制方面的不足，提出了“慢启动” (Slow Start)和“拥塞避免(Conges tion Avoidance )算法。1990 年出现的TCP Re

15、no版本增加了“快速重传”(FastRetransmit)、“快速恢复”(Fast Recovery)算法，避免了 网络拥塞不严重时采用“慢启动”算法而造成过度减小发送窗 口尺寸的现象，这样TCP的拥塞控制就主要由这4个核心算法组 成。TCP协议的目的是为上层应用提供可靠的服务，其主要特征在于:1. 确保各流享用带宽的公平性。2. 动态发现当前可利用的带宽。3. 拥塞避免及控制机制以避免拥塞崩溃(congestion collapse )的发生。标准版本的TCP使用基于窗口的的和式增加积式减小(Additive Increase Multiplicative Decrease，AIMD)方式控

16、制发送速率， 以保证稳定性及带宽享用的公平性。错误控制机制是一个可靠传输协议的关键部分。它对协议的性能 有很大的影响，包括吞吐量、能量消耗及可靠性。错误控制通常 包括错误检测和错 误恢复两部分。为了保证数据传输的可靠性， TCP要求接受端在正确接收到数据段(data segment)后向发送 端发送一个确认包，确认包中包含了期望接收到的下一个数据段 的序号。TCP发送端通过监测确认包的序号来检测是否发生了错 误。如 果发生超时或者发送端收到一定数量(通常是3个)重 复的确认包，则认为传输过程中发生了错误，数据段被丢弃。由 于有线网络的位出错率很低(例如光纤的BER通常只有10 1222)，因此

17、TCP假设丢包是由于网络拥塞引起的。在错误恢 复处理过程中，TCP重传丢弃的数据段、减小发送端窗口大小并 且 在超时情况下重置超时时钟。最初的TCP协议只有基于窗口的流控制(flow control)机制而 没有拥塞控制机制。流控制作为接受方管理发送方发送数据的方 式，用来防止接受方可用的数据缓存空间的溢出。流控制是一种 局部控制机 制，其参与者仅仅是发送方和接收方，它只考虑了 接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制 则注重于整体，其考虑的是整个网络的传输能力， 是一种全局 控制机制。正因为流控制的这种局限性，从而导致了拥塞崩溃现 象的发生。1986年初,Jacobson开发

18、了现在在TCP应用中的拥塞控制机制。运行在端节点主机中的这些机制使得TCP连接在网络发生拥塞 时 回退(back off)，也就是说TCP源端会对网络发出的拥塞 指示(congestionnotification)(例如丢包、重复的ACK等) 作出响应。1988年Jacobson针对TCP在控制网络拥塞方面的不 足，提出了“慢启动”(Slow St ar t)和“拥塞避免”(Congestion Avoidance)算法。1990 年出现的 TCP Reno 版本 增加了“快速重传”(Fast Retransmit)、“快速恢复”(Fast Recovery)算法，避免了网络拥塞不严重时采用“

19、慢启动”算法 而造成过大地减小发送窗口尺寸的现象，这样TCP的拥塞控制就 由这4个核心部分组成。近几年又出现TCP的改进版本如 NewReno 和选择性应答(selective acknowledgement, SACK) 等。正是这些拥塞控制机制防止了今天网络的拥塞崩溃。TCP拥塞控制四个主要过程(如图4 (a)和(b)所示)简要介 绍如下：1.慢启动阶段：早期开发的TCP应用在启动一个连接时会向 网络中发送大量的数据包，这样很容易导致路由器缓存空 间耗尽，网络发生拥 塞，使得TCP连接的吞吐量急剧下降。 由于TCP源端无法知道网络资源当前的利用状况，因此新 建立的TCP连接不能一开始就发送

20、大量数据，而只能逐步 增加 每次发送的数据量，以避免上述现象的发生。具体地说，当建立新的TCP连接时，拥塞窗口 (congestion window, cwnd )初始化为一个数据包大小。源端按cwnd大小发送数 据，每收到一个ACK确认,cwnd就增加一个数据包发送量， 这样cwnd就 将随着回路响应时间(Round Trip Time, RTT) 呈指数增长，源端向网络发送的数据量将急剧增加。事实 上，慢启动一点也不慢，要达到每 RTT 发送 W 个数据包所 需时间仅为RTTXlogW。由于在发生拥塞时，拥塞窗口会 减半或降到 1，因此慢启动确保了源端的发送速率最多是链 路带宽的两倍。2.

21、 拥塞避免阶段:如果TCP源端发现超时或收到3个相同ACK 副本时，即认为网络发生了拥塞(主要因为由传输引起的 数据 包损坏和丢失的概率很小(1%)。此时就进入拥 塞避免阶段。慢启动阈值(ss thresh )被设置为当前拥塞 窗口大小的一半；如果超 时，拥塞窗口被置 1。如果 cwndssthresh，TCP就执行拥塞避免算法，此时，cwnd在 每次收到一个 ACK 时只增加 1/cwnd 个数据 包，这样，在 一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd 不是呈指数增长，而是线性增长。3. 快速重传和快速恢复阶段：快速重传是当 TCP 源端收到到 三个相同的ACK副本时，即

22、认为有数据包丢失，则源端重 传丢失 的数据包，而不必等待RTO超时。同时将ssthresh 设置为当前cwnd值的一半,并且将cwnd减为原先的一半。 快速恢复是基于“管道”模型(pipe model)的“数据包 守恒” 的原则(conservation of packets principle)， 即同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网 络。如果发送方收到一个重复的ACK，则认为已经有一个 数据包离开了网络，于是将拥塞窗口加1。如果“数据包守 恒”原则能够得到严格遵守，那么网络中将很少会发生拥 塞；本质上，拥塞控制的目的就是找到违

23、反该原则的地方 并进行修正。经过十多年的发展，目前TCP协议主要包含有四个版本：TCPTahoe、TCP Reno、TCP NewReno 和 TCP SACK。TCP Tahoe 是早 期的TCP版本，它包括了 3个最基本的拥塞控制算法一“慢启 动”、“拥塞避免”和“快速重传”。TCP Reno在TCP Tahoe 基础上增加了 “快速恢复”算法。TCP NewReno对TCP Reno中 的“快速恢复”算法进行了修正，它考虑了一个发送窗口内多个 数据包丢失的情况。在Reno版中，发送端收到一个新的ACK后 旧退出“快速恢复”阶段，而在NewReno版中，只有当所有的 数据包都被确认后才退出

24、“快速恢复”阶段。TCP SACK关注的 也是一个窗口内多个数据包丢失的情况，它避免了之前版本的 TCP重传一个窗口内所有数据包的情况，包括那些已经被接收端 正确接收的数据包， 而只是重传那些被丢弃的数据包。另外，在1994年，L.S.Brakmo等提出了一种新的拥塞控制策略 TCP Vegas。由于RTT值与网络运行情况有密切关系，因此， TCP Vegas通过观察TCP连接中RTT值改变感知网络是否发生拥 塞，从而控制拥塞窗口大小。如果发现RTT值变大，Vegas就认 为网络正在发生拥塞，于 是开始减小拥塞窗口；另一方面，如 果RTT变小，Vegas就认为网络拥塞正在解除，于是再次增加拥

25、塞窗口。这样，拥塞窗口在理想情况下就会稳定在一个合 适的 值上。TCP Vegas的最大优点在于拥塞机制的触发只与RTT的改 变有关，而与包的具体传输时延无关。由于TCP Vegas不是利用 丢包来判断网络可用带宽，而是以RTT的变化来判断，因此能更 精确地预测网络的可利用带宽，其公平性、效率都较好。但TCP Vegas之所以未能在互联网上大规模使用，主要是因为使用TCP Vegas的流在带宽竞争能力方面不及未使用TCP Vegas的流，从 而导致网络资源享用不公平，而不是算法本身的问题。3.2拥塞控制的主要问题拥塞控制的问题主要集中在效率和公平性（fairness）上。网络 资源的使用效率是

26、指源端要求的总资源与网络所能提供的资源 之间的关系。如果二者刚好相等或者很接近，那么这种算法的效 率就是高的，否则都是效率不高的表现。公平性是指在网络发生拥塞时各连接能公平地共享网络资源。产 生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据 包丢失会导致各数 据流之间为争抢有限的网络资源发生竞争， 竞争能力强的数据流将到更多网络资源，从而损害了其他流的利 益。所以说没有拥塞，也就没有公平性问题。公平性问题 表现 在两方面：一是拥塞响应的TCP流和非拥塞响应的UDP流之间资 源享用不公平；二是TCP流之间资源享用的不公平。前者主要是 在发生拥塞时对拥塞指示 作出的不同反应造成的。由于TC

27、P流 具有拥塞控制机制，在收到拥塞指示后，源端会主动降低发送速 率；而UDP流由于没有端到端的拥塞控制机制，因此在收到拥 塞指示后，UDP不会降低数据发送速率。结果在网络拥塞时，拥 塞适应的TCP流得到的资源越来越少，非拥塞适应的UDP得到的 资源越来越多，从而导致了网络资源分配的不公平。网络资源分 配的不公平反过来会加重拥塞情况，甚至可能导致拥塞崩溃。对 于第二个不公平性问题，研究表明，不同的窗口大小、RTT值 及 数据包的尺寸都会影响 TCP 流对带宽的占用。窗口较大，或者 RTT较小，或者数据包较大的流往往能占用更多的带宽。3.3有线网络中TCP拥塞控制机制的改进3.3.1 针对对不必要

28、的超时重传和快速重传我们知道，当前的TCP应用主要有两种重传机制一快速重传和超 时重传。当TCP源端收到3个ACK副本时，就会触发快速重传机 制，此时源 端重传丢失的数据包并且将拥塞窗口大小减半。这 种情况下，TCP流往往能够很快从丢包中恢复过来，重新回到原 先的发送速率。但如果TCP源端没有收到3个ACK副本，例如 拥塞窗口大小小于4,那么TCP源端则需要等待相当长时间，以 便超时重发。这样，小窗口的TCP流就很容易陷入不必要的超时 重发，使其吞 吐量大大下降。为了避免这种不必要的超时重传，一种改进办法就是只要TCP源 端收到一个或者两个ACK副本，并且如果通告窗口允许，便继续 发送新的数据

29、包。这是因为只要收到ACK副本，就表明有数据 包已经离开网络被接受端接收了，而此时源端还无法判断数据包 是否被丢弃，根据“数据包守恒”原则，只要遵守拥塞窗口的规 范，也即同时在网络中传送的数据包数量不能超过拥塞窗口的大 小（以数据包为单位），源端就可以继续发送新的数据包。这种 机制称为限制传输机制 （Limited Transmit mechanism）,这种 机制对排序的数据包尤其有效。限制传输机制可以使小窗口的TCP流很快从丢包中恢复过来。例 如,对于拥塞窗口大小为4地TCP流,如果其第二个数据包丢失， 那么按传统地做法需要等待超时重传。而在限制传输机制下，当 源端收到对第三个数据包确认的

30、ACK副本时（ACK中要求源端发 送第二个数据包）,继续发送新的数据包,最终源端可以收到三 个 ACK 副本从而触发快速重传,从而减少了不必要的超时重传。3.3.2 针对乱序包和延迟包引起的重传在不少情况下，TCP源端推断认为数据包被丢弃了，从而导致重 传及拥塞窗口的减小,而实际上数据包并没有被丢弃。如果超时 时钟过早地到时了（事实上数据包或者ACK并没有丢失，只要能 够再等待一会儿并可收到ACK），源端便毫无必要地重发了数据 包，更严重的是拥塞窗口的减小，而实际上并没有数据包被丢弃。 类似地，如果由于数据包的乱序导致源端接收到3个ACK副本, 便会导致快速重传，TCP源端也毫无必要地重发了数

31、据包，并且 减小了拥塞窗口。对于前者，虽然可以通过更为精确地调节超时 时钟来减少不必要地超时重传，但要完全避免却是不可能的。同 样，对于后者，虽然可以通过提高快速重传算法的性能来减少不 必要的快速重传，但也不可能完全避免。对于拥塞窗口较大的流，比如大小为W,不必要地减小拥塞窗口 会导致其至少花费W/2 RTT时间恢复到原来拥塞窗口的大小，从 而使其性能大大下降，特别是在数据包持续出现乱序或者对RTT 的估算不很精确的情况下。持续乱序的数据包往往是由 于路由 的改变或者链路层重传受损的数据包引起的。为了使得在出现不必要的超时重传和快速重传情况下，TCP性能 能够更加健壮(robust), 种方法

32、就是在出现这些情况时向TCP 源端 发送有关的信息。这个工作已经由 D-SACK 扩展(duplicate-SACK extension)完成了。D-SACK 扩展允许 TCP 接受端在利用SACK选项来通报收到重复的数据包，从而TCP源 端能够正确地推断出接受端是否收到了重复地数据包。因此， D-SACK扩展使得TCP源端在重发后一个RTT时间内正确地推断 出重发是否必要。如果源端认为重发是不必要的，那么拥塞窗口 减半也就没必要了，源端就会将拥塞窗口大小和慢启动阈值分别 恢复到原来的值，这样拥塞窗口恢复到原来的大小只需1RTT时间而不是W/2 RTT时间了。3.3.3 一种新的拥塞控制机制X

33、CP针对目前基于窗口的 TCP 拥塞控制机制的不足，最近 MIT 的D.Katabi、C.Rohrs 和 UC Berkeley 的 M.Handley 共同提出了一 种新的互联网拥塞控制机制XCP(eXplicit Control Protocol)。 XCP源端维持有拥塞窗口 cwnd和回路响应时间RTT并且通过数 据包中的拥塞头(congestion header )将这两个值与路由器进 行通信。当XCP连接刚刚建立时，与TCP 一样，初始cwnd较小， XCP将其理想的发送速率填入到拥塞头中,如果链 路带宽允许， 则在一个RTT后就以次速率发送数据；如果链路带宽不足，则网 络会给出一个

34、发送速率，在一个RTT后源端就以此速率发送数据。在随后的数据包传输过程中，根据数据流入速率和链路带宽之间 的关系，路由器通知每个流是要增加还是减少拥塞窗口并将有关 信息填入到拥塞头中。如果在后面的传输过程中，有路由器拥塞 更加严重，则该路由器将拥塞头中的有关信息改写。最终该数据 包将获得传输过程中的瓶颈链路信息，并将传送给接收 端。接 收端再将次信息写入到确认包中传送给源端，源端依此信息对拥 塞窗口进行调整。通过将拥塞状态信息放入数据包中，XCP无需 路由器维持每流状态信息，扩展性较好。实验表明，与传统的TCP拥塞控制机制相比，XCP具有链路利用 效率高、公平性好、可扩展性强、排队时延小的优点，并且路由 器的开销也非常小。但XCP最终能否被标准化作为下一代互联网 的传输协议我们将拭目以待。