一、这一节到底在问什么

第四章开篇那句问话是"我们真的知道每天浏览的 Web 网站是如何工作的吗"。从 4.1 一路走到 4.11，零件基本齐了。这一节把它们装起来，回答最后一个问题：

从敲下回车，到页面上出现内容，这段时间里到底执行了哪些处理？

教材把答案收成三段：

二、三个处理，三段接力

三段的关系不是"三件并列的事"，而是一条交接清楚的接力链：

      第一棒                 第二棒                  第三棒
   DNS 域名解析    ──→     HTTP 请求     ──→     HTTP 响应
   拿到：一串域名          拿到：IP + 路径          拿到：请求报文
   给出：一个 IP 地址      给出：一张请求报文       给出：状态码 + 头部 + 正文
   （3.21 · 3.22）        （4.4 · 4.5）           （4.5 · 4.6）

每一棒的"给出"，正是下一棒的"拿到"。 这句话听起来像废话，但它有一个很实际的推论：

任何一棒断了，后面全都不会发生。 —— 解析不出来，就建不了连接；连不上，就发不出请求；请求没送出去，就不会有响应。

而且三棒里，只有第一棒（DNS 解析）通常只做一次，第二、三棒要来回很多遍——这一点后面第六节会讲清。

三、第一棒：DNS 的域名解析

1. 为什么不能跳过这一步

收 3.21 讲过，DNS 是"网络的电话簿"：人记域名，机器认 IP 地址。

麻烦就在这里——你在地址栏里敲的是 shop.example.com，但数据真正要发到某个 IP 地址上。中间这层"翻译"就是第一棒要干的活。而干这活的，是浏览器里那个 DNS 解析模块（收 3.22）。

2. 它不是"问一次就完了"——有缓存层次

这一层是本节值得补上的：同一件事要按顺序往下找，找到就停。

第③层的缓存能存多久，由那条记录的 TTL 决定（收 3.22 的资源记录）。TTL 没到，再来问就直接给你上一次的答案——这就是"第一棒通常不用真的往外跑"的原因。

3. 解析结果不是固定的

一个值得记住的事实：同一个域名，不同时间、不同地点、不同网络，解析出来的 IP 可能不一样。

原因不是出错，而是有意设计：CDN 与就近接入，正是靠"让不同地区的用户解析到离自己最近的那台缓存节点"来加速的（收 4.8 讲的反向代理）。所以你解析出来的那个 IP，很可能根本不是源服务器。

4. 这一棒的产出

一个 IP 地址。 拿到它，第一棒的任务就完成了，交接给第二棒。

四、第二棒：HTTP 请求

1. 严格说，发请求之前还有两小步

拿到 IP 之后不能直接开口说话，得先把"路"接上：

• 建 TCP 连接：和那个 IP 的对应端口三次握手（收 3.18、3.17）
• 谈 TLS：如果网址是 https，还要验证证书、商定密钥（收 4.11）

这两小步合起来，就是"准备工作"里那六步的第④⑤步。它们是第二棒的前置动作，也是"贵的部分"——后面会看到，这两步同样通常只做一次。

2. 请求报文本身：三段结构

收 4.5 讲过的规矩，这里只强调两处最容易忘的：

• 起始行里只有路径，没有域名：GET /index.html HTTP/1.1
• 域名在 Host 头里：Host: shop.example.com

收 4.4 那句结论在这里兑现：服务器永远只看到"路径 + 查询串"。 你在地址栏里敲的六段，到这一棒只剩两段装进了那张纸。

3. 浏览器替你塞进去的一堆东西

这一条很值钱：你什么都没写，但那张纸上已经贴满了标签。

4. 一个页面不止一个请求

收 4.1 讲过的：HTML 里每个 CSS、JS、图片都只是引用，各要单独要一回。

所以第二棒和第三棒会反复来回——这才是"几十上百次请求"的真实来源（后面第六节展开）。

5. 这一棒的产出

一张请求报文，交到服务器手上。

五、第三棒：HTTP 响应

服务器那边接过请求之后做的事，收 4.6 讲得很细，这里按"这一棒"的视角收一遍：

服务器执行四步：收下请求 → 找到内容（静态读文件 / 动态跑程序）→ 装好包装 → 发出响应。

响应报文也是三段（状态行 + 头部 + 空行 + 正文），其中三样最关键：

