DNS、DHCP、HTTP/2/3：一条链路看懂应用层核心协议

写这篇之前，我想先说一个被问烂但确实值得系统回答的问题：当你在浏览器里敲下一个域名回车，这台电脑到底都经历了什么？如果你能把整条链路从头到尾说清楚——DHCP怎么给设备下发地址、DNS怎么把名字变成IP、HTTP又是怎么把页面又快又稳地拉回来——那么计网应用层里最容易混淆、也最常考的三个协议，你就基本通关了。我打算把 DNS、DHCP、HTTP/2.0、HTTP/3.0 放在一条完整的网络请求链路里拆开讲，不照着教材念字段，而是按真实发生的顺序把它们串起来。这篇内容适合期末复习的学生、准备面试的同学，也适合日常需要排障的开发和运维。要是你正被“应用层到底学了个啥”困住，这篇应该能帮你把乱掉的线理顺。

1. 先建个整体框架：DNS、DHCP、HTTP 到底各管哪一段

1.1 从“新设备插网线”到“页面渲染”，一条完整的链路

很多人在学习应用层协议时最大的问题，是把 DNS、DHCP、HTTP 当成三个完全独立的知识点在背，背完发现还是会串台。其实它们分别负责网络请求链路里三个完全不同的阶段：能用、能找到、能传回来。

我刚拿一个新的笔记本连到办公室网络时，设备上可能是空的，没有 IP、没有网关、没有 DNS 服务器地址。这时候第一件事是向网络里的 DHCP 服务器要一份“入网许可证”，拿到地址、网关、DNS 信息之后，这台设备才算真正加入局域网。接着我打开浏览器输入www.example.com，计算机发现自己并不认识这个域名，于是把解析请求交给上一步 DHCP 下发的 DNS 服务器，由它一层层查下去，最终返回站点真实的 IP。拿到 IP 之后，浏览器开始建立连接、发起 HTTP 请求，服务器把页面数据返回，浏览器渲染成我们看到的网页。

这三件事发生的顺序是：先 DHCP 解决“有没有资格上网”，再 DNS 解决“去哪找服务器”，最后 HTTP 解决“怎么高效传输内容”。如果把一次网络访问比作寄快递，DHCP 是帮你拿到有效地址，DNS 是把“XX省XX市XX路”翻译成精确的经纬度坐标，HTTP 则是你最终写出的那份包裹单据和递送规则。三者环环相扣，缺一不可。

1.2 为什么理解协议不能只背报文格式

我见过不少同学能背出 DHCP 的 DORA 四步，却说不清租约时间 T1、T2 到底有什么用；能默写 DNS 的 A、AAAA、CNAME 是什么，遇到实际解析异常却不知道从哪下手。原因很简单：把协议学成了一堆孤立的知识点。

应用的协议最终要落到现实场景。比如你改了公司网站的域名解析记录，等了半天全世界还是访问到旧服务器，这背后是 TTL 和各级缓存的作用；办公网突然一大批设备获取不到 IP，你得能判断是地址池耗尽、DHCP 服务挂了，还是交换机上的 DHCP Snooping 把报文丢了；网站访问慢，你要能分清是 HTTP 连接建立慢、TCP 层丢包严重，还是传输层队头阻塞导致页面资源被强制排队。这些能力不是靠背字段能练出来的，必须把协议放在链路里理解。这也是我写这篇文章的初衷：把协议讲成一条可以走通的路，而不是一张张孤立的纸。

在进入细节前，先看一张我总结的对照表，后面每部分都会围绕这个框架展开：

2. DNS：不止是把域名翻译成 IP 那么简单

2.1 域名的层次结构和记录类型，你得先分清“哪一级在管什么”

DNS 能全球范围正常工作，依赖的是一棵倒挂的树。根域名在最上面，用“.”表示，下面依次是顶级域（如.com、.cn）、二级域（如example.com）、三级域（如www.example.com）。配置权威 DNS 时，你要明确自己管的是哪个区段，这是理解解析过程的基础。

日常最常打交道的其实是不同类型的资源记录。我给团队新人培训时，喜欢用一张表让他们先记住：

