滑动窗口协议

上传人:小*** 文档编号:180508364 上传时间:2023-01-06 格式:DOC 页数:3 大小:17.50KB
收藏 版权申诉 举报 下载
滑动窗口协议_第1页
第1页 / 共3页
滑动窗口协议_第2页
第2页 / 共3页
滑动窗口协议_第3页
第3页 / 共3页
资源描述:

《滑动窗口协议》由会员分享,可在线阅读,更多相关《滑动窗口协议(3页珍藏版)》请在装配图网上搜索。

1、滑动窗口协议,是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输。只有在接收窗口向前滑动时(与此同时也发送了确认),发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动,因此这种协议又称为滑动窗口协议。当发送窗口和接收窗口的大小都等于1时,就是停止等待协议。当发送窗口大于1,接收窗口等于1时,就是回退N步协议。当发送窗口和接收窗口的大小均大于1时,就是选择重发协议。协议中规定,对于窗口内未经确认的分组需要重传。这种分组的数量最多可以等于发送窗口的大小,即滑动窗口的大小n减

2、去1(因为发送窗口不可能大于(n-1),起码接收窗口要大于等于1)。协议在工作时,如果发送端的协议软件每传输一个数据分组后,必须等待接收端的确认才能够发送下一个分组,由于网络传输的时延,将有大量时间被用于等待确认,导致传输效率低下。为此在进行数据传输时使用了滑动窗口机制。滑动窗口用来暂存两台计算机问要传送的数据分组。每台运行协议的计算机有两个滑动窗口:一个用于数据发送,另一个用于数据接收。发送端待发数据分组在缓冲区排队等待送出。被滑动窗口框入的分组,是可以在未收到接收确认的情况下最多送出的部分。滑动窗口左端标志的分组,是已经被接收端确认收到的分组。随着新的确认到来,窗口不断向右滑动。协议软件依

3、靠滑动窗口机制解决传输效率和流量控制问题。它可以在收到确认信息之前发送多个数据分组。这种机制使得网络通信处于忙碌状态,提高了整个网络的吞吐率,它还解决了端到端的通信流量控制问题,允许接收端在拥有容纳足够数据的缓冲之前对传输进行限制。在实际运行中,滑动窗口的大小是可以随时调整的。收发端协议软件在进行分组确认通信时,还交换滑动窗口控制信息,使得双方滑动窗口大小可以根据需要动态变化,达到在提高数据传输效率的同时,防止拥塞的发生。称窗口左边沿向右边沿靠近为窗口合拢,这种现象发生在数据被发送和确认时。当窗口右边沿向右移动时将允许发送更多的数据,称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的

4、数据并释放了的接收缓存时。当右边沿向左移动时,称为窗口收缩。强烈建议不要使用这种方式。但必须能够在某一端产生这种情况时进行处理。如果左边沿到达右边沿,则称其为一个零窗口。滑动窗口协议的基本原理就是在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧。下面举一个例子(假设发送窗口尺寸为2,接收窗口尺寸为1):分析:初始态,发送方

5、没有帧发出,发送窗口前后沿相重合。接收方号窗口打开,等待接收号帧;发送方打开号窗口,表示已发出帧但尚确认返回信息。此时接收窗口状态不变;发送方打开、号窗口,表示0、1号帧均在等待确认之列。至此,发送方打开的窗口数已达规定限度,在未收到新的确认返回帧之前,发送方将暂停发送新的数据帧。接收窗口此时状态仍未变;接收方已收到号帧,号窗口关闭,号窗口打开,表示准备接收1号帧。此时发送窗口状态不变;发送方收到接收方发来的0号帧确认返回信息,关闭0号窗口,表示从重发表中删除0号帧此时接收窗口状态仍不变;发送方继续发送号帧,号窗口打开,表示2号帧也纳入待确认之列。至此,发送方打开的窗口又已达规定限度,在未收到

6、新的确认返回帧之前,发送方将暂停发送新的数据帧,此时接收窗口状态仍不变;接收方已收到号帧,号窗口关闭,号窗口打开,表示准备接收2号帧。此时发送窗口状态不变;发送方收到接收方发来的1号帧收毕的确认信息,关闭1号窗口,表示从重发表中删除1号帧。此时接收窗口状态仍不变。若从滑动窗口的观点来统一看待比特滑动窗口、后退及选择重传三种协议,它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议:发送窗口,接收窗口1后退协议:发窗口,接收窗口1选择重传协议:发送窗口接收窗口。比特滑动窗口协议当发送窗口和接收窗口的大小固定为1时,滑动窗口协议退化为停等协议(一一)。该协议规定发送方每发送一帧后就要停下

7、来,等待接收方已正确接收的确认()返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧,因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧,因而只用一比特来编号就够了。后退协议由于停等协议要为每一个帧进行确认后才继续发送下一帧,大大降低了信道利用率,因此又提出了后退协议。后退协议中,发送方在发完一个数据帧后,不停下来等待应答帧,而是连续发送若干个数据帧,即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍没有收到确认帧,就要重发相应的数据帧。女如

8、当发送方发送了个帧后,若发现该帧的前一个帧在计时器超时后仍未返回其确认信息,则该帧被判为出错或丢失,此时发送方就不得不重新发送出错帧及其后的帧。从这里不难看出,后退协议一方面因连续发送数据帧而提高了效率,但另一方面,在重传时又必须把原来已正确传送过的数据帧进行重传(仅因这些数据帧之前有一个数据帧出了错),这种做法又使传送效率降低。由此可见,若传输信道的传输质量很差因而误码率较大时,连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为,接收窗口仍是1选择重传协议在后退n协议中,接收方若发现错误帧就不再接收后续的帧,即使是正确到达的帧,这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层但,接收方仍可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧一。旦收到重新传来的帧后,就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发SELECTICEREPEAT),显然,选择重发减少了浪费,但要求接收方有足够大的缓冲区空间。

展开阅读全文
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!