【网络】TCP/UDP协议
目录
一.TCP
1.1 报文格式
1.2 确认应答
1.3 超时重传
超时重传的优化机制
1. 快速重传（Fast Retransmit）
2. 选择性确认（SACK）
3. 伪超时（Spurious Retransmission）处理
1.4 连接管理
三次握手：
主机A和主机B如何建立连接：
TCP 为什么是三次握手，而不是两次或四次？
四次挥手：
客户端和服务器断开连接：
四次挥手中对应的状态转化：
1. 客户端的状态转换
2. 服务器的状态转换
挥手一定要四次吗？
1.5 滑动窗口
滑动窗口的核心作用
1.6 拥塞控制
为什么需要有拥塞控制？
TCP 拥塞控制的核心逻辑
1.7 粘包问题
二.UDP
1.1 报文格式
1.2 无连接
1.3 不可靠
1.4 面向数据报
1.5 低开销
TCP和UDP应用场景：
一.TCP
TCP（Transmission Control Protocol，传输控制协议）是互联网核心协议之一，位于传输层，提供可靠的、面向连接的、基于字节流的数据传输服务。
TCP的主要作用是确保数据从发送端到接收端的完整、准确无误的传输。
下面从多个维度详细解析TCP协议：
1.1 报文格式
源端口&目的端口（4个字节）：标识发送方和接收方的端口
例如：HTTP 80端口 HTTPS 443端口
序号（4个字节）：标识发送的数据字节流的顺序号
确认序号（4个字节）：标识期望收到的下一个序号，实现可靠传输
数据偏移（4个比特位）：表示 TCP 首部的长度
保留位（6个比特位）：保留给未来扩展使用，目前必须全部置为 0
标志位（6个比特位）：
| 标志位 | 名称 | 作用 |
|---|---|---|
| URG | 紧急 | 为1时表示紧急指针有效（需优先处理）。 |
| ACK | 确认 | 为1时表示确认号有效（建立连接后所有报文ACK必须为1）。 |
| PSH | 推送 | 为1时要求接收方立即将数据提交给应用层（避免缓冲延迟）。 |
| RST | 重置 | 为1时强制断开连接，用于异常恢复。 |
| SYN | 同步 | 为1时表示连接请求/同步序列号（用于三次握手）。 |
| FIN | 结束 | 为1时表示发送方数据发送完毕，请求关闭连接（用于四次挥手）。 |
窗口大小（2个字节）：用于接收方告知发送方当前可接受的字节数（实现流量控制）
校验和（2个字节）：校验头部、数据和伪头部（源/目的IP、协议类型等）的完整性。
紧急指针： 描述哪些数据是紧急数据
选项（0-40字节）：提供额外功能，非必需字段
以上就是报文基本信息，接下来介绍的是TCP的核心特点；
1.2 确认应答
TCP的核心特点就是确认应答，这也应征了它的可靠传输这一特性；
当发送方发送消息给接收方之后，接收方会返回给一个ACK(确认应答标志位)，表示已收到数据，期待下一次数据是从xxx开始；
当然TCP发送方发送数据的时候，每块数据都会带上序列号，来证明发送数据的内容；
1.3 超时重传
当发送方在一定时间内未收到接收方的ACK，会进行重传数据，有俩个原因：
1.接收方返回的ACK丢失，导致未收到；
2.发送方发送的数据压根没到接收方；
当接收方收到多份重复的数据，会根据它们的序列号进行丢弃；
超时时间（RTO）怎么确定？
RTO是动态变化的，会根据网络环境的不同。累计到一定的重传次数， TCP 认为网络或者对端主机出现异常，强制关闭连接。
超时重传的优化机制
1. 快速重传（Fast Retransmit）
-
触发条件：收到3个重复ACK（如连续3个
ack=200）。 -
动作：立即重传丢失报文（如
seq=200），无需等待RTO超时。 -
优势：显著降低丢包恢复延迟（尤其在高延迟网络中）。
2. 选择性确认（SACK）
-
作用：通过TCP选项字段明确告知发送方哪些数据块已收到，避免重传已成功的数据。
-
例如：接收方发送
ACK=200, SACK=300-400，表示200-299丢失，但300-399已收到。
3. 伪超时（Spurious Retransmission）处理
-
场景：网络延迟突增导致误判丢包（实际ACK仍在途中）。
-
检测方法：
-
收到原始报文的ACK（非重传报文的ACK）。
-
或通过时间戳选项（Timestamp）发现ACK对应原始报文。
-
1.4 连接管理
正常情况下，发送方和接收方连接前需要进行一次三次握手才能进行连接通信
三次握手：
目的：
1.为了帮助通信双方协同初始化序列号
2.避免历史双方错误的连接，减小通信双方不必要的资源消耗
主机A和主机B如何建立连接：
1.主机A发送给主机B建立连接的请求 SYN ，设置SYN=1，seq=x seq表示序列号，发送的初始序号为x
2.主机B接收到数据 返回 ACK +SYN 报文包括 设置 ACK = 1、SYN = 1 、 ack = x+1 表示期待下次收到序号x+1的数据 和seq = y
3.主机A收到数据 返回 ACK 报文包括 设置ACK = 1 ，seq = x+1,ack = y+1
TCP 为什么是三次握手，而不是两次或四次？
第一次握手：验证服务器的接收能力
第二次握手：验证客户端的发送能力 + 验证服务器的发送能力
第三次握手：验证客户端的接收能力
如果第二次握手：
1.客户端不能自己是否有接收能力，双方状态不至于，可能会导致服务器一直等待客户端请求~2.无法处理过期的请求，导致可能会产生错误连接
因为网络原因会导致服务堵塞，所以客户端可能会第一次发送请求，超时了所以继续发送请求，那么就会导致服务器接收了第二次新请求，而老请求可能晚点也会到达服务器，这样再返回就可能会创建一个无人使用的连接，导致浪费了资源；而三次握手通过第三次
ACK，让服务器最终确认「客户端能收」，同时通过序号机制过滤过期请求，实现了双向的完整确认
三次握手够了，没必要浪费多个资源~
四次挥手：
目的：用于安全关闭一个已连接的状态，确保双方通信能够完成数据传输并安全地释放连接管理~
客户端和服务器断开连接：
- 客户端 → 服务器（FIN）：客户端告诉服务器 “我不再发数据了”（关闭客户端→服务器的发送通道）。
- 服务器 → 客户端（ACK）：服务器回复 “收到你的关闭请求”（确认客户端→服务器通道关闭）。
- 服务器 → 客户端（FIN）：服务器处理完剩余数据后，告诉客户端 “我也不再发数据了”（关闭服务器→客户端的发送通道）。
- 客户端 → 服务器（ACK）：客户端回复 “收到你的关闭请求”（确认服务器→客户端通道关闭）。
四次挥手中对应的状态转化：
1. 客户端的状态转换
- ESTABLISHED：连接正常通信状态。
- FIN_WAIT_1：客户端发送 FIN 后，等待服务器的 ACK（对应第一步）。
- 作用：等待服务器确认 “客户端→服务器” 通道关闭。
- FIN_WAIT_2：客户端收到服务器的 ACK 后进入此状态，等待服务器的 FIN（对应第二步后）。
- 作用：此时客户端→服务器通道已关闭，但服务器→客户端通道仍可能有数据发送，客户端需等待服务器的关闭请求。
- TIME_WAIT：客户端发送最后一个 ACK 后进入此状态（对应第四步后），等待 2 倍 MSL（报文最大生存时间）。
- 作用：① 确保服务器能收到最后一个 ACK（若服务器没收到 FIN 的 ACK，会重发 FIN，客户端可在此时重传）；② 避免过期报文干扰新连接（等待网络中残留的旧报文失效）。
- CLOSED：TIME_WAIT 超时后，客户端彻底关闭连接。
2. 服务器的状态转换
- ESTABLISHED：连接正常通信状态。
- CLOSE_WAIT：服务器收到客户端的 FIN 后，发送 ACK 并进入此状态（对应第二步）。
- 作用：此时服务器需要通知应用层 “客户端已关闭发送”，并处理剩余数据（若有），准备关闭自己的发送通道。
- LAST_ACK：服务器发送 FIN 后，等待客户端的 ACK（对应第三步后）。
- 作用：等待客户端确认 “服务器→客户端” 通道关闭。
- CLOSED：服务器收到客户端的 ACK 后，彻底关闭连接（对应第四步后）。
挥手一定要四次吗？
TCP是一个全双工协议，所以双方都需要关闭，每一方都需要发送FIN+ACK,所有就是四次；
但有时候，如果服务器已经没有消息要传输，那么服务器可以直接将FIN+ACK合并成一次发送给客户端~
1.5 滑动窗口
TCP 的滑动窗口（Sliding Window）是实现可靠传输和流量控制的核心机制，它允许发送方在收到接收方确认前，连续发送多个数据段（而非每发一个等一个确认），大幅提升了传输效率。同时，通过接收方动态告知窗口大小，避免发送方发送速率超过接收方的处理能力（防止缓冲区溢出）。
可以把窗口理解为 “允许发送方连续发送的数据范围”，这个范围由 “已发送未确认的数据” 和 “未发送但可发送的数据” 组成。窗口的大小由接收方决定（通过 TCP 报文的Window字段告知），发送方不能发送超过窗口大小的数据。
滑动窗口的核心作用
- 提高传输效率：通过 “流水线发送”（一次发多个数据段）替代 “停止 - 等待”（发一个等一个确认），减少等待时间。
- 流量控制：接收方通过动态调整窗口大小（
Window字段），告诉发送方 “我还能收多少”，避免发送方速率过快导致接收方缓冲区溢出。 - 可靠传输：对未确认的数据（窗口内的
已发送未确认部分）启动超时重传，确保数据不丢失。
1.6 拥塞控制
为什么需要有拥塞控制？
滑动窗口的逻辑是 “接收方能收多少，发送方就发多少”，但忽略了一个关键问题：数据从发送方到接收方，需要经过中间网络（路由器、交换机、光纤 / 电缆等）。这些中间设备（如路由器）也有自己的缓冲区和带宽限制:
- 若发送方仅凭 “接收方窗口” 疯狂发送，可能导致中间路由器的缓冲区被塞满（比如多个发送方同时向同一链路发送数据），进而触发丢包；
- 丢包会导致 TCP 重传，重传又会加剧网络负担，形成 “拥塞→丢包→重传→更拥塞” 的恶性循环，最终网络瘫痪。
拥塞控制的本质是：发送方通过 “探测网络拥塞程度”，动态调整自己的 “拥塞窗口（cwnd）” 大小，控制发送速率。
- 拥塞窗口（cwnd）：发送方自己维护的一个变量，表示 “当前认为网络能承载的最大发送量”（不考虑接收方窗口时的发送上限）。
- 实际发送窗口：发送方最终能发送的字节数 = min (接收方窗口大小，拥塞窗口大小)（取两者较小值，同时满足流量控制和拥塞控制）。
TCP 拥塞控制的核心逻辑
| 维度 | 滑动窗口（流量控制） | 拥塞控制 |
|---|---|---|
| 目标 | 避免接收方缓冲区溢出 | 避免网络中间设备（路由器）拥塞 |
| 控制依据 | 接收方缓冲区剩余空间 | 网络丢包情况（重复 ACK 或超时） |
| 作用范围 | 端到端（发送方→接收方） | 全网链路（中间路由器 + 端到端） |
1.7 粘包问题
TCP 是面向字节流的协议，它将数据视为连续的字节序列，没有 “消息边界” 的概念。发送方和接收方通过缓冲区处理数据，这会导致以下两种典型的 “粘包” 现象：
- 粘包：多个小数据包被合并成一个大数据包发送 / 接收（如发送方
send("A")+send("B")，接收方可能一次recv()得到"AB"）。 - 拆包：一个大数据包被拆分成多个小数据包发送 / 接收（如发送方
send("ABCDE")，接收方可能分两次recv()得到"ABC"和"DE"）。
解决粘包问题，确定各个数据的边际就行，场景的方案：
| 场景 | 推荐方案 | 典型案例 |
|---|---|---|
| 消息长度固定 | 固定长度法 | 某些物联网传感器数据 |
| 消息长度不固定（通用） | 长度前缀法 | 大多数 RPC 框架（如 gRPC） |
| 文本类消息 | 分隔符法 | HTTP、FTP 协议 |
| 复杂多类型消息 | 协议格式法 | 自定义私有协议（如游戏协议） |
二.UDP
1.1 报文格式
UDP 是 TCP/IP 协议栈中与 TCP 并列的传输层协议，核心特性可概括为 “无连接、不可靠、面向数据报、低开销”，与 TCP 的 “有连接、可靠、面向字节流、高开销” 形成鲜明对比。具体特性如下：
1.2 无连接
- 通信前无需像 TCP 那样进行 “三次握手” 建立连接，发送方直接往目标 IP: 端口发送数据报，接收方收到后也无需 “四次挥手” 断开连接。
- 类比：如同邮寄明信片，写好地址直接投递，无需提前通知对方 “我要寄信了”，对方收到也不用回复 “收到了”。
1.3 不可靠
- 不保证送达：数据报发送后，UDP 不确认接收方是否收到，也不重传丢失的包。
- 不保证顺序：若多个数据报经不同路径传输，到达接收方可能乱序，UDP 不处理排序。
- 不保证无重复：数据报可能因网络延迟等原因重复到达，UDP 不去重。
- 无流量控制 / 拥塞控制：发送方不会因接收方忙或网络拥堵而减速，可能导致接收方缓冲区溢出，数据丢失。
1.4 面向数据报
- 数据以 “数据报” 为单位传输（类似 “信件”），每个数据报包含完整的源 / 目标端口、长度、校验和等头部信息，以及应用层数据。
- 发送方调用
sendto一次发送一个数据报，接收方调用recvfrom一次读取一个完整的数据报（若数据报太大，超过接收缓冲区，可能被截断或丢弃）。
1.5 低开销
- 头部仅 8 字节（远小于 TCP 的 20-60 字节），无握手 / 挥手、重传、排序等机制，协议处理效率极高，延迟极低。
没有了这些可靠机制，并不代表不可用，恰恰相反，大多数场景下都是用udp场景为主，因为太快了，可以接受一些场景的丢包
UDP 不是 “TCP 的劣质替代品”，而是为 “延迟敏感、可容忍少量丢包、需要灵活性” 的场景设计的协议。其核心价值在于：
- 极致低延迟：无握手 / 重传等待，适合实时交互；
- 低开销：适合资源受限设备（如传感器）；
- 支持广播 / 多播：适合一对多通信；
- 灵活性：允许应用层按需实现可靠性，避免 TCP 的 “过度可靠” 带来的性能损耗。
TCP和UDP应用场景：
| TCP | 可靠、有序、无丢包 | 文件传输、网页浏览、邮件、数据库、登录认证、金融交易 | 数据不允许出错，延迟可接受 |
| UDP | 低延迟、高吞吐量、轻量 | 实时音视频、在线游戏、DNS、物联网、广播 / 多播、QUIC 协议、自定义可靠传输场景 | 实时性优先，少量丢包可容忍或通过上层弥补 |