TCP协议滑动窗口机制

概述

从网络传输数据来讲,TCP、UDP以及其他协议都可以完成数据的传输,而TCP协议与其他协议不同的一点就是提供了一个可靠的,流量控制的数据传输方案。

  • 可靠性 : TCP协议的保证数据能够准确到达目的地,通过确认机制来实现。若未收到确认码,超过超时时间之后则重新发送数据。
  • 流量控制 : 数据发送过程中,通过滑动窗口机制,保证流量传输不超过设备的负载能力。

滑动窗口引入

TCP协议包括两种窗口机制,分别为固定窗口和滑动窗口。

固定窗口

TCP协议是可靠协议,通过确认机制实现数据的可靠传输。即发送方在发送完数据之后启动定时器,然后等待确认包的到来,若超过一定时间未收到确认包,则重新发送该数据。这种情况下,如果某个数据包多次传输失败,则会直接影响后续数据包的发送,非常影响传输效率。固定窗口发送示意图如下:
在这里插入图片描述

滑动窗口

滑动窗口的最大优势为不需要对每个数据包进行确认,而是可以进行累积确认。
滑动窗口的几个原则如下:

  1. 对发送数据做分段处理,并对每个段编号。
  2. 滑动窗口的大小是动态变化的,每次由接收端连同确认码一并返回。
  3. 接收端对接收到的连续数据进行确认,若出现乱序传输,则将先到达的编号较大的数据缓存,并等待数据到达。

由于TCP协议属于全双工协议,所以两个端都包含发送窗口和接收窗口。

滑动窗口的发送方结构如下:

  1. 发送且已确认窗口 : 这个窗口内的数据表示已经发送成功并已经被确认的数据。
  2. 发送但未确认窗口 : 这个窗口内的数据表示已经发送成功但并没有被确认的数据。
  3. 未发送但允许发送的窗口 : 这个窗口内的数据表示尚未发送但是允许被发送的数据。
  4. 不允许发送窗口 : 这个窗口内的数据属于接收端不允许发送的数据,因为这些数据已经超出了发送端所接收的范围。
    发送窗口简易结构如下图:
    在这里插入图片描述

滑动窗口的接收方结构如下:

  1. 接收但未处理窗口 : 这个窗口内数据属于接收了但是还没有被上层的应用程序处理,被缓存在窗口内。
  2. 接收但未确认窗口 : 这个窗口内数据属于接收了但是还没有来得及确认的数据。
  3. 有空位但还未接收数据窗口 : 表示可以接收数据,但是数据尚未发送过来的窗口。

滑动窗口原理

滑动窗口并不会对每一个报文段都回复确认码ACK,而是对一个或多个报文段发送一个确认码。例如发送方有1,2,3这3个报文段,首先一次发送了1,2,3三个报文段,但是接收方提前接收到了2,3报文段,而1报文段还没有到达,这时2,3报文段只能缓存起来并等待1报文段的到来。如果1报文段一直不来,则2,3报文段将被丢弃;如果1报文段及时赶来,则发送一个确认码对1,2,3这3个报文段进行一次确认。
例子如下:

  1. 假设有33-39这些数据待发送,TCP协议将它们分成四个报文段分别为seg1 33-34,seg2 35-36,seg3 37,seg4 38-39这四个段,并依次发给接收端。
  2. 假设接收端之接收到了seg1,seg2,seg4。则此时接收端回复一个ACK表示33-36已经成功接收,由于seg3尚未到达,所以将seg4缓存起来。
  3. 发送端接收到ACK后将33-36这部分数据从“发送但未确认窗口”移到“发送且已确认窗口”,即将“发送但未确认窗口”的左边界右移4个单位。
  4. 假设接收端发送给窗口大小不变,则“发送但未确认窗口”的右边界继续向右移动4个单位,只要不越进“不允许发送窗口”即可。
  5. 对于seg3,若一段时间后,接收端接收到了seg3,则发送确认码表示seg3和seg4接收成功。若没有收到seg3,则丢弃seg4。对应的,如果发送端一段时间没有接收到seg3的确认码,则重传seg3。
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 游动-白 设计师:白松林 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值