Networking on 纪伟的个人博客

TCP/IP（十三）：抓包与网络诊断方法论

Wed, 10 Jun 2026 10:00:00 +0800

写在前面

上一篇把 NAT、DHCP 这些“地址怎么来、怎么转换”的机制讲完了，五层模型从下到上的协议也就齐了。但会背协议和“真的会排障”是两回事——线上一个“网站打不开”，到底是 DNS 挂了、网关不通、端口被占，还是应用自己炸了？

本篇是系列收官，目标是把前十二篇的原理落到工具上：先给一张网络诊断工具速查表，再重点拆 tcpdump 和 Wireshark，最后给一套按层排查的连通性方法论。结尾会把整个 TCP/IP 系列串一遍，并指向本站相关的实战文章。

一、工具速查表

先一张总表，每层对应的常用工具：

层	工具	解决什么问题
网络层	ping	连通性 + RTT（基于 ICMP Echo）
网络层	traceroute / mtr	观察探测路径与逐跳响应，辅助定位异常区间（基于 TTL）
传输层	ss / netstat	连接状态、监听端口、TIME_WAIT 堆积
应用层	dig / nslookup / host	DNS 解析是否正常
全层	tcpdump	抓包，看链路上真实在跑什么
全层	Wireshark	读 pcap、按协议分层解析、交互式过滤

下面挑最常用的逐个说清楚。

ping：连通性与 RTT

ping 发 ICMP Echo Request，对端回 ICMP Echo Reply，用来判断可达性和往返延迟（RTT） 。

1
2
3
4
5
6


$ ping -c 4 8.8.8.8
PING 8.8.8.8 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.9 ms
...
4 packets transmitted, 4 received, 0% packet loss

读懂输出：ttl 是应答到达你时剩余的跳数；只有先假设对端使用了某个常见初始 TTL，才能粗略估计回程跳数，而且回程路由可能与去程不同。time 是 RTT，丢包率是重要指标。注意 ping 不通不等于网络断了——很多服务器 / 防火墙会禁掉 ICMP，HTTP 服务照样能访问。

traceroute / mtr：逐跳路径

ping 只能观察目标是否回应特定 ICMP 探测；traceroute 则通过各跳返回的 ICMP 响应观察一条可能的探测路径，帮助缩小异常范围，但不能单凭某一跳不回应就断定业务包在那里丢失。原理是利用 IP 头里的 TTL：

先发一个 TTL=1 的包，第一跳路由器收到后 TTL 减到 0，丢弃并回 ICMP Time Exceeded；
再发 TTL=2 的包，第二跳路由器回 Time Exceeded；
如此递增，直到到达目的或超时。

1
2
3
4
5
6


$ traceroute -n 8.8.8.8 # Linux/macOS，-n 不反解域名（更快）
 1 192.168.1.1 1.2 ms # 家用路由器
 2 10.0.0.1 5.3 ms # 运营商接入
 3 * * * # 这一跳禁了 ICMP，不代表故障
 ...
 9 8.8.8.8 12.1 ms

平台差异要注意：Linux 的 traceroute 默认发 UDP 包到高端口（33434 起），Windows 的 tracert 默认发 ICMP Echo。有的路由器只对 ICMP 放行、对 UDP 高端口丢包，所以同一目标两边结果可能不同。

mtr（my traceroute）结合了持续探测与逐跳统计，实时显示各跳响应率和延迟，是常用的路径诊断工具。中间节点可能限制 ICMP 回包；若某一跳显示丢包而后续节点和最终目标正常，通常不能认定业务流量在该跳丢失：

1

$ mtr -n 8.8.8.8 # 持续刷新，Ctrl+C 退出看汇总

一个常见误读：中间某跳显示丢包，但后面几跳正常——这往往是该路由器对 ICMP 限速（control-plane policing），不是真丢包。看最终目的的丢包率才靠谱。

ss / netstat：连接状态与监听端口

netstat 是老牌工具，现代 Linux 发行版通常推荐使用 ss（socket statistics）。两者有一部分相似的短参数，但语法、过滤能力和输出并不完全兼容。排查“端口被谁占了”“连接建立没建立”“TIME_WAIT 是不是爆了”都可以用到它们。

1
2
3
4


ss -tlnp # 监听中的 TCP 端口（-t tcp -l listen -n 不解析 -p 进程）
ss -tnp # 已建立的 TCP 连接
ss -s # 连接状态汇总（ESTABLISHED / TIME-WAIT / ... 数量）
ss -tan state time-wait # 只看 TIME-WAIT 状态的连接

经典场景：服务起不来报 Address already in use，用 ss -tlnp | grep :8080 看端口被哪个进程占着；短连接打多了，ss -s 里 TIME-WAIT 几万条，就是连接复用要做优化了（详见 TCP 那篇的状态机）。

dig / nslookup / host：DNS

“能访问 IP、按域名访问失败”时，DNS 是优先检查项之一，但 Host / SNI、代理、虚拟主机和应用配置也可能造成相同表象。三个工具各有侧重：

1
2
3
4
5
6
7


dig www.example.com # 最详细：显示完整的查询过程和 TTL
dig +short www.example.com # 只要结果 IP，适合脚本
dig @8.8.8.8 www.example.com # 指定用哪个 DNS 服务器查
dig MX example.com # 查特定记录类型（MX/NS/TXT/A ...）

nslookup www.example.com # 老牌，交互式，输出不如 dig 清晰
host www.example.com # 最精简，只给一句话结论

排 DNS 时常用 dig @指定DNS 域名 对比。不同解析器结果不一致，说明问题与解析路径有关，可能是本地缓存或配置，也可能是 split-horizon、区域调度、DNS 劫持或不同解析器命中了不同 CDN 节点，需要结合权威记录和业务预期继续判断。

二、tcpdump：抓包与过滤语法

上面这些工具都是"问别人"，tcpdump 是直接看链路上跑的原始字节。它是网络排障的终极武器，也是 Wireshark 抓包数据的命令行来源。

基本用法

1
2
3
4
5
6


tcpdump -i eth0 # 监听 eth0 网卡（-i 指定接口）
tcpdump -i eth0 -n # -n 不反解 IP 为域名（快、输出干净）
tcpdump -i eth0 -nn # -nn 连端口也不反解
tcpdump -i eth0 -c 100 # 抓够 100 个包就停
tcpdump -i eth0 -w out.pcap # 写入 pcap 文件（给 Wireshark 看）
tcpdump -i eth0 -w out.pcap -W 1 -G 60 # 每 60 秒轮转一个文件

习惯上排障时用 tcpdump -i any -nn 监听所有网卡、不解析名字，先看清流量再说。

过滤表达式（BPF 语法）

tcpdump 用的是 BPF（Berkeley Packet Filter）表达式，逻辑是"按条件筛选包"。这套语法也适用于 Wireshark 的抓包过滤器（capture filter，注意和显示过滤器 display filter 不是一回事）。核心原语：

原语	含义	示例
`host`	源或目的是某 IP	`host 8.8.8.8`
`src host` / `dst host`	只匹配源 / 目的	`src host 192.168.1.10`
`net`	匹配网段	`net 192.168.1.0/24`
`port`	源或目的是某端口	`port 80`
`src port` / `dst port`	只匹配源 / 目的端口	`dst port 443`
`tcp` / `udp` / `icmp`	按协议	`tcp and port 80`
`and` / `or` / `not`	逻辑组合	`host A and port 80`

实战组合：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 抓与某主机的所有 HTTP 流量
tcpdump -i eth0 -nn host 93.184.216.34 and tcp port 80

# 抓某个客户端的所有 DNS 查询（UDP 53）
tcpdump -i eth0 -nn src host 192.168.1.10 and udp port 53

# 只抓 TCP SYN 包（连接建立的第一个包）——发现谁在发起连接
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0'

# 抓 SYN 但不带 ACK 的包（纯握手起始，排除 SYN-ACK）
tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

# 抓所有 RST（连接被重置）
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'

TCP 标志位的写法要特别说明：tcp[tcpflags] 是 TCP 头里标志字段，后面跟位掩码 &。可用的标志常量是 tcp-fin、tcp-syn、tcp-rst、tcp-push、tcp-ack、tcp-urg。想抓"某组合位都被置上"，用 == (tcp-syn|tcp-ack)；想抓"只要含某位"，用 & tcp-syn != 0。

语法细节参考官方 pcap-filter(7) man page。记住一点：tcpdump 的过滤表达式和 Wireshark 的显示过滤器是两套语法 。tcpdump 过滤（BPF）在抓包时就生效，决定哪些包写入 pcap；Wireshark 显示过滤是抓完之后再筛，语法完全不同（如 ip.addr == 8.8.8.8）。

三、Wireshark：分层解析利器

tcpdump 适合在服务器上快速看一眼，真正要"逐字段拆解协议"，还得靠 Wireshark。典型工作流是：服务器上 tcpdump -w 存成 pcap → 下载到本地用 Wireshark 打开。

Wireshark 的核心能力是按协议分层展开一个包：点开一个帧，能看到以太网头、IP 头、TCP 头、HTTP 报文逐层嵌套，每一层的每个字段（TTL、序号、标志位、窗口大小……）都标好了含义——正好对应第一篇讲的封装。

显示过滤器（Display Filter）

Wireshark 的显示过滤器是一套独立语法，比 BPF 强大得多：

过滤表达式	含义
`ip.addr == 8.8.8.8`	源或目的是 8.8.8.8
`tcp.port == 443`	TCP 端口 443
`tcp.flags.syn == 1`	SYN 标志位置 1
`tcp.flags.reset == 1`	RST 包
`dns`	所有 DNS 报文
`http.request.method == "GET"`	HTTP GET 请求
`tls.handshake.type == 1`	TLS ClientHello

还能按协议右键某个字段 → “作为过滤器应用”，组合条件非常方便。

常用排障视角

TCP 流跟踪：右键一个 TCP 包 → Follow → TCP Stream，把一个连接的请求 / 响应整理成可读的对话，看 HTTP 在裸 TCP 上是怎么一来一回的。
统计 → 会话（Conversations）：列出所有连接的端点、包数、字节数，快速发现"谁在异常大量通信"。
统计 → IO 图表：按时间画吞吐量曲线，定位性能毛刺。

Wireshark 配合前十二篇的协议知识，基本是"协议的活体解剖"——你能在里面亲眼看到三次握手、TLS 握手、HTTP 请求头、DNS 查询响应。

四、分层连通性排障方法论

工具会用了，关键是怎么有章法地用 。网络问题的典型困境是：现象一样（“连不上”），原因五花八门。乱试一通效率极低，正确做法是沿协议栈自底向上逐层排除，在哪一层断了就停在那查。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


应用层 DNS 解析对吗？HTTP/TLS 正常吗？应用本身有没有报错？
 ▲ │ dig / curl -v / 应用日志
 │ ▼
传输层 端口通吗？连接能建立吗？TIME_WAIT 堆积了吗？
 ▲ │ ss / telnet host port / nc -zv
 │ ▼
网络层 网关能 ping 通吗？路由对吗？哪一跳丢包？
 ▲ │ ping / ip route / traceroute / mtr
 │ ▼
链路层 ARP 学到吗？MAC 对得上吗？网卡有没有丢包错包？
 ▲ │ arp -a / ip -s link
 │ ▼
物理层 网线插好了吗？网卡灯亮吗？交换机端口正常吗？
 眼看 / ethtool

每一层的判断准则：这一层通了，才往上查；这一层不通，先修这一层 。原因很简单——下面断了，上面必然全断；下面不通时去调应用，纯属浪费时间。

每层的关键检查项

物理层：看网卡灯、ethtool eth0 看链路是否 up、有没有大量物理层错误。云服务器里这层基本是虚拟的，可跳过。

链路层：ip neigh（旧 arp -n）看 ARP 表，目标 IP 的 MAC 学到了吗？ip -s link 看网卡有没有 RX/TX 丢包、错误帧。VLAN、二层隔离的问题也在这层。

网络层：

ping 网关 通吗？不通说明本机到网关就有问题（链路层或本机配置）。
ping 8.8.8.8 有回应吗？有回应只说明这条 ICMP 路径此刻可达，不代表所有出口协议和目标都正常；无回应时可换目标并结合 traceroute / mtr 观察异常从哪一段开始持续出现。
ip route 看默认路由在不在、对不对。

传输层：

ss -tlnp 确认服务真的在监听那个端口、那个地址（监听 127.0.0.1:8080 是连不上外部访问的）。
nc -zv host port 或 telnet host port 测端口可达性。
ss -s 看连接状态，TIME_WAIT / CLOSE_WAIT 堆积是常见病。

应用层：

dig 验证 DNS。
curl -v 看完整的 HTTP / TLS 交互，分清是 DNS、连接、TLS 还是应用层返回错误。
看应用自身日志——很多"网络问题"最后是应用抛的异常。

五、实战：网站打不开怎么按层排查

把方法论套到一个真实场景。假设用户反馈 https://api.example.com 打不开，按层走一遍：

1. 物理层 / 链路层（先确认本机网络没断）

1
2
3


$ ip -s link show eth0 # 网卡 up，无错包
$ ping 192.168.1.1 # ping 网关
64 bytes from 192.168.1.1: time=0.5 ms # 通

本机到网关正常，底层没问题。

2. 网络层（确认出网正常）

1
2
3


$ ping 8.8.8.8
64 bytes from 8.8.8.8: time=12 ms # 出网正常
$ ping 1.1.1.1 # 换个目标再确认

能 ping 通某个公网 IP，说明到该目标的 ICMP 往返路径可达，但不能据此断言整个网络层或所有出口策略都正常。如果这步异常，可更换探测目标，并用 mtr -n 8.8.8.8 观察异常是否从某一跳开始延续到最终目标。

3. 应用层 - DNS（域名能解析吗）

1
2
3
4


$ dig api.example.com +short
(空) # 解析不出来！
$ dig @8.8.8.8 api.example.com +short
1.2.3.4 # 换 DNS 能解析

定位到 DNS 路径差异后，再检查本机、递归解析器和权威记录。使用 systemd-resolved 的新系统可执行 resolvectl flush-caches；DNS 配置通常由 NetworkManager、systemd-resolved 或 DHCP 管理，不要在未确认管理方式前直接修改可能被自动覆盖的 /etc/resolv.conf。

4. 传输层（端口可达吗，假设 DNS 修好了拿到 IP）

1
2


$ nc -zv 1.2.3.4 443
Connection to 1.2.3.4 443 port [tcp/https] succeeded! # 端口通

端口通说明 TCP 层没问题。如果这里超时，多半是对端没监听、被防火墙拦或本机出口被限。

5. 应用层 - HTTP/TLS（服务正常响应吗）

1
2
3
4
5
6


$ curl -v https://api.example.com
* Trying 1.2.3.4:443...
* Connected
* TLS handshake # 卡在这里？
> GET / HTTP/2
< HTTP/2 500 # 服务端报错

curl -v 会展示连接、TLS 握手和 HTTP 请求响应等阶段。失败阶段能帮助确定优先排查方向，但跨层依赖和中间设备会让同一根因表现为不同阶段失败，不能把它当成严格的一一映射。这里若是 TLS 失败，应继续检查证书、时间、SNI 和协议协商；若收到 HTTP 500，说明请求已经到达某个 HTTP 服务，重点转向应用及其后端依赖。

整个过程对应的方法论就是：从下到上逐层排除，用工具验证每一层的假设，定位到具体层后再深入 。比起一上来就重启服务、瞎改配置，这套方法省时得多。

小结

网络诊断要按层排查：物理 → 链路（ARP/MAC）→ 网络（ping/路由/traceroute）→ 传输（端口/TIME_WAIT）→ 应用（DNS/HTTP/TLS），一层通了才往上查。
ping 观察 ICMP 可达性与 RTT，traceroute / mtr 观察探测路径和异常区间，ss / netstat 看连接与端口，dig 查 DNS。
tcpdump 是抓包终极武器，过滤用 BPF 语法（host/port/tcp[tcpflags] & tcp-syn），存成 pcap 交给 Wireshark。
Wireshark 按协议分层展开，配合系列前十二篇的知识能看懂每个字段；显示过滤器是独立语法，别和 BPF 混。

系列总结

十三篇，从"为什么要分层"到"怎么抓包排障"，TCP/IP 的主干终于串完了。回顾整个系列，可以浓缩成一条主线：数据在发送端被逐层封装，在接收端被逐层解封装，每一层只解决自己的问题 。

篇	主题	一句话要点
1	分层模型	OSI 七层是参考、TCP/IP 四层贴实际、五层是教学折中
2–3	链路层	以太网帧 + MAC 地址，ARP 把 IP 翻译成 MAC，交换机按 MAC 转发
4–6	网络层	IP 编址与子网划分，路由怎么选路，ICMP 反馈通断
7–9	传输层	TCP 三次握手 / 四次挥手 / 状态机，可靠性与流控拥塞控制，UDP 轻量无连接
10–11	应用层	DNS 分层解析与缓存，HTTP 语义、连接复用与 TLS
12	地址机制	NAT/NAPT 改写地址省公网 IP，DHCP 自动分配 IP，CGNAT 让家网失去公网 IP
13	诊断方法论	工具速查 + 按层排障

把这些拼起来，一个 HTTP 请求的全貌就是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


应用层：构造 HTTP 报文
 │ DNS 解析域名 → 拿到 IP（应用层，但贯穿）
 │ HttpClient / epoll 在这层调度 I/O
 ▼
传输层：套 TCP 头，三次握手建连接，按序可靠传输
 ▼
网络层：套 IP 头，路由逐跳转发
 ▼
链路层：套帧头尾，ARP 找到下一跳 MAC，交换机转发
 ▼
物理层：比特流出网线
 │
 │ 出口 NAT 改写源 IP:端口 → 公网
 │ 对端反向解封装，层层上交到应用
 ▼
对端应用收到报文，返回响应走反向全程

每一步都对应系列里某一篇的原理。理解了这条链，再回头看平时写的后端代码，很多"玄学问题"就有了着落。

网络是后端、云原生、分布式共同的地基，本站还有几篇从应用侧把网络用起来的实战文章，正好衔接：

HttpClient 的前世今生：从 Socket 耗尽到 .NET 8 韧性管线 ——传输层连接池、Socket 耗尽、DNS 刷新在工程里怎么踩坑怎么治。
epoll 的前世今生：从 select/poll 到 io_uring ——高并发下传输层的 I/O 复用是怎么演进的。
跟着一个 API 请求走完全程：后端全链路解剖 ——把本系列的网络层和业务代码、中间件串起来看。
.NET 高并发编程全景：从异步到高性能实战 ——传输层之上，应用怎么榨干单机的并发能力。

TCP/IP 系列到此完结。原理是死的，排障是活的——希望你下次遇到网络问题时，能从容地掏出这套分层方法论，而不是只会重启服务。

参考：

tcpdump man page / pcap-filter(7)

Wireshark User’s Guide

mtr — GitHub

Using dig for DNS troubleshooting

TCP/IP（十二）：NAT、DHCP 与地址机制

Mon, 08 Jun 2026 10:00:00 +0800

写在前面

前十一篇把五层模型从链路一路讲到了应用层：以太网与 ARP、IP 编址与路由、TCP/UDP、HTTP/DNS。但有一个非常现实的问题一直没正面回答——

你的电脑 IP 多半是 192.168.1.x，这明明是个"私网地址"，为什么能访问公网？ 公司里几千台机器共用一个出口 IP，外网的响应是怎么精确回到你这台的？ 还有，这个 IP 是谁分配给你的，为什么重启路由器可能就变了？

这些问题的答案就是 NAT 和 DHCP——两个支撑整个现代互联网"最后一公里"的地址机制。本篇把它们一次讲透。

一、为什么需要 NAT

NAT（Network Address Translation，网络地址转换）诞生的直接原因就一个：IPv4 地址不够用了 。

IPv4 总共约 43 亿个地址，扣掉组播、保留、特殊用途，能分给终端的更少。2011 年 IANA 的全球地址池就发完了，APNIC（亚太）等区域注册局也先后告急。与此同时，联网设备却爆炸式增长——每台手机、每台电视、每个智能插座都要 IP。怎么办？

NAT 的思路很朴素：不需要每台设备都有公网 IP，让一群设备共用一个（或少数几个）公网 IP 出网 。具体做法是在内网和公网的边界（家用路由器、企业防火墙）上做地址改写：

内网用私网地址，设备之间互相访问；
出网时，NAT 把源地址从私网改成公网，返回流量再改回来。

这就引出两个配套概念：私网地址段（内网用什么 IP），以及转换表（怎么把流量对回正确的内网主机）。

NAT 还顺带带来了一个工程上的副作用：隐藏内网结构 。公网看到的全是出口 IP，内网拓扑对外不可见，某种程度上也算一层隔离（但别把它当安全机制用）。

二、私网地址段与公网：RFC 1918

既然内网不走公网路由，就得有一段"大家都能随便用、但不会被公网路由"的地址。这就是 RFC 1918 定义的三个私网地址段：

私网地址段	CIDR	范围	典型场景
10.0.0.0/8	A 类	10.0.0.0 – 10.255.255.255	企业内网、数据中心（地址多）
172.16.0.0/12	B 类 ×16	172.16.0.0 – 172.31.255.255	中等规模内网、容器网络
192.168.0.0/16	C 类 ×256	192.168.0.0 – 192.168.255.255	家庭网络、小型办公

这三个段全球任何组织都可以重复使用，因为它们不会出现在公网路由表里——运营商会在边界丢弃目的为私网地址的流量。你家是 192.168.1.x，邻居家也是，互不冲突，因为各自都在自己的 NAT 后面。

规范细节：RFC 1918 地址不应在公共互联网中传播路由。访问 192.168.1.1 时，主机会根据本地路由把流量交给本地链路或私网下一跳，而不会靠公网路由去寻找其他组织中重复使用的同名地址；VPN、重叠私网或更具体的本地路由仍可能改变实际去向。

与之相对的是公网地址（也叫可路由地址、全球单播地址），由 IANA → RIR → NIR → ISP 层层分配，全球唯一，能在公网被路由。

除了 RFC 1918，还有几段容易混淆的特殊地址，顺带记住：

