TCP 与 UDP 的全面解析：从基础概念到实际应用 - 详解

前言(认识TCP/UDP报文格式)

在这里插入图片描述

字段名称位数说明
源端口（Source Port）16 位发送方端口号
目的端口（Destination Port）16 位接收方端口号
UDP 长度（Length）16 位UDP 头 + 数据总长度
校验和（Checksum）16 位检测错误
数据（Data）可变实际传输内容

在这里插入图片描述

字段名称位数说明
源端口（Source Port）16 位发送方端口号
目的端口（Destination Port）16 位接收方端口号
序列号（Sequence Number）32 位用于分片排序、可靠传输
确认号（Acknowledgment Number）32 位用于确认收到的数据
首部长度（Header Length）4 位TCP 头部长度
保留字段（Reserved）6 位保留未用
标志位（Flags）6 位URG、ACK、PSH、RST、SYN、FIN
窗口大小（Window Size）16 位流量控制
校验和（Checksum）16 位错误检测
紧急指针（Urgent Pointer）16 位URG 数据偏移
选项（Options）可变可选字段，如 MSS、窗口扩大等
数据（Data）可变实际传输内容

1.TCP/IP基础概念

1.1TCP是什么?

TCP（Transmission Control Protocol，传输控制协议）是一种 面向连接、可靠、有序 的传输协议。

✅ 核心特点：
面向连接：通信前必须先“握手”建立连接（三次握手），结束后要“挥手”断开（四次挥手）。
可靠传输：确保数据不丢失、不重复、按顺序到达。如果丢包，会自动重传。
流量控制 & 拥塞控制：防止发送太快导致接收方或网络崩溃。
字节流服务：应用层发的数据被看作连续的字节流，没有消息边界。
举个例子：
当你用浏览器打开一个网页（比如百度），背后就是通过 TCP 下载网页内容——必须保证每一张图片、每一行文字都完整无误地传到你电脑上。

常见用途：
网页浏览（HTTP/HTTPS）
电子邮件（SMTP、IMAP）
文件传输（FTP）
数据库连接
✅ 适合对“准确性”要求高的场景。

1.2TCP的报文格式及说明

1.3UDP 是什么？

UDP（User Datagram Protocol，用户数据报协议）是一种 无连接、不可靠、高效 的传输协议。

✅ 核心特点：
无连接：不需要建立连接，直接发送数据。
不可靠：不保证数据一定到达，也不重传、不排序。
低延迟、高效率：头部只有 8 字节，处理快，适合实时通信。
保留消息边界：每次发送就是一个独立的数据包（“数据报”）。
举个例子：
你在玩《王者荣耀》时，你的操作（比如移动、释放技能）通过 UDP 发送给服务器。即使偶尔丢掉一个操作包，游戏也能继续，但若用 TCP 等待重传，就会明显卡顿。

常见用途：
视频会议（Zoom、腾讯会议）
在线游戏
直播（如抖音直播、B站直播）
DNS 域名查询
物联网（IoT）设备通信
✅ 适合对“速度”和“实时性”要求高、能容忍少量丢包的场景。

1.4UDP的报文格式及说明

2.TCP和UDP的核心区别

对比项TCPUDP
连接方式面向连接（建立连接后传输）无连接（直接发包）
可靠性可靠传输：确认应答、重传机制不可靠传输：不保证送达
顺序性保证数据包按顺序到达不保证顺序
传输速度相对较慢（处理机制多）非常快（协议更轻量）
传输模式字节流（Stream）数据报（Datagram）
头部开销较大（至少 20 字节）很小（8 字节）
流量控制支持（滑动窗口）不支持
拥塞控制支持（慢启动、拥塞避免等）不支持
错误检测有校验+重传仅校验，无重传
适用场景文件传输、HTTP、邮件、SSH 等可靠性高的应用视频直播、语音通话、DNS、实时游戏等实时性要求高的应用
是否有握手/挥手有：三次握手、四次挥手无：直接发送
数据边界无边界（连续字节流）有边界（按数据包发送）

3. TCP 的关键机制（重点）

3.1三次握手（Three-Way Handshake）

握手过程
TCP 是面向连接的协议，通信前必须建立连接。三次握手确保双方都能正常收发数据。

步骤发送方 → 接收方标志位说明
1客户端 → 服务端SYN=1, seq=x客户端发起连接请求，随机初始序号 x
2服务端 → 客户端SYN=1, ACK=1, seq=y, ack=x+1服务端确认客户端请求，并发送自己的初始序号 y
3客户端 → 服务端ACK=1, seq=x+1, ack=y+1客户端确认服务端的 SYN，连接建立完成

✅ 此后双方进入 ESTABLISHED 状态，可正常传输数据。

❓ 为什么需要“三次”？两次行不行？
核心原因：防止历史重复连接请求造成资源浪费或错误连接。
假设只有两次握手：

  • 客户端发送 SYN，但因网络延迟很久才到达服务端；
  • 此时客户端早已超时重发或放弃；
  • 服务端收到“过期”的 SYN，误以为是新连接，直接分配资源并回复 ACK；
  • 但客户端不会响应（因为它没发起新连接），导致服务端白白占用资源。

