4.11 浏览Web网站时的准备工作（访问Web时使用的应用软件与协议）

📄 一句话概括

打开一个网页，需要两样东西先就位：一个会用 HTTP 的"应用软件"，和一套配好的"协议"。 应用软件这一侧，主角是浏览器——但浏览器不是一个程序，而是一堆客户端拼起来的一个程序（HTTP 客户端、DNS 解析模块、TCP 客户端、TLS 客户端、缓存、Cookie 仓库、渲染引擎、脚本引擎，各管一段）。协议这一侧，一次访问至少动五个层：应用层（HTTP / HTTPS / DNS）、安全层（TLS）、传输层（TCP / 端口号）、网络层（IP / ICMP / ARP）、网络接口层（以太网 / Wi-Fi）。所以"准备工作"实际上分两半：软件自己做的（拆 URL → 查缓存 → 查 DNS → 建 TCP → 谈加密 → 发请求）和你要做的（装好浏览器、网络配置对、代理设置别残留、缓存与 Cookie 的取舍、系统时间要准）。这一节把它们一条条对到点上——顺手也就得到了一张"网页打不开该先查哪儿"的表。

📝 本节和前面几节的关系

这一节是第四章的"集合点名"：前面每一节讲的是一个角色，这里把角色按出场顺序排成一队。

4.4 的 URL、4.5 的 HTTP、4.6 的缓存、4.7 的 Cookie、4.8 的代理：全都是浏览器内部某一个模块的活
3.17 的端口、3.18 的 TCP、3.21/3.22 的 DNS、3.7 的 IP：也全都在这一条链上，一次访问要依次走过
所以这一节最重要的收获不是新知识，而是一条排查顺序——出了问题时，能知道该从哪一层看起

一、这一节到底在问什么

前面几节回答的是"Web 是什么、怎么运作"。这一节换个角度问一个更实际的问题：

要访问一个 Web 网站，我这台电脑上得先备好什么？

答案分两半，缺一不可：

	谁准备的	具体是什么
软件	你装，它自己跑	浏览器（一个会用多种协议的客户端）
协议	操作系统与网络配置	能解析域名、能建连接、能发请求的一整套能力

二、主角：浏览器是"一堆客户端"打包成的一个程序

收 1.5 讲过：收发数据的主角是应用程序。访问 Web 时，这个主角就是浏览器。

但这里有个容易忽略的事实——浏览器不是一个程序，而是好几个"客户端"拼在一起：

浏览器内部的模块	它的活	出处
URL 处理 / 地址解析	把地址拆成协议、域名、端口、路径	收 4.4
缓存模块	先看本地有没有存过，有就直接用	收 4.6
Cookie 仓库	按域名存那张纸条，每次请求自动带上	收 4.7
DNS 解析模块	域名换成 IP	收 3.22
TCP 客户端	和服务器建立可靠连接（三次握手）	收 3.18
TLS 客户端	HTTPS 时先谈好加密	收 4.8
HTTP 客户端	发请求、收响应	收 4.5
渲染引擎 + 脚本引擎	把收到的 HTML/CSS/JS 画成页面	收 4.2 / 4.3 / 4.10
代理设置	决定请求要不要先送给别人	收 4.8

📝 这一栏表格的用法

每一个模块，都对应一个可能出问题的点。 后面第七节那张"症状 → 病因"表，其实就是这张表的倒推。

也顺带回答了一个常见疑问："为什么换个浏览器有时能解决、有时不能？"——问题在浏览器那几个模块上（缓存、Cookie、扩展、代理设置），换一个就好；问题在下面几层（DNS、线路、防火墙），换谁都没用。

三、敲下回车之后：六步准备依次上岗

从你按下回车，到屏幕上出现第一行字，浏览器内部是这样排队的：

步骤	干什么	一句话
① 拆 URL	把地址分成协议、域名、端口、路径	收 4.4："用 https 去某站 443 号门口拿某个文件"
② 查缓存	本地有现成的吗？有就直接用，连门都不出	收 4.6：强缓存命中时一个请求都不发
③ 查 DNS	域名 → IP（也可能命中本机缓存）	收 3.22：DNS 解析模块的活
④ 建 TCP 连接	和那个 IP 的目标端口三次握手	收 3.18：可靠传输的起点
⑤ 谈加密（仅 HTTPS）	TLS 握手：验证书、商定密钥	4.8/4.9 反复点到的那扇门
⑥ 发 HTTP 请求	送去第一个请求，把首页要回来	收 4.5