地址段	含义
127.0.0.0/8	环回（loopback），本机自测，最常用 `127.0.0.1`
169.254.0.0/16	链路本地（link-local），DHCP 拿不到 IP 时操作系统自动配的
0.0.0.0	“本机所有地址”，常出现在监听（`0.0.0.0:80`）和默认路由

知道这些段，后面排查"为什么我的 IP 是 169.254.x.x"（答：DHCP 失败了）就不会懵。

三、NAT 工作原理：NAPT

最简单的 NAT 是"一对一"——一个公网 IP 对一个内网 IP，但这等于没省。实际家网、企业网用的几乎都是 NAPT（Network Address Port Translation，也叫 PAT），它同时改 IP 和端口，让多个内网主机共用一个公网 IP。

一次出网的全过程

假设你家出口公网 IP 是 203.0.113.5，内网两台机器同时访问 8.8.8.8:53（DNS）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


内网主机 A 192.168.1.10:5000 ──┐
 │ [NAT 网关 203.0.113.5]
内网主机 B 192.168.1.20:5000 ──┘
 │
 │ 出网时，NAT 改写源地址（SNAT）：
 │ A → 203.0.113.5:30001
 │ B → 203.0.113.5:30002
 │
 ▼
 公网 8.8.8.8:53

NAT 在内部维护一张转换表（NAT session table），把"内网 IP:端口"映射到"公网 IP:端口"：

方向	源	目的	协议
内→外（改写前）	192.168.1.10:5000	8.8.8.8:53	UDP
外→内（公网看到的）	203.0.113.5:30001	8.8.8.8:53	UDP
内→外（改写前）	192.168.1.20:5000	8.8.8.8:53	UDP
外→内（公网看到的）	203.0.113.5:30002	8.8.8.8:53	UDP

关键点：

即便两台内网机器用了相同的源端口（都是 5000），NAT 通过分配不同的外部端口（30001 / 30002）也能区分开来——这就是 NAPT 省地址的精髓。
返回流量到达 203.0.113.5:30001 时，NAT 查表反查出 192.168.1.10:5000，改写目的地址（DNAT）后送回内网。
这张表是有状态的，条目有空闲超时（TCP 几小时、UDP 几十秒到几分钟不等），超时未用就清除。

这种出网改源地址的叫 SNAT（Source NAT）。后面端口映射那种"进网改目的地址"的叫 DNAT（Destination NAT）。家用路由器做的 NAPT 本质是 SNAT。

NAT 让公网 IP 消耗骤降——一个家庭、一栋楼甚至一个小区可以共用少数公网 IP。但它的代价也很明显：打破了 IP 端到端的语义 。公网主机没法主动发起连接到内网主机（因为 NAT 表里没有对应条目，包到不了），这直接导致了后面的 P2P 问题。

四、端口映射 / 端口转发

NAPT 解决了"内网出去"，但反过来"公网进来"呢？默认情况下，公网主动发起到你出口 IP 的连接，NAT 不知道该转给谁，只能丢弃。

端口映射（port forwarding，也叫端口转发） 就是为这个场景准备的：在 NAT 上配一条静态规则，把"公网某个端口"固定转发到"内网某台主机的某端口"。

1
2
3
4
5
6
7


公网用户 家用路由器 内网服务器
 │ 203.0.113.5 192.168.1.10
 │ :8080
 │ 访问 http://203.0.113.5:8080 ▲
 │ ──────────────► [DNAT 规则] │
 │ 公网 :8080 → 192.168.1.10:8080
 │ ─────────────────────────►│

常见场景：

自托管：在家用宽带搭个博客、游戏服务器，把公网 80/443/25565 映射到内网那台机器；
远程访问：把 22（SSH）或 3389（RDP）映射到内网某台主机，出门在外也能连回家；
容器 / 虚拟机：Docker 的 -p 8080:80、VirtualBox 的端口转发，本质都是同一个机制，只是在宿主机上做了一层 DNAT。

配置方式各家不同，但概念一致：一条固定的 公网端口 → 内网 IP:端口 规则 。和 NAPT 的动态转换表不同，端口映射是手动写死的、长期有效的。

注意端口映射能成立的前提是你得有公网 IP 。下面马上说，现在很多家网已经没有公网 IP 了。

五、NAT 对 P2P 的阻碍与打洞：STUN / TURN / ICE

NAT 帮我们省了地址，却给 P2P（点对点）通信 添了大麻烦。

P2P 的前提是"两台主机互相直接发包"。但 NAT 后面的主机对外不可见，A 想连 B，B 的 NAT 会直接丢包——因为表里没有 A 的条目。语音通话（WebRTC）、BT 下载、游戏联机这类强 P2P 场景全受影响。

要理解怎么解决，先要知道 NAT 的映射与过滤行为并不完全相同。工程资料常沿用 RFC 3489 的经典分类，从宽松到严格列成下表：

NAT 类型	行为	能否打洞
Full Cone（完全锥型）	最宽松：内网主机从内出去后，任何公网主机往那个映射端口发包都能进	容易
Restricted Cone（限制锥型）	只允许发往"内网主机曾访问过的那个公网 IP"的包进来	可打洞
Port Restricted Cone（端口限制锥型）	还限制"必须是那个 IP 的那个端口"	可打洞
Symmetric（对称型）	最严格：对不同目的分配不同外部端口，外部几乎无法预测	很难，通常要中转

术语演进：RFC 3489 后来被 RFC 5389 取代，RFC 4787 / RFC 5780 等文档改用**映射行为（mapping behavior）和过滤行为（filtering behavior）**两个维度描述 NAT。两者必须分别判断；端口保持、hairpinning 和映射超时也会影响连通性。工程里老叫法仍然流行，因此这里只把它当作历史速记。

针对这个困境，业界提出了三件套：

STUN（Session Traversal Utilities for NAT）：客户端向公网的 STUN 服务器发请求，STUN 回包告诉它“你在公网看来是哪个 IP:端口”。这个服务器反射地址可作为 ICE 候选之一；打洞能否成功还取决于双方 NAT 的映射、过滤、端口保持和超时行为，不能只用“是否对称型”一个标签判断。
TURN（Traversal Using Relays around NAT）：当打洞失败（典型是对称型 NAT），就退而求其次，让一台公网中继服务器转发两端流量。能连通，但代价是延迟增加、中继服务器带宽吃紧。
ICE（Interactive Connectivity Establishment）：一套编排框架，把直连、STUN 打洞、TURN 中继都列成候选路径，按优先级依次尝试，选第一个能通的。WebRTC 就是基于 ICE 来协商 P2P 媒体通道的。

一句话：STUN 负责发现公网映射、尝试打洞；TURN 在打不通时当中继；ICE 负责把两者和直连编排起来选最优路径 。

六、CGNAT：为什么家网没有公网 IP

如果你试过在家宽带路由器上配端口映射，却怎么也连不上——很可能你的宽带已经在 CGNAT（Carrier-Grade NAT，运营商级 NAT）后面了，你拿到的根本不是公网 IP 。

CGNAT 是运营商部署的大规模 NAT，目的和家网 NAT 一样：省公网地址。结构上是两层 NAT 串联：

1
2


你的设备 ──► 家用路由器(NAT) ──► 运营商 CGNAT(NAT) ──► 公网
192.168.x 10.x / 100.64.x 公网 IP

你家路由器拿到的是运营商分配的"伪公网 IP"，通常是 RFC 6598 定义的共享地址段 100.64.0.0/10（100.64.0.0 – 100.127.255.255）；
这个段专门给 CGNAT 用，和 RFC 1918 私网段区分开，避免和企业内网冲突；
你的流量到运营商 CGNAT 后，再被改写成真正的公网 IP 出网。

后果就是：你家路由器做的端口映射，只把端口开到了 100.64.x.x 那一层，公网根本到不了 。这种情况下想做自托管、被外网主动访问，基本只能靠内网穿透（frp、ngrok、Tailscale 之类）走中继了。

怎么判断自己是不是在 CGNAT 后面？先看路由器 WAN 地址是否位于 100.64.0.0/10 或 RFC 1918 私网段，再与外部网站看到的出口地址对比。两者不一致是“中间还存在 NAT、代理或 VPN”的强烈迹象，但不能单凭这一点断定就是运营商 CGNAT；双路由、企业出口和 VPN 也会造成类似现象。必要时再结合 traceroute 和运营商信息确认。

CGNAT 的大量部署，本身就是 IPv4 地址枯竭的直接证据。彻底解决要靠 IPv6（它有 2¹²⁸ 个地址，足以让每粒沙子都有公网 IP），但 IPv6 的全面替换依旧是个漫长的工程。

七、DHCP：自动分配 IP（DORA 四步）

讲完了地址转换，再说地址怎么来的。手动给每台机器配 IP 显然不现实——办公网络、Wi-Fi、容器都要求"插上网线 / 连上 Wi-Fi 就能上网"。这件事由 DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）完成。

DHCP 不只分配 IP，还一次性把这几样都下发：

IP 地址 + 子网掩码（告诉你 IP 和网络范围）；
默认网关（去往外网的下一跳，详见路由那篇）；
DNS 服务器（域名解析用谁）；
租约时间（lease time，这个 IP 借你用多久）。

DORA 四步

DHCP 获取地址的过程叫 DORA，是四个报文的首字母：Discover → Offer → Request → Acknowledge。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


客户端 DHCP 服务器
 │ (还没 IP，用 0.0.0.0 作源) │
 │ │
 │ ① DHCPDISCOVER (广播, → UDP 67) │
 │ ─────────────────────────────────────────► │ "谁是 DHCP 服务器？我要 IP"
 │ │
 │ ② DHCPOFFER (→ UDP 68) │
 │ ◄──────────────────────────────────────── │ "我这有个 IP 给你，附掩码/网关/DNS"
 │ │
 │ ③ DHCPREQUEST (广播) │
 │ ─────────────────────────────────────────► │ "我就要你给的这个"
 │ │
 │ ④ DHCPACK (→ UDP 68) │
 │ ◄──────────────────────────────────────── │ "确认，租约 86400 秒，拿去用"
 │ │
 │ 现在客户端正式配置好 IP，可以通信了 │

几个关键点：

端口：服务器监听 UDP 67，客户端监听 UDP 68 。Discover 是广播（因为客户端还不知道服务器在哪），Offer / ACK 通常也是广播或单播取决于实现。
为什么 Request 要广播：可能网络里有多个 DHCP 服务器都回了 Offer，客户端广播 Request 既是在"认领"选中的那个，也是在告诉其余服务器"我没选你，你可以回收那个 IP"。
竞态：客户端发 Discover 后可能收到多个 Offer，一般选最先到达的。

租约与续约

DHCP 给的 IP 不是永久的，而是租约（lease） ，到期不续就回收。续约过程：

到租约的 50%（T1），客户端向原服务器单播 Request 续约；
到 87.5%（T2），若原服务器没响应，客户端进入 rebinding，向任意 DHCP 服务器广播求续；
若到 100% 还没续上，客户端必须释放 IP，重新走一遍 DORA。

这就是为什么"重启路由器 IP 会变"——租约可能到期被回收，再申请时拿到的是池里另一个 IP。同样，ifconfig 看到自己 IP 是 169.254.x.x（链路本地地址），说明 DHCP 整个过程失败了，操作系统给自己随便配了个地址应急。

DHCP 的初始发现依赖广播，但服务器并非“无状态”：它需要维护地址池、客户端标识、租约和到期时间。服务器短时不可用时，客户端通常仍可在现有租约有效期内使用地址，但续租和重新分配会受影响。同一网段可以部署经过协调的多个 DHCP 服务器，却不能随便接入未授权服务器；交换机的 DHCP Snooping 会限制只有信任端口能够发送服务器侧报文，防止私接 DHCP 把终端带到错误网络。

小结

NAT 的本质是在私网/公网边界改写地址，让多台设备共用一个公网 IP，缓解 IPv4 地址枯竭；实际用的 NAPT 同时改 IP 和端口，靠一张有状态的转换表把流量对回正确主机。
RFC 1918 定义了三个可重复使用的私网地址段（10/8、172.16/12、192.168/16）；RFC 6598 的 100.64.0.0/10 专给运营商 CGNAT 用，CGNAT 是家网"没有公网 IP"的根因。
端口映射（DNAT）把公网端口固定转发到内网，用于自托管；前提是真公网 IP。
NAT 破坏了端到端，给 P2P 制造障碍；STUN 打洞、TURN 中继、ICE 编排 是 WebRTC 等场景的标准解法，对称型 NAT 通常只能靠 TURN 中继。
DHCP 用 DORA 四步（Discover/Offer/Request/Acknowledge）自动下发 IP、掩码、网关、DNS，配合租约机制管理地址池；端口是 UDP 67（服务器）/ 68（客户端）。

下一篇是系列收官：TCP/IP（十三）：抓包与网络诊断方法论 ——把前面学的所有协议落到工具上，给一套分层的连通性排障方法论，再把整个系列串一遍。

参考：

RFC 1918: Address Allocation for Private Internets

RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space

RFC 3489: STUN (Classic) / RFC 5389: STUN / RFC 8445: ICE

RFC 2131: Dynamic Host Configuration Protocol (DHCP)

Carrier-grade NAT — Wikipedia

TCP/IP（十一）：HTTP、HTTPS 与 TLS

Sat, 06 Jun 2026 10:00:00 +0800

写在前面

上一篇讲了 DNS——怎么把 example.com 这样的域名变成 IP。拿到 IP 之后，浏览器要做的下一件事就是：建连、发请求、拿数据。承载这套交互的，是应用层里最成功的协议——HTTP。

但光有 HTTP 还不够：它是明文的，链路上任何人都能偷看甚至篡改。于是有了 HTTPS，也就是 HTTP 套上一层 TLS。这一篇把两件事讲透：HTTP 从 1.0 一路演进到 3 到底在解决什么痛点，以及 TLS 那次"握手"究竟握了什么、为什么需要证书链。

本文是应用层的"主菜"。如果你更关心"一次完整的 API 请求在工程上怎么跑"，可以回看本站的后端全链路解剖；想深入 .NET 里 HTTP 客户端的坑（DNS 不刷新、socket 耗尽、连接池），看 HttpClient 的前世今生。

一、应用层概览：HTTP 站在哪儿

回忆第五层模型：应用层直接跑在传输层之上。HTTP 绝大多数时候跑在 TCP 上（可靠传输对网页、API 来说是刚需），默认端口 80；加密后的 HTTPS 默认端口 443。

1
2
3
4
5


应用层： HTTP / HTTPS （应用报文）
 │
 │ （HTTPS 在这里多一层 TLS，把 HTTP 加密后再交给 TCP）
 ▼
传输层： TCP（端口 80 / 443）

TLS 严格说不是"传输层之上、应用层之下"的独立层（五层模型里它通常算应用层的一部分），但工程上它确实横在 HTTP 和 TCP 之间，对 HTTP 透明——HTTP 该怎么发还怎么发，只是字节流被加了一层加密。

HTTP 能一统 Web，靠的是无状态 + 请求-响应 + 文本可读 的极简模型。但这个模型在性能上踩过不少坑，每一次大版本升级都是在对这些坑打补丁。

二、HTTP/1.0：每个请求开一条连接

1996 年的 HTTP/1.0（RFC 1945）模型简单粗暴：

1
2
3
4
5
6


Client Server
 │ ── TCP 三次握手 ──────────────▶ │
 │ ── HTTP 请求 ─────────────────▶ │
 │ ◀── HTTP 响应 ───────────────── │
 │ ── TCP 四次挥手（连接关闭）────▶ │
 │ ── 下一个请求？再握手一遍 ─────▶ │

默认每个请求单独开一条 TCP 连接，响应完就关。痛点很明显：

每个请求都要一次 TCP 握手（1 个 RTT）+ 一次 TLS 握手（如果走 HTTPS，又是 1~2 个 RTT）；
TCP 慢启动 每条新连接都要从头爬坡，根本用不上已经调好的拥塞窗口；
一个页面几十个资源，就几十次握手，延迟堆叠非常可怕。

严格说，HTTP/1.0 并非完全不能复用连接——它有个 Connection: Keep-Alive 扩展头可以勉强长连，但非默认、且语义不统一。真正把长连接变成默认行为的是 1.1。

三、HTTP/1.1：keep-alive、Host 头与管线化

1997 年的 HTTP/1.1（RFC 2068，后由 RFC 2616 / 7230 系列修订）是生命力最长的一版，今天很多服务还跑在它上面。三大关键改进：

1. 持久连接（keep-alive）成为默认

连接不再用完即弃，而是默认保持打开，后续请求复用同一条 TCP 连接，省掉了反复握手的开销：

1
2


── TCP 握手 ──▶ 请求1 → 响应1 → 请求2 → 响应2 → …… → 请求N → 响应N ── TCP 关闭 ──▶
 └──────────── 一条连接复用 ────────────┘

2. Host 头：虚拟主机的基石

请求行里加了 Host: www.example.com。这让一台服务器、一个 IP 上能托管成百上千个域名 —— 服务器靠 Host 头区分请求要给哪个站点。没有这一条，今天的云托管 / SaaS 多租户根本做不起来。

3. 管线化（pipelining）：想法很美，落地很惨

1.1 允许客户端连发多个请求不等响应（流水线）：

1
2


Client：请求1, 请求2, 请求3 ─────▶ Server
Client ◀──── 响应1, 响应2, 响应3

听起来能省掉等待，但有两个致命问题：

应用层队头阻塞 —— 响应必须按请求顺序 返回，响应 1 慢了，2 和 3 再快也得堵在后面；
代理 / 服务器兼容性差 —— 不少中间件对管线化支持有 bug，容易串响应。

结果：主流浏览器默认关闭管线化，实际生产里基本没人用，HTTP/2 的多路复用才是它的"正版替代品"。

1.1 还顺手加了 chunked transfer encoding（分块传输） —— 边生成边发，不用提前知道 Content-Length，对动态页面和流式响应很关键。

四、HTTP/2：二进制帧、多路复用与首部压缩

2015 年的 HTTP/2（RFC 7540，来自 Google 的 SPDY）做了一次大手术，但仍然跑在 TCP 上。四个核心特性：

1. 二进制分帧

抛弃 1.1 的文本格式，把每个请求/响应拆成一个个二进制帧（frame）。一个连接里可以混合传输属于不同请求的帧：

1
2
3
4
5


一条 TCP 连接
├── Stream 1： 帧 │ 帧 │ │ 帧 │
├── Stream 3： │ 帧 │ 帧 │ │ 帧
├── Stream 5： 帧 │ │ 帧 │ │
 ↑ 同一条连接里交织发帧

2. 多路复用（multiplexing）

这是 HTTP/2 的杀手锏。一条 TCP 连接上同时跑无数个并发请求/响应，每个请求是一个独立的 stream，互不阻塞。1.1 的应用层队头阻塞被干掉了——再也不用为了"并发"去开 6~8 条连接。

3. 首部压缩（HPACK）

1.1 每个请求都带一坨重复的 header（Cookie、User-Agent、Accept …）。HTTP/2 用 HPACK 算法压缩这些头部，还维护一张静态表 + 动态表，重复字段只传索引，能省下可观字节。

4. 服务端推送（Server Push）—— 已废弃

服务器可以在客户端请求 A 时，主动把 B、C 一起推过去（“你待会儿肯定要这俩”）。但实践中收益不稳、难调优、还浪费带宽，Chrome 从 106 版（2022 年）起默认禁用、随后彻底移除。今天它事实上已经死了，替代方案是 103 Early Hints。

没解决的痛：TCP 层队头阻塞

HTTP/2 解决了应用层 的队头阻塞，但底层还是一条 TCP 连接。一旦某个 TCP 包丢了，TCP 会卡住整条连接 等重传——所有 stream 上的帧（哪怕本身已经到了接收端）都得等着。并发越多，这个"被一个丢哥拖垮全军"的问题越明显。这正是 HTTP/3 要解决的。

五、HTTP/3：扔掉 TCP，跑在 QUIC 上

2022 年正式发布的 HTTP/3（RFC 9114）做了一个激进决定：不再跑 TCP，改跑 QUIC，而 QUIC 跑在 UDP 上。

1
2


HTTP/2： HTTP → TLS → TCP → IP
HTTP/3： HTTP → QUIC（内建 TLS 1.3，跑在 UDP） → IP

QUIC（RFC 9000）把传输层和加密层揉在了一起 重新设计，带来几个关键收益：

特性	解决了什么
独立 stream，无 TCP 队头阻塞	一个 stream 丢包只卡它自己，其他 stream 照跑
集成 TLS 1.3	握手和传输合并，1-RTT 建连，复用时 0-RTT
连接迁移	手机从 Wi-Fi 切 4G，IP 变了连接不断（靠 Connection ID，不靠四元组）
0-RTT 数据	对访问过的服务器，首个请求的数据能和握手一起发出去

代价是部署上：QUIC 跑 UDP，而不少企业防火墙 / 中间盒对 UDP 不友好（限速、直接丢），所以实践中 HTTP/3 的升级往往需要先 HTTP/2 协商 Alt-Svc 再尝试切换。

各版本一句话对比：1.0 一请求一连接，1.1 默认长连 + Host，HTTP/2 多路复用但卡在 TCP，HTTP/3 干脆换传输层彻底解决队头阻塞 。

版本	年份	传输层	关键特性	主要痛点
HTTP/1.0	1996	TCP	每请求一连接（默认）	握手开销大、慢启动从头爬
HTTP/1.1	1997	TCP	keep-alive、Host 头、管线化、chunked	应用层队头阻塞、管线化难落地
HTTP/2	2015	TCP	二进制帧、多路复用、HPACK、推送	TCP 层队头阻塞、推送已废弃
HTTP/3	2022	QUIC(UDP)	独立流、集成 TLS 1.3、0-RTT、连接迁移	UDP 在部分网络 / 防火墙受限

六、HTTPS = HTTP + TLS：为什么需要这层壳

HTTP 本身不加密，明文跑在网络上意味着：

能被窃听 —— 链路上的任何一跳都能看到你传了什么（密码、token、业务数据）；
能被篡改 —— 中间人可以改响应、插广告、劫持跳转；
无法验证身份 —— 你连的 bank.com 到底是真银行还是钓鱼站，HTTP 自己说了不算。

