滑动窗口协议和
TCP协议中的滑动窗口与拥塞窗口：区别与联系(九)
TCP是传输层协议中最重要的协议之一，它通过连接、可靠、有序传输数据来保证网络通信的可靠性。
其中，滑动窗口和拥塞窗口是TCP协议中的两个重要概念。
本文将分别介绍滑动窗口和拥塞窗口在TCP协议中的作用、区别和联系。
一、滑动窗口滑动窗口是用来控制发送方和接收方之间的数据传输速率以及确认机制的一种技术。
在发送数据时，发送方将数据划分为一定大小的数据块，每个数据块称为一个段(segment)。
发送方通过发送窗口来控制连续发送的段的数量。
接收方使用接收窗口来控制接收的段的数量。
滑动窗口的原理是通过动态调整发送和接收窗口的大小，实现了发送和接收端之间的流量控制。
通过自适应调整窗口的大小，可以有效避免发送方发送速度过快或接收方处理速度过慢导致的丢包、拥塞等问题。
滑动窗口的大小取决于网络状况和接收端的处理能力，可以根据情况进行动态调整。
二、拥塞窗口拥塞窗口是用来控制发送方在网络中发送的数据量的一种机制。
当网络中的拥塞程度增加时，为了避免拥塞进一步加剧，TCP协议会动态调整发送数据的速率。
这个动态调整的过程就是通过拥塞窗口来实现的。
拥塞窗口的大小取决于网络中的拥塞情况。
当网络中出现拥塞时，拥塞窗口的大小会减小，从而降低发送数据的速率。
反之，当网络中的拥塞减少时，拥塞窗口的大小逐渐增大，发送数据的速率也逐渐增加。
三、滑动窗口与拥塞窗口的区别滑动窗口与拥塞窗口在TCP协议中的作用是不同的。
滑动窗口是通过控制发送方和接收方之间的数据传输速率来保证可靠性；而拥塞窗口是通过控制发送方发送数据的速率来避免网络拥塞问题。
其次，滑动窗口的大小是根据接收方的处理能力和网络状况进行动态调整的，用于实现流量控制；而拥塞窗口的大小是根据网络中的拥塞情况进行动态调整的，用于实现拥塞控制。
最后，滑动窗口和拥塞窗口的调整方式也不同。
滑动窗口是通过接收方发送的确认信息来动态调整窗口的大小；而拥塞窗口是通过网络中的拥塞程度来动态调整窗口的大小。
四、滑动窗口与拥塞窗口的联系虽然滑动窗口和拥塞窗口在TCP协议中的作用和调整方式不同，但它们之间也存在联系。
滑动窗口协议 (2)
滑动窗口协议协议名称：滑动窗口协议1. 引言滑动窗口协议是一种用于数据传输的协议，它通过将数据分割成多个小块，并按照顺序发送和接收，以提高传输效率和可靠性。
本协议旨在定义滑动窗口协议的标准格式和规范，以确保数据的可靠传输和顺序性。
2. 术语和定义2.1 发送方（Sender）：负责将数据分割成小块并发送的一方。
2.2 接收方（Receiver）：负责接收并组装数据块的一方。
2.3 窗口（Window）：发送方和接收方之间的数据缓冲区，用于控制数据的流动。
2.4 序列号（Sequence Number）：用于标识数据块的顺序，以便接收方正确组装数据。
3. 协议规范3.1 连接建立发送方和接收方在建立连接前，双方需要互相确认通信参数，包括最大窗口大小、超时时间等。
连接建立后，双方将进入数据传输阶段。
3.2 数据分割和发送3.2.1 发送方将待传输的数据分割成多个数据块，并为每一个数据块分配一个惟一的序列号。
3.2.2 发送方根据窗口大小，将数据块按序发送给接收方。
3.2.3 发送方维护一个发送窗口，窗口的大小不超过接收方指定的最大窗口大小。
发送方将已发送但未收到确认的数据块缓存在窗口中。
3.3 确认和接收3.3.1 接收方收到数据块后，将根据序列号进行排序和组装。
3.3.2 接收方向发送方发送确认消息，确认已成功接收到数据块。
3.3.3 接收方维护一个接收窗口，窗口的大小不超过发送方指定的最大窗口大小。
接收方将已正确接收到的数据块缓存在窗口中。
3.4 窗口滑动3.4.1 发送方收到接收方的确认消息后，将滑动发送窗口，将窗口内的数据块向前滑动。
3.4.2 接收方收到发送方的确认消息后，将滑动接收窗口，将窗口内的数据块向前滑动。
3.5 超时重传3.5.1 发送方在发送数据块后，等待接收方的确认消息。
如果超过预设的超时时间仍未收到确认消息，则发送方将重新发送该数据块。
3.5.2 接收方在接收到数据块后，如果发现数据块的序列号与预期不符，则发送一个重复确认消息，要求发送方重新发送该数据块。
滑动窗口协议书
滑动窗口协议书甲方（发送方）：_____________________乙方（接收方）：_____________________鉴于甲方与乙方就数据传输服务达成合作意向，为确保数据传输的准确性、完整性和稳定性，双方同意采用滑动窗口协议来管理数据传输过程。
现就滑动窗口协议的具体条款达成如下协议：第一条协议目的本协议旨在通过滑动窗口机制，确保双方在数据传输过程中能够有效地控制数据流量，避免数据丢失和重复发送，提高传输效率。
第二条协议定义2.1 滑动窗口协议：指在数据传输过程中，发送方在未收到接收方确认信息前，可以连续发送多个数据包，但发送的数据包数量受到窗口大小的限制。
2.2 窗口大小：指在任何时刻，发送方可以发送但尚未收到确认的数据包的最大数量。
第三条窗口大小3.1 双方同意，初始窗口大小设定为N个数据包。
3.2 根据网络状况和接收方的处理能力，乙方有权要求调整窗口大小，但需提前通知甲方，并得到甲方的同意。
第四条数据传输4.1 甲方在发送数据时，应按照滑动窗口协议的规定，控制发送的数据包数量。
4.2 乙方在接收数据后，应及时向甲方发送确认信息，以便甲方更新窗口状态并发送后续数据包。
第五条数据确认5.1 乙方在接收到数据包后，应检查数据的完整性和正确性。
5.2 若数据包无误，乙方应向甲方发送确认信息；若数据包有误，乙方应向甲方发送否定确认信息，并要求重新发送。
第六条超时重传6.1 若甲方在规定时间内未收到乙方的确认信息，应视为数据传输失败，甲方应重新发送该数据包。
6.2 双方应协商确定超时时间，并在协议中明确。
第七条协议变更7.1 任何一方希望变更本协议内容，应提前通知对方，并得到对方的书面同意。
7.2 变更后的协议内容，自双方签字盖章之日起生效。
第八条争议解决8.1 本协议在履行过程中发生的任何争议，双方应通过友好协商解决。
8.2 如协商不成，任何一方均可向甲方所在地人民法院提起诉讼。
第九条其他9.1 本协议自双方签字盖章之日起生效，有效期为一年，除非双方另有书面约定。
滑动窗口协议
滑动窗口协议协议名称：滑动窗口协议一、协议介绍滑动窗口协议是一种用于数据传输的协议，通过设置发送方和接收方的窗口大小，实现可靠的数据传输和流量控制。
本协议旨在确保数据的完整性和可靠性，提高数据传输的效率和可控性。
二、协议要求1. 数据传输的可靠性：确保数据在传输过程中不丢失、不损坏、不重复。
2. 流量控制：根据接收方的处理能力和网络状况，控制发送方的数据发送速率，避免数据拥塞。
3. 窗口管理：通过滑动窗口的机制，实现数据的分段发送和接收，提高数据传输的效率。
4. 错误检测和纠正：采用适当的错误检测和纠正机制，保证数据传输的准确性。
三、协议流程1. 发送方将待发送的数据分割为固定大小的数据段，并设置发送窗口的大小。
2. 发送方将数据段按照顺序发送给接收方，并启动定时器等待接收方的确认信息。
3. 接收方接收到数据段后，检查数据的完整性。
如果数据正确无误，则发送确认信息给发送方。
4. 发送方收到确认信息后，将发送窗口向前滑动一个位置，并继续发送下一个数据段。
5. 如果发送方在定时器超时前没有收到确认信息，则认为数据丢失，重新发送该数据段。
6. 接收方在收到重复的数据段时，丢弃重复数据并发送确认信息。
四、协议实现1. 窗口大小的选择：根据网络状况和接收方的处理能力，合理选择发送窗口和接收窗口的大小。
2. 序列号的分配：发送方为每个数据段分配一个唯一的序列号，接收方通过序列号确认接收到的数据段。
3. 确认机制：接收方在接收到数据段后，发送确认信息给发送方，确认已收到数据段。
4. 定时器机制：发送方设置定时器，超时后重新发送未收到确认的数据段。
5. 错误检测和纠正：采用适当的错误检测和纠正机制，如循环冗余校验（CRC）等。
五、协议优化1. 快速重传：接收方在收到连续的重复数据段时，立即发送确认信息，以提高数据传输效率。
2. 拥塞控制：根据网络拥塞的程度，动态调整发送窗口的大小，避免数据拥塞和丢失。
3. 流量控制：接收方通过发送窗口的大小，控制发送方的数据发送速率，防止数据过载。
滑动窗口协议
滑动窗口协议一、背景与目的滑动窗口协议是一种通信协议，用于在不可靠的通信信道上实现可靠的数据传输。
它通过使用滑动窗口机制，确保数据的有序传输和可靠接收。
本协议的目的是规定滑动窗口协议的标准格式，以便确保各方在通信过程中能够正确理解和实施该协议。
二、术语定义1. 发送方（Sender）：负责将数据发送给接收方的实体。
2. 接收方（Receiver）：负责接收发送方传输的数据的实体。
3. 帧（Frame）：数据传输中的基本单位，包含数据和控制信息。
4. 序列号（Sequence Number）：用于标识每个帧的唯一编号。
5. 窗口（Window）：发送方和接收方之间的缓冲区，用于存储待发送或待接收的帧。
6. 确认帧（Acknowledgement Frame）：接收方向发送方发送的帧，用于确认已成功接收的帧。
7. 超时（Timeout）：发送方等待接收方确认帧的时间长度。
8. 重传（Retransmission）：发送方在超时后，重新发送未收到确认的帧。
三、协议规定1. 帧格式滑动窗口协议的帧格式如下：[序列号][数据][校验和]- 序列号：占用固定长度的位数，用于标识帧的序列号。
- 数据：占用固定长度的位数，用于存储待传输的数据。
- 校验和：占用固定长度的位数，用于校验数据的完整性。
2. 窗口大小- 发送方窗口（Sender Window）：发送方允许发送的帧的最大数量。
- 接收方窗口（Receiver Window）：接收方允许接收的帧的最大数量。
3. 发送方操作1) 初始化- 发送方窗口起始位置为0。
- 发送方等待接收方确认帧的超时时间为T。
2) 发送数据- 发送方将待传输的数据划分为多个帧，并依次发送。
- 发送方将每个帧的序列号填入帧的序列号字段。
- 发送方等待接收方确认帧，如果超过超时时间仍未收到确认帧，则重传该帧。
3) 接收确认- 发送方接收到接收方的确认帧后，将发送方窗口向前滑动一个位置。
滑动窗口协议
滑动窗口协议引言在计算机网络中，滑动窗口协议是一种常用的数据传输协议，用于确保可靠的数据传输。
本文将介绍滑动窗口协议的基本概念、工作原理以及应用场景等内容。
滑动窗口协议的基本概念滑动窗口协议是一种基于窗口的流量控制协议。
在数据传输过程中，发送方和接收方都维护着一个固定大小的窗口，用于管理待发送的数据和已接收的数据。
滑动窗口协议的工作原理滑动窗口协议的工作原理可以简单地描述为以下几个步骤： 1. 发送方将待发送的数据分割成若干个数据包，并按顺序发送。
2. 接收方接收数据包，并发送确认信息给发送方。
3. 发送方收到确认信息后，将窗口向前滑动一个单位，继续发送下一个数据包。
4. 如果接收方未收到某个数据包，或者数据包有错误，将请求发送方重新发送该数据包。
滑动窗口协议的优势相比于其他传输协议，滑动窗口协议具有以下优势： 1. 可靠性：滑动窗口协议通过确认机制和重传机制，能够确保数据的可靠传输。
2. 流量控制：通过窗口大小的控制，滑动窗口协议可以有效控制数据传输的速率，避免数据的丢失和网络拥塞。
3. 高效性：滑动窗口协议支持并行发送多个数据包，提高了数据传输的效率。
滑动窗口协议的应用场景滑动窗口协议广泛应用于各种数据传输场景，包括但不限于： 1. 文件传输：在文件传输过程中，滑动窗口协议可以确保文件的完整性和正确性。
2. 视频流传输：通过滑动窗口协议，可以实现对视频流的实时传输和播放。
3. 数据库同步：在数据库同步过程中，滑动窗口协议可以确保数据的一致性和可靠性。
总结滑动窗口协议是一种常用的数据传输协议，通过窗口管理机制，实现了数据的可靠传输和流量控制。
它具有可靠性、高效性和流量控制等优势，并在文件传输、视频流传输和数据库同步等场景中得到广泛应用。
熟悉滑动窗口协议的工作原理和应用场景，对于网络通信的设计和优化具有重要意义。
流水线机制、滑动窗口协议、GBN、SR
流⽔线机制、滑动窗⼝协议、GBN、SR
⼀、滑动窗⼝协议
为了解决停等操作的性能问题（发了⼀个分组之后⼀直等到确认了这个分组才发下⼀个），推出了流⽔线机制，提供资源利⽤率。
就是允许发送⽅在收到对⽅的ACK前，发送多个分组
其中窗⼝是⼀个范围管理发出去还没确认的分组，随着不断传输，这个窗⼝不断滑动，名称的由来。
窗⼝左端的序号收到了ACK，就可以往右滑动了。
滑动窗⼝协议有GBN、SR
⼆、滑动窗⼝协议的实现：GBN
1.分组头部包含序列号
2.窗⼝如下，⼤⼩为N，最多允许N个分组未确认
3.ACK(n),则表⽰确认从开始到n（包含n）的序列号全部正确接收
4.会空中在传的分组设置⼀个Timer计时器，处理超时，如果收到了timeout(n)事件，那么会重传的是n以及n以后的所有分组（尽管后⾯的可能已经收到了，这就是回退，回退到n开始传，GBN）
5.接收⽅会有⼀个期望序列号，如果收到的不是期望的分组，直接丢弃
三、滑动窗⼝协议的实现：SR（选择重传）
GBN缺陷，累积确认机制导致回退到N，重复传了很多。
解决这个。
1.对每个分组分别确认，不再只接收期望的，接到不期望的，就先缓存（设置缓存机制），接到期望的才交付上层
2.发送⽅只需要重传那些没收到ACK的分组了
3.产⽣了接收⽅窗⼝（GBN只有发送⽅窗⼝），⽤来缓存，现在有两窗⼝了
4.序列号的位数是K的话，那么得满⾜ 接收⽅窗⼝⼤⼩N+发送⽅N<= 2的k次⽅，防⽌因为接收⽅ACK丢失导致发送重发k号分组，⽽此时接收⽅滑到了新窗⼝，新窗⼝有新的k号分组（不是原来的，共⽤序号产⽣的），导致出错。
滑动窗口协议
滑动窗口协议协议名称：滑动窗口协议一、引言滑动窗口协议是一种用于数据传输的协议，其主要目的是在发送方和接收方之间建立可靠的数据传输通道。
该协议通过使用滑动窗口的概念来实现数据的流控制和错误恢复。
二、协议背景随着网络通信的发展，数据传输的可靠性和效率成为了重要的问题。
传统的数据传输方式存在着丢包、重传等问题，因此需要一种更可靠、高效的协议来解决这些问题。
滑动窗口协议应运而生。
三、协议原理1. 数据分段：发送方将要传输的数据按照一定的大小进行分段，并为每个数据段分配一个序号。
2. 窗口大小：发送方和接收方都维护一个滑动窗口，窗口大小表示当前可以发送或接收的数据段的数量。
3. 发送方操作：a. 发送窗口：发送方将窗口内的数据段发送给接收方，并等待接收方的确认。
b. 接收确认：接收到接收方的确认后，发送方将窗口滑动，并发送下一个窗口内的数据段。
c. 超时重传：如果发送方在一定时间内未收到接收方的确认，将会重传窗口内的数据段。
4. 接收方操作：a. 接收窗口：接收方接收到发送方发送的数据段后，将其存储在接收窗口中，并发送确认给发送方。
b. 确认重复：如果接收方收到重复的数据段，将会发送上一次确认的序号给发送方。
c. 有序交付：接收方将有序交付给上层应用的数据段，即按照序号顺序将数据段交付给应用层。
四、协议流程1. 发送方将要传输的数据按照一定的大小进行分段，并为每个数据段分配一个序号。
2. 发送方维护一个发送窗口，将窗口内的数据段发送给接收方，并等待接收方的确认。
3. 接收方接收到发送方发送的数据段后，将其存储在接收窗口中，并发送确认给发送方。
4. 发送方收到接收方的确认后，将窗口滑动，并发送下一个窗口内的数据段。
5. 如果发送方在一定时间内未收到接收方的确认，将会重传窗口内的数据段。
6. 接收方如果收到重复的数据段，将会发送上一次确认的序号给发送方。
7. 接收方将有序交付给上层应用的数据段，即按照序号顺序将数据段交付给应用层。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第7页/共42页
(a) 正常情况
(b) 不正常情况
一位滑动窗口协议的两种情形(双方同时发送分组)
第8页/共42页
接收窗口>1滑动窗口示意图
发送方
70 61 52
43
7 61 52
43
7 6 52
43
7 6 52
43
接收方
7 61 52
43
(a)初态
7 61 52
43
(b)发送帧0
7 61 52
43
收到0号帧,期待1号帧 收到1号帧,期待2号帧 收到2号帧,期待3号帧 收到3号帧,期待4号帧 收到4号帧,期待5号帧 收到5号帧,期待6号帧 收到6号帧,期待7号帧 收到7号帧,期待0号帧
……
0 1 2 3 4 5 6 7 准备接收新的0号帧 0 1 2 3 4 5 6 7 错将重发帧当作新帧接收
第9讲 窗口滑动机制和 HDLC
窗口滑动机制 高级数据链路控制协议HDLC PPP协议
第1页/共42页
1 滑动窗口机制
发送端和接收端分别设定发送窗口和接收窗口 。 发送窗口用来对发送端进行流量控制。 发送窗口的大小 WT 代表在还没有收到对方确认信
息的情况下发送端最多可以发送多少个数据帧。
每收到一个序号正确的帧，接收窗口就向前（即向右方） 滑动一个帧的位置。同时发送对该帧的确认。
第4页/共42页
WR
(a)
01 2
准备接收 0 号帧
WR
(b)
01 2
已收到 准备接收 1 号帧
(c)
01 2
已收到
34 56 7 0 1 2 不允许接收这些帧
34 56 7 0 1 2 不允许接收这些帧
此帧才提交给网络层。
第15页/共42页
选择重传协议的思路
发送方
超时间隔
0 12 34 5 26 7
8 9 10 11
01
34 5
接收方
出错 缓存的帧
26
7 8 9 10 11 时间
第16页/共42页
选择重传协议窗口大小的约束条件
发送窗口和接收窗口尺寸大小相同—两个窗口的尺寸≤2k的一半， 即2k-1
第2页/共42页
发送窗口 WT
(a) 0 1
2
34
567
0
12
允许发送 5 个帧 WT
不允许发送这些帧
(b) 0 1 2 3 4 5 6 7 0 1 2
已发送 还允许发送 4 个帧
不允许发送这些帧
WT
(c) 0 1
2
34
567
0
12
已发送
不允许发送这些帧
WT
(d) 0 1 2
已发送 并已收到确认
34 56 7
如果这时收到了接收端发来的确认帧，那么还可以接 着发送数据帧。
由于减少了等待时间，整个通信的吞吐量就提高了。 要求接收方的数据链路层必须按次序把分组交给网络
层。 当帧n的确认到达时，帧n-1,n-2等也都被自动确认。
第11页/共42页
退后N帧协议的思路
接收方将出错的帧及其后续帧一起丢弃，对出错的 帧不发送确认帧；发送方在出错帧的确认帧超时后， 从出错的帧开始重传所有已发送但未被确认的帧。
(c)发送帧1
70 6 52
43
(d)接收帧0
发送方
70 6 52
43
70 6 5
43
70 6 5
43
70 61 5
43
接收方
70 6 52
43
70 6 52
43
70 61 5
43
70 61 5
43
(e)接收确认帧0
(f)发送帧2 (g)接收帧1 (h)接收确认帧1
第9页/共42页
1.2 退பைடு நூலகம்N帧协议
第6页/共42页
1.1 一位滑动窗口协议
70
70
70
70
6 发送方
16
16
16
1
5
25
25
25
2
43
43
43
43
70
70
70
70
接收方 6 5
16 25
16 25
16 25
1 2
43
43
43
43
（a）
（b）
（c）
（d）
(a) 初始时 (c) 第一个帧接收之后
(b) 第一个帧发出之后 (d) 第一个确认收到之后
发送方
超时间隔
0 12 34 5 2 34 5 6 7 8
0 接收方
1 出错
丢弃的帧
2 34 5 6 7 8 时间
第12页/共42页
退后N帧协议窗口大小的约束条件
发送方
WT=8 01234567
连续发送 8个帧
Tout
01234567
接收方
WR=1 01234567
准备接收0号帧
01234567 01234567 01234567 01234567 01234567 01234567 01234567 01234567
WR 34 56 7 0 1 2
不允许接收这些帧 准备接收 4 号帧
第5页/共42页
滑动窗口的重要特性
只有在接收窗口向前滑动时（与此同时也发送 了确认），发送窗口才有可能向前滑动。
收发两端的窗口按照以上规律不断地向前滑动， 因此这种协议又称为滑动窗口协议。
当发送窗口和接收窗口的大小都等于 1时，就 是停止等待协议。
抛弃一种技巧性的假设
一个帧到达接收方的传输时间，加上确认帧来回的 传输时间是可以忽略不计。
解决策略
允许发送过程在阻塞之前发送多达w个帧，而不是
1帧。由于可以适当的选择w，发送过程就可以在等
待往返传输的时间内连续传输帧，而不至于填满窗
口。
第10页/共42页
退后N帧的工作原理
在发送完一个数据帧后，不是停下来等待确认帧，而 是可以连续再发送若干个数据帧。
已发送
还允许发送 3 个帧
第3页/共42页
0 12 不允许发送这些帧
接收端设置接收窗口
在接收端只有当收到的数据帧的发送序号落入接收窗口内 才允许将该数据帧收下。
若接收到的数据帧落在接收窗口之外，则一律将其丢弃。 在连续 ARQ 协议中，接收窗口的大小 WR = 1。
只有当收到的帧的序号与接收窗口一致时才能接收该帧。 否则，就丢弃它。
第14页/共42页
1.3 选择重传协议
如果线路很糟糕，使用退后n帧的协议会浪费大量的带 宽重传帧。
解决的策略：
允许接收过程接收并缓存坏帧或丢失帧后面的帧。 接收方只把出错的帧丢弃，其后续帧保存在缓存中，向发送
方发送对出错帧的非确认帧（NAK）。 如果落在窗口内并从未接收过，就接受此帧，并存储起来。 直到比它序列号小的所有帧都按次序已经交给了网络层后，
第13页/共42页
退后N帧协议窗口大小的约束条件
考虑最大发送窗口大小为8的情况： 发送过程发送帧0~7帧； 帧7的捎带确认最终返回到发送过程； 发送过程发送另外8帧0~7，序号再次为0~7； 现在帧7的另一个捎带确认到达。
问题：第二次发送的8帧是成功了还是全部丢失了？
发送和接收窗口尺寸小于2k，K（序列号的位数）