Linux网络编程:传输层协议UDP

目录

一、端口号

认识知名端口号

二、UDP协议

1.UDP协议端格式

2.UDP的特点

3.UDP缓冲区

4.使用注意事项


一、端口号

端口号是在网络中标识一台主机上进行通信的程序的唯一性 的,在TCP/IP协议中,用源IP、源端口号、目的IP、目的端口号、协议号这样一个五元组来标识一个通信。

而端口号的设定是有其一定的规则的:

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

认识知名端口号

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

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

我们可以在Linux下输入cat /etc/services来查看这些知名端口号:

cpp 复制代码
cat /etc/services

需要注意的是**,一个进程可以绑定多个端口号,但是一个端口号不能被多个进程同时绑定。所以我们在自己写服务的时候,一定要避开这些知名端口号,否则我们的服务就会启动不起来。**

二、UDP协议

1.UDP协议端格式

UDP协议格式如上图所示,由16位源端口号、16位目的端口号、16位UDP长度、16位UDP校验和、数据正文这几部分组成。

  • UDP的报头长度是确定的,16位UDP长度表示整个数据报(UDP首部+UDP数据)的最大长度。
  • (16位无符号整数的最大值是65535字节)
  • 16位UDP校验和是用来校验的,如果校验和出错,那么UDP整个数据报就会被直接丢弃。

2.UDP的特点

UDP传输的过程类似于寄信。

  1. 无连接 :UDP协议是无连接的,只需要知道对端的IP地址和端口号就可以直接进行传输,不需要建立连接。
  2. 不可靠传输 :没有确认机制,没有重传机制,如果因为网络故障该段无法发送到对方,UDP协议层也不会给应用层返回任何错误信息。不可靠传输是UDP协议的特点,虽然看起来像是缺点,但也因不可靠传输让UDP的维护成本比较低,因为它不需要为了可靠传输而做更多其它工作。
  3. 面向数据报 :面向数据报也是UDP协议的另一个特点。所谓面向数据报意思就是,应用层交给UDP多长的报文,UDP原样接收,既不拆分,也不合并。 可以简单理解为UDP接受报文也是原子性的:要么不接受报文,一旦接收了报文,一定是接收完整的报文。举个例子,比如说发送端调用一次sendto函数发送100个字节,那么接收端也必须调用一次recvfrom函数接收100个字节,接收端不可以循环调用10次recvfrom函数每次只接收10个字节。这里就像寄信,别人给我们寄来一封信,我们接收到的一定是一封完整的信,而不是每次只读取几个文字。

3.UDP缓冲区

UDP协议没有真正意义上的发送缓冲区,我们调用sendto函数通过网络发送数据时,本质上其实并不是直接就能通过网络发送到对端,而是将我们的数据发送到操作系统内核 中,操作系统内核再根据自己的发送策略在合适的时机通过网络将我们的数据发送给对端。UDP其实根本不需要所谓的发送缓冲区,因为UDP协议发送的数据格式太简单了,它只需要将数据发送给操作系统内核,操作系统内核直接给它添加上定长的数据报头添加完成之后操作系统就直接将数据交给网络协议栈到达网络层了,不需要维护可靠性不需要暂时将数据暂存起来等操作。

虽然UDP具有接收缓冲区,但是这个接收缓冲区不能保证收到的UDP数据报的顺序和发送UDP数据报的顺序一致,因为在网络层面这些UDP数据报可能先出发但中途耽误了一些时间,所以接收缓冲区无法保证这个顺序和发送时的顺序一致。如果我们需要关心数据报的顺序,只能在发送端应用层维护每一个数据报的发送编号,到了接收端再根据数据报的发送编号进行重新排序。如果UDP的缓冲区满了,再到达的UDP数据就会被丢弃。

4.使用注意事项

我们注意到,UDP协议首部中有一个16位的最大长度.也就是说一个UDP能传输的数据最大长度是64KB(包含UDP首部)。上面说过最大长度是65527 字节(约 64KB)

然而64KB在当今的互联网环境下,是一个非常小的数字.如果我们需要传输的数据超过64KB,就需要在应用层手动的分包,多次发送,并在接收端手动拼装

所以在一些直播场景中,一般采用的是UDP协议 ,原因是如果有大量的观众在观看直播,用TCP让每个用户都为其维护一个连接的话,用户量一旦大起来,服务器可能会承受不住。所以UDP的无连接特点在这种场景下非常适用,不需要再给每个用户建立连接,即使UDP是不可靠传输,在传输过程中可能会出现丢包等情况,但这种情况最多导致直播过程中画面模糊、声音变卡,观众几乎可以忽略,且后续的数据包会快速覆盖这个问题,而这些相比较于服务器崩溃来说是可以接受的,所以采用UDP协议比较合适。

相关推荐
我头发多我先学14 分钟前
linux系统编程:初识进程
linux·运维·服务器
Freak嵌入式24 分钟前
版本混乱 / 依赖缺失?uPyPi:MicroPython 版 PyPI,彻底解决库管理混乱
linux·服务器·数据库·单片机·嵌入式硬件·性能优化·依赖倒置原则
看昭奚恤哭27 分钟前
ontainer App】Container App无法从Container Registries 拉取镜像 - 报错 Forbidden
后端·python·flask
云飞云共享云桌面35 分钟前
SolidWorks—天津智能装备工厂1台高配主机共享给10个研发用
运维·服务器·自动化·汽车·制造
Nebula_g1 小时前
Java实现本地Socket通信(四)
网络
苍狗T1 小时前
LVS相关知识总结
linux·运维·服务器·lvs
QH139292318801 小时前
Keysight N9917B N9918B手持式综合微波分析仪
网络·科技·嵌入式硬件·集成测试·信息与通信
Drgfd1 小时前
半导体国产替代进入“深水区”:决战设备、材料、IP三大高地
网络·fpga开发
程序员cxuan2 小时前
DeepSeek-V4-Flash 正式版来了!这次提升有点夸张。
人工智能·后端·程序员
lightqjx2 小时前
【Linux系统】基础 IO
linux·c语言·重定向·缓冲区·文件io·文件的系统调用