用Internet网关保护和优化TCP业务的带宽*

*该课题由国家自然科学基金（69882003）和国家教育部博士学科点专项科研基金（98061409）资助

　　随着光纤通信技术的进步，下层网络可以提供的链路带宽日益增加。然而，用户需求也在变化和增长，在目前的通信网中，带宽仍然无法完全满足用户需求，尤其在广域网和骨干链路上，带宽被视为一种十分宝贵的资源，可以预见，在实用化的密集波分复用(DWDM)技术成熟并大规模使用之前，这种带宽缺乏的现象还会继续存在。因此，带宽的保护和优化利用是通信网领域一项很值得研究的技术问题。

　　尽管今后的通信网有可能支持较为丰富的优先级，但如果我们从目前Internet中的业务入手进行分析，可以看到，几乎所有的业务都属于Best－effort(尽力传输)业务，从拥塞控制的角度看，这些Best－effort业务又可分为两种不同的类型，一种是适应性业务(如TCP)，另一种是非适应性业务(如UDP)。非适应性业务十分简单，信源在发送数据时，并不考虑网络的拥塞状况，即使网络拥塞导致数据丢失，信源也不会为减轻拥塞而降低发送速率，这种业务缺乏端到端的拥塞控制机制。与之相比，适应性业务会根据网络拥塞状况降低发送速率。

　　传输控制协议(TCP)业务是一种典型的适应性业务。TCP具有一套端到端的拥塞控制机制，包括慢启动、拥塞避免、快速恢复、快速重传(Tahoe TCP除外)等几个部分[1]。它采用加性增大、乘性减小(AIMD)的窗口变化策略以及指数后退算法缓解和避免Best－effort业务在网络中的拥塞。如果信源的重传计时器超时或收到一定数目的重复确认分组，就认为网络拥塞，于是平均发送速率减半，减半靠慢启动门限、拥塞窗口和重传超时(RTO)等参数来具体实现；反之，如果信源未发现网络拥塞，就按每往返时延(RTT)增加1个TCP段的线性速率增大拥塞窗口。

　　虽然在以往的大多数情况下，TCP的拥塞控制策略是行之有效的，但随着Internet中引入非适应性业务(如以UDP为传输层协议的IP电话)，TCP拥塞控制的效果将被削弱，TCP的带宽将被缺乏拥塞控制的业务抢占。而且，在Internet中，即使某些业务使用了端到端的拥塞控制机制，也不能确保它们遵循TCP的标准，如果它们比标准TCP更激进，也会抢占本应由TCP业务使用的带宽。情况严重时，这些新业务的加入甚至还可能危及Internet的正常运行，导致拥塞崩溃。由于Internet支持越来越多的音频和视频流，如果不采取相应的措施对业务流进行调节和控制，这种危险将日益增加。

　　本文将这些可能抢占TCP带宽、妨碍TCP正常通信的业务统称为非TCP友好业务。考虑到Internet网关在IP数据转发的过程中处于核心地位，而TCP是目前Internet中应用最为广泛的传输层协议，本文拟对用Internet网关保护和优化TCP业务带宽的问题及其解决措施作一个分析与总结，并给出研究建议，以供参考。

　　1 仅有适应性业务时面临的问题

　　当网络中仅有适应性业务时，在带宽的优化问题上，主要考虑的指标是有效吞吐量(即除去所有重传的分组后得到的吞吐量)和均衡的带宽分配。让我们先来看两个实验结果。

　　(1)实验1：实测IP分组长度和TCP吞吐量的关系

　　国外有研究表明，如果IP分组长度设置不当，在FTP应用中，155Mbit/s的IP over ATM网络(OC－3线路)只能获得4Mbit/s的传输速率[2]。我们也利用自行设计的软件Tapwin在10Mbit/s的以太网上实测了两台PC之间的有效吞吐量[3]。当RTT约为0.8ms时，不同长度的IP分组下对应的TCP 有效吞吐量如表1所示，其中，1 500字节的IP分组长度达到以太网的最大传输单元。由表1可见，TCP有效吞吐量随IP分组长度的增加而增加。