TLS（Transport Layer Security，前身 SSL）补三件事，正好对应信息安全的三大目标：

TLS 提供	对应威胁	怎么做到
机密性（加密）	窃听	协商出对称密钥，加密应用数据
身份认证	钓鱼 / 中间人冒充	服务器出示证书，由受信任的 CA 签名
完整性	篡改	每条记录带 MAC / AEAD 标签，改一个字节都验不过

所以 HTTPS 不是"一种新协议"，而是 HTTP 的字节流先经 TLS 加密，再交给 TCP。对 HTTP 来说它完全透明。

七、TLS 握手：到底"握"了什么

TLS 握手要解决一个核心难题：双方在一条不安全的信道上，协商出一个只有他们俩知道的对称密钥，同时让客户端确认服务器的身份。下面分别看 1.2 和 1.3。

TLS 1.2：2-RTT，明文握手主体

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Client Server
 │ │
 │ ── ClientHello (支持的 TLS 版本、加密套件、随机数 Rc) ─▶ │
 │ │
 │ ◀── ServerHello (选定套件、随机数 Rs) ───────────────── │
 │ ◀── Certificate (服务器证书) ────────────────────────── │
 │ ◀── ServerKeyExchange (DH 参数，视套件而定) ─────────── │
 │ ◀── ServerHelloDone ─────────────────────────────────── │ ← 第 1 个 RTT 结束
 │ │
 │ ── ClientKeyExchange (DH 公开值) ──────────────────▶ │
 │ ── ChangeCipherSpec ──────────────────────────────────▶ │
 │ ── Finished (已加密，含握手摘要) ──────────────────────▶ │
 │ │
 │ ◀── ChangeCipherSpec ────────────────────────────────── │
 │ ◀── Finished (已加密) ────────────────────────────────── │ ← 第 2 个 RTT 结束
 │ │
 │ ◀═══════ 加密的应用数据（HTTP） ═════════════════════▶ │

握手干了四件事：

协商参数 —— 双方交换支持的版本、加密套件、两个随机数（Rc、Rs）；
验证身份 —— 服务器发证书，客户端用本地信任库验证证书链（见下一节）；
建立共享秘密并派生密钥 —— 以常见的 ECDHE 为例，双方各生成临时密钥对，用本端临时私钥和对端临时公钥算出相同的共享秘密，再结合 Client Random、Server Random 等握手上下文派生会话密钥。证书私钥和 ECDHE 临时私钥都只在本端使用、不会通过网络发送；“私钥永远不上线”并不准确，服务器通常在本机或 HSM 中使用证书私钥完成签名；
确认无误 —— 双方各发一个 Finished，包含整段握手的摘要，确保握手没被篡改。

之后用的对称密钥就是从这里来的。非对称（证书 + DH）只为这一步服务，因为它慢；后续大量数据用对称密钥加密。

TLS 1.3：1-RTT，握手主体被加密

TLS 1.3（RFC 8446，2018）做了大刀阔斧的精简：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


Client Server
 │ │
 │ ── ClientHello (套件、随机数、密钥共享 KeyShare) ────▶ │
 │ （附上客户端的 DH 公开值，不再等） │
 │ │
 │ ◀── ServerHello (套件、随机数、KeyShare) ────────────── │
 │ ▼ 从这条消息之后，所有握手记录全部加密 ▼ │
 │ ◀── {EncryptedExtensions} ─────────────────────────── │
 │ ◀── {Certificate} ──────────────────────────────────── │
 │ ◀── {CertificateVerify} (用证书私钥签名) ───────────── │
 │ ◀── {Finished} ─────────────────────────────────────── │ ← 第 1 个 RTT 结束
 │ │
 │ ── {Finished} ──────────────────────────────────────▶ │
 │ │
 │ ◀═══════ 加密的应用数据（HTTP） ═════════════════════▶ │

相比 1.2，1.3 有三个显著改进：

少一个 RTT —— 客户端在 ClientHello 里就带上密钥共享（KeyShare），服务器第一个回包就能算出密钥、开始加密，握手压到 1-RTT；
握手加密 —— ServerHello 之后的所有消息都加密了，连证书都不再明文暴露（防被动监听窥探服务器证书）；
0-RTT 恢复 —— 如果是复用之前的会话（PSK），客户端可以在 ClientHello 里直接捎带应用数据，连那 1 个 RTT 都省了。代价是 0-RTT 数据不具备完整的前向保密保证，而且可能跨连接被重放，因此只能发送应用明确判定为可安全重放的数据。幂等请求常是候选，但“幂等”不自动等于“重放安全”，仍要结合计费、审计、限额等业务副作用判断。

1-RTT / 0-RTT 看似只是省了一个往返，但在移动互联网和高延迟链路上，每省一个 RTT 都直接转化成更快的首字节时间（TTFB）。HTTP/3 把 QUIC 和 TLS 1.3 揉在一起，很大程度就是为了把这几个 RTT 彻底榨干。

八、证书链与 CA 信任：凭什么信这张证书

握手里客户端要"验证服务器证书"，但这张证书凭什么可信？答案是信任链：

1
2
3
4
5


你的服务器证书 中间 CA 证书 根 CA 证书
example.com ──签发──▶ Let's Encrypt R3 ──签发──▶ ISRG Root X1
 │
 （根证书自签名，预装在
 操作系统 / 浏览器信任库里）

验证过程是沿着链向上找：

服务器在握手里不只发自己的证书，而是发整条链（服务器证书 + 中间 CA 证书）；
客户端用中间 CA 的公钥验证服务器证书的签名 → 验证通过，说明服务器证书确实由该中间 CA 签发；
再用根 CA 的公钥验证中间 CA 证书的签名 → 一路验到根 CA；
根 CA 是自签名 的，它的证书预装在操作系统 / 浏览器的信任库里（Windows、macOS、Firefox、Android 各自维护一份）。只要根在信任库里，这条链就算可信。

信任的根基是"你的设备信任哪些根 CA"。这套体系（PKI，Public Key Infrastructure）把"信任某个网站"简化成"信任几百个根 CA"，而根 CA 再通过中间 CA 把签名能力分级下发。

证书可能出问题：

过期 —— 证书有有效期，过期了浏览器会拦截。线上事故里"证书忘续期"是高频低级错误，运维必须配监控自动续期（Let’s Encrypt + certbot / cert-manager）。
吊销 —— 私钥泄露或站点停业，CA 要把证书提前作废。机制有 CRL（吊销列表，已少用）和 OCSP（在线查状态）；但都偏慢，现代浏览器倾向用 OCSP Stapling（服务器主动把 OCSP 响应钉在握手里）。

为什么要有中间 CA，不让根直接签？因为根私钥是整个体系的命根子，必须离线存放、极少使用。日常签发全交给中间 CA，根只在签发/轮换中间 CA 时才出动——一旦根私钥泄露，整个信任体系崩塌。

小结

HTTP/1.0 一请求一连接、握手开销大；HTTP/1.1 默认 keep-alive、加 Host 头、引入管线化（但几乎没人用）；
HTTP/2 用二进制帧 + 多路复用 + HPACK 干掉了应用层队头阻塞，服务端推送已废弃；但底层仍是 TCP，丢包会卡住整条连接；
HTTP/3 换到 QUIC（UDP），用独立 stream 彻底解决 TCP 队头阻塞，集成 TLS 1.3 实现 1-RTT / 0-RTT 和连接迁移；
HTTPS = HTTP + TLS，TLS 提供加密、身份认证、完整性，对应机密性、真实性、防篡改三个目标；
TLS 1.2 要 2-RTT、握手明文；TLS 1.3 精简到 1-RTT、握手加密、支持 0-RTT（注意重放风险）；
证书靠 CA 信任链 取信——服务器证书 ← 中间 CA ← 根 CA（自签名、预装在设备信任库），信任的根基是"你的设备信哪些根 CA"。

下一篇：TCP/IP（十二）：NAT、DHCP 与地址机制 —— 私网 IP 怎么靠 NAT 出网、为什么家用路由器一个公网 IP 能带几十台设备、DHCP 又是怎么自动分配地址的。

参考：

HTTP/3 — RFC 9114

HTTP/2 — RFC 9113（原 RFC 7540）

TLS 1.3 — RFC 8446

Remove HTTP/2 Server Push from Chrome — Chrome Developers

Introducing Zero Round Trip Time Resumption (0-RTT) — Cloudflare Blog

TCP/IP（十）：DNS——从域名到 IP 的解析

Thu, 04 Jun 2026 10:00:00 +0800

写在前面

前面九篇把物理、链路、网络、传输四层讲透了：网线上的比特怎么成帧、IP 怎么跨网路由、TCP 怎么保证可靠、UDP 怎么图快。从这一篇开始，我们登上最高层——应用层。

应用层的协议很多（HTTP、SMTP、SSH、FTP……），但几乎每一个都绕不开同一个前置动作：拿到目标机器的 IP。用户记不住 93.184.216.34，只记得 example.com；而 IP 可能因为换机房、换云厂商而变。这套"域名 ↔ IP"的翻译系统，就是 DNS（Domain Name System）。它既是应用层协议，又是一个遍布全球的分布式数据库——这一篇就把它讲透。

一、为什么需要 DNS

先想一个没有 DNS 的世界：你想上网，就得在浏览器里敲一串 IP；服务换了 IP，得挨个通知所有用户。这显然不可行。DNS 解决三件事：

人友好 —— www.example.com 比 93.184.216.34 好记；
解耦 —— 域名稳定，IP 可变，迁移机器只改 DNS 记录，用户无感；
负载与高可用 —— 一个域名可以映射到多台机器，DNS 轮询 / 智能调度都能在域名这一层做。

一句话：DNS 是互联网的"通讯录"，把人用的名字翻译成网络层要的 IP 。

二、DNS 的层级结构：一棵全球共享的树

DNS 不是一个巨型数据库（单点会压垮、会被攻击、政治上也不可接受），而是按域名分段、层层授权的分布式数据库。域名的每一个点分隔一段，对应树上的一层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 根 (root, 写作 ".", 通常省略)
 │
 ┌─────────────┼─────────────┐
 com org cn ← 顶级域 TLD (Top-Level Domain)
 │ │ │
 example example com ← 二级域
 │ │
 www mail example ← 三级域 / 子域
 │
 www

每一层由不同的服务器群体负责：

层级	服务器	职责
根域	根服务器（13 组逻辑实例，用 anycast 扩到上千台）	告诉你各 TLD（.com / .org / .cn …）由谁管
顶级域 TLD	TLD 服务器（由注册局运营，如 Verisign 管 .com）	告诉你 `example.com` 这类二级域由谁权威
权威域	权威服务器（域名所有者自建或托管）	给出本域名的最终记录（A / AAAA / MX …）

“13 台根服务器” 是历史限制——受早期 DNS 报文能塞进的 13 个地址约束。今天靠 anycast，这 13 个标签背后是全球几百个站点、几千台机器，任播让请求自动落到最近的一台。

授权是这套树能扩展开的关键：根只管到 TLD，TLD 只管到二级域，二级域再往下可以继续授权（子域委托）。没有任何一台服务器需要知道全部答案，每台只负责自己那一段、并知道"再往下该问谁"。

三、解析流程：一次完整查询走了多远

假设浏览器要访问 www.example.com，完整流程是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


浏览器 / 应用
 │ (1) 需要 www.example.com 的 IP
 ▼
本地解析器 (stub resolver，操作系统内置)
 │ 查本机 DNS 缓存 ── 未命中
 ▼
hosts 文件 (/etc/hosts 或 C:\Windows\System32\drivers\etc\hosts)
 │ (hosts 优先级高于 DNS，命中则直接返回) ── 未命中
 │ (2) 把查询转发出去
 ▼
递归解析器 (recursive resolver，通常 ISP 或 8.8.8.8 / 1.1.1.1)
 │ 查自身缓存 ── 未命中
 │
 │ (3) 问根：www.example.com 在哪？ ──▶ 根服务器
 │ │
 │ ◀── "我不知道，但 .com 归这几台 TLD 管" ──────────── ┘
 │
 │ (4) 问 .com TLD：www.example.com 在哪？ ──▶ TLD 服务器
 │ │
 │ ◀── "我不知道，但 example.com 归这几台权威管" ────── ┘
 │
 │ (5) 问 example.com 权威：www 在哪？ ──▶ 权威服务器
 │ │
 │ ◀── "www.example.com 的 A 记录是 93.184.216.34" ─── ┘
 │
 │ (6) 把答案返回客户端；递归解析器按 TTL 缓存委派与答案
 ▼
浏览器拿到 IP，开始 TCP 握手 → 发 HTTP 请求

几个工程要点：

hosts 文件优先 —— 这就是为什么改 hosts 能"劫持"域名做本地调试，也常被恶意软件篡改。
递归解析器做了绝大多数工作 —— 客户端只问它一次，它要自己去跑 (3)(4)(5) 这条链路。常见的 8.8.8.8（Google）、1.1.1.1（Cloudflare）、223.5.5.5（阿里）就是公共递归解析器。
缓存显著减少权威查询 —— 日常查询往往在浏览器、操作系统或递归解析器命中；递归解析器还会缓存从根 / TLD 获得的委派信息，因此很多查询不必再次访问根服务器。根、TLD、权威服务器并不是把请求逐级转发并各自缓存最终答案的“链路节点”。

四、递归查询 vs 迭代查询

这两个词在书里经常并列出现，混淆点在于"谁负责追到底"：

模式	谁干活	谁返回最终答案	在 DNS 里出现在哪
递归查询 (recursive)	被问的人去追完整条链路	被问的人	客户端 → 递归解析器
迭代查询 (iterative)	问的人自己一级级往下追，被问的只给"下一步去问谁"	问的人自己	递归解析器 → 根/TLD/权威

所以一次解析其实是 “客户端对解析器递归，解析器对权威链路迭代” 的组合。解析器拿到客户端的递归请求后，自己变成那个一级级追问的人（迭代），最终把答案递归地交回给客户端。

一套 DNS 软件甚至同一台机器可以同时承担权威和递归角色，但生产环境通常会分离职责并严格限制递归访问。公网权威服务一般不为任意客户端递归查询；递归解析器则代表获准客户端向权威体系发起非递归查询。若把递归能力无访问控制地暴露到公网，就可能成为开放解析器并被滥用于 DNS 放大攻击。

五、DNS 记录类型：不只是 IP

DNS 存的远不止"域名 → IP"一种映射，而是一张张资源记录（Resource Record, RR）。每条记录都有类型、域名、值和 TTL。常见类型：

类型	全称	作用	示例
A	Address	域名 → IPv4 地址	`www.example.com. IN A 93.184.216.34`
AAAA	IPv6 Address	域名 → IPv6 地址（四个 A，因为 IPv6 地址是 IPv4 的四倍长）	`www.example.com. IN AAAA 2606:2800:220:1:...`
CNAME	Canonical Name	别名，把一个域名指向另一个域名（常用于 CDN / 别名）	`blog.example.com. IN CNAME example.github.io.`
MX	Mail Exchange	收邮件的服务器，带优先级（数字越小越优先）	`example.com. IN MX 10 mail.example.com.`
NS	Name Server	这个域由哪台权威服务器管	`example.com. IN NS ns1.example.com.`
TXT	Text	任意文本，常用于域名所有权验证、SPF / DKIM / DMARC 防伪造	`example.com. IN TXT "v=spf1 -all"`
SOA	Start of Authority	一个区的权威元信息：主服务器、管理员邮箱、序列号、刷新/重试/过期时间、最小 TTL	每个 zone 必有一条

几个容易踩的细节：

CNAME 不能和其他记录共存 —— 同一域名要么是别名（CNAME），要么有自己的 A / MX 等记录，不能既要又要；根域（zone apex，如 example.com 本身）尤其不能用 CNAME，这就是所谓的 CNAME flattening / ANAME / ALIAS 记录要解决的问题。
MX 的优先级 —— 数字小者优先。同等优先级的两条 MX，收件方会随机挑，可做简单负载均衡。
NS 决定授权边界 —— 子域一旦在父域里写了 NS 记录，就等于把该子域委托出去，之后父域不再回答它的细节。

六、缓存与 TTL：为什么改了 DNS 不立刻生效

DNS 能扛住全球规模，缓存功不可没。最终答案可能被浏览器、操作系统和递归解析器缓存；递归解析器还会缓存 NS、A / AAAA 等委派相关信息：

1

浏览器 DNS 缓存 → 操作系统解析器缓存 → （路由器缓存） → 递归解析器缓存 → ……

每条缓存能留多久，由记录的 TTL（Time To Live，秒） 决定。TTL 是域名所有者在权威服务器上设的"建议保质期"。

这就解释了 DNS 改动的一个经典坑：改完记录，总有部分用户还在访问老 IP。 因为各级缓存里的老记录要等自己的 TTL 到期才会刷新，而不同用户命中的递归解析器各不相同、缓存剩余时间也不同。所以线上切换 IP 之前，业内惯用做法是：

提前把 TTL 调小（比如从 3600s 降到 60s），等一个旧 TTL 周期过去；
再做 IP 切换，这样最多 60s 内全网收敛；
切稳之后再把 TTL 调回大值（减少查询压力）。

TTL 是个权衡：大 TTL 省查询、抗 DNS 抖动，但切换慢；小 TTL 切换快，但查询量大、对权威压力高 。CDN / 高频切换场景常用几十秒；稳定服务常用小时级。

七、安全与隐私：DNSSEC、DoH、DoT

传统 DNS 有两个先天缺陷：

明文传输 —— 查询走 UDP 53（或 TCP 53），链路上任何人都能看到你查了什么域名，甚至篡改返回的 IP；
无身份校验 —— 解析器拿到一个 IP，无法验证它是不是权威真正签发的，中间人塞个假 IP 你也信。

两套机制分别补这两个洞，别混为一谈：

机制	解决什么	怎么做	端口
DNSSEC	数据真实性与完整性（防篡改、防伪造）	对每条记录加密码学签名，解析器沿信任链验证签名	53（不改传输）
DoT（DNS over TLS）	传输加密（防窃听）	用 TLS 包裹 DNS 查询	853
DoH（DNS over HTTPS）	传输加密 + 混在 HTTPS 流量里（更难与普通 HTTPS 区分）	用 HTTPS 传 DNS 报文，可承载于 HTTP/2 或 HTTP/3 等版本	443

关键区分：DNSSEC 签的是"数据对不对"，DoT / DoH 加密的是"传的过程看不看得到" 。两者正交，可以同时用（DoH + DNSSEC 验证）。DNSSEC 不提供机密性——签名让数据可被验证，但查询内容依旧明文；DoT / DoH 提供机密性，但如果上游解析器作恶，它返回的假 IP 你没法自己验（所以有人坚持要在客户端做 DNSSEC 验证）。

一个现实工程点：用了 DoH / DoT 之后，企业内网的 DNS 过滤、家长的域名黑白名单都会失效——因为查询绕过了本地解析器直接走加密通道去公网解析器了。这是"隐私"和"可控"的天然张力。

八、动手验证：dig 与 nslookup

讲了一堆原理，落到命令上最直观。dig（Linux/macOS 自带，Windows 可装 BIND 工具）和 nslookup（全平台自带）是最常用的两个：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 基本查询：看 www.example.com 的 A 记录（dig 默认查 A）
dig www.example.com

# 指定记录类型
dig example.com MX # 看邮件服务器
dig example.com NS # 看权威服务器
dig example.com TXT # 看 SPF / 验证记录
dig example.com AAAA # 看 IPv6

# 看完整解析过程（+trace 从根开始迭代追问，相当于手动模拟递归解析器）
dig +trace www.example.com

# 指定用某个解析器
dig @8.8.8.8 www.example.com

dig +trace 是理解第二节那棵树最好的工具——它会依次打印根、TLD、权威的应答，把整条授权链摆给你看。排 DNS 问题时，先用 dig 看记录对不对，再看是不是缓存（换个解析器 @1.1.1.1 对比），最后用 +trace 看授权链有没有配错。

小结

DNS 是应用层的分布式数据库，按域名分段、层层授权，没有任何一台服务器需要知道全部答案；
一次解析通常是 “客户端请求递归解析器、解析器逐级查询权威体系” 的组合；客户端、本机和递归解析器可按 TTL 缓存结果，解析器也会缓存委派信息；
记录类型不只是 A/AAAA——CNAME 别名、MX 带优先级的邮件、NS 决定授权边界、TXT 承载验证信息、SOA 是区的元信息；
改 DNS 不立刻生效 是各级 TTL 缓存的必然结果，切换前先调小 TTL 是标准做法；
DNSSEC 防篡改（签名），DoT / DoH 防窃听（加密） ，两者正交、可叠加。

下一篇：TCP/IP（十一）：HTTP、HTTPS 与 TLS —— 拿到 IP 之后，浏览器怎么建连、发请求、传页面；HTTP 从 1.0 到 3 演进了什么；HTTPS 套的那层 TLS 又是怎么握手的。

参考：

RFC 1034 — Domain Names: Concepts and Facilities

RFC 1035 — Domain Names: Implementation and Specification

DNSSEC — Wikipedia

DNS over TLS vs. DNS over HTTPS — Cloudflare

How DNS works (交互式图解)

TCP/IP（九）：TCP 进阶——SACK、Nagle、keepalive 与端口复用

Tue, 02 Jun 2026 10:00:00 +0800

写在前面

前两篇讲完了 TCP 的"宏观调控"——连接管理、可靠性、流量控制、拥塞控制。但 TCP 还有一批很常用、却常被忽略的"细节机制" ：它们大多是默认开启或默认关闭的开关，在文档里不起眼，却直接决定了一个连接在高延迟、小包、长连接、服务器重启这些场景下的真实表现。一个 SACK 没开、一个 Nagle 没关、一个端口没复用，可能就是线上延迟毛刺或"Address already in use"的根因。

本篇逐个讲清这些进阶机制的原理和"什么时候开 / 关"，最后把目光投向正在替代 TCP 的 QUIC 和多路径 MPTCP。

一、SACK：选择确认

累积确认的痛点

