当前位置: 首页 > article >正文

【JavaEE初阶】深入理解TCP协议特性之延时应答,捎带应答,面向字节流以及异常处理

 

前言

🌟🌟本期讲解关于TCP协议的重要的机制“延时应答,捎带应答,面向字节流,异常情况”~~~

🌈感兴趣的小伙伴看一看小编主页:GGBondlctrl-CSDN博客

🔥 你的点赞就是小编不断更新的最大动力                                       

🎆那么废话不多说直接开整吧~~

目录

📚️1.延时应答

1.1概念的引出

1.2延时应答机制

1.3丢包处理机制

📚️2.捎带应答

2.1概念的引出

2.2捎带应答机制

📚️3.面向字节流

3.1粘包问题

3.2解决办法

3.3UDP的情况

📚️4.异常情况

4.1一方进程崩溃

4.2一方进行了关机

4.3 一方出现了断电

4.4网线断开

📚️5.总结


 

📚️1.延时应答

1.1概念的引出

我们知道在上节的描述中知道滑动窗口的大小,是取决于接受方返回ack报文段中16位窗口大小这个字段的影响,所以为了在这个基础之上我们需要提高效率,那么此时就是涉及到就是我们应该增大ack报文携带的这个字段的大小

注意:由于16位窗口大小依赖于接受方缓冲区的剩余空间大小,所以我们要提升缓冲区的的剩余空间的大小

此时依据上面的讲解,就提出来一个重要的概念:“延时应答”;

1.2延时应答机制

机制:

所谓的延时应答,就是当接收方收到来自发送方的数据的时候,不会立即返回ack确认应答报文,而是等待一段时间,在这个时间里处理更多的数据,然后再发送ack;

注意:

等待一段时间后返回ack,给接受方更多的时间来处理缓冲区里更多的数据,那么返回ack报文中16位窗口大小的字段的数据就更大的,对应的发送方的滑动窗口就会增大了;

1.3丢包处理机制

前言:

我们知道在滑动窗口中ack丢包了,那么对于滑动窗口来说是没有什么影响的,当收到后面的ack,就表示前面的数据已经被接收到了;

机制:

在延时应答中,就是在滑动窗口的机制之上,当ack丢包后,延时应答会继续接受数据,然后每隔几个数据返回ack,(那么此时返回ack就表示前面的数据都已经收到了,而且每隔几个数据就表示减少了ack的发送节约了带宽,并且便于接收方处理更多缓冲区里的问题了)

注意:这里的等待,不仅仅是依赖于等待的数据的数量,还有这个时间的参考;所以在传输的数据不多的时候,那么在一定时间后,也会发送ack;

📚️2.捎带应答

2.1概念的引出

我在延时应答机制中理解到这是一种提高发送方的发送的窗口大小的方法,而延时发送ack时,可能与请求响应的时间会进行重合,那么此时就会引出一个新的概念“捎带应答”

2.2捎带应答机制

这里的机制是在延时应答机制的前提之上,因为ack延时发送,那么会导致可能和请求或者响应的发送时间相差不大,那么此时就可以进行重合;

具体实例如下两个图的比较:

解释:

可以看到此时的ack和response在延时应答的情况下,两者执行的时间相差不大,那么此时就可以将ack报文,以及响应进行重合为一个TCP数据报,那么这就形成了捎带应答;

注意:

合并的前提是由于ack报文不携带载荷,只有报头中的窗口大小以及ack标志位更改为1,以及确认序号.....和请求和响应合并没有影响,所以这里可以合并

优点:

1.由于捎带应答是在延时应答的基础之上,那么延时ack继承了延时应答的优点,增大了发送方的发送窗口,提高了效率

2.将ack和响应或者请求重合及合并起来,减少了封装和分用的开销,并且还提高了一定的效率

📚️3.面向字节流

3.1粘包问题

在这里面向字节流那么就有一个重要的问题“粘包问题”,那么此处的包指的是TCP数据包,那么具体情况如下:

那么加入这三个TCP携带的应用层数据包,在接收缓冲区里的情况就是

111222333 

那么此时主要问题就是:“由于TCP中read字节的方法是非常灵活的”那么就会导致可能读取的数据就是:

1、11、111、1112、11122 

这中大概样式的数据,那么此时就无法分辨出多个应用层数据包,所以就会导致“粘包问题” 

3.2解决办法

这边主要有两种解决办法:

第一种:通过特殊的符号,作为分割符,那么在讲到分隔符的时候,就表示一个数据包结束了;

第二种:指定包的长度,在最开始的时候,加上一个特殊空间存储数据来表示整个数据的长度;

注意:

在第一种情况下,特殊符号是不能再正式的数据中出现的;

第二种情况下,具体前面的数据表示的是后面数据的长度,那么具体的样式是如下所示的:

这里前面的特殊存储空间就是两个字节的长度(这是固定的); 

3.3UDP的情况