表1　TCP有效吞吐量随IP分组长度的关系

　　如果IP分组长度太短，而网络对分组的处理速度有限，则必然导致有效吞吐量降低。即使链路仅承载一条TCP连接，带宽也无法充分利用。

　　(2)实验2：TCP最大窗口和有效吞吐量的关系

　　利用NS 仿真器 (Version 2.1b6)[4]，我们构造了图1所示的仿真网络。TCP流由FTP应用驱动。这里仅给出Reno TCP的仿真结果(经比较，Tahoe、New Reno、Sack的结果也与此类似)。

图1　仿真网络（实验2）

　　该实验比较了TCP最大窗口和有效吞吐量在不同链路时延下的关系，结果见图2。图中，x轴代表TCP最大窗口(以段为单位)。通常，一个段的TCP数据在IP层将被封装为一个IP分组。S与G1、D与G2间的链路时延均为1ms，G1与G2间的链路时延在各次实验中分别为1、3、5、7、10ms，图2中示出的时延值即G1与G2间的链路时延。各链路的带宽均为10Mbit/s。由图2可见，在链路时延一定时，随着TCP最大窗口的增加，有效吞吐量也将增加，最后将趋于一个饱和值，它大致等于链路的固有带宽扣除附加开销后的剩余部分。在TCP最大窗口一定时，链路时延增加，有效吞吐量减小。欲使链路带宽充分利用，TCP最大窗口应和该TCP连接的带宽时延积(BDP)相当。

图2 TCP最大窗口与有效吞吐量的关系

　　综合上述两个实验可知，如果有多条TCP连接共享链路，即使这些TCP使用完全相同的版本，IP分组较长、TCP最大窗口较大、RTT较短的连接也将占用较大的带宽，这是TCP业务带宽分配不均衡的一个主要原因。

　　另外，TCP最大窗口越大、IP分组越长，业务突发性也就越大，网关的缓存就越有可能溢出。研究表明，缓存溢出容易导致所有途径该网关的TCP连接同时出现分组丢失，继而同时降低发送速率，一段时间后，又一齐增加发送速率，从而引起吞吐量震荡(在一个时候，缓存溢出，丢失数据，而另一个时候，缓存又可能为空，链路带宽不能充分利用)，这就是所谓的全局同步效应[5-7]。这个问题不能仅靠增加缓存容量来解决。如果一味增加缓存容量，排队时延也会相应增加，不利于对时延敏感的业务，更严重的是，有可能因陈旧分组过多，引起拥塞崩溃[10]。

　　如果网络中仅有TCP业务，通过在网关处实现主动队列管理[6]，上述问题可以获得一定程度的解决。

　　2 主动队列管理

　　Internet中传统的队列管理机制基于尾丢弃(Tail Drop)技术，它的优点在于简单，但却引起两个明显的问题，一是带宽的分配不均衡，二是队列长时间处于满状态。

　　由于TCP将分组丢弃视作网络拥塞的信号，如果能在缓存溢出之前就丢弃一些分组，则可以提前让信源降低发送速率，进而将平均排队时延控制在一定的范围内。这便是主动队列管理技术。

　　随机早期检测(RED)就是一种典型的主动队列管理的算法。RED中由avg计算p的过程如下(其中gentle为可选参数)：

If avg<minth
p←0
Else if minth<avg<maxth
p←maxp(avg－minth)/(maxth－minth)
Else if(maxth<avg<2maxth)and(gentle=true)
p←avg(1－maxp)/maxth＋2maxp－1
Else p←1

