文章目录
前言
UDP 是 用户数据报协议 的简称，是互联网协议套件中与 TCP 齐名的核心传输层协议 。它提供了一种不可靠的、无连接的通信方式。
一、传输层
1.传输层的目标与问题
传输层的根本目标是：为运行在不同主机上的应用进程之间提供端到端的、逻辑的通信服务。
- 应用进程通信：网络层（如IP协议）只负责将数据从一台主机送到另一台主机。而传输层则进一步将数据交付给主机上运行的特定应用程序（如浏览器、微信、游戏客户端）。
- 端到端：传输层的功能在通信路径的两端（源主机和目的主机）实现，中间的路由器、交换机等网络设备只处理到网络层。
- 逻辑通信：从应用程序的角度看，它们仿佛直接通过传输层建立的通道在对话，无需关心底层复杂的网络拓扑、数据链路和物理介质。
2.传输层的两大核心功能
多路复用与多路分解：
- 多路复用：在发送方，传输层从多个不同的应用进程（Socket）收集数据块，并为每个数据块封装上首部信息（主要是端口号），组合成传输层报文段，然后交给网络层发送出去。
- 多路分解：在接收方，传输层从网络层接收到的报文段，根据其首部中的目的端口号，将数据正确地交付给等待数据的相应应用进程。
提供不同类型的传输服务：
主要通过不同的传输层协议来实现
- 可靠数据传输：确保数据无差错、不丢失、不重复、按序到达。通过确认、重传、序号、校验和等机制实现。
- 吞吐量控制：匹配发送方的发送速率与接收方的处理能力，避免接收方缓冲区溢出。
二、端口号
1.端口号作用
在一台主机内部，唯一 标识一个正在等待或进行网络通信的应用程序（进程） 。它本质上是一个 16 位的逻辑地址 ，取值范围是 0 到 65535 。
在TCP/IP协议中, 用 "源IP", "源端口号", "目的IP", "目的端口号", "协议号" 这样⼀个五元组来标识⼀个通信（在linux中可以通过netstat -n查看）。
2.端口号范围划分
3.端口的重要特征
一个进程可以被多个端口号绑定，但一个端口号只能绑定一个进程。这也很好理解，因为我们是通过端口号来找到一个特定的、唯一的进程。若一个端口号bind多个进程，那么我们就会找不到特定的进程，无法实现通信。
- 协议绑定 ：端口号是与传输层协议绑定的。
TCP 80 端口和 UDP 80 端口是两个完全不同的、独立的通道。 - 唯一性：在同一时刻、同一传输层协议下，一个端口号在一台主机上只能被一个进程监听。否则会发生"端口冲突"。
- 服务端：需要bind监听在一个众所周知的端口上（如 Web 服务器的 80 端口），以便客户端能找到它。
- 客户端：不需要固定端口。发起连接时，系统自动分配一个临时端口。一个客户端可以同时用多个临时端口与不同的服务器通信。
三、UDP协议
1.核心特点
无连接：
- 通信前不需要像 TCP 那样经过"三次握手"建立连接。
- 发送方直接构造数据包并发送出去，不关心接收方是否存在、是否准备就绪。
- 优点：开销小，延迟极低。
不可靠传输：
- 不保证交付：数据包可能在中途丢失，UDP 不会重传。
- 不保证顺序：即使发送顺序是 A、B、C，接收顺序也可能是 C、A、B 或丢失一部分。
- 无拥塞控制：无论网络状况多拥堵，UDP 都会以恒定的速率发送数据。这可能会加剧网络拥堵，但对于某些应用（比如微信视频通话）是必要的。
面向数据报：
- 发送端 UDP 一次交付一个完整的数据报（报文），应用程序交付多长的数据，UDP 就发送多长的数据，不合并也不拆分。
- 接收端的 UDP 一次只接收一个完整的数据报。
头部开销小：
- UDP 头部固定只有 8 字节，远小于 TCP 的 20 字节（不含选项）。这使得传输效率更高。
UDP也支持全双工：
- 每个UDP socket 都有一个接收缓冲区 和一个发送缓冲区。
- UDP的发送缓冲区并不像TCP那样具有复杂的拥塞控制和重传机制，它只是将应用层的数据加上UDP头部后交给网络层。
- UDP的接收缓冲区用于存放到达该socket的数据，等待应用层读取。如果缓冲区已满，则新到达的数据报会被丢弃。因此，如果应用程序读取数据的速度跟不上数据到达的速度，就会发生丢包。
2.UDP协议格式
- 源端口号：发送方应用程序的端口号
- 目的端口号：接收方应用程序的端口号。这是 UDP 实现多路复用的关键，通过端口号将数据交给正确的应用进程。
- 16位UDP长度：表示整个数据报的长度(UDP 首部 + UDP 数据) 的最大长度（单位：字节），最小值为 8（只有头部）。
- 检验和：用于检测 UDP 数据报在传输中是否出错。在 UDP 中是可选的，如果发送方不计算，则填 0。如果接收方检查出错，数据包会被静默丢弃（不通知发送方）。
3.UDP的应用场景
- 实时音视频流媒体：视频会议、在线直播、网络电话：丢失少量数据包只会导致短暂花屏或杂音，但重传旧的 TCP 数据会带来无法接受的延迟。用户更愿意接受轻微卡顿，而不是持续的"音画不同步"。
- DNS 查询：域名解析请求通常很小，且要求响应快。一个 UDP 数据包就能完成一次查询/应答。如果超时未响应，只需重发一次查询即可，用 TCP 反而大材小用。
- 实时在线游戏：玩家的位置、动作状态需要以极低的延迟同步。使用 UDP，即使偶尔丢包导致角色"瞬移"一下，也比使用 TCP 因重传和拥塞控制导致的"操作粘滞"体验更好。
- 等等...