计算机网络实验六——TCP流量控制协议分析

【实验目的】

1、掌握TCP的流量控制机制;

2、理解TCP的零窗口通知及处理方法。

【实验步骤与结果记录】

要求:根据实验指导书中的实验内容和步骤,认真完成实验。采取截图、拍照等形式记录自己的实验步骤和结果。(可根据需要加页)

1.修改Linux系统参数 

(1)在Linux中,修改TCP连接的接收缓存参数,限制Linux分配的接收缓存为9032字节

2.创建虚拟网络拓扑

3.为虚拟网络拓扑中的各路由器配置静态路由

4.关闭网卡offload功能,将运输层封装时需要的计算还给CPU

5.打开两个终端,分别模拟主机ns56A和ns57C

利用网络空间命名ns56A和ns57C模拟两台通信的主机,模拟的主机和实验三相同

6.在主机ns56A上创建一个10K字节长度的文件备用

7.在主机ns57C上启动Wireshark,在接口tap57C上启动抓包

8.在主机ns57C上打开TCP服务程序,在主机ns56A上打开TCP客户程序,通过网络将主机ns56A上的10K.0文件发送到主机ns57C,并限制ns57C上的TCP服务程序延迟5秒再读取程序

(1)在4499端口打开TCP服务,nc进程延迟操作5秒,并将输出重定向到文件10K.1

(2)在主机ns56A的模拟终端中,打开TCP客户程序,指定TCP服务程序的IP地址和端口,并将输入重定向到文件10K.0

9.在Wireshark中停止抓包,保存结果并分析

【问题与分析】

1、在步骤8中,操作系统为主机ns56A上的TCP客户程序分配的端口号是多少?截图说明你的分析过程。

34612

2、在你的实验结果中,主机ns56A发送了多少字节数据后,收到了来自主机ns57C的零窗口通知报文?主机ns57C发送第一个零窗口通知报文之前,最后发送的那个ACK报文段中,窗口字段值是多少?收到第一个零窗口通知报文前,主机ns56A发送的最后一个数据报文段的序号字段值是多少?它包含多少字节数据?截图说明你的分析过程。

主机ns56A发送了9032字节数据后,收到来自主机ns57C的零窗口通知报文

最后发送的那个ACK报文段中,窗口字段值是344,不是86,因为还有一个窗口扩大系数4,所以是86*4

最后一个数据报文段的序号字段值是8689,包含344字节数据

15号报文的窗是344,那16号报文只能发344个字节了,这就是流量控制.

3、在你的实验结果中,主机ns56A一共发送了几个窗口探测报文。第一个窗口探测报文与第一个零窗口通知报文的时间间隔多少?随后的多个窗口探测报文之间的时间间隔分别是多少?在窗口探测报文中包含多少字节的数据?窗口探测报文中的序号字段值是多少?零窗口通知报文中的确认号字段值是多少?这两个值有什么关系?截图说明你的分析过程。

共发送4个窗口探测报文,第一个窗口探测报文与第一个零窗口通知报文的时间间隔为0.520191255-0.301351262=0.218839993s

之后的窗口探测报文之间的时间间隔分别是:

0.951641762-0.520191255=0.431450507s

1.790204031-0.951641762=0.838562269s

3.433134203-1.790204031=1.642930172s

零窗口探测报文没有数据

