2026-02-03 19:41:14 +08:00
|
|
|
|
# 从 URL 到网页显示:一次网络"快递"之旅
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
<script setup>
|
|
|
|
|
|
import UrlToBrowserQuickStart from '../../.vitepress/theme/components/appendix/url-to-browser/UrlToBrowserQuickStart.vue'
|
|
|
|
|
|
import UrlParserDemo from '../../.vitepress/theme/components/appendix/url-to-browser/UrlParserDemo.vue'
|
|
|
|
|
|
import DnsLookupDemo from '../../.vitepress/theme/components/appendix/url-to-browser/DnsLookupDemo.vue'
|
|
|
|
|
|
import TcpHandshakeDemo from '../../.vitepress/theme/components/appendix/url-to-browser/TcpHandshakeDemo.vue'
|
|
|
|
|
|
import HttpExchangeDemo from '../../.vitepress/theme/components/appendix/url-to-browser/HttpExchangeDemo.vue'
|
|
|
|
|
|
import BrowserRenderingDemo from '../../.vitepress/theme/components/appendix/url-to-browser/BrowserRenderingDemo.vue'
|
|
|
|
|
|
</script>
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
> **学习指南**:本章节无需编程基础。我们将用**"寄快递"**的生活化比喻,配合**真实的技术过程**,带你一步步理解浏览器如何将一行网址变成丰富多彩的页面。
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 0. 引言:当你按下回车键的那一刻
|
|
|
|
|
|
|
|
|
|
|
|
想象你要给远方的朋友寄一份礼物。你需要:
|
|
|
|
|
|
1. **填写快递单**(写明地址、收件人)
|
|
|
|
|
|
2. **快递公司查地址**(把"XX市XX区"转换成具体的门牌号)
|
|
|
|
|
|
3. **打电话确认**(确保对方在家能收件)
|
|
|
|
|
|
4. **快递员送达**(把包裹交给对方)
|
|
|
|
|
|
5. **朋友拆开包裹**(看到礼物)
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
**访问网页的过程和寄快递惊人地相似!**
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
当你在浏览器输入 `google.com` 并按下回车,浏览器就是那个"快递员",它要完成一次从"你的电脑"到"远方服务器"再到"屏幕显示"的完整旅程。
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
<UrlToBrowserQuickStart />
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
## 1. 第一步:填写"快递单" —— URL 解析
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
### 生活比喻:填写快递单
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
假设你只在快递单上写"寄给张三",快递员肯定找不到人。你需要写清楚:
|
|
|
|
|
|
- **用什么快递**(顺丰/中通)
|
|
|
|
|
|
- **哪个城市**(北京市)
|
|
|
|
|
|
- **具体地址**(朝阳区XX街道XX号)
|
|
|
|
|
|
- **哪栋楼哪间房**(3号楼201)
|
|
|
|
|
|
- **备注信息**(放快递柜/打电话)
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
### 真实过程:浏览器解析 URL
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
**URL(Uniform Resource Locator,统一资源定位符)**就是浏览器世界的"快递单格式"。当你在地址栏输入 `https://www.example.com:8080/path/page.html?id=123#section`,浏览器会立即拆解它:
|
|
|
|
|
|
|
|
|
|
|
|
| URL 部分 | 示例值 | 快递单类比 | 技术作用 |
|
|
|
|
|
|
|----------|--------|-----------|----------|
|
|
|
|
|
|
| **协议** `https://` | 安全超文本传输协议 | **快递公司**:顺丰(安全)vs 中通(普通) | 决定使用什么规则通信。`http` 是普通传输,`https` 是加密传输 |
|
|
|
|
|
|
| **域名** `www.example.com` | 服务器的人类可读名字 | **收件人姓名**:张三 | 告诉浏览器要找哪台服务器。域名是为了让人记住,最终要转换成 IP 地址 |
|
|
|
|
|
|
| **端口** `:8080` | 服务器的具体"门牌号" | **详细门牌号**:3号楼201(默认不写) | 服务器上可能有多个服务,端口指定访问哪一个。HTTP 默认 80,HTTPS 默认 443 |
|
|
|
|
|
|
| **路径** `/path/page.html` | 服务器上的文件位置 | **房间里的抽屉**:衣柜第二层 | 指定服务器上的具体资源位置 |
|
|
|
|
|
|
| **查询参数** `?id=123` | 附加信息 | **备注**:请轻拿轻放 | 传递给服务器的额外数据,如搜索关键词、页码等 |
|
|
|
|
|
|
| **锚点** `#section` | 页面内的位置 | **书里的页码**:翻到第5页 | 页面加载后自动滚动到指定位置,不发送给服务器 |
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
<UrlParserDemo />
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
> **关键理解**:URL 的存在是为了让**人类**能记住和输入。计算机最终需要的是 **IP 地址**(就像快递员最终需要的是门牌号,而不是"张三的家")。
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
## 2. 第二步:查"地址簿" —— DNS 查询
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
### 生活比喻:查地址簿
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
你告诉快递员"送到张三那里",但快递员怎么知道张三住哪?他需要查地址簿:
|
|
|
|
|
|
1. 先翻**通讯录**(最近联系过的人)→ 浏览器缓存
|
|
|
|
|
|
2. 没有的话问**社区服务中心**(他们知道各个小区归谁管)→ 本地 DNS 服务器
|
|
|
|
|
|
3. 社区问**总管理处**(他们知道XX街道归哪个片区管)→ 根域名服务器
|
|
|
|
|
|
4. 片区查**住户登记**(最终找到张三的门牌号)→ 权威域名服务器
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
### 真实过程:DNS 分层查询
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
**DNS(Domain Name System,域名系统)**是互联网的"分布式地址簿查询系统"。由于全球有数十亿个域名,采用分层架构来分散查询压力:
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
```
|
|
|
|
|
|
你(浏览器)
|
|
|
|
|
|
↓ 问:google.com 的 IP 是多少?
|
|
|
|
|
|
本地 DNS 服务器(你的网络运营商,如电信/联通)
|
|
|
|
|
|
↓ 问:.com 归谁管?
|
|
|
|
|
|
根域名服务器(全球13组根服务器,管理所有顶级域)
|
|
|
|
|
|
↓ 告诉:去问 .com 的管理者
|
|
|
|
|
|
顶级域服务器(Verisign 管理 .com)
|
|
|
|
|
|
↓ 告诉:去问 google.com 的管理者
|
|
|
|
|
|
权威域名服务器(Google 自己的 DNS 服务器)
|
|
|
|
|
|
↓ 告诉:google.com 的 IP 是 142.250.80.46
|
|
|
|
|
|
返回 IP 地址给浏览器
|
|
|
|
|
|
```
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
**查询类型说明:**
|
|
|
|
|
|
- **递归查询(Recursive Query)**:浏览器只发一次请求,本地 DNS 负责层层查询后返回结果
|
|
|
|
|
|
- **迭代查询(Iterative Query)**:每一层只告诉下一层去哪查,浏览器需要多次查询
|
|
|
|
|
|
- **缓存机制**:查询结果会被缓存,下次直接返回,大大加速访问
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
<DnsLookupDemo />
|
|
|
|
|
|
|
|
|
|
|
|
> **为什么需要这么多层?** 想象一下如果全世界只有一个地址簿,几十亿人同时查,早就崩溃了。分层设计让每个层级只管理自己的"辖区",既高效又可靠。
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
## 3. 第三步:打电话确认 —— TCP 三次握手
|
|
|
|
|
|
|
|
|
|
|
|
### 生活比喻:打电话确认
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
假设快递员直接冲到张三家门口,结果:
|
|
|
|
|
|
- 张三不在家 → 白跑一趟
|
|
|
|
|
|
- 电话打不通 → 不知道送哪
|
|
|
|
|
|
- 地址错了 → 送错地方
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
**所以在真正送包裹之前,必须先确认"对方能收到"**。
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
### 真实过程:TCP 三次握手
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
**TCP(Transmission Control Protocol,传输控制协议)**是确保数据可靠传输的规则。在发送任何数据前,客户端和服务器必须通过"三次握手"建立可靠连接:
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
客户端(你的浏览器) 服务器(网站)
|
|
|
|
|
|
| |
|
|
|
|
|
|
|--- SYN=1, seq=x ------------->| 第1次:我想连接你,我的初始序号是 x
|
|
|
|
|
|
| |
|
|
|
|
|
|
|<-- SYN=1, ACK=1, seq=y, ack=x+1 | 第2次:我也想连接你,我的初始序号是 y,期待收到 x+1
|
|
|
|
|
|
| |
|
|
|
|
|
|
|--- ACK=1, ack=y+1 ----------->| 第3次:确认,期待收到 y+1
|
|
|
|
|
|
| |
|
|
|
|
|
|
===== 连接建立,开始传输数据 =====
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**为什么是三次,不是两次?**
|
|
|
|
|
|
|
|
|
|
|
|
- **第一次(SYN)**:客户端证明自己能发送
|
|
|
|
|
|
- **第二次(SYN-ACK)**:服务器证明自己能接收和发送
|
|
|
|
|
|
- **第三次(ACK)**:客户端证明自己能接收
|
|
|
|
|
|
|
|
|
|
|
|
三次握手确保:**双方都能发、双方都能收** —— 四个条件都满足,才能可靠传输。
|
|
|
|
|
|
|
|
|
|
|
|
**TCP 还负责:**
|
|
|
|
|
|
- **数据分包**:大数据拆成小数据包传输
|
|
|
|
|
|
- **顺序重组**:确保数据包按正确顺序组装
|
|
|
|
|
|
- **错误重传**:丢包后自动重新发送
|
|
|
|
|
|
- **流量控制**:根据网络状况调整发送速度
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-01-16 19:10:21 +08:00
|
|
|
|
<TcpHandshakeDemo />
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
> **HTTPS 的额外步骤**:如果是 HTTPS(安全的网站),在 TCP 握手后还会进行 **TLS 握手**(1-RTT 或 2-RTT),双方交换加密密钥,确保之后的对话内容只有双方能看懂,就像用暗语通话。
|
2026-01-15 20:10:19 +08:00
|
|
|
|
|
2026-02-03 19:41:14 +08:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 4. 第四步:"快递员"和"收件人"的对话 —— HTTP 请求与响应
|
|
|
|
|
|
|
|
|
|
|
|
### 生活比喻:快递员送达
|
|
|
|
|
|
|
|
|
|
|
|
快递员敲门:"张三在吗?您的快递!"
|
|
|
|
|
|
张三开门:"好的,给我吧。" 或者 "我没买东西啊,退回去吧。"
|
|
|
|
|
|
|
|
|
|
|
|
### 真实过程:HTTP 协议通信
|
|
|
|
|
|
|
|
|
|
|
|
**HTTP(HyperText Transfer Protocol,超文本传输协议)**是浏览器和服务器之间的"对话规则"。TCP 连接建立后,浏览器发送 HTTP 请求:
|
|
|
|
|
|
|
|
|
|
|
|
**HTTP 请求示例:**
|
|
|
|
|
|
```http
|
|
|
|
|
|
GET /index.html HTTP/1.1 ← 请求方法 + 路径 + 协议版本
|
|
|
|
|
|
Host: www.example.com ← 目标主机(支持虚拟主机,一台服务器可托管多个网站)
|
|
|
|
|
|
User-Agent: Chrome/120.0 ← 客户端标识(服务器可据此返回适配内容)
|
|
|
|
|
|
Accept: text/html,application/xhtml+xml ← 可接受的响应格式
|
|
|
|
|
|
Accept-Language: zh-CN,zh;q=0.9 ← 偏好的语言
|
|
|
|
|
|
Accept-Encoding: gzip, deflate ← 支持的压缩格式
|
|
|
|
|
|
Connection: keep-alive ← 保持连接(复用 TCP 连接)
|
|
|
|
|
|
Cookie: session_id=abc123 ← 身份凭证
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**常见 HTTP 方法:**
|
|
|
|
|
|
- `GET`:获取资源(安全、幂等,可被缓存)
|
|
|
|
|
|
- `POST`:提交数据(创建资源,如注册、登录)
|
|
|
|
|
|
- `PUT`:更新资源(完整替换)
|
|
|
|
|
|
- `PATCH`:部分更新资源
|
|
|
|
|
|
- `DELETE`:删除资源
|
|
|
|
|
|
- `HEAD`:获取响应头(不返回主体,用于检查资源是否存在)
|
|
|
|
|
|
|
|
|
|
|
|
**服务器返回 HTTP 响应:**
|
|
|
|
|
|
```http
|
|
|
|
|
|
HTTP/1.1 200 OK ← 协议版本 + 状态码 + 状态描述
|
|
|
|
|
|
Date: Mon, 23 May 2025 12:00:00 GMT ← 服务器时间
|
|
|
|
|
|
Content-Type: text/html; charset=UTF-8 ← 内容类型和编码
|
|
|
|
|
|
Content-Length: 1234 ← 内容长度(字节)
|
|
|
|
|
|
Cache-Control: max-age=3600 ← 缓存策略
|
|
|
|
|
|
Set-Cookie: user_id=xyz789 ← 设置 Cookie
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**HTTP 状态码分类:**
|
|
|
|
|
|
|
|
|
|
|
|
| 状态码 | 类别 | 含义 | 生活类比 |
|
|
|
|
|
|
|--------|------|------|----------|
|
|
|
|
|
|
| **200** | 成功 | 请求成功处理 | "给,这是你要的" |
|
|
|
|
|
|
| **301/302** | 重定向 | 资源已移动 | "搬家了,去新地址取" |
|
|
|
|
|
|
| **304** | 未修改 | 缓存仍有效 | "和上次一样,不用重新拿" |
|
|
|
|
|
|
| **400** | 客户端错误 | 请求格式错误 | "你说的话我听不懂" |
|
|
|
|
|
|
| **401** | 未授权 | 需要身份验证 | "请出示证件" |
|
|
|
|
|
|
| **403** | 禁止访问 | 权限不足 | "你不准进" |
|
|
|
|
|
|
| **404** | 未找到 | 资源不存在 | "没这个人/没这个东西" |
|
|
|
|
|
|
| **500** | 服务器错误 | 服务器内部错误 | "我们这系统出故障了" |
|
|
|
|
|
|
| **502** | 网关错误 | 上游服务器无响应 | "我们上级部门没回应" |
|
|
|
|
|
|
| **503** | 服务不可用 | 服务器过载或维护 | "今天休息,不营业" |
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
<HttpExchangeDemo />
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 5. 第五步:拆开"包裹" —— 浏览器渲染
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
### 生活比喻:拆开包裹看到礼物
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
快递员把包裹交给张三,张三看到的是**包装盒**。他需要:
|
2026-02-03 19:41:14 +08:00
|
|
|
|
1. **拆开包装**(去掉快递袋)→ 解析 HTML
|
|
|
|
|
|
2. **查看说明书**(了解怎么用)→ 解析 CSS
|
|
|
|
|
|
3. **组装零件**(按说明书拼装)→ 构建渲染树
|
|
|
|
|
|
4. **摆放位置**(确定放哪里)→ 布局计算
|
|
|
|
|
|
5. **最终呈现**(展示成品)→ 绘制到屏幕
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
### 真实过程:浏览器渲染引擎
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
浏览器收到的是 **HTML/CSS/JavaScript 代码**(枯燥的文本),但它要变成**像素画面**(精美的网页)。这个过程叫做**渲染(Rendering)**,由浏览器的**渲染引擎**(如 Chrome 的 Blink、Safari 的 WebKit)执行。
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
#### 步骤1:解析 HTML → 构建 DOM 树
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
浏览器读取 HTML 字节流,按编码(通常是 UTF-8)转换成字符,通过词法分析生成 Token,再解析成 DOM 节点,最终构建成**DOM(Document Object Model,文档对象模型)树**:
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
```html
|
2026-02-03 19:41:14 +08:00
|
|
|
|
<!-- 原始 HTML -->
|
|
|
|
|
|
<html>
|
|
|
|
|
|
<body>
|
|
|
|
|
|
<div class="header">标题</div>
|
|
|
|
|
|
<div class="content">内容</div>
|
|
|
|
|
|
</body>
|
|
|
|
|
|
</html>
|
|
|
|
|
|
```
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
```
|
2026-02-03 19:41:14 +08:00
|
|
|
|
变成树形结构:
|
|
|
|
|
|
Document
|
|
|
|
|
|
│
|
|
|
|
|
|
html
|
|
|
|
|
|
│
|
|
|
|
|
|
body
|
|
|
|
|
|
/ \
|
|
|
|
|
|
div div
|
|
|
|
|
|
.header .content
|
|
|
|
|
|
│ │
|
|
|
|
|
|
"标题" "内容"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
**关键特性:**
|
2026-02-03 19:41:14 +08:00
|
|
|
|
- **流式解析**:浏览器边下载边解析,不需要等整个 HTML 下载完
|
|
|
|
|
|
- **遇到 script 标签**:会暂停解析,先下载并执行 JavaScript(除非加 `async` 或 `defer`)
|
|
|
|
|
|
- **遇到 css 链接**:不会阻塞解析,但会阻塞渲染(需要等 CSS 下载完)
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
#### 步骤2:解析 CSS → 构建 CSSOM 树
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
浏览器同时解析 CSS(内联样式、`<style>` 标签、外部 `.css` 文件),构建**CSSOM(CSS Object Model,CSS 对象模型)树**:
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
```css
|
2026-02-03 19:41:14 +08:00
|
|
|
|
.header { color: blue; font-size: 24px; }
|
|
|
|
|
|
.content { margin: 20px; background: #f0f0f0; }
|
|
|
|
|
|
```
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
CSSOM 树与 DOM 树结构类似,但存储的是样式规则。
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
**CSS 解析特点:**
|
2026-02-03 19:41:14 +08:00
|
|
|
|
- **阻塞渲染**:CSS 会阻塞渲染,因为浏览器不知道元素长什么样就无法绘制
|
|
|
|
|
|
- **层叠和继承**:CSS 的"C"就是 Cascading(层叠),遵循特定的优先级规则
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
#### 步骤3:合并 → 渲染树(Render Tree)
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
|
|
|
|
|
DOM 树 + CSSOM 树 = **渲染树**。渲染树只包含可见元素(`display: none` 的元素不会进入渲染树)。
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
渲染树节点示例:
|
|
|
|
|
|
- 节点类型:div
|
|
|
|
|
|
- 样式:color: blue, font-size: 24px
|
|
|
|
|
|
- 内容:"标题"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
#### 步骤4:布局(Layout / Reflow)
|
|
|
|
|
|
|
|
|
|
|
|
浏览器计算渲染树中每个节点的**精确位置和大小**:
|
|
|
|
|
|
- 视口(viewport)多大?
|
|
|
|
|
|
- 每个元素占多少空间?
|
|
|
|
|
|
- 元素之间如何排列?
|
|
|
|
|
|
|
|
|
|
|
|
这个过程也叫**重排(Reflow)**,是性能开销较大的操作。
|
|
|
|
|
|
|
|
|
|
|
|
**影响布局的因素:**
|
|
|
|
|
|
- 视口大小变化(窗口缩放)
|
|
|
|
|
|
- 元素尺寸变化(内容增减)
|
|
|
|
|
|
- 字体大小变化
|
|
|
|
|
|
- CSS 布局属性变化(`width`、`height`、`margin` 等)
|
|
|
|
|
|
|
|
|
|
|
|
#### 步骤5:绘制(Paint)→ 合成(Composite)
|
|
|
|
|
|
|
|
|
|
|
|
**绘制阶段**:把渲染树的每个节点绘制成像素,填充到**图层(Layer)**中。
|
|
|
|
|
|
|
|
|
|
|
|
**合成阶段**:如果页面有多个图层(如 `position: fixed`、CSS 动画、3D 变换等),浏览器会把这些图层按正确顺序叠加,最终显示到屏幕上。
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
**GPU 加速**:现代浏览器会把某些图层交给 GPU 处理,实现流畅的动画效果。
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
<BrowserRenderingDemo />
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
|
|
|
|
|
> **关键洞察**:渲染是"渐进式"的。浏览器不需要等所有内容都下载完才开始显示,而是收到一部分就渲染一部分。这就是为什么大网页会"慢慢加载出来"。
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 6. 总结:一次完整的"网络快递"之旅
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
|
|
|
|
|
让我们回顾整个旅程:
|
|
|
|
|
|
|
|
|
|
|
|
| 阶段 | 技术术语 | 快递类比 | 核心任务 | 关键技术 |
|
|
|
|
|
|
|------|----------|----------|----------|----------|
|
|
|
|
|
|
| **1. 解析** | URL 解析 | 填写快递单 | 理解用户想访问哪里 | 协议、域名、端口、路径、参数 |
|
|
|
|
|
|
| **2. 查询** | DNS 查询 | 查地址簿 | 把域名转换成 IP 地址 | 递归/迭代查询、缓存机制 |
|
|
|
|
|
|
| **3. 连接** | TCP 握手 | 打电话确认 | 确保双方能可靠通信 | 三次握手、序列号、流量控制 |
|
|
|
|
|
|
| **4. 对话** | HTTP 交换 | 快递员送达 | 请求和传输数据 | 请求方法、状态码、头部字段 |
|
|
|
|
|
|
| **5. 展示** | 浏览器渲染 | 拆开包裹 | 把代码变成画面 | DOM、CSSOM、渲染树、布局、绘制 |
|
|
|
|
|
|
|
|
|
|
|
|
**整个过程通常在几百毫秒内完成** —— 想想这有多么不可思议!
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
你的浏览器在不到1秒的时间里:
|
2026-02-03 19:41:14 +08:00
|
|
|
|
- 解析了一个复杂的地址
|
|
|
|
|
|
- 查询了分布在全球的 DNS 服务器
|
|
|
|
|
|
- 和千里之外的服务器建立了可靠连接
|
|
|
|
|
|
- 进行了一次完整的 HTTP 对话
|
|
|
|
|
|
- 把枯燥的代码变成了精美的画面
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
这就是互联网的魅力:**复杂的技术,简单的体验**。
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 7. 名词速查表 (Glossary)
|
|
|
|
|
|
|
|
|
|
|
|
| 名词 | 全称 | 简单解释 |
|
|
|
|
|
|
|------|------|----------|
|
|
|
|
|
|
| **URL** | Uniform Resource Locator | **统一资源定位符**。网页的"地址",告诉浏览器去哪里找资源。 |
|
|
|
|
|
|
| **DNS** | Domain Name System | **域名系统**。互联网的"电话簿",把人类可读的域名转换成机器可读的 IP 地址。 |
|
|
|
|
|
|
| **IP 地址** | Internet Protocol Address | **互联网协议地址**。每台联网设备的唯一"门牌号",如 `192.168.1.1`。 |
|
|
|
|
|
|
| **TCP** | Transmission Control Protocol | **传输控制协议**。确保数据可靠传输的"规则",通过三次握手建立连接。 |
|
|
|
|
|
|
| **HTTP** | HyperText Transfer Protocol | **超文本传输协议**。浏览器和服务器"对话"的规则。 |
|
|
|
|
|
|
| **HTTPS** | HTTP Secure | **安全的 HTTP**。在 HTTP 基础上加了加密(TLS/SSL),保护数据安全。 |
|
|
|
|
|
|
| **HTML** | HyperText Markup Language | **超文本标记语言**。网页的"骨架",定义内容的结构。 |
|
|
|
|
|
|
| **CSS** | Cascading Style Sheets | **层叠样式表**。网页的"皮肤",定义内容的外观。 |
|
|
|
|
|
|
| **DOM** | Document Object Model | **文档对象模型**。浏览器把 HTML 转换成的树形结构,方便操作。 |
|
|
|
|
|
|
| **CSSOM** | CSS Object Model | **CSS 对象模型**。浏览器把 CSS 转换成的树形结构。 |
|
|
|
|
|
|
| **渲染** | Rendering | 浏览器把代码转换成屏幕像素的过程。 |
|
|
|
|
|
|
| **RTT** | Round Trip Time | **往返时间**。数据包从发送到接收确认的时间,影响网页加载速度。 |
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
2026-01-15 20:10:19 +08:00
|
|
|
|
> **恭喜!** 现在当你再次在地址栏输入网址时,你已经能看到屏幕背后的那个忙碌而精彩的数字世界了。
|
2026-02-03 19:41:14 +08:00
|
|
|
|
|