TCP历史版本分析比较及研究
摘要
TCP协议是一种面向连接的可靠运输协议。TCP通过拥塞控制机制来控制允许传送到网络上的数据量。按照拥塞控制方法的不同，TCP分为Tahoe, Reno, NewReno, Vegas, SACK五个版本。本文通过NS2模拟仿真实验，分析比较并评价不同的TCP 版本。
关键词：NS2 ；Tahoe TCP；Reno TCP；NewReno TCP；Vegas TCP；SACK TCP
Abstract
TCP is a connection-oriented unicast protocol that offers reliable data transfer as well as flow and congestion control which used to control the throughput to the network. There are five different TCP versions including Tahoe, Reno, NewReno, Vegas and SACK according to the congestion control algorithm. In this paper, simulate the five TCP version with NS2, analyzing, comparing and evaluating the difference among the five TCP Versions.
Key Words: NS2 ；Tahoe TCP；Reno TCP；NewReno TCP；Vegas TCP；SACK TCP
背景
互联网最初源于美国国防部的ARPANET计划。早在70年代中期，ARPA为了实现异种网络之间的互联与互通，推出了TCP/IP体系结构和协议规范。时至今日，TCP/IP协议也成为最流行的网际互联协议，并由单纯的TCP/IP协议发展成为一系列以IP为基础的TCP/IP协议簇。TCP／IP协议簇为互联网提供了基本的通信机制。互联网采用的是无连接的端到端数据包交换，提供“尽力而为（best effort）”的服务[1]，随着互联网用户数量的膨胀，网络的拥塞问题也越来越严重。因此，互联网上主要的互连协议TCP/IP的拥塞控制（congestion control）机制对控制网络拥塞具有特别重要的意义。从70年代至今，TCP的拥塞控制机制经历多次的改进和调整，根据不同时期的TCP的拥塞控制机制的不同，从而诞生了几种不同的TCP版本。本文针对这几种不同的TCP版本[2]，在NS2中进行实验，并进行分析比较。
1
拥塞控制
当网络中存在过多的数据包时，网络的性能就会下降，这种现象称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发生“拥塞崩溃”（congestion collapse）现象。之所以会发生拥塞是因为网络能够提供的资源不足以满足用户的需求。这时，网络自身只能靠降低服务质量来继续为用户服务，也就是“尽力而为”的服务。 虽然拥塞是因为资源不足而造成的，但是拥塞本身并不是一个静态问题，它是一个动态的问题，所以单纯的增加网络资源并不能解决拥塞。目前，网络对拥塞问题的控制主要基于TCP的拥塞控制。
TCP通过拥塞控制窗口（Congestion Window，简称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）在拥塞发生时对拥塞指示的不同反应和处理，导致对网络资源的不公平使
2
用问题，在文献[6]中提出了TCP-Friendly的概念。
实验
实验环境
本文所进行的模拟仿真环境为：Ubuntu 12.04 + NS2。
Tahoe 与 Reno
TCP Tahoe是早期的TCP版本，它包括了3个最基本的拥塞控制算法“慢启动”、“拥塞避免”和“快速重传”。Reno在Tahoe基础上增加了“快速恢复”算法。在该实验中主要对Tahoe和Reno的拥塞窗口大小的变化进行观察。
图1：Tahoe 和 Reno实验网络拓扑图
图2：Tahoe 和 Reno的平均吞吐量
3
图3：Tahoe 和 Reno的cwnd窗口变化
图3中， Tahoe 开始执行时，先由slow-start（SS）开始，cwnd超过ssthresh时进入拥塞避免（CA）阶段。由于传送到网络上的丢包不断增加，当超出允许能传送到网络上的个数时，路由器开始丢包。当数据报遗失时，Tahoe会将ssthresh设为发现数据报遗失时的一半，接着将拥塞窗口的值设为1。Tahoe重新进入慢启动阶段。而Reno 的ssthresh和拥塞窗口的值会被设置为先前拥塞窗口值的一半。由于结束Fast recovery 后， Reno中拥塞窗口的值由先前拥塞窗口值的1/2开始增加，所以得到的平均吞吐量比Tahoe 大一些（图2）。
Reno、NewReno 和 SACK
New Reno跟Reno 在只有一个数据包遗失的情况下，其机制是一样的。当同时有多个 packet遗失时，New Reno就显示出了它的优势。NewReno在收到Partial ACK时，并不会立即结束Fast-recovery，相反，NewReno的传送端会持续地重送Partial ACK之后的数据包，直到将所有遗失的数据包重送后才结束Fast-recovery。这使得NewReno的传送端在网络有大量数据包遗失时不需等待Timeout就能更正此错误，减少大量数据包遗失对传输效果造成的影响。NewReno大约每一个RTT时间可重送一个遗失的数据包，在Fast-recovery阶段，若允许的话，传送端会继续送出新的数据包，以增加链路的使用率。
4
SACK(Selective Acknowledgment，选择性确认)使TCP只重新发送交互过程中丢失的包，不用发送后续所有的包，而且提供相应机制使接收方能告诉发送方哪些数据丢失，哪些数据重发了，哪些数据已经提前收到了。
图4：网络拓扑实验图（BufferSize为15）
图5：Reno、NewReno 和 SACK 平均吞吐量
图5显示了Reno，NewReno和SACK的平均吞吐量，通过将队列的大小设置为15个数据包，经计算发现，当路径上的数据包超过16.44个时，就会开始丢包。此外，通过实验发现，SACK 和 NewReno的平均吞吐量要比Reno大。
5