入门
基于 HTTP 现代标准 · 核于 2026-06
速查
- 传输层 = 进程到进程通信（IP 只负责主机到主机）；靠 端口（16 位 0-65535）区分应用
- 端口三段：知名 0-1023 / 注册 1024-49151 / 动态 49152-65535；
socket = IP + 端口，TCP 连接由四元组唯一确定 - UDP：无连接、不保证可靠/有序、8 字节首部——低延迟低开销；用于 DNS、实时音视频、游戏、QUIC
- TCP：面向连接、可靠、有序、字节流；用于网页、API、文件传输、邮件
- 三次握手 SYN→SYN+ACK→ACK（同步双向序列号；三次才能确认双向收发能力 + 防历史连接）
- 四次挥手 FIN→ACK→FIN→ACK（全双工，两方向各自关闭）；主动关闭方 TIME_WAIT 等 2MSL
- 可靠传输：序列号（按字节）+ 累积确认 ACK + 超时重传（RTO）+ 快速重传（3 个重复 ACK）+ SACK
- 流量控制（rwnd 滑动窗口，护接收方）vs 拥塞控制（cwnd，护网络）；发送窗口 = min(rwnd, cwnd)
- 拥塞四阶段：慢启动（指数）→ 拥塞避免（线性）→ 快重传 → 快恢复；遵循 AIMD（加性增乘性减）
- 拥塞算法：Reno → CUBIC（Linux 默认）→ BBR（Google，基于带宽时延）
- TCP 队头阻塞：有序交付的代价——一个段丢失阻塞后面已到达的段；HTTP/2 仍受困，QUIC 用 UDP 绕开
TCP 与 UDP 的分工
传输层在「不可靠的 IP」之上提供两种截然不同的服务，前端按需求二选一：
| TCP | UDP | |
|---|---|---|
| 连接 | 面向连接（先握手） | 无连接（直接发） |
| 可靠性 | 可靠、有序、不重复 | 不保证 |
| 速度 | 较慢（握手 + 确认 + 拥塞控制） | 快（无握手、无状态） |
| 首部 | 20~60 字节 | 8 字节 |
| 典型应用 | 网页、API、文件、邮件 | DNS、音视频、游戏、QUIC |
一句话选型：要可靠有序选 TCP；要低延迟、能容忍少量丢包选 UDP。
为什么需要传输层
IP 只能把数据包送到「某台主机」，但一台主机上跑着浏览器、微信、游戏几十个程序。传输层用端口把数据精确投递到具体进程——这就是「复用」（多个应用共享网络发送）与「分用」（接收方按端口分发）。
TCP 可靠的代价：握手与队头阻塞
TCP 的「可靠有序」不是免费的：
- 建连要握手：三次握手才能开始传数据（多一个 RTT）；HTTPS 还要再叠 TLS 握手。
- 有序交付有队头阻塞：TCP 保证按序，一个段丢了，后面已经到达的段也得等它重传补齐才能交给应用——这就是 TCP 队头阻塞。HTTP/2 的多路复用解决了应用层队头阻塞，却仍困于这一层，最终催生了基于 UDP 的 QUIC（见「HTTP 演进与性能」叶）。
下面各页逐一展开：先看 传输层与端口·复用分用。