　　RED中有三个预先设定的门限参数，分别表示为minth、maxth、maxp。minth代表最小队列门限，maxth代表最大队列门限，maxp代表最大随机丢失概率门限。，avg是以指数加权移动平均(EWMA)计算得到的平均队长(之所以选择avg代替当前的实际队长参与评估，是为了容纳一定限度的突发业务)。如果avg小于minth，RED算法不丢弃任何到达分组，即丢失概率p为0。如果avg位于minth和maxth之间，就按概率p丢弃到达分组，p的大小与avg的大小成线形关系，这个线形关系的一端是avg=minth、p=0，另一端是avg=maxth、p=maxp(0<maxp<1)。当avg大于maxth，又按gentle参数取true(真)还是取false(假)分为两种情况。如果gentle=false，则p=1；如果gentle=true，则p的大小与avg的大小成斜率更大的线形关系，这个线形关系的一端是avg=maxthh、p=maxp，另一端是avg=2maxth、p=1。当avg大于2maxth时，无论gentle取值如何，p都为1，即丢弃所有到达分组。

　　最初的RED算法没有gentle参数(相当于gentle = false)，该参数的使用可以平滑p的变化过程，使p不会因为avg短时达到maxth而出现突变，有助于增强算法的健壮性。RED算法可以从总体上减少分组丢失数、增加有效吞吐量/时延比。另外，由于正常情况下的随机丢失概率很低(通常小于0.01)，在一定程度上避免了全局同步效应。

　　通过对RED中分组丢弃记录的研究可以发现，速率较高的流，分组丢弃也较多[3,9]。如果这些流都属于适应性业务，较多的分组丢弃会较大地降低发送速率。虽然RED未提供严格均分带宽的机制，但这在一定程度上仍有利于均衡TCP的带宽分配。

　　如果除TCP外，网络中还存在一些激进的适应性业务(如非标准的TCP业务)，也会影响TCP的带宽分配，这时，主动队列管理若不奏效，还可通过公平队列管理和针对特定流的分组丢弃来保护TCP业务的带宽。

　　3 适应性业务与非适应性业务并存时面临的问题

　　在以往的大多数情况下，Internet以适应性业务为主，TCP的拥塞控制策略是行之有效的，在主动队列管理的辅助下，各TCP流能共享链路带宽。然而，随着非适应性业务的加入，TCP拥塞控制的效果将被削弱，带宽的分配和使用情况将发生明显的变化。

　　(1)实验3：适应性业务和非适应性业务的有效吞吐量(尾丢弃队列)

图3 仿真网络（实验3-6）

　　为了分析加入非适应性业务后带宽的使用情况，我们从最简单的尾丢弃队列(Buffer size = 30)入手，构造如图3所示的仿真网络。它包含6个信源节点(S1到S6)和6个信宿节点(D1到D6)，以及2个网关(G1和G2)。各条链路的带宽均为10Mbit/s，从S到G1、G1到G2、G2到D点的链路时延分别为3ms、3ms、2ms。6个业务流分别从Si出发，经G1、G2到Di(i = 1,2,···,6)，其中4个是TCP流，2个是用户报协议(UDP)流，TCP流由FTP应用驱动，UDP流由恒定比特率(CBR)应用驱动。UDP的发送速率均为9Mbit/s。TCP流在0s到2s内陆续启动，第一个UDP流在5s时启动，第二个UDP流在8s时启动，仿真运行15s。实验结果见图4，粗线代表TCP的总有效吞吐量，细线代表UDP的总有效吞吐量(对UDP而言，因为没有分组重传，它等效于吞吐量)。从图4可见，在第一个UDP流启动之前，带宽由TCP使用。当第一个UDP流开始发送数据之后，TCP可以得到的总带宽急剧下降(尽管有4个TCP流)，而当第二个UDP流启动后，TCP带宽进一步恶化，趋近于0。几乎所有的带宽都被UDP占据。

图4　有效吞吐量的变化情况（尾丢弃队列）

　　(2)实验4：适应性业务和非适应性业务的有效吞吐量(RED队列)

