传输层协议：UDP

概述

UDP（User Datagram Protocol，用户数据报协议）是一种无连接的传输层协议，位于OSI模型的第四层。与TCP不同，UDP不提供可靠性保证、流量控制或拥塞控制机制，但具有低延迟和高效率的特点，适用于实时性要求高的应用场景。

端口号(port)标识了一台主机上的不同应用程序。

在TCP/IP协议中,用"源IP","源端口号","目的IP","目的端口号","协议号"这样一个

五元组来标识一个通信(可以通过netstat-n查看)：

端口号范围划分：

我们如果使用普通用户绑定知名端口号就会失败，必须用root才能给自己的应用程序绑定知名端口号。

部分知名端口号：

可以用cat /etc/services指令查看知名端口号：

那么这时候就有两个问题：

1.一个进程是否可以bind多个端口号?

------完全可以

2.一个端口号是否可以被多个进程bind?

------可以，但建议一个端口号绑定一个进程

事实上OS管理端口号是通过维护一张Hash Table，每个端口号就是对应的索引，指向的就是对应进程

因此我们不同的端口号完全可以绑定同一个进程，而且我们可以通过开放地址和闭址法来解决哈希冲突，因此一个端口号也能绑定多个进程。

这种做法也告诉我们传输层是如何实现分用的，只需根据五元组中的目的端口号就能准确推送到对应进程，实现分用。

UDP的报头十分简易：

可以看到UDP的报头就只有8字节。而且udp的报头就是一个位段数据结构。

因此udp在进行数据传输时并不会进行序列化和反序列化，而是整体直接发送。然后接受方根据前8字节自行解析报头。

并且udp没有重传机制，如果数据错误就直接丢失。

此外udp是面向数据报的：

应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并;

用UDP传输100个字节的数据:
如果发送端调用一次sendto,发送100个字节,那么接收端也必须调用对应的一次recvfrom, 接收100个字节;而不能循环调用10次recvfrom,每次接收10个字节

刚刚提到udp是面向数据报的，那么发送缓冲区也没有意义。因此udp没有发送缓冲区只有接收缓冲区。

当sendto的时候会直接像peer的内核写入数据，因此udp也支持全双工。

但是这样也有一定问题，同一时段可能会有很多的数据报向上或向下传递。因此操作系统还要额外对这些报文进行管理:

struct sk_buff（socket buffer）是 Linux 内核网络子系统的核心数据结构，用于管理网络数据包的存储和传递。它封装了数据包的元信息（如协议头、设备信息等）和实际数据负载，支持高效的网络数据包处理。