前言

本篇介绍UDP报文格式，认识UDP报文，介绍TCP报文格式，了解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方法才会触发；

总结

✨✨✨各位读友，本篇分享到内容如果对你有帮助给个👍赞鼓励一下吧！！
感谢每一位一起走到这的伙伴，我们可以一起交流进步！！！一起加油吧！！！