一个容易忽略的点：响应里装的不一定是网页

同一套 HTTP，运的东西五花八门：

判断依据永远是那个 Content-Type 头，不是文件后缀，也不是"看起来像什么"。

这一棒的产出

一段字节流 + 一份说明，交给浏览器渲染引擎。到这里，三个处理都完成了——但一次访问往往到这里才刚过半。

六、串成一条线：一次访问的完整时序

把三段接起来，从敲回车到看见页面：

七、三个会"拐弯"的地方

上面那条链画得太顺了。实际跑起来，有三处会让它拐个弯——这也是本节最容易漏掉的细节。

1. 缓存命中：链条提前结束

第 3 步查缓存强缓存命中时，整条链连第一棒都不做，直接从本地拿出来显示（收 4.6）。

这就是"第二次打开同一个页面特别快"的原因——不是网变快了，是活儿根本没那么干了。

2. 301 / 302 重定向：整条链再走一遍

收到的响应不是内容，而是一句"东西搬家了，去 Location 里那个地址拿"（收 4.5 的状态码家族）。

浏览器会拿着新地址重新走一遍——建连接、发请求、收响应，如果换了域名还要重新做一次 DNS 解析。

所以 F12 里会看到多出来一轮请求。这不是重复，是规矩要求它再走一遍。

3. CDN / 反向代理：解析出来的 IP 根本不是源服务器

第 4 步解析得到的那个 IP，可能只是离你最近的缓存节点（收 4.8）。你拿到的内容可能是它替你取回来的、甚至是它早就存好的。

所以"同一个域名，不同人解析到不同 IP"不是异常——这正是大型网站让全世界都访问得快的方式。

还有一种"拐弯"：响应里还藏着子资源

第 11 步那个循环，本质上也是"拐弯"：一个响应里可以再引出好几个请求。CSS 里引字体、JS 里调接口、页面里嵌图片——层层套下去，所以页面是"一点点长出来"的（收 4.10 讲的 Web 应用，还会让这个过程变得更频繁）。

八、三段失败，三种现象

这条链有一个非常实际的用法：哪一棒断了，现象是不一样的。

一条最实用的经验："页面本身打不开"和"页面开了但缺东西"，是完全不同的问题。 前者断在前两棒，后者只是某个子资源自己没拿到——页面是好的。

九、动手：Demo49 把三段分开看

第 1 步｜只看第一棒。 命令行敲：

nslookup example.com

得到一个 IP 地址——这就是第一棒的产出。

第 2 步｜换个 DNS 服务器再问一次。

nslookup example.com 8.8.8.8

对比两次结果。不一样是正常的——第一棒的结果可以被有意设计。

第 3 步｜看 DNS 缓存。

ipconfig /displaydns

你会看到一长串"刚查过的域名 + TTL 倒计时"。这就是"第一棒通常只做一次"的证据——本机记着答案，短期内不用再问。

第 4 步｜只看第二、三棒。

curl -v http://example.com/

> 开头的那几行是请求报文（第二棒），< 开头的那几行是响应报文（第三棒）。一条命令，两棒分得清清楚楚。

第 5 步｜只取响应头部。

curl -I https://example.com/

这就是第三棒的前半段——状态码和头部，正文不要。

第 6 步｜让"第一棒失败"长什么样。 把域名换成一个不存在的：

curl -v http://no-such-host-abcxyz.com/

报的是解析失败，而不是连接失败——因为第一棒就没过去，第二棒压根没开始。这一步是本节的核心现场。

第 7 步｜F12 计时栏对时序。 刷新一次页面，看"计时"那一栏的分段：

排队 → DNS 查找 → 连接 → TLS → 等待 → 下载

这六段正好对应上面时序的第 3~9 步。哪段长，问题就在哪段。

第 8 步｜30 秒实验。 数一下这一次访问一共发了多少个请求。回头再看 4.1 那句"几十上百次请求"——现在你能自己解释了：因为第 7~9 步被循环了 N 次。

十、常见误区

