个人主页 ： 个人主页
个人专栏 ： 《数据结构》 《C语言》《C++》《Linux》
文章目录
- 前言
- UDP协议
- 报头和有效载荷分离的问题
- 有效载荷向上交付的问题，也就是交给哪个进程？
- 怎么确定把报文收全了？
- UDP报头是如何封装的呢？
- UDP特点
- UDP的缓冲区
- 基于UDP的应用层协议
- 总结
前言
本文是对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报头是如何封装的。
- 定义一个 sk_buff 和 一个缓冲区。刚开始 data 和 tail指向同一个地址。
- data指针向前移动5个字节(hello 的长度)，也就是开辟了5个字节的空间，然后，将 hello 从用户层拷贝到内核层。
- 定义一个 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协议的知识总结