TCP 的 ACK 是累积的：ACK 号 N 表示"序号 N 之前的所有数据都收到了"，对 N 之后的乱序数据则只字不提。一个窗口里如果丢了多个段，发送端只看 ACK 根本不知道后面哪些到了、哪些没到，只能保守地从 N 开始一个个重传 ——哪怕其中很多段接收端早就收到了。

举例，发送端发了 5 个段（S1~S5），S2 丢了：

1
2
3
4


发送: S1 S2 S3 S4 S5
 ↓ 丢
接收: S1 ✗ S3 S4 S5 （S3/S4/S5 乱序到达）
ACK : ACK S2 重复 ACK S2 重复 ACK S2 ... （累积 ACK 一直卡在 S2）

没有额外信息时，发送端只知道"S2 起还没齐"，S3/S4/S5 到底到没到无从判断 ，最坏情况会把 S2~S5 全重传一遍。

SACK 怎么解决

SACK（Selective ACKnowledgment，RFC 2018）在 TCP 头部选项里增加一个 SACK 选项，让接收端额外报告"我这边已经收到的、但不连续的数据块" ：

1
2
3


SACK 选项内容示例（接上例）：
 累积 ACK 号 = S2 起点 （S1 已确认，S2 起待确认）
 SACK 块 1 = [S3 起点, S6 起点) ← 告诉发送端：S3 S4 S5 我都收到了

发送端拿到 SACK 就知道只有 S2 真的丢了 ，只重传 S2，S3/S4/S5 不必重发。一个窗口里丢多个段时，SACK 能在一个 RTT 内把它们一次性补齐，而不是像 NewReno 那样每个丢包耗一个 RTT。

每个 SACK 选项最多能携带 3~4 个不连续块（受 TCP 选项字段 40 字节的限制，开了时间戳后通常是 3 块）。还有个扩展叫 D-SACK（RFC 2883）：接收端可以用它告诉发送端"你重传的那段我之前已经收过了"，帮助发送端区分真丢包和乱序。

该不该开：几乎总是该开。SACK 在现代操作系默认就是开启的 （Linux 的 net.ipv4.tcp_sack = 1），它在有丢包时显著减少不必要的重传。关掉它基本只在和一些极古老设备的兼容场景里才考虑。

二、Nagle 算法、延迟 ACK 与 TCP_NODELAY / CORK

Nagle 算法：小包合并

很多交互式应用（Telnet、SSH、游戏）会频繁发 1 字节、几字节的小包，每个小包加上 TCP/IP 头有 40+ 字节，开销极大。Nagle 算法（RFC 896）规定：

如果连接上有尚未被确认 的小段数据在途，就先别发新的小段 ，攒着；等要么"前面的数据被 ACK 了"，要么"攒够一个全尺寸段（MSS）"，再一起发。

效果是把零散小包合并成大包，减少头部开销。多数系统默认开启 Nagle 。

和延迟 ACK 的冲突

延迟 ACK（Delayed ACK，RFC 1122）是接收端的优化：收到数据后不立刻回 ACK，最多攒两个全尺寸段、或延迟约 200ms 再回 ，好让 ACK 能捎带反向数据、或合并多个 ACK。

这两个优化单独看都合理，叠在一起却会打架 ，产生著名的"40ms（或更长）毛刺"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


场景：一端连续写入两个小段，第一段尚未被确认

 发送端 接收端
 │ ── 第一个小段 ────────────→ │
 │ │ 暂不立即回 ACK（延迟 ACK）
 │ 应用很快又写入第二个小段 │
 │ Nagle 发现本端已有未确认小段 │
 │ 暂缓发送第二段 │
 │ │
 │ ◀──────── 延迟 ACK ───────── │
 │ ── 第二个小段 ──────────────→ │
 ↓ ↓
 第二段被额外压住一个延迟 ACK 周期

本质是：Nagle 在等待本端先前已发送数据的 ACK，而接收端正按延迟 ACK 策略暂缓这个 ACK；其间本端后续的小段就可能被多压一个延迟 ACK 周期。Nagle 不会等待“本端对对方数据的 ACK”。

怎么关：TCP_NODELAY 与 TCP_CORK

选项	作用	何时用
`TCP_NODELAY`	关掉 Nagle ，小包立即发	低延迟、请求-响应、交互式：SSH / RDP / 游戏 / HTTP/2 多路复用 / 数据库短查询，基本都该开
`TCP_CORK`（Linux）	反向操作：把连接"塞住"，攒到 MSS 或显式"拔塞"才发	批量场景：先写头部、再写 body，希望它们合到一个包发出去，`write(headers); write(body);` 后再拔塞

经验法则：

低延迟 / 交互场景，开 TCP_NODELAY （关掉 Nagle）。代价是多几个小包，但换来可预测的低延迟。绝大多数 RPC 框架、数据库驱动、HTTP 客户端默认就设了 TCP_NODELAY。
大批量传输、希望合并发送的，用 TCP_CORK ，并记得发完拔塞。
不要"既不开 NODELAY 也不开 CORK"地裸跑一个请求-响应协议——Nagle + 延迟 ACK 的毛刺会让你排查到怀疑人生。

三、TCP keepalive：探活死连接

它解决什么问题

连接建立后，如果对端进程崩溃、被 kill -9、或者网络中间的链路静默断开（没发 FIN/RST），发送端会一直以为连接还在——直到下次写数据时才发现对方已不在，这中间可能空等几个小时甚至无限期。keepalive 就是 TCP 层的"定期探活"：连接空闲超过阈值后，发一个空探测包，看对端还回不回。

Linux 默认参数（保守得离谱）

参数	默认值	含义
`tcp_keepalive_time`	7200 秒（2 小时）	连接空闲多久后开始发第一个探测
`tcp_keepalive_intvl`	75 秒	相邻探测之间的间隔
`tcp_keepalive_probes`	9 次	连续多少次探测失败就判定连接死了

也就是说，默认情况下一条死连接要等 2 小时 + 9×75 秒 ≈ 2 小时 11 分 才会被 TCP 层发现。对绝大多数应用这个延迟毫无意义。可在 /proc/sys/net/ipv4/ 改全局默认，或对单个 socket 用 setsockopt + TCP_KEEPIDLE / TCP_KEEPINTVL / TCP_KEEPCNT 单独设。

该用 TCP keepalive 还是应用层心跳

多数长连接服务（数据库连接池、消息队列、RPC 长连接）倾向于自己做应用层心跳 ，而不是裸依赖 TCP keepalive：

TCP keepalive 只能告诉你"TCP 层通不通" ，不能告诉你"对端进程是否真的在干活"（比如对方线程死锁了，TCP 连接依然在）。
应用层心跳（定时 ping / 业务层探活）能穿越 HTTP 代理、负载均衡、NAT 这些TCP keepalive 看不到的中间层 ——很多中间设备会独立维护连接状态，TCP 探活可能根本走不到对端。
心跳间隔可以根据业务设（通常 30s~60s），比 2 小时合理得多。

建议：长连接、对断连敏感的场景，开 keepalive 并把参数调小（如 idle=60s、intvl=10s、probes=3），同时配应用层心跳 兜底；纯短连接或无所谓的场景可以不管。

四、SO_REUSEADDR / SO_REUSEPORT：端口复用

排障时人人都见过 Address already in use——上次服务没退干净、端口还占着。这两个 socket 选项就是解决"端口能不能重新绑"的，但它们不是一回事 。

SO_REUSEADDR

最经典用途：允许新 socket 绑定一个仍处于 TIME_WAIT 状态的端口 。服务重启时，上一条连接可能还在 2MSL 的 TIME_WAIT 里占着端口，没这个选项就得干等几十秒到两分钟。设了 SO_REUSEADDR 就能立刻 bind 成功，实现快速重启。

主要解决 TIME_WAIT 占端口的问题。
在 Linux 上不允许 两个 socket 同时绑定完全相同的 IP:port。

注意：TIME_WAIT 出现在主动关闭 连接的一方。对服务器而言，通常是客户端主动断；但服务器若主动关闭（如短连接服务端关连接），它的端口也会进 TIME_WAIT。SO_REUSEADDR 让这些端口的复用不被卡住。客户端侧用固定源端口重连时同理受益。

SO_REUSEPORT（Linux 3.9+，2013）

比 SO_REUSEADDR 强得多：允许多个 socket 同时绑定完全相同的 IP:port ，内核把进来的连接在这些 socket 之间做负载均衡 。

典型用途：

零停机重启 ：新进程绑定同一端口、起来接流量后，老进程再优雅退出。
多进程 / 多线程监听同一端口 ：nginx、Envoy 等用多个 worker 各持一个监听 socket，内核把新连接均匀分发，避免"惊群"。

1
2
3
4


 SO_REUSEPORT
 进程 A (socket 1) ┐
 进程 B (socket 2) ├─ 都 bind 同一个 IP:80 ── 内核对入站连接做负载均衡
 进程 C (socket 3) ┘

特性	SO_REUSEADDR	SO_REUSEPORT
绑定 TIME_WAIT 端口	可以	可以
同 IP:port 多 socket 共存	不行（Linux）	可以
内核负载均衡	无	有（Linux）
可移植性	较通用	差（Linux / BSD 语义不同，Windows 的 SO_REUSEADDR 行为另类）

一句话：SO_REUSEADDR 解决"端口占着没法 bind"，SO_REUSEPORT 解决"多个进程同时监听同一端口" 。

五、展望：QUIC 与 MPTCP

TCP 已经四十多岁了，内核里固化、中间盒识别、握手慢、队头阻塞这些问题根上很难改。两条"另起炉灶"的演进路线值得关注。

QUIC：UDP 之上的现代传输

QUIC（RFC 9000，2021）跑在 UDP 之上，把传输层 + TLS 1.3 加密揉在一起 重新设计，是 HTTP/3 的传输基础。它解决了 TCP 的几个老毛病：

流级队头阻塞：HTTP/2 在单条 TCP 上多路复用，一个包丢了会卡住所有流（TCP 不知道流的概念）。QUIC 在每条流上独立做丢包恢复 ，一条流丢包不影响其他流。
握手慢：TCP 三次握手 + TLS 握手要 2~3 个 RTT；QUIC 把传输握手和 TLS 握手合并，首次连接 1-RTT、重连甚至 0-RTT 。
连接迁移：QUIC 用连接 ID 而非"四元组（IP+端口）“标识连接，手机从 Wi-Fi 切到 4G / 5G，IP 变了连接不断。
拥塞控制、丢包恢复在应用层实现，可以快速迭代（BBR 等算法在 QUIC 栈里更容易铺开）。

代价：跑在 UDP 上，某些防火墙 / NAT 对 UDP 不友好；CPU 开销比内核态 TCP 高（但在持续优化）。

MPTCP：多路径 TCP

MPTCP（RFC 8684，2020）让一条 TCP 连接同时跨越多条物理路径 ——比如手机同时用 Wi-Fi 和蜂窝网络收发数据。好处是带宽聚合、路径冗余和无缝切换。Linux 内核 5.6（2020）起原生支持。它对上层应用基本透明，但端到端要求两边都支持，部署普及度还有限。

小结

SACK（RFC 2018）让接收端报告已收到的乱序数据块，发送端只补丢的、不瞎重传；默认该开。
Nagle 攒小包、延迟 ACK 压 ACK，两者叠加会产生延迟毛刺；低延迟场景用 TCP_NODELAY 关掉 Nagle，批量合并发送用 TCP_CORK 。
TCP keepalive 探活死连接，默认 2 小时才开始探测、约 2h11m 才判死，太保守；长连接建议调小参数并配应用层心跳 。
SO_REUSEADDR 解决 TIME_WAIT 占端口、SO_REUSEPORT（Linux 3.9+）让多进程同时监听同一端口并内核负载均衡。
QUIC（UDP 之上、流级无队头阻塞、1/0-RTT、连接迁移）是 HTTP/3 的传输基础；MPTCP 让一条连接跨多条路径。

下一篇：TCP/IP（十）：DNS —— 域名是怎么一步步解析成 IP 的，递归 / 迭代查询、层级与缓存、常见记录类型，以及 DoH / DoT / DNSSEC。

参考：

RFC 2018 — TCP Selective Acknowledgment Options

RFC 896 — Congestion Control in IP/TCP Internetworks（Nagle 算法）

RFC 1122 — Requirements for Internet Hosts（Delayed ACK）

RFC 9000 — QUIC: A UDP-Based Multiplexed Transport

RFC 8684 — TCP Extensions for Multipath Operation

SO_REUSEADDR vs SO_REUSEPORT — Stack Overflow

TCP/IP（八）：TCP 拥塞控制——从慢启动到 BBR

Sun, 31 May 2026 10:00:00 +0800

写在前面

上一篇把 TCP 的可靠性机制讲完了：序号与确认保证"发出去的都到了"，超时重传和快重传补上丢失的段，滑动窗口和流量控制让发送方不会淹没接收方。但这里有个被刻意回避的问题：如果丢包不是因为接收方缓存满了，而是中间网络本身堵了呢 ？

流量控制只盯着两端的收发能力，对中间路径一无所知。一个连接如果只顾自己往里灌数据，路由器缓冲区一旦撑满就开始丢包，丢包触发重传，重传又加剧拥堵——这就是 1986 年著名的"互联网拥塞崩溃"（congestion collapse）的成因。本篇就讲 TCP 怎么主动探测网络的承受能力 ，也就是拥塞控制（congestion control）的四个经典算法，以及从 Reno 到 BBR 的思路演进。

一、流量控制 vs 拥塞控制：保护对象不同

这是最容易混的一对概念，先一张表说清：

	流量控制 Flow Control	拥塞控制 Congestion Control
保护谁	接收端（别撑爆接收缓存）	中间网络（别压垮路由器 / 链路）
信号来自哪	接收端通过 ACK 头里的窗口字段（rwnd）告诉发送端	发送端自己猜（没人直接告诉你网络堵没堵）
窗口	rwnd（接收窗口）	cwnd（拥塞窗口，发送端自己维护）
关系	协议里明文协商	纯靠发送端算法估算

一句话：流量控制是接收端"明示"你慢一点，拥塞控制是发送端"自觉"慢一点 。两者并不互斥，实际能往网络里塞多少数据，取两者的较小值（见下一节）。

二、两个窗口：cwnd 与 rwnd

发送端在任一时刻"在途未确认"的数据量（FlightSize），不能超过两个窗口的较小值：

1

实际发送上限 = min(cwnd, rwnd)

cwnd（congestion window，拥塞窗口）：发送端自己估算的"网络能吞多少"，是拥塞控制的核心状态变量，动态变化。
rwnd（receive window，接收窗口）：接收端在 ACK 报文里捎带的"我还能收多少"，上一篇流量控制讲过。

1
2
3
4
5
6
7
8
9


 发送端能发多少？
 │
 ┌───────────┴───────────┐
 │ │
 cwnd ── 网络承受力 │
 │ │
 └──────── min ──────────┘
 │
 rwnd ── 接收端承受力

rwnd 是被动接收的（接收端说了算），而 cwnd 完全由发送端的拥塞控制算法自己驱动——下面四个算法就是围绕"cwnd 怎么涨、怎么砍"展开的。

三、经典四算法：慢启动、拥塞避免、快重传、快恢复

这是 RFC 5681 定义的 TCP 拥塞控制基本盘，几乎所有教科书都按这套讲（Reno / NewReno 实现）。核心是两个变量：cwnd 和 ssthresh（slow start threshold，慢启动阈值）。

1. 慢启动（Slow Start）：指数增长

连接刚建立，发送端对网络一无所知，先"小心翼翼地试探"：

初始 cwnd = IW（Initial Window）。老协议是 1 个 MSS，RFC 6928 把它提到 IW10 = min(10×MSS, 14600 字节) ，现代 Linux 默认就是 IW10。
每收到一个确认 ACK，cwnd 增加 1 个 MSS。
一个 RTT 内能收到的 ACK 数 ≈ cwnd / MSS，所以经过一个 RTT 后 cwnd 大约翻倍——指数增长 （1 → 2 → 4 → 8 → …）。

“慢"启动并不慢，它只是"起步慢、加速快”。指数增长会很快把网络塞满，所以必须有个刹车——就是 ssthresh：

当 cwnd ≥ ssthresh 时，退出慢启动，进入拥塞避免。

2. 拥塞避免（Congestion Avoidance）：线性增长

进了拥塞避免，发送端认为已经接近网络容量，改成"谨慎试探"：

每经过一个 RTT，cwnd 才增加 1 个 MSS（实现上：每个 ACK 让 cwnd 加 SMSS×SMSS/cwnd）。
也就是 线性增长 ，和慢启动的指数增长形成鲜明对比。

为什么从指数切到线性？因为指数增长以 2 的幂次逼近极限，越往后越容易瞬间冲破网络容量；线性增长让 cwnd 在接近容量时缓慢上探，给网络留缓冲。

3. 快重传（Fast Retransmit）：3 个重复 ACK

慢启动和拥塞避免回答"cwnd 怎么涨"，那什么时候砍？最直观的信号是超时（RTO），但等 RTO 太慢（往往要几百毫秒到秒级）。快重传用一个更早的信号：重复 ACK 。

接收端收到失序的段会立即回一个重复 ACK（ACK 号还是上次那个最大的连续确认号）。
发送端如果连续收到 3 个重复 ACK ，就判定中间那个段丢了，不等超时、立即重传 丢失的段。
为什么是 3 个？因为单个重复 ACK 可能只是乱序（网络重排），连收 3 个基本能确认是真的丢了。

4. 快恢复（Fast Recovery）：砍半不归零

快重传之后 cwnd 怎么调？这里有个关键区分，取决于"丢包是哪种信号触发的"：

超时（RTO）：认为网络出现了更严重的拥塞信号 → ssthresh 按规范根据 FlightSize 计算，cwnd 降到不超过 1 SMSS（一个完整报文段），再从慢启动增长。这里不是降到 0，也不等于恢复到现代常见的 IW10。
快重传（3 dup ACK）：网络其实还能传（毕竟重复 ACK 说明后面的段都到了），只是局部丢包 → 不必回到慢启动，只把 cwnd 砍半。

快恢复的具体步骤（Reno）：

1
2
3
4
5
6
7
8
9


收到第 3 个重复 ACK 时：
 1. ssthresh = max(cwnd / 2, 2) # 新阈值砍半
 2. 重传那个丢失的段 # 快重传
 3. cwnd = ssthresh + 3 # 临时抬高 3 个 MSS
 #（3 个 dup ACK 意味着有 3 个段已离开网络）
 此后每再收到一个重复 ACK：cwnd += 1 # 窗口膨胀，允许继续发新数据
 直到收到一个新的（非重复）ACK：
 cwnd = ssthresh # 膨胀结束，回到阈值
 进入拥塞避免（线性增长） # 注意：不回慢启动

这就是"快恢复"的含义：砍半，但不归零 ——比超时那条路温和得多。

ssthresh 的角色

ssthresh 是慢启动和拥塞避免的分水岭，本身是动态的：

初始值通常很大（或设为任意大）。
每次发生拥塞（快重传或超时）就更新：ssthresh = 当前 cwnd 的一半。
于是 cwnd 在网络抖动中不断"涨上去 → 砍一半 → 再涨"，ssthresh 像个跟随学习的天花板。

四、cwnd 随时间变化示意图

把上面几个阶段画在一张图上，cwnd 的典型轨迹长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


 cwnd
 ↑
 │ ╮ 收到 3 个重复 ACK
 │ ╭─╯ → 快重传 + 快恢复
 │ ╭─╯ ssthresh = cwnd/2
 │ ╭─╯ cwnd 落回 ssthresh
 │ 指数增长 ╭─╯ 后继续线性(拥塞避免)
 │(慢启动) ╭─╯
 │ ╭─ ← cwnd ≥ ssthresh：转为线性增长
 │ ╭─╯
 │ ╭─╯
 │ ╭─╯
 └─┴──────────────────────────────────→ 时间
 建立连接

如果是超时而不是快重传，就把图上的“落到 ssthresh”换成“cwnd 落到 1 SMSS，再重新走指数慢启动”。看懂这张图就抓住了经典 Reno 的主线：指数上探 → 遇阻降低窗口 → 线性再上探。两条下降路径里，快重传后的恢复较温和，超时后的窗口收缩更激进，但都不是把 cwnd “归零”。

五、丢包作为拥塞信号的局限

上面整套 Reno 逻辑，都是把丢包当作拥塞的唯一信号 。这在 1980 年代的网络里成立——路由器缓存小，满了就丢。但在现代网络里这套假设出了三个问题：

1. Bufferbloat（缓冲膨胀）

现代路由器 / 交换机缓冲区都很大（为了尽量不丢包）。基于丢包的算法会一直加 cwnd，直到把缓冲区填满才触发丢包——而这意味着每个包都要在满缓冲区里排上几百毫秒，延迟暴涨。结果就是：吞吐看着不低，但延迟和抖动高得离谱 。这就是著名的 Bufferbloat 问题，对交互应用（SSH、游戏、视频通话）是灾难。

2. 把随机丢包误判为拥塞

无线网络（Wi-Fi、4G / 5G）会因信号波动随机丢包，这根本不是"网络堵了"。但 Reno / Cubic 照样砍 cwnd，导致无线场景下吞吐上不去。

3. 高 BDP 链路利用不足

长肥管道（卫星、跨洲骨干）的"带宽 × 延迟"（BDP）很大，基于丢包的算法要"填满"整条管道才能逼近满速，而一旦丢包砍半又要很久爬回来。

Reno 的直接改进是 Cubic（Linux 2.6.19 起，2006 年至今的默认算法）：把"砍半后线性恢复"换成一条三次函数曲线，恢复更快、对高 BDP 更友好。但它依然是基于丢包的 ，根本局限没动。

六、BBR：基于带宽与 RTT 的模型

BBR（Bottleneck Bandwidth and RTt）是 Google 在 2016 年提出的拥塞控制算法（Linux 4.9 起可选）。它换了个根本思路：不把丢包当唯一信号，而是直接建模网络的带宽和延迟 。

核心思路

BBR 持续测量并维护两个核心估计量：

BtlBw（Bottleneck Bandwidth）：瓶颈链路的可用带宽——发送端通过观察 ACK 的到达速率（单位时间被确认的数据量）取一个滑动窗口内的最大值。
RTprop（Round-trip propagation time）：链路的最小往返传播时延——在没有排队的情况下测到的 RTT 最小值。

