feat: 更新附录交互组件和文档

docs/zh-cn/appendix/1-computer-fundamentals/computer-networks.md

@@ -1,84 +1,224 @@
 # 计算机网络：从输入网址到返回结果的过程
 
 ::: tip 🎯 核心问题
-**当你在浏览器输入 www.google.com 并按下回车，到底发生了什么？**
+**当你舒服地靠在沙发上，在手机浏览器里输入 `www.google.com` 并按下回车，为什么几百毫秒后，搜索结果就能准确无误地出现在你的屏幕上？**
 
-这个看似简单的动作，背后隐藏着一个庞大精密的跨国“快递系统”。从填写订单（URL解析）到查询地址簿（DNS解析），从建立运输通道（TCP握手）到快递员送货（HTTP请求与响应），最终在你屏幕上拆开包裹组装（浏览器渲染）。本章带你零基础、完整理解这个神奇的过程。
+在上一章中，我们知道了数据是如何被编码成 0 和 1 并通过海底光缆传输的。但这还不够。互联网上的服务器浩如烟海，你的手机是怎么在茫茫机海中精准找到 Google 的服务器，商量好暗号，并成功把页面要回来的呢？
+
+这个看似无比简单的"敲回车"动作，背后其实隐藏着一个精密到令人震撼的跨国"快递接力系统"。本章，我们不讲枯燥的八股文概念，而是顺着**"填写购物单 -> 查地址簿 -> 打电话确认 -> 寄包裹 -> 自己拆解组装"**这条主线，带你零基础看清网络世界的全貌。
 :::
 
 ---
 
-## 全景演示：网络世界的快递系统
+## 第一步：填写购物单 (URL 解析)
 
-你可以通过下方的交互组件，直观地体验从输入网址到看到网页的 5 个关键步骤。先自己点一点，然后再看底下的详细解释！
+**目标**：把人类能看懂的网址，翻译成浏览器能理解的结构化信息。
 
-<UrlToBrowserDemo />
+当你在地址栏中输入 `https://www.google.com/search` 时，浏览器第一步必须先把你输入的这段"人类文字"，仔细拆解成它能看懂的标准化字段。
+
+这就像是你准备去商店买东西，首先要在**购物单**上写清楚：用什么交通工具去、去哪家店、拿什么货。
+
+<UrlParserDemo />
+
+**💡 核心原理解析：URL是怎么分工的？**
+
+- **交通方式（Protocol/协议）**：比如开头写的 `https://`。这代表你要求坐安全级别最高的"运钞车"（加密通信）去。如果是老式的 `http://`，就相当于坐敞篷车，你一路上买什么都会被别人看光。
+- **店铺名（Host/主机名）**：比如 `www.google.com`。这就是你要去哪家店（也就是服务器的域名）。
+- **具体货架（Path/路径）**：比如后面的 `/search`。这代表进了店门之后，你要去哪个房间拿具体的哪份文件。
+
+**这一步完成了什么？** 浏览器现在知道了：我要用 HTTPS 协议，去 `www.google.com` 这个域名对应的服务器，获取 `/search` 路径下的内容。
+
+**但问题来了**：浏览器知道了域名，但网络世界只认数字 IP 地址。就像你知道"王府井大饭店"，但司机需要 GPS 坐标。下一步，我们需要把域名转换成 IP 地址。
 
 ---
 
-## 1. 填写购物单 (URL 解析)
+## 第二步：查地址簿 (DNS 解析)
 
-当你在浏览器的地址栏中输入 `https://www.google.com` 这样一段地址并按下回车，这就像是你准备去商店买东西，首先要在**购物单**上写清楚：
+**上一步完成了**：浏览器拆解了 URL，知道了目标域名是 `www.google.com`。
 
-- **交通方式 (Protocol)**：例如 `https://`，代表你想坐安全级别的最高的“运钞车”（加密通信）去。如果是单纯的 `http://`，就相当于坐普通的“大巴”（明文传输），路上可能会被人偷看行李。
-- **店铺地址 (Host)**：例如 `www.google.com`，也就是你要去哪家店（域名）。
-- **商品位置 (Path)**：例如 `/search`，意思是进了商店之后，你要去哪个货架找什么东西（即请求的具体资源路径）。
+**这一步要实现**：把域名转换成 IP 地址，让浏览器知道服务器的精确位置。
 