⑥ 之后还有一长串：首页一到，浏览器发现它还缺 CSS、JS、图片——于是按同样的路子再跑几十上百次（收 4.1）。

💡 这六步里，有一步是"白跑"的

② 查缓存这一步，在缓存命中时会让整条链提前结束。这也是为什么"刷新一下特别慢、再刷就快了"——第一次出门跑完了全程，第二次在第②步就结束了。

这条顺序还有一个实际用途：页面慢，是慢在哪一步，是可以量出来的（第八节 Demo 里 F12 的"计时"栏就是这份体检表）。

四、协议视角：一次访问至少动了五个层

把软件放到一边，只看"用了哪些协议"，就是下面这样——注意其中每一个你都在前面见过：

层	用到的协议 / 技术	干什么	出处
应用层	HTTP / HTTPS、DNS	要文件、要应答；域名换 IP	4.5 · 4.6 · 3.21
安全层	TLS	把上面的字节加密，顺带验明服务器身份	4.8 · 4.9
传输层	TCP、端口号	可靠送达、把数据送到对的程序	3.17 · 3.18
网络层	IP、ICMP、ARP	找路、报错、把 IP 对应到 MAC	3.7 · 3.15 · 3.16
网络接口层	以太网 / Wi-Fi / MAC	真正把电信号或无线电发出去	3.2 · 2.2

📝 TLS 为什么单独算一层

它夹在应用层和传输层之间，是个"半层"： - 对上面（HTTP）来说：它提供了一条"看起来像普通连接"的通道——HTTP 完全不用知道自己在加密 - 对下面（TCP）来说：它只是"一段要被送走的字节"——TCP 也完全不知道里面是什么

记住这个位置，4.8 那句"HTTPS 之后代理只能看到信封"就顺理成章了：代理在应用层，而加密是它下面那一层干的活。

五、你要做的准备（人这一侧的清单）

软件那半是自动的，这半是你自己得管的：

准备项	为什么重要	出处
装好浏览器	它把上面九种能力打包好了，你不必自己拼	本节第二节
网络配置正确	IP 地址、默认网关、DNS 服务器——错一个就打不开网页	3.12 · 3.23 · 3.7
代理设置	有代理就走代理；设置残留会表现为"上不了网"	4.8 · 4.9
系统时间要准	证书校验依赖时间——时间错太多，HTTPS 会全线报错	4.9
缓存 / Cookie 的取舍	全清掉=慢一点但干净；留着=快但可能看到旧版本	4.6 · 4.7
扩展插件	它们会改写你的请求（拦截广告、注入脚本），也算"准备工作"一环	4.5
默认浏览器	点链接时由谁出面——换个"出面的人"，习惯会变	本节第二节

⚠️ "系统时间"这一条是最反直觉的

它跟网络看起来毫无关系，但 TLS 证书有"生效日期"：时间不对，浏览器没法判断证书是否在有效期内，于是所有 HTTPS 站点一起报证书错误。

所以有一条实战经验："所有网站都报证书错"→ 先看系统时间。

六、Web 客户端不止浏览器

这一点值得单独说，因为它把标题的两个词点透了："应用软件"是选择，"协议"才是标准。

客户端	是什么	和浏览器的关系
`curl` / `wget`	命令行工具	同一套 HTTP，只是没有界面、不会渲染
手机 App 里的 WebView	内嵌的渲染组件	用的是同一套协议，但不一定是完整浏览器
爬虫 / 各种 SDK	程序里的 HTTP 库	完全相同的请求报文，4.5 那套规矩一个不少
在线文档、邮箱等 Web 应用	跑在浏览器里的程序	收 4.10：浏览器同时是它们运行的环境

💡 一个实用推论

同一个网站，换浏览器能打开、浏览器打不开（或者反过来）——问题多半在"客户端这一侧"，不在网络这一侧。

而 curl 之所以是好工具，恰恰因为它把"准备工作"简化到了最低：没有缓存、没有 Cookie（除非你指定）、没有扩展、没有渲染。它能通，说明下面几层都是好的。

七、"准备工作没做好"的症状对照表（本节最实用的一张）