两者的乘积就是 BDP（Bandwidth-Delay Product），也就是"把管道填满但不溢出"的理想在途数据量：

1

理想 cwnd ≈ BtlBw × RTprop = BDP

BBR 以 BtlBw 和 RTprop 为模型基础，用 **pacing（按速率平滑发送）**和拥塞窗口上限控制在途数据，并通过不同增益阶段周期性探测带宽。它的目标是在维持高吞吐的同时减少不必要的排队，但在途量并不恒等于一个 BDP，也不能保证缓冲区始终“半空”或“近空”。

和 Reno / Cubic 的根本区别

	Reno / Cubic（基于丢包）	BBR（基于模型）
主要控制依据	丢包（及 ECN）	带宽、RTT 模型；新版本也参考丢包 / ECN
发送控制	主要调整 cwnd	pacing + cwnd 上限 + 周期性探测
延迟表现	容易在深缓冲路径积累排队	目标是减少持续排队，但不保证所有路径都更低延迟
随机丢包	照砍 cwnd（误判）	不轻易砍
适用场景	传统有线、公平性友好	高 BDP、长距、无线、低延迟

现状

BBR 在 Linux 上通过 sysctl net.ipv4.tcp_congestion_control=bbr 开启，需要内核 ≥ 4.9。
主流 Linux 发行版的默认仍是 Cubic ，BBR 作为可选；部分对吞吐 / 延迟敏感的场景（CDN、跨洲链路、Google 内部、YouTube）已大规模启用 BBR。
BBR 自身也在演进（v1、v2、v3），v2 起更注重和 Cubic 的公平性、对丢包 / ECN 做出更克制的反应。

一句话总结 BBR：与其等"丢包"这个事后信号，不如主动测出网络的真实容量 。

小结

流量控制 保护接收端（rwnd），拥塞控制 保护网络（cwnd），实际发送上限 = min(cwnd, rwnd)。
经典四算法：慢启动（指数增长）→ 越过 ssthresh 进入拥塞避免（线性增长）→ 丢包时快重传（3 个重复 ACK）→ 快恢复（窗口明显降低但不回到 1 SMSS）；超时后则把 cwnd 降到不超过 1 SMSS，再回慢启动。
ssthresh 是慢启动与拥塞避免的分水岭，每次拥塞后动态更新。
Reno / Cubic 主要依赖丢包（也可结合 ECN）感知拥塞，在 Bufferbloat、随机丢包和高 BDP 场景可能遇到局限。
BBR 主要用带宽（BtlBw）与最小 RTT（RTprop）建模，通过 pacing 与窗口上限控制发送；它不以丢包作为首要信号，但新版本仍会参考丢包 / ECN，实际效果取决于路径与版本。

下一篇：TCP/IP（九）：TCP 进阶 —— SACK 选择确认、Nagle 与延迟 ACK 的冲突、keepalive 探活、SO_REUSEADDR / REUSEPORT 端口复用，以及 QUIC 与 MPTCP 简介。

参考：

RFC 5681 — TCP Congestion Control

RFC 6928 — Increasing TCP’s Initial Window

BBR Congestion Control — IETF Draft

TCP Congestion Control — Wikipedia

Bufferbloat — Wikipedia

TCP/IP（七）：TCP 可靠性——序号、重传与滑动窗口

Fri, 29 May 2026 10:00:00 +0800

写在前面

上一篇把 TCP 的连接生命周期走了一遍：握手建状态、挥手拆状态、中间一张 11 状态的状态机。但建立连接只是搭好了一座桥，真正的难题在桥上：IP 层是不可靠的——包会丢、会乱序、会重复、会损坏。TCP 怎么在这堆"不靠谱"之上，给应用层交付一条按顺序、不丢、不重、不出错的字节流？

这一篇就来拆 TCP 最核心的能力——可靠性。它靠三件事撑起来：给每个字节编号（序号）、收到就回执（确认）、丢了就补（重传） 。围绕这三件套，再配上滑动窗口让"等确认"这件事可以批量进行，TCP 才既可靠又不会慢到没法用。

文末会把流量控制讲清——它是收发两端之间"别发太快压垮我"的协调；和下一篇要讲的拥塞控制（“别发太快压垮网络”）是两回事，这一篇先把边界划清楚。

一、不可靠的 IP 之上，如何造出可靠

IP 层是"尽力而为"（best-effort）的：路由器拥塞了就丢包、链路抖动了就乱序，IP 自己一概不负责。TCP 要做的，就是在应用看来"假装"这些都没发生。它的工具箱只有三件：

序号（Sequence Number）：给发送的每个字节编个号，接收端据此去重、排顺；
确认（Acknowledgment）：接收端收到数据后回个 ACK，告诉发送端"我到这里了"；
重传（Retransmission）：发送端等不到确认就再发一次。

这套思路有个学名：ARQ（Automatic Repeat reQuest，自动重传请求） 。下面先看序号和确认怎么用，再看 ARQ 有哪几种、TCP 选了哪种。

二、字节流、序号与确认号

TCP 传的不是"一条条消息"，而是连续的字节流。序号针对的是字节，不是报文段：

发送端把自己要发的数据看成一长串字节，给每个字节一个编号；TCP 头里的序号字段，表示这个报文段里第一个字节的编号。
初始序号（ISN）不是 0，而是握手时协商的随机值——上一篇文章里那个 seq=x。

举个例子，假设 ISN = 1000：

1
2


发送的字节流： [1000 1001 1002 ... 1023] [1024 ... 2047] [2048 ...]
 └── 第一个段，seq=1000 ──┘ └ seq=1024 ──┘

确认号：累计确认

TCP 的确认号含义是：我下一个期望收到的字节编号。换句话说，“这个编号之前的所有字节我都收到了”——这叫累计确认（cumulative ACK）。

延续上例，接收端收到 seq=1000、长度 1024 字节的段后，回：

1

ACK, ack = 1000 + 1024 = 2024 # "2024 之前的都收到了，给我 2024"

累计确认的好处：中间丢一个，后面的 ACK 照样能回来，发送端看确认号就能推断出哪里断了；坏处：接收端乱序到达的段没法直接确认（ACK 还是只回"按顺序连续到哪了"），这部分后面 SACK 再补。

SYN 和 FIN 虽然不携带用户数据，但各占一个序号（上一篇握手 / 挥手里 ack=x+1、ack=u+1 就是这个原因），这样它们也能被确认、能被重传，语义统一。

三、ARQ 的三种思想：停等 → 回退 N 步 → 选择重传

“发一段、等确认、丢了重发"这件事，可以做得粗，也可以做得细。经典的三种思想：

策略	发多少再等	丢了怎么办	信道利用
停等（Stop-and-Wait）	发 1 段，等 ACK	重发那 1 段	极低（一来一回只能发一段）
回退 N 步（GBN）	一次发 N 段（窗口）	从丢失段起，后面全部重发	较高，但重发浪费
选择重传（SR）	一次发 N 段	只重发丢失的那段	最高，但实现复杂

停等是教科书的起点，但一次只在途一段，在跨地域高延迟链路上等于把带宽饿死。
回退 N 步允许"一次在途 N 段”，配合累计确认很自然；代价是乱序或丢一段时，已经发出去但未确认的整批都得重来。
选择重传只补丢的那段，需要接收端能缓存乱序段、发送端能选择性重发，实现更复杂，要靠 SACK（Selective ACK，RFC 2018）选项 支持。

TCP 选了什么

TCP 的累计确认与 Go-Back-N 有相似之处，但真实 TCP 不能简单归类为标准的 Go-Back-N：超时重传、快速重传、Reno / NewReno 恢复和 SACK 会共同决定补传哪些数据。累计 ACK 只能指出“下一个期望字节”；如果两端协商了 SACK（多数现代系统默认开启），接收端还能报告已经收到的非连续区间，发送端据此更精确地选择补传内容。

一句话总结：TCP 是“滑动窗口 + 累计确认 + 快速 / 超时重传 + 可选 SACK”的工程组合，不是某种单一 ARQ 模型的纯实现。

四、重传超时 RTO 与 RTT 估算

“等多久还没收到 ACK 就算丢了”——这个阈值叫 RTO（Retransmission Timeout） 。设长了，真丢包时干等、延迟飙升；设短了，包没丢只是慢了就误重传，反而拥塞。理想 RTO 应该紧跟着网络实际的往返时延 RTT。

RTT 怎么测、RTO 怎么算

TCP 会持续测量报文段的往返时间（SampleRTT = 收到 ACK 的时刻 − 发送时刻），但单次样本抖动大，所以要平滑。RFC 6298 给的经典做法是两个 EWMA（指数加权移动平均）：

1
2
3


EstimatedRTT = ⅞ · EstimatedRTT + ⅛ · SampleRTT # 平滑后的 RTT
DevRTT = ¾ · DevRTT + ¼ · |SampleRTT − EstimatedRTT| # RTT 的抖动幅度
RTO = EstimatedRTT + 4 · DevRTT # 上界留足余量

工程实现里还会给 RTO 加下限（比如至少 1 秒）并加上退避：每次重传后 RTO 翻倍（指数退避），避免重传把拥塞的网络越搞越糟。

Karn 算法：重传过的段别用来测 RTT

这里有个歧义：一段发出后被重传过，最后收到的 ACK 到底是确认"第一次"还是"重传那一次"？分不清就会把 RTT 测错。Karn 算法规定：重传过的报文段，其 ACK 不参与 RTT 采样；同时配合上面的指数退避。简单粗暴但有效。

五、滑动窗口：让"等确认"可以批量进行

如果发一段就停下等一个 ACK（停等），在长肥管道（高带宽 × 高延迟）上吞吐会很惨。TCP 的解法是滑动窗口：允许发送端在还没收到确认的情况下，连续发出一段范围内的数据。这个"范围"就是窗口。

发送缓冲区的四段划分

把发送缓冲区从左到右切成四段：

1
2
3


 已发送且已确认 │ 已发送未确认（在途） │ 可发送但未发送 │ 超出窗口、暂不可发
 ◀────────────────────────▶│◀──────────────────────────▶│◀──────────────────▶│◀──────────────────▶
 ◀───── 发送窗口 = min(rwnd, cwnd) ─────▶

已发送且已确认：可以回收缓冲区了；
已发送未确认：还在路上，丢了要重传；
可发送但未发送：在窗口内、应用层可以立刻塞进来发；
超出窗口、暂不可发：受窗口限制，得等窗口右移。

随着 ACK 到来，左边界（= 已确认位置）右移，整窗口向右"滑动"，于是新的字节不断进入"可发送"区——这就是"滑动窗口"名字的由来。

发送窗口的实际大小 = min(rwnd, cwnd)。rwnd 是接收端告知的接收窗口（这一篇的主题，流量控制）；cwnd 是发送端自己估的拥塞窗口（下一篇的主题，拥塞控制）。两个约束谁小听谁的。

接收窗口

接收端这边也有一个窗口，本质是"接收缓冲区还剩多少空间"。它把这个值写进每个 ACK 的窗口字段回传给发送端——这就是 rwnd（receive window）。发送端据此调整自己的发送窗口，永远不让在途数据超过接收端能存下的量。

六、零窗口与窗口探测

接收端处理慢、缓冲区满时，会回一个 rwnd = 0 的 ACK，告诉发送端"先别发了"。发送端就停。

这里有个死锁风险：接收端后来腾出空间、发了个"窗口更新"的 ACK 想让发送端继续，但这个 ACK 如果丢了，双方就永久卡住——发送端在等"窗口打开"，接收端在等"数据进来"。

TCP 用 持久计时器（persist timer）+ 窗口探测（window probe） 破局：发送端收到 0 窗口后启动持久计时器，到点就发一个只含 1 字节数据的探测段，逼接收端回一个带最新 rwnd 的 ACK。探测按指数退避反复进行（上限约 60 秒一次），直到窗口重新打开。这样即便窗口更新丢了，连接也不会永久挂死。

顺带：糊涂窗口综合征（SWS）

反过来，如果接收端每次只腾出几字节就急着通告、发送端也每次只发几字节，TCP 头的开销就会把有效吞吐吃光——这叫糊涂窗口综合征（Silly Window Syndrome） 。接收端和发送端各有 Clark 算法做规避：接收端在缓冲区没腾出"够大"的空间前，继续通告 rwnd=0；发送端也攒够一段才发。这些细节 TCP 实现都自动处理，应用层一般无感。

七、流量控制：收发两端之间的限速

把上面几节串起来，流量控制（flow control） 的全貌就清楚了：它是接收端用来限制发送端的机制，目的是"别发得比我处理得快，免得压垮我的缓冲区"。手段就是滑动窗口 + rwnd：

接收端通过 ACK 的窗口字段实时通报自己还剩多少缓冲；
发送端据此调整在途数据上限，永远不超过；
窗口为 0 时发送端停下，靠窗口探测等重新开放。

流量控制 vs 拥塞控制：别搞混

这俩名字像、都限制发送速率，但作用对象完全不同，是 TCP 窗口那 min(rwnd, cwnd) 里的两个独立分量：

	流量控制（Flow Control）	拥塞控制（Congestion Control）
保护谁	接收端（别压垮对端缓冲）	网络（别压垮路由器 / 链路）
谁感知	接收端（缓冲剩余空间）	发送端（靠丢包 / 延迟推断）
靠什么限速	`rwnd`（ACK 里带）	`cwnd`（发送端内部维护）
作用范围	点对点，两个端之间	整条路径上的所有连接共享

一句话：流量控制是"接收端喊停"，拥塞控制是"发送端自律" 。下一篇就专门讲拥塞控制——TCP 怎么在没有网络层任何反馈的情况下，靠"试"和"退"把全网吞吐调到尽量高又不崩溃。

小结

TCP 的可靠性三板斧是序号、确认、重传；序号针对字节，确认是累计确认（“下一个期望的字节”），SYN/FIN 各占一个序号。
ARQ 有三种思想——停等、回退 N 步、选择重传；TCP 是"回退 N 的窗口 + 累计确认 + 快速 / 超时重传 + 可选 SACK"的工程混合体。
RTO 紧跟 RTT 动态估算（RFC 6298 的 EWMA + 4 倍偏差），重传段不参与采样（Karn 算法），重传后 RTO 指数退避。
滑动窗口让"等确认"可以批量进行：发送窗口 = min(rwnd, cwnd)，随 ACK 到来向右滑动。
零窗口靠持久计时器 + 1 字节窗口探测破解死锁；糊涂窗口综合征靠 Clark 算法规避。
流量控制（收发之间，靠 rwnd）与拥塞控制（作用于网络，靠 cwnd）是两件事，分别约束窗口的两个分量。

下一篇：TCP/IP（八）：TCP 拥塞控制 —— 慢启动、拥塞避免、快速重传 / 快速恢复，以及为什么 TCP 能"自发"地把全网的吞吐挤到一个不错的平衡点。

参考：

RFC 9293: Transmission Control Protocol (TCP)

RFC 6298: Computing TCP’s Retransmission Timer

RFC 2018: TCP Selective Acknowledgment Options (SACK)

RFC 6429: TCP Sender Clarification for Persist Condition

RFC 7323: TCP Extensions for High Performance（时间戳 / PAWS，取代 RFC 1323）

TCP/IP（六）：TCP 连接管理——握手、挥手与状态机

Wed, 27 May 2026 10:00:00 +0800

写在前面

上一篇我们认识了传输层的两位主角 TCP 与 UDP，也拆解了 TCP 报文段头部里的那些字段——序号、确认号、标志位（SYN/ACK/FIN/RST）、窗口大小……当时说"这些字段怎么用，留到后面讲"，这一篇就来还债。

TCP 把自己叫作"面向连接"的协议，可这个"连接"到底是什么？它不是一条物理通路，而是通信两端各自维护的一组状态（各自的序号、窗口、计时器）。连接管理要回答的核心问题就两个：怎么把这组状态建起来，又怎么干净地拆掉 。建起来的过程叫握手（三次），拆掉的过程叫挥手（四次），中间还牵出一堆状态和一个让无数后端工程师踩过坑的 TIME_WAIT。

这一篇就把这些一次讲透：握手为什么是三次、挥手为什么是四次、完整的状态机长什么样、TIME_WAIT 为什么存在，以及一个高频实战问题——客户端短连接打太快把临时端口耗光。

一、先说清：TCP 的"连接"是什么

TCP 的连接不是物理的，而是逻辑上的状态同步。两台主机上的 TCP 实体各自记住一组变量，主要包括：

对端 IP 与端口（连同自己的，构成四元组）；
自己的发送序号、对端要确认的下一个序号；
发送窗口、接收窗口（下一篇讲）；
一堆计时器（重传、保活、持久……）。

一条 TCP 连接由四元组唯一标识：(源 IP, 源端口, 目的 IP, 目的端口)。理论上同一台机器上只要四元组之一不同，就能并存多条连接——这也是后面理解"端口耗尽"的关键。

UDP 没有这些建连过程，发完就走，所以叫"无连接"。TCP 要先握手把这些状态协商好（尤其是双方的初始序号），然后才能可靠地收发字节流。

二、三次握手：为什么是三次

建立一条 TCP 连接，客户端和服务端要互相确认两件事：我能听见你，你也能听见我；还要协商好各自的初始序号（ISN）。整个过程三个报文：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


 客户端 服务端
 CLOSED LISTEN
 │ │
 │ ─── SYN, seq=x ─────────────────────────▶│ "我想建连，我的 ISN 是 x"
 │ SYN-SENT │
 │ ▼
 │ SYN-RECEIVED
 │ ◀──────────── SYN+ACK, seq=y, ack=x+1 ────│ "同意；我的 ISN 是 y，期待 x+1"
 │ │
 │ ─── ACK, seq=x+1, ack=y+1 ──────────────▶│ "收到，期待 y+1"
 │ ESTABLISHED │
 │ ESTABLISHED

要点（后面要考）：

SYN 和 FIN 各消耗一个序号，所以对 SYN 的确认是 ack = x + 1，而不是 x；
中间那个报文是 SYN+ACK（标志位同时置位），把"服务端的 SYN"和"对客户端 SYN 的 ACK"合二为一——这正是省下一次往返的原因；
握手完成后，双方都进入 ESTABLISHED，可以双向传数据。

为什么不是两次

这是面试高频题，也是真正理解 TCP 的分水岭。两次握手的意思是：服务端一发完自己的 SYN+ACK 就直接 ESTABLISHED，开始等数据。问题有两个：

服务端的初始序号没有得到确认。三次握手中，客户端的第三个 ACK 确认了服务端的 SYN 和初始序号。两次握手缺这一步，服务端若直接认定连接建立，就无法确认双方是否已经完成双向序号同步。“确认客户端的接收能力”可以帮助直觉理解，但规范层面的核心是同步并确认双方的初始序号。
挡不住历史重复的 SYN。网络里会残留延迟报文。设想一个旧的、早已失效的 SYN 晚到服务端，两次握手会让服务端立刻开一条连接干等，直到超时才释放——这就是经典的资源浪费。三次握手里，客户端收到服务端对这个旧 SYN 的回应时，能发现序号对不上（这是给一个早已不存在的连接的确认），于是回一个 RST 拆掉它。这第三步本质上是一次"双向确认 + 旧报文过滤" 。

为什么不是四次

因为中间的“服务端 SYN”和“服务端对客户端 SYN 的 ACK”本来就能合并成一个 SYN+ACK 报文，没必要拆成两个独立包。三次已经足够让双方的 SYN 和初始序号都得到确认，再拆成四次不会增加必要的协议信息。

一句话：三次握手 = 双方各自发一次 SYN + 各自收到一次对 SYN 的 ACK，其中一方的 SYN 与对另一方的 ACK 合并成了一个报文 。

三、四次挥手：为什么 ACK 和 FIN 要分开

TCP 是全双工的——双方都能独立地"发完数据"。所以关闭一条连接不能像握手那样一步到位，而要各自单独关闭自己的发送通道。这就是四次：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 主动关闭方 (A) 被动关闭方 (B)
 ESTABLISHED ESTABLISHED
 │ 应用调用 close() │
 │ ─── FIN, seq=u, ack=v ──────────────────▶│ "我没数据要发了"
 │ FIN-WAIT-1 │
 │ CLOSE-WAIT
 │ ◀──────────────────── ACK, ack=u+1 ───────│ "收到你的 FIN"
 │ FIN-WAIT-2 │
 │ ...B 还可以继续发剩余数据... │
 │ ◀──────────────────── FIN, seq=w, ack=u+1─│ "我也发完了"
 │ LAST-ACK
 │ ─── ACK, ack=w+1 ──────────────────────▶│
 │ TIME-WAIT (等 2×MSL) │
 │ CLOSED
 │ ──(2×MSL 后)──▶ CLOSED

为什么中间的 ACK 和 FIN 不合并

因为它们触发于不同时刻。A 发 FIN 表示"A 发完了"；B 收到后立刻回 ACK。但 B 此刻可能自己还有数据没发完——它处于 CLOSE-WAIT，发送通道还开着。等 B 也把数据发完、自己的应用也调了 close，B 才发自己的 FIN。

握手时服务端的 SYN 和 ACK 是"同时"要发的（都在握手那一瞬间），可以合并；挥手时 B 的 ACK 是"立刻"发的，而 FIN 要等到 B 应用层决定关闭，两者通常隔得很远，所以分开发。只有当 B 恰好也没有数据要发时，ACK 和 FIN 才可能挤进同一个包——但那是优化，不是常态。

全双工的"半关闭"

FIN-WAIT-2 状态下，A 已经关闭了发送方向，但接收方向还开着——B 仍可以继续给 A 推数据，直到 B 也发 FIN。这叫"半关闭"（half-close）。虽然 TCP 协议支持，但应用层很少主动用它，多数实现里一关就双向关。

三个值得记住的状态

