1. 完整回答
在地址栏输入 https://www.example.com/products 并回车，浏览器首先会识别和解析 URL，得到协议、域名、端口、路径等信息，同时检查缓存、已有连接以及 Service Worker 能否直接提供资源。
需要访问网络时，浏览器会通过 DNS 把域名解析成 IP 地址，优先利用已有解析结果，未命中时再由 DNS 解析器查询。接着建立连接：HTTP/1.1 和 HTTP/2 通常使用 TCP，需要三次握手；HTTPS 还要通过 TLS 握手验证服务器身份、协商加密密钥。如果协商使用 HTTP/3，则通过基于 UDP 的 QUIC 建立安全连接。
连接准备好后，浏览器发送 HTTP 请求。请求可能先到 CDN 或反向代理，再由应用服务器处理业务、查询数据，最后返回状态码、响应头和 HTML 等内容。如果返回重定向，浏览器会根据新地址继续导航。
收到 HTML 后，浏览器会边下载边解析，构建 DOM，同时加载 CSS、JavaScript、图片等资源。CSS 用于计算样式，JavaScript 可能修改页面结构。随后浏览器对可见内容进行布局、绘制和合成，把页面显示出来。这个过程是渐进的，通常能先看到部分内容，再等后续资源加载完毕。
2. 核心原理与关键概念
整体流程： URL 解析与本地检查 → DNS 解析 → 建立传输连接与安全连接 → 发送 HTTP 请求 → 服务端处理与响应 → 解析 HTML 和加载子资源 → 样式计算与布局 → 绘制、合成并显示。
- URL 解析与本地检查： 识别协议、主机、端口、路径和查询参数；
#后面的片段标识符由浏览器处理，不随 HTTP 请求发送。还可能命中缓存、已有连接或 Service Worker。已启用的 HSTS 也可能提前把 HTTP 升级为 HTTPS。 - DNS 解析： 利用浏览器、操作系统及递归解析器的缓存或本地主机映射。必要时，递归解析器依次向根域名服务器、顶级域名服务器和权威域名服务器获取解析结果。
- 建立连接： TCP 使用
SYN → SYN+ACK → ACK完成三次握手；HTTPS 在 TCP 上还会进行 TLS 握手。HTTP/3 走 QUIC，传输连接与 TLS 1.3 安全握手相结合。已有可复用连接时可以跳过新的建连过程。 - 请求与响应： 浏览器发送请求方法、目标路径、请求头及必要的请求体；服务端可能经由 CDN、负载均衡、反向代理和业务服务返回响应。响应包含状态码、响应头及可选响应体。
- 解析与渲染： HTML 逐步生成 DOM，CSS 形成 CSSOM 并参与样式计算；之后生成用于布局和绘制的结构，确定元素尺寸与位置，再绘制、栅格化和合成显示。资源发现与下载通常和解析交错进行。
| 关键概念 | 作用 |
|---|---|
| DNS | 将域名解析为可用于连接的地址 |
| TCP / QUIC | 提供网络传输；TCP 面向字节流，QUIC 支持多路流并集成安全握手 |
| TLS | 认证服务器身份，并保护传输数据的机密性与完整性 |
| HTTP | 规定请求、响应、状态码、首部和缓存等语义 |
| DOM / CSSOM | 分别表示文档结构与样式规则，是后续渲染的重要输入 |
3. 高频面试追问
3.1 输入 URL 后，一定会发起网络请求吗？
不一定。浏览器可能直接使用仍然有效的 HTTP 缓存；页面受 Service Worker 控制时，也可能由它返回缓存内容或自行生成响应。前进、后退时如果命中 往返缓存（bfcache），甚至可以直接恢复之前的页面状态。单纯修改 URL 的 # 片段，通常也不需要重新请求 HTML。
继续追问：强制缓存和协商缓存怎么区分？
强制缓存命中时，缓存中的响应可以直接复用；协商缓存需要向服务器发送条件请求，例如携带 If-None-Match，服务器确认资源未变化就返回 304，浏览器继续使用本地响应体。
3.2 DNS 是怎么找到服务器 IP 的？
浏览器会使用本地可用的解析结果，操作系统也可能通过缓存或 hosts 映射直接给出地址。如果还没有结果，就向配置的递归 DNS 解析器发起查询。递归解析器在缓存未命中时，通常会依次查询根、顶级域和权威 DNS，拿到记录后返回给客户端并按 TTL 缓存。现代浏览器也可能使用加密 DNS，具体路径取决于系统和浏览器配置。
3.3 TCP 为什么要三次握手？每个资源都要握手吗？
三次握手让双方确认彼此的初始序列号以及收发能力，并减少旧的重复连接请求造成的混乱。过程是客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK。每个资源都重新握手会增加延迟，所以 HTTP/1.1 默认支持持久连接，HTTP/2 还能在同一连接上并发传输多个请求；只有需要新建 TCP 连接时才重新握手。
3.4 HTTPS 的 TLS 握手具体解决什么问题？
它主要解决身份认证、加密传输和完整性保护。浏览器与服务器协商 TLS 参数和密钥交换材料，验证服务器证书是否可信、域名是否匹配，然后使用协商出的会话密钥加密应用数据。这样可以降低窃听和篡改风险。TLS 保护的是连接中的数据，无法保证业务接口本身没有漏洞；使用 HTTP/3 时，TLS 1.3 集成在 QUIC 的握手过程中。
3.5 服务器收到请求后会发生什么？301、302 和 304 有什么区别？
请求可能先经过 CDN、网关或反向代理。如果边缘节点能命中缓存，就可以直接返回；否则转发给应用服务，由路由、鉴权、业务逻辑和必要的数据访问生成响应。301 表示永久重定向，302 表示临时重定向，浏览器通常会按 Location 发起后续请求。304 表示条件请求对应的缓存内容仍有效，通常不返回资源响应体，它属于缓存校验结果。
3.6 HTTP/1.1、HTTP/2、HTTP/3 对加载过程有什么影响？
HTTP/1.1 可以复用 TCP 连接，但同一连接上的请求响应通常难以高效并发，因此浏览器可能建立多条连接。HTTP/2 通过二进制分帧和多路复用，让多个请求共享一条 TCP 连接，但 TCP 丢包仍可能影响这条连接上的所有流。HTTP/3 使用基于 UDP 的 QUIC，也支持多路复用，不同流之间可以避免 TCP 层队头阻塞，并且有更灵活的连接建立机制。
3.7 收到 HTML 后，CSS 和 JavaScript 会阻塞什么？
浏览器收到 HTML 就可以逐步解析并发现子资源。普通同步脚本在解析器遇到时，通常会暂停 HTML 解析，等待脚本获取和执行，因为脚本可能修改 DOM。CSS 通常不会直接暂停 HTML 解析，但会影响页面渲染；已经解析到的样式表还可能使后续脚本等待，以确保脚本读取的样式正确。所以大体积的首屏样式和同步脚本都可能推迟页面显示。
3.8 async 和 defer 有什么区别？
两者都允许外部经典脚本与 HTML 解析并行下载。async 下载完成后尽快执行，执行时可能中断解析，多个脚本之间没有固定执行顺序，适合独立统计脚本。defer 会等 HTML 解析结束再执行，并保持文档中的脚本顺序，适合依赖 DOM 或其他脚本的业务逻辑；DOMContentLoaded 会等待这些延迟脚本执行完成。普通模块脚本默认具有类似 defer 的行为。
3.9 DOMContentLoaded、load 和页面首次显示是一回事吗？
它们对应不同阶段。DOMContentLoaded 表示 HTML 已解析完成，相关延迟脚本也已执行；它不要求图片等资源全部加载完成。load 通常还需要等待页面依赖的图片、样式表和子框架等资源。用户看到内容的时间可以早于这两个事件，常用 FCP 衡量首次内容绘制，LCP 衡量视口内最大内容元素完成渲染的时间，因此不能只看 load 判断首屏体验。
3.10 如果一个页面打开很慢，你会怎么排查？
我会先用浏览器开发者工具的 Network 看瀑布图，把时间拆成 DNS、建连、等待首字节和内容下载。如果 TTFB 高，就检查重定向、CDN 命中、服务端耗时和数据库查询；如果资源下载慢，就看资源体积、压缩、缓存和请求优先级。网络阶段正常但页面仍白屏，我会再看 Performance 里的长任务、同步脚本、样式计算和布局，结合 LCP 判断关键内容为什么迟迟没有显示，再针对最慢的阶段优化。
4. 易混淆概念对比
4.1 TCP 与 TLS
| 概念 | 核心职责 | 所处环节 |
|---|---|---|
| TCP | 可靠、有序的字节流传输，使用三次握手建立连接 | HTTP/1.1、HTTP/2 常用的传输层 |
| TLS | 身份认证、密钥协商、加密和完整性保护 | HTTPS 安全层；HTTP/3 中集成于 QUIC |
4.2 强制缓存与协商缓存
| 概念 | 是否需要向服务器验证 | 典型依据 |
|---|---|---|
| 强制缓存 | 有可复用的新鲜缓存时无需验证 | Cache-Control: max-age |
| 协商缓存 | 需要发送条件请求，由服务器确认资源是否变化 | ETag / If-None-Match、Last-Modified / If-Modified-Since |
Cache-Control: no-cache 允许存储，但复用前要验证；no-store 表示不应存储该响应。
4.3 HTTP/1.1、HTTP/2 与 HTTP/3
| 版本 | 常见传输方式 | 并发与关键限制 |
|---|---|---|
| HTTP/1.1 | TCP | 支持持久连接，通常需要多条连接提高并发 |
| HTTP/2 | TCP + TLS | 多路复用；仍可能受到 TCP 层队头阻塞影响 |
| HTTP/3 | QUIC（基于 UDP，集成 TLS 1.3） | 多路流之间独立推进，降低丢包对其他流的阻塞 |
4.4 CSS 与普通同步 JavaScript 的阻塞行为
| 资源 | 对 HTML 解析的影响 | 对首次渲染的影响 |
|---|---|---|
| CSS 样式表 | 通常不直接阻塞解析 | 关键样式表会阻塞对应内容的渲染，还可能让后续脚本等待 |
| 普通同步 JavaScript | 通常暂停解析，执行完成后继续 | 可能占用主线程并推迟渲染 |
4.5 DOMContentLoaded 与 load
| 事件 | 触发条件 | 通常不等待的内容 |
|---|---|---|
| DOMContentLoaded | HTML 解析完成，延迟脚本和默认延迟执行的模块脚本已执行 | 图片、异步脚本等完成加载 |
| load | 文档及其需要等待的依赖资源完成加载 | 后续动态请求、持续运行的应用任务 |
5. 总结
浏览器输入 URL 后，会先解析地址，检查缓存和已有连接；需要联网时通过 DNS 找到目标地址，再建立 TCP 或 QUIC 连接，并在 HTTPS 场景下完成安全握手。随后浏览器发送 HTTP 请求，服务器返回 HTML 等资源。浏览器边接收边解析 HTML，构建 DOM，结合 CSS 计算样式，再经过布局、绘制和合成把页面展示出来，JavaScript 和资源加载也会影响这个过程。这里有两个容易忽略的地方：一是命中缓存或复用连接时，部分网络步骤可以省略；二是页面可以渐进显示，看到内容、DOMContentLoaded 和 load 分别代表不同的时间点。