从输入 URL 到页面显示，浏览器经历了什么？

从浏览器地址栏输入一个网址并按下回车后到页面出现，这段时间虽然很短，浏览器却完成了域名解析、建立连接、发送请求、接收资源和渲染页面等一系列工作。

理解这条链路，不仅能帮助我们入门 Web 开发，也能在网站加载缓慢时提供清晰的排查方向。

本文先从完整流程入手，再介绍 URL、DNS 和 HTTP 等基础概念，最后通过浏览器开发者工具观察一次真实请求。

网页加载的完整流程

从输入 URL 到看到页面，可以概括为以下六步：

1. 浏览器解析 URL，确定协议、域名、端口和路径。
2. 查询 DNS，将域名转换为服务器的 IP 地址。
3. 与服务器建立连接；传统 HTTP 通常使用 TCP，HTTPS 还需要协商 TLS 加密连接。
4. 浏览器发送 HTTP 请求。
5. 服务器处理请求并返回 HTML 等内容。
6. 浏览器解析资源，计算页面布局并将内容绘制到屏幕上。

这六步是理解网页加载过程的主线。真实环境中还可能经过浏览器缓存、CDN、代理服务器、负载均衡等环节，但它们并不会改变这条基本链路。

第一步：解析 URL

URL 是资源在网络中的地址。例如：

https://demo.vercel.app/zh/blog/
✦复制代码

它可以拆成四个主要部分：

• https 是协议，规定浏览器与服务器如何通信。
• demo.vercel.app 是域名，方便人类记忆，常见域名还有 example.com。
• 443 是端口，用于确定服务器上的具体网络服务。
• /zh/blog/ 是路径，表示要访问的资源位置。

HTTP 的默认端口是 80，HTTPS 的默认端口是 443。使用默认端口时，通常不需要在地址中明确写出端口号。

浏览器解析 URL 后，就知道自己要使用什么协议、联系哪台服务器，以及请求哪个资源。

第二步：通过 DNS 查找 IP 地址

网络通信最终依赖 IP 地址，而不是便于记忆的域名。DNS 的作用，就是把域名解析成 IP 地址。

例如，浏览器访问 example.com 时，需要先查询它对应的 IP 地址。为了减少重复查询，浏览器、操作系统和 DNS 服务都可能保存缓存。如果缓存中没有结果，请求才会继续向 DNS 服务器查询。

常见的 DNS 记录包括：

• A 记录：把域名指向一个 IPv4 地址。
• AAAA 记录：把域名指向一个 IPv6 地址。
• CNAME 记录：为域名设置另一个域名作为别名。

可以使用 nslookup 查看基本的解析结果：

nslookup xxxxxxx.com
✦复制代码

如果系统安装了 dig，也可以查看更详细的 DNS 信息：

dig xxxxxx.com
✦复制代码

DNS 解析完成后，浏览器就获得了目标服务器的网络地址。

第三步：建立安全连接

知道 IP 地址并不等于已经可以传输网页内容，浏览器还需要与服务器建立连接。

在常见的 HTTP/1.1 和 HTTP/2 场景中，双方通常先通过 TCP 三次握手确认连接可用。可以把三次握手理解为三次确认：

1. 浏览器发出建立连接的请求。
2. 服务器确认收到，同时表示自己也可以建立连接。
3. 浏览器再次确认，连接正式建立。

如果访问的是 HTTPS 网站，双方还要进行 TLS 握手。这个阶段会验证服务器证书，并协商后续通信使用的加密方式。握手完成后，浏览器与服务器之间传输的数据才会受到加密保护。

现代网站也可能使用基于 QUIC 的 HTTP/3。它不使用 TCP，但仍然需要完成连接和安全协商。对于入门学习，先掌握“建立连接，再发送 HTTP 请求”这条主线即可。

第四步：发送 HTTP 请求

连接建立后，浏览器会发送 HTTP 请求。一个经过简化的请求如下：

GET /zh/blog HTTP/1.1
Host: demo.vercel.app
Accept: text/html
✦复制代码

其中：

• GET 是请求方法，表示获取资源。
• /zh/blog 是资源路径。
• Host 指定目标域名。
• Accept 表示浏览器期望接收的内容类型。

常见请求方法还有 POST，通常用于提交数据。需要注意，GET 和 POST 的区别不只是“查看”和“提交”；它们在语义、缓存和重复执行的预期上也不同。

第五步：服务器处理并返回响应

服务器收到请求后，会根据路径、请求方法和参数决定如何处理。它可能直接读取一个静态文件，也可能调用后端程序、查询数据库或请求其他服务。