在上面我们了解到由于TCP是传输的单位是面向字节流,那么就会发生粘包问题,所以这个粘包问题不是针对TCP而是所有一面向字节流单位传输的;那么UDP会有这样的情况吗??

注意:

UDP的传输的单位是面向数据报,所以这里不会发生粘包的问题~~~

那么UDP的接受缓冲区的样子是如何的呢,具体图片解释如下:

 

这里的接受缓冲区就像是一条链表,所以每个节点就是一个UDP数据报,里面存储的就是应用层数据报,所以就会泾渭分明,不会出现粘包的问题;

📚️4.异常情况

所谓的异常情况,就是比丢包更加严重,那么此时就有一下几种异常的情况:

4.1一方进程崩溃

进程无论是正常结束还是异常崩溃都是触发回收文件资源,还是会触发四次挥手;

TCP的连接的生命周期比进程更加的长

所以在一方进程结束的时候,就会触发四次挥手,这种异常情况和一般情况差不多;

4.2一方进行了关机

这里当关机后,会直接出现系统关闭,所以关机意味着进程结束了,但是系统也要进行关闭,所以可能会导致四次挥手执行不完

注意:但是至少关机一方能发送fin给对方,所以当接受到后没有关机的一方就会发送ack和fin表示我愿意你断开连接,然后由于没有受到对方的ack就会进入“超时重传”

由于没有还是没有受到ack就会单方面断开连接(单方面删除对方的信息);

4.3 一方出现了断电

那么此时就是更加严重的情况就是fin都还没发送;

1.若是接受方断电:

此时发送方就会发现没有ack发过来了,那么就会有以下情况,进行重传,若还是没有受到ack,就会进入“复位连接”(清除TCP中的临时的数据,重新开始连接)若还是没有受到ack,那么就会直接放弃连接;

2.若是发送方断电:

那么此时就是接受方阻塞等待发送方发送消息,那么此时接受方就会判断发送方是挂了还是暂时没有发送,此时就会发送“心跳包”来确认对方的信息,如果对方没有心跳就会尝试复位连接然后再断开连接;

注意:

RST:是复位连接的标志位;

URG:是表示TCP中带有特殊功能的数据包,携带一些特殊功能的数据

PSH:这里表示的就是催促的意思,叫对方快点发送消息

心跳包:是周期性的发送的,并且不携带应用层数据的特殊数据包,没有心跳就视为对方挂了;

4.4网线断开

这里即时网络通信断开了,就是上面一方出现的断电的情况,即这里就是两边都断电了,接受方和发送方的处理情况就是上面的情况,小编就不再过多的赘述了~~~

📚️5.总结

OK啊uu们,小编在本期主要讲解了关于TCP特性的几种机制:延时应答,捎带应答,面向字节流,异常情况...到此关于TCP的主要的比较重要的特性小编就在次讲完啦,TCP的特性是面试中表重要的一部分,希望各位uu能够好好了了解一下

那么接下来就是关于IP的协议的理解了,小编会在下期讲解哦~~~

🌅🌅🌅~~~~最后希望与诸君共勉,共同进步!!


💪💪💪以上就是本期内容了, 感兴趣的话,就关注小编吧。

                 😊😊  期待你的关注~~~


http://www.kler.cn/a/377743.html

相关文章:

  • windows下Redis的使用
  • 电子电气架构 --- 什么是自动驾驶技术中的域控制单元(DCU)?
  • uniapp使用live-pusher实现模拟人脸识别效果
  • Speckly:基于Speckle文档的RAG智能问答机器人
  • Vue axios 异步请求,请求响应拦截器
  • ArrayList源码解析
  • 修改 Docker 镜像默认存储位置的方法
  • 申请CNAS软件测试资质,如何选择测试工具最具性价比?
  • 三、Kafka集群
  • Vue常用的修饰符有哪些?
  • 基于PyTorch的大语言模型微调指南:Torchtune完整教程与代码示例
  • MATLAB FDATool工具箱入门教程
  • ubuntu20.04 加固方案-设置用户缺省UMASK
  • Vue 学习随笔系列十三 -- ElementUI 表格合并单元格
  • redis详细教程(5.AOP和RDB持久化)
  • 在 ubuntu20.04 安装 docker
  • 无人机拦截捕获/直接摧毁算法详解!
  • Dockerfile 增强新语法
  • A Consistent Dual-MRC Framework for Emotion-cause Pair Extraction——论文阅读笔记
  • 【JAVA】利用钉钉自定义机器人监控NACOS服务,实现实时下线通知
  • LabVIEW 离心泵机组故障诊断系统
  • 【elkb】创建用户和角色
  • 银行零售贵金属交易-小程序端业务
  • 项目升级到.Net8.0 Autofac引发诡异的问题
  • Rust常用属性及应用
  • windows rdp 将远程技术嵌入到你的软件——未来之窗行业应用跨平台架构