【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应用场景：
https://i-blog.csdnimg.cn/direct/428905a606764bd29ab520ad3733434c.gif
前言：
我们首先要知道什么是传输层，传输层就是负责数据可以或许从发送端传输到吸收端。
1.再谈端口号：
端口号(Port)标识了一个主机上举行通讯的差别的应用程序。
https://i-blog.csdnimg.cn/direct/a1fd748802f74ac29febb629a867c21d.png在 TCP/IP 协议中, 用 "源 IP", "源端口号", "目的 IP", "目的端口号", "协议号" 如许一个五元组来标识一个通讯(可以通过 netstat -n 查看);
https://i-blog.csdnimg.cn/direct/ba12b3ddb7a24b1b82b27556942664b5.png
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协议端格式
https://i-blog.csdnimg.cn/direct/c047396a111c40a4a50bc1ae055fa525.png
[*]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（传输控制协议）或其他可靠的传输层协议。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]