处理完成后，服务器返回 HTTP 响应：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!doctype html>
<html>...</html>
✦复制代码

响应中包含状态码、响应头和响应体。状态码可以按首位数字快速分类：

• 2xx：请求成功，例如 200 OK。
• 3xx：需要重定向，例如 301 Moved Permanently。
• 4xx：请求侧出现问题，例如 404 Not Found。
• 5xx：服务器侧处理失败，例如 500 Internal Server Error。

这里容易产生一个误解：服务器通常不会把完整页面所需的所有内容一次性打包返回。浏览器先取得 HTML，然后根据其中的引用继续请求 CSS、JavaScript、图片和字体等资源。因此，打开一个页面往往会产生几十甚至上百条网络请求。

第六步：浏览器渲染页面

收到 HTML 后，浏览器开始把文本转换成可见页面。简化后的渲染过程如下：

1. 解析 HTML，构建 DOM 树。
2. 解析 CSS，得到样式规则。
3. 结合文档结构与样式，确定可见元素及其样式。
4. 计算每个元素的位置和尺寸，也就是布局。
5. 将文字、颜色、边框和图片等内容绘制出来。
6. 把不同图层合成为最终画面并显示在屏幕上。

JavaScript 也可能在此期间修改 DOM 和样式，触发新的布局或绘制。外部 CSS、脚本、图片等资源的加载方式，也会影响页面何时开始显示、何时能够交互。

所以，“收到服务器响应”并不代表页面已经加载完成。网络传输结束后，浏览器仍然需要解析和渲染内容。

用 DevTools 观察一次真实请求

理解概念后，可以直接在浏览器中验证整个过程。Chrome、Edge 和 Firefox 都提供了开发者工具。

1. 打开任意网页。
2. 按 F12，或者右键选择“检查”。
3. 切换到 Network 面板。
4. 刷新页面。

刷新后，面板会显示页面产生的所有网络请求。常用字段包括：

• Name：请求的资源名称。
• Status：HTTP 状态码。
• Type：文档、脚本、样式表、图片等资源类型。
• Size：传输的数据大小。
• Time：请求总耗时。
• Waterfall：各请求开始时间和持续时间的时间线。

点击通常位于列表前部、类型为 document 的主文档请求，可以在 Headers 中查看请求 URL、请求方法、状态码和响应头；在 Timing 中可以查看 DNS、建立连接、等待服务器响应和下载内容等阶段的耗时。

不要默认点击“第一条请求”：浏览器扩展、重定向或其他后台行为可能改变请求顺序。根据 Type 和请求 URL 找到主文档更可靠。

如果网页加载缓慢，可以先观察：

• DNS 查询或连接建立是否耗时过长；
• 等待服务器响应的时间是否异常；
• 是否存在体积很大的图片或脚本；
• 某些请求是否失败或发生多次重定向；
• 关键资源是否被其他请求长时间阻塞。

DevTools 不会直接给出所有问题的答案，但它能帮助我们先确定时间主要消耗在哪个阶段。

面试

“从输入 URL 到页面渲染，中间发生了什么？”是一道常见的前端基础题。回答时不必一开始就罗列所有细节，可以先给出主流程：

浏览器先解析 URL，并通过 DNS 将域名解析为 IP 地址。随后与服务器建立连接；如果使用 HTTPS，还要完成 TLS 握手。连接建立后，浏览器发送 HTTP 请求，服务器处理并返回 HTML。浏览器解析 HTML 构建 DOM，处理 CSS、JavaScript 和其他资源，经过布局、绘制与合成，最终将页面显示出来。

如果面试官继续追问，再展开具体环节：

• DNS 有哪些缓存层级？
• TCP 为什么需要三次握手？
• TLS 如何验证服务器身份？
• HTTP 缓存如何工作？
• CSS 和 JavaScript 为什么可能阻塞渲染？
• DOM、布局、绘制和合成分别做什么？

这样的回答先建立清晰框架，再根据问题逐层深入，比一次堆出大量术语更容易表达，也更便于面试官判断你是否真正理解。

总结

从输入 URL 到看到页面，核心过程可以压缩为一句话：

解析地址，找到服务器，建立连接，发送请求，接收资源，渲染页面。

这条链路同时连接了 DNS、TCP、TLS、HTTP 和浏览器渲染等知识。入门阶段不必一次记住所有细节，先用 DevTools 把抽象过程和真实请求对应起来，再逐步深入每一个环节，会更容易形成完整的 Web 基础知识体系。