华中科技大学计算机通信与网络实验报告-基于NS2的协议分析实验.docx

实验二基于NS2的协议分析实验2. 1环境硕件配置：Intel Core i5-7300HQ处理器、8.00GB内存平台信息：Windows 10操作系统下Ubantu NS2模拟平台及可视化NS2编辑器2.2实验要求熟悉NS2模拟平台，并利用NS2模拟平台完成实验内容实验内容共三项第一项实验一一仿真与测试TCP和UDP协议• 网络性能的比较• 公平性研究与探讨第二项实验一一仿真与测试TCP协议中的不同拥塞控制算法（端到端拥塞 控制）• TCP Tahoe 算法、TCP Reno 算法、TCP New Reno 算法、TCP SACK 算法、TCP FACK算法和TCP Vegas算法• 性能对比• 拥塞窗口、阈值变化、吞吐量、网络效率、带宽利用率•拥塞控制能力对比第三项实验一一仿真与测试不同IP拥塞控制策略（中间节点排队策略）• 先进先tB FIFO.随机早期检测算法RED、显示拥塞指示算法ECN、公平排队算法FQ、随机公平排队算法SFQ、加权公平排队算法WFQ> 性能对比> 阈值变化、吞吐量、网络效率、带宽利用率> 拥塞控制能力对比2.3实验步骤说明及结果分析 2. 3. 1第一项实验的步骤及结果分析A.实验步骤① 进行网络节点和链路的设置，并完成对链路层、传输层和应用层的配置。

设 置参数包括TCP包大小5000, UDP包大小10000c FTP起始时间为1,终止时 间10CBR起始时间1,终止时间4,包总数lOOOo如图2.1图2.1网络节点的拓扑② 生成并执行脚本，观察数据传输的Nam演示发现存在包的丢失如图2.2所示图2.2出现丢包现象B・结果分析① 包重传率分析实验结果，抽样TCPk TCP2、TCP3和TCP4,发现每一 TCP均存在 重传现象这和实验中出现的丢包现象是相符合的重传率分别是：0.018469658, 0.034602076, 0.04375, 0.069148935 表 2.1 所示表2.1 TCP存在重传TCP序号重传率TCP序号重传率10.01846965820.03460207630.0437540.069148935分析UDP的结果，发现UDP也存在一定的重传这可能是应用层存在重传 的原因也可能是软件本身存在的bug）结果如表2.2所示表2.2 UDP包重传率UDP序号重传率UDP序号重传率80.2329450890.08985025100.16472545110.2279534120.32445922② 网络抖动分析网络抖动，发现TCP传输的节点nl到n0存在抖动现象，如图2.3所示。

而与之相对的，UDP不存在网络抖动的现象，如图2.4所示网络抖动是最大延迟和最小延迟Z间的时间差值它反映了传输往返时延的 变化通过网络抖动曲线，可以看出一个网络的稳定性对两个图进行比较可以 发现，TCP传输存在网络的抖动，而UDP传输基木没有网络的抖动这是因为 二TCP存在拥塞控制协议，因此，当TCP受到UDP的挤压时，或TCP之间相互 竞争时，就可能引起节点收到包的延时而产生抖动从图2.3中还可以看到，在 前段时间里，TCP的抖动较为频繁，这可能是因为TCP同时受到UDP的竞争和 其他TCP的竞争所致而在后面的时间里，抖动频率下降，这是可能因为UDP 的传输己完成，竞争的来源减少了0.2000.1750.1500.1250.100 启 0.075 * 0.0500.0250.0000025-0.050网络抖动分祈0 50 100 150 200 250 300 350包序号图2.3网络抖动分析从网络抖动分析0.2000.1750.1500.1250.1000.0750.0500.0250.0000 50 100 150 200 250 300 350 400 450 500 550 600句反2图2.4网络抖动分析从n8-n7③ 网络吞吐量图2.5显示的是TCP协议的吞吐量的分析曲线（因为每条TCP的吞吐量基 木相同，因此只选取其中的一个作为代表），图2.6显示的是UDP协议的吞吐量 的分析曲线。

对于两条分析曲线，可以明显观察到TCP的吞吐量存在较大的波动，而UDP 的吞吐量从直线上升到最大值后就保持恒定之所以UDP呈现出直线增长和恒定吞吐，是因为UDP没有拥塞的控制，会 最大程度地使用带宽，从而实现以恒定的速率传输数据而TCP的传输是存在拥塞控制协议的，TCP的吞吐量曲线会存在不断的波 动在TCP的吞吐量分析图中可以观察到，在第1秒到第4秒间，吞吐量出现 了下降的情况这是由于，在这段吋间里，UDP在进行传输，对TCP的吞吐量 带宽进行了压制而在4s之后，UDP传输完成，TCP的吞吐量又再次回刃二图2.5 TCP吞吐量吞吐■分析1,5001,2501,000 QH 占 血 75050025001.00 1.25 1.50 1.75 2.00 2.25 2.50 2.75 3.00 3.25 3.5C 3.75 4.00 时间（秒）图2.6 UDP吞吐量分析④ 端到端时延TCP的端到端时延如表2.3所示，UDP的端到端时延情况如表2.4所示从表中可以清楚地看到，使用TCP协议的各节点Z间存在有端到端的时延 情况，而使用UDP协议的各个节点之间不存在端到端的时延究其原因，是因 为TCP的传输协议是面向连接的；也就是说，在传输过程中，TCP需要在端到 端之间维持连接的状态，因而需要根据网络状况来控制拥塞。

