【Linux】UDP协议

传输层

通过前面文章对于应用层的讲解，我们知道应用层主要是将我们的数据按照协议的格式进行划分，它并不关心数据是如何从发送端到接收端的，它将数据报向下交付给传输层，由它来负责数据从发送端传输到接收端。

端口号

端口号（Port）标识了一个主机上进行网络通信的不同的应用程序，当主机从网络中获取数据时，数据需要自底向上进行交付，而上层存在多个应用程序，那么交付给哪一个应用程序就由端口号来决定。

在这里插入图片描述

在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看)；其中 IP 地址和端口号标识网络中唯一的一个进程，而协议号是一个整数，用于标识传输层使用的协议类型。常见的传输层协议包括 TCP 协议、UDP 协议等。

netstat

netstat是一个用来查看网络状态的重要工具。
语法： netstat [选项]
功能：查看网络状态
常用选项：

n 拒绝显示别名，能显示数字的全部转化成数字
l 仅列出有在 Listen (监听) 的服務状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项

在这里插入图片描述

端口号范围划分

0 - 1023：知名端口号，HTTP，FTP，SSH 等这些广为使用的应用层协议，它们的端口号都是固定的。
1024 - 65535：操作系统动态分配的端口号。客户端程序的端口号，就是由操作系统从这个范围分配的。

认识知名端口号(Well-Know Port Number)

有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号:

ssh服务器, 使用22端口
ftp服务器, 使用21端口
telnet服务器, 使用23端口
http服务器, 使用80端口
https服务器, 使用443

我们自己写一个程序使用端口号时, 要避开这些知名端口号。

Q：一个进程可以绑定多个端口号吗？

一个进程可以绑定多个端口号。因为在计算机网络中，一个进程可能需要提供不同的服务或处理不同类型的数据流，因此需要监听不同的端口来处理来自网络的不同请求。

Q：一个端口号可以被多个进程绑定吗？

通常情况下，一个端口号只能被一个进程绑定。这是因为端口号用于标识网络上的特定服务，当客户端尝试连接到服务器的某个端口时，操作系统需要知道哪个进程负责处理该连接请求。如果多个进程绑定到同一个端口号，操作系统将无法确定应该将连接请求发送给哪个进程。但是如果采取的通信协议不同，就可以绑定同一个端口号。例如：一个进程可以使用 TCP 协议绑定到端口号 80，而另一个进程可以使用 UDP 协议绑定到端口号 80。这是因为操作系统不仅根据端口号，还根据通信协议来区分不同的服务。因此，当客户端尝试连接到服务器的某个端口时，操作系统会根据客户端使用的通信协议来确定应该将连接请求发送给哪个进程。

Q：某个报文经过网络传输到达了指定的计算机，它是如何交给指定的进程处理的呢？

我们知道网络通信的本质其实就是上层应用的进程间进行通信，进程间通信就是让双方看到同一份资源。发送端将报文数据经过网络传输到了接收端，报文数据中包含目的IP地址和目的端口号信息，操作系统本身维护一张端口号到进程的映射表，当网络协议栈确定了报文应该交给哪个端口号时，它会查询这张映射表，找到对应的进程，然后将该报文传递给该进程进行处理。

pidof
pidof 命令用于查找指定名称进程的进程 ID，在查看服务器的进程id时非常方便。
语法： pidof [进程名]
功能：通过进程名, 查看进程id

UDP协议

UDP协议端格式

在这里插入图片描述
UDP 报文分为 UDP 报头和 UDP 数据区两部分。报头由 4 个 16 位长（2字节）字段总共8字节组成，分别说明该报文的源端口、目的端口、报文长度和校验值。

