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

相关文章
|
JavaScript
JS自动生成速记符、拼音简写/拼音的声母(例如:“你挚爱的强哥”转换为“NZADQG”)。提取首字母,返回大写形式;提取拼音, 返回首字母大写形式(全拼)。
JS自动生成速记符、拼音简写/拼音的声母(例如:“你挚爱的强哥”转换为“NZADQG”)。提取首字母,返回大写形式;提取拼音, 返回首字母大写形式(全拼)。
28595 0
|
存储 前端开发 Java
Python 教程之控制流(9)Python 中的 Switch Case(替换)
Python 教程之控制流(9)Python 中的 Switch Case(替换)
725 0
|
运维 Prometheus 监控
Grafana 系列 - 统一展示 -11-Logs Traces 无缝跳转
Grafana 系列 - 统一展示 -11-Logs Traces 无缝跳转
QGS
Debian11,Ubuntu20.04部署zabbix6.0解决中文乱码问题
记Debian11,Ubuntu20.04部署zabbix6.0解决中文乱码问题
QGS
1502 0
Debian11,Ubuntu20.04部署zabbix6.0解决中文乱码问题
|
6月前
|
弹性计算 编解码 安全
阿里云服务器2核4G最低价格:通用算力型、经济型、计算型等不同实例活动价格参考
阿里云服务器2核4G配置因均衡性能与内存成热门选择,但实例类型多样、价格差异大。通用算力型u1实例2核4G配置,企业用户特惠价199元/年,性价比极高;u2a与u2i实例性能更佳,适合个人或对算力要求高的用户,价格406.20元/年起;经济型e实例适合中小型网站等,价格599.93元/年起;计算型c9i实例性能强劲,适用于高性能需求场景,价格1742.08元/年起。建议根据需求、预算选合适实例,利用优惠券购买。
|
8月前
|
存储 Linux 文件存储
深入理解Linux文件系统(从零开始掌握文件存储与管理)
本教程深入浅出地讲解Linux文件系统核心机制,涵盖ext4文件系统、inode结构、磁盘管理及常用命令(如df、ls -i、lsof等),揭示文件存储原理与常见问题(如删除文件后空间未释放)的根源,助你掌握Linux底层知识,提升系统管理能力。
|
10月前
|
消息中间件 运维 数据可视化
别再“人肉运维”了——聊聊自动化运维平台怎么从0到1搭起来
别再“人肉运维”了——聊聊自动化运维平台怎么从0到1搭起来
607 1
|
缓存 监控 测试技术
获取API接口数据的最佳实践详解
在开发过程中,与API进行交互是获取数据和服务的关键步骤。本文详细介绍了10个最佳实践,包括明确需求和文档、错误处理、数据验证、性能优化、安全性、日志和监控、版本控制、代码复用和维护、测试以及遵守法律和道德规范,帮助开发者更高效地从API获取数据,确保数据的准确性、安全性和性能。
|
网络协议 Unix Linux
[计算机网络]---TCP协议
[计算机网络]---TCP协议

热门文章

最新文章