在线做数据图的网站有哪些问题,十大室内设计师排名,那些网站做的非常好看的,可以建站的网站一、摘要
之前在上分享网络编程知识文章的时候#xff0c;有网友写下一条留言#xff1a;“可以写写一篇关于 TCP 滑动窗口原理的文章吗#xff1f;”。
当时没有立即回复#xff0c;经过查询多方资料#xff0c;发现这个 TCP 真的非常非常的复杂#xff0c;就像一个清…一、摘要
之前在上分享网络编程知识文章的时候有网友写下一条留言“可以写写一篇关于 TCP 滑动窗口原理的文章吗”。
当时没有立即回复经过查询多方资料发现这个 TCP 真的非常非常的复杂就像一个清澈的小沟你以为很浅结果一脚踩下去感觉深不可测。
虽然之前也总结过一些关于网络编程相关的技术知识对于 TCP 协议栈也做过一些介绍但是大体上都描述的比较简单没有深入去了解本篇在很大程度上弥补了我对计算机网络知识的空白。
话不多说直接上干货
二、TCP 数据传输
在之前的文章中我们了解到TCP 协议能保证网络上的计算机之间可靠无差错的数据传输比如上传文件、下载文件、浏览网页等都得益于它实际的应用场景非常广泛。
与 TCP 协议一并称霸天下的还有 UDP 协议不过 UDP 协议虽然传输效率更高但是并不保证数据传输正确性相比 TCP 要稍逊一些。
事实上TCP 协议经过多年的发展已经成为实现数据可靠传输的标准协议所谓可靠就是确保数据准确的、不重复、无延迟的到达目的地那 TCP 协议是如何实现这些特点的呢
其实要实现数据可靠传输并不简单因为要考虑异常的情况比较多例如数据丢失、数据顺序混乱、网络拥堵等如果不能解决这些问题也就无从谈起可靠传输。
总的来说TCP 协议是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现数据稳定可靠性的传输。
以下是 TCP 协议的报文格式。 TCP 报文段包括协议首部和数据两部分协议首部的固定部分是 20 个字节头部是固定部分后面是选项部分。
下面是报文段首部各个字段的含义
源端口号以及目的端口号各占 2 个字节端口是传输层和应用层的服务接口用于寻找发送端和接收端的进程一般来讲通过端口号和IP地址可以唯一确定一个 TCP 连接在网络编程中通常被称为一个 socket 接口。序号Seq 序号占 4 个字节。用来标识从 TCP 发送端向 TCP 接收端发送的数据字节流序号发起方发送数据时对此进行标记。确认序号Ack 序号占 4 个字节包含接受端所期望收到的下一个序号。只有 ACK 标记位为 1 时确认序号字段才有效因此确认序号应该是上次已经成功收到数据字节序号加 1即 Ack Seq 1。数据偏移占 4 个字节用于指出 TCP 首部长度。保留字段占 6 位暂时可忽略值全为 0。六位标志位值内容含义如下 URG(紧急)为1时表明紧急指针字段有效ACK(确认)为1时表明确认号字段有效PSH(推送)为1时接收方应尽快将这个报文段交给应用层RST(复位)为1时表明TCP连接出现故障必须重建连接SYN(同步)在连接建立时用来同步序号FIN(终止)为1时表明发送端数据发送完毕要求释放连接 窗口占 2 个字节用于流量控制和拥塞控制表示当前接收缓冲区的大小。校验和占 2 个字节范围包括首部和数据两部分紧急指针指出了紧急数据的末尾在报文段中的位置和 URG 搭配使用选项和填充是可选的默认情况是不选。
计算机之间使用 TCP 协议进行传输数据时每次连接都需要经过 3 个阶段创建连接、数据传送和释放连接即传输数据之前在发送端和接收端建立逻辑连接、然后传输数据、最后断开连接它保证两台计算机之间比较可靠的数据传输。
2.1、创建连接
当两个设备之间准备传输数据之前TCP 会建立连接创建连接的阶段需要三次握手过程如下 详细过程如下
第一次握手客户端向服务器端发出连接请求等待服务器确认第二次握手服务器端收到请求后向客户端回送一个确认通知客户端收到了连接请求第三次握手客户端再次向服务器端发送确认信息确认连接
完成以上 3 次握手之后可靠性连接建立完成就可以进行数据传输了。
2.2、释放连接
当数据传输完毕之后TCP 会释放连接连接的释放需要四次挥手过程如下 第一次挥手客户端向服务器端发出请求切断连接等待服务器确认第二次挥手服务器端收到请求后向客户端回送一个确认信息并同意关闭请求第三次挥手服务器端再次向客户端发出请求切断连接等待客户端确认第四次挥手客户端收到请求后向服务器端回送一个确认信息并同意关闭请求
完成以上 4 次挥手之后连接释放完成。
2.3、数据传输过程
通过以上的介绍我们可以描绘出一个简易版的 TCP 数据传输过程如下图所示。 通过序列号与确认应答机制是 TCP 实现数据可靠传输的方式之一也是最为重要的基石。
但是在复杂的网络环境下并不一定能如上图所描述的那样顺利的进行数据传输例如数据包丢失针对这种问题TCP 使用了重传机制来解决。
三、重传机制介绍
当网络不稳定的时候很容易出现数据包丢失TCP 采用了哪些重传手段来解决数据包丢失问题呢
常见的重传方式有以下几种
超时重传快速重传SACKD-SACK
3.1、超时重传
超时重传顾名思义就是在发送数据时设定一个定时器当超过指定的时间后没有收到对方的 ACK 确认应答报文就会重发数据。
TCP 会在以下两种情况发生超时重传
发送的数据包丢失确认应答丢失
其中比较关键的就是超时重传时间如何来设定的问题。
我们先来看看正常的数据传输过程。 其中 RTT 指的是数据从网络一端传送到另一端所需的时间也就是数据包发送出去的往返时间。
超时重传时间我们以 RTO Retransmission Timeout 超时重传时间来表示。
当超时重传时间设定过大会出现什么情况呢如下图所示 当超时重传时间设定过小又会出现什么情况呢如下图所示 一路分析下来可以得出如下结论
当超时重发时间 RTO 设置较大时会出现数据传输效率差的现象比如数据包丢失之后需要等很长时间才重发性能差当超时重发时间 RTO 设置较小时可能会出现并没有丢失包就重发多次重发会造成网络拥堵导致出现更多的超时更多的超时意味着更多的重发
因此可以得出一个结论超时重发时间既不能设置过大也不能设置过小必须精准的计算。
以 Linux 操作系统为例RTO 的计算过程如下
首先对 TCP 数据传输所需的往返时间也就是 RTT 值进行采样然后进行加权平均算出一个平滑 RTT 的值同时这个值随着网络状态会不断的变化。除了采样 RTT 值还要记录 RTT 的波动变化避免 RTT 的变化较大难以发现 其中SRTT是计算平滑的RTT DevRTR是计算平滑的RTT与最新RTT的差距在 Linux 下通常α 0.125β 0.25μ 1∂ 4至于这个数值是怎么算出的答案就是大量的数据采集统计出来的。
实际算出来的超时重传时间RTO的值应该略大于报文往返RTT的值符合预期值。
如果超时重发的数据再次超时的时候又需要重传的时候TCP 的策略是超时间隔加倍。
也就是说每当遇到一次超时重传的时候会将下一次超时时间间隔设为先前值的两倍多次超时说明网络环境差不宜频繁反复重发。
3.2、快速重传
超时重传虽然能解决数据丢包的问题但是超时重发时间有时候可能会较长有没有一种更快的重传方式呢
快速重传就是来补充超时重传机制中时间过长的问题。
简单的说快速重传不像超时重传那样通过时间来驱动重发而是通过次数来驱动重发。
当收到报文重复的 ACK 数量到达一定的阀值一般为3TCP 会在定时器过期之前检查丢失的报文段并重传丢失的报文段。
大致的工作方式可以用如下图来描述 在上图发送方向接受方发出了 1、2、3、4、5 份数据大致执行的过程如下
第一份 Seq1 先送到了接受方就 Ack 回 2表示 seq 1 已经收到准备接受下一个序列号为 2 的包Seq2 因为某些原因没收到Seq3 到达了因为 Seq2 缺失还是 Ack 回 2后面的 Seq4 和 Seq5 都到了因为 Seq2 没有收到还是 Ack 回 2发送端收到了三个 Ack 2 的确认知道了 Seq2 还没有收到就会在定时器过期之前重传丢失的 Seq2最后接收方收到了 Seq2此时因为 Seq3Seq4Seq5 都收到了于是 Ack 回 6 。
因此快速重传的工作方式是当收到相同的 ACK 报文数量到达一个阀值默认是 3会在定时器过期之前重传丢失的报文段。
快速重传机制弥补了超时重传机制中时间过长的问题但是它依然面临着另外一个问题那就是重传的时候是重传之前的一个还是重传所有的包
例如上面的例子是重传 Seq2 呢还是重传 Seq2、Seq3、Seq4、Seq5 呢
根据 TCP 不同的实现以上两种情况都有可能。
另外按照上文的分析如果每发送一个数据当收到确认应答再发送下一个数据包的传输模式下基本上不会出现快速重传的可能。
关于快速重传的实际应用我们会在滑动窗口中再次进行详解目前只需要知道有这个方式就行。
3.3、SACK 方法
为了解决不知道该重传哪些 TCP 报文天才师们想出来了SACK方法英文全称Selective Acknowledgment也被称为选择性确认。
具体实现就是需要在 TCP 头部选项字段里加一个 SACK 的东西接受方可以将缓存的数据地图发送给发送方这样发送方就可以知道哪些数据收到了哪些数据没收到知道了这些信息就可以只重传丢失的数据。
如下图当发送方收到了三次同样的 ACK 确认报文于是就会触发快速重发机制通过 SACK 信息发现只有200~299这段数据丢失会将丢失的片段进行重发以便提升数据传输可靠性效率。 需要主要的是如果要支持 SACK 机制必须发送方和接受方都要支持。在 Linux 操作系统中开发者可以通过net.ipv4.tcp_sack参数打开这个功能Linux 2.4 后默认打开。
3.4、Duplicate SACK 方法
最后再来讲讲 Duplicate SACK 方法又称D-SACK这个方法实现主要是使用 SACK和ACK来告诉发送方有哪些数据被重复接收了以防止 TCP 反复的重发。
我们用个案例来介绍D-SACK的作用例如 ACK 丢包的场景如下图 过程分析
发送方向接受方成功的发送了两个数据包但是接受方发给发送方两个 ACK 确认应答都丢失了发送方检查超时后重传第一个数据包100 ~ 199接收方发现数据是重复收到的于是回了一个ACK 300和 SACK 100~199告诉发送方100~299的数据早已被接收了因为 ACK 都到300了因此这个 SACK 可以称为D-SACK。当发送方知道数据没有丢是接收方的 ACK 确认报文丢了就不会继续重发数据包了
使用D-SACK方法的好处可以让发送方知道是发出去的包丢了还是接收方回应的 ACK 包丢了然后来决定是否需要继续重发包。
在 Linux 操作系统下可以通过net.ipv4.tcp_dsack参数来开启/关闭这个功能Linux 2.4 后默认打开。
四、滑动窗口介绍
在上文中我们有介绍到 TCP 协议的数据传输机制当两台计算机之间建立连接之后就可以进行传输数据了TCP 每发送一个数据都要进行一次确认应答当上一个数据包收到了确认应答了 再发送下一个从而保证数据的可靠传输。 这种传输方式虽然可靠但是缺点也比较明显传输数据的效率非常的低下好比你现在跟某个人打电话你说了一句话只有等到对方回复了你你才能说下一句这显然不现实。
为解决这个问题TCP 引入了滑动窗口可以一次性向窗口中发送多个数据包并不需要依次等待接受方的确认应答即使在往返时间较长的情况下它也不会降低数据传输效率。
那什么是滑动窗口呢我们以高速路的收费站为例做一个类比介绍。
上过高速的同学应该都知道在高速路上有一个入口收费站和一个出口收费站。TCP 也是一样的除了入口有发送方滑动窗口出口处也设立有接收方滑动窗口。 对于发送方滑动窗口我们可以把数据包看成车辆分类它们的状态
还未进入入口收费站的车辆对应的是上图Not SentRecipient Not Ready to Receive部分这些属于发送端未发送同时接收端也未准备接收的数据已进入收费站但未进入高速路的车辆对应的是上图Not SentRecipient Ready to Receive部分这些属于发送端未发送但已经告知接收方的数据其实已经在窗口中发送端缓存了等待发送。在高速公路上行驶的车辆对应的是上图Send But Not Yet Acknowledged部分这些属于发送端已发送出去等到接收方接受的数据属于窗口内的数据。到达出口收费站的车辆对应的是上图Sent and Acknowledged部分这些属于已经发送成功并已经被接受的数据这些数据已经离开窗口了。
同样对于接受方滑动窗口我们也可以把数据包看成车辆分类它们的状态
还未到达出口收费站的车辆状态为Not Received表示还没有被接收的数据。到达出口收费站但未完成缴费的车辆状态为Received Not ACK表示已经被接受但是还没有回复 ACK缴完费并离开出口收费站的车辆状态为Received and ACK表示已经被接受并回复了 ACK
通过以上的描述相信大家对滑动窗口已经有了初步的认识在整个数据传输过程中光线传输类似于高速公路TCP 滑动窗口类似于收费站通过收费站可以做到对车辆进行适当的流量控制以防止高速公路出现拥堵滑动窗口也有同样的作用。
4.1、发送方的滑动窗口
下图就是发送方的滑动窗口样例图根据处理的情况分成四个部分其中深蓝色方框是发送窗口紫色方框是可用窗口。 含义解释
#1表示已发送并收到 ACK 确认的数据1~31 字节#2表示已发送但未收到 ACK 确认的数据32~45 字节#3表示未发送但总大小在接收方处理范围内46~51字节#4表示未发送但总大小超过接收方处理范围52 字节以后
当发送方把数据全部都一下发送出去后可用窗口的大小就为 0 了表明可用窗口耗尽在没收到接受方 ACK 确认之前是无法继续发送数据的。 当收到之前发送的数据32~36字节的 ACK 确认应答后如果发送窗口的大小没有变化则滑动窗口往右边移动 5 个字节因为有 5 个字节的数据被应答确认接下来52~56字节又变成了可用窗口那么后续也就可以发送52~56这 5 个字节的数据了。 问题来了程序是如何精准的控制发送方的窗口数据呢
TCP 滑动窗口方案使用三个指针来跟踪在四个传输类别中的每一个类别中的字节。其中两个指针是绝对指针指特定的序列号一个是相对指针需要做偏移。 含义解释
SND.WND表示发送窗口的大小大小是由接收方指定的SND.UNA是一个绝对指针它指向的是已发送但未收到确认的第一个字节的序列号也就是#2的第一个字节SND.NXT也是一个绝对指针它指向未发送但可发送范围的第一个字节的序列号也就是#3的第一个字节可用窗口大小是一个相对指针通过SND.WND - (SND.NXT - SND.UNA)公式计算得来
4.2、接受方的滑动窗口
接下来我们看看接收方的滑动窗口接收窗口相对简单一些根据处理的情况划分成三个部分。 含义解释
#1和#2表示已成功接收并确认的数据等待应用进程读取#3表示未收到数据但可以接收的数据#4表示未收到数据并不可以接收的数据
其中三个接收部分使用两个指针进行划分:
RCV.WND表示接收窗口的大小它会通告给发送方RCV.NXT是一个绝对指针它指向期望从发送方发送来的下一个数据字节的序列号也就是#3的第一个字节可接受数据的最大值位置它可以通过RCV.NXT RCV.WND计算得出也就是#4的第一个字节
五、滑动窗口小结
相比传统的发送一个包然后等待确认应答再发送包的数据传输模型滑动窗口这种一次性批量发包然后等待确认应答的传输方式可以显著的提升数据传输效率整个传输过程可以用如下图来描述。 上图中的 ACK 600 确认应答报文丢失也不会影响数据传输因为可以通过下一个确认应答进行确认只要发送方收到了 ACK 700 确认应答就表示 700 之前的所有数据接收方都收到了这种确认应答模式叫累计确认或者累计应答。
在上文中我们提到滑动窗口有一个很关键字的参数就是窗口大小。
通常窗口的大小是由接收方来决定的接收端告诉发送端自己还有多少缓冲区可以接收数据防止发送的数据量过大导致接受方处理不过来会触发发送方重发机制从而导致网络流量的无端的浪费。
通过控制窗口大小可以避免发送方的数据超过接收方的可用窗口也就是大家常说的流量控制。
除此之外计算机网络都处在一个共享的环境难免会出现网络拥堵的现象。当网络出现拥堵时流量控制的手段非常有限。
如果网络出现拥堵时发送方继续发送大量数据包可能会导致数据包时延、丢失等这时 TCP 就会重传数据重传就会导致网络的更拥堵于是会导致更大的延迟以及更多的丢包此时可能就会进入恶性循环….
因此当网络发生拥堵时TCP 需要主动降低发送的数据量避免发送方的数据填满整个网络我们把这一行为称为拥塞控制。
关于流量控制和拥塞控制的实现鉴于文章篇幅过长我们会在下篇文章中进行详解。
本文整理了一些优秀网友分享的知识在此感谢作者小林 coding 的《图解 tcp 滑动窗口文章》分享给予了很大的知识帮助同时结合自己的理解比较全面的探讨了 TCP 滑动窗口的原理希望对大家有所帮助。
六、写到最后
不会有人刷到这里还想白嫖吧点赞对我真的非常重要在线求赞。加个关注我会非常感激
此外本文已整理到技术笔记中笔记内容还涵盖 Spring、Spring Boot/Cloud、Dubbo、JVM、集合、多线程、JPA、MyBatis、MySQL 等技术知识。需要的小伙伴可以点击 技术笔记 获取
