
🔥承渊政道: 个人主页
❄️个人专栏: 《C语言基础语法知识》 《数据结构与算法》 《C++知识内容》 《Linux系统与网络知识》 《算法刷题指南》 《测评文章活动推广》 《大模型语言路线学习》 《MySQL数据库学习》 《Python知识内容》 《cpolar知识学习》
✨逆境不吐心中苦,顺境不忘来时路!✨ 🎬 博主简介:

在Linux网络编程中,会调用发送与接收接口,只是使用UDP的第一步.要真正理解它,还需要回答几个问题:不建立连接,数据如何到达目标应用?一次发送的数据会以什么形式被接收?数据丢失或接收顺序发生变化时,又该由谁处理? 这些问题串联起了 UDP的报文结构、通信机制与应用选择,也是从"会用接口"走向"理解协议"的关键.UDP是一种无连接、面向数据报的传输层协议 ,通过端口将数据交付给对应的应用程序.它采用固定的八字节首部,保留数据报边界,但不保证数据可靠、有序地到达,也不自动提供丢包重传机制.因此,选择UDP并不是简单地认为它"比TCP更快",而是需要结合业务,在通信开销、实时性与可靠性之间作出取舍,并在必要时由应用层补充相应机制.本文将以 "传输层职责 → 报文结构 → 通信机制 → 应用场景" 为主线,首先理解端口与数据分用,再逐一分析源端口、目的端口、长度和校验和字段,随后结合实例说明数据报边界、丢包、乱序以及广播与多播等特点.最后通过与TCP的对比及收发、抓包实验,将协议原理与实际现象对应起来,为后续网络编程和传输协议选择打下基础.