症状	先查哪儿	出处
只有某个网站打不开，其他都正常	DNS（域名解析）	3.21 · 3.22
一直转圈、最后超时	端口 / 防火墙 / 路由可达性	3.17 · 3.7
所有 HTTPS 站点都报证书错	系统时间，其次根证书	4.9
页面出来了但没样式、没图	CSS / 静态资源没取回来	4.3 · 4.1
老看到几天前的旧版本	缓存（清一下或强刷）	4.6
一刷新就退出登录	Cookie 被禁或被清	4.7
能 `ping` 通域名，浏览器却上不了	代理设置残留	4.8
只有自己这台机器打不开	hosts / DNS / 本机代理	3.21

排查的顺序也顺着这条链来：域名（DNS）→ 通不通（ping）→ 端口（telnet）→ 代理 → 缓存与 Cookie → 最后才怀疑网站。

八、动手 Demo（Demo48）：把"准备工作"一条条验一遍

思路：用命令行把第三节那六步拆开来单独验。每一步只用一个命令，哪一步断了立刻就知道。

第 1 步 · 验"③ 查 DNS"

nslookup example.com

看到 Address 里给出的 IP——域名换 IP 这一步是通的。

第 2 步 · 验"④ 能不能到得了"（网络层）

ping example.com

通，说明域名能解析 + 包能往返（这一步动的是 ICMP，收 3.15）。

第 3 步 · 验"④ 建 TCP + ⑤ 谈加密 + ⑥ 发请求"（一网打尽）

curl -v https://example.com

-v 会把全过程打出来，按顺序能看到：

Trying 93.184.216.34:443... ← ④ 建 TCP（IP 和端口都出来了）
SSL connection using TLSv1.3... ← ⑤ 谈加密
> GET / HTTP/1.1 ← ⑥ 发请求（请求行，收 4.5）
< HTTP/1.1 200 OK ← 收到响应（收 4.6）

这就是"准备工作"的完整现场：一条命令把六步里最难看见的四步全打出来了。

第 4 步 · 验"有没有代理挡在中间"

netsh winhttp show proxy

显示"直接访问"就是没走代理；如果显示了一个地址端口，而你又不知道那是谁——这就是"能 ping 通却上不了网"的常见元凶（收 4.8）。

第 5 步 · 在浏览器里看"计时"栏（本节最值得看的一处）

F12 → 网络 → 点任意一条请求 → 看 计时 / Timing 那一栏。它会把第三节那六步按耗时拆开：

排队 → DNS 查询 → 建立连接 → TLS 协商 → 等待服务器响应 → 内容下载

哪一段长，问题就在哪一段。这张图就是"准备工作"的体检报告。

第 6 步 · 亲手制造一次"系统时间不对"（做完要改回来）

把系统时间往后调一天，然后打开任意一个 HTTPS 网站——会报证书错误。

这一步很震撼，因为它说明："时间"也是准备工作的一部分。

⚠️ 实验完立刻把系统时间调回自动同步，否则会影响别的东西（文件时间、软件授权都可能受影响）。

第 7 步 · 收个尾

curl -I http://example.com

只看响应头，把"准备工作"的最后一步——收到响应之后的解读——也过一遍（收 4.6）。

九、30 秒实验

30 秒：nslookup example.com —— 一眼看到"域名换 IP"这一步的结果。
30 秒：F12 → 网络 → 任意请求 → 计时栏 —— 找到"DNS 查询"和"TLS 协商"分别花了多久。
30 秒：netsh winhttp show proxy —— 确认你这台机器有没有被谁"代着走"（收 4.8）。

十、常见误区

"浏览器就是一个软件。" —— 它是一堆客户端拼起来的：HTTP 客户端、DNS 模块、TCP 客户端、TLS 客户端、缓存、Cookie 仓库、渲染引擎，各管一段。
"打开一个网页只用了 HTTP。" —— 一次访问至少动五个层：DNS、TCP、IP、ARP / 以太网，HTTPS 还要多一层 TLS。
"准备工作都是浏览器的事，跟我无关。" —— 代理设置、缓存与 Cookie 的取舍、扩展插件、系统时间、DNS 配置，全在你手上。
"系统时间不准只是小事。" —— 证书校验依赖时间。时间错得多，所有 HTTPS 站点会一起报证书错。
"换个浏览器就能解决网络问题。" —— 问题在浏览器那几个模块上（缓存 / Cookie / 扩展 / 代理设置）时管用；问题在 DNS、线路、防火墙这些下层时，换谁都不管用。
"curl 能打开，说明网站没问题。" —— 反过来用更有价值：curl 是排除浏览器干扰的最好工具（没有缓存、没有 Cookie、没有扩展、不渲染）。
"网页打不开，就是网站挂了。" —— 先按顺序自检：域名 → 通不通 → 端口 → 代理 → 缓存 / Cookie，最后才怀疑网站。
"TLS 是应用层的东西。" —— 它是夹在应用层与传输层之间的"半层"：HTTP 不知道自己在加密，TCP 也不知道自己运的是什么。
"装个拦截插件只影响广告。" —— 它是在改写你的请求，属于"准备工作"的一环；有些网站会因为它的存在而报错。
"手机 App 里的网页也是浏览器。" —— 那是 WebView（内嵌渲染组件），不一定是完整浏览器，但用的是同一套协议（这正是"软件可选、协议是标准"的意思）。

