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

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

利用窗口控制提高速度

TCP以1个段为单位,每发一个段进行一次确认应答的处理,如图。这样的传输方式有一个缺点。那就是,包的往返时间越长通信性能就越低。

为解决这个问题,TCP引入了窗口这个概念。即使在往返时间较长的情况下,它也能控制网络性能的下降。如图所示,确认应答不再是以每个分段,而是以更大的单位进行确认时,转发时间将会被大幅度的缩短。也就是说,发送端主机,在发送了一个段以后不必要一直等待确认应答,而是继续发送。

窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。在上图中,窗口大小为4个段。


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


如下图所示,发送数据中高亮圈起的部分正是前面所提到的窗口。在这个窗口内的数据即便没有收到确认应答也可以发送出去。此外,从该窗口中能看到的数据因其某种数据已在传输中丢失,所以发送端才能收到确认应答,这种情况也需进行重发。为此,发送端主机在等到确认应答返回之前,必须在缓冲区中保留这部分数据。

3b6a5edc2d3441f4a4d4a6403bce95ba.png

在滑动窗口以外的部分包括尚未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发,此时数据就可以从缓存区清除。


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

窗口控制与重发控制

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

确认应答未能返回的情况

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

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


在传统的TCP中,如果接收方收到乱序的数据段,它只会发送一个累积确认(Acknowledgment,ACK)来指示已经成功接收到哪些数据段,而没有指明丢失了哪些数据段。这样,发送方只能根据连续的确认来确定丢失的数据,并进行重传。

然而,使用了SACK选项后,接收方可以在ACK中指明哪些数据段已经成功接收,同时也指明哪些数据段还未接收到。这样,发送方就知道了具体哪些数据段需要进行重传,而不必等待超时,提高了传输效率。

SACK选项提供了更精确的信息,使得发送方能够快速重传仅丢失的数据段,而不必重传已经成功接收的数据段。这样可以避免不必要的重传,减少网络拥塞和传输延迟,提高整体速度。

需要注意的是,SACK选项并不是TCP的必需功能,它是一种可选的扩展。因此,对于不支持SACK的TCP实现或网络环境,仍然会使用传统的累积确认和超时重传机制。

某个报文段丢失的情况

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


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

image.png

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


TCP使用序号(Sequence Number)来标识每个传输的数据段,并使用确认序号(Acknowledgment Number)来确认已成功接收到的数据。当接收主机收到一个序号不匹配的数据段时,它会忽略该数据段,并发送一个确认应答,确认已经成功接收到的数据,即上一个正确的序号对应的数据。

这种行为是为了通信的可靠性和协议的健壮性。通过确认已成功接收的数据,发送主机可以得知哪些数据已经被接收到,从而避免重复发送相同的数据。接收主机可以通过丢弃不匹配的数据段并返回确认应答来通知发送主机数据接收的状态。

如果发送主机在一定时间内没有收到确认应答,它会认为发送的数据丢失,并重新发送相应的数据段,以确保数据的可靠传输。

总结来说,当接收主机收到一个不匹配序号的数据时,它会针对当前为止已经成功接收到的数据返回确认应答,而不会针对异常数据。这种机制有助于确保TCP的可靠性和传输的正确性。

控制流

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


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


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


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


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

c557997de6ea466cb3c3ba932790c420.png

相关文章
|
26天前
|
网络协议 Linux
TCP中两种保活方式
【4月更文挑战第7天】两种保活方式:Keep Alive和心跳包
|
28天前
|
网络协议
TCP关闭连接的两种方式
【4月更文挑战第5天】close 和 shutdown 的函数
|
9月前
|
缓存 网络协议 算法
窗口到底有多滑动?揭秘TCP/IP滑动窗口的工作原理
当涉及网络性能优化和数据传输可靠性时,TCP/IP滑动窗口是一个关键的技术。本文的摘要将深入揭示TCP/IP滑动窗口的工作原理,探讨其在确保数据准确性和实现高效通信方面的重要性。通过对滑动窗口大小、流控制和数据包确认机制的解析,我们将揭示如何通过优化窗口大小和流控制参数来提升网络性能。此外,我们还将介绍滑动窗口在解决网络拥塞和丢包问题方面的作用,以及如何通过精准的窗口调整实现零丢失、百分之百到达的数据传输。通过理解滑动窗口的工作原理,读者将能够更好地理解网络通信的内部机制,并为优化其应用程序的性能提供有价值的见解。
144 0
窗口到底有多滑动?揭秘TCP/IP滑动窗口的工作原理
|
9月前
|
网络协议
TCP的三次握手以及以段为单位发送数据【TCP原理(笔记二)】
TCP的三次握手以及以段为单位发送数据【TCP原理(笔记二)】
TCP的三次握手以及以段为单位发送数据【TCP原理(笔记二)】
|
9月前
|
存储 缓存 网络协议
深入理解Linux网络——TCP连接建立过程(三次握手源码详解)-2
三、深入理解connect 客户端再发起连接的时候,创建一个socket,如何瞄准服务端调用connect就可以了,代码可以简单到只有两句。
深入理解Linux网络——TCP连接建立过程(三次握手源码详解)-2
|
9月前
|
缓存 网络协议 NoSQL
深入理解Linux网络——TCP连接建立过程(三次握手源码详解)-3
五、异常TCP建立情况 1)connect系统调用耗时失控 客户端在发起connect系统调用的的时候,主要工作就是端口选择。在选择的过程中有一个大循环
|
9月前
|
存储 网络协议 Linux
深入理解Linux网络——TCP连接建立过程(三次握手源码详解)-1
一、相关实际问题 为什么服务端程序都需要先listen一下 半连接队列和全连接队列长度如何确定 “Cannot assign requested address”这个报错是怎么回事
|
12月前
|
网络协议 Java
TCP发送数据、接受数据及TCP通信程序练习
TCP发送数据、接受数据及TCP通信程序练习
111 0
|
网络协议
TCP协议三次握手的执行流程,tcp的交互模式
TCP协议三次握手的执行流程,tcp的交互模式
129 0
|
编解码 网络协议 网络架构
计算机网络基础 和 tcp 三次握手四次挥手,tcpdump抓包分析 协议过滤 分析,连接状态,标志位详解
wireshark 软件过滤及转码使用 ,TCP tcpdump 连接状态,标志位详解
239 1