浏览器原理与网络 —— 页面如何运行

1.1 进程与线程

• 进程：程序运行的最小资源单位，有独立的内存空间。一个进程崩了不影响其他进程。
• 线程：进程内的执行单元，同一进程的线程共享内存。

Chrome 是多进程浏览器，主要进程：

1.2 渲染进程内部的关键线程

• 主线程：解析 HTML/CSS、执行 JS、布局、绘制——JS 在这里跑，所以 JS 卡顿会卡住渲染。
• 合成线程：把图层拼合成最终画面，transform/opacity 动画在这里做，不占主线程。
• 事件触发线程：管理事件队列。
• 定时器线程：管理 setTimeout 计时（JS 线程忙时定时器会被推迟）。

这也是阶段二事件循环的「物理载体」：主线程跑同步代码和微任务，宏任务从事件队列取。

2.1 完整流程（八步）

1. 输入 URL：地址栏判断是网址还是搜索词。
2. DNS 解析：把域名翻译成服务器 IP（先查本地缓存，再逐级向上查询）。
3. 建立连接：TCP 三次握手 + HTTPS 的 TLS 握手（加密通道协商）。
4. 发送请求：浏览器先查本地缓存，命中则直接使用，不发请求。
5. 服务器响应：返回 HTML（含状态码 200/304 等）。
6. 解析 HTML：构建 DOM 树，遇到 CSS 构建 CSSOM，遇到 JS 先下载执行（可被 defer/async 改变）。
7. 构建渲染树：DOM + CSSOM 合并，剔除 display:none 等不可见节点。
8. 布局 → 绘制 → 合成：计算每个节点位置（布局）、画出像素（绘制）、分层合成（合成）。

2.2 解析 HTML 的细节：为什么 JS 会阻塞

<!-- 普通 script：会阻塞 HTML 解析，先下载并执行完才继续 -->
<script src="a.js"></script>

<!-- defer：并行下载，但等 HTML 解析完才执行（按顺序）-->
<script defer src="a.js"></script>

<!-- async：并行下载，下载完立即执行（不保证顺序）-->
<script async src="a.js"></script>

// 推荐：普通脚本放 body 底部，或使用 defer

2.3 回流（Reflow）与重绘（Repaint）

• 回流：元素尺寸、位置变了，浏览器要重新计算布局（最贵）。触发：改 width/height/margin/padding、增删 DOM、窗口缩放。
• 重绘：样式变了但布局没变，只重新绘制（较便宜）。触发：改 color/background。
• 合成：transform/opacity 变化只触发合成（最便宜，GPU 处理，不占主线程）。

3.1 请求与响应结构

// 请求（请求行 + 请求头 + 请求体）
POST /api/login HTTP/1.1              // 方法 路径 版本
Host: example.com
Content-Type: application/json
Authorization: Bearer <token>

{"username":"zhangsan","password":"***"}

// 响应（状态行 + 响应头 + 响应体）
HTTP/1.1 200 OK                       // 版本 状态码 原因短语
Content-Type: application/json
Cache-Control: max-age=3600

{"token":"eyJ..."}

常用状态码（必须脱口而出）

3.2 请求方法

4.1 强缓存：不请求服务器

// 服务器在响应头里返回，浏览器下次直接用缓存，不发请求
Cache-Control: max-age=3600          // 1 小时内直接用缓存
Cache-Control: no-cache              // 每次都要重新验证（协商）
Cache-Control: no-store              // 完全不缓存
Expires: Wed, 21 Oct 2026 07:28:00 GMT // 老方案，HTTP/1.0，已被 Cache-Control 取代

• 命中强缓存：状态码 200（from memory/disk cache），无网络请求。
• max-age 优先级高于 Expires。

4.2 协商缓存：问服务器还新不新

// 第一次请求：服务器返回资源 + 标识
ETag: "abc123"                        // 内容的指纹（优先级高）
Last-Modified: Wed, 19 Aug 2026 08:00:00 GMT  // 最后修改时间

// 第二次请求：浏览器带上标识问服务器
If-None-Match: "abc123"               // 对应 ETag
If-Modified-Since: Wed, 19 Aug 2026 08:00:00 GMT  // 对应 Last-Modified

// 服务器判断：没变 → 返回 304（无响应体），浏览器用缓存
// 变了 → 返回 200 + 新资源

5.1 HTTPS：加密的 HTTP

• HTTP 明文传输，内容可被窃听、篡改、冒充。HTTPS = HTTP + TLS（加密层）。
• 混合加密：非对称加密（RSA/ECC）安全交换密钥 → 对称加密（AES）高效传输数据。
• 证书的作用：证明「这个网站是真的」——CA 机构签发，浏览器内置信任根。