-浏览器第一步要做的，就是把这段“人类语言”拆解开，看看你到底想要什么。
+**目的**：网络世界的底层路由器（负责指路的交警）根本不懂英文，它们**只认数字**，也就是所谓的 **IP 地址（如 142.250.80.46）**。
+
+<DnsLookupDemo />
+
+**💡 核心原理解析：找"114查号台"**
+
+既然必须用 IP 地址，浏览器就会走一个叫做 **DNS (Domain Name System)** 的打听流程：
+
+1. **翻自己的备忘录（本地缓存）**：浏览器会先翻翻自己的浏览历史，看看前几天是不是刚去过这家店，记没记过它的数字地址。如果记了，直接用。
+2. **打电话给查号台（递归查询）**：如果实在没见过，它就会向互联网的"总查号台"（通常由你的宽带运营商提供，比如联通、电信的 DNS 服务器）发请求："你好，请帮我查一下，google.com 对应的数字坐标是几？"
+3. **拿到坐标**：查号台通过逐级查询，最终把一个准确的 IP 地址（如 `142.250.80.46`）发回给你的手机。
+
+**这一步完成了什么？** 浏览器现在拿到了 Google 服务器的精确 IP 地址 `142.250.80.46`。
+
+**但问题来了**：有了 IP 地址就能直接发请求了吗？万一服务器宕机了呢？万一网线断了呢？如果直接发请求，对方没收到，就成了鸡同鸭讲。下一步，我们需要先确认双方能正常通信。
 
 ---
 
-## 2. 查找店铺地址 (DNS 解析)
+## 第三步：打电话确认 (TCP 三次握手)
 
-网络世界的“快递员”（路由器设备）是不懂英文的，它们只认数字（也就是 **IP 地址**）。
+**上一步完成了**：浏览器通过 DNS 查询，拿到了服务器的 IP 地址 `142.250.80.46`。
 
-它们需要知道对方的精确数字坐标！这就像快递员不知道“王府井百货”在哪，他必须先查地图，找到“北京市东城区王府井大街255号”这个确切的门牌号（比如 `142.250.66.4`）。
+**这一步要实现**：建立一条可靠的通信通道，确保双方都能收发数据。
 
-- **本地缓存**：浏览器会先翻翻自己的备忘录（看之前有没有访问过该网站）。
-- **DNS 系统**：如果在本地找不到，它就会向互联网的“查号台”（DNS 服务器）打电话询问：“请问 google.com 的数字地址是什么？”。一旦获得了对应的 IP 地址，浏览器的快递车就知道该往哪里开了。
+**目的**：在正式传输数据之前，必须先确认"对方在线"且"双方收发通道都正常"。这就像打电话前要先确认"喂，能听到吗？"
+
+<TcpHandshakeDemo />
+
+**💡 核心原理解析：为什么非得是"三"次？**
+
+不要被专业名词吓到，它完全可以在现实生活中还原。想象一下你给朋友打电话：
 
 ---
 
-## 3. 建立通话 (TCP 握手)
+### 第一次握手：SYN（同步请求）
 
-拿到了地址，浏览器不能直接冲过去，万一店今天没开门呢？所以，要先进行一次**“电话确认”**（这叫建立 TCP 连接）。为了确保通话稳定可靠，会有三次非常严谨的“确认打招呼”机制，行业里叫**三次握手 (Three-way Handshake)**：
+**浏览器发送 SYN 包**
 
-- **第一次握手 (浏览器)**：“喂，你好，我要来买东西，你在吗？” (SYN)
-- **第二次握手 (服务器)**：“我在的，欢迎光临！你也听得到我说话吗？” (SYN-ACK)
-- **第三次握手 (浏览器)**：“我也听到了！那我就要过来了！” (ACK)
+就像你拨通朋友电话后说的第一句话："喂，你好，能听到我说话吗？"
 
-经过这三次确认，双方都知道了彼此的听力和表达能力都没问题，一条稳定可靠的通信通道就正式建立了。
+- **SYN** 是 **Synchronize**（同步）的缩写
+- 浏览器生成一个随机数字（比如 `Seq = 100`），告诉服务器："我要开始建立连接了，我的初始序号是 100"
+- 这个序号用来标记后续发送的数据顺序，防止乱序
+
+**这一步确认了什么？** 服务器收到了浏览器的消息 → 浏览器的**发送通道**正常。
 
 ---
 
-## 4. 购买商品 (HTTP 请求与响应)
+### 第二次握手：SYN-ACK（同步+确认）
 
-通道建好后，业务正式开始。
+**服务器回复 SYN-ACK 包**
 
-- **浏览器（买家）提交订单**：浏览器会打包一份极其规范的订单表格（**HTTP 请求报文**），里面写着：“老板，请给我拿一份你的主页 HTML 文件，我是用 Chrome 浏览器来访问的哦。”
-- **服务器（卖家）根据订单发货**：位于地球另一端的 Google 服务器收到请求后，立刻开始在仓库里配货，生成网页的 HTML 代码，然后打包成包裹（**HTTP 响应报文**），发回给你的浏览器。包裹外面还会贴个标签“200 OK”，意思是“交易成功，你要的货全齐了”。
+就像朋友回答："喂喂，我能听到你！你也能听到我吗？"
+
+- **SYN-ACK** = **Synchronize + Acknowledge**（同步+确认）
+- 服务器做两件事：
+  1. **ACK**：确认收到浏览器的消息（`Ack = 101`，表示"我期待收到你序号为 101 的下一个包"）
+  2. **SYN**：服务器也生成自己的随机序号（比如 `Seq = 200`），告诉浏览器："我的初始序号是 200"
+
+**这一步确认了什么？** 浏览器收到了服务器的回复 → 服务器的**发送通道**正常，浏览器的**接收通道**正常。
 
 ---
 