很多人在配置时容易搞混 CNAME 和 A 记录。CNAME 本质是“转发”，你请求www.example.com时，解析结果可能是另一个域名example.com，浏览器需要再发起一次查询拿到最终 IP。而 A 记录直接返回 IP，少一次查询，但缺点是 IP 变更时需要挨个修改。我在生产环境的原则是：能用 CNAME 就用 CNAME，特别是需要对接 CDN 的业务，因为 CDN 厂商经常需要给你切流到不同节点，直接给你一个 CNAME 指向，他们就能在不通知你的情况下调度。

2.2 一次完整解析到底要问几次“人”：递归与迭代

这是面试高频考点，也是理解 DNS 的核心难点。当我在浏览器里访问www.example.com，缓存里没有记录时，完整的查询过程是这样的：

1. 浏览器先查自身缓存，没有则查操作系统 hosts 文件和本地 DNS 缓存。
2. 仍然没有，就把请求发给本地 DNS 服务器（通常由 DHCP 下发，比如运营商的 DNS）。
3. 本地 DNS 先查自己的缓存，没有则启动“替客户端跑腿”模式——这就是递归查询，客户端只问一次，剩下的路本地 DNS 走完。
4. 本地 DNS 首先问根服务器：“www.example.com的 IP 是什么？”根服务器不直接知道，但它返回了负责.com顶级域的服务器地址，这个过程叫迭代查询，本地 DNS 一家家问过去。
5. 本地 DNS 继续问.com顶级域服务器，对方返回example.com权威服务器的地址。
6. 本地 DNS 最后问example.com的权威服务器，成功拿到www这条记录对应的 IP。
7. 本地服务器把结果返回给客户端，同时按照 TTL 缓存这份记录。

这里最容易被忽略的是根服务器和顶级域服务器从来不存储具体网站的 IP，它们只负责“指路”。就像你在一栋大厦里问“财务部怎么走”，一楼前台不会直接告诉你房间号，而是告诉你“坐电梯上5楼找财务部前台”。这个机制保证了整个 DNS 系统不需要维护一张无穷大的总表，只需要分级维护自己的那部分数据，这也是互联网能支撑数十亿域名的根本原因。

2.3 缓存、TTL 和那些让你“改了不生效”的坑

实际排障时，DNS 缓存带来的问题比协议本身还多。我帮不少朋友处理过“域名解析记录改了，但电脑上一直打不开新站点”的问题，十有八九是缓存没刷。

TTL（Time To Live）是 DNS 记录里的生存时间，单位是秒。它告诉各级缓存服务器“这条记录最多能保存多久”。如果你给一条 A 记录设置的 TTL 是 600 秒，那么修改记录后，最慢需要等所有缓存过期才能看到新结果。这里有个实际经验：做域名解析迁移前，先把 TTL 调低到 60 秒，等迁移完成后再恢复，能把切换时间从几小时缩短到一分钟级别。这是 DNS 运维里非常实用的操作技巧。

排障的话，我常用的命令是：

# 指定某台 DNS 服务器解析，绕过本机缓存 nslookup www.example.com 223.5.5.5 # 查看详细迭代过程 dig +trace www.example.com # 只看最终答案 dig www.example.com +short

另外要说一个安全相关的点：DNS 劫持和缓存投毒是真实存在的威胁。比如你解析正常的域名，结果被中间人改成了钓鱼服务器地址。解决思路有两个层面，一是使用可信的公共 DNS，二是启用加密 DNS，也就是 DoH（DNS over HTTPS）或 DoT（DNS over TLS）。简单理解，DoH 就是把 DNS 查询请求塞进 HTTPS 流量里加密传输，中间人再也看不到你问了什么域名、也没法篡改返回结果。现在主流浏览器都内置了 DoH 功能，比较大的公共 DNS 服务商也都支持，建议有条件就打开。

3. DHCP：让设备“插线即用”的幕后功臣

3.1 DORA 四步交互，以及租约里藏着的时间参数

从用户视角看，DHCP 的体验就是“网线一插，自动连上”。但从协议视角看，一台设备拿到 IP 一共要经历四个步骤，业界简称DORA：

