TCP的窗口控制和重发控制【TCP原理(笔记三)】

利用窗口控制提高速度

TCP以1个段为单位,每发一个段进行一次确认应答的处理,如图。这样的传输方式有一个缺点。那就是,包的往返时间越长通信性能就越低。
按数据包进行确认应答
为解决这个问题,TCP引入了窗口这个概念。即使在往返时间较长的情况下,它也能控制网络性能的下降。如图所示,确认应答不再是以每个分段,而是以更大的单位进行确认时,转发时间将会被大幅度的缩短。也就是说,发送端主机,在发送了一个段以后不必要一直等待确认应答,而是继续发送。
用滑动窗口方式并行处理
窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。在上图中,窗口大小为4个段。

这个机制实现了使用大量的缓冲区(缓冲区(Buffer)在此处表示临时保存收发数据的场所。通常是在计算机内存中开辟的一部分空间。) ,通过对多个段同时进行确认应答的功能。

如下图所示,发送数据中高亮圈起的部分正是前面所提到的窗口。在这个窗口内的数据即便没有收到确认应答也可以发送出去。此外,从该窗口中能看到的数据因其某种数据已在传输中丢失,所以发送端才能收到确认应答,这种情况也需进行重发。为此,发送端主机在等到确认应答返回之前,必须在缓冲区中保留这部分数据。
滑动窗口方式
在滑动窗口以外的部分包括尚未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发,此时数据就可以从缓存区清除。

收到确认应答的情况下,将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也被称为滑动窗口控制。

窗口控制与重发控制

在使用窗口控制中,如果出现段丢失该怎么办?

确认应答未能返回的情况

首先,我们先考虑确认应答未能返回的情况。在这种情况下,数据已经到达对端,是不需要再进行重发的。然而,在没有使用窗口控制的时候,没有收到确认应答的数据都会被重发。而使用了窗口控制,就如下图所示,某些确认应答即便丢失也无需重发。
没有确认应答也不受影响

TCP中的窗口控制机制可以使得即便某些确认应答丢失,发送方无需重发对应的数据。这是通过TCP的选择确认机制(Selective Acknowledgment,SACK)来实现的。

  • 在传统的TCP中,如果接收方收到乱序的数据段,它只会发送一个累积确认(Acknowledgment,ACK)来指示已经成功接收到哪些数据段,而没有指明丢失了哪些数据段。这样,发送方只能根据连续的确认来确定丢失的数据,并进行重传。
  • 然而,使用了SACK选项后,接收方可以在ACK中指明哪些数据段已经成功接收,同时也指明哪些数据段还未接收到。这样,发送方就知道了具体哪些数据段需要进行重传,而不必等待超时,提高了传输效率。
  • SACK选项提供了更精确的信息,使得发送方能够快速重传仅丢失的数据段,而不必重传已经成功接收的数据段。这样可以避免不必要的重传,减少网络拥塞和传输延迟,提高整体速度。
  • 需要注意的是,SACK选项并不是TCP的必需功能,它是一种可选的扩展。因此,对于不支持SACK的TCP实现或网络环境,仍然会使用传统的累积确认和超时重传机制。

某个报文段丢失的情况

其次,我们来考虑一下某个报文段丢失的情况。如图所示,接收主机如果收到一个自己应该接收的序号以外的数据时,会针对当前为止收到数据返回确认应答(不过即使接收端主机收到的包序号并不连续,也不会将数据丢弃而是暂时保存至缓冲区中。) 。

如图所示。当某一报文段丢失后,发送端会一直收到序号为1001的确认应答,这个确认应答好像在提醒发送端“我想接收的是从1001开始的数据”。因此,在窗口比较大,又出现报文段丢失的情况下,同一个序号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答(之所以连续收到3次而不是两次的理由是因为,即使数据段的序号被替换两次也不会触发重发机制。) ,就会将其所对应的数据进行重发。这种机制比之前提到的超时管理更加高效,因此也被称作高速重发控制。
高速重发控制

如果接收主机收到一个自己应该接收的序号以外的数据时,它会针对当前为止已经成功接收到的数据返回确认应答,而不是针对异常数据。

  • TCP使用序号(Sequence Number)来标识每个传输的数据段,并使用确认序号(Acknowledgment Number)来确认已成功接收到的数据。当接收主机收到一个序号不匹配的数据段时,它会忽略该数据段,并发送一个确认应答,确认已经成功接收到的数据,即上一个正确的序号对应的数据。
  • 这种行为是为了通信的可靠性和协议的健壮性。通过确认已成功接收的数据,发送主机可以得知哪些数据已经被接收到,从而避免重复发送相同的数据。接收主机可以通过丢弃不匹配的数据段并返回确认应答来通知发送主机数据接收的状态。
  • 如果发送主机在一定时间内没有收到确认应答,它会认为发送的数据丢失,并重新发送相应的数据段,以确保数据的可靠传输。
  • 总结来说,当接收主机收到一个不匹配序号的数据时,它会针对当前为止已经成功接收到的数据返回确认应答,而不会针对异常数据。这种机制有助于确保TCP的可靠性和传输的正确性。

控制流

发送端根据自己的实际情况发送数据。但是,接收端可能收到的是一个毫无关系的数据包又可能会在处理其他问题上花费一些时间。因此在为这个数据包做其他处理时会耗费一些时间,甚至在高负荷的情况下无法接收任何数据。如此一来,如果接收端将本应该接收的数据丢弃的话,就又会触发重发机制,从而导致网络流量的无端浪费。

为了防止这种现象的发生,TCP提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量。这就是所谓的流控制。它的具体操作是,接收端主机向发送端主机通知自己可以接收数据的大小,于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口大小。在前面6.4.6节中所介绍的窗口大小的值就是由接收端主机决定的。

TCP首部中,专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端。这个字段的值越大,说明网络的吞吐量越高。

不过,接收端的这个缓冲区一旦面临数据溢出时,窗口大小的值也会随之被设置为一个更小的值通知给发送端,从而控制数据发送量。也就是说,发送端主机会根据接收端主机的指示,对发送数据的量进行控制。这也就形成了一个完整的TCP流控制(流量控制)。

下图为根据窗口大小控制流量过程的示例。
控制流

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

全栈ing小甘

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值