CLOSE_WAIT：被动关闭方收到 FIN、回了 ACK 之后进入。它表示"对端不再发了，但我可能还要把缓冲区里剩下的数据发完，然后等我的应用层调 close"。如果应用层迟迟不关 socket，连接就会长期停在 CLOSE_WAIT——这是排查应用层 bug（忘了关连接、句柄泄漏）时的常见信号。
LAST_ACK：被动关闭方发完自己的 FIN 后进入，等最后一个 ACK。ACK 一到就 CLOSED。
CLOSING：少见。当 A 发完 FIN 进入 FIN-WAIT-1，没等到对端的 ACK，却先等到了对端的 FIN（两边几乎同时主动关闭）时，A 跳过 FIN-WAIT-2 直接进 CLOSING，再收到 ACK 后进 TIME-WAIT。

四、完整 TCP 状态机：11 个状态

把握手和挥手的状态串起来，就是那张著名的 TCP 状态转换图。RFC 793（现已被 RFC 9293 取代）里画的就是它，一共 11 个状态（含概念上的初始 / 终态 CLOSED）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


 被动打开 主动打开 (connect)
 │ │
 ▼ ▼
 ┌─────────┐ 收 SYN / 发 SYN+ACK ┌─────────┐
 ┌─────│ LISTEN │◀──────────────────────│ CLOSED │
 │ └────┬────┘ └────┬────┘
 │ 收 SYN │ 发 SYN │ 发 SYN
 │ 发 SYN+ACK │ ▼
 ▼ ▼ ┌──────────┐
 ┌──────────────┐ ┌─────│ SYN-SENT │
 │ SYN-RECEIVED │ ◀─── 收 SYN / 发 SYN+ACK ─│ └────┬─────┘
 └──────┬───────┘ 收 SYN+ACK / 发 ACK │ │ 收 SYN+ACK
 │ 收 ACK │ │ 发 ACK
 │ │ ▼
 └──────────────▶ ESTABLISHED ◀────────┘
 │
 主动关闭 / 发 FIN │ 收 FIN / 发 ACK
 ▼ ▼
 ┌───────────┐ ┌───────────┐
 │ FIN-WAIT-1│ │ CLOSE-WAIT│
 └─────┬─────┘ └─────┬─────┘
 收 ACK │ │ close() / 发 FIN
 ▼ │ 收 FIN+ACK ▼
 ┌──────────┐ │ ┌──────────┐
 │FIN-WAIT-2│ │ │ LAST-ACK │
 └────┬─────┘ │ └────┬─────┘
 收 FIN│ / 发 ACK │ │ 收 ACK
 ▼ │ ▼
 ┌──────────┐ │ ┌────────┐
 │TIME-WAIT │ │ │ CLOSED │
 └────┬─────┘ │ └────────┘
 2×MSL│ │
 ▼ │
 ┌────────┐ │
 │ CLOSED │◀─────┘ (FIN-WAIT-1 收到对端 FIN/ACK → CLOSING → 收 ACK → TIME-WAIT)
 └────────┘

各状态一览（按出现顺序）：

状态	谁会进入	含义
`CLOSED`	起点 / 终点	虚构状态，连接不存在
`LISTEN`	服务端	等待连接请求
`SYN-SENT`	客户端	发了 SYN，等 SYN+ACK
`SYN-RECEIVED`	服务端	收到 SYN 并回了 SYN+ACK，等最后 ACK
`ESTABLISHED`	双方	数据传输中
`FIN-WAIT-1`	主动关闭方	发了 FIN，等 ACK 或对端 FIN
`FIN-WAIT-2`	主动关闭方	收到对端 ACK，等对端 FIN（半关闭）
`CLOSE-WAIT`	被动关闭方	收到对端 FIN，等本端应用 close
`CLOSING`	主动关闭方	两边同时关闭的特例
`LAST-ACK`	被动关闭方	发了 FIN，等最后一个 ACK
`TIME-WAIT`	主动关闭方	等待 2×MSL，确保旧报文消亡

排查线上连接问题，netstat -an 或 ss -tan 看到的就是这些状态名。下一篇讲可靠性时还会回到这张图——建立连接是序号协商的起点，拆连接是收尾的边界 。

五、TIME_WAIT 详解：那个让运维失眠的状态

正常关闭时，TIME_WAIT 通常由主动关闭连接的一方承担，持续时间 2×MSL（Maximum Segment Lifetime，报文最大生存时间）；如果双方同时关闭，两端都可能进入 TIME_WAIT。RFC 9293 沿用 2 分钟的规范 MSL 取值，因此规范示例中的 2×MSL 是 4 分钟；Linux 实现通常约 60 秒，不能直接通过普通 sysctl 调整。

为什么必须是主动关闭方、必须等 2×MSL？有两个独立的原因，缺一不可。

原因一：让本连接的旧报文彻底消亡

网络里会残留延迟或重复的报文。如果 TIME_WAIT 一结束、四元组立刻被复用到一条新的、碰巧同四元组的连接，上一个连接里"还在路上"的旧报文就可能被新连接错误接收，造成数据错乱。2×MSL 是一个保守上界：一个报文最多在网络里活 1 个 MSL，加上可能的、由对端重发的方向再 1 个 MSL，合起来 2×MSL 之后，这条四元组相关的旧报文就一定已经消失。

原因二：保证最后一个 ACK 可达

主动关闭方发的最后那个 ACK（对被动方的 FIN 的确认）可能丢。如果丢了，被动方在 LAST-ACK 等不到确认，会重发 FIN；这时主动方还活着（在 TIME_WAIT），就能再回一个 ACK，让被动方正常进入 CLOSED。

如果没有 TIME_WAIT，主动方一发完最后一个 ACK 就直接 CLOSED，被动方一旦没收到这个 ACK、重发 FIN 过来，会收到一个 RST——被动方只能以"异常方式"关闭，连接收尾不可靠。

这两个原因合起来就是为什么 RFC 反复强调 TIME_WAIT 是 TCP 健壮性的一部分，不是可以随便关掉的"包袱" 。它由主动关闭方承担，这是协议天然的设计代价。

六、实战：客户端高频短连接 → TIME_WAIT 堆积 → 端口耗尽

理论说完了，来看一个真实坑。场景：一个 .NET / Java 服务作为客户端，高频地对下游发起短连接——典型的就是轮询、或每次请求都 new HttpClient() 而不复用。每条连接用完就关，下游一般也会被动关，但很多情况下客户端是先关的那一方（请求方发完数据就 close）。

于是：每条连接可能在客户端留下一个 TIME_WAIT，暂时保留对应的连接四元组，其中包含一个临时端口（ephemeral port）。连接虽然关闭了，但同一四元组不能立即无条件复用。

数字一算就明白了

Linux 临时端口范围默认 32768–60999，约 28000 个；
TIME_WAIT 约 60 秒；
如果只有一个本地源地址，并持续连接同一个目的 IP:端口，28000 / 60 ≈ 470 次/秒 可以作为非常粗的最坏情况量级估算。

这不是客户端的总建连上限：TCP 由四元组区分，同一临时端口可以用于不同目的端点，多本地地址、IPv6 和内核的安全复用策略也会改变结果。在上述受限场景中，如果建连速率持续超过可用四元组的回收速度，新连接可能报：

1

connect: Cannot assign requested address (EADDRNOTAVAIL)

更阴的是：即便流量回落，之前堆积的 TIME_WAIT 也得等满 60 秒才陆续释放，这期间新连接仍然连不上——这就是"恢复后也连不上"的现象。

怎么治

按"治本 → 治标"排序：

连接复用（治本）。短连接的本质问题是"用一次就建一次、关一次"。改成长连接 + 连接池，让一条 TCP 连接承载多次请求，TIME_WAIT 自然不再堆积。.NET 里就是用单例 HttpClient 或 IHttpClientFactory 管理的 HttpClient——这个问题在《HttpClient 的前世今生》里讲得很透，连"socket 耗尽"现象都是同一个根因的两种表现。
合理设计关闭方，但别只为转移状态而改协议。正常关闭时谁主动关，谁通常承担 TIME_WAIT；HTTP keep-alive 连接也常由服务端在空闲超时后关闭。不过，刻意把关闭责任推给下游只是转移资源压力，还可能破坏连接复用和协议语义，必须结合两端容量与业务行为设计。
谨慎评估 net.ipv4.tcp_tw_reuse（治标）。当前 Linux 文档定义 0 为禁用、1 为全局启用、2 为仅 loopback 流量启用，默认值是 2。它允许内核在协议判定安全时为新连接复用 TIME-WAIT socket，但官方明确提示不要在缺少专家评估时修改。不要把它当成通用推荐，更不能代替连接池和长连接。
扩大临时端口范围：net.ipv4.ip_local_port_range = 10000 65535 之类，把池子做大，单纯把阈值推高，没解决根因。
别用 tcp_tw_recycle。这个开关在 Linux 4.12 已经被彻底移除——它在 NAT / 负载均衡环境下会基于时间戳丢弃合法连接，害处远大于收益。网上老文章还在推荐，别信。

经验法则：看到 TIME_WAIT 多先别慌，它是 TCP 的正常行为，量级到几万也不一定有问题。真正要看的是是否伴随着端口耗尽 / 建连失败——有才治，没有就让协议自己跑。

七、SYN flood 与 SYN cookies

握手的状态机里有个软肋：服务端收到 SYN 就要分配资源、进入 SYN-RECEIVED，等第三个 ACK。攻击者只要发海量伪造源 IP 的 SYN、但永远不发第三个 ACK，服务端的半连接队列（SYN backlog）就会被占满，正常用户反而连不进来——这就是 SYN flood。

SYN cookies：无状态地扛过去

防御思路是 Bernstein 提出的 SYN cookies：收到 SYN 时先不分配任何状态，而是把"这条连接的身份信息"用一个服务端秘钥做 MAC，编码进 SYN+ACK 的初始序号里发回去。服务端什么也不记，直接忘掉这条连接。

当（真正的）客户端回第三个 ACK 时，它的确认号 = 之前的序号 + 1，服务端从里面反解并校验 MAC：合法就认、重建连接状态；伪造源 IP 的攻击者根本收不到 SYN+ACK，自然也回不出合法 ACK。

代价是 Cookie 可编码的状态空间有限，一些 TCP 选项可能无法完整保留；现代 Linux 可借助时间戳等机制保存更多协商信息，具体限制取决于内核实现。Linux 通常默认 tcp_syncookies=1，在 SYN 队列溢出时启用。

SYN flood 是典型的"利用协议状态机的资源占用做放大"的攻击。同理，让主动关闭方堆积 TIME_WAIT 也可以是一种"被动 DoS"——这也是上一节强调复用连接的另一个理由。

小结

三次握手让双方同步并确认初始序号，也能正确处理历史重复 SYN；不是两次（服务端 SYN 尚未被确认）也不是四次（中间 SYN 和 ACK 可合并）。
四次挥手源于 TCP 的全双工：每一方都要单独关闭自己的发送方向，中间的 ACK 与 FIN 因时刻不同通常无法合并。
TCP 有 11 个状态，串成那张经典状态机；ESTABLISHED 是中点，两侧分别是建立与拆除路径。
正常关闭时 TIME_WAIT 通常由主动关闭方承担，同时关闭时两端都可能进入；它持续 2×MSL，目的是隔离旧报文并允许重发最后的 ACK——是 TCP 健壮性的代价，不是包袱。
客户端高频短连接会把 TIME_WAIT 堆到临时端口耗尽（EADDRNOTAVAIL），治本是连接复用，治标是 tcp_tw_reuse。
SYN flood 借握手占用半连接资源，SYN cookies 用"序号里编码 MAC"实现无状态握手来扛。

下一篇：TCP/IP（七）：TCP 可靠性——序号、重传与滑动窗口 —— 连接建好之后，TCP 到底怎么在会丢包、乱序、重复的 IP 之上，拼出一条不出错的字节流。

参考：

RFC 9293: Transmission Control Protocol (TCP)（取代 RFC 793，现行 TCP 规范）

RFC 793: Transmission Control Protocol（经典，状态机原图出处）

RFC 4987: TCP SYN Flooding Attacks and Common Mitigations

SYN cookies — D. J. Bernstein

Coping with the TCP TIME-WAIT state on busy Linux servers — Vincent Bernat

HttpClient 的前世今生（本站）

TCP/IP（五）：传输层与 UDP——端口与无连接

Mon, 25 May 2026 10:00:00 +0800

写在前面

上一篇把网络层的 IP 地址、子网、路由和 ICMP 讲透了。但有个问题一直没回答：IP 只能把包送到某台主机，而一台机器上同时跑着浏览器、SSH、数据库几十个进程，一个进来的 IP 包到底该交给谁？

这个"交给谁"的问题，正是传输层要解决的。这一篇先讲传输层的职责和它的核心概念端口号，再展开两个传输层协议中较简单的那个——UDP ：它为什么这么轻、靠什么校验、适合什么场景，并和 TCP 做一次选型对比。

一、传输层：从"主机到主机"到"进程到进程"

网络层（IP）解决的是主机到主机：路由器逐跳转发，把包送到目的 IP 那台机器。但它不关心机器内部。传输层在网络层之上，做两件 IP 做不了的事：

进程到进程（端到端）的分发 —— 一台主机上多个进程共用一个 IP，传输层靠端口号区分，把数据准确交给目标进程。这个"多路分用（demultiplexing）“是传输层最根本的职责；
端到端的可靠性与流量控制（可选） —— IP 是无连接、不可靠的，要不要重传、要不要按序、要不要限速，由传输层协议决定（TCP 提供，UDP 不提供）。

1
2
3
4
5
6
7
8


发送端进程 接收端进程
 HTTP(80) HTTP(80)
 SSH(22) ┌──── 传输层 ────┐ SSH(22)
 DNS(53) ──► │ 按端口号分发 │ ──► DNS(53)
 └────────────────┘
 ▲
 网络层只管送到这台主机
 （IP 不区分进程）

所以传输层是第一个真正的端到端层：数据从源进程的端口，直达目的进程的端口。理解了这一点，TCP/UDP 的所有设计都围绕"如何更好地完成端到端通信"展开。

二、端口号与套接字

端口号是一个 16 位的整数，取值范围 0 ~ 65535。IANA 把它分成三段：

范围	名称	说明	例子
0 – 1023	知名端口（well-known）	系统级服务常驻，Unix 下通常需要特权	22=SSH、53=DNS、80=HTTP、443=HTTPS
1024 – 49151	注册端口（registered）	IANA 为应用登记	3306=MySQL、5432=PostgreSQL、6379=Redis
49152 – 65535	动态 / 私有端口（dynamic）	临时端口，客户端发起连接时由系统随机分配	——

客户端发起请求时，操作系统从动态端口范围里临时挑一个作为源端口，去连服务端的知名端口。这个动态范围因系统而异：Linux 默认大致是 32768~~60999（cat /proc/sys/net/ipv4/ip_local_port_range 可查），Windows 默认是 49152~~65535。IANA 的建议标准是 49152~65535（RFC 6335）。

套接字（Socket）= IP + 端口

一个 套接字 用一个二元组唯一标识一条通信端点：

1
2
3


套接字 = （IP 地址，端口号）
例如：192.168.1.10:54321 → 本机某个客户端的临时端口
 93.184.216.34:443 → 某网站 HTTPS 服务

一条 TCP/UDP 连接（或数据流）由两端的套接字共同确定：(源IP, 源端口, 目的IP, 目的端口, 协议)，这叫五元组。抓包工具里看到的一条连接，就是靠五元组区分的。后面讲 TCP 会再回到这个概念。

三、UDP：无连接的极简协议

UDP（User Datagram Protocol，用户数据报协议）是传输层的"极简派”——RFC 768 一个文档就讲完了，核心特点四个字：尽力而为 。

无连接 —— 发数据前不需要先建连，拿了 IP 和端口直接发，也不维护对端状态；
不保证可靠 —— 不确认、不重传，包丢了就丢了，应用层自己处理；
不保证顺序 —— 后发的可能先到，到达顺序不保证；
没有流量 / 拥塞控制 —— 不会因为对端慢就降速，也不会因为网络拥塞就退让（所以 UDP 容易"冲"，也因此在某些场景下比 TCP 快）。

UDP 的设计哲学是：传输层只做最少的搬运——加上端口、做个校验，剩下的全交给应用层 。这让它天然适合"宁可丢一点、也别等"的场景。

四、UDP 头部与校验和

UDP 的头部只有 8 字节，是 TCP 头部（最少 20 字节）的零头：

