【网络篇】----- 传输层协议 之 UDP（协议格式，协议特性和编程影响三方面详细分析）

文章目录

• 前言
• 1、UDP协议
• 2、协议格式
  • 2.1、协议格式模型
  • 2.2、字段分析
• 3.协议特性
• 4.编程影响
• 总结

---

前言

---

1、UDP协议

UDP协议，又名数据报传输协议，是传输层协议之一！！！

在TCP/IP五层模型中，在传输层中，对数据的封装时，会对上层应用层的数据，封装对应传输层协议的报头！！！可铁子，你知道UDP报头中长啥损样不？？

这就为佬，你解密！！！

2、协议格式

2.1、协议格式模型

2.2、字段分析

• 16位源端端口和16位对端端口： 传输协议，即本身便是负责“两端”的数据传输，其实则交代何去何从罢了；

---

• 16位报头长度： 描述报文长度（包含头部在内）；

16位的报头长度，实则就已经限制了，UDP报文大小必须要小于64K
同时在套接字编程中，我们还接触一接口，sendto函数接口（UDP发送数据接口）

函数接口原型如下：

 ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,const struct sockaddr *dest_addr, socklen_t addrlen);

其中buf参数，为发送数据的数据长度，它的长度会有限制吗？？？
当然！UDP报文的被限制于64K以内，而其中固定数据包含8字节（16位源端端口，16位对端端口，16位报头长度以及16位的校验和），而剩余的64K-8，即为发送数据的最大长度；

---

• 16位校验和： 用于检验接受到的数据是否于发送的数据一致；

  • 之所以存在校验和，是因为，数据在传输给对端的时候，可能收到多方面因素的影响，例如网速，进而导致数据出现部分丢失，甚至数据到达对端的先后不同而产生错误；
  • 因而对端在接受数据时，首先就会通过一定算法，比较报文头部字段中的校验和，判断当前按数据是否与发送数据保持一致；一致则接受，反之则直接丢弃；

而其中，关于用校验和验证接受到数据与发送数据是否一致，大佬们则想出了算法！！
二进制反码求和算法，步骤如下：

	- 发送方将报文数据组织完毕，将校验和字段置为0；- 从第0个字段（包含头部），对每个字段进行取反，求和；- 再求和过程中，若数据大小超过16位，则截断，并于低16位进行求和；- 最终得到的32字节的校验和数据，填充UDP头部的校验和字段中；- 接受方接受到数据，同样对数据进行相同的操作！！！

关于这种算法，博主，也没具体尝试过，不过倒是想起了数据的原码与反码的相互转换，其中，有一种方法，便是，对同一数据的原码，反码进行相同的数求反码操作，均会得到对方；

3.协议特性

UDP协议，有三大特性，即无连接，不可靠与面向数据报传输；

• 无连接： 即收发数据双方，无需建立连接，便可接收发送数据；

就比如咱们在一些聊天APP上，比如QQ，不一定需要对方在线才能发送数据，当然QQ的通信方式，以UDP为主，TCP-为辅；

---

• 不可靠： 即不能保住数据有序，且安全的到达对端；

其原因也在于，UDP传输不存在丢包检测，重传机制以及无包序管理，上述提到的16校验和，实则仅仅只是验证数据的一致，而并没有做出任何使数据安全的措施;

UDP说：

但是UDP，人家也是真的快啊！！！在无以上的操作，UDP的传输效率也得到了大大提升；

---

• 面向数据报： UDP的数据都是整条交付的，且数据有固定最大长度限制，必须小于64K；

4.编程影响

• 由于数据可能无法安全对端，那就让收拾这烂摊子吧！！！；

程序猿，可在应用层进行对应操作：

• UDP面向数据报，有固定长度限制，64K（应用层数据小于64K-8）

但是要是数据大于64K呢？则需要分包处理！！(此处的分包，是在应用层方面对数据进行分包，与UDP数据的整条交付必定不冲突~~)

• UDP要求数据整条传输交付

当接受方接受UDP数据时，会将其整条（带头部）置于接受缓冲区中！！

~~~ 带头部，这嘛呢？？

不带头部，嘛取数据呢？？！！对于UDP报文数据的解析，首先就先取出头部的16位报头长度，之后减去8字节固定数据，剩下的便是数据大小；（也正因为如此，UDP传输不存在数据的粘包问题！！！）

同时需要注意的是，程序员接受recvfrom接受数据的缓冲区，一定要足够大！！！否则，可能应为无法存放下数据而导致，数据丢失！！！

总结

传输层，不还有个TCP吗，博主觉的两个板块，分别写一个博客，会方便观看点~
下期，TCP协议，仍会从以上方面，逐个分析，还有诸多面试题的详细分析！！！
不想错过，就给博主，一个小小的关注吧？