目录
- 一、传输层
- 二、再谈端⼝号
-
- 2.1端⼝号范围划分
- [2.2认识知名端⼝号(Well-Know Port Number)](#2.2认识知名端⼝号(Well-Know Port Number))
- 2.3两个问题
- 三、UDP协议
一、传输层
传输层(Transport Layer)负责应用进程之间的端到端通信,是OSI七层模型的第4层,位于网络层之上. 常见协议是 TCP 和 UDP.
1.它解决什么问题?
一台电脑上可能同时运行浏览器、微信和游戏.网络数据到达电脑后,需要交给正确的应用.
- 网络层通过 IP 地址寻址,负责将数据包送往目标主机.
- 传输层通过端口号区分通信端点,帮助操作系统将数据交给相应的应用进程.
例如,访问网站时,通信端点可以表示为:
客户端 IP:临时端口 → 服务器 IP:443
2.主要功能
- 进程间通信:让两端的应用交换数据.
- 复用与分用:多个应用共享网络;接收端根据端口等信息分发数据.
- 按协议提供传输保障:例如 TCP 提供可靠传输、流量控制和拥塞控制.
注意:可靠传输并不是所有传输层协议都提供的功能.
3.TCP和UDP的区别
| 对比项 | TCP | UDP |
|---|---|---|
| 连接 | 传输前需要建立连接 | 无需先建立连接 |
| 数据形式 | 字节流,不保留应用消息边界 | 数据报,保留消息边界 |
| 可靠性 | 通过确认、重传等机制提供可靠、有序的传输 | 不保证送达、顺序或去重 |
| 流量控制 | 有,避免发送速度超过接收方的处理能力 | 协议本身不提供 |
| 拥塞控制 | 有,根据网络状况调节发送速率 | 协议本身不提供 |
消息边界的例子:应用连续发送"你好"和"世界",TCP接收方可能一次读到"你好世界",需要应用自己划分消息;UDP接收方收到的仍是独立的数据报,但可能发生丢失或乱序.
记住两个区别:网络层负责主机间的数据包传递,传输层负责进程间的数据传输;TCP提供可靠字节流,UDP提供数据报服务.
二、再谈端⼝号
端⼝号(Port)标识了⼀个主机上进⾏通信的不同的应⽤程序.

在TCP/IP协议中,⽤"源IP","源端⼝号","⽬的IP","⽬的端⼝号","协议号"这样⼀个五元组来标识⼀个通信(可以通过netstat -n查看).

2.1端⼝号范围划分
TCP和UDP的端口号都是16位无符号整数,取值范围为 0~65535,共65536个端口号.
根据IANA的规定,端口号主要划分为三类.
1.端口号范围划分

| 分类 | 端口号范围 | 主要用途 |
|---|---|---|
| 熟知端口(系统端口) | 0~1023 | 常见标准网络服务 |
| 注册端口(用户端口) | 1024~49151 | 注册应用和其他应用服务 |
| 动态/私有端口 | 49152~65535 | 临时通信、客户端端口 |
2.三类端口的区别
① 熟知端口:0~1023
通常用于标准网络服务.例如:
| 端口 | 协议 | 应用 |
|---|---|---|
| 21 | TCP | FTP |
| 22 | TCP | SSH |
| 25 | TCP | SMTP |
| 53 | TCP/UDP | DNS |
| 80 | TCP | HTTP |
| 443 | TCP | HTTPS(也可使用 UDP/QUIC) |
注意:端口0是保留端口,不是普通应用服务端口.
② 注册端口:1024~49151
供应用程序和特定网络服务使用,其中部分端口已由 IANA 正式注册.
例如MySQL常使用TCP3306,Redis常使用TCP 6379.
③ 动态/私有端口:49152~65535
通常可供客户端建立连接时临时分配,也称临时端口(Ephemeral Ports).
但实际操作系统的临时端口分配范围可以不同,不一定严格限定在 49152~65535.
3.结合前面理解
例如客户端 A 访问 Web 服务器:

这里有一个特别容易混淆的知识点:
- 服务器使用的80属于熟知端口.
- 客户端使用的2001属于注册端口范围,但仍然可以作为客户端的临时源端口.
因此,端口号的分类不等于端口用途的强制限制.不是只有动态端口范围才能用作客户端源端口.
2.2认识知名端⼝号(Well-Know Port Number)
知名端口号(也叫熟知端口号)是指 0~1023 范围内的端口号,通常分配给常见的网络服务,例如 HTTP、FTP、SSH、DNS 等.
可以这样理解:
- IP 地址:找到哪一台计算机.
- 端口号:找到计算机上的哪一个网络服务.
- 知名端口号:相当于某些网络服务约定俗成的固定门牌号.
1.常见的知名端口号
| 端口号 | 应用层协议 | 传输层协议 | 主要作用 |
|---|---|---|---|
| 20、21 | FTP | TCP | 文件传输 |
| 22 | SSH | TCP | 安全远程登录 |
| 23 | Telnet | TCP | 远程登录(不加密) |
| 25 | SMTP | TCP | 邮件传输 |
| 53 | DNS | UDP/TCP | 域名解析 |
| 67、68 | DHCP | UDP | 自动分配 IP 地址 |
| 69 | TFTP | UDP | 简单文件传输 |
| 80 | HTTP | TCP | 网页访问 |
| 110 | POP3 | TCP | 接收电子邮件 |
| 123 | NTP | UDP | 网络时间同步 |
| 143 | IMAP | TCP | 邮件访问与同步 |
| 161、162 | SNMP | UDP | 网络设备管理 |
| 443 | HTTPS | TCP/UDP | 加密网页通信 |
FTP的21端口用于控制连接,20端口通常用于主动模式的数据连接;HTTPS使用TCP443,基于 QUIC 的HTTP/3通常使用UDP443.
2.形象理解知名端口号
把一台服务器想象成一栋办公楼:

例如:
访问 http://192.168.1.100,浏览器通常默认访问 TCP 80 端口.
访问 https://192.168.1.100,浏览器通常默认访问 443 端口.
这就是为什么同一台服务器能够同时提供网页服务、文件传输、远程登录等功能.
2.3两个问题
1.一个进程是否可以 bind 多个端口号?
可以.一个进程可以创建多个Socket(套接字),分别绑定不同的端口号.
例如,一个进程同时提供两个服务:

这个进程既可以监听 8000 端口,也可以监听 9000 端口.
关键:一个进程可以拥有多个Socket,每个Socket可以绑定相应的本地地址和端口.
2.一个端口号是否可以被多个进程 bind?
可以,但要分情况讨论.
| 场景 | 能否绑定相同端口 |
|---|---|
| 相同 IP、相同协议,普通 TCP 监听 | 通常不能 |
| 不同 IP、相同协议 | 可以(满足地址绑定条件) |
| 相同 IP、不同协议(TCP/UDP) | 可以 |
相同 IP、相同协议,启用 SO_REUSEPORT |
支持的系统上可以 |
例如,进程 A 已经监听:
192.168.1.10:8080(TCP)
此时,进程B如果也想普通监听 192.168.1.10:8080(TCP),一般会遇到 Address already in use(地址已被使用)错误.
但如果操作系统支持,并且两个进程正确配置了 SO_REUSEPORT,就可以共享相同的监听地址和端口.
3.结合之前的图片理解
前面的图片中,有三个 HTTP 服务进程:
- httpd1:80
- httpd2:80
- httpd3:80
为什么三个进程看起来都能使用 80 端口?
因为可能采用了多个工作进程共享同一个监听 Socket 的方式,例如服务器主进程先创建监听 Socket,再通过 fork() 创建子进程.也可能通过 SO_REUSEPORT 让多个进程分别创建监听 Socket.
注意,多个进程共同处理 80 端口的连接,不代表它们都独立执行了 bind(80).
另外,即使服务器只有一个监听 Socket,也可以同时服务很多客户端:
客户端 A:2001 ──┐
│
客户端 A:2002 ──┼──→ 服务器 TCP 80
│
客户端 B:2001 ──┘
因为TCP能利用源IP、源端口、目标IP、目标端口区分不同连接.
最重要的两个结论:
① 一个进程 → 多个端口:可以.创建多个Socket即可.
② 一个端口 → 多个进程:有条件可以.取决于IP地址、传输层协议、Socket选项以及操作系统的绑定规则.
理解这个问题的关键是:端口号不是直接绑定到进程上的,而是通过Socket与进程建立联系.
三、UDP协议
UDP(用户数据报协议)是传输层的一种协议,特点是:无连接、不保证可靠交付、面向数据报、开销小.
可以把 UDP 理解为寄快递:发送方把数据包交给网络,网络负责尽力传送,但UDP本身不保证对方一定收到,也不保证数据按发送顺序到达.
1.UDP是如何工作的?
假设客户端 A 向 DNS 服务器发送域名解析请求.

UDP不需要像TCP一样先进行三次握手,可以直接发送数据.
2.UDP协议的四大特点
| 特点 | 解释 |
|---|---|
| 无连接 | 发送数据前不需要建立传输层连接 |
| 不可靠交付 | 不保证数据一定到达,不自动确认、重传 |
| 面向数据报 | 保留应用层每次发送的数据报边界 |
| 首部开销小 | UDP 首部固定只有 8 字节 |
其中,面向数据报 是非常重要的概念.
假设发送方连续发送两个 UDP 数据报:

UDP不会像TCP字节流一样合并数据边界.但两个数据报可能丢失、乱序,接收缓冲区不足时还可能被截断.
3.UDP报文格式(重点)
UDP 首部一共 8 字节(64位),由四个字段构成,每个字段都是16位.

各字段作用:
- 源端口号:标识发送方的端口.
- 目的端口号:标识接收方的端口,用于将数据交给正确的应用.
- UDP 长度:UDP 首部与数据部分的总长度,以字节为单位.
- 校验和:检查传输过程中是否出现数据差错,但不负责纠错或重传.
4.UDP与TCP的区别
| 比较项目 | UDP | TCP |
|---|---|---|
| 是否需要建立连接 | 不需要 | 需要 |
| 可靠传输 | 不提供保证 | 提供 |
| 数据传输方式 | 数据报 | 字节流 |
| 是否保证顺序 | 不保证 | 保证 |
| 自动重传 | 没有 | 有 |
| 流量控制 | 没有 | 有 |
| 拥塞控制 | UDP 本身没有 | 有 |
| 首部大小 | 固定 8 字节 | 最少 20 字节 |
UDP 协议本身功能较少,但应用程序可以自行实现确认、重传和拥塞控制.例如 HTTP/3 使用的QUIC协议就建立在UDP之上,并提供可靠传输等功能.
3.1UDP协议端格式

3.2UDP的特点
UDP(User Datagram Protocol,用户数据报协议)是传输层协议.
UDP 最核心的特点:无连接、不可靠交付、面向数据报、首部开销小.
1.UDP的六大特点
1.无连接
UDP 在发送数据前,不需要建立连接,可以直接发送数据报.
- TCP:先进行三次握手,再传输数据.
- UDP:不需要三次握手,直接发送数据.
例如,客户端向DNS服务器发送查询请求,不需要先建立UDP连接.
2.不可靠交付
UDP 采用尽最大努力交付(Best-Effort),不保证数据一定能够到达接收方.
UDP 本身不提供:
- 确认应答机制
- 超时重传机制
- 按序交付机制
- 流量控制机制
例如,发送方连续发送三个数据报:

3.面向数据报
UDP 保留应用层消息的边界.
假设应用程序连续发送两次数据:
- 第一次:
Hello - 第二次:
World
UDP 将它们分别封装成两个独立的数据报,不会像TCP一样把它们当作连续的字节流.
注意:数据报可能丢失、乱序;如果接收缓冲区太小,数据还可能被截断.
4.首部开销小
UDP 首部固定只有 8 字节,由四个字段组成.
| UDP 首部字段 | 大小 |
|---|---|
| 源端口号 | 16 位 |
| 目的端口号 | 16 位 |
| UDP 长度 | 16 位 |
| UDP 校验和 | 16 位 |
| 总计 | 64 位 = 8 字节 |
相比之下,TCP首部最少需要20字节.
5.支持一对一、一对多、多对一和多对多通信
UDP 支持单播、广播(IPv4)和多播通信,因此可以向一个或多个接收方发送数据报.
例如,局域网内的设备发现服务可以利用UDP广播或多播.
6.没有内置拥塞控制
UDP 本身不根据网络拥塞情况自动调整发送速率.
因此,应用程序需要根据实际需求控制发送速度,否则大量UDP流量可能造成网络拥塞.
需要注意:UDP不保证低延迟,只是省去了TCP建立连接等协议机制.实际延迟还受到网络拥塞、丢包和应用设计的影响.
2.UDP 和 TCP 对比
| 特性 | UDP | TCP |
|---|---|---|
| 连接方式 | 无连接 | 面向连接 |
| 可靠性 | 不保证可靠交付 | 可靠传输 |
| 数据单位 | 数据报 | 字节流 |
| 数据边界 | 保留 | 不保留 |
| 顺序保证 | 不保证 | 保证 |
| 自动重传 | 不提供 | 提供 |
| 流量控制 | 不提供 | 提供 |
| 拥塞控制 | 不提供 | 提供 |
| 首部大小 | 8 字节 | 最少 20 字节 |
| 广播和多播 | 支持 | 不支持 |
3.UDP的应用场景
UDP 常见于以下场景:
- DNS 域名解析:常使用 UDP 53.
- 实时音视频:例如基于 RTP/UDP 的语音、视频通信.
- 网络游戏:用于快速传递游戏状态.
- DHCP:通过 UDP 67、68 端口分配网络配置.
- QUIC / HTTP/3:基于 UDP 实现自己的可靠传输、拥塞控制等机制.
3.3UDP的缓冲区
UDP 有接收缓冲区,但没有像TCP那样用于可靠传输的发送缓冲区.
需要注意:这不代表操作系统完全不给UDP发送数据分配缓冲空间,而是UDP不会为了等待确认、超时重传而长期保存已发送的数据.
1.UDP的接收缓冲区
当网络中的UDP数据报到达主机时,操作系统会将数据报放入对应 Socket 的接收缓冲区,等待应用程序读取.

接收缓冲区的作用,就是解决网络到达速度与应用读取速度不一致的问题.
例如,网络每秒收到100个UDP数据报,但应用程序暂时只处理60个,剩余的数据报就需要在缓冲区内等待.
2.接收缓冲区满了怎么办?
如果UDP接收缓冲区已经满了,新到达的数据报通常会直接被丢弃.

为什么 UDP 不让发送方稍等一下?
因为UDP本身没有TCP那样的流量控制机制,接收方不会通过TCP接收窗口通知发送方暂停发送.
这也是UDP不可靠交付的一种体现.
3.UDP的发送缓冲区
这里是一个容易产生误解的地方.
| 项目 | UDP | TCP |
|---|---|---|
| 接收缓冲区 | 有 | 有 |
| 发送时的内核缓冲空间 | 有,依赖操作系统实现 | 有 |
| 保留已发送数据等待确认 | 不需要 | 需要 |
| 超时自动重传 | 不支持 | 支持 |
| 发送端依据接收窗口控制速率 | 不支持 | 支持 |
UDP 调用 sendto() 时,数据一般会交给内核,由内核构造UDP数据报并向IP层提交.
应用程序即使发送成功,也不代表接收方已经收到数据.
此外,Socket 的 SO_SNDBUF 和 SO_RCVBUF 可以用于配置相关缓冲区,但实际效果与具体操作系统有关.
4.UDP缓冲区与数据报边界
假设发送方连续发送:
- 第一个数据报:
Hello(5 字节) - 第二个数据报:
World(5 字节)
如果两个数据报都成功到达,那么接收端调用两次普通的 recvfrom(),通常分别读取 Hello 和 World.
UDP不会将它们合并成一个10字节的数据报.
还有一个重要细节:如果接收缓冲区里有一个100字节的数据报,而应用程序只提供了50字节的接收空间,那么通常只能读取前50字节,剩余部分会被截断丢弃,而不是留给下一次 recvfrom().
3.4UDP使⽤注意事项
使用UDP(User Datagram Protocol)时,最重要的是理解:
UDP只负责尽力发送数据报,不保证数据可靠、有序地到达,也不自动处理丢包、重传和流量控制.
因此,使用UDP时主要有以下7个注意事项.
1.UDP的7个使用注意事项
| 注意事项 | 具体说明 |
|---|---|
| 1. 注意数据丢失 | UDP 不保证数据到达,重要数据需要应用层实现确认和重传 |
| 2. 注意数据乱序 | 先发送的不一定先到达,可通过应用层序号处理 |
| 3. 注意数据重复 | 网络或应用层重传可能造成重复报文,需要根据业务去重 |
| 4. 注意数据报大小 | UDP 数据报过大,可能引发 IP 分片,增加丢包风险 |
| 5. 注意接收缓冲区 | 接收缓冲区满时,新到达的数据报可能被丢弃 |
| 6. 注意数据报边界 | UDP 面向数据报,一次普通接收操作读取一个数据报,不会自动拼接 |
| 7. 注意发送速率 | UDP 没有内置流量控制和拥塞控制,应用程序需要合理控制发送速率 |
2.重点理解三个容易出错的问题
1.UDP 发送成功,不代表对方接收成功
假设客户端 A 向服务器 B 发送数据:

即使 sendto() 返回成功,也只是说明本地发送操作已被接受或完成了相应处理,不代表数据已经送达服务器.
如果业务要求可靠传输,就需要应用层设计确认、超时重传等机制,或者直接选择TCP.
2.UDP数据报不能无限大
UDP长度字段为16位.对于普通IPv4 UDP数据报,在IPv4首部没有选项时,其理论最大数据部分为:
65535 − 20 − 8 = 65507 字节 65535 - 20 - 8 = 65507 \text{ 字节} 65535−20−8=65507 字节
但这不代表实际网络中适合发送这么大的 UDP 数据报.
例如,以太网MTU为1500字节,在普通IPv4首部为20字节的情况下:
1500 − 20 − 8 = 1472 字节 1500 - 20 - 8 = 1472 \text{ 字节} 1500−20−8=1472 字节
因此,该链路上UDP数据部分不超过1472字节时,通常可以避免IP分片.实际端到端路径的 MTU 还可能更小.
建议:尽量发送较小的数据报,避免依赖IP分片.对跨互联网的应用,可以将约1200字节作为保守起点,并结合路径MTU和实际网络环境调整.
3.UDP 接收缓冲区太小,会发生什么?
假设发送方发送了一个1000字节的UDP数据报,但接收应用提供的接收空间只有500字节.

普通 UDP 接收调用不会把未读取的剩余部分保留到下一次读取.
这里需要区分两个概念:
- Socket 接收缓冲区:内核保存等待应用读取的数据报,满了可能丢包.
- 应用接收缓冲区:调用
recvfrom()时提供的内存空间,太小可能造成数据报截断.
3.其他容易忽略的问题
UDP 本身不提供加密、身份认证或防重放保护.如果涉及账号、支付等敏感业务,需要额外的安全协议或应用层保护.
此外,UDP不需要建立传输层连接,但某些操作系统允许对UDP Socket调用 connect(),用于设置默认通信对端和过滤接收来源.这不会把UDP变成TCP式的可靠连接.
3.5基于UDP的应⽤层协议
UDP是传输层协议,许多应用层协议都通过UDP来传输数据.常见的有 DNS、DHCP、TFTP、SNMP、NTP 等.
这些协议选择UDP,通常是因为它具有无连接、首部开销小、支持广播和多播、保留数据报边界等特点.
1.常见的基于UDP的应用层协议
| 应用层协议 | UDP 端口号 | 主要功能 |
|---|---|---|
| DNS | 53 | 域名解析,将域名转换为 IP 地址 |
| DHCP | 67、68 | 动态分配 IP 地址等网络参数 |
| TFTP | 69 | 简单文件传输 |
| SNMP | 161、162 | 网络设备管理与监控 |
| NTP | 123 | 网络时间同步 |
| RIP | 520 | 路由信息交换 |
| mDNS | 5353 | 局域网内的域名解析与服务发现 |
| HTTP/3 | 通常 443 | 通过 QUIC 实现 Web 通信 |
注意:DNS也使用TCP;HTTP/3并不是直接在UDP上实现可靠传输,而是通过建立在UDP之上的QUIC协议进行通信.
2.形象理解:应用层协议如何使用UDP?

3.典型协议的工作原理
1.DNS:域名解析(UDP 53)
当我们访问 www.example.com 时,DNS可以将域名解析为对应的IP地址.

DNS常使用UDP,是因为普通查询报文较小、请求与响应过程简单.不过DNS在区域传送、大型响应等情况下也会使用TCP.
2.DHCP:动态分配 IP 地址(UDP 67、68)
电脑刚接入局域网时,可能还没有可用的 IP 地址。
DHCP 可以通过 UDP 广播完成最初的网络配置交互.
DHCP 获取地址的四个阶段(DORA)
- Discover:客户端寻找 DHCP 服务器
- Offer:服务器提供可用 IP 地址
- Request:客户端请求使用某个地址
- ACK:服务器确认分配结果
服务器通常使用 UDP 67,客户端使用UDP68.
3.TFTP:简单文件传输(UDP 69)
TFTP(Trivial File Transfer Protocol)用于简单的文件传输,例如部分设备的网络启动和固件传输.
TFTP虽然基于不可靠的UDP,但它在应用层实现了数据块编号、确认和超时重传机制.
这说明:UDP 本身不可靠,不代表基于UDP的应用层协议不能实现可靠传输.
4.NTP:网络时间同步(UDP 123)
NTP(Network Time Protocol)用于设备之间的时间同步.
例如,计算机可以向时间服务器发送 UDP 请求,再根据返回的时间戳等信息估计时钟偏差并调整本机时间.
4.为什么这些协议选择 UDP?
| UDP 特点 | 适合的应用场景 |
|---|---|
| 无连接 | DNS、NTP 等简单请求与响应 |
| 支持广播 | DHCP 等局域网服务发现 |
| 支持多播 | mDNS、部分设备发现协议 |
| 数据报边界清晰 | TFTP 等按独立消息进行交互的协议 |
| 协议开销小 | 实时音视频、实时状态更新 |
但UDP也有不足,例如不保证可靠交付、不保证顺序、不提供内置拥塞控制.因此,应用层可能需要自行增加相关机制.

🚀真正的勇者不是流泪的人,而是含泪奔跑的人!
敬请期待下一篇文章内容
每日心灵鸡汤: 真正的反内耗专注自己,别让别人消耗你!
牛人都有反内耗体质:什么是反内耗?就是专注做自己的事情,不操心其他人的事情,甚至要果断拒绝别人,不要让闲人占用自己的时间和精力,不要尝试改变任何人,想改变别人的都是神经病,和这个世界过不去,就是和自己过不去.世界是包容的,任何人、任何三观,都有存在的理由.不要让任何人站在高处,对你评头论足,也不要随意去评判任何人.一个人的时间精力都是非常有限的,有人喜欢吃和玩,有人喜欢专注自身、提升自己,这都是可以的.一切都是自作自受,选择了什么,就要承担什么.一定要正确去认识自己,做到清醒果断,拒绝放纵的诱惑,多花时间去提升自己!
