个人主页：Lei宝啊
愿所有美好如期而遇
Udp协议段格式
16位Udp长度，表示整个数据报长度(报头(8字节) + 数据)。
如果校验和错误，报文直接丢弃。
端口号划分及知名端口号
- 0 - 1023: 知名端口号, HTTP, FTP, SSH 等这些广为使用的应用层协议, 他们的端口号都是固定的.
- 1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的
ssh 服务器, 使用 22 端口
ftp 服务器, 使用 21 端口
telnet 服务器, 使用 23 端口
http 服务器, 使用 80 端口
https 服务器, 使用 443使用cat /etc/services命令可以查看到知名端口号
两个问题
一个进程是否可以bind多个端口号？
：可以，一个进程可以创建多个套接字，每个套接字都可以绑定一个端口号，这样，一个进程也就可以bind多个端口号，实现多端口监听和数据处理。
一个端口号是否可以被多个进程bind？
：一个端口号通常只能由一个进程bind，每个端口号在本地机器上都是唯一的，用于区分不同的服务或应用程序。但是凡事有特殊情况，通过一些手段我们可以实现，但是我们一般不考虑，认为是不可以的。
Udp特点
无连接：只需要知道目的ip和目的端口就可以实现通信，不需要连接。
不可靠：没有确认机制，没有重传机制，如果因为网络故障该段无法发到对方,UDP 协议层也不会给应用层返回任何错误信息。
面向数据报：没有面向字节流的粘包问题，数据怎么发的，发多少，会原样发送，不会拆分也不会合并，这个就和Udp协议的设计有关。
Udp缓冲区
Udp没有真正意义上的发送缓冲区，为什么？什么又是发送缓冲区？如何理解解包与封装？
首先，OS内可不可以存在很多收到的报文，而这些报文还没有来得及处理，他们处在OSI七层模型的各个层中，那么OS要不要对这些报文进行管理呢？需要，所以就会有这样的结构：
所以，向下封装时，也就变成了头指针的移动，从应用层到传输层的封装，就是这样的流程：
而解包，就变成head - sizeof(struct udphdr);
而管理报文的结构体，事实上，发送缓冲区就是由这样的结构体组成的队列，上层将数据直接写入到他所管理的内存空间中。
而Udp是没有真正意义上的发送缓冲区的，调用 sendto 会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作，但是Udp有接收缓冲区，毕竟他也支持全双工，所以接收缓冲区还是要有的，而Udp接收缓冲区满了，再有到达的Udp数据则直接丢弃。