1
2
3
4
5
6
7
8
9


 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 源端口 (16) | 目的端口 (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 长度 (16) | 校验和 (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 数据（若有）... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

四个字段各 2 字节：

源端口 —— 可选，不用时填 0；
目的端口 —— 必填，接收端靠它分发；
长度 —— 整个 UDP 数据报（头部 + 数据）的字节数，最小值 8（只有头、没数据）；
校验和 —— 覆盖"伪首部 + UDP 头 + 数据"。

伪首部（pseudo header）：连 IP 层一起校验

校验和最值得说的设计是伪首部：它不是真正传输的数据，只是计算校验和时临时拼在 UDP 头前面的 12 字节，内容来自 IP 头部：

1
2
3
4
5
6
7
8
9


 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 源 IP 地址 (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 目的 IP 地址 (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (8) | 协议号 (8)=17 | UDP 长度 (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

为什么要把 IP 地址也算进来？因为 UDP 想顺带验证：这个包确实发给了正确的 IP 和正确的协议（UDP 的 IP 协议号是 17） 。如果 IP 层把包投错了地址、或把别的协议误当成 UDP，校验和就对不上，UDP 会直接丢弃——等于给"端口分发"多上了一层保险。

一个 IPv4 的细节：UDP 校验和在 IPv4 里是可选的（填 0 表示“不校验”）；IPv6 默认要求非零 UDP 校验和，因为 IPv6 没有头部校验和。RFC 6935 / RFC 6936 为特定、受控的隧道封装定义了零校验和例外，但普通 UDP 应用不应把例外当常规做法。实际工程中的通用 UDP 实现通常都会开启校验和。

五、UDP 适用场景

正因为"轻、快、不啰嗦"，UDP 在这些场景里是更优解：

场景	为什么选 UDP
DNS	查询报文极小（通常一个包搞定），一来一回就完事；若用 TCP，每次查询都三次握手，开销远大于数据本身
DHCP	客户端连 IP 都还没有，没法建连；靠 UDP 广播/组播完成地址发现，天然契合无连接
音视频通话、直播	容忍丢包（丢一帧花屏而已），但受不了 TCP 那种"丢包 → 重传 → 阻塞"带来的延迟和卡顿
在线游戏	状态实时刷新，旧数据重传毫无价值，宁可丢也要保住最新帧
QUIC / HTTP/3	在 UDP 之上自行实现可靠性、加密、多路复用和拥塞控制，绕开 TCP 内核栈的演进包袱

最后一条尤其重要：QUIC 选择"在 UDP 上重建一套类 TCP 的可靠传输" ，而不是直接用 TCP，是因为 TCP 的连接管理、拥塞控制都焊死在操作系统内核和中间网络设备里，升级一次要等十年；而 UDP 是个"白板"，把控制逻辑放回用户态就能快速迭代——这是现代协议设计的一个重要趋势。

六、TCP vs UDP 选型对比

回到工程实践：到底该选 TCP 还是 UDP？一张表说清差异：

维度	TCP	UDP
连接方式	面向连接（三次握手建连）	无连接，拿来就发
可靠性	可靠（确认 + 超时重传）	不可靠，尽力而为
数据顺序	按序交付，接收端无序感	不保证顺序，可能乱序
流量控制	有（滑动窗口）	无
拥塞控制	有（慢启动、AIMD 等）	无（应用层自行决定）
头部开销	最少 20 字节	固定 8 字节
传输效率 / 延迟	有握手和确认开销，延迟略高	极低开销，延迟低
通信模式	一对一（点对点）	一对一、一对多（广播/组播）
典型场景	网页、文件传输、邮件、数据库	DNS、DHCP、音视频、游戏、QUIC

一个简单的选型口诀：

数据必须完整、不能丢 —— 选 TCP（文件传输、交易、数据库连接）；
实时性优先、容忍少量丢包 —— 选 UDP（音视频、游戏）；
查询极小、一问一答 —— 选 UDP（DNS）；
需要组播 / 广播 —— 只能 UDP（TCP 是严格的点对点）；
想要可靠又想摆脱 TCP 内核束缚 —— 在 UDP 上自建可靠层（QUIC）。

下一篇：TCP/IP（六）：TCP 连接管理 —— TCP 怎么靠三次握手建立连接、四次挥手断开、为什么是"三次"不是"两次"、TIME_WAIT 状态存在的意义，把传输层里最经典也最常被追问的部分讲透。

参考：

User Datagram Protocol (RFC 768)

Service Name and Transport Protocol Port Number Registry — IANA

Internet Assigned Numbers Authority Procedures (RFC 6335)

QUIC: A UDP-Based Multiplexed and Secure Transport (RFC 9000)

TCP/IP（四）：IP 地址、子网与路由

Sat, 23 May 2026 10:00:00 +0800

写在前面

前几篇走完了分层模型、链路层，又把网络层的 IP 数据报整体结构（头部字段、TTL 的作用）过了一遍。这一篇聚焦 IP 协议里被引用最多、面试最爱考、工程上最常踩坑的部分：IP 地址到底怎么编排、子网怎么划分、路由器怎么查表转发，以及 ICMP 怎么撑起 ping 和 traceroute 。

这些知识在云原生里天天见——配置 Pod 的 CIDR、规划 VPC 子网、写路由表、排查"为什么 ping 不通"，全靠它。

一、IPv4 地址：32 位与点分十进制

IPv4 地址是一个 32 位的无符号整数，为了方便记忆，把它每 8 位切一段、转成十进制、用点连起来，这就是"点分十进制"：

1
2
3
4


192 .168 .1 .10
11000000 .10101000 .00000001 .00001010
 └─8位─┘ └─8位─┘ └─8位─┘ └─8位─┘
 第1字节 第2字节 第3字节 第4字节

所以 IPv4 地址总共只有 2³² = 4294967296（约 43 亿）个，这正是地址紧缺、要搞 IPv6 和 NAT 的根本原因。

注意 IP 地址是网络层地址，跨网可路由；而 MAC 地址是链路层地址，只在同一链路内有效。这两套地址体系互不替代，后面讲 ARP 会把它们接起来。

二、网络位与主机位：地址的两段结构

光知道 32 位还不够，关键在于这 32 位要拆成两段：

1
2
3
4


 IPv4 地址（32 位）= 网络位 ｜ 主机位
 └──┬─┘ └──┬─┘
 标识"哪个网络" 标识"网络里的哪台主机"
 （路由器靠它转发）（路由到目的网后用它在链路内定位）

网络位（network prefix） —— 决定这个地址属于哪个网段，路由器逐跳转发时只看这部分；
主机位（host part） —— 在同一网段内区分不同主机，只有"到了最后一跳、进了目的网络"之后才用得上。

历史上有 A/B/C 三类地址，靠固定的前几位决定网络位长度（A 类 /8、B 类 /16、C 类 /24）。但这种"定长分类"太死板：一个 /16 网段有 65534 个主机地址，对一个几十台机器的小公司是巨大浪费；一个 /252 又装不下大企业。于是有了子网划分和 CIDR（无类别域间路由）——网络位长度不再由"类别"决定，而是可以任意指定。

三、子网掩码与 CIDR 记法

既然网络位长度可变，就需要一种方式告诉别人"前多少位是网络位"。有两种等价写法：

1. 子网掩码（dotted mask） —— 把网络位全置 1、主机位全置 0，也写成点分十进制：

1
2
3
4
5


前 24 位是网络位：
掩码 = 11111111.11111111.11111111.00000000 = 255.255.255.0

前 22 位是网络位：
掩码 = 11111111.11111111.11111100.00000000 = 255.255.252.0

2. CIDR 记法 —— 在 IP 地址后面直接写 /n，n 就是网络位的位数：

1
2


192.168.1.10/24 → 前 24 位是网络位，掩码 255.255.255.0
10.0.0.5/22 → 前 22 位是网络位，掩码 255.255.252.0

工程里几乎都用 CIDR 记法，因为它一眼就能看出网络位长度。常见的 CIDR 与掩码对应：

CIDR	子网掩码	主机位	可用主机数	典型用途
/8	255.0.0.0	24	16777214	A 类整段、10/8 私有
/16	255.255.0.0	16	65534	中型网络、172.16/12 子段
/24	255.255.255.0	8	254	最常见的子网大小
/28	255.255.255.240	4	14	小网段、云上分配合
/30	255.255.255.252	2	2	点对点链路
/32	255.255.255.255	0	1	单机路由、主机精确匹配

两个特例：可用主机数 = 2^(主机位) − 2 ，因为主机位全 0 的那个是"网络地址"、全 1 的那个是"广播地址"，都不能分配给主机。/31 是个特殊例外（RFC 3021），点对点链路上只有两台主机、不需要广播，所以两个地址都可用；/32 则表示单个主机，没有主机位。

四、动手算：网络地址、广播地址、可用主机数

这是面试高频题，也是规划子网的基本功。规则只有三条：

网络地址 = IP 地址 AND 子网掩码（按位与，主机位清零）；
广播地址 = 网络地址 OR （主机位全 1）；
可用主机数 = 2^(主机位) − 2，范围是"网络地址 + 1"到"广播地址 − 1"。

例 1：192.168.1.10/24

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


/24 → 主机位 = 32 − 24 = 8，掩码 255.255.255.0

IP : 192.168.1.10 = 11000000.10101000.00000001.00001010
掩码: 255.255.255.0 = 11111111.11111111.11111111.00000000
 AND ─────────────────────
网络地址: 192.168.1.0 = 11000000.10101000.00000001.00000000

广播地址: 192.168.1.255 = 11000000.10101000.00000001.11111111 (主机位全 1)

可用主机数 = 2^8 − 2 = 254
可用范围 : 192.168.1.1 ~ 192.168.1.254

例 2：10.0.0.5/22（非字节边界，更接近真实场景）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


/22 → 主机位 = 32 − 22 = 10，掩码 255.255.252.0

第 3 字节的掩码是 11111100 = 252（注意不是 255，跨了字节边界）

IP : 10.0.0.5 = 00001010.00000000.00000000.00000101
掩码: 255.255.252.0 = 11111111.11111111.11111100.00000000
 AND ──────────────────
网络地址: 10.0.0.0 = 00001010.00000000.00000000.00000000

把后 10 位主机位全置 1 得广播地址：
广播地址: 10.0.3.255 = 00001010.00000000.00000011.11111111
 ↑第3字节后2位=11=3

可用主机数 = 2^10 − 2 = 1022
可用范围 : 10.0.0.1 ~ 10.0.3.254

第二个例子最容易出错的地方是第 3 字节的边界：掩码 252 说明第 3 字节里只有前 2 位属于网络位，后 2 位属于主机位。所以广播地址的第 3 字节是 00000000 | 00000011 = 3，整个网段横跨 10.0.0.0 ~ 10.0.3.255 这四个"第 3 字节"。

一个速算技巧：对 /24 以上（即掩码在第 4 字节内）的子网，“块大小”= 256 − 掩码字节。比如 /28 掩码是 .240，块大小 = 256 − 240 = 16，所以子网的第 4 字节从 0 开始按 16 递增：.0、.16、.32……这台主机落在哪个块里，网络地址就是那个块的起点。

五、VLSM 与私有地址段

VLSM：可变长子网掩码

CIDR 让网络位长度任意，而 VLSM（Variable Length Subnet Masking，可变长子网掩码） 进一步允许对同一个主网，按不同子网的实际大小切出不同掩码长度。

举个规划例子：一个公司拿到 192.168.10.0/24，要分给几个不同规模的部门：

1
2
3
4
5


部门 A（120 台）: 192.168.10.0/25 → 126 个可用（最省的能盖住 120 的子网）
部门 B（50 台） : 192.168.10.128/26 → 62 个可用
部门 C（25 台） : 192.168.10.192/27 → 30 个可用
点对点互联（2台）: 192.168.10.224/30 → 2 个可用
剩余未分配 : 192.168.10.228/30 ...

没有 VLSM 之前（只能用定长子网掩码 FLSM），所有子网都得按最大的那个来切，地址浪费严重。VLSM 让掩码长度"按需伸缩"，是现代网络和云上 VPC 子网规划的基础。

私有地址段（RFC 1918）

不是所有地址都能在公网路由。RFC 1918 划出三段私有地址，供内网自由使用、不用申请，出公网时靠 NAT 转换：

名称	网段	CIDR	容量
A 类私有	10.0.0.0 ~ 10.255.255.255	10.0.0.0/8	2²⁴（约 1677 万）
B 类私有	172.16.0.0 ~ 172.31.255.255	172.16.0.0/12	2²⁰（约 100 万）
C 类私有	192.168.0.0 ~ 192.168.255.255	192.168.0.0/16	2¹⁶（65536）

家里路由器的 LAN、公司办公网、数据中心内网、云上 VPC、Docker 默认网桥——绝大多数内网都落在这三段里。还有几个特殊段也值得知道：169.254.0.0/16（链路本地，DHCP 拿不到地址时的 fallback）、127.0.0.0/8（环回，localhost）。

六、路由表与最长前缀匹配

IP 地址规划好之后，路由器靠"路由表"决定每个包往哪转发。一条路由条目至少包含三要素：

1

目的网络（含掩码） | 下一跳（Next Hop） | 出接口

比如一台主机的路由表可能长这样：

1
2
3
4


目的网络 掩码 下一跳 接口
0.0.0.0 0.0.0.0 192.168.1.1 eth0 ← 默认路由（兜底）
192.168.1.0 255.255.255.0 0.0.0.0(本机) eth0 ← 直连子网
10.0.0.0 255.255.252.0 192.168.1.254 eth0 ← 去往 10.0.0.0/22

最长前缀匹配（Longest Prefix Match）

当一个目的地址能匹配多条路由时，路由器永远选掩码最长（最具体）的那条——因为掩码越长、网络位越精确，指向的网段越小。

举例：要发往 10.0.0.50，路由表里有 10.0.0.0/22 和 10.0.0.0/24 两条。两者都能匹配（50 落在这两个网段里），但 /24 比 /22 更长更具体，于是走 /24 那条。

1
2
3


目的 10.0.0.50
 ├─ 命中 10.0.0.0/22 (网络位 22)
 └─ 命中 10.0.0.0/24 (网络位 24) ← 更长，优先选这条

默认路由与默认网关

如果没有任何具体路由能匹配目的地址怎么办？交给默认路由 0.0.0.0/0。它的掩码是 0 位，能匹配任意地址，所以它是"兜底"——按最长前缀匹配规则，它永远排在最后才被选中。

家宽场景里，主机的默认路由下一跳就是默认网关（家用路由器的 LAN 口 IP），所有"非本网段"的流量都甩给它，由它继续往运营商转发。ip route 或 route -n 看到的 default via ... 就是这条。

1

default via 192.168.1.1 dev eth0 ← 等价于 0.0.0.0/0 via 192.168.1.1

七、ICMP：ping 与 traceroute 的底层

IP 协议本身只管"尽力把包送到"，不反馈任何状态。ICMP（Internet Control Message Protocol，互联网控制报文协议） 就是 IP 层的"信使"，用来报告差错和探测网络——ping 和 traceroute 都建立在它之上。

严格说 ICMP 工作在网络层（和 IP 同层，封装在 IP 包里，协议号 1），没有端口号，不涉及传输层。所以"ping 某个端口"在 ICMP 意义上是不成立的——ping 只能测主机可达性。

ping：Echo Request / Echo Reply

ping 的原理极其简单——发一个 ICMP Echo Request（类型 8，代码 0） 给目标，目标收到后回一个 Echo Reply（类型 0，代码 0），一来一回就能算 RTT 和丢包：

1
2
3
4
5
6


本机 目标主机
 │ │
 │── Echo Request (Type 8) ─────────►│
 │ │
 │◄──────── Echo Reply (Type 0) ──────┤
 │ 记录往返时间 RTT │

ping 不通的原因很多：目标离线、路由不可达、防火墙丢弃了 ICMP（很多生产环境出于安全只放行业务端口、禁 ping，所以"ping 不通 ≠ 服务不可用"，这点排查时要记牢）。

traceroute：靠 TTL 递增一跳跳摸路径

traceroute 巧妙利用了 IP 头部里的 TTL（Time To Live，生存时间） 字段。每经过一台路由器，TTL 减 1；一旦减到 0，路由器就丢弃该包并回送一个 ICMP Time Exceeded（类型 11） 给源。traceroute 正是靠这个回包"自报家门"的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


源 路由器A 路由器B 目标
 │
 │ TTL=1 ─────────────────►│
 │ │ TTL-1=0，丢弃
 │◄──── ICMP Time Exceeded──┤ （记录 A 的地址 + 耗时）
 │
 │ TTL=2 ─────────────────►│转发, TTL=1►│
 │ │ │ TTL-1=0，丢弃
 │◄────────── ICMP Time Exceeded─────────┤ （记录 B）
 │
 │ TTL=3 ─────────────────►│ ─────────►│ ─────────►│
 │ 到达目标
 │◄────────── Echo Reply / Port Unreachable ───┤ （结束）

过程是：先发 TTL=1，第一台路由器把 TTL 减到 0、回 Time Exceeded，于是知道了第一跳；再发 TTL=2，第二台路由器回包，知道第二跳……如此递增，直到某个探测包真正到达目标，目标回一个应答（ICMP Echo Reply 或 UDP 端口不可达），路径就摸完了。

一个跨平台要注意的细节：探测包用什么协议，不同系统不一样——

Linux 的 traceroute（传统默认）发 UDP 探测包，目的端口用一个递增的高端口，目标通常因端口未监听而回 ICMP Port Unreachable（类型 3）；
Windows 的 tracert 发 ICMP Echo Request 探测包，目标回 Echo Reply。

两者定位每一跳都靠中间路由器回的 ICMP Time Exceeded（类型 11），只是"到达目标后收到的那个结束应答"不同。现代 Linux 也可以用 traceroute -I 强制走 ICMP、mtr 做持续式路径探测，在排查抖动时更顺手。

小结

IPv4 地址是 32 位整数，点分十进制只是写法；核心在于它被切成网络位 + 主机位 ；
子网掩码和 CIDR /n 是描述网络位长度的两种等价方式，可用主机数 = 2^(主机位) − 2；
网络地址 = IP AND 掩码，广播地址 = 主机位全 1；非字节边界（如 /22）的算法要练熟；
VLSM 让同一主网按需切出不同掩码；私有地址段（10/8、172.16/12、192.168/16）供内网自由使用；
路由器按最长前缀匹配选路，默认路由 0.0.0.0/0 是兜底；
ICMP 是 IP 层信使，ping 用 Echo Request/Reply 测可达性，traceroute 靠 TTL 递增 + Time Exceeded 逐跳摸路径。

下一篇：TCP/IP（五）：传输层与 UDP —— 从"主机到主机"上升到"进程到进程"，讲清端口号、套接字，以及 UDP 这个"极简"传输层协议的头部、校验和和适用场景。

参考：

Address Allocation for Private Internets (RFC 1918)

Classless Inter-Domain Routing (CIDR) — RFC 4632

Using 31-Bit Prefixes on Point-to-Point Links (RFC 3021)

ICMP Parameters — IANA

traceroute — Wikipedia

TCP/IP（三）：IP 协议——数据报、头部与分片

Thu, 21 May 2026 10:00:00 +0800

写在前面

上一篇把链路层讲完了：同一子网里，靠 MAC 地址 + 以太网帧 + 交换机 + ARP，两台设备就能把数据搬过去。但 MAC 只管"一跳"，跨网、跨子网、从北京到纽约，链路层就无能为力了。

升级到网络层，主角登场：IP（Internet Protocol）。这一篇先不谈地址怎么划分、路由怎么走（那是下一篇的事），而是把 IP 协议本身讲透——它的设计哲学、IPv4 数据报头部每一个字段、TTL 怎么防环路、分片怎么和 MTU 较劲，最后带一眼 IPv6 的概貌。

一、IP 的设计哲学：尽力而为

IP 的脾性可以用三个词概括：无连接、不可靠、尽力而为 。

无连接（connectionless）：发包前不先建电路、不先握手，抬手就发；
不可靠（unreliable）：不保证送达、不保证顺序、不保证不重复；
尽力而为（best-effort）：会尽量投递，但出了问题不负责善后——丢了就丢了，乱序就乱序。

这听起来很糟，其实是有意为之。可靠性、顺序、去重这些复杂活，IP 全部甩给上层（一般是 TCP）去干。IP 只负责一件事：看目的地址，把包往目的方向推一跳。这样网络层保持极简、极快，复杂逻辑只在端点上做——这正是互联网能"大而糙地"扩到全球的秘诀。

顺带一提 ICMP（Internet Control Message Protocol），它是 IP 的"信使"。IP 自己不报告错误，遇到问题（TTL 超时、目的不可达、需要分片但 DF 置位）就回一个 ICMP 报文告诉源端。日常用的 ping、traceroute 都靠它。

二、IPv4 数据报头部

IP 层的 PDU 叫数据报（datagram）。一个 IPv4 数据报由头部 + 载荷组成，头部固定部分 20 字节，最长 60 字节（带选项）。RFC 791 定义的头部布局：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0 |Version| IHL | DSCP | ECN | Total Length |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4 | Identification |Flags| Fragment Offset |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 | TTL | Protocol | Header Checksum |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12 | Source IP Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16 | Destination IP Address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 20 | Options (if any) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

逐字段拆解：

字段	位宽	说明
Version	4 位	IP 版本，IPv4 这里是 `4`
IHL	4 位	头长，以 4 字节为单位。最小 `5`（=20 字节，无选项），最大 `15`（=60 字节）。它决定了载荷从哪个字节开始
DSCP	6 位	差分服务码点，用于 QoS 打标记优先级
ECN	2 位	显式拥塞通告，路由器用它给端点"我拥塞了"的信号
Total Length	16 位	整个数据报（头部 + 载荷）的字节数，理论最大 65535
Identification	16 位	标识符，分片重组时用来认"这几片本来是一家"
Flags	3 位	bit0 保留（置 0）；bit1 DF（Don’t Fragment）；bit2 MF（More Fragments）
Fragment Offset	13 位	本片在原数据报中的位置，以 8 字节为单位
TTL	8 位	生存时间，每经一跳减 1
Protocol	8 位	上层协议号，告诉对面"载荷交给谁"（见下表）
Header Checksum	16 位	只校验头部，不校验载荷
Source IP	32 位	源地址
Destination IP	32 位	目的地址
Options	可变	几乎不用，多数路径会忽略或直接丢

Protocol 字段 常见取值（IANA 维护完整列表）：

协议号	协议
1	ICMP
2	IGMP
6	TCP
17	UDP
41	IPv6 封装
47	GRE
50	ESP（IPsec）
51	AH（IPsec）
58	ICMPv6
89	OSPF

几个容易记错的点：

IHL 数的是 4 字节单位，不是字节。所以 5 代表 20 字节、15 代表 60 字节，别和 Total Length 搞混；
Header Checksum 只管头部，载荷的完整性交给上层（TCP 有自己的校验和、UDP 在 IPv4 里校验和可选但实际都开）；
Options 基本退出历史舞台：带选项的包常被路径上的设备丢弃或特殊处理，安全设备尤其敏感。

三、TTL：防环路的保险丝

TTL（Time To Live）名字像"时间"，其实是跳数。规则极简：

源端给个初值（常见 64、128 或 255，因系统而异）；
每经过一台路由器，TTL 减 1；
减到 0 还没到目的地，路由器丢弃该包，并回一个 ICMP Time Exceeded 给源。

它的核心使命是防止环路包永远转圈。要是没有 TTL，一个配错路由的包可能在两台路由器之间无限循环，把链路带宽吃光。

不同系统的默认 TTL 不一样，常被拿来粗略判断对端系统（不完全可靠，可被改）：

系统	常见默认 TTL
Linux / macOS	64
Windows	128
网络设备（路由器等）	255

这正是 traceroute（Windows 下叫 tracert）的原理：故意发 TTL = 1、2、3 … 的探测包，每一跳的路由器因为 TTL 超时回 ICMP Time Exceeded，把返回的 ICMP 源地址记下来，就描出了整条路径。

四、分片与 MTU

上一篇说过，以太网的 MTU = 1500 字节（载荷上限）。可 IP 数据报最长能到 65535 字节。当 IP 包大于出口链路的 MTU 时，就要分片（fragmentation）：路由器把载荷切成几片，每片都套上一个完整的 IP 头，各自独立转发。

分片相关三个字段一起用：

Identification：原数据报被切出来的所有分片，共用同一个 Identification，让目的端能认出"这几片是一家的"；
MF（More Fragments）：除最后一片外都是 1，最后一片是 0——告诉目的端"分片到这就齐了"；
Fragment Offset：本片数据在原载荷中的偏移，以 8 字节为单位。

重组（reassembly）只在目的端做，中间路由器不重组。目的端靠 (源 IP, 目的 IP, Protocol, Identification) 四元组把同一组的分片归到一起，按 Offset 拼回去；MF = 0 的那片到齐、且中间没有空洞，就算拼完。

为什么 Offset 以 8 字节为单位？因为 13 位的 Offset 域，乘以 8 才能覆盖 16 位的最大长度：2^13 × 8 = 65536，正好够表示最大 65535 字节的数据报。这也意味着每片的载荷长度必须是 8 的倍数（最后一片除外）。

DF 标志与 PMTUD：DF = 1 表示"不要分片"。如果路由器发现包超过 MTU 又被置了 DF，它会丢弃该包，并回一个 ICMP “需要分片” 报文（Fragmentation Needed），把"下游 MTU 是多少"也带上。源端收到后调小包重发——这就是 PMTUD（Path MTU Discovery，路径 MTU 发现）的核心。现代网络强烈推荐用 PMTUD + DF = 1 来避免分片，原因下面说。

分片为什么能避则避：

一片丢，全丢：任一分片在路上丢了，整个数据报就拼不齐，上层（TCP）只能整体重传，放大了丢包代价；

防火墙难处理：分片后第一条之外的片没有 L4 头部，安全策略和 NAT 很难判断，历史上是著名的绕过手法；

重组负担在目的端：占用内存、可能被用来打"重组炸弹"。

所以实践里：应用尽量别发超大包、TCP 配合 PMTUD、UDP 应用自己控制报文大小，能不分片就不分。

五、IPv6 概览

IPv4 地址（32 位）早不够用了，IPv6 把地址扩到 128 位，号称"给每粒沙子都分一个地址"。但 IPv6 不只是"地址变长"，它对头部做了大幅简化。IPv6 基本头部固定 40 字节，没有选项、没有头部校验和、分片相关字段也从基本头里挪走了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0 |Version| Traffic Class | Flow Label |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4 | Payload Length | Next Header | Hop Limit |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 | |
 + +
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24 | |
 + +
 | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 字节 8~23：Source Address（128 位）；字节 24~39：Destination Address（128 位）

字段对照 IPv4 看更清楚：

IPv6 字段	位宽	对应 IPv4 / 说明
Version	4 位	这里是 `6`
Traffic Class	8 位	对应 IPv4 的 DSCP + ECN
Flow Label	20 位	IPv6 新增，标识一条流，便于做 QoS
Payload Length	16 位	只算载荷，不含 40 字节基本头（IPv4 的 Total Length 是含头的）
Next Header	8 位	对应 IPv4 的 Protocol，但还能指向扩展头链（见下）
Hop Limit	8 位	对应 TTL，名字更准确（每跳减 1）
Source / Dest Address	各 128 位	16 字节的 IPv6 地址

IPv6 相对 IPv4 的几个关键变化：

头部更简、转发更快。固定 40 字节、没有头部校验和（校验交给上层和链路层 FCS），路由器转发时不用每跳重算校验和，转发效率更高。

扩展头链代替 Options。IPv6 把可选功能（逐跳选项、路由、分片、IPsec 的 ESP/AH、目的选项）做成一条扩展头链，用 Next Header 一个接一个串起来，最后才接上层协议。基本头永远在前、固定 40 字节，路由器只需看基本头就能转发，绝大多数扩展头只有目的端（或指定节点）才处理。

中间路由不再分片。IPv6 规定路由器不负责分片，只有源端能分（通过分片扩展头）。如果路由器发现包超过下游 MTU，直接丢弃并回 ICMPv6 Packet Too Big，源端据此调小重发（PMTUD）。IPv6 还规定每条链路最低 MTU = 1280 字节，低于这个值必须做适配。

Hop Limit 取代 TTL，机制完全一样（每跳减 1、到 0 丢弃），只是换了个更诚实的名字。

NDP 取代 ARP。IPv6 没有 ARP 协议，地址解析改由 NDP（Neighbor Discovery Protocol，邻居发现协议，RFC 4861）完成——它基于 ICMPv6，用组播（而非广播）来查询邻居的链路层地址。好处是：不再有 ARP 那种全链路广播风暴，也顺带把 ARP 欺骗的老坑换成了新的安全模型（NDP 有 SEND 等机制可加固）。

小结

IP 是无连接、不可靠、尽力而为的网络层协议，可靠性交给上层（TCP）；
IPv4 头部固定 20 字节（可扩到 60），关键字段：Version / IHL（4 字节单位）/ Total Length / TTL / Protocol / 头部校验和 / 源 / 目的 IP，分片靠 Identification + Flags + Fragment Offset 三个字段；
TTL 每跳减 1，到 0 丢弃并回 ICMP Time Exceeded，是防环路的保险丝，也是 traceroute 的原理；
当 IPv4 数据报长度超过出口链路 MTU 且没有禁止分片时，源主机或中间路由器可能分片；重组只在目的端进行。现代实践倾向用 DF = 1 + PMTUD 避免分片（一片丢则全丢、安全设备难处理）；
IPv6 头部固定 40 字节、无校验和、扩展头链代替选项、中间路由不分片、最低 MTU 1280、Hop Limit 取代 TTL、NDP 取代 ARP。

下一篇，我们正式进入 IP 地址的世界——TCP/IP（四）：IP 地址、子网划分与路由 ：地址分类、子网掩码与 CIDR、私有地址、路由表怎么选下一跳。

参考：

RFC 791 — Internet Protocol (IPv4)

RFC 8200 — Internet Protocol, Version 6 (IPv6)

RFC 4861 — Neighbor Discovery for IP version 6 (IPv6)

IANA — Assigned Internet Protocol Numbers

IPv6 packet — Wikipedia

TCP/IP（二）：以太网与链路层——MAC 地址、帧与 ARP

Tue, 19 May 2026 10:00:00 +0800

写在前面

上一篇把分层模型讲完了：OSI 七层、TCP/IP 四层、实际用的五层，还有逐层封装。从这一篇开始，我们沿五层模型自底向上一层层展开。

最底下是物理层（比特、电信号、光纤），它没什么"协议"可讲，略过。再往上就是数据链路层——这一层要解决的问题是：在相邻两个节点之间，怎么把比特组织成可以识别、可以校验的数据单元传过去 。注意是"相邻"——同一根线两头的两台设备，链路层只管这一跳；跨网、跨子网的事留给上面的网络层。

这一篇聚焦工程上最主流的链路技术以太网（Ethernet），讲四件事：MAC 地址、以太网帧、交换机怎么转发、ARP 怎么把 IP 翻译成 MAC。

一、链路层到底管什么

把网络层交下来的 IP 包搬到"对面那台设备"，链路层要做这几件事：

成帧 —— 给 IP 包套上自己的头部和尾部（帧头 + 帧尾），告诉对面"这是一帧、从哪来、到哪去"；
物理寻址 —— 用 MAC 地址在同一链路上定位网卡；
差错检测 —— 帧尾加一段校验码（FCS），接收方算一遍，错了就丢，不交给上层；
介质访问控制 —— 决定谁能在共享介质上发数据（经典以太网用 CSMA/CD，全双工交换式以太网里基本退场）。

要特别强调一点：链路层大多数时候只做"检错 + 丢弃"，不做重传。丢了的帧交给上层（比如 TCP）去补。这也是分层分工的体现——链路层保持简单、快。

一个常被忽略的点：Wi-Fi（IEEE 802.11）和以太网（802.3）是两条不同的链路层，但它们都承载 IP，所以你从 Wi-Fi 切到有线，上层协议毫无感知。这正是分层带来的好处。

二、MAC 地址：网卡的身份证

MAC（Media Access Control）地址是网卡的硬件地址，几个关键事实：

长度 48 位（6 字节），标准名也叫 EUI-48，习惯写成 AA:BB:CC:DD:EE:FF 这种六段十六进制。
传统的 48 位全局 MAC 地址常按 前 3 字节 OUI（Organizationally Unique Identifier，组织唯一标识符）+ 后 3 字节厂商分配部分来理解。IEEE 现在还提供 MA-M、MA-S 等更小的地址号段，因此“前三字节一定是厂商 OUI”适合作为经典模型，而不是覆盖所有现代分配方式的绝对规则。
因此又叫"固化地址"（burned-in address）。但现在的 MAC 未必真的固化：虚拟机网卡、容器 veth、手机随机 MAC（隐私保护）、手工 ip link set 改的 MAC——都是"本地分配"的，不来自 OUI。

关键在于第一字节的最低两位，它们决定了这个地址的性质：

位	名称	0	1
bit 0（最低位）	I/G 位（Individual / Group）	单播	组播 / 广播
bit 1（次低位）	U/L 位（Universal / Local）	全局唯一（OUI）	本地分配

记住几条推论：

单播 MAC 的 I/G 位是 0，目标是某一块网卡；
组播 MAC 的 I/G 位是 1，目标是"一组"网卡；
广播地址 FF:FF:FF:FF:FF:FF 是组播的特例（全 1），目标是本链路上所有设备；
IPv4 组播映射到 MAC 时以 01:00:5E: 开头，IPv6 组播以 33:33: 开头——你抓包看到这两类前缀，就知道是组播流量。

你看到的虚拟机 / 容器 MAC 常以 02: 开头，正是因为第二位被置 1（U/L = 本地），第一位保持 0（单播）。这是"本地单播"地址的典型长相。

三、以太网帧：数据在链路上的信封

一个以太网帧长这样（从左到右逐字节发送）：

1
2
3
4
5


+--------+-----+---------+---------+--------+----------------+-------+
|Preamble| SFD | Dst MAC | Src MAC |Type/Len| Payload | FCS |
| 7 B | 1 B | 6 B | 6 B | 2 B | 46 ~ 1500 B | 4 B |
+--------+-----+---------+---------+--------+----------------+-------+
 前导 + SFD 共 8 B，不计入帧长 从目的 MAC 到 FCS 才算帧：64 ~ 1518 B

逐字段说明：

字段	大小	作用
前导 Preamble	7 字节	交替的 `1010...` 比特，让接收方做时钟同步
SFD	1 字节	帧起始定界符，`10101011`，标志帧开始
目的 MAC	6 字节	接收方网卡地址
源 MAC	6 字节	发送方网卡地址
类型 / 长度	2 字节	见下文
载荷 Payload	46 ~ 1500 字节	上层来的数据（一般就是 IP 包）
FCS	4 字节	CRC32 校验，错了整帧丢弃

几个要点：

前导和 SFD 不算帧长。对经典、无 VLAN 标签的 Ethernet II 帧，“最小帧 64 字节”指的是从目的 MAC 到 FCS：6+6+2+46+4 = 64；“最大帧 1518 字节”是 6+6+2+1500+4 = 1518。802.1Q VLAN 标签会再增加 4 字节，一些网络还支持厂商相关的 Jumbo Frame。最小帧设 64，是历史原因——为了让冲突信号能在 CSMA/CD 里来得及传回发送方。

类型 / 长度的双关：这个字段如果 ≤ 1500 表示"载荷长度"（IEEE 802.3 风格），如果 ≥ 1536（0x0600） 表示"上层协议类型"（Ethernet II 风格）。现代 IP 流量几乎都走 Ethernet II，所以你看到的都是类型。常见的 EtherType：

EtherType	协议
`0x0800`	IPv4
`0x0806`	ARP
`0x86DD`	IPv6
`0x8100`	802.1Q VLAN 标签

经典以太网常见的 MTU = 1500 字节，指的是能够承载的网络层数据包上限。这是当前链路给网络层的约束：一个 IP 包（含 IP 头）超过该链路 MTU 就得想办法——下一篇会讲 IP 分片和 PMTUD。PPPoE、隧道或 overlay 会吃掉额外头部空间，Jumbo Frame 则可能提供更大的 MTU，实际值应以路径和接口配置为准。

FCS 只检错不纠错。错了直接丢，网卡层面就丢了，上层（TCP）感知到丢包再重传。

四、交换机 vs 集线器：冲突域与广播域

这块容易混，先把两个概念钉死：

冲突域（collision domain）：共享同一介质、可能发生冲突的一组设备。集线器所有端口是同一个冲突域；交换机每个端口是独立的冲突域。
广播域（broadcast domain）：一个广播帧能扩散到的范围。没划 VLAN 时，一台交换机的所有端口是同一个广播域；路由器能隔断广播域。

集线器（hub） 是物理层设备，本质是"中继器"：一个端口收到电信号，原样复制到所有其他端口。所以它不认 MAC、不认帧，所有端口抢同一根介质，靠 CSMA/CD 避冲突。今天基本被淘汰。

交换机（switch） 是链路层设备，核心是一张 MAC 地址表（也叫 CAM 表），记录"哪个端口号 ↔ 哪个 MAC"。转发逻辑：

1
2
3
4
5
6
7
8


收到一帧（端口 P，源 MAC = S，目的 MAC = D）：

1. 学习：把 (S → P) 记进 MAC 表（已有就刷新老化时间）
2. 转发：
 - 若 D 在表中，且对应的端口就是 P → 过滤，不回发（避免环路回弹）
 - 若 D 在表中，对应端口是 Q（≠ P）→ 只从 Q 发出去（单播转发）
 - 若 D 不在表中 → 泛洪（flood）：从除 P 外所有端口发出去
 - 若 D 是广播 / 组播 → 泛洪（组播在高级交换机里有 IGMP snooping 精细化，先不展开）

所以交换机的两个本事：靠源 MAC 学习，靠目的 MAC 转发；查不到就泛洪兜底。这让它比集线器高效得多——大多数流量只走目标端口，不再全网广播。

一句话区分：集线器是"大喇叭"（同一冲突域、同一广播域），交换机是"分机总机"（每端口一个冲突域，全机一个广播域）。要切广播域，得上路由器或 VLAN。

五、ARP：IP 怎么翻译成 MAC

现在问题来了：主机 A 要往同子网的主机 B 发一个 IP 包，A 知道 B 的 IP，但帧头要写的是 B 的 MAC，A 一开始并不知道 B 的 MAC 是什么。这就靠 ARP（Address Resolution Protocol，地址解析协议）。

完整流程：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


A（IP=10.0.0.2，MAC=a） ──→ B（IP=10.0.0.5，MAC=b） 同子网

1. A 查本地 ARP 缓存，没有 10.0.0.5 的条目
2. A 发一个 ARP 请求（ARP Request）：
 - 以太网帧目的 MAC = FF:FF:FF:FF:FF:FF（广播）
 - 内容："谁有 10.0.0.5？把 MAC 告诉 10.0.0.2（MAC=a）"
3. 同子网所有主机都收到这个广播，但只有 B 发现"问的是我的 IP"
4. B 回一个 ARP 应答（ARP Reply）：
 - 以太网帧目的 MAC = a（单播，只给 A）
 - 内容："10.0.0.5 的 MAC 是 b"
5. A 把 (10.0.0.5 → b) 存进 ARP 缓存，带老化时间（几分钟到几十分钟不等，各系统不同）
6. 之后 A 直接用 b 当目的 MAC 发 IP 包，不再广播

两个细节值得注意：

请求广播、应答单播。请求是喊一嗓子（广播），应答是悄悄回（单播）。

跨子网时 ARP 找的是网关，不是目标。如果 B 在另一个子网，A 不会去解析 B 的 MAC——A 会把 IP 包（目的 IP 仍是 B）封装成发给默认网关（路由器）MAC 的帧。路由器收到后拆开 IP 头，再决定下一跳怎么转发，下一跳又是一次新的"ARP 找下一跳 MAC"。

这正好呼应分层：IP 地址端到端不变（全程都是 B），MAC 地址逐跳变（每一段链路换成当时那一跳的 MAC）。抓包时如果你看到 IP 目的始终是某台远端主机，而以太网源 / 目的 MAC 一段段在变，就是这个原因。

ARP 欺骗（ARP spoofing）：因为 ARP 没有认证，谁都能冒充应答。攻击者发一个伪造的 ARP 应答，把"网关 IP"指向自己的 MAC，受害主机的流量就被骗到攻击者那里，形成中间人。防御手段：静态 ARP 绑定、交换机的动态 ARP 检测（DAI）、监控异常 MAC 翻转等。

六、既然有了 IP，为什么还要 MAC

这是学网络几乎人人会问的问题——既然 IP 也能定位主机，干嘛还弄一个 MAC？

答案是分层分工，两者解决的问题不在一个层面：

MAC 标识一块网卡：扁平、硬件级、不可路由，只在同一条链路上有意义。换了链路（比如从有线换无线）MAC 也跟着换。
IP 标识主机在网络中的位置：有结构、可聚合、可路由，跨链路全程有效。

打个比方：MAC 像身份证号，唯一但不告诉你人在哪；IP 像邮寄地址，有结构、能路由 。寄一封信，信封上写的是地址（IP），但信件在每一站实际交接时，邮递员要看的是"这一段交给谁"（逐跳的 MAC）。

另一个现实理由是软硬件解耦：

网卡坏了换一块（MAC 变了），IP 不用动，上层连接的逻辑不受影响；
机器从这台物理机迁移到那台（虚拟化迁移），IP 可以保留，由新的网卡（新 MAC）承载。

如果 IP 和硬件地址是同一个东西，这种灵活性就没了。分层让"网络位置（IP）“和"硬件身份（MAC）“独立变化，这正是分层架构的回报。

小结

链路层在相邻两节点之间成帧、寻址、检错；不做可靠重传，交给上层；
常见 MAC 地址为 48 位，传统 MA-L 分配可理解为 OUI + 厂商分配部分；第一字节的 bit 0 是单播 / 组播位，bit 1 是全局 / 本地位；广播 = FF:FF:FF:FF:FF:FF；
经典无标签 Ethernet II 帧 = 前导 + SFD +（目的 / 源 MAC + 类型 + 载荷 + FCS），载荷 46 ~ 1500 字节，常见 MTU = 1500；VLAN 和 Jumbo Frame 会改变边界；
交换机靠源 MAC 学习、靠目的 MAC 转发，查不到就泛洪；每端口一个冲突域，全机一个广播域；
ARP 用广播请求 + 单播应答把 IP 翻译成 MAC；跨子网时解析的是网关 MAC；IP 端到端不变，MAC 逐跳变。

下一篇，我们升一层，进入网络层的核心——TCP/IP（三）：IP 协议——数据报、头部与分片 。

参考：

Ethernet frame — Wikipedia

MAC address — Wikipedia

IEEE 802.3 — Wikipedia

RFC 826 — An Ethernet Address Resolution Protocol

IANA EtherType numbers

TCP/IP（一）：网络分层模型——OSI、TCP/IP 与五层模型

Sun, 17 May 2026 10:00:00 +0800

写在前面

网络是后端、云原生、分布式都绕不开的地基，可它偏偏是那种"天天用、却很少系统学"的东西——出问题时抓包看不懂、调内核参数不知道原理、被人问"TCP 为什么是三次握手"答不完整。

这个系列从分层模型开始，自底向上把 TCP/IP 讲透。第一篇先回答最基础也最重要的问题：网络为什么要分层 ，以及 OSI、TCP/IP、平时说的"五层"这三种模型到底什么关系、怎么对应。

一、为什么需要分层

先想象不分层的网络是什么样：一个大程序要同时管电缆上的电信号、怎么给数据编址、怎么保证可靠、要不要加密、网页是什么格式……只要换一个环节（比如从有线换成无线），整个程序都得重写。

分层把这套极复杂的问题切成互不干扰的几层，每层只解决一件事，对上提供接口、对下使用下层服务。这样换来四个好处：

解耦 —— 换网卡、换链路（有线 / 无线）不影响上面的 HTTP；
复用 —— TCP 这一套可靠性机制，HTTP、SSH、数据库协议都能直接用；
标准化 —— 不同厂商的设备能互通，因为大家都按同一套分层与接口来实现；
可排查 —— 出问题时能按层定位（是物理断了？链路冲突？路由不通？端口被占？还是应用 bug？）。

一句话：分层把"两台机器上的程序互相通信"这件极复杂的事，拆成若干个可独立设计、可替换的简单问题 。

二、OSI 七层模型

OSI（Open Systems Interconnection）是 ISO 在 1984 年提出的参考模型，把网络通信分成七层。它是"教科书标准"，概念清晰，但现实里的协议很少严格按七层实现。

自底向上：

层	名称	负责什么	典型协议 / 设备
7	应用层 Application	为用户程序提供网络服务接口	HTTP、DNS、SMTP、SSH
6	表示层 Presentation	数据格式转换、编码、加解密、压缩	TLS、JPEG、ASCII
5	会话层 Session	建立 / 管理 / 断开会话	（少有独立的会话层协议）
4	传输层 Transport	端到端通信、可靠性与分段	TCP、UDP
3	网络层 Network	跨网络寻址与路由	IP、ICMP、路由器
2	数据链路层 Data Link	相邻节点间成帧、差错检测	以太网、Wi-Fi、交换机
1	物理层 Physical	比特在介质上的传输	电缆、光纤、集线器

记忆顺序（自底向上）：物理、链路、网络、传输、会话、表示、应用。

一个常见疑问：会话层、表示层为什么"没什么存在感"？因为在工程实践中，它们的功能往往被应用层或 TLS 顺手做掉了，没有单独的协议实体。这也是 OSI 在工程上不如 TCP/IP 贴合实际的原因之一。

三、TCP/IP 四层模型

TCP/IP 模型是伴随互联网（ARPANET）一起成长起来的工程模型（也叫 DoD 模型），RFC 1122 把它划成四层。它先有协议、再归纳模型，所以和实际协议贴得很紧——这一点和 OSI 正好相反。

TCP/IP 层	对应 OSI	负责什么	典型协议
应用层 Application	5 / 6 / 7	应用逻辑 + 表示 + 会话全部合并	HTTP、DNS、SMTP、TLS
传输层 Transport	4	端到端通信（端口、可靠性）	TCP、UDP
网际层 Internet	3	跨网寻址与路由	IP、ICMP
网络接口层 Network Access（Link）	1 / 2	物理传输 + 成帧	以太网、Wi-Fi、PPP

最容易混的是命名：TCP/IP 的网际层（Internet layer）对应 OSI 的网络层，别和"网络接口层"搞混——前者管 IP 路由，后者管链路成帧。最底下那层在不同教材里叫法不一（Network Access / Link / Network Interface），指的都是同一层。

四、实际用的五层模型

OSI 太细（会话 / 表示层实际很少单独存在），TCP/IP 太粗（把物理和链路合在一起，不好分开讲）。教学和工程里常用一个折中的五层模型，既好理解，又能一一对应到真实协议：

五层	PDU 名称	典型协议 / 设备
应用层	报文 Message / Data	HTTP、DNS
传输层	段 Segment（TCP）/ 数据报 Datagram（UDP）	TCP、UDP
网络层	包 Packet（IP 数据报）	IP、ICMP、路由器
数据链路层	帧 Frame	以太网、Wi-Fi、交换机
物理层	比特 Bit	电缆、光纤、集线器

本系列后面的篇幅就按五层来展开（链路 → 网络 → 传输 → 应用），既保留 TCP/IP 的工程视角，又不丢 OSI 的概念清晰度。

三者怎么对应？一句话：TCP/IP 把 OSI 的 5/6/7 合成应用层、把 1/2 合成网络接口层；五层模型再把 TCP/IP 的网络接口层拆回物理和链路 。

五、封装与解封装：数据是怎么一层层"穿上"的

分层不是"各干各的就完了"——数据发送时，每一层都会在上层数据外面套一个自己的头部（链路层还会加尾部），这叫封装（encapsulation）；接收端再逐层拆掉，叫解封装。

一次 HTTP 请求从你的机器发出去，要经历：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


应用层： 生成 HTTP 报文
 │ + TCP 头部（源端口 / 目的端口 / 序号 …）
 ▼
传输层： TCP 段（Segment）
 │ + IP 头部（源 IP / 目的 IP / TTL …）
 ▼
网络层： IP 包（Packet）
 │ + 帧头（源 MAC / 目的 MAC）+ 帧尾（FCS）
 ▼
链路层： 以太网帧（Frame）
 │ 转成比特流
 ▼
物理层： 比特（Bit）经网线 / 光纤发出

每一层只认自己的头部，不关心（也看不懂）上层的载荷——这就是"解耦"在数据层面的体现。比如路由器只看到网络层的 IP 头就能决定往哪转发，完全不必读懂 TCP 或 HTTP。

这里出现的 PDU（Protocol Data Unit，协议数据单元）就是每一层处理后产生的数据单元：应用层叫报文、传输层叫段 / 数据报、网络层叫包、链路层叫帧、物理层叫比特。

六、每层靠什么"认人"：地址

各层有各自的寻址方式，互不替代：

层	地址	说明
传输层	端口号	区分同一台机器上的不同进程（如 80 = HTTP）
网络层	IP 地址	跨网络定位主机，可路由
链路层	MAC 地址	同一链路上定位网卡，出厂固化

后面几篇会分别展开：IP 地址怎么划分、路由怎么走（网络层），TCP 怎么用端口建立连接（传输层），ARP 怎么把 IP 翻译成 MAC（链路层）。

小结

分层是为了解耦、复用、标准化、可排查；
OSI 七层是概念参考模型，TCP/IP 四层贴合实际协议，五层模型是教学折中；
数据发送时逐层封装（加头 / 尾），接收时逐层解封装；每层都有自己的 PDU 名称和地址体系。

下一篇：TCP/IP（二）：以太网与链路层 —— MAC 地址、帧结构、交换机怎么转发、ARP 怎么把 IP 变成 MAC。

参考：

OSI model — Wikipedia

Requirements for Internet Hosts (RFC 1122)

TCP/IP Model vs. OSI Model — Fortinet