点击链接后浏览器做了什么？完整技术链路解析

当你点击一个链接，屏幕上瞬间出现了网页内容——这看似简单的操作，背后其实是一整套精密协作的技术流程。从操作系统的网络栈到 DNS 解析，从 TCP 握手到 HTTP 请求，再到浏览器引擎的渲染，每一步都环环相扣。本文基于 Chrome 团队的官方讲解，拆解点击链接背后完整的技术链条。

浏览器不是独自作战：网络栈的协作

很多人以为，点击链接后浏览器就直接「伸手」去网站抓取像素回来。但真实情况要复杂得多。

当你点击指向某个页面的链接时，本质上是在告诉 Chrome：「我想查看链接另一端的那个网页。」这个页面可能是社交媒体、在线商店、流媒体服务或博客——具体是什么并不重要，重要的是 Chrome 需要获取到用于展示和交互的全部资源。

而 Chrome 并不会独自完成所有工作，它非常擅长「委派任务」。首先，Chrome 会与设备操作系统的**网络栈（Network Stack）**通信。无论你用的是 Android、Windows 还是 macOS，网络栈都是系统软件的一部分，负责帮助 Chrome 建立通往 Web 服务器的网络连接。

网络栈是操作系统中实现网络通信的核心软件组件，它按照 TCP/IP 四层模型进行分层设计——从底层的网络接口层（处理物理帧的收发）、网络层（IP 寻址和路由）、传输层（TCP/UDP 连接管理）到应用层（HTTP/HTTPS 协议），每一层各司其职。Chrome 浏览器虽然自身实现了部分网络功能（如 HTTP/2、QUIC 协议的支持），但底层的 socket 创建、IP 路由选择、网卡驱动交互等仍依赖操作系统内核提供的系统调用接口。

随后，操作系统的网络栈向设备的网络硬件发送请求。网络栈与硬件会根据当前可用的连接方式（Wi-Fi、移动网络或有线连接），通过网卡去获取互联网资源。

DNS 解析：找到服务器的「门牌号」

浏览器的第一个关键任务，是搞清楚如何找到存放网页资源的服务器。

假设你点击了 cats.example 这个链接，浏览器怎么知道该去哪里取资源？这里就轮到 DNS 服务器（域名系统） 登场了。

DNS 服务器的核心作用，是将人类可读的域名（如 cats.example）翻译成机器可用的数字地址，也就是 IP 地址（如 142.250.187.214）。有了这个 IP 地址，浏览器才能定位到真正提供资源的那台计算机。

可以把 DNS 想象成一本超大的「电话簿」——你只记得对方的名字，而 DNS 帮你查出对应的号码。这一步看似不起眼，却是整个网页加载流程的起点。

实际上，DNS 解析并非每次都需要从头查询。现代系统采用多级缓存策略：浏览器自身维护 DNS 缓存（Chrome 可通过 chrome://net-internals/#dns 查看）、操作系统有本地 DNS 缓存、路由器通常也会缓存解析结果。只有当所有缓存都未命中时，才会向递归 DNS 服务器发起查询。递归服务器会依次访问根域名服务器、顶级域名服务器（如 .com、.example 对应的 TLD 服务器）和权威域名服务器，最终获得目标 IP 地址。整个过程涉及 DNS 记录的 TTL（生存时间）管理，TTL 过期后缓存失效需重新查询。

TCP/IP 握手与 TLS 安全连接

一旦 DNS 提供了目标网站的 IP 地址，Chrome 就可以开始协商建立连接。这个过程遵循一套通信规则，即 TCP/IP 协议。

所谓协议，就是一套标准化的通信规则。Chrome 会按照 TCP/IP 规则向 cats.example 发送消息，网站作出响应，Chrome 再回应，如此往复，直到完成整个「握手」过程。握手完成后，浏览器和 Web 服务器之间就建立起了交换消息和文件的机制，这被称为 TCP 会话（TCP Session）。

具体来说，TCP 三次握手（Three-Way Handshake）的过程是：客户端发送 SYN（同步序列号）报文，服务器回应 SYN-ACK（同步确认）报文，客户端再发送 ACK（确认）报文。这三步确保双方都确认了对方的接收和发送能力，同时协商了初始序列号（ISN），用于后续数据传输的顺序保证和丢包重传。TCP 还引入了滑动窗口机制实现流量控制，以及拥塞控制算法（如 CUBIC、BBR）来避免网络拥塞。这些机制虽然增加了延迟，但保证了数据传输的可靠性和有序性。

HTTP 与 TCP 的分工

很多人容易混淆 HTTP 和 TCP。简单来说：

• TCP 是底层的传输机制，负责让数据可靠地传输，因此被称为传输层（Transport Layer）。
• HTTP 则是在 TCP 连接之上，用于交换消息和文件的应用层协议。

一个来自浏览器的 HTTP 请求，本质上就是一段遵循 HTTP 规则的文本消息。服务器收到后会返回一个文件——可能是 HTML、CSS、图片或其他任何内容。请求和响应还可以携带额外的文本信息，即请求头（Headers），Cookie 数据就是通过请求头随请求或响应一起发送的。

值得一提的是，浏览器不仅能下载，还能上传文件，甚至支持视频流、音频流和视频通话——不过这些场景需要与服务器采用完全不同的通信方式。

TLS 协议：给通信加上「安全锁」