　　如果将尾丢弃队列改为RED队列(其它条件仍和实验3相同)，RED按字节模式操作，其参数设置如下：Wq=0.002, minth=5, maxth=15，maxp=0.01, wait=false, gentle=true。实验结果示于图5。图5与图4十分相似，表明RED队列在高速率非适应性业务的时候不奏效。

图5　有效吞吐量的变化情况（RED队列）

　　从上述两个实验可以看出，在网络拥塞时，高速率的非适应性业务会抢占TCP业务的带宽，甚至会使所有与其共享链路的TCP 有效吞吐量接近于0。即使采用主动队列管理，这个问题也不能获得解决。

　　要从实质上避免拥塞崩溃，只有两条途径：

• 继承目前Internet中业已广泛使用的端到端拥塞控制机制，在网络拥塞时，信源通过自适应的方式降低发送速率，使拥塞缓解。
  
• 采用类似于ATM网的虚电路转发机制和连接接纳控制(CAC)机制，拒绝接纳因网络资源不足而无法递交的分组。
  

　　4 公平队列管理

　　在适应性业务和非适应性业务并存的环境中，公平队列管理可以对TCP流起到一定的保护作用。FQ (Fair Queueing)、WFQ (Weighted Fair Queueing) 和SFQ (Stochastic Fair Queueing)等都属于公平队列的算法。而Round－Robin、WRR(Weighted Round－Robin)的作用也与之相似。

　　(1)实验5：UDP的发送速率增加时，TCP 所获得的有效吞吐量

图6 UDP发送速率与TCP有效吞吐量的关系

　　本实验仍然采用图3的仿真网络，旨在分析多个TCP流和一个UDP流竞争带宽的结果。UDP流在0s启动，5个TCP流在0s到2.5s的期间内陆续启动。图6示出了两组仿真结果，一组采用的是RED队列(其参数设置与实验4相同)，另一组采用的是SFQ队列，每一组结果包含10个点，分别对应于UDP发送速率从0到10Mbit/s的10次仿真，x轴代表UDP的发送速率，y轴代表各次仿真的TCP总有效吞吐量在3s到15s内的平均值(之所以从3s开始计算，是考虑到有效吞吐量需要一段时间才能进入稳态)。图6表明，如果非适应性业务的数目不多，公平队列管理对保护TCP带宽是有效的。

　　(2)实验6：UDP流的数目增加时，TCP 所获得的有效吞吐量

图7 UDP流的数目与TCP有效吞吐量的关系

　　本实验旨在分析UDP流的数目增加对TCP带宽的影响，结果示于图7。图中的x轴代表UDP流的数目，分别从1增加到5，各个UDP的发送速率均为5Mbit/s。y轴代表各次仿真的TCP总有效吞吐量在3s到15s内的平均值。图7表明，随着UDP流数据的增加，TCP 有效吞吐量下降。如果非适应性业务流的数目太多，即使采用公平队列管理，TCP也只能得到很少的带宽。

　　公平队列可以为每个流分配一定的带宽，但却不能从根本上避免拥塞崩溃。它不“惩罚”那些高速率的非适应性业务流，因而对端到端拥塞控制机制的实现没有刺激作用。

　　公平队列的另一个不足是与先到先服务(FCFS)队列比较而言的。公平队列的实现比FCFS队列复杂，且复杂度随着流的数目的增加而增加。FCFS队列可以对短的突发业务以突发方式进行传输，而公平队列则会导致突发业务的“展宽”和通信时间的延长(TCP要等到信源收到最后一个分组的确认，才能结束正常通信)。因此，我们考虑另一个措施。

　　5 针对特定流的分组丢弃

　　如果Internet网关能检测出非TCP友好流，就可以对这些流进行专门的处理，以保护TCP的带宽。