• Discover（发现）：新设备不知道局域网里有没有 DHCP 服务器，于是向255.255.255.255发送广播包，源地址是0.0.0.0，目标端口是 67。
• Offer（提供）：服务器收到后，在地址池里挑一个可用地址，用广播（如果客户端尚未有 IP）或者单播回应，端口是 68，带着候选 IP、子网掩码、网关、租约时间等信息。
• Request（请求）：客户端可能会收到多个 Offer，它会选择其中一个（通常是最先到达的），然后再次广播一个 Request 告诉所有服务器“我要用哪台给的地址”，没被选中的服务器可以收回候选项。
• Acknowledge（确认）：被选中的服务器最终返回 ACK，正式把这个租约分配给客户端。

这四步里最有意思的是Request 阶段为什么要再广播一次。它的作用不只是告诉服务器“我选你”，更是为了防止地址重复分配：如果有另一台设备已经通过别的服务器拿到了同一个 IP，这次的广播就能让周边设备都知道这个地址即将被占用。这种设计在早期没有冲突检测机制的年代非常关键。

租约时间也不是随便定的。客户端拿到租约后，会在 50% 时间点（T1）尝试向原服务器续租，如果失败，在 87.5% 时间点（T2）进入广播式续租，寻找任意可用服务器。理解这个机制对排障很有用：如果租约时间设成 8 小时，那客户端在第 4 小时就悄悄续约了，而不是等地址过期后重新申请。我曾经排过一个“设备每隔一段时间掉线”的故障，就是因为租约时间设得太短，而 DHCP 服务器负载过高，无法及时响应续约请求。

3.2 跨网段分配：DHCP 中继到底解决了什么问题

DHCP 靠广播工作，但广播不能跨 VLAN 或跨网段。现实里公司网络通常按部门划分 VLAN，DHCP 服务器只有一台在服务器区，这时候就需要DHCP 中继（DHCP Relay）。

中继的原理是：交换机或路由器收到客户端的 Discover 广播后，不直接丢弃，而是把广播包转成单播，发给预先配置好的 DHCP 服务器地址，并在报文的 giaddr 字段填上自己所在网段的网关地址。服务器看到 giaddr 后，就知道客户端属于哪个网段，从对应的地址池里分配地址。

我记得在华为设备上配置中继只有几行：

interface Vlanif 10 ip address 192.168.10.1 255.255.255.0 dhcp select relay dhcp relay server-ip 192.168.0.5

排障经验是：如果客户端能收到 Offer 但最终拿不到地址，优先看一下中继设备上接口地址填的对不对。giaddr 如果写错网段，服务器分配的地址池就不匹配，客户端和服务器之间就会“鸡同鸭讲”。

3.3 服务端配置实操和常见避坑

如果你在 Linux 上临时搭一个 DHCP 服务器，用dhcpd的例子配置一个网段：

subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.100 192.168.10.200; option routers 192.168.10.1; option domain-name-servers 223.5.5.5, 119.29.29.29; default-lease-time 600; max-lease-time 7200; }

这里几个参数要解释一下。range 是动态地址池，客户端从这里随机拿地址；option routers下发的网关就是客户端的默认路由；两台 DNS 服务器之间用逗号分隔，客户端会依次尝试。我更推荐小型网络直接用 dnsmasq，配置简单得多：

dhcp-range=192.168.10.100,192.168.10.200,255.255.255.0,12h dhcp-option=3,192.168.10.1 dhcp-option=6,223.5.5.5,119.29.29.29

实际部署里最容易踩的坑有这几个：

1. 地址池规划不合理。办公网 300 台设备，地址池只放 200 个地址，高峰期必然有设备拿不到 IP，日志里全是 DHCP Discover 无人应答。
2. 把特殊用途的地址也放进了动态池。打印机、门禁这类设备最好用保留地址（按 MAC 固定分配），不然重启后 IP 漂移，依赖固定 IP 的业务直接出问题。
3. 忘记配置 IP 冲突检测。有的环境是双 DHCP 服务器，一旦地址范围设置重合，就会出现两台设备争抢同一地址的诡异问题。

另外提醒一句：排查 DHCP 故障时，先看客户端是否真的发出了 Discover 广播，而不是凭感觉怀疑服务器。用 Wireshark 抓包，过滤dhcp就能看到完整时序，这是最快的定位手段。

