图6：Reno、Newreno 和 SACK 的cwnd变化
6
7
图7：Reno、NewReno 和 SACK的队列长度变化情况
SACK丢包情况 1 0.160008 0 32 2 0.168328 0 34 3 0.176648 0 36 4 0.184968 0 38 5 0.193288 0 40 6 0.201608 0 42 7 0.209928 0 44 8 0.218248 0 46 9 1.100168 0 145 10 2.256648 0 284 11 3.421448 0 424 12 4.577928 0 563 13 5.734408 0 702 14 6.899208 0 842 15 8.055688 0 981 16 9.212168 0 1120 NewReno丢包情况 1 0.160008 0 32 2 0.168328 0 34 3 0.176648 0 36 4 0.184968 0 38 5 0.193288 0 40 6 0.201608 0 42 7 0.209928 0 44 8 0.218248 0 46 9 1.205736 0 156 10 2.353896 0 294 11 3.510376 0 433 12 4.658536 0 571 13 5.806696 0 709 14 6.963176 0 848 15 8.111336 0 986 16 9.259496 0 1124 Reno丢包情况 1 0.160008 0 32 2 0.168328 0 34 3 0.176648 0 36 4 0.184968 0 38 5 0.193288 0 40 6 0.201608 0 42 7 0.209928 0 44 8 0.218248 0 46 9 1.869832 0 196 10 3.026312 0 335 11 4.174472 0 473 12 5.322632 0 611 13 6.479112 0 750 14 7.627272 0 888 15 8.775432 0 1026 16 9.931912 0 1165 表1：Reno、NewReno 和 SACK的丢包情况（drop_no, time, flow_id,seq_no）
通过实验结果，可以发现，Reno的cwnd变化情况，在大概0.6s左右发生了一次超时事件。在这段时间里，Reno的队列变化情况可知，由于传送端没有再继续送出新的数据（等待超时），所以瓶颈（r0与r1间）的缓冲区都是空的。
8
从图6 NewReno的cwnd的变化情况发现，在t=0.6s左右，NewReno一下送出了许多数据包，造成这种现象原因是NewReno在结束Fast Recovery时，由于一次ACK回来的数据包较多，再加上传送端的Sequence Number 已经在重送过程中后移，所以有可能造成传送端在重新进入Congestion Avoidance阶段时，马上送出很多数据包。与Reno不同，NewReno在这段时间中它的缓冲区不为空（图7）。通过SACK选项，传送端可以很明确地知道哪些数据包已经被接收端收到，并且直接针对部分遗失部分重送。因此，可缩短错误回复（Error Recovery）的时间，减少因为多数据包遗失造成超时的机会。
Vegas
Vegas利用RTT来控制拥塞，通过观察以前的TCP连接中RTT值的改变情况来控制拥塞窗口cwnd。如果发现RTT变大，那么Vegas就认为网络发生拥塞，并开始减小cwnd；如果RTT变小，Vegas则解除拥塞，再次增加cwnd。
[7]
图8：网络拓扑结构
图9：Vegas 的cwnd变化情况
9
其中，红色线条为tcp0的cwnd变化情况，绿色线条为tcp1的cwnd变化情况。从图中可以看到，在慢开始（Slow-start）阶段，cwnd的值大约经过2个RTT才会增加1倍。与Reno不同的是，当Diff的值介于α与β之间时，Vegas的cwnd值会维持在一个稳定的状态，我们可通过分析记录文件来观察队列的变化。值得注意的是，当有两条以上联机存在于网络时，Vegas还是能维持在稳定的状态而且不会因传送得太快而造成数据包丢失。因为，基本上Vegas的拥塞控制算法是一种“拥塞避免”方法。
图10：vegas队列变化情况（对应tcp0）
图10可以看到，大约在0s到0.6s之间，tcp0发送数据包，队列长度持续增长；0.6s到0.7s，网络发生拥塞，队列长度减小；0.7s到5s，网络稳定，队列长度维持基本不变。5s后，tcp1也开始发送数据包，使得队列中的数据包数突然激增，于5.8s时网络拥塞。随之，调整数据包的数目，于6s左右达到了新的平衡。
10