写这篇之前我想先说一个被问烂但确实值得系统回答的问题当你在浏览器里敲下一个域名回车这台电脑到底都经历了什么如果你能把整条链路从头到尾说清楚——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 层丢包严重还是传输层队头阻塞导致页面资源被强制排队。这些能力不是靠背字段能练出来的必须把协议放在链路里理解。这也是我写这篇文章的初衷把协议讲成一条可以走通的路而不是一张张孤立的纸。在进入细节前先看一张我总结的对照表后面每部分都会围绕这个框架展开协议端口/底层核心职责一句话类比DHCPUDP 67/68自动分配 IP、网关、DNS 等网络参数入住酒店时前台给你房卡DNSUDP/TCP 53域名到 IP 的映射与查询手机里的联系人通讯录HTTP/2TCP 443/80在 TCP 上实现多路复用传输同一条高速路上并排跑多辆车HTTP/3UDP 443基于 QUIC 解决 TCP 队头阻塞每条车道独立堵车不互相影响2. DNS不止是把域名翻译成 IP 那么简单2.1 域名的层次结构和记录类型你得先分清“哪一级在管什么”DNS 能全球范围正常工作依赖的是一棵倒挂的树。根域名在最上面用“.”表示下面依次是顶级域如.com、.cn、二级域如example.com、三级域如www.example.com。配置权威 DNS 时你要明确自己管的是哪个区段这是理解解析过程的基础。日常最常打交道的其实是不同类型的资源记录。我给团队新人培训时喜欢用一张表让他们先记住记录类型作用典型使用场景A域名指向 IPv4 地址最基础的主机记录AAAA域名指向 IPv6 地址网站支持 IPv6 访问CNAME域名别名指向另一个域名将www指向主域名MX指定邮件服务器邮箱收发信路由NS指定该域名的权威 DNS 服务器域名解析授权TXT任意文本信息域名验证、SPF 邮件防伪SRV指定服务端口企业内网服务发现很多人在配置时容易搞混 CNAME 和 A 记录。CNAME 本质是“转发”你请求www.example.com时解析结果可能是另一个域名example.com浏览器需要再发起一次查询拿到最终 IP。而 A 记录直接返回 IP少一次查询但缺点是 IP 变更时需要挨个修改。我在生产环境的原则是能用 CNAME 就用 CNAME特别是需要对接 CDN 的业务因为 CDN 厂商经常需要给你切流到不同节点直接给你一个 CNAME 指向他们就能在不通知你的情况下调度。2.2 一次完整解析到底要问几次“人”递归与迭代这是面试高频考点也是理解 DNS 的核心难点。当我在浏览器里访问www.example.com缓存里没有记录时完整的查询过程是这样的浏览器先查自身缓存没有则查操作系统 hosts 文件和本地 DNS 缓存。仍然没有就把请求发给本地 DNS 服务器通常由 DHCP 下发比如运营商的 DNS。本地 DNS 先查自己的缓存没有则启动“替客户端跑腿”模式——这就是递归查询客户端只问一次剩下的路本地 DNS 走完。本地 DNS 首先问根服务器“www.example.com的 IP 是什么”根服务器不直接知道但它返回了负责.com顶级域的服务器地址这个过程叫迭代查询本地 DNS 一家家问过去。本地 DNS 继续问.com顶级域服务器对方返回example.com权威服务器的地址。本地 DNS 最后问example.com的权威服务器成功拿到www这条记录对应的 IP。本地服务器把结果返回给客户端同时按照 TTL 缓存这份记录。这里最容易被忽略的是根服务器和顶级域服务器从来不存储具体网站的 IP它们只负责“指路”。就像你在一栋大厦里问“财务部怎么走”一楼前台不会直接告诉你房间号而是告诉你“坐电梯上5楼找财务部前台”。这个机制保证了整个 DNS 系统不需要维护一张无穷大的总表只需要分级维护自己的那部分数据这也是互联网能支撑数十亿域名的根本原因。2.3 缓存、TTL 和那些让你“改了不生效”的坑实际排障时DNS 缓存带来的问题比协议本身还多。我帮不少朋友处理过“域名解析记录改了但电脑上一直打不开新站点”的问题十有八九是缓存没刷。TTLTime 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也就是 DoHDNS over HTTPS或 DoTDNS over TLS。简单理解DoH 就是把 DNS 查询请求塞进 HTTPS 流量里加密传输中间人再也看不到你问了什么域名、也没法篡改返回结果。现在主流浏览器都内置了 DoH 功能比较大的公共 DNS 服务商也都支持建议有条件就打开。3. DHCP让设备“插线即用”的幕后功臣3.1 DORA 四步交互以及租约里藏着的时间参数从用户视角看DHCP 的体验就是“网线一插自动连上”。但从协议视角看一台设备拿到 IP 一共要经历四个步骤业界简称DORADiscover发现新设备不知道局域网里有没有 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 或跨网段。现实里公司网络通常按部门划分 VLANDHCP 服务器只有一台在服务器区这时候就需要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-range192.168.10.100,192.168.10.200,255.255.255.0,12h dhcp-option3,192.168.10.1 dhcp-option6,223.5.5.5,119.29.29.29实际部署里最容易踩的坑有这几个地址池规划不合理。办公网 300 台设备地址池只放 200 个地址高峰期必然有设备拿不到 IP日志里全是 DHCP Discover 无人应答。把特殊用途的地址也放进了动态池。打印机、门禁这类设备最好用保留地址按 MAC 固定分配不然重启后 IP 漂移依赖固定 IP 的业务直接出问题。忘记配置 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与一个请求或响应对应的一系列帧。帧FrameHTTP/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 的思路是从预置的静态表中索引常见头部字段比如:method: GET只需要发送一个整数索引。通信双方维护一张动态表首次传输较长的头部内容后后续相同字段就可以用索引代替。对字符串使用 Huffman 编码压缩进一步减小体积。动态表是上下行各自独立的各自维护并同步状态。这个机制让头部体积平均能减少 80% 以上对弱网环境提升非常明显。至于服务端推送Server Push我建议现在的同学不要过度依赖。它本意是服务器在浏览器请求 HTML 时主动把 CSS、JS 推给客户端省去浏览器发现资源再发请求的往返时间。但实际落地时问题很多服务器经常不知道浏览器的缓存情况容易推送一堆客户端本来就有缓存的数据浪费带宽。主流浏览器后来已经移除了对 HTTP/2 Server Push 的支持我个人的建议是静态资源预加载用link relpreload更可控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 在早期实验了 SPDYHTTP/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 切到 4GIP 变了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 cant 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 排查清单速查表我把上面几种场景合并成一张速查表贴在日常笔记里遇到问题照着过一遍现象优先怀疑协议层第一排查动作常用工具/命令无法解析域名DNS检查系统 DNS 配置换公共 DNS 测试nslookup、dig所有网站打不开但聊天正常DNS/TCPping 外网 IP再测 DNS 解析ping、nslookup设备拿到 169.254 地址DHCP确认 DHCP 服务、地址池、中继Wireshark 过滤dhcpIP 频繁冲突DHCP查地址池保留、静态分配冲突ARP 表、DHCP 日志页面加载慢但首包快HTTP/TCPDevTools 看 Waterfall确认协议版本Chrome DevTools视频长连接断线HTTP/2检查是否切网考虑 H3 连接迁移客户端日志、QUIC 工具这个表解决不了所有问题但它能给排障一个明确起点。每次排障回来我都会把新的“症状→根因”组合补充进去慢慢积累成自己的知识库。这是我认为最有效的学习方式不是记住所有答案而是建立一套定位问题的路径。最后再分享一个小技巧。学这三个协议别只看书一定要抓包。打开 Wireshark先过滤dns || dhcp || http2 || quic然后随便访问一个网站你会亲眼看到 DORA 的四个包、DNS 查询一层层展开的过程、HTTP/2 的多路复用帧交错在同一个连接上。真实抓包带来的理解是任何图例和文字都替代不了的。我到现在遇到协议细节回忆不清时第一反应还是先抓包再看标准文档几十次下来很多模糊的概念就自己串起来了。