TCP历史版本分析比较及研究

1TCP历史版本分析比较及研究摘要TCP协议是一种面向连接的可靠运输协议。TCP通过拥塞控制机制来控制允许传送到网络上的数据量。按照拥塞控制方法的不同，TCP分为Tahoe,Reno,NewReno,Vegas,SACK五个版本。本文通过NS2模拟仿真实验，分析比较并评价不同的TCP版本。关键词：NS2；TahoeTCP；RenoTCP；NewRenoTCP；VegasTCP；SACKTCPAbstractTCPisaconnection-orientedunicastprotocolthatoffersreliabledatatransferaswellasflowandcongestioncontrolwhichusedtocontrolthethroughputtothenetwork.TherearefivedifferentTCPversionsincludingTahoe,Reno,NewReno,VegasandSACKaccordingtothecongestioncontrolalgorithm.Inthispaper,simulatethefiveTCPversionwithNS2,analyzing,comparingandevaluatingthedifferenceamongthefiveTCPVersions.KeyWords:NS2；TahoeTCP；RenoTCP；NewRenoTCP；VegasTCP；SACKTCP背景互联网最初源于美国国防部的ARPANET计划。早在70年代中期，ARPA为了实现异种网络之间的互联与互通，推出了TCP/IP体系结构和协议规范。时至今日，TCP/IP协议也成为最流行的网际互联协议，并由单纯的TCP/IP协议发展成为一系列以IP为基础的TCP/IP协议簇。TCP／IP协议簇为互联网提供了基本的通信机制。互联网采用的是无连接的端到端数据包交换，提供“尽力而为（besteffort）”的服务[1]，随着互联网用户数量的膨胀，网络的拥塞问题也越来越严重。因此，互联网上主要的互连协议TCP/IP的拥塞控制（congestioncontrol）机制对控制网络拥塞具有特别重要的意义。从70年代至今，TCP的拥塞控制机制经历多次的改进和调整，根据不同时期的TCP的拥塞控制机制的不同，从而诞生了几种不同的TCP版本。本文针对这几种不同的TCP版本[2]，在NS2中进行实验，并进行分析比较。2拥塞控制当网络中存在过多的数据包时，网络的性能就会下降，这种现象称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发生“拥塞崩溃”（congestioncollapse）现象。之所以会发生拥塞是因为网络能够提供的资源不足以满足用户的需求。这时，网络自身只能靠降低服务质量来继续为用户服务，也就是“尽力而为”的服务。虽然拥塞是因为资源不足而造成的，但是拥塞本身并不是一个静态问题，它是一个动态的问题，所以单纯的增加网络资源并不能解决拥塞。目前，网络对拥塞问题的控制主要基于TCP的拥塞控制。TCP通过拥塞控制窗口（CongestionWindow，简称cwnd）来控制允许被传送到网络上的数据报数量。在开始数据传送之前，TCP会先在传送端与接收端间建立一条网络联机，将要传送的信息分割成数个数据报，并按照封包编号通过网络层所提供的功能依次传送出去。当收到一个数据报时，TCP的接收端会返回一个ACK（Ackonwledgment，ACK）给传送端，以表示这个数据报已被收到。在整个传送过程中，TCP进行拥塞控制，以避免因为传送过快而造成网络拥塞[]。TCP拥塞控制[3,4,5]算法主要包括三个部分：加性增，乘性减；慢启动；对超时事件作出反应。TCP拥塞控制是通过控制一些重要参数的改变而实现的。TCP用于拥塞控制的参数主要有：(1)拥塞窗口（cwnd）:拥塞控制的关键参数，它描述源端在拥塞控制情况下一次最多能发送的数据包的数量。(2)通告窗口（awin）:接收端给源端预设的发送窗口大小，它只在TCP连接建立的初始阶段发挥作用。(3)发送窗口（win）:源端每次实际发送数据的窗口大小。(4)慢启动阈值（ssthresh）:拥塞控制中慢启动阶段和拥塞避免阶段的分界点。初始值通常设为65535byte。(5)回路响应时间（RTT）:一个TCP数据包从源端发送到接收端，源端收到接收端确认的时间间隔。(6)超时重传计数器（RTO）:描述数据包从发送到失效的时间间隔，是判断数据包丢失与否及网络是否拥塞的重要参数。通常设为2RTT或5RTT。(7)快速重传阈值(tcprexmtthresh):：能触发快速重传的源端收到重复确认包ACK的个数。当此个数超过tcprexmtthresh时，网络就进入快速重传阶段。tcprexmtthresh缺省值为3。TCP拥塞控制的公平性是指发生拥塞时各源端（或同一源端建立的不同TCP连接或UDP数据报）能公平地共享同一网络资源。处于相同级别的源端应该得到相同数量的网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，争抢能力弱的数据流将受到更多损害。面向连接的TCP和其他的非TCP(例如无连接的UDP）在拥塞发生时对拥塞指示的不同反应和处理，导致对网络资源的不公平使3用问题，在文献[6]中提出了TCP-Friendly的概念。实验实验环境本文所进行的模拟仿真环境为：Ubuntu12.04+NS2。Tahoe与RenoTCPTahoe是早期的TCP版本，它包括了3个最基本的拥塞控制算法“慢启动”、“拥塞避免”和“快速重传”。Reno在Tahoe基础上增加了“快速恢复”算法。在该实验中主要对Tahoe和Reno的拥塞窗口大小的变化进行观察。图1：Tahoe和Reno实验网络拓扑图图2：Tahoe和Reno的平均吞吐量4图3：Tahoe和Reno的cwnd窗口变化图3中，Tahoe开始执行时，先由slow-start（SS）开始，cwnd超过ssthresh时进入拥塞避免（CA）阶段。由于传送到网络上的丢包不断增加，当超出允许能传送到网络上的个数时，路由器开始丢包。当数据报遗失时，Tahoe会将ssthresh设为发现数据报遗失时的一半，接着将拥塞窗口的值设为1。Tahoe重新进入慢启动阶段。而Reno的ssthresh和拥塞窗口的值会被设置为先前拥塞窗口值的一半。由于结束Fastrecovery后，Reno中拥塞窗口的值由先前拥塞窗口值的1/2开始增加，所以得到的平均吞吐量比Tahoe大一些（图2）。Reno、NewReno和SACKNewReno跟Reno在只有一个数据包遗失的情况下，其机制是一样的。当同时有多个packet遗失时，NewReno就显示出了它的优势。NewReno在收到PartialACK时，并不会立即结束Fast-recovery，相反，NewReno的传送端会持续地重送PartialACK之后的数据包，直到将所有遗失的数据包重送后才结束Fast-recovery。这使得NewReno的传送端在网络有大量数据包遗失时不需等待Timeout就能更正此错误，减少大量数据包遗失对传输效果造成的影响。NewReno大约每一个RTT时间可重送一个遗失的数据包，在Fast-recovery阶段，若允许的话，传送端会继续送出新的数据包，以增加链路的使用率。5SACK(SelectiveAcknowledgment，选择性确认)使TCP只重新发送交互过程中丢失的包，不用发送后续所有的包，而且提供相应机制使接收方能告诉发送方哪些数据丢失，哪些数据重发了，哪些数据已经提前收到了。图4：网络拓扑实验图（BufferSize为15）图5：Reno、NewReno和SACK平均吞吐量图5显示了Reno，NewReno和SACK的平均吞吐量，通过将队列的大小设置为15个数据包，经计算发现，当路径上的数据包超过16.44个时，就会开始丢包。此外，通过实验发现，SACK和NewReno的平均吞吐量要比Reno大。6图6：Reno、Newreno和SACK的cwnd变化78图7：Reno、NewReno和SACK的队列长度变化情况SACK丢包情况NewReno丢包情况Reno丢包情况10.16000803220.16832803430.17664803640.18496803850.19328804060.20160804270.20992804480.21824804691.1001680145102.2566480284113.4214480424124.5779280563135.7344080702146.8992080842158.0556880981169.2121680112010.16000803220.16832803430.17664803640.18496803850.19328804060.20160804270.20992804480.21824804691.2057360156102.3538960294113.5103760433124.6585360571135.8066960709146.9631760848158.1113360986169.2594960112410.16000803220.16832803430.17664803640.18496803850.19328804060.20160804270.20992804480.21824804691.8698320196103.0263120335114.1744720473125.3226320611136.4791120750147.6272720888158.77543201026169.93191201165表1：Reno、NewReno和SACK的丢包情况（drop_no,time,flow_id,seq_no）通过实验结果，可以发现，Reno的cwnd变化情况，在大概0.6s左右发生了一次超时事件。在这段时间里，Reno的队列变化情况可知，由于传送端没有再继续送出新的数据（等待超时），所以瓶颈（r0与r1间）的缓冲区都是空的。9从图6NewReno的cwnd的变化情况发现，在t=0.6s左右，NewReno一下送出了许多数据包，造成这种现象原因是NewReno在结束FastRecovery时，由于一次ACK回来的数据包较多，再加上传送端的SequenceNumber已经在重送过程中后移，所以有可能造成传送端在重新进入CongestionAvoidance阶段时，马上送出很多数据包。与Reno不同，NewReno在这段时间中它的缓冲区不为空（图7）。通过SACK选项，传送端可以很明确地知道哪些数据包已经被接收端收到，并且直接针对部分遗失部分重送。因此，可缩短错误回复（ErrorRecovery）的时间，减少因为多数据包遗失造成超时的机会。VegasVegas[7]利用RTT来控制拥塞，通过观察以前的TCP连接中RTT值的改变情况来控制拥塞窗口cwnd。如果发现RTT变大，那么Vegas就认为网络发生拥塞，并开始减小cwnd；如果RTT变小，Vegas则解除拥塞，再次增加cwnd。图8：网络拓扑结构图9：Vegas的cwnd变化情况10其中，红色线条为tcp0的cwnd变化情况，绿色线条为tcp1的cwnd变化情况。从图中可以看到，在慢开始（Slow-start）阶段，cwnd的值大约经过2个RTT才会增加1倍。与Reno不同的是，当Diff的值介于α与β之间时，Vegas的cwnd值会维持在一个稳定的状态，我们可通过分析记录文件来观察队列的变化。值得注意的是，当有两条以上联机存在于网络时，Vegas还是能维持在稳定的状态而且不会因传送得太快而造成数据包丢失。因为，基本上Vegas的拥塞控制算法是一种“拥塞避免”方法。图10：vegas队列变化情况（对应tcp0）图10可以看到，大约在0s到0.6s之间，tcp0发送数