引入
传输层负责数据能够从发送端传输到接收端。
端口号（Port）
端口号标识了一个主机上进行通信的一个进程。
两个问题：
- 一个进程可以绑定多个端口号吗？--可以
2.一个端口号可以绑定多个进程吗？--不可以
我们需要维护的是一个端口号唯一确定一个进程，这关系好比函数（一个x只能唯一确定一个y才是函数关系，但是y可以对应多个x，y=x²是函数，但是y²=x不是函数），一个端口号只能绑定一个进程，一个进程却可以绑定多个端口号
netstat指令
用来查看网络状况的重要工具
进程的标准输入VS命令行参数
bash
pidof HttpServer | xargs kill -9xargs 的作用： 将标准输入的内容转化为命令行参数 （HttpServer是程序名称）
上面是一些引入的知识，方便后面介绍使用。
UDP的协议格式
几乎任何协议都要解决2个问题：
1 . 如何分离（封装） 2. 如何交付（解包）
- 如何分离？
UDP是固定长度的报头，可以直接将报头和有效载荷分离
- 如何交付
根据报头中的16位端口号，进行向上交付（进程绑定了端口号）
1. 为什么我们在应用层编写代码时候，每一次写端口号的时候，都喜欢用 uint16_t ?
2.UDP是如何提取整个报文的？
1. 因为协议用的是端口号是16位的；
- UDP具有将报文一个一个正确接受的能力的，UDP是面向数据报的，通过固定长度的报头可以获取到16位udp长度
理解报文本身
首先，我们有一个很基本的认识，操作系统的底层大部分都是C语言写的。报文在不同主机间通过网络交流传输，肯定是有大量的报文的，那OS该怎么管理他们呢？C++以及java语言的学习者，可能很容易想到类，对象之类的东西，但是 OS的底层主要是 C语言，C是用的什么呢？ --结构体
cpp
struct udp_hdr
{
uint32_t src_port:16; //源端口号
uint32_t dst_port:16; //目的端口号
uint32_t udp_len:16; //UDP长度
uint32_t udp_check:16; //udp 检验和
}这个 ： 大家有没有一点熟悉，对，位断 ，有想要进一步了解这方面知识的uu移步 ：
https://blog.csdn.net/qq_59293418/article/details/122667301?sp
UDP的特点
无连接
不可靠
首先，我想强调的一点是，这里的不可靠并不是一个贬义词，和生活场景是不一样的。UDP不可靠的同时也确保了其简单和高效，像现在很多直播，视频平台就喜欢用UDP协议，其简单高效已于维护，即使是偶尔出现掉帧（数据包丢失等）情况，也是在大多数人可以接受的范围内的。
面向数据报
深入理解 IO类接口
之前写UDP或者TCP的相关代码时候经常会使用到 read/write/sendto/recvfrom/recv/send这些IO类接口。很容易以为这些函数是负责和网络交互的，其实不然，我们通过下面这个图简单分析以下
什么时候发送数据，发送多少数据，发送出错了怎么办？
不用焦虑，这些问题OS会处理的，UDP不用负责这些。
所以，我们有了这个结论： 这些IO类接口本质的工作是将内容从用户层拷贝到内核层，至于接下来的发送系类的事就安心交给OS就好了，他们本身也只是 拷贝函数
UDP的全双工VS半双工
UDP的缓冲区
UDP本身没有真正意义上的发送缓冲区，他只管发送，不处理出错的问题，
但UDP具有接收缓冲区，所以UDP的socket既能读又能写，这叫全双工
怎么直观理解全双工和半双工呢
在平常的正常人际交流中，我们通常是比较客气绅士的，两个人说话会等对方说完，确认听清和理解后给出反应（这就是半双工），但是当我们有了冲突矛盾，说话也没有那么客气了，也不在乎别人说什么，这个时候大家都在说话，吵吵闹闹的状态（全双工）。
简单来说： 全双工既在输出，也在接收，半双工只能进行单一的输出或者输入。