4. HTTP/2.0：多路复用到底改了什么

4.1 从 HTTP/1.1 的痛点说起

HTTP/1.1 是我们印象里的经典协议，但它有一个长期被诟病的缺陷——队头阻塞（Head-of-Line Blocking）。早期阶段浏览器对同一域名建立多个 TCP 连接（通常是 6 个），每个连接上一次只能处理一个请求，前一个响应必须完整返回，后一个才轮得到。如果一个请求特别慢，后面排队的资源全部卡住，页面首屏就慢得像蜗牛。

业界想出过一些“绕路”的办法，比如域名分片，把静态资源放在cdn1.example.com、cdn2.example.com上，绕开浏览器同域名连接数限制。但这种做法治标不治本，还会增加 DNS 查询和连接开销。HTTP/2 的目标，就是从根本上解决连接利用效率的问题。

4.2 二进制分帧层：帧、消息、流的关系

HTTP/2 最核心的变化是引入了二进制分帧层（Binary Framing Layer）。HTTP/1.x 的报文是文本形式，以换行符分隔；而 HTTP/2 把请求和响应的数据切成一个个小的二进制帧，并给每一帧打上所属流的编号。

这里有三个层次要分清：

• 流（Stream）：一个完整的请求/响应交换过程，有唯一的流 ID。
• 消息（Message）：与一个请求或响应对应的一系列帧。
• 帧（Frame）：HTTP/2 中最小的数据传输单位，包含流 ID、长度、类型等。

在同一个 TCP 连接上，可以同时交错传输属于不同流的数据帧。比如请求 A 的资源很大，但响应中间还插入了请求 B 的数据帧，接收方再根据流 ID 把碎片拼成完整消息。这就是多路复用的本质：不再需要多个 TCP 连接，同一个连接内并行处理所有请求。

我可以用一个生活化的例子解释：HTTP/1.1 就像单车道收费站，一次只能过一辆车，后面的车必须排队等前车操作完；HTTP/2 直接把收费站改成洗车场，不同车辆并行进多个洗车间，互不干扰。

4.3 HPACK 头部压缩和服务端推送的真相

HTTP/2 的另一个关键优化是HPACK 头部压缩。HTTP/1.x 每次请求都会带上完整的头部，重复的 User-Agent、Accept、Cookie 等字段在几十个请求里反复传输，浪费带宽。HPACK 的思路是：

1. 从预置的静态表中索引常见头部字段，比如:method: GET只需要发送一个整数索引。
2. 通信双方维护一张动态表，首次传输较长的头部内容后，后续相同字段就可以用索引代替。
3. 对字符串使用 Huffman 编码压缩，进一步减小体积。

动态表是上下行各自独立的，各自维护并同步状态。这个机制让头部体积平均能减少 80% 以上，对弱网环境提升非常明显。

至于服务端推送（Server Push），我建议现在的同学不要过度依赖。它本意是服务器在浏览器请求 HTML 时主动把 CSS、JS 推给客户端，省去浏览器发现资源再发请求的往返时间。但实际落地时问题很多：服务器经常不知道浏览器的缓存情况，容易推送一堆客户端本来就有缓存的数据，浪费带宽。主流浏览器后来已经移除了对 HTTP/2 Server Push 的支持，我个人的建议是：静态资源预加载用<link rel="preload">更可控，HTTP/3 时代的策略也基本放弃了 Server Push 这条路。

4.4 实际部署 HTTP/2 的注意事项

如果你准备在 Nginx 或者 CDN 上启用 HTTP/2，有几个现实问题避不开。

第一，绝大多数浏览器只支持基于 TLS 的 HTTP/2。也就是说，你至少需要给站点配上 HTTPS 证书，并在 TLS 握手时通过 ALPN 协议协商出 HTTP/2。如果站点还在裸跑 HTTP，那基本享受不到 HTTP/2 的核心能力。

