前言
OSI七层模型：应用层、表示层、会话层、传输层 、网络层、数据链路层、物理层。 TCP、UDP属于传输层协议，负责端到端（应用程序之间）的数据传输。 网络层IP负责主机到主机；传输层TCP/UDP负责端口到端口，区分同一台机器上不同进程。
TCP：面向连接、可靠传输；UDP：无连接、不可靠传输，简单高效。
一、UDP 用户数据报协议
1.1 UDP特点
- 无连接：通信前不需要建立连接。发送方直接打包数据，扔给网络，不管对方是否在线。
- 不可靠：没有确认机制、重传机制。报文丢了不会重发；收到乱序报文也不会处理。
- 面向报文 ：应用层交给UDP多大报文，UDP就原样发送，不会拆分合并。
- 头部开销极小：仅8字节。
- 支持一对一、一对多、多对多通信（广播、组播）。
优点：简单，开销小，延迟低
缺点：不可靠，数据可能丢失、乱序
1.2 适用场景
适合能容忍少量丢包、对实时性要求高的场景：
- 音视频通话、直播（丢几帧画面人感知不强，但是不能卡顿等待重传）
- DNS域名解析（短请求，单次查询，建立TCP握手成本太高）
- DHCP动态分配IP
- 游戏实时对战
业务需要可靠时，可以在应用层自己做确认、重传机制（如QUIC协议）。
二、TCP 传输控制协议
TCP是面向连接的可靠传输协议。通信双方必须先建立连接，传输完成后正常断开连接。
TCP头部最小20字节，带序列号、确认号、窗口大小等字段。
2.1 TCP核心特性
- 面向连接：通信前建立连接，通信结束正常断开。
- 可靠传输：依靠序列号、ACK确认、超时重传保证数据完整送达。
- 面向字节流：把数据当成一串连续字节流，没有报文边界，会产生粘包拆包。
- 流量控制：滑动窗口，接收方告知发送方自己剩余缓冲区大小，防止发送太快淹没接收端。
- 拥塞控制：慢启动、拥塞避免、快重传、快恢复，防止网络过载。
2.2 三次握手（建立连接，必背）
目的：确认双方收发能力都正常；同步双方初始序列号。
-
第一次握手 SYN ：客户端发送SYN报文，携带客户端初始序列号seq=x。客户端进入SYN_SENT状态。 客户端：我想建立连接，我的序列号是x。
-
第二次握手 SYN+ACK ：服务端收到SYN，回复SYN+ACK；SYN表示服务端也要同步序列号seq=y；ACK确认号=x+1。服务端进入SYN_RCVD状态。 服务端：收到你的请求，同意连接，我的序列号y。
-
第三次握手 ACK ：客户端收到SYN+ACK，回复ACK，确认号=y+1。客户端、服务端进入ESTABLISHED连接状态。 客户端：收到你的确认，连接建立，可以传数据。
为什么不是两次握手？ 两次握手只能保证客户端发、服务端收正常；无法确认服务端发送能力、客户端接收能力正常。旧的延迟SYN报文会导致服务端建立无效连接，浪费资源。
2.3 四次挥手（断开连接）
TCP连接是全双工，双方都可以独立发送数据，关闭需要双向分别关闭。
- 第一次挥手 FIN ：客户端发送FIN，seq=u。客户端进入FIN_WAIT_1，表示客户端不再发送数据。 客户端：我这边数据发完了，请求关闭。
- 第二次挥手 ACK ：服务端回复ACK，ack=u+1。服务端进入CLOSE_WAIT；客户端进入FIN_WAIT_2。 服务端：收到关闭请求。此时服务端还可以继续向客户端发剩余数据。
- 第三次挥手 FIN ：服务端数据发送完毕，发送FIN，seq=v。服务端进入LAST_ACK。 服务端：我这边数据也发完了，可以关闭。
- 第四次挥手 ACK：客户端回复ACK，ack=v+1；客户端进入TIME_WAIT，等待2MSL；服务端收到ACK直接CLOSED。等2MSL超时后客户端关闭。
为什么四次挥手，不能三次？ TCP全双工，一方发完FIN只代表不再发送数据，但还能接收对方剩余数据。不能一次性同时关闭两个方向。
TIME_WAIT为什么要等待2MSL？
- 保证最后一个ACK报文能到达服务端，如果ACK丢失，服务端重发FIN，客户端可以重新回复ACK；
- 等待网络中残留的本次连接数据包全部消失，避免下一个新连接收到旧报文。
2.4 可靠传输机制
- 序列号seq：字节编号，保证顺序；
- ACK确认应答：接收方收到数据，返回确认号，告诉发送方收到哪一段；
- 超时重传：发送报文后，超时没收到ACK，自动重发；
- 流量控制（滑动窗口）：接收方窗口，控制发送速率，防止接收缓冲区溢出；
- 拥塞控制：控制发送速率，保护整个网络不拥塞。
2.5 TCP粘包与拆包（高频考点）
TCP是字节流，没有消息边界。
- 拆包：单个数据包太大，大于MSS，TCP自动拆分成多个段发送；
- 粘包：多个小数据包，TCP优化合并成一个报文发送（Nagle算法）。
现象：发送2次消息，接收端一次性读到合并后的数据，分不清消息边界。
解决方案（应用层处理）：
- 固定消息长度；
- 特殊分隔符分割（如换行符）；
- 消息头+消息体：头部存储消息长度，读取时先读长度，再读取对应字节数据（最常用）。
三、TCP UDP对比表
| 对比维度 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接（三次握手建立，四次挥手断开） | 无连接，无需握手 |
| 可靠性 | 可靠传输，不丢包、有序 | 不可靠，可能丢包、乱序 |
| 传输形式 | 字节流 | 面向报文 |
| 头部开销 | 最小20字节 | 8字节 |
| 拥塞/流量控制 | 支持 | 不支持 |
| 实时性 | 较差 | 好，延迟低 |
| 适用场景 | 文件传输、HTTP、HTTPS、数据库访问 | 直播、音视频、DNS、游戏 |
四、高频问答
Q1：TCP三次握手过程，为什么两次不行？
A：客户端发SYN；服务端回SYN+ACK；客户端回ACK。两次握手无法验证服务端发送能力，老旧SYN报文会造成无效连接。
Q2：TCP四次挥手，TIME_WAIT作用？A：等待2MSL。一是保证服务端收到ACK；二是等待网络残留数据包消失，避免新连接收到旧数据。
Q3：TCP粘包拆包是什么？怎么解决？A：TCP字节流无消息边界；大包拆成多段、小包合并，导致接收方分不清消息。应用层方案：固定长度、分隔符、消息头携带长度。
Q4：UDP不可靠，为什么还要使用UDP？A：UDP开销小、延迟低。音视频场景少量丢包可接受，优先实时性；可靠性可以在应用层实现。
Q5：流量控制和拥塞控制区别？A：流量控制：点对点，防止发送方把接收方缓冲区打满；拥塞控制：全局网络，防止网络拥堵。
结语
TCP核心关键词：面向连接、可靠、字节流、三次握手四次挥手、滑动窗口、粘包拆包；UDP关键词：无连接、不可靠、面向报文、低延迟。 重点区分两者适用场景，理解三次握手四次挥手的设计目的，不要死记流程，要理解背后为什么这么设计。开发网络程序时，TCP要额外处理粘包问题。