传输层协议--UDP

引入

传输层负责数据能够从发送端传输到接收端。

端口号（Port）

端口号标识了一个主机上进行通信的一个进程。

两个问题：

1. 一个进程可以绑定多个端口号吗？--可以

2.一个端口号可以绑定多个进程吗？--不可以

我们需要维护的是一个端口号唯一确定一个进程，这关系好比函数（一个x只能唯一确定一个y才是函数关系，但是y可以对应多个x，y=x²是函数，但是y²=x不是函数），一个端口号只能绑定一个进程，一个进程却可以绑定多个端口号

netstat指令

用来查看网络状况的重要工具

进程的标准输入VS命令行参数

pidof HttpServer | xargs kill -9

xargs 的作用： 将标准输入的内容转化为命令行参数 （HttpServer是程序名称）

上面是一些引入的知识，方便后面介绍使用。

UDP的协议格式

几乎任何协议都要解决2个问题：

1 . 如何分离（封装） 2. 如何交付（解包） 

1. 如何分离？

UDP是固定长度的报头，可以直接将报头和有效载荷分离

2. 如何交付

根据报头中的16位端口号，进行向上交付（进程绑定了端口号）

   1. 为什么我们在应用层编写代码时候，每一次写端口号的时候，都喜欢用 uint16_t ?

                 2.UDP是如何提取整个报文的？ 

  1. 因为协议用的是端口号是16位的；

                 2.  UDP具有将报文一个一个正确接受的能力的，UDP是面向数据报的，通过固定长度的报头可以获取到16位udp长度

理解报文本身

首先，我们有一个很基本的认识，操作系统的底层大部分都是C语言写的。报文在不同主机间通过网络交流传输，肯定是有大量的报文的，那OS该怎么管理他们呢？C++以及java语言的学习者，可能很容易想到类，对象之类的东西，但是 OS的底层主要是 C语言，C是用的什么呢？ --结构体

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既能读又能写，这叫全双工

怎么直观理解全双工和半双工呢

在平常的正常人际交流中，我们通常是比较客气绅士的，两个人说话会等对方说完，确认听清和理解后给出反应（这就是半双工），但是当我们有了冲突矛盾，说话也没有那么客气了，也不在乎别人说什么，这个时候大家都在说话，吵吵闹闹的状态（全双工）。

简单来说： 全双工既在输出，也在接收，半双工只能进行单一的输出或者输入。