server { listen 443 ssl; http2 on; # 新版本 Nginx 写法，旧版本直接 listen 443 ssl http2; server_name example.com; ssl_certificate /path/cert.pem; ssl_certificate_key /path/key.pem; }

第二，不是把所有资源都套上 HTTP/2 就万事大吉。大量小图片、小图标其实不适合全部走多路复用，因为每个流都有额外开销。生产环境更好的做法是配合 HTTP 缓存和 CDN，让真正的重复请求在边缘节点就直接命中。

第三，也是很多人忽略的一点——HTTP/2 并没有解决 TCP 层队头阻塞。如果网络丢包，TCP 为了保证有序性，会强制重传并阻塞后续所有流，即便 HTTP/2 已经把一个连接拆成了多个流，它们只要走同一个 TCP 连接，就会一起被“卡脖子”。这就是 HTTP/3 诞生的直接原因。

5. HTTP/3.0：传输层换成 QUIC，快在哪

5.1 为什么 HTTP/2 都用了多路复用，还是觉得不够快

前面刚提到 HTTP/2 的一个未解问题：TCP 层的队头阻塞。这个问题的本质是 TCP 的可靠性机制：接收方收到乱序的包，会在缓冲区里等待缺失的包，缺失的包不到，后续已经到达的包即使完整也不能交付给应用层。一个包丢失，拖慢的是整个连接上的所有流。

举个例子，在一条双向延迟 100ms 的链路上，每 100 个包丢 1 个，TCP 丢包重传加等待带来的延迟放大，会让多个并行资源请求同时卡住。移动互联网时代网络环境差、用户切换频繁，这套设计越来越跟不上节奏。所以 Google 在早期实验了 SPDY（HTTP/2 前身）之后，再次另起炉灶，把底层从 TCP 换成了基于 UDP 的QUIC 协议，网上层是 HTTP/3。

5.2 QUIC 到底改了什么：传输功能重写

QUIC 最大的特点是在用户态实现了很多原本 TCP 和 TLS 内核态承担的功能。它不是一个简单的“UDP + 加密”，而是把传输控制、可靠传输、加密、多路复用全部打包重新设计。

先说多路复用。QUIC 内部同样有流的概念，但它把每个流的传输独立性做到了协议层。在 UDP 这条“大水管”上，可以同时存在多个独立逻辑流，每个流都有自己的序号和可靠传输机制。一个流丢包了，只重传这个流的数据，其他流完全不受影响。这是对 HTTP/2 队头阻塞问题的根除。

再说加密。QUIC 强制集成了 TLS 1.3，并且把 TLS 握手和 QUIC 连接建立合二为一。第一次连接时，客户端和服务器往返一次（1-RTT）就能完成连接并开始发送业务加密数据，而传统 TCP + TLS 需要 TCP 握手加 TLS 握手共两次往返（2-RTT）。如果是重连，TLS 1.3 的会话恢复机制让 QUIC 可以实现0-RTT，客户端可以在发出第一个数据包时直接携带应用数据，省掉整个握手过程。这对高延迟移动网络的体验提升非常可观。

5.3 连接迁移、0-RTT 和其他值得关注的设计

以前 TCP 连接是靠四元组（源 IP、源端口、目的 IP、目的端口）来标识的。Wi-Fi 切到 4G，IP 变了，TCP 连接立刻断开，应用层只能重连。QUIC 对此做了彻底改变：连接使用一个 64 位的连接 ID 来标识，IP 和端口变化不影响连接本身。

这个机制怎么理解呢？把 TCP 连接想象成你拿着一张写有姓名和身份证号的车票，只认名字；QUIC 的连接 ID 则更像一个手环，你换衣服、换座位都不影响身份识别。所以拿着手机从办公室 Wi-Fi 走出门切到移动网络时，HTTP/3 连接不会断，视频通话、WebSocket 这类长连接不会被中断重连。这个能力对移动端的卡顿优化几乎是决定性的。

此外，QUIC 的拥塞控制模块是可插拔的。TCP 的拥塞控制算法要跟着操作系统升级，而 QUIC 在用户态实现，应用层可以随时替换成不同算法。这意味着服务商可以针对实时音视频、网页浏览等不同业务，快速切换最合适的拥塞控制策略，而不用等内核团队更新。

5.4 HTTP/3 生产环境落地现状和选型

到目前，HTTP/3 已经不是新鲜事物。主流浏览器 Chrome、Firefox、Edge、Safari 都默认支持。像 Cloudflare、Google 这些大型 CDN 和云服务商很早就开放了 HTTP/3 接入，国内很多大厂也在推动自家节点支持。不过作为工程人员，我不会建议所有业务无脑切到 HTTP/3。

从实战角度，这几类业务能明显吃到 HTTP/3 的红利：

• 移动端长连接场景，比如即时通讯、推送、音视频通话，连接迁移特性非常宝贵。
• 网络质量不稳定、延迟高、丢包率高的地区，多流独立传输能显著减少感知到的卡顿。
• 首屏请求比较多、依赖并行加载的 Web 应用，0-RTT 和独立流对首屏速度有帮助。

如果当前业务主要跑在机房内网、网络稳定且延迟极低，切到 HTTP/3 的收益相对有限，升级成本却不小。我的建议是：先通过 CDN 开启 HTTP/3 做灰度观察，用 RUM（真实用户监控）数据对比延迟和错误率，再决定是否全量推送到源站。

6. 综合排障：一个现象对应哪一层的问题

6.1 现象一：能上微信却不能打开网页

这类问题我处理过很多次。表现是即时通讯软件正常，但浏览器访问任何网站都提示域名解析失败。初步怀疑 DNS。先用命令行看一下解析是否正常：

nslookup www.example.com

如果返回server can't find，说明本地 DNS 服务器有问题。再看，ping 223.5.5.5通不通，通了说明网络没问题，问题集中在 DNS 上。这时候我会把系统 DNS 临时改成223.5.5.5再试一次，正常了，那就是原 DNS 服务器配置或者链路有问题。

6.2 现象二：办公网新设备获取不到地址

同事拿来一台新笔记本，插上网线后右下角一直转圈，IP 显示 169.254.x.x，这是 Windows 在 DHCP 失败后自分配的保留地址，看到它基本可以锁定是 DHCP 层面的故障。

先查服务器侧：DHCP 服务进程是否存活、地址池是否还有空闲。再看网络侧：如果跨 VLAN，检查中继配置。最后别忘了看交换机上有没有开 DHCP Snooping，有的网络默认开启，且没有把合法 DHCP 服务器端口设为信任接口，广播直接被打掉，这种情况不是服务器的问题，是老实的“安全机制”误杀了合法请求。

6.3 现象三：HTTPS 站点加载极慢

站点能打开，但图片、样式一直转圈，页面整体要扛十几秒。打开浏览器开发者工具，看协议列。如果显示的是http/1.1，那么瓶颈很可能是 HTTP/1.1 的队列排队；如果显示http/2，那要看网络面板的 Waterfall，确认是不是某个大资源占用了太长时间。

如果是http/2且服务器和客户端网络往返不高，还可以怀疑中间网络设备对 UDP 443 流量做了特殊处理。因为 HTTP/3 走的是 UDP，部分防火墙默认只放行 TCP，如果站点曾经支持 H3 而某次网络策略调整后变慢，就要检查这条 UDP 链路。这是我在产线踩过的坑：HTTP/3 的 UDP 端口在中间链路被限速，不降级、也不报错，页面却一直转圈，最难查。

6.4 排查清单速查表

我把上面几种场景合并成一张速查表，贴在日常笔记里，遇到问题照着过一遍：

这个表解决不了所有问题，但它能给排障一个明确起点。每次排障回来，我都会把新的“症状→根因”组合补充进去，慢慢积累成自己的知识库。这是我认为最有效的学习方式：不是记住所有答案，而是建立一套定位问题的路径。

最后再分享一个小技巧。学这三个协议，别只看书，一定要抓包。打开 Wireshark，先过滤dns || dhcp || http2 || quic，然后随便访问一个网站，你会亲眼看到 DORA 的四个包、DNS 查询一层层展开的过程、HTTP/2 的多路复用帧交错在同一个连接上。真实抓包带来的理解，是任何图例和文字都替代不了的。我到现在遇到协议细节回忆不清时，第一反应还是先抓包，再看标准文档，几十次下来，很多模糊的概念就自己串起来了。