【JavaEE】——TCP应答报文机制,超时重传机制

发布于:2024-10-16 ⋅ 阅读:(16) ⋅ 点赞:(0)

8e19eee2be5648b78d93fbff2488137b.png

阿华代码,不是逆风,就是我疯

你们的点赞收藏是我前进最大的动力!!

希望本文内容能够帮助到你!!

目录

一:TCP协议(面试重点重点)

1:报头长度

2:保留位

3:六位标志位

二:TCP传输的可靠性

1:场景引入

2:数据后发先至问题

3:序号解决问题

三:应答报文机制

(1)过程梳理

(2)误区

四:超时重传机制

1:发送方丢包

2:超时重传

(1)重传次数有上限

(2)超时时间动态变化

3:接收方丢包

(1)扣款情景引入

4:数据缓存

(1)数据去重

(2)数据排序


一:TCP协议(面试重点重点)

引入:

8位(bit) = 1 字节(byte),8位就是01010111这样的二进制数字组成

1:报头长度

解释:①看报头部分,不算选项那一行(后面再讲)共计5行每一行32位,换算为4个字节。那总共就是4 * 5 = 20个字节,这20个字节是固定长度(最小长度)

②另一种看法:因为4位首部长度是01这样的二进制数据 即范围为   0101(5)——>1111(15);注意这里4位首部长度的单位是4个字节,不是1个字节。所以报头长度的动态波动长度就为5*4=20,15*4=60。即[20,60]。所以这里多出来的40部分可以理解为,就是为了给选项部分预留的空间。

即:报头长度最低为20字节,此时无选项部分,

2:保留位

像UDP这个协议,受到2个字节的限制,无法扩展,如果扩展就会与其他厂商的机器不兼容,

所以在TCP这里,预防TCP以后进行功能扩展,而保留一部分空间,(留个坑位)

3:六位标志位

可以理解为像UDP中检验和一样,把报头和载荷放到一起进行计算,后续会对里面的内容进行具体解释,后面这个图我们会多次用到

二:TCP传输的可靠性

在过去的学习中我们了解到,TCP传输的特点有:有连接,可靠传输,面向字节流,全双工。

其中最重要的机制就是“可靠传输”,在数据传输过程中,我们无法保证数据100%传达到对端,退而求其次,我们可以确认对端是否受到数据了,这样保住了传输的可靠性

1:场景引入

应答机制这是TCP传输中最核心的机制

试想这样一个情景,我给我的发消息女神表白,并邀请她去爬山

本来女神已经答应做我的女朋友了,但是由于“滚,不行”   这条回复信息  ,后发先至,比“好呀好呀”更快一步到达我这一端,导致我以为女神拒绝我了~~~这是一个悲伤的故事

2:数据后发先至问题

为什么会出现信息后发先至这种情况呢?

我们知道,广域网之间是由很多路由器和交换机连接的,那么数据在进行传输的时候就有很多路径可以选择,倘若先发出去的数据包①遭遇线路阻塞,那么很可能后发的数据包②会比①还要先到达另一端。

3:序号解决问题

我们通过加入序号这一形式,来确认应答的哪一条数据,这里的模型只是简化了一下,实际TCP序号和确认序号都是以字节来进行编号的,要复杂的多

假如载荷中有1000个字节那么每一个字节都会有一个相应的序号。由于这个序号是连续的,我们只要确定头序号,后面的字节通过计算就可以很容易拿到了

三:应答报文机制

数据发送出去了,那么以怎样的形式,告知发送方“哦,我收到了”~

注:应答报文——也叫ask报文(asknowledge缩写),通过应答报文来反馈给发送方,当前的数据收到了。

(1)过程梳理

A发送1-1000这个数据,主机B如果收到了,就会反馈一个“应答报文”——应答报文的序号是收到的数据的最后一个字节的序号+1。即从1001开始

注:这里的1001有两层含义

①告诉主机A:序号<1001的数据我都收到了

②主句A你下次应该给我发1001开始的数据了

(2)误区

确认应答机制是TCP“可靠性传输”的核心机制,并非是只要有确认应答机制就可以保证TCP可靠传输。

TCP的可靠传输是因为“进行了三次握手”这一说法是错误的(后续我们会详细解释)

四:超时重传机制

超时重传机制是确认应答的补充

1:发送方丢包

上文有说到,设备间进行通讯的时候需要经过,像路由器和交换机这种中间站,进行转发,我们知道路由器和交换机能处理转发的数据是由上限的,如果超过了负载上限,这个数据报包就会被丢弃 ,这就是我们说的“丢包”现象

2:超时重传

发送方发送完数据后,会等待接收方返回应答报文(不是无限制的等待~),迟迟等不到(超时)ask应答报文,发送方就会认为,这次发送的数据报包丢失了没有到达接收方,那么就会重新在发送一遍。

注:这里的重传次数也是有策略的

(1)重传次数有上限

假设数据传输到接收方的概率是90%,那么发送方发送两次数据发生丢包的概率就是10%*10%=1%。这种情况,此时就很可能不是丢包的问题了,可能是设备的问题,此时设备间就会重新连接,连接失败,就放弃连接了

(2)超时时间动态变化

超时时间会随着重传次数的增加而增大,(因为经历重传之后还丢包的话,大概率是网络的原因,在咋传也是白费力气,不如少传几次,节省力气资源)

3:接收方丢包

上述,我们得到一个结论(有问题):如果发送方(主机A)没有收到ask,那么就认为发送的数据丢包了

这里其实还有一些问题——到底是“发送的数据丢了,还是返回的ask丢了”。从发送方的角度是没有办法区分的。

(1)扣款情景引入

如果是主机A发送扣款数据,主机B完成扣款,并发送ask报文,但是ask丢失了,此时主机A迟迟收不到ask报文(超时重传),A再次发送扣款数据,完蛋了~,扣了两次款。

4:数据缓存

通过之前的socket的学习,我们知道socket在内存当中有一块缓存区(用flush冲刷解决问题那一篇文章)

对于接收到的数据都是先暂时放到缓存区中,攒一波,然后调用read或者scanner.next进行读取操作,这里读的就是接受缓存区中的内容。

这里的应答过程中,也有读取数据这一操作,这里的缓冲区主要有两个作用

(1)数据去重

当数据到达接受方的时候,接收方会先判断一下,缓冲区中是否已经有或者有过这个数据,如果yes,那么就把这个重复发来的数据就丢弃,确保应用程序不会出现重复的数据。

(2)数据排序

对接受的数据按照序号进行排序,保证应用程序中读到的数据顺序跟发送过来的数据顺序是一致的。

注:应用程序读的时候也是按照序号的先后顺序连续读取,可以想象成一个阻塞队列。

实现以上两个作用的核心是:数据有序号