前言
本篇介绍UDP报文格式,认识UDP报文,介绍TCP报文格式,了解TCP可靠性的核心机制,TCP通信中三次握手与四次挥手;如有错误,请在评论区指正,让我们一起交流,共同进步!
文章目录
- 前言
- 1. 认识UDP协议报文格式
- 1.2 校验和
- 2. TCP报文格式
- TCP的可靠性
- 总结
本文开始
1. 认识UDP协议报文格式
UDP报文包含两部分:
① UDP报头 (header) : 报头共8字节分为4部分,每部分两个字节;
1-2字节是源端口号;3-4字节是目的端口号;5-6字节是报文长度;6-8字节是校验和;
传输层中UDP协议上只包含端口,不包含IP;
【注】每个端口号包含在UDP报文中,并占两个字节;
端口号取值范围:0 - 65535;小于1024的端口称为知名端口号,为有名的服务器所预留的端口(但不建议使用,如果想用可以用);
② UDP 正文 / 载荷 ( payload):包含一个完整的应用层数据报;
图示:
UDP报文长度:两个字节 0 - 65535 =》 UDP报文最大长度 64KB;
【注】使用UDP编程需要注意数据不能太长!
1.2 校验和
网络传输并非很稳定,可能会受到外界干扰,产生问题,导致数据传输出错;(电磁传输受干扰造成比特翻转,从而数据传输错误)
校验和的作用:判断一下当前传输的数据是否出错;
① 如果校验和不对,此时数据一定不对;
② 如果校验和对,此时数据也有一定概率是错误的;(不能完全保证)
对于上述问题,为了让校验和有更高的识别率,通常会用数据的内容作为参数进行计算;此时数据变化,校验和也会变化;
=》校验和一般取内容 或者 内容的一部分,通过一些算术运算,数学公式得到一个数值来判断;
例如:目的是想要记住一些书名,就把这些书名的每个开头的字记录下来作为校验和,根据这些开头字来确认记住的书名是否正确,这样就提高了校验的识别率;
验证数据报的准确性过程:
前提:认为输入的内容一样,按照同一个算法得到的校验和也应该一样;
发送方:把载荷数据,通过校验和算法,得到校验和结果s1,然后再发送数据;
接收方:收到数据,再次通过校验和算法,得到校验和结果s2;
如果 s1 != s2 ,校验和不同,数据(内容)一定出现了问题;
2. TCP报文格式
TCP报文格式:
TCP特点:
有连接:
面向字节流: 读写操作涉及字节;
全双工通信: Socket 服务器和客户端都可使用;
可靠传输;
认识TCP核心机制:可靠传输;
TCP的可靠性
1.确认应答
在网络传输中,传输的数据可能会出现后发的消息,先到达的情况,为了解决这种问题,就给发送的消息分配序号,同时应答报文,给出确认序号;
在TCP中:
序列号(序号):TCP将每个字节的数据都进了编号;-》
确认序号:取发送方发过来的全部数据,最后一个字节的下一个字节的序号;
确认序号1001的理解:
① 小于1001的数据,接收方已经收到
② 接收方下面向发送方索要从1001开始的数据(1001之后的数据);
发送方与接收方传输:
消息后发先至产生的原因:
多个报文发送开始是有序的,但在网络传输过程中,每个报文走的路径有不相同,就导致后面的报文可能跑到前面来;
为了解决这种情况,TCP会有接收缓冲区,TCP就可以按照序号针对收到的信息进行整队,让报文再次变得有序;
2.超时重传
确认应当在正常情况下,会顺利进行,但也有不正常情况丢包;
什么是丢包?
网络传输会经过很多节点和设备,每个设备都有自己转发能力的上限,当到达设备流量达到峰值,就可能会引起部分数据被丢包;
超时重传:发送方一直拿不到应答报文,等待一段时间后,还没有收到应答报文,发送方此时认为刚才的数据丢包了,会重新发送一遍数据;
发送方对于丢包的两种判定:一定时间内,没有收到ack(应答报文)
① 数据直接丢失,接收方没直接收到数据,不会发送ack;
② 接收方收到数据,但返回的ack丢失了;
对于上述两种判定,发送方都会重传;
如图:发送方重传会产生接收方收到重复数据的问题,这怎么办呢?
解决方式:TCP自动解决,TCP接收缓冲区会根据收到的数据序号自动去重;
小结TCP可靠性的体现:
① 确认应答保证的可靠性;
② 丢包现象,使用超时重传补充;
3.连接管理
认识TCP如何建立连接 和 断开连接;
3.1 TCP建立连接: 三次握手
何为握手:通信双方,进行一次 网络交互;
三次握手:客户端 与 服务器之间,通过三次交互,建立连接;
【注】syn: 同步报文段,一方向另一个,申请建立连接;
三次握手在内核中自动完成,应用程序不能干预;
syn+ack: 同意客户建立连接的请求,并且服务器也向客户端发起连接申请;
ack: 应答报文段;
图示:
三次握手的目的:验证客户端与服务器,各自发送能力与接收能力是否正常;(确保通信正常)
问题来了:问什么一定是三次,两次不行吗或者四次可以吗?
如果是两次握手,根据上图就是少了客户端对服务器的ack,这时客户端知道接收和发送通信都正常,但是服务器不知道自己发送通信是否正常;(服务器只知道自己接收正常,但是发送正不正常不知道)
如果是四次相当于把中间ack+syn分开发送,可以是可以,但是效率相比于一次发送两个要低,所以最后是这两个一起发送;
3.2 TCP断开连接:四次挥手
四次挥手:通信双方,各自给对方发送一个FIN,再各自给对方返回ACK;
【注】FIN:结束报文;
图示:
【注】建立连接:一定是客户端先发起;断开连接:客户端和服务器都可能先发起;
问题:为什么四次挥手不能合并,而三次握手可以呢?
三次握手:ack 和 syn 都是同一时机触发的,都由内核来完成;
四次挥手:ack 和 fin 是不同时机触发的;
ack是内核完成的,在收到fin的时候第一时间返回 (第一次fin,服务器在收到后立即返回ack; 第二次fin, 是服务器发现客户端断开连接后,再close从而触发fin; );而fin是应用程序代码控制的,必须在调用socket的close方法才会触发;
总结
✨✨✨各位读友,本篇分享到内容如果对你有帮助给个👍赞鼓励一下吧!!
感谢每一位一起走到这的伙伴,我们可以一起交流进步!!!一起加油吧!!!