三次握手解决了这个问题：

  • 第三次 ACK 由客户端发出，表明它确实想建立连接；
  • 如果是旧 SYN，客户端不会发第三次 ACK，服务端就不会真正建立连接。

✅ 三次握手能双向确认双方的发送和接收能力都正常，且避免历史连接干扰。

3.2四次挥手（Four-Way Wavehand / Connection Termination）

TCP 连接是全双工的（双方可同时收发），所以关闭需要各自独立关闭方向。

挥手过程

步骤发送方 → 接收方标志位说明
1主动关闭方 → 被动方FIN=1, seq=u主动方（如客户端）数据发送完，请求关闭
2被动方 → 主动方ACK=1, seq=v, ack=u+1被动方确认 FIN，但可能还有数据要发
3被动方 → 主动方FIN=1, seq=w, ack=u+1被动方数据也发完，请求关闭
4主动方 → 被动方ACK=1, seq=u+1, ack=w+1主动方确认，连接完全关闭

注意：步骤 2 和 3 不能合并（除非被动方恰好没有数据要发），所以通常是四次。

⏳ 为什么有 TIME_WAIT 状态？
主动关闭方在发送最后一个 ACK 后，会进入 TIME_WAIT 状态，持续 2×MSL（Maximum Segment Lifetime，通常 30~120 秒）。

目的有两个：

  • 确保最后一个 ACK 能到达对方
  • 如果 ACK 丢失，被动方会重发 FIN；
  • TIME_WAIT 期间可再次响应 ACK，避免对方无法关闭。
  • 防止旧连接的数据包干扰新连接
  • 网络中可能还有旧连接的“残余数据包”；
  • 等待 2×MSL（足够让所有旧包过期），再允许相同四元组（IP+端口）建立新连接。

⚠️ 大量短连接可能导致服务器 TIME_WAIT 过多，占用端口资源（可通过 SO_REUSEADDR 优化）。

3.3滑动窗口（Sliding Window）—— 实现流量控制

目标：防止发送方发得太快，导致接收方缓冲区溢出。
工作原理：

  • 接收方在每个 ACK 报文中携带 窗口大小（Window Size） 字段，告诉发送方“我还能接收多少字节”。
  • 发送方根据这个窗口动态调整可发送的数据量。
  • 窗口“滑动”：随着数据被确认，窗口向前移动，释放新空间。

示例：

  • 接收方缓冲区 4KB，已用 1KB → 告诉发送方窗口 = 3KB；
  • 发送方最多发 3KB 数据，直到收到新的 ACK 更新窗口。

✅ 滑动窗口实现了端到端的流量控制（Flow Control），保护接收方不被压垮。

3.4拥塞控制（Congestion Control）

目标：防止网络过载（不只是接收方，而是整个路径上的路由器/链路）。

TCP 使用 四个核心算法：

1. 慢启动（Slow Start）

  • 初始拥塞窗口（cwnd）很小（如 1 MSS）；
  • 每收到一个 ACK，cwnd += 1 MSS → 指数增长（1→2→4→8…）；
  • 直到达到 慢启动阈值（ssthresh），转为拥塞避免。

快速探测网络容量，但避免一开始就发太多。
2. 拥塞避免（Congestion Avoidance）

  • cwnd 线性增长：每 RTT 增加 1 MSS（即每个 ACK 增加 1/cwnd）；
  • 更温和地探测网络上限。
    3. 快速重传（Fast Retransmit）
  • 当发送方收到 3 个重复 ACK（表示某个包丢失，后续包已到）；
  • 不等超时，立即重传丢失的包；
  • 避免长时间等待 RTO（Retransmission Timeout）。
    4.快速恢复（Fast Recovery）
  • 在快速重传后进入；
  • 将 ssthresh 设为当前 cwnd 的一半；
  • cwnd = ssthresh + 3（补偿已收到的重复 ACK 数量）；
  • 继续按拥塞避免方式增长，不回到慢启动。

整体策略：

慢启动 → 拥塞避免 →（丢包）→ 快速重传 + 快速恢复 → 拥塞避免

3.5超时重传（Retransmission Timeout, RTO）

触发条件：

  • 发送数据后，在 RTO 时间内未收到 ACK；
  • 则认为包丢失，重传该数据段。

⏱️ RTO 如何计算？

  • 基于 RTT（Round-Trip Time） 动态估算；

  • 使用 Jacobson 算法（考虑 RTT 变化和抖动）；

公式简化版：

RTO = SRTT + 4 × RTTVAR

其中 SRTT 是平滑 RTT，RTTVAR 是 RTT 方差。
⚠️ 超时重传 vs 快速重传：

机制触发条件速度效率
超时重传RTO 超时慢（秒级）低（网络空闲）
快速重传收到 3 个重复 ACK快（毫秒级）高

✅ 现代 TCP 优先使用快速重传，超时重传是最后兜底。