1. "DNS 解析每次访问都要做一遍。" —— 有多层缓存（浏览器 → 系统 → DNS 服务器），同一个域名的解析结果通常被缓存复用。一次访问里往往只做一次，TTL 决定多久后要重新问。
2. "一个网页只发一个 HTTP 请求。" —— 主页 + 每个 CSS、JS、图片、字体各一次。第二、三棒要反复来回。
3. "域名解析出来的 IP 是固定的。" —— 不同时间、地点、网络可以解析到不同 IP。CDN 与就近接入正是靠这个工作的。
4. "请求和响应是同一件事的两面，可以合并理解。" —— 它们是两方各自执行的处理：请求是浏览器写的，响应是服务器写的。方向、内容、负责人都不同。
5. "访问慢就是网速慢。" —— 慢可能出在任何一段：DNS 慢、握手慢、服务器慢（等待耗时长）、文件大（下载慢）。必须按段看。
6. "URL 里写了域名，所以服务器知道我在访问哪个域名。" —— 服务器是从 Host 头知道的；请求行里只有路径和查询串（收 4.4）。
7. "响应里一定是网页。" —— 可能是 HTML、CSS、JS、JSON、图片、字体……Content-Type 说了算（收 4.6）。
8. "收到 200 就说明页面对了。" —— 200 只说明这一个请求被正确处理。页面里某张图 404，主页照样是 200。
9. "DNS 解析成功就说明网络是通的。" —— 解析成功只说明问到了 DNS 服务器。后面的建连接、谈加密、发请求都可能失败。
10. "重定向只是换个地址而已。" —— 301/302 会让浏览器从建连接那一步重新来过（换域名时还要重做 DNS 解析）。一次访问变成两轮。

十一、动手自测

十二、下一步学什么

• ☑ 5.1 在同一网络中传输数据（以太网、无线局域网（Wi-Fi）） ✅ 已学 —— 在同一网络中传输数据（以太网、无线局域网（Wi-Fi））（第五章开篇章：本节链路上的时序第 4 步"建连接"往下走，就是第五章要讲的"最后那一段路"——两条路的判据〔同网段走交换机、不同网段交给默认网关〕、以太网与 Wi-Fi 是同一层的两副肉身、介质共用引出 CSMA/CD 与 CSMA/CA 两套规矩、数据帧与"交换机只看门牌"）
• ☐ 5.2（按教材顺序） —— 报个标题接着走：第五章讲的是"同一网络内部怎么送数据"；下一节大概率是以太网的传输机制（帧的格式、MAC 地址与交换机转发的细节）、无线局域网的机制（CSMA/CA、信道、AP 与 SSID），或交换机的作用与转发原理。等你报标题。

相关笔记

• 浏览Web网站时的准备工作（访问Web时使用的应用软件与协议） —— 上一节：访问前的静态准备清单；本节讲访问时实际执行了什么
• 网络的电话簿（域名解析、主机名、DNS） —— 第一棒的理论来源："网络的电话簿"
• 使用DNS自动获取IP地址（资源记录、DNS解析模块、递归查询） —— 第一棒的机制：解析模块、递归查询、资源记录与 TTL
• 对应用程序的数据进行可靠传输（TCP） —— 时序第 5 步的三次握手
• 根据端口号分配数据到应用程序（端口号、已知端口号） —— 连接要连到"对的端口"，80 与 443 的区别
• 数据的发送和接收（IP、IP数据包、路由） —— 拿到 IP 之后，数据包怎么一站站接力到那儿
• Web网站的地址（URL） —— 时序第 2 步"拆 URL"；也是"服务器只看到路径 + 查询串"的出处
• 请求Web网站的文件（HTTP） —— 第二、三棒的报文结构与状态码家族
• 传输Web网站的文件（HTTP响应） —— 服务器那四步；缓存与 304 让链条提前结束
• 记录Web网站的文件（HTTPCookie） —— 请求头上那条 Cookie 是谁自动带上的
• 对Web网站的访问进行代理（代理服务器） —— CDN 与反向代理为什么让解析出的 IP 不是源服务器
• Web浏览器不仅仅是用来浏览网页的（Web应用） —— 响应里那些 JSON 是给脚本吃的；Web 应用让"循环"更频繁
• Web网站是如何构建的（Web网站） —— "一次打开网页从来不是一次请求"，本节给出了机制上的解释
• 网络的网络（互联网） —— 这一整条链，就是"互联网上跑一次 Web 访问"的具体样子
• 在同一网络中传输数据（以太网、无线局域网（Wi-Fi）） —— 下一章：时序里"建连接"之后，数据真正走的最后那一段路，由以太网与 Wi-Fi 完成