十一、动手自测

❓ 自测一下

访问一个 Web 网站，需要"准备工作"的两半分别是什么？
为什么说"浏览器不是一个程序，而是一堆客户端"？举出其中四个模块。
敲下回车后的六步准备工作是什么？哪一步可能让整条链提前结束？
一次访问至少动了哪五个层？各层用到什么协议？
TLS 为什么算"夹在中间的一层"？它的上面和下面分别是什么？
"系统时间"为什么会影响上网？
换个浏览器就能解决的问题，通常出在哪几个模块上？
"所有网站都打不开"和"只有某个网站打不开"，该分别先查什么？
为什么说 curl 是排查问题的好工具？
Web 客户端不止浏览器——这句话想说明什么？

答案： ① 一个会用 HTTP 的"应用软件"（浏览器）＋一套配好的"协议"（能解析域名、能建连接、能发请求）。② 因为它内部每个协议都对应一个独立模块：URL 处理、缓存模块、Cookie 仓库、DNS 解析模块、TCP 客户端、TLS 客户端、HTTP 客户端、渲染引擎、脚本引擎——各管一段，拼在一起才是一个浏览器。③ ① 拆 URL → ② 查缓存 → ③ 查 DNS → ④ 建 TCP 连接 → ⑤ 谈加密（TLS，仅 HTTPS）→ ⑥ 发 HTTP 请求。② 查缓存这一步命中时会让整条链提前结束——这就是"第二次打开特别快"的原因。④ 应用层（HTTP / HTTPS、DNS）、安全层（TLS）、传输层（TCP、端口号）、网络层（IP、ICMP、ARP）、网络接口层（以太网 / Wi-Fi / MAC）。⑤ 因为它上不碰内容、下不管运输：对上面的 HTTP 来说它提供一条"看起来像普通连接"的通道（HTTP 不知道自己被加密），对下面的 TCP 来说它只是"一段要被送走的字节"。正因为加密在应用层下面，4.8 说代理（应用层）只能看到"信封"。⑥ 因为 TLS 证书有生效日期，浏览器要拿系统时间判断证书是否在有效期内；时间错得多，所有 HTTPS 站点会一起报证书错误。⑦ 通常出在缓存、Cookie、扩展插件、代理设置这几个"客户端侧"的模块上——它们是浏览器自己管的部分。⑧ "所有网站都打不开"：先看本机网络配置、代理设置、线路（下层问题）；"只有某个网站打不开"：先看 DNS（那个域名解析不出来），其次才是那个站本身。⑨ 因为它把"准备工作"简化到了最低——没有缓存、没有 Cookie、没有扩展、不渲染。它通，说明下面几层都是好的；它不通，问题就在下面几层——一刀就把"客户端问题"和"网络问题"分开了。⑩ 说明"软件"是可以换的（浏览器 / curl / 爬虫 / WebView），"协议"是共同的标准。用同一套 HTTP 与 DNS 的东西，都是 Web 客户端。

十二、下一步学什么

☑ 4.12 浏览Web网站时执行的处理（DNS的域名解析、HTTP请求与HTTP响应） —— 已完成：浏览Web网站时执行的处理（DNS的域名解析、HTTP请求与HTTP响应）。本节把那六步"准备"在运行时展开成一条真正的链，也给出了第四章那问的完整回答。
☐ 4.13（按教材顺序） —— 报个标题接着走：本节把一次访问的三个处理完整走了一遍（DNS 解析 → HTTP 请求 → HTTP 响应），也补上了"主线 + N 次循环""三处会拐弯"这些细节；下一节大概率是 用 HTTPS 保护 Web 通信（SSL / TLS）（4.8 / 4.9 / 4.11 三次点到的那扇门，本节时序里第 6 步也是它）、让网页动起来（JavaScript），或第四章小结。等你报标题。