-## 5. 拆盒组装 (浏览器渲染)
+### 第三次握手：ACK（确认）
 
-最后一步，货物送到了你的电脑。但发过来的只是一堆代码（HTML、CSS、JavaScript），这就好比你网购买了一箱乐高积木，还需要自己组装：
+**浏览器回复 ACK 包**
 
-1. **看说明书 (解析 HTML)**：浏览器先把 HTML 代码解读出来，拼装成网页的骨架（DOM 树）。
-2. **涂抹颜色 (解析 CSS)**：然后检查 CSS 代码，看看字体要多大、按钮是什么颜色，给网页穿上漂亮的外衣（CSSOM 树）。
-3. **计算布局并拼装 (Layout & Paint)**：浏览器计算好每个元素在屏幕上的确切位置，用画笔把它们画在你的显示器上。
-4. **注入灵魂 (执行 JavaScript)**：最后，各种能点击、能滑动的交互效果都通过 JavaScript 激活。
+就像你回答："能听到！那我们开始聊正事吧！"
 
-**只要短短的几百毫秒，所有的步骤就已全部完成，你也就看到了那个熟悉的页面！**
+- **ACK** 是 **Acknowledge**（确认）的缩写
+- 浏览器回复：`Ack = 201`，表示"我期待收到你序号为 201 的下一个包"
+
+**这一步确认了什么？** 服务器收到了浏览器的确认 → 服务器的**接收通道**也正常。
 
 ---
 
-## 总结：从微观到宏观
+### 为什么必须是三次？两次行不行？
 
-如果我们把目光再拉远一点，整个网络通讯的本质，就是在做**接力跑和翻译**：
+**假设只有两次握手：**
 
-- 我们上面看到的这五步，大多是发生在你眼前的**应用程序**层面的事情。
-- 在肉眼看不见的底层，刚才那个充满代码的 HTML 包裹，会被切分成无数块极小的碎片（数据包）。这些碎片顺着你家墙上的网线、海底的万兆光缆，像接力棒一样在各种路由器之间传递。
-- 最终，这一切碎片完好无损地抵达，并在哪怕是几十个毫秒的时间里，化成你屏幕上的绚丽像素。
+1. 浏览器："喂，能听到吗？"
+2. 服务器："能听到！"
 
