kp-036 端到端案例：浏览器输入 URL 后发生了什么

注：本文基于模型知识整理，建议结合权威教材与 RFC 原文核对细节。

一句话定义

从敲下回车到页面出现，浏览器经历 URL 解析、DNS 解析、TCP 握手、TLS 握手、HTTP 请求响应、渲染六个阶段；把每一步的时延来源与优化手段挂回这条时间线，是整库知识的收口练习。

为什么重要

这是网络工程师与后端面试的经典题，更是把 36 个知识点串成体系的总纲：单独记住三次握手或 DNS 递归价值有限，能说清「每一步花在哪、哪一步能省、优化的代价是什么」才算真正掌握。CDN、keep-alive、TLS 1.3、dns-prefetch 这些零散的优化名词，都能在这张图上找到精确坐标。

前置知识

建议先读 kp-022《DNS》，理解递归与迭代解析及缓存层级；建议先读 kp-023《HTTP》，理解请求响应语义；时延四分量见 kp-002《性能指标与时延模型》，握手细节见 kp-018《TCP 连接管理》，TLS 版本差异见 kp-024《HTTPS/TLS》。

核心概念

时间线六阶段：

URL 解析与补全：补全协议头（https://），拆出主机名、端口、路径。
DNS 解析：依次查浏览器缓存→操作系统缓存（含 hosts 文件）→本地 DNS 服务器；本地 DNS 未命中时才由它代为发起 kp-022 的迭代解析（根→顶级域→权威）。命中与否决定这一步是近似零时延还是几十毫秒级。
TCP 三次握手：SYN→SYN+ACK→ACK，消耗 1 个 RTT（kp-018）。
TLS 握手：TLS 1.2 需额外约 2 个 RTT；TLS 1.3 压缩到 1 个 RTT，重连可 0-RTT（kp-024）。
HTTP 请求与响应：请求发出后，服务端经反向代理、应用、数据库处理（此属服务端范畴，一句带过），响应分块返回。
浏览器解析渲染：HTML→DOM、CSS→CSSOM，合成渲染树再绘制——至此进入前端领域边界，本库止步。

公式与模型

设端到端 RTT 为 R，DNS 解析耗时为 D（缓存命中时近似为 0），服务端处理时间为 S，则首字节时延近似为：

首字节 ≈ D + R(TCP握手) + R(TLS1.3握手) + R/2(请求去) + S + R/2(响应回)
       = D + 3R + S        ( TLS 1.3 )
       ≈ D + 4R + S        ( TLS 1.2, 握手多一个 RTT )

该模型的推论：R 越大每一项都被等比放大，这就是「把内容搬到离用户近的地方」能成倍缩短时延的数学根源。

图示

浏览器                      本地 DNS                    目标服务器
  |                            |                            |
  | 1.解析URL/查DNS缓存         |                            |
  |--2.DNS查询(递归)----------->|--迭代: 根→TLD→权威          |
  |<------- A 记录 ------------|                            |
  | 3.SYN -------------------------------------------------->|
  | 4.SYN+ACK <----------------------------------------------|  TCP 1 RTT
  | 5.ACK --------------------------------------------------->|
  | 6.ClientHello ------------------------------------------->|
  | 7.ServerHello+证书+Finished <-----------------------------|  TLS1.3 1 RTT
  | 8.Finished ---------------------------------------------->|  (TLS1.2 需 2 RTT)
  | 9.GET / HTTP/1.1 ---------------------------------------->|
  | 10.反向代理→应用→数据库(服务端处理)                         |
  |<11.200 OK + HTML(分块) -----------------------------------|
  | 12.HTML→DOM, CSS→CSSOM→渲染树→绘制                         |

原理与机制

时延成分拆解：DNS 的耗时以各级查询的处理与排队为主，命中本地缓存时近似为零；TCP 与 TLS 握手是纯 RTT 消耗——握手完成前连接上不能发送应用数据；响应传输阶段受 kp-002 的四时延（处理、排队、传输、传播）共同约束，资源越多、R 越大，累积越可观。

