网站建设企业有哪些方面提高工作效率的方法不正确的是

个人主页 ： 个人主页
个人专栏 ： 《数据结构》 《C语言》《C++》《Linux》

---

前言

本文是对UDP协议的知识总结

---

UDP协议

UDP协议格式如下：

• 16位源端口号：标识发送数据报的应用程序所在的端口。
• 16位目的端口号：标识接收数据报的应用程序所在的端口。
• 16位UDP长度：表示整个UDP数据报的长度，包括UDP头部和数据部分。
• 16位UDP检验和：表示整个UDP数据报的长度，包括UDP头部和数据部分。

这里我们有几个问题？

报头和有效载荷分离的问题

UDP协议使用固定报头长度(8字节)的方式，来分离报头和有效载荷。

有效载荷向上交付的问题，也就是交给哪个进程？

UDP报头字段中16位目的端口号就是标识接受数据报的进程。

怎么确定把报文收全了？

UDP协议，对于小于8字节的报文会直接丢弃，毕竟光是UDP报头大小就是8字节；对于大于8字节的报文，会用 16位UDP长度 - 报头大小 = 数据长度 和 16位UDP检验和 的方式来确定报文是否收全。

UDP报头是如何封装的呢？

报头是一个结构化字段，也就是结构体。

如果我们一次接受大量的UDP报文，那操作系统要不要对这些报文进行管理？要进行管理。如何管理？先描述，在组织。内核中，为了管理报文，定义了sk_buff结构体。

知道了上面两个结构体，我们就可以以使用 udp 发送 hello 给127.0.0.1:8888为列子，来了解UDP报头是如何封装的。

1. 定义一个 sk_buff 和 一个缓冲区。刚开始 data 和 tail指向同一个地址。
   
2. data指针向前移动5个字节(hello 的长度)，也就是开辟了5个字节的空间，然后，将 hello 从用户层拷贝到内核层。
   
3. 定义一个 struct udphdr 结构体，在将16位原端口号，16位目的端口号，16位UDP长度，16位UDP检验和信息填充。然后，data再前移8个字节，再见报头字段拷贝到缓冲区。
   
   到这里，对报文进行UDP封装就完成了。
   以下是 linux-2.6.11.10下的udphdr结构体 和 sk_buff结构体
   

UDP特点

• 无连接：知道对端的IP和端口号就直接进行传输，不需要建立链接
• 不可靠：没有确认应答机制，没有重传机制，如果因为网络故障导致报文无法发到对方，UDP协议也不会给应用层返回任何错误信息
• 面向数据报：不能够灵活的控制读写数据的次数和数量(应用层交给UDP多长的有效载荷，UDP会加上报头直接发送，不会拆分，也不会合并)

UDP的缓冲区

• UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续传输动作
• UDP具有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报文的顺序和发送UDP报文顺序的一致；如果缓冲区满了，再到达的接收端主机的UDP报文就会被丢弃

基于UDP的应用层协议

• NFS：网络文件系统
• TFTP：简单文件传输协议
• DHCP：动态主机配置协议
• BOOTP：启动协议
• DNS：域名解析协议

---

总结

以上就是我对于UDP协议的知识总结