如果通信不加密，黑客就可能窃听浏览器与服务器之间的对话。为此，我们需要 传输层安全协议（TLS）。

TLS 会在任何实质通信开始前，在浏览器和服务器之间进行一系列往返交互，就像一次漫长的握手，用来验证双方确实是「他们所声称的身份」。这一步保障了数据传输的机密性和完整性。

现代网站普遍使用 TLS 1.3 协议，相比 TLS 1.2 将握手从两次往返（2-RTT）缩减为一次往返（1-RTT），甚至在重连场景下支持零往返（0-RTT）恢复。TLS 握手的核心步骤包括：协商加密套件、通过数字证书验证服务器身份（证书链追溯至受信任的根证书颁发机构 CA）、使用非对称加密（如 ECDHE）交换密钥材料、最终派生出对称加密密钥用于后续通信。浏览器地址栏的「锁」图标正是 TLS 连接建立成功的可视化标志。HTTPS 中的「S」代表的就是 TLS 这层安全保障。

Blink 渲染引擎与 V8：从代码到画面

当浏览器终于从服务器收到响应，拿到 CSS 和 HTML 文件后，真正的「渲染魔法」才开始。

代码解析过程

Chrome 首先要把收到的代码转换成自己能处理的形式，并获取页面所需的额外资源，比如图片和其他文件。这个过程叫做解析（Parsing）。JavaScript 同样需要被解析和执行。

Blink 渲染引擎的工作

Blink 是所有基于 Chromium 的浏览器（包括 Chrome）所使用的渲染引擎。渲染引擎的职责，是将 HTML、CSS、JavaScript 以及图片等资源，转换成屏幕上可供查看和交互的页面。

Blink 的渲染流水线（Rendering Pipeline）包含多个精确的阶段：首先将 HTML 解析为 DOM 树（Document Object Model），将 CSS 解析为 CSSOM 树（CSS Object Model）；然后将两者合并为渲染树（Render Tree），排除不可见元素；接着进行布局（Layout）计算每个元素的精确几何位置和尺寸；再进行分层（Layering）和绘制（Paint）生成绘制指令列表；最后通过合成器（Compositor）将多个图层合成为最终帧并提交给 GPU 显示。任何 DOM 或样式变更都可能触发部分或全部流水线的重新执行，这就是前端性能优化中常说的「回流」（Reflow）和「重绘」（Repaint）的技术根源。

而在解析和执行 JavaScript 与 WebAssembly 时，Blink 会调用另一个引擎——V8。V8 同样是 Chromium 项目的开源组件，以高性能著称。

V8 引擎采用即时编译（JIT, Just-In-Time Compilation）策略来平衡启动速度和运行性能。JavaScript 代码首先被解析为抽象语法树（AST），然后由 Ignition 解释器编译为字节码并立即执行，保证快速启动。当 V8 检测到某段代码被频繁执行（成为「热点代码」），TurboFan 优化编译器会将其编译为高度优化的机器码。如果运行时类型假设被打破（如变量类型发生变化），V8 会进行「去优化」（Deoptimization）回退到解释执行。这种分层编译策略使得 V8 在处理动态类型语言时仍能接近原生代码的性能。

图形渲染与第三方库

完成解析后，Blink 开始渲染（Rendering），也就是布局和显示网页的工作。为了渲染图形，Blink 使用开源的 Skia 图形引擎 与底层的图形硬件交互。

Skia 是 Google 维护的开源 2D 图形库，不仅用于 Chrome，还是 Android、Flutter 和 Firefox 等项目的图形后端。Skia 将高层的绘图命令（如绘制路径、文本、图像）转换为底层图形 API 调用，支持 OpenGL、Vulkan、Metal 和 Direct3D 等多种后端。在 Chrome 中，合成器线程利用 GPU 进行图层合成和动画处理，使得 CSS 变换（transform）和透明度（opacity）动画能够在不触发主线程重新布局的情况下流畅运行，这就是开发者被建议优先使用 transform 而非修改 top/left 属性来实现动画的技术原因。

此外，Blink 还依赖多个第三方库。例如 WebGL 用于渲染交互式的 2D 和 3D 图形——想直观感受 WebGL 的威力，可以体验分形渲染应用 Fractures。

完整链条：一次点击的全景回顾

把整个流程串起来，当你点击一个链接时，Chrome 依次完成了这些事：

1. 通过 Blink 访问手机或电脑操作系统的底层网络栈；
2. 网络栈向设备网卡发起请求，与互联网服务商建立连接；
3. 通过 DNS 解析将域名翻译为 IP 地址，经过多级缓存逐级查询；
4. 在 Chrome 与 Web 服务器之间通过三次握手建立 TCP 会话；
5. 通过 TLS 握手建立加密通道，确保通信安全；
6. 通过 HTTP 请求与响应 获取网页资源；
7. Blink 解析 HTML/CSS 构建 DOM 树和 CSSOM 树，V8 通过 JIT 编译解析并执行 JavaScript 与 WebAssembly；
8. 经过布局、绘制、合成等渲染流水线阶段，最终渲染出你能查看和交互的网页。

看似一瞬间的「点击」，实际上是操作系统、网络硬件、协议栈、加密层与浏览器引擎的一场高度协同的接力赛。理解这条链路，不仅能帮助开发者更好地优化性能与排查问题，也让我们对每天使用的浏览器多了一份敬畏。