5.2 HTTP/2 的关键改进

• 多路复用：一个连接并发多个请求，解决 HTTP/1.1 的队头阻塞（一个请求卡住后面全卡）。
• 头部压缩（HPACK）：重复的请求头大幅压缩。
• 二进制分帧：数据以二进制帧传输，更高效。
• 服务端推送：服务器主动推资源（实际用处有限）。

HTTP/3 更进一步：基于 UDP（QUIC），解决了 TCP 层的队头阻塞，连接建立更快（0-RTT），弱网表现更好。

// localStorage 使用（只能存字符串，对象要 JSON 序列化）
localStorage.setItem("theme", "dark");
const theme = localStorage.getItem("theme");   // "dark"
localStorage.removeItem("theme");
// 存对象：JSON.stringify / JSON.parse 包裹

7.1 同源策略

「源」= 协议 + 域名 + 端口，三者完全相同才算同源。浏览器出于安全，默认禁止跨源读取资源。判断例子：

// 页面在 https://a.com:443/index.html
https://a.com/api        // ✅ 同源
https://a.com:8080/api   // ❌ 端口不同
http://a.com/api         // ❌ 协议不同
https://b.com/api        // ❌ 域名不同

7.2 CORS（跨域资源共享）：正规的解法

核心思路：服务器在响应头里「批准」某个源可以访问。浏览器看到许可就放行。

// 服务器返回的响应头（关键就这一行）
Access-Control-Allow-Origin: https://a.com   // 允许哪个源；* 表示任意源

// 复杂请求（自定义头、非简单方法）会先发 OPTIONS 预检
// 服务器回应：
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true      // 允许携带 Cookie（此时 Origin 不能是 *）

其他跨域方案

• JSONP：用 script 标签不受同源限制的漏洞，只支持 GET，老方案。
• 代理：开发期用构建工具代理，生产期用 Nginx 反向代理，把跨域请求变成同源。
• postMessage：iframe 间跨源通信。

8.1 XSS（跨站脚本攻击）

攻击者把恶意脚本注入页面，脚本在受害者浏览器里执行，可偷 Cookie、伪造操作、窃取数据。

// 反射型/存储型：把用户输入当 HTML 输出
// ❌ 危险：用户在评论区输入 <script>偷Cookie</script>，被执行
comment.innerHTML = userInput;

// ✅ 安全：用 textContent，内容只当纯文本
comment.textContent = userInput;

三类 XSS

防御三板斧

1. 转义输出：所有用户内容按纯文本处理（textContent / 框架自带转义如 React 默认转义）。
2. CSP（内容安全策略）：服务器设 Content-Security-Policy，只允许指定来源的脚本执行。
3. Cookie 加 HttpOnly：脚本读不到 Cookie，偷了也没用。

8.2 CSRF（跨站请求伪造）

攻击者诱导你点开一个恶意页面，该页面偷偷向你的目标网站发请求——浏览器自动带上你的 Cookie，服务器以为是你在操作。

// 攻击页面里藏着一个自动发出的请求：
<img src="https://bank.com/api/transfer?to=黑客&amount=10000">
// 你的 Cookie 会自动带上，服务器以为是你的操作！

防御三板斧

1. SameSite Cookie：Cookie 设 SameSite=Lax/Strict，跨站请求不携带（现代浏览器默认 Lax，效果最好）。
2. CSRF Token：表单里带服务器下发的随机 token，攻击页面拿不到。
3. 验证请求来源：服务器校验 Origin/Referer 头。

项目一：性能面板实战分析

打开自己阶段一的个人主页，用 DevTools 的 Network 面板：① 逐个资源看加载时间、缓存命中情况；② 用 Performance 面板录制加载过程，找到关键渲染路径上的阻塞资源；③ 用 Lighthouse 打分并记录优化前后对比。把分析写成一份报告。

项目二：手写「从输入 URL 到页面显示」图文笔记

用流程图软件或手绘，画出完整链路（DNS → 连接 → 请求缓存 → 响应 → 解析 → 渲染树 → 布局 → 绘制 → 合成），每步标注「谁能优化、怎么优化」。这份笔记未来面试前复习，价值极高。

项目三：跨域实战

① 本地起两个端口互相请求，观察跨域报错；② 用 vite 的 proxy 配置解决开发期跨域；③ 用 Node 写一个带 CORS 头的接口，验证预检请求 OPTIONS 的完整流程。