Ayahunter

URL 与 origin#

Web 安全模型经常使用 origin。它通常由 scheme、host 和 port 共同确定：

1
https://example.com:443

只改变 path 或 query 不会改变 origin；从 https 改为 http、更换主机或端口则会改变。浏览器的同源策略、Cookie 规则、CORS 和连接复用都会受到这些边界影响，但它们不是完全相同的一套判断条件。

Service Worker 可能拦截请求#

如果当前站点注册且激活了 Service Worker，并且请求位于其控制范围内，Service Worker 可以处理 fetch 事件。它可以：

• 从 Cache Storage 返回响应；
• 修改请求后访问网络；
• 采用 cache-first、network-first 等应用策略；
• 在离线状态返回预设页面。

Service Worker 缓存策略由站点代码决定，不等同于浏览器的 HTTP 缓存规则。没有安装或尚未接管当前页面时，这一步不会发生。

HTTP 缓存检查 freshness#

浏览器 HTTP 缓存会根据请求和已有响应的缓存元数据判断能否复用：

• 响应仍然新鲜时，可能直接使用缓存而不联系源服务器；
• 响应需要验证时，可以携带 If-None-Match 或 If-Modified-Since；
• 服务器返回 304 Not Modified 后，浏览器继续使用已有响应正文；
• no-store 等指令可能禁止保存，认证、请求方法和共享缓存还有额外规则。

常见响应头示例：

1
Cache-Control: public, max-age=3600
2
ETag: "article-42-v3"

缓存是否可用不能只看“磁盘里有没有文件”，而要按 HTTP 缓存语义计算。新鲜度、验证和陈旧响应的使用边界定义在 RFC 9111。

常见 DNS 记录#

每条记录都带有 TTL，用于约束缓存时间。TTL 到期意味着缓存需要刷新，并不保证所有中间系统在同一瞬间得到相同答案。负缓存、递归解析器策略、地理调度和客户端对 IPv4/IPv6 的选择，也会让不同用户观察到不同结果。

HTTP/1.1 与 HTTP/2：先建立 TCP#

在常见的 HTTPS 场景中，HTTP/1.1 和 HTTP/2 都运行在 TCP 之上。新连接先通过 TCP 握手建立可靠的双向字节流：

sequenceDiagram
    participant C as 客户端
    participant S as 服务器
    C->>S: SYN
    S-->>C: SYN + ACK
    C->>S: ACK

TCP 负责按序传输、重传和拥塞控制。握手成功只代表传输连接建立，还没有证明 HTTPS 身份，也没有收到页面内容。

HTTPS 继续进行 TLS 握手#

TLS 握手主要完成以下事情：

1. 协商协议版本和密码套件；
2. 服务器发送证书链，客户端检查信任链、有效期和主机名；
3. 双方通过密钥交换得到会话密钥；
4. 后续应用数据获得机密性和完整性保护；
5. 通过 ALPN 等机制协商使用 h2 还是 http/1.1。

TLS 保护的是传输中的内容和对端身份验证，不会自动保证应用没有漏洞，也不会隐藏所有网络元数据。TLS 1.3 的协议细节见 RFC 8446。

HTTP/3：QUIC 中集成 TLS#

HTTP/3 不先建立 TCP 连接，而是运行在 QUIC 之上；QUIC 通常通过 UDP 承载，并把 TLS 1.3 握手集成进传输层。客户端可以通过既有配置、Alt-Svc 或其他服务发现机制得知服务器支持 HTTP/3；如果 UDP 路径不可用，客户端通常仍可尝试基于 TCP 的 HTTP/2 或 HTTP/1.1。

QUIC 的核心协议见 RFC 9000，HTTP/3 映射见 RFC 9114。

Cookie 和认证信息何时发送#

浏览器只会发送符合域、路径、过期时间、Secure、SameSite 等条件的 Cookie。认证也可能使用 Authorization 请求头或其他机制。

路由和中间件#

服务器根据 method、host 和 path 等信息找到处理逻辑。日志、限流、追踪、认证、CORS、内容解析等功能常由中间件完成。中间件顺序会影响结果，例如在身份认证之前读取受保护用户信息通常得不到有效身份。

应用缓存和数据库#

应用可能先查询内存缓存或 Redis 等外部缓存；未命中时再通过连接池访问数据库。一次数据库访问又可能经历：

1. 从连接池获取连接；
2. 解析或复用预编译语句；
3. 执行查询和事务；
4. 读取索引页或磁盘数据；
5. 返回结果并序列化。

并非每个请求都会访问数据库。静态资源可能由 CDN 直接返回，健康检查可能只读取进程状态，写请求则可能涉及事务、消息队列或多个依赖服务。

延迟会累积，也会并行#

