【Linux】深入理解传输层：端口号、UDP协议及其应用场景
目录
前言：
1.再谈端口号：
1.1.端口号范围划分
1.2.认识知名端口号(Well-Know Port Number)
1.3两个问题
1.3.1一个进程是否可以bind多个端口号？
服务端进程绑定多个端口号
客户端进程绑定多个端口号
实现方式
1.3.2.一个端口号是否可以被多个进程 bind?
2.UDP协议
2.1.UDP协议端格式
2.2.UDP 的特点
3.什么是面向数据报传输呢
4.UDP 的缓冲区
5.UDP 使用注意事项
UDP应用场景：
前言：
我们首先要知道什么是传输层，传输层就是负责数据能够从发送端传输到接收端。
1.再谈端口号：
端口号(Port)标识了一个主机上进行通信的不同的应用程序。
在 TCP/IP 协议中, 用 "源 IP", "源端口号", "目的 IP", "目的端口号", "协议号" 这样一个五元组来标识一个通信(可以通过 netstat -n 查看);
1.1.端口号范围划分
- 0 - 1023: 知名端口号, HTTP, FTP, SSH 等这些广为使用的应用层协议, 他们的端口号都是固定的.
- 1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的.
1.2.认识知名端口号(Well-Know Port Number)
有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号:
- ssh 服务器, 使用 22 端口
- ftp 服务器, 使用 21 端口
- telnet 服务器, 使用 23 端口
- http 服务器, 使用 80 端口
- https 服务器, 使用 443
我们自己写一个程序使用端口号时, 要避开这些知名端口号。普通用户进程无法直接绑定这些端口号。如果需要绑定这些端口号，通常需要提升进程的权限（例如使用root用户运行程序）
1.3两个问题
1.3.1一个进程是否可以bind多个端口号？
可以的！我们要的是端口号到服务的唯一性，一个进程可以创建多个Socket，每个Socket都可以绑定一个端口号！
服务端进程绑定多个端口号
对于服务端而言，绑定多个端口号通常是为了提供多种服务或处理不同类型的连接请求。例如，一个Web服务器可能同时监听HTTP和HTTPS两种协议，分别对应80和443两个端口。在这种情况下，服务端进程需要绑定这两个端口，以便能够同时处理来自这两个端口的连接请求。
客户端进程绑定多个端口号
虽然客户端通常不需要像服务端那样显式地绑定端口号（因为客户端的端口号通常由操作系统动态分配），但在某些情况下，客户端进程也可能需要绑定特定的端口号。例如，当客户端需要与多个服务端进行通信，并且希望每个连接都使用不同的端口号时，客户端进程就可以绑定多个端口号。此外，在某些网络编程框架中，也允许客户端进程显式地绑定端口号，以便更好地控制网络连接。
实现方式
在编程实现上，一个进程可以通过创建多个套接字（socket），并将每个套接字绑定到不同的端口号上，来实现绑定多个端口号的功能。
1.3.2.一个端口号是否可以被多个进程 bind?
一个端口号在同一时间内不能被多个进程绑定。在操作系统中，端口号是用于区分不同网络服务或应用程序的唯一标识符。当一个进程绑定到一个端口号时，操作系统会记录这个绑定关系，以确保后续的网络请求能够被正确地路由到该进程。
如果多个进程尝试绑定到同一个端口号，操作系统通常会阻止这种操作，因为它无法同时处理来自同一个端口号的多个网络请求。这种限制有助于防止网络请求被错误地路由到错误的进程，从而确保网络通信的准确性和可靠性。
2.UDP协议
2.1.UDP协议端格式
- 16 位 UDP 长度, 表示整个数据报(UDP 首部+UDP 数据)的最大长度;
- 如果检验和出错, 就会直接丢弃
最大长度限制：由于UDP协议首部中有一个16位的最大长度字段，因此一个UDP数据报所能传输的最大长度是64K（65536字节减去IP和UDP首部的长度）。在实际应用中，还需要考虑数据链路层的最大传送单元（MTU）限制。
2.2.UDP 的特点
UDP 传输的过程类似于寄信
- 无连接: 知道对端的 IP 和端口号就直接进行传输, 不需要建立连接;
- 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方,UDP 协议层也不会给应用层返回任何错误信息;
- 面向数据报: 不能够灵活的控制读写数据的次数和数量;
3.什么是面向数据报传输呢
应用层交给 UDP 多长的报文, UDP 原样发送, 既不会拆分, 也不会合并;
举个例子：
用 UDP 传输 100 个字节的数据:
如果发送端调用一次 sendto, 发送 100 个字节, 那么接收端也必须调用对应的一次 recvfrom, 接收 100 个字节; 而不能循环调用 10 次 recvfrom, 每次接收 10 个字节;
4.UDP 的缓冲区
- UDP 没有真正意义上的 发送缓冲区. 调用 sendto 会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
- UDP 具有接收缓冲区. 但是这个接收缓冲区不能保证收到的 UDP 报的顺序和发送 UDP 报的顺序一致; 如果缓冲区满了, 再到达的 UDP 数据就会被丢弃;
UDP 的 socket 既能读, 也能写, 这个概念叫做 全双工
5.UDP 使用注意事项
我们注意到, UDP 协议首部中有一个 16 位的最大长度. 也就是说一个 UDP 能传输的数据最大长度是 64K(包含 UDP 首部).
然而 64K 在当今的互联网环境下, 是一个非常小的数字.
如果我们需要传输的数据超过 64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;
6.UDP应用场景：
由于UDP具有无连接、不可靠和面向数据报等特点，它非常适合于那些对实时性要求较高但对数据完整性要求不高的应用场景。以下是一些常见的UDP应用：
-
实时通信：如在线视频聊天、音频通话等。这些应用需要快速响应和实时传输数据，但对数据的完整性要求相对较低。
-
视频流和音频流：如在线视频、网络电台等。这些应用需要连续传输大量的音视频数据，但对数据的丢失和乱序有一定的容忍度。
-
在线游戏：如网络游戏、多人在线竞技等。这些应用需要实时传输游戏数据，但对数据的完整性要求相对较低，因为游戏逻辑可以处理部分数据的丢失和延迟。
-
DNS（域名系统）：DNS使用UDP来查询域名和IP地址之间的映射关系。由于DNS查询通常较小且对实时性要求较高，因此使用UDP可以提高查询效率。
需要注意的是，虽然UDP具有许多优点，但由于其不可靠性，它并不适合所有应用场景。对于需要高可靠性和完整性的数据传输，建议使用TCP（传输控制协议）或其他可靠的传输层协议。