优化手段与阶段映射：

阶段	手段	原理
DNS	dns-prefetch 预解析	页面加载早期并行解析后续域名
握手	keep-alive 长连接	复用 TCP 连接，省去每请求重建
握手	HTTP/2 多路复用	单连接并发多流，消除 HTTP/1.1 应用层队头（kp-025）
TLS	TLS 1.3 与会话恢复	握手 2→1 RTT；重连 0-RTT，但早期数据不防重放（kp-024）
传输	CDN	内容搬到边缘节点，缩短 R 与回源路径（kp-027）
传输	资源指纹与长缓存	文件名含内容哈希，命中强缓存则连请求都不发（kp-027）

0-RTT 的双面性：TLS 1.3 允许重连时在第一个飞行包里就携带应用数据，省一个 RTT，但早期数据可被重放，服务端必须只放行幂等请求走 0-RTT 通道。

实例分析

用模型算账：设 R=50ms、DNS 未命中 D=40ms、S=60ms，则 TLS 1.3 首字节约 D+3R+S=250ms；换 TLS 1.2 多 50ms；若服务器在另一大洲（R=200ms），仅两次握手就吃掉 400ms——这解释了 CDN 的根本价值：把 R 从「跨洲」换成「同城」。二次访问时三件事同时生效：DNS 命中缓存、连接复用省去握手、TLS 会话恢复把 TLS 压到 0～1 RTT，时延几乎只剩服务端处理。任何一个性能优化的收益，都能用这张账单拆解归因。

常见误区

顺序记反：「先连 TCP 再解析域名」是错的，没有 IP 就无从握手，DNS 必然在前（除非已命中缓存或复用连接）。
把握手与传输混为一谈：握手期间不发应用数据，是纯等待，不能用「带宽大」弥补。
认为 HTTP/2 彻底解决队头阻塞：它只消除 HTTP 层队头，TCP 层丢包仍阻塞所有流（kp-025）。
忽视 0-RTT 重放风险：省一个 RTT 的代价是早期数据可被重放，非幂等请求必须禁走 0-RTT。
把渲染慢归咎网络：DOM/CSSOM 构建与 JS 执行都在前端侧，首屏慢不一定是网络慢。

自测题

从输入 URL 到收到首字节，哪些步骤消耗 RTT、哪些不消耗？

答案要点： 消耗 RTT 的有 TCP 握手（1 个）、TLS 握手（1.3 为 1 个、1.2 约 2 个）、请求往返；URL 解析与 DNS 缓存命中不消耗 RTT，DNS 未命中时消耗的是各级查询的处理与排队时延。

为什么 TLS 1.3 能把握手压到 1-RTT 而 TLS 1.2 需要 2-RTT？

答案要点： 1.2 的证书交换与密钥协商分散在多个来回；1.3 把密钥协商与证书验证压缩进同一轮消息，客户端发出 ClientHello 后即可推导密钥并提前发送应用数据，重连时更能 0-RTT（受重放限制）。

dns-prefetch 优化的是哪一步？何时收益最大？

答案要点： 优化 DNS 解析阶段；收益最大的是页面引用大量第三方域名（统计、字体、图片 CDN）且解析尚未发起时——提前并行解析，避免关键资源等到用时才开始查。

keep-alive 与 HTTP/2 多路复用分别省了什么？

答案要点： keep-alive 复用 TCP 连接，省去每个请求的 TCP（及 TLS）握手 RTT；HTTP/2 在一条连接上并发多流，进一步消除 HTTP/1.1 的应用层队头与连接数限制，但 TCP 层队头仍在。

复习时如何用这张时间线挂回任意一个新学的网络知识？

答案要点： 问四件事：它发生在哪一步（DNS/握手/传输/渲染）；省了多少时间（几个 RTT、几次解析）；防了什么风险（重放、劫持、队头）；有什么副作用——以此把新知识挂上终身复习索引。