服务端总耗时不一定是每一步简单相加。互不依赖的查询可以并行，连接池等待、锁竞争、缓存穿透、慢查询和下游超时则会显著增加尾延迟。排查时需要端到端 trace 或分层指标，不能只看应用函数的执行时间。

状态码表达处理结果#

• 2xx：请求已按相应语义成功处理；
• 3xx：需要重定向或可以使用缓存表示；
• 4xx：请求一侧存在问题，例如未认证、无权限或资源不存在；
• 5xx：服务器处理请求时失败。

状态码只说明 HTTP 层约定的结果。一个返回 200 的接口仍可能把业务错误包装在 JSON 中；这会增加调用方判断成本，API 设计应保持语义清晰。

响应可能被压缩、缓存或流式发送#

服务器或代理可以根据 Accept-Encoding 选择 gzip、Brotli 等内容编码。缓存头决定后续是否可复用。大响应也可能分块或流式传输，让浏览器在完整正文到达前开始处理。

对于 HTTP/2 和 HTTP/3，响应数据会被拆成帧放入对应 stream。协议的多路复用让同一连接上可以交错传输多个资源，但应用优先级、服务端调度和带宽仍会影响实际完成顺序。

从字节到 DOM#

浏览器根据响应头、BOM 和 HTML 规则确定字符编码，然后由 tokenizer 与 parser 构造 DOM。HTML 解析具有错误恢复规则，遇到不规范标签时不一定直接失败。详细算法见 HTML Standard：Parsing HTML documents。

解析器发现 <link>、<script>、<img> 等元素后，会发起更多请求。浏览器还可能通过预加载扫描器提前发现资源，因此“解析完 HTML 后才下载 CSS 和图片”并不准确。

CSS、JavaScript 和渲染流水线#

可以用下面的概念流程理解：

1
HTML → DOM ┐
2
            ├→ render tree → layout → paint → composite
3
CSS  → CSSOM┘

• CSSOM 表示计算样式所需的 CSS 结构；
• render tree 只包含参与当前渲染的节点及样式信息；
• layout 计算元素几何位置和尺寸；
• paint 生成绘制指令；
• composite 把不同图层组合到屏幕。

JavaScript 可以读取和修改 DOM/CSSOM，也可能触发新的样式计算、布局和绘制。经典同步脚本可能阻塞 HTML 解析；defer、async 和模块脚本具有不同的下载与执行时机。

HTTP/1.1：持久连接但没有 stream 多路复用#

HTTP/1.1 默认支持持久连接，可以在同一 TCP 连接上依次发送多个请求。协议存在 pipelining 机制，但响应必须与请求顺序对应，且浏览器实践中没有成为解决并发加载的主要方式；客户端常通过多条连接提高并发。

HTTP/1.1 报文和连接管理定义在 RFC 9112。

HTTP/2：在一条 TCP 连接上复用多个 stream#

HTTP/2 把消息拆成带 stream 标识的帧，使多个请求和响应可以在同一连接中交错传输。一个慢响应不必在 HTTP 层阻止其他响应发送，但所有 stream 仍共享同一 TCP 字节流；发生丢包时，TCP 必须补齐缺失数据后才能继续按序交付，因而可能暂时影响全部 stream。

HTTP/2 的帧和 stream 语义定义在 RFC 9113。

HTTP/3：把 HTTP 映射到 QUIC stream#

HTTP/3 使用 QUIC stream 承载请求。QUIC 在传输层区分 stream，因此某一 stream 丢失的数据需要重传时，其他已经完整到达的 stream 不必等待它恢复。这减少了 HTTP/2 在 TCP 层的跨 stream 队头阻塞，但拥塞、带宽和应用调度仍然是共享约束。

QUIC 还使用连接 ID 支持连接迁移等能力，但网络切换后能否无感保持连接取决于客户端、服务器和路径条件，不能把它理解为永不掉线。HTTP/3 的规范见 RFC 9114。

DNS 解析失败#

1
dig example.com A
2
dig example.com AAAA

先比较系统或指定解析器的结果。DNS 正常只说明得到了记录，不说明目标端口或应用健康。

TCP、TLS 或 HTTP 失败#

1
curl -v https://example.com/
2
curl -I -L https://example.com/

curl -v 可以观察地址选择、连接、TLS 和 HTTP 头；-I -L 适合查看重定向链。具体是否支持 --http2 或 --http3 取决于本机 curl 的构建和依赖。

浏览器里页面很慢#

开发者工具的 Network 面板可以观察：

• 请求是否来自 memory cache、disk cache 或 Service Worker；
• DNS、连接、TLS、等待首字节和内容下载时间；
• 重定向链和协议版本；
• 哪些 CSS、字体、脚本或图片阻塞关键渲染路径；
• 响应头是否允许缓存和压缩。

各浏览器的时间字段名称和精确边界并不完全相同。服务端慢应结合 trace、访问日志、应用指标和数据库指标判断，不能只靠前端瀑布图猜测内部原因。