源端口：这个字段占据 UDP 报文头的前 16 位，通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。
目的端口：接收端计算机上 UDP 软件使用的端口，占据 16位。
UDP长度：该字段占据 16 位，表示 UDP 数据报长度，包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节，假设没有数据的情况下，UDP数据报长度最小就为 8。
校验值：该字段占据 16 位，可以检验数据在传输过程中是否被损坏。如果数据报未被损坏，网络协议栈会将其传递给上层应用程序进行处理。但是如果数据报在传输过程中丢失或损坏，UDP 协议并不会对其进行重传，UDP协议只会读一个完整的报文，如果读取到的不是完整报文，那么直接会丢弃该报文。

我们知道传输层是负责将数据向上/向下交付给接收端的，那么必定要将报头与有效载荷进行分离，那么对于UDP协议，它是如何来分离的呢？

Q：UDP报头和有效载荷是如何分离的？

UDP协议报头中有2个字节是来表示UDP长度的，而且我们也知道UDP报头是固定大小的，我们只需UDP长度-8字节就能得到有效载荷的长度。当struct UDP_header* p = start，有效载荷的起始位置即为：start + 8.

Q：有效载荷是如何交付给上层的？
在分离出有效载荷后，网络协议栈会将其传递给上层应用程序进行处理。操作系统会维护一个端口号到进程的映射表，当网络协议栈确定了数据报应该交给哪个端口号时，它会查询这张映射表，找到对应的进程，然后将有效载荷传递给该进程进行处理。

Q：为什么应用层使用的端口号类型是 uint16_t 呢？

因为在 UDP 和 TCP 报文头中源端口和目的端口字段都是 16 位长，这意味着端口号的取值范围是 0 到 65535。uint16_t 类型正好可以表示这个范围内的所有整数，因此它被用作应用层端口号的类型。

UDP的特点

UDP 协议是一种无连接的、不可靠、面向数据报的传输协议。

无连接：知道对端的 IP 和端口号就直接进行传输，不需要建立连接。
不可靠：没有确认机制，没有重传机制。如果因为网络故障该段无法发到对方，UDP 协议层也不会给应用层返回任何错误信息。
面向数据报：不能够灵活的控制读写数据的次数和数量。

Q：为什么UDP是面向数据报的？

这是由UDP协议特点性质决定的，UDP 协议是面向数据报的，这意味着它将应用层传递给它的数据作为一个独立的数据报来处理，每个数据报都包含了足够的信息，如：UDP报头字段中的UDP长度，上层应用就能知道我们要接收的数据报长度，使得接收端能够将其独立地传递给上层应用程序。
应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并。用UDP传输100个字节的数据：如果发送端调用一次sendto发送100个字节，那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom，每次接收10个字节。

UDP的缓冲区

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

Q：为什么UDP不需要发送缓冲区呢？

因为应用层交给UDP多长的报文，UDP只需原样发送即可，不需要控制发送长度将其放在缓冲区中，那么直接调用sendto拷贝到内核即可，由内核再将数据进行传递；而由于上层应用的接收速度、网络等各种原因导致数据不按顺序到达，所以我们需要暂时将数据保存在接收缓冲区中。那为何TCP有发送缓冲区？这是由TCP可靠机制决定的，它能控制每次读取多大的数据，保证数据按序到达并且对丢失数据进行重传等，这样就注定了TCP具有发送缓冲区！

UDP协议是全双工通信的，它可以同时进行读与写操作。也就是说，应用程序可以在不等待接收完成的情况下发送数据，反之亦然。这种全双工的工作方式提高了通信效率，使得 UDP 协议能够更好地满足实时应用的需求；而像我们之前提到的管道属于半双工通信，只能有一方进行读或写的操作，你写的时候对方是处于堵塞状态的，必须等你写完才能读。

UDP使用注意事项

UDP 协议首部中有一个 16 位的最大长度，也就是说一个 UDP 能传输的数据最大长度是 64K（包含 UDP 首部）。然而在当今的互联网环境下，64 K 是一个非常小的数字，如果我们需要传输的数据超过 64K，就需要在应用层手动的分包，多次发送，并在接收端手动拼装。

基于UDP的应用层协议

NFS: 网络文件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议

当然，也包括你自己写 UDP 程序时自定义的应用层协议。