diff --git a/docs/.vitepress/theme/components/appendix/url-to-browser/BrowserRenderingDemo.vue b/docs/.vitepress/theme/components/appendix/url-to-browser/BrowserRenderingDemo.vue index 4a7a257..0b1154f 100644 --- a/docs/.vitepress/theme/components/appendix/url-to-browser/BrowserRenderingDemo.vue +++ b/docs/.vitepress/theme/components/appendix/url-to-browser/BrowserRenderingDemo.vue @@ -1,14 +1,14 @@ diff --git a/docs/.vitepress/theme/components/appendix/url-to-browser/DnsLookupDemo.vue b/docs/.vitepress/theme/components/appendix/url-to-browser/DnsLookupDemo.vue index 01495e6..1173f72 100644 --- a/docs/.vitepress/theme/components/appendix/url-to-browser/DnsLookupDemo.vue +++ b/docs/.vitepress/theme/components/appendix/url-to-browser/DnsLookupDemo.vue @@ -1,724 +1,649 @@ diff --git a/docs/.vitepress/theme/components/appendix/url-to-browser/HttpExchangeDemo.vue b/docs/.vitepress/theme/components/appendix/url-to-browser/HttpExchangeDemo.vue index 9be8441..c9cf206 100644 --- a/docs/.vitepress/theme/components/appendix/url-to-browser/HttpExchangeDemo.vue +++ b/docs/.vitepress/theme/components/appendix/url-to-browser/HttpExchangeDemo.vue @@ -1,135 +1,126 @@ diff --git a/docs/.vitepress/theme/components/appendix/url-to-browser/TcpHandshakeDemo.vue b/docs/.vitepress/theme/components/appendix/url-to-browser/TcpHandshakeDemo.vue index 4cbdb9d..960a129 100644 --- a/docs/.vitepress/theme/components/appendix/url-to-browser/TcpHandshakeDemo.vue +++ b/docs/.vitepress/theme/components/appendix/url-to-browser/TcpHandshakeDemo.vue @@ -1,136 +1,166 @@ @@ -138,52 +168,118 @@ diff --git a/docs/.vitepress/theme/components/appendix/url-to-browser/UrlParserDemo.vue b/docs/.vitepress/theme/components/appendix/url-to-browser/UrlParserDemo.vue index 4463686..f431169 100644 --- a/docs/.vitepress/theme/components/appendix/url-to-browser/UrlParserDemo.vue +++ b/docs/.vitepress/theme/components/appendix/url-to-browser/UrlParserDemo.vue @@ -1,197 +1,253 @@ + \ No newline at end of file diff --git a/docs/.vitepress/theme/components/appendix/url-to-browser/UrlToBrowserQuickStart.vue b/docs/.vitepress/theme/components/appendix/url-to-browser/UrlToBrowserQuickStart.vue index a069480..1909314 100644 --- a/docs/.vitepress/theme/components/appendix/url-to-browser/UrlToBrowserQuickStart.vue +++ b/docs/.vitepress/theme/components/appendix/url-to-browser/UrlToBrowserQuickStart.vue @@ -1,914 +1,637 @@ diff --git a/docs/zh-cn/appendix/url-to-browser.md b/docs/zh-cn/appendix/url-to-browser.md index 3a5f76b..f27aa73 100644 --- a/docs/zh-cn/appendix/url-to-browser.md +++ b/docs/zh-cn/appendix/url-to-browser.md @@ -9,66 +9,66 @@ import HttpExchangeDemo from '../../.vitepress/theme/components/appendix/url-to- import BrowserRenderingDemo from '../../.vitepress/theme/components/appendix/url-to-browser/BrowserRenderingDemo.vue' -> **学习指南**:本章节无需编程基础。我们将用**"寄快递"**的生活化比喻,配合**真实的技术过程**,带你一步步理解浏览器如何将一行网址变成丰富多彩的页面。 +> **学习指南**:本章节无需编程基础。我们将用**"网购"**的生活化比喻,配合**真实的技术过程**,带你一步步理解浏览器如何将一行网址变成丰富多彩的页面。 --- ## 0. 引言:当你按下回车键的那一刻 -想象你要给远方的朋友寄一份礼物。你需要: -1. **填写快递单**(写明地址、收件人) -2. **快递公司查地址**(把"XX市XX区"转换成具体的门牌号) -3. **打电话确认**(确保对方在家能收件) -4. **快递员送达**(把包裹交给对方) -5. **朋友拆开包裹**(看到礼物) +想象你正在进行一次**网购**。你需要: +1. **填写订单**(选好商品,确认收货地址) +2. **系统查找仓库**(根据店铺名找到具体的发货仓库) +3. **建立物流通道**(确保仓库正常营业且能发货) +4. **仓库发货**(快递员把包裹送上门) +5. **拆箱体验**(打开包裹,看到心仪的商品) -**访问网页的过程和寄快递惊人地相似!** +**访问网页的过程和网购惊人地相似!** -当你在浏览器输入 `google.com` 并按下回车,浏览器就是那个"快递员",它要完成一次从"你的电脑"到"远方服务器"再到"屏幕显示"的完整旅程。 +当你在浏览器输入 `google.com` 并按下回车,你就是那个"买家",浏览器通过一系列操作,最终把远方服务器上的"商品"(网页内容)送到你的屏幕上。 --- -## 1. 第一步:填写"快递单" —— URL 解析 +## 1. 第一步:填写"订单" —— URL 解析 -### 生活比喻:填写快递单 +### 生活比喻:填写购物单 -假设你只在快递单上写"寄给张三",快递员肯定找不到人。你需要写清楚: -- **用什么快递**(顺丰/中通) -- **哪个城市**(北京市) -- **具体地址**(朝阳区XX街道XX号) -- **哪栋楼哪间房**(3号楼201) -- **备注信息**(放快递柜/打电话) +假设你只在订单上写"买鞋子",仓库肯定不知道发哪双。你需要写清楚: +- **店铺类型**(官方旗舰店/普通店) +- **店铺名称**(Nike 官方店) +- **商品位置**(男鞋区/跑鞋系列) +- **具体型号**(Air Max 90) +- **备注信息**(我要红色的) ### 真实过程:浏览器解析 URL -**URL(Uniform Resource Locator,统一资源定位符)**就是浏览器世界的"快递单格式"。当你在地址栏输入 `https://www.example.com:8080/path/page.html?id=123#section`,浏览器会立即拆解它: +**URL(Uniform Resource Locator,统一资源定位符)**就是浏览器世界的"商品定位码"。当你在地址栏输入 `https://www.example.com:8080/path/page.html?id=123#section`,浏览器会立即拆解它: -| URL 部分 | 示例值 | 快递单类比 | 技术作用 | +| URL 部分 | 示例值 | 网购类比 | 技术作用 | |----------|--------|-----------|----------| -| **协议** `https://` | 安全超文本传输协议 | **快递公司**:顺丰(安全)vs 中通(普通) | 决定使用什么规则通信。`http` 是普通传输,`https` 是加密传输 | -| **域名** `www.example.com` | 服务器的人类可读名字 | **收件人姓名**:张三 | 告诉浏览器要找哪台服务器。域名是为了让人记住,最终要转换成 IP 地址 | -| **端口** `:8080` | 服务器的具体"门牌号" | **详细门牌号**:3号楼201(默认不写) | 服务器上可能有多个服务,端口指定访问哪一个。HTTP 默认 80,HTTPS 默认 443 | -| **路径** `/path/page.html` | 服务器上的文件位置 | **房间里的抽屉**:衣柜第二层 | 指定服务器上的具体资源位置 | -| **查询参数** `?id=123` | 附加信息 | **备注**:请轻拿轻放 | 传递给服务器的额外数据,如搜索关键词、页码等 | -| **锚点** `#section` | 页面内的位置 | **书里的页码**:翻到第5页 | 页面加载后自动滚动到指定位置,不发送给服务器 | +| **协议** `https://` | 安全超文本传输协议 | **物流方式**:保密配送(HTTPS)vs 普通配送(HTTP) | 决定使用什么规则通信。`http` 是普通传输,`https` 是加密传输 | +| **域名** `www.example.com` | 服务器的人类可读名字 | **店铺名称**:京东超市 | 告诉浏览器要找哪台服务器。域名是为了让人记住,最终要转换成 IP 地址 | +| **端口** `:8080` | 服务器的具体"门牌号" | **柜台编号**:3号柜台(默认不写) | 服务器上可能有多个服务,端口指定访问哪一个。HTTP 默认 80,HTTPS 默认 443 | +| **路径** `/path/page.html` | 服务器上的文件位置 | **货架位置**:日用品区/第三排 | 指定服务器上的具体资源位置 | +| **查询参数** `?id=123` | 附加信息 | **订单备注**:红色、XL码 | 传递给服务器的额外数据,如搜索关键词、页码等 | +| **锚点** `#section` | 页面内的位置 | **说明书页码**:翻到第5页 | 页面加载后自动滚动到指定位置,不发送给服务器 | -> **关键理解**:URL 的存在是为了让**人类**能记住和输入。计算机最终需要的是 **IP 地址**(就像快递员最终需要的是门牌号,而不是"张三的家")。 +> **关键理解**:URL 的存在是为了让**人类**能记住和输入。计算机最终需要的是 **IP 地址**(就像快递员最终需要的是具体的仓库地址,而不是"Nike 官方店"这个名字)。 --- ## 2. 第二步:查"地址簿" —— DNS 查询 -### 生活比喻:查地址簿 +### 生活比喻:查仓库地址 -你告诉快递员"送到张三那里",但快递员怎么知道张三住哪?他需要查地址簿: -1. 先翻**通讯录**(最近联系过的人)→ 浏览器缓存 -2. 没有的话问**社区服务中心**(他们知道各个小区归谁管)→ 本地 DNS 服务器 -3. 社区问**总管理处**(他们知道XX街道归哪个片区管)→ 根域名服务器 -4. 片区查**住户登记**(最终找到张三的门牌号)→ 权威域名服务器 +你下单写的是"Nike 官方店",但物流系统不知道仓库在哪。它需要查地址簿: +1. 先查**常用地址**(最近买过这家吗)→ 浏览器缓存 +2. 没有的话问**小区快递点**(他们知道大区域的分配)→ 本地 DNS 服务器 +3. 问**总部调度中心**(知道.com类店铺归谁管)→ 根域名服务器 +4. 问**品牌管理处**(最终找到 Nike 店铺的真实发货仓库)→ 权威域名服务器 ### 真实过程:DNS 分层查询 @@ -101,29 +101,29 @@ import BrowserRenderingDemo from '../../.vitepress/theme/components/appendix/url ## 3. 第三步:打电话确认 —— TCP 三次握手 -### 生活比喻:打电话确认 +### 生活比喻:建立物流通道 -假设快递员直接冲到张三家门口,结果: -- 张三不在家 → 白跑一趟 -- 电话打不通 → 不知道送哪 -- 地址错了 → 送错地方 +假设物流车直接开到仓库,结果: +- 仓库关门了 → 白跑一趟 +- 仓库爆仓不接单 → 无法发货 +- 找不到卸货口 → 无法对接 -**所以在真正送包裹之前,必须先确认"对方能收到"**。 +**所以在真正发货之前,必须先建立可靠的运输通道**。 ### 真实过程:TCP 三次握手 -**TCP(Transmission Control Protocol,传输控制协议)**是确保数据可靠传输的规则。在发送任何数据前,客户端和服务器必须通过"三次握手"建立可靠连接: +**TCP(Transmission Control Protocol,传输控制协议)**是确保数据可靠传输的规则。在传输商品(数据)前,必须通过"三次握手"建立连接: ``` -客户端(你的浏览器) 服务器(网站) +客户端(你的电脑) 服务器(商家仓库) | | - |--- SYN=1, seq=x ------------->| 第1次:我想连接你,我的初始序号是 x + |--- SYN=1 --------------------->| 第1次:你好,我在家,准备收货!(SYN) | | - |<-- SYN=1, ACK=1, seq=y, ack=x+1 | 第2次:我也想连接你,我的初始序号是 y,期待收到 x+1 + |<-- SYN=1, ACK=1 ---------------| 第2次:收到!我也准备好发货了,你在家吗?(SYN-ACK) | | - |--- ACK=1, ack=y+1 ----------->| 第3次:确认,期待收到 y+1 + |--- ACK=1 --------------------->| 第3次:在的!请发货吧。(ACK) | | - ===== 连接建立,开始传输数据 ===== + ===== 通道建立,开始发货 ===== ``` **为什么是三次,不是两次?** @@ -146,16 +146,16 @@ import BrowserRenderingDemo from '../../.vitepress/theme/components/appendix/url --- -## 4. 第四步:"快递员"和"收件人"的对话 —— HTTP 请求与响应 +## 4. 第四步:"买家"和"商家"的对话 —— HTTP 请求与响应 -### 生活比喻:快递员送达 +### 生活比喻:仓库发货 -快递员敲门:"张三在吗?您的快递!" -张三开门:"好的,给我吧。" 或者 "我没买东西啊,退回去吧。" +物流车到达仓库:"这是订单(HTTP请求),**我要取回商品(网页 HTML 源代码)!**" +仓库管理员核对:"订单有效,这是你要的包裹(**HTML 文件**),请拿好。" ### 真实过程:HTTP 协议通信 -**HTTP(HyperText Transfer Protocol,超文本传输协议)**是浏览器和服务器之间的"对话规则"。TCP 连接建立后,浏览器发送 HTTP 请求: +**HTTP(HyperText Transfer Protocol,超文本传输协议)**是浏览器和服务器之间的"对话规则"。通道建立后,浏览器发送**取货请求**,**核心目标是拿回网页的源代码(HTML 文件)**: **HTTP 请求示例:** ```http @@ -169,6 +169,20 @@ Connection: keep-alive ← 保持连接(复用 TCP 连接) Cookie: session_id=abc123 ← 身份凭证 ``` +::: tip 💡 开发者顿悟:这不就是 API 吗? +**一模一样!** +你平时写的 API 调用(`fetch` / `axios`)和浏览器访问网页,在 **HTTP 层面完全是同一个东西**。 + +它们都是发送一个请求,服务器返回一段文本数据。 +* 如果服务器给的是 **HTML**,浏览器就把它**画出来**(变成网页)。 +* 如果服务器给的是 **JSON**,你的代码就把它**存起来**(用于逻辑处理)。 + +**根本就没有"两种"请求,只有同一种 HTTP 请求,只是返回的数据格式(Content-Type)不同而已。** +这也是为什么理解了 HTTP,你就理解了 90% 的后端 API 原理。 + +如果你想深入学习 API 开发,请参考 [API 章节](./api-intro.md)。 +::: + **常见 HTTP 方法:** - `GET`:获取资源(安全、幂等,可被缓存) - `POST`:提交数据(创建资源,如注册、登录) @@ -193,16 +207,16 @@ Set-Cookie: user_id=xyz789 ← 设置 Cookie | 状态码 | 类别 | 含义 | 生活类比 | |--------|------|------|----------| -| **200** | 成功 | 请求成功处理 | "给,这是你要的" | -| **301/302** | 重定向 | 资源已移动 | "搬家了,去新地址取" | -| **304** | 未修改 | 缓存仍有效 | "和上次一样,不用重新拿" | -| **400** | 客户端错误 | 请求格式错误 | "你说的话我听不懂" | -| **401** | 未授权 | 需要身份验证 | "请出示证件" | -| **403** | 禁止访问 | 权限不足 | "你不准进" | -| **404** | 未找到 | 资源不存在 | "没这个人/没这个东西" | -| **500** | 服务器错误 | 服务器内部错误 | "我们这系统出故障了" | -| **502** | 网关错误 | 上游服务器无响应 | "我们上级部门没回应" | -| **503** | 服务不可用 | 服务器过载或维护 | "今天休息,不营业" | +| **200** | 成功 | 请求成功处理 | "订单确认,马上发货" | +| **301/302** | 重定向 | 资源已移动 | "本店搬家了,请去新店下单" | +| **304** | 未修改 | 缓存仍有效 | "你上次买的还能用,不用重新发货" | +| **400** | 客户端错误 | 请求格式错误 | "订单填写模糊,看不懂" | +| **401** | 未授权 | 需要身份验证 | "请先出示会员卡" | +| **403** | 禁止访问 | 权限不足 | "非内部人员禁止入内" | +| **404** | 未找到 | 资源不存在 | "仓库里没这款商品" | +| **500** | 服务器错误 | 服务器内部错误 | "仓库起火了,暂时发不了货" | +| **502** | 网关错误 | 上游服务器无响应 | "总仓没货了,分仓也调不到" | +| **503** | 服务不可用 | 服务器过载或维护 | "爆单了,暂停接单" | @@ -210,118 +224,89 @@ Set-Cookie: user_id=xyz789 ← 设置 Cookie ## 5. 第五步:拆开"包裹" —— 浏览器渲染 -### 生活比喻:拆开包裹看到礼物 +### 生活比喻:拆箱与组装 -快递员把包裹交给张三,张三看到的是**包装盒**。他需要: -1. **拆开包装**(去掉快递袋)→ 解析 HTML -2. **查看说明书**(了解怎么用)→ 解析 CSS -3. **组装零件**(按说明书拼装)→ 构建渲染树 -4. **摆放位置**(确定放哪里)→ 布局计算 -5. **最终呈现**(展示成品)→ 绘制到屏幕 +你终于收到了快递包裹(HTTP 响应),但打开一看,里面不是现成的家具,而是一堆**零件**(HTML)和一本**组装说明书**(CSS)。作为"买家"(浏览器),你需要亲自动手组装: + +1. **拆开包装**:取出所有零件,核对清单(解析 HTML → DOM 树)。 +2. **阅读说明**:看懂说明书,知道哪个零件该装哪、什么颜色(解析 CSS → CSSOM 树)。 +3. **分类整理**:挑出需要组装的零件,扔掉包装泡沫(`display: none`),准备组装(构建渲染树)。 +4. **测量位置**:用尺子量好房间尺寸,决定每个家具具体摆在哪(布局/回流)。 +5. **上色装饰**:给家具刷漆、贴贴纸(绘制)。 +6. **最终展示**:打扫干净,开灯展示(合成)。 ### 真实过程:浏览器渲染引擎 浏览器收到的是 **HTML/CSS/JavaScript 代码**(枯燥的文本),但它要变成**像素画面**(精美的网页)。这个过程叫做**渲染(Rendering)**,由浏览器的**渲染引擎**(如 Chrome 的 Blink、Safari 的 WebKit)执行。 -#### 步骤1:解析 HTML → 构建 DOM 树 +#### 步骤1:解析 HTML → 构建 DOM 树 (零件清单) -浏览器读取 HTML 字节流,按编码(通常是 UTF-8)转换成字符,通过词法分析生成 Token,再解析成 DOM 节点,最终构建成**DOM(Document Object Model,文档对象模型)树**: +浏览器读取 HTML 字节流,将其解析为**DOM(Document Object Model,文档对象模型)树**。这就像把一堆散乱的零件整理成一个有层级关系的清单: ```html - - -
标题
-
内容
- - +
标题
+
内容
``` -``` -变成树形结构: - Document - │ - html - │ - body - / \ - div div - .header .content - │ │ - "标题" "内容" +```text +DOM 树结构: +Document + └─ html + └─ body + ├─ div.header ("标题") + └─ div.content ("内容") ``` -**关键特性:** -- **流式解析**:浏览器边下载边解析,不需要等整个 HTML 下载完 -- **遇到 script 标签**:会暂停解析,先下载并执行 JavaScript(除非加 `async` 或 `defer`) -- **遇到 css 链接**:不会阻塞解析,但会阻塞渲染(需要等 CSS 下载完) +#### 步骤2:解析 CSS → 构建 CSSOM 树 (说明书) -#### 步骤2:解析 CSS → 构建 CSSOM 树 - -浏览器同时解析 CSS(内联样式、`