　　为了发现非TCP友好流，我们必须考察TCP发送速率的内在规律。如果假设TCP信宿每收到一个分组就回发一个确认(ACK)，可以利用式(1)来粗略地估算TCP的发送速率[10]。　

　　式中，R代表TCP的发送速率(以B/s为单位)，B代表该TCP连接的分组长度(以字节为单位)，RTT是往返时延(以s为单位)，p是分组丢失率。

　　另一个更精确的公式考虑了TCP重传超时，最初在文献[11]中给出，后又在文献[8]中简化为：

　　式中，Brtt代表TCP在RTT时间内可以发送的分组数。

　　如果Internet网关对不同流的到达速率进行监测，就可以与(1)、(2)两式给出的TCP发送速率比较。那些实际到达速率高于式中所描述的速率的流，可以被视为非TCP友好流。然后，就可以针对这些流进行分组丢弃，就此，本文提出两种处理建议：

　　(1) 针对特定的非TCP友好业务流，根据其速率超过标准TCP速率的多少，计算分组丢失概率，按此概率丢弃来自该业务流的后续分组。

　　(2) 当发现非TCP友好业务流后，丢弃所有来自该流的后续分组，并继续监测其到达速率，直至它降低速率，不对TCP构成威胁时，再让它的分组通过网关，参考文献[8]中Flow－valve采用的就是这种方法。

　　用分组丢弃的方法保护TCP的带宽，可以对非TCP友好流加以较大的限制，更能刺激端到端拥塞控制机制的推广，从而在一定程度上减轻拥塞崩溃的危险。

参考文献

1 M Allman,V Paxson.TCP Congestion Control. RFC 2581, April 1999
2 R Melle,C Williamson, T Harrison. Diagnosing a TCP/ATM Performance Problem: A Case Study. In Proc Globecom97, 1997
3 温蜀山,孙海荣,李乐民. 用Tapwin实测TCP/IP网络的性能. CERNET第5届年会,1998,9
4 UCB/LBNL/VINT Network Simulator－ns(version 2). http://www.isi.edu/nsnam/ns/
5 S Floyd, V Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Trans Networking, Aug 1993,1(4):397－413
6 B Braden, et al. Recommendations on Queue Management and Congestion Avoidance in the Internet. RFC2309, April 1998
7 V Jacobson. Congestion Avoidance and Control. In Proc. SIGCOMM'88, Aug 1988,314－329
8 K Cho. Flow－Valve: Embedding a Safety－Valve in RED. In Proc Globecom'99, 1999
9 S Floyd, K Fall, K Tieu. Estimating Arrival Rates from the RED Packet Drop History. http://www.aciri.org/floyd/end2end－paper.html
10 S Floyd, K Fall. Promoting the Use of End－to－End Congestion Control in the Internet. IEEE/ACM Trans Networking,Aug 1999 ,7(4):458－472
11 J Padhye, et al.Modeling TCP Throughput: A Simple Model and its Empirical Validation. In Proc SIGCOMM98, 1998

[摘要] 文章通过多个实验(包括实测和仿真)，分别分析了仅有适应性业务和适应性业务与非适应性业务并存时TCP带宽的使用与分配问题，并就保护和优化TCP带宽和缓解拥塞崩溃介绍了Internet网关可以采取的几种措施(主动队列管理、公平队列管理以及针对特定流的分组丢弃)，同时给出了研究建议。

[关键词] 网关 传输控制协议 带宽 主动队列管理 公平队列管理

[Abstract] Based on experiments (including real test and simulation), this paper analyzes the problems of allocating and making use of TCP bandwidth separately in the circumstances when only adaptive traffic exists and when both adaptive and non－adaptive traffic coexist with each other. To protect and optimize TCP bandwidth, as well as decrease the danger of congestion collapse, the Internet gateways can adopt several measures (active queue management,fair queue management,or dropping the arrival packets from certain flows).This paper also gives the suggestion for further research.

[Keywords] Gateway TCP Bandwidth Active queue management Fair queue management