3.6 TCP 连接建立（三次握手）与关闭（四次挥手）状态变化表和说明表

✅ TCP 连接建立（三次握手）与关闭（四次挥手）状态变化表

阶段步骤客户端（主动方）状态含义服务端（被动方）状态含义
连接建立初始CLOSED无连接CLOSED无连接
（三次握手）1. 客户端发 SYNSYN_SENT已发送 SYN，等待服务端确认LISTEN监听连接请求
2. 服务端回 SYN+ACKSYN_SENT等待服务端 ACKSYN_RECEIVED已收到 SYN 并回 ACK，等待客户端最终确认
3. 客户端发 ACKESTABLISHED连接已建立，可收发数据ESTABLISHED连接已建立，可收发数据
数据传输—ESTABLISHED正常通信中ESTABLISHED正常通信中
连接关闭1. 客户端发 FINFIN_WAIT_1已发送 FIN，等待 ACKESTABLISHED → CLOSE_WAIT收到 FIN，进入半关闭状态（仍可发数据）
（四次挥手）2. 服务端回 ACKFIN_WAIT_2已收到 ACK，等待服务端 FINCLOSE_WAIT应用层需调用 close() 才能发 FIN
3. 服务端发 FINFIN_WAIT_2等待服务端 FINLAST_ACK已发送 FIN，等待客户端确认 ACK
4. 客户端发 ACKTIME_WAIT等待 2×MSL 后彻底关闭CLOSED连接完全关闭
超时后CLOSED连接彻底释放——

关键状态详解

状态说明
LISTEN服务端等待客户端连接请求（调用 listen() 后）
SYN_SENT客户端已发送 SYN，等待服务端响应
SYN_RECEIVED服务端收到 SYN 并回复 SYN+ACK，等待客户端 ACK（短暂中间态）
ESTABLISHED连接已建立，双方可正常收发数据
FIN_WAIT_1主动关闭方已发送 FIN，等待对方 ACK
FIN_WAIT_2主动关闭方已收到 ACK，等待对方 FIN（此时不能再发送数据，但可接收）
CLOSE_WAIT被动关闭方收到 FIN，通知应用层关闭连接，等待本地应用调用 close()
LAST_ACK被动关闭方已发送 FIN，等待最后 ACK，收到后关闭
TIME_WAIT主动关闭方确保最后一个 ACK 被接收，并防止旧连接影响新连接（等待 2×MSL）
CLOSED无连接或连接已完全释放

补充说明

  • ** 谁先发 FIN，谁就是主动关闭方（通常是客户端，但服务端也可主动关闭）。**
  • ** TIME_WAIT 只出现在主动关闭方。**
  • 如果服务端主动关闭，则角色互换，状态变化对称。
  • 大量 TIME_WAIT 是正常现象，但过多可能耗尽端口（可通过调整内核参数优化）。

3.7 总结图（逻辑流程）

连接建立： 三次握手
↓
数据传输： 滑动窗口（流量控制）
↓
拥塞控制（慢启动 → 拥塞避免）
↘ 丢包？ → 快速重传 + 快速恢复
↘ 超时？ → 超时重传 + 慢启动重启
↓
连接关闭： 四次挥手 + TIME_WAIT

4. UDP 的核心优势

优势说明
头部结构简单仅 8 字节 固定头部（TCP 至少 20 字节），开销极小
无连接无需握手/挥手，直接发送数据，延迟极低
无重传/确认机制不因丢包而阻塞或重传，避免卡顿
保留消息边界每次 send() 对应一个独立数据报，应用层易处理
支持广播/多播可同时向多个主机发送（TCP 仅支持单播）

⚠️ 注意：这些“优势”本质上是牺牲可靠性换来的效率，适用于能容忍少量丢包的场景。

5. 实际应用场景对比

协议类型常见应用场景示例/说明
TCPWeb 通信HTTP / HTTPS（网页加载、API 请求）
远程登录SSH（安全远程管理服务器）
文件传输FTP（可靠传输文件）
邮件服务SMTP / IMAP / POP3（邮件发送与收取）
其他需要可靠性保障的通信数据必须可靠、有序，不丢不重
UDP域名解析DNS（快速查询，无需建立连接）
地址分配DHCP（广播式发现与响应）
实时视频/音频传输RTSP、实时直播（低延迟比可靠性更重要）
游戏通信FPS、MOBA（快速同步位置、状态）
其他实时性要求高的应用即使丢包也要优先保证低延迟

6.如何选择 TCP 或 UDP

需求/场景推荐协议原因说明
需要可靠传输TCP有重传、确认、丢包恢复
需要实时性UDP无握手、无阻塞，延迟极低
需要保证消息顺序TCP内部按序号保证严格的包顺序
要极低延迟UDP不确认、不重传，发送即走
允许少量丢包UDP丢包不阻塞，适用音视频/游戏
不能接受丢包TCP保证可靠、有序
posted @ 2025-12-15 18:29  gccbuaa  阅读(4)  评论(0)    收藏  举报