探测报文序列号是9032,零窗口通知报文确认号是9033,发的是9032,但是接受方已经接受了第9032个字节了的,这种报文为保护报文,也被用来做探测报文,接收方回一个9033表示希望接受第9033开始以后的数据。也就是+1的关系

 

  • 32
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
随着计算机和通信技术的发展,人们对 Internet 的需求已经越来越超乎想象,因此更 多、更合理的控制机制对现有网络的顺畅运作起着非常重要的作用,其中最基本、最关键 的就是拥塞控制,即如何有效防止或消除网络出现的拥塞,使网络基本运行在轻度拥塞的 最佳状态。 网络中的拥塞来源于网络资源和网络流量分布的不均衡性,它不会随着网络处理能力 的提高而消除。到目前为止,拥塞问题始终没有一个完美的解决方案。面对各种复杂的网 络环境,拥塞控制算法不但在设计方面存在一定的困难,在算法的性能评价方面也都缺乏 统一的标准。根据拥塞控制算法的实现位置,主要分为源端算法和链路算法两种:源端算 法在主机和网络边缘设备中执行,作用是根据反馈信息调整发送速率;链路算法在网络设 备(如路由器和交换机)中执行,作用是检测网络拥塞的发生,产生拥塞反馈信息。拥塞 控制算法设计的关键问题是如何生成反馈信息和如何对反馈信息进行响应。 TCP 协议是使用最广泛的源端算法,也是目前在 Internet 中使用最广泛的传输协议。 它包括慢启动、拥塞避免、快速重传和快速恢复四个阶段,其核心的拥塞避免算法采用一 种 AIMD(加性增加乘性减少)的窗口调节机制。TCP 协议从提出到现在虽然经历了几个 版本的不断改进,但在高带宽时延乘积网络不断扩大的今天,它的局限性也愈加明显,尤 其是 TCP 的拥塞控制算法对大的拥塞窗口响应很慢,发生拥塞时又降低窗口过快的问题。 近几年,在 TCP 协议的基础上提出了一些新的改进协议,如:HSTCP、STCP、H-TCP、 Fast-TCP、BIC 和 CUBIC 等,这些协议公布了它们各自的实现机制和算法,并对可扩展 性、带宽利用率、TCP 友好性、稳定性、RTT 公平性等性能进行衡量和评价,使网络的 性能以及解决拥塞问题的灵敏度等方面得到很大程度地改进和提高。虽然这些新的拥塞控 制协议的算法和实现机制各有千秋,但依然还不能说它们中有哪个能很好地解决现在网络 环境中面临的所有问题,真正实现一个简单又鲁棒性更好的拥塞控制协议,因此,端系统 的拥塞控制协议方面的改进依然在不断深入研究和探索的阶段,尤其在协议参数的修改方 面依然是研究的热点,如何在各个性能之间权衡取舍,以使网络能够运行在最佳状态,仍然值得我们去探讨。 本文从 STCP 和 CUBIC 出发,通过大量不同网络环境下的模拟实验,对它们以及 TCP 协议的性能进 行参照对比,得出各协议的拥塞窗口变化、吞吐量、稳定性、TCP 友好性、RTT 公平性等方面的比较 和分析结果,并从中找到契合点,对总体表现更好些的 CUBIC 协议实施改进。在众多实验结果中我 们发现:基于 CUBIC 协议的运行机制,在 TCP 友好性、RTT 公平性方面都明显优于 STCP,在可扩 展性和稳定性方面也表现出很好的性能,但 CUBIC 的拥塞窗口增长过于保守,且波动幅度与 STCP 相比也相对较大,即 CUBIC 在稳定性方面尚有较大的改进空间。STCP 是以稳定性著称的一种机制简 单的拥塞控制协议,基于其在检测到拥塞后的窗口减小机制与 CUBIC 基本一致,我们想到在保留 CUBIC 原有基本机制的情况下,结合 STCP 的窗口增长机制,将 CUBIC 的窗口增量和 STCP 的窗口 增量糅合,并保持 CUBIC 原有的最大、最小增量的限制机制不变,这样就使 CUBIC 窗口增量在原有 的增量限制范围内做合理且适当的提高,试验证明,这个新改进的算法具有比 CUBIC 更好的稳定性, 并在传承了其在可扩展性、TCP 友好性和 RTT 公平性等优点的同时,也能有所提升,这个改进算法就 叫做——SCUBIC。 主要工作有: 1、阅读参考文献,了解拥塞控制基本理论、发展现状,重点对最近提出的基于端算法的新协议进行理 论分析总结。 2、利用模拟工具 NS-2 重点对 STCP、CUBIC 协议TCP 协议进行模拟实验,并结合理论从其可扩展 性、稳定性、TCP 友好性、RTT 公平性方面进行比较分析。 3、针对 STCP 稳定性和可扩展性比 CUBIC 更加优越的特点,提出一种新的改进算法 SCUBIC。通过 实验验证 SCUBIC 增强了拥塞窗口的稳定和带宽使用的平稳度,较大程度地提高了协议的稳定性,同 时在可扩展性、TCP 友好性和 RTT 公平性方面也有所提升。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值