与之相对的，UDP 协议是非连接的协议UDP的端到端之间不建立可靠的连接UDP的发送方只 负责将报文尽可能快地发送到通信网络上，而UDP的接收方，只需要每次从来 临的消息队列中读取一段报文即可因此，UDP不存在端到端的时延表2.3 TCP的端到端时延TCP序号端到端时延TCP序号端到端时延10.10172521.10292531.10412541.10532551.10652561.107725表2.4 UDP的端到端时延UDP序号端到端时延UDP序号端到端吋延102030405060⑤ 网络公平性从网络吞吐量、网络抖动和端到端吋延可以看岀TCP协议对网络拥塞的控 制；这种控制使其他节点能够获得相对公平的带宽而与之相对的，UDP协议 会尽可能地利用网络带宽，抢占尽可能多的资源供自己使用因此，从TCP的 角度来看，UDP是不公平的传输层协议2. 3. 2第二项实验的步骤及结果分析A・实验步骤①在实验一的基础上，将节点nl・n6所用的TCP算法，分别改为TCP Tahoe.TCP Reno> TCP new Reno> TCP SACK、TCP FACK 和 TCP Vegas 算法其网络 拓扑图如图2.7所示。

图2.7实验二网络拓扑图② 用Nam进行演示，并对脚本进行分析③ 比较6种拥塞控制算法对拥塞窗口、阈值变化、吞吐量、网络效率、带宽 利用率的影响B.结果分析1 .TCP Tahoe 算法TCP Tahoe算法是最为传统的慢启动、拥塞避免算法当出现3个冗余ACK 或丢包时，拥塞窗口都会下降为1,进入慢启动阶段①拥塞窗口分析TCPTahoe算法的拥塞窗口大小随时间的变化如图2.8所示初始时，TCP 的拥塞窗口大小为1 （1个MSS人小）在1秒后，TCP传输开始，并进入慢启 动阶段在这一阶段，TCP的拥塞窗口以指数速度增加但由于UDP对带宽的 压制，TCP很快就出现了 3个兀余ACK （或丢包）；在岀现3个冗余ACK （或 丢包）后，拥塞窗口下降到1,门限值下降为了原来的拥塞窗口的一半在1・2秒内，继续出现3个冗余ACK （或丢包）的情况，因此，门限值继续下降在4s后，UDP的传输完成此后，TCP的传输不再受到UDP的压制，因 此拥塞窗口又开始上升在上升过程中，很快就超过了门限值；因此，在Z后一 直采用的是“加性增”直到接近8s时，又出现3个冗余ACK （或丢包），拥塞 窗口乂下降为1之后，乂重新开始指数增加；达到门限值后，再开始“加性增”。

拥塞窗口分析A-KOBI17.5 —0123456789 10时间（秒） pCWnd —WndQ.50.5Q.5.052.a7.52.a1 1 1图2.8 TCP Tahoe算法拥塞窗口②吞吐量分析如图2.9为TCP Tahoe算法的吞吐量分析在图中，可以看到，从1到1.4s期间，吞吐量呈指数上升状态，因为这一 时期拥塞窗口处于慢启动阶段而在1.4s之后，吞吐量骤降；因为此时带宽受 到了 UDP的压制，拥塞窗口降到了 lo在4s后，由于没有了 UDP的压制，TCP 的拥塞窗口逐渐增加，其吞吐量也逐渐上升吞吐■分析1,5001,2501,000750500250023456789 10时间（秒）图2.9 Tahoe的吞吐量分析2.TCP Reno 算法TCP Reno算法是基于TCP Tahoe的一种改进在Tahoe的基础上，TCP Reno 增加了快速恢复的机制即，在出现3个冗余ACK后，拥塞窗口仅会下降到原 来的一般，而不会直接降为1只有在出现丢包时，拥塞窗口才会下降为1①拥塞窗口分析TCP Reno算法的拥塞窗口大小随时间的变化如图2.10所示在图中，可以 明显观察到TCP Reno算法与TCP Tahoe算法的不同。

在第1.7 s吋，出现3个冗 余ACK后，TCP Ren o的拥塞窗口仅是下降到了原来的一半（而TCP Tahoe会下 降至1）在第7.1s时，TCP Reno也同样是下降到了原来的一般，而不会下降至0.0拥塞窗口分析02 3 4 5 6 7 8 9 10时间（秒）[―CWnd —Wnd|O 5• ・O 72 1O 552.1 1O 5• •O 7O 55 ?图2.10 TCP Reno算法拥塞窗口变化曲线②吞吐量分析和TCP Tahoe类似，在l・1.6s间，吞吐量快速上升在1.6・4s,拥塞窗口受 到UDP压制，吞吐量也相应地降低在4s后，吞吐量重新回升由T TCP Reno不会像TCP Tahoe那样频繁地将拥塞窗口调为1；因此TCPReno的总体吞吐量要大于TCP Tahoeo吞吐■分析2,0001,7501,500■ WO 占10 1,00075050025023456789 10时间（秒）图2.11 TCP Reno算法吞吐量分析0123456789 10时间（秒）-CWnd — Wnd0.03. TCP New Reno 算法TCP New Reno算法在TCP Reno的基础上再次对“快速恢复”进行了改进。

在快速恢复期间,TCP Reno在收到一个新的数据的ACK时就会退出快速恢复状 态，而TCP New Reno需要收到该窗口内的所有数据报的ACK后才会退出快速 恢。