传输层服务
端口的作用
- 通过 "端口号" 标识本主机的一个特定进程，每台主机的端口号是相互独立的，并且TCP、UDP 两种协议的端口号是相互独立的
- TCP 或 UDP 协议，通过 Socket 套接字 ={IP 地址：端口号}，唯一地标识网络中的一台主机上的一个应用进程
- 端口号的分类
-
- 服务器使用的端口号
-
-
- 熟知端口号 0~1023------ 通常只能用于被熟知的重要应用程序
- 登记端口号 1024~49151
-
-
- 客户端使用的端口号 ------ 短暂端口号 49152~65535
功能
- 实现端到端（进程到进程）的通信
- 复用和分用
-
- 复用（从上到下）：在发送数据的时候，同一台主机上的多个进程可以使用同一个传输层协议
- 分用（从下到上）：在接收数据的时候，传输层可以把数据正确交付到目的进程
- 差错检测
-
- TCP 检测出差错后丢弃数据，并通知发送方重传
- UDP 检测出错误后直接丢弃数据，且不通知发送方
- 向应用层提供两种服务
-
- 面向连接的、可靠的端到端传输服务（TCP）------ 确保数据正确 / 完整，但开销大、实时性较差
- 无连接的、不可靠的端到端传输服务（UDP）------ 数据可能出错 / 丢失，但速度快、开销小
UDP协议
UDP（User Datagram Protocol，用户数据报协议）是 TCP/IP 协议族中无连接、不可靠 的传输层协议，核心设计目标是 "快速、低开销"，适用于对实时性要求高、可容忍少量数据丢失的场景。
协议结构
包含 8 字节固定首部 + 应用层数据（无选项字段）
| 字段 | 长度（字节） | 核心作用 |
|---|---|---|
| 源端口号 | 2 | 标识发送方的应用进程（如客户端端口，可选：若无需接收响应，可设为 0） |
| 目的端口号 | 2 | 标识接收方的应用进程（必须填写，是数据交付到目标进程的关键） |
| UDP 长度 | 2 | 表示 UDP 首部（8 字节）+ 应用层数据的总长度（最小值为 8，最大值为 65535） |
| 校验和 | 2 | 检测 UDP 数据报（含伪首部）在传输中的错误（错误则丢弃，不通知发送方） |
UDP与TCP对比
- UDP 首部很小，只占 8B
- UDP 每次传输一个完整的报文，不支持报文自动拆分、重装
- UDP 是无连接的、不可靠的（可靠性可以交给应用层处理），也不支持拥塞控制
- 不保证数据的 "交付成功"：发送方发送数据后，不等待接收方的确认（ACK），即使数据丢失也不会重传。
- 不保证数据的 "顺序性"：若多个 UDP 数据报因网络延迟差异到达接收方，可能出现 "后发先至"，接收方不会重组顺序。
- 不保证数据的 "完整性"：仅通过校验和检测错误（错误则丢弃，不通知发送方），无重传、流量控制等纠错机制。
- UDP 支持一对一（封装成单播 IP 数据报）、一对多传输（封装成广播 / 多播 IP 数据报）
- TCP 首部更大，占 20~60B
- TCP 支持报文自动拆分、重装，因此可以传输长报文
- TCP 是有连接的、可靠的、支持拥塞控制
- TCP 仅支持一对一传输（因为通信双方的传输层必须先建立连接）
UDP数据报
UDP检验
将原始的 48bit 数据分成三组 16bit 的数据依次进行二进制加法 （最高位产生的进位需要回卷），然后将得到的中间结果进行取反，所得到的就是校验和。并将校验和和原始数据组合在一起成为新的数据发送。
接收方对传输过来的数据进行验证，同样将数据拆分为 16bit 的数据进行二进制加法，如果加法结果不全是1，那么就说明发生了比特错误。
依此为基础，就可以理解UDP的检验
发送方的传输层
- 传输层的 UDP 协议在计算检验和之前，先添加伪首部
- 把伪首部、首部、数据部分以 16bit 为一组，进行二进制加法（最高位产生的进位需要回卷）
- 将最终的加法结果逐位取反，就得到 16bit 检验和，将其填入 UDP 首部
- 去掉伪首部，并将 UDP 数据报交给网络层，封装成 IP 数据报
接收方的传输层
- 网络层向传输层递交 UDP 数据报
- 传输层在 UDP 数据报之前，添加伪首部
- 把伪首部、UDP 首部、数据部分以 16bit 为一组，进行二进制加法（最高位产生的进位需要回卷）
- 如果加法结果为全 1，说明没有比特错误，于是接收该 UDP 数据报，并根据目的端口号，向应用层递交报文。如果加法结果不是全 1，说明有差错，于是丢弃该 UDP 数据报
应用场景
- 实时音视频传输：如 VoIP（网络电话）、视频会议（Zoom、腾讯会议）、直播（抖音、快手）。这类场景中，少量数据丢失仅导致短暂卡顿 / 模糊，但若延迟过高（如 TCP 重传导致的延迟），会严重影响体验。
- DNS 域名解析：DNS 查询通常仅需传输少量数据（如域名→IP 的映射请求 / 响应），若用 TCP 需先建立连接，反而增加延迟；UDP 能快速完成解析，即使丢失也可由应用层重试。
- 广播 / 多播场景：如局域网内的设备发现（如打印机共享）、实时数据分发（如股票行情推送、物联网传感器数据上报），UDP 支持一对多传输，效率远高于 TCP 的一对一连接。
- 轻量控制协议：如 TFTP（简单文件传输协议，用于设备固件升级）、SNMP（简单网络管理协议，用于监控路由器 / 交换机），这类场景数据量小、对可靠性要求低，UDP 足够满足需求。