-这就是计算机网络的神奇魅力！
+这时候服务器以为连接建立了，开始发送数据。但如果服务器的回复在半路丢了，浏览器根本没收到，浏览器就不会认为连接建立成功，也不会处理服务器发来的数据。
+
+**结果**：服务器单方面认为连接已建立，疯狂发数据，但浏览器全当垃圾丢弃。服务器资源被白白浪费。
+
+**三次握手的精妙之处**：
+
+第三次握手的 ACK 包，**证明了浏览器确实收到了服务器的回复**。只有浏览器收到了，才会回复 ACK；服务器收到了这个 ACK，才能**100%确定**双方通道都是通的。
+
+这就像打电话时的完整确认：
+- 你："喂，能听到吗？"（SYN）
+- 朋友："能听到，你呢？"（SYN-ACK）
+- 你："我也能听到！"（ACK）
+
+**这一步完成了什么？** 浏览器和服务器都确认了：**我能发给你，我能收到你的，你也能发给我，你也能收到我的**。一条可靠的 TCP 通道正式建立！
+
+**现在可以开始了吗？** 通道已建立，下一步就是正式发送请求，获取网页内容。
+
+---
+
+## 第四步：寄包裹 (HTTP 请求与响应)
+
+**上一步完成了**：通过 TCP 三次握手，建立了可靠的通信通道。
+
+**这一步要实现**：正式发送请求，获取网页内容。
+
+**目的**：浏览器向服务器"下单"，服务器返回"货物"（网页内容）。
+
+<HttpExchangeDemo />
+
+**💡 核心原理解析：HTTP 请求与响应的小纸条**
+
+浏览器会把你刚才写好的购物单，按照一种极为规范的格式打包（这叫 **HTTP 请求头**），正式塞进刚才建立好的 TCP 通道里，发给服务器。
+
+- **买方发纸条（HTTP Request）**：
+  浏览器发出的包裹里，写着大写的请求指令。如果是看网页就是 `GET`，如果是提交账号密码登录就是 `POST`。不仅如此，这张纸条里还附带了一些重要情报："嗨，我是用 Mac 电脑的 Chrome 浏览器访问的哦，另外我只能听懂中文，请把给我的货也转换成中文。"（这些补充说明就被叫做 **请求 Headers**）。
+
+- **卖方发纸条（HTTP Response）**：
+  位于千里之外的服务器收到这包东西后，看了一眼："哦，他要 `GET` 这个页面啊"。于是服务器飞速在自己的硬盘里找到相应的 HTML 网页代码打包好，在包裹最外面贴上一个标签：`200 OK`（意思是交易非常成功，你要的货全齐了），然后借由同一个通道，原路寄回给你的电脑。
+
+> **小科普**：如果是找不到你要找得页面，服务器就会贴个 `404 Not Found` 的悲伤标签给你退回来。如果是服务器自己代码写错了挂掉了，就会贴个 `500 Server Error` 的崩溃标签。
+
+**这一步完成了什么？** 浏览器收到了服务器返回的 HTML、CSS、JavaScript 代码（也就是网页的"原材料"）。
+
+**但问题来了**：这些代码只是文本，还不是你能看到的网页画面。下一步，浏览器需要把这些代码"翻译"成屏幕上的像素。
+
+---
+
+## 第五步：拆解组装 (浏览器渲染)
+
+**上一步完成了**：通过 HTTP 请求，浏览器获取了网页的源代码（HTML、CSS、JavaScript）。
+
+**这一步要实现**：把代码转换成屏幕上可见的网页画面。
+
+**目的**：将文本代码"翻译"成像素，让用户看到最终的网页。
+
+<BrowserRenderingDemo />
+
+**💡 核心原理解析：毫秒级的画家**
+
+此时你电脑收到的，仅仅是一大串干瘪枯燥的文本代码（HTML 骨架、CSS 色彩图纸、JS 交互动效代码）。这就像你网购了一箱子乐高，它给你的只有几千个塑料零件和一本极度复杂的说明书。
+
+浏览器的组装过程堪比惊心动魄的全自动工厂流水线：
+
+1. **搭骨架 (DOM 解析)**：工人先把 HTML 文件通读一遍，理清楚网页的结构。比如"这里要有一个标题框，那里要有三个图片框"。这个骨架叫做 DOM 树。
+2. **上颜色 (CSS 解析)**：紧接着看 CSS 文件，"哦，老王说标题框必须是红色的，图片框必须有圆角。"
+3. **几何计算排版 (Layout)**：结合骨架和颜色后，开始拿尺子计算。因为每个人的屏幕大小不一样，同样是三个图片框，在手机上只能竖着放，在电脑上可以横着放。必须计算出每一个像素块极其精确的摆放坐标。
+4. **上色绘制 (Paint)**：最后拿起了画笔，按照前面算出来的精确设计图，把真真切切的颜色和像素渲染到了你的显示器上！
+
+**这一步完成了什么？** 浏览器把代码转换成了屏幕上的像素，用户终于看到了完整的网页！
+
+---
+
+## 完整流程回顾
+
+让我们把整个过程串起来：
+
+| 步骤 | 完成了什么 | 下一步需要什么 |
+|------|-----------|---------------|
+| **1. URL 解析** | 拆解网址，知道要去哪 | 需要把域名转成 IP |
+| **2. DNS 解析** | 拿到服务器 IP 地址 | 需要确认服务器在线 |
+| **3. TCP 握手** | 建立可靠通信通道 | 需要发送正式请求 |
+| **4. HTTP 交换** | 获取网页源代码 | 需要把代码转成画面 |
+| **5. 浏览器渲染** | 把代码渲染成像素 | ✅ 用户看到网页！ |
+
+---
+
+## 结语：0.5 秒里发生了什么
+
+敲下回车，等上半秒，页面就跳出来了——我们早就习惯了这个速度，甚至觉得慢。
+
+但仔细想想，就在这眨眼的功夫里：
+
+- **第一步**：浏览器把你输入的网址拆开看懂
+- **第二步**：跑去问了好多台服务器才要到 IP 地址
+- **第三步**：跟大洋彼岸的服务器来回确认了三次"能听见吗"
+- **第四步**：把请求打包发过去，再等着收回来
+- **第五步**：最后还要把成千上万行代码瞬间组装成你能看到的画面
+
+这些步骤一环扣一环，**前一步的输出是后一步的输入**，中间哪个环节出问题，页面就打不开。而那些路由器、服务器、光缆，就默默在后台 24 小时运转，保证你每次滑动手机时，内容都能准时出现。
+
+下次等网页加载的时候，或许可以想想：这 0.5 秒，其实挺忙的。