在浏览器中输入 google.com 后发生了什么：从 DNS 解析到页面渲染的完整链路解析-平芜编程栈

后端
文档
教程

【免费下载链接】system-design-101

Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.

项目地址：https://gitcode.com/GitHub_Trending/sy/system-design-101

在浏览器地址栏输入google.com并按下回车，到页面完整呈现在屏幕上，这短短数百毫秒内发生了一连串精密的网络与渲染动作。本指南以 System Design 101 仓库中的《What Happens When You Type google.com Into a Browser?》为核心脉络，结合仓库内 DNS、TCP、HTTP、浏览器渲染等专题文档，逐层拆解这条完整链路。读完本文，你将能用自己的语言讲清楚 DNS 查询、TCP 三次握手、HTTP 请求与浏览器渲染管线这四大环节，并掌握其中每个环节的关键概念与排查思路——这正是技术面试中高频考察的基础题。

全链路总览：输入地址后的 8 个关键动作

当你在浏览器地址栏输入google.com并回车，浏览器会依次执行以下 8 个步骤：

在地址栏输入网站地址；
浏览器先检查自身缓存，若缓存未命中（cache miss），则必须找到该域名对应的 IP 地址；
开始 DNS 查找（可以理解为"查电话号码"）：请求依次经过根（root）、顶级域（TLD）和权威（authoritative）DNS 服务器，最终拿到 IP 地址；
浏览器发起 TCP 连接（类似握手）：以 HTTP 1.1 为例，客户端与服务端通过 SYN、SYN-ACK、ACK 三个报文完成 TCP 三次握手；
握手成功后，浏览器向服务器发送 HTTP 请求，服务器返回 HTML、CSS 与 JS 文件；
浏览器开始处理一切：解析 HTML 文档，构建 DOM 树与 CSSOM 树；
浏览器执行 JavaScript，并通过 tokenizer、parser、render tree、layout、painting 等多个步骤渲染页面；
网页最终呈现在屏幕上。

下面我们沿着这条链路，逐步深入每个环节的原理。

第一步：URL 输入与浏览器对请求的预处理

用户在地址栏输入google.com并回车，浏览器首先需要理解这个输入。更完整的 URL 通常由四部分构成（参考仓库中《What Happens When You Type a URL Into Your Browser?》的讲解）：

组成部分	示例	作用
scheme（协议）	`http://`/`https://`	告诉浏览器使用什么协议与服务器通信
domain（域名）	`google.com`	网站的域名名称，人类可读
path（路径）	`product/electric`	服务器上请求资源的路径
resource（资源）	`phone`	用户想要访问的具体资源名

第二步：浏览器缓存检查——为什么本地缓存是第一步

在发起任何网络请求之前，浏览器会先在本地缓存中查找目标资源。这一步的目的非常明确：DNS 查找与网络请求都是昂贵的操作，能命中缓存就绝不走网络。

缓存失败（cache miss）后，浏览器才需要进入下一步——寻找域名对应的 IP 地址。

值得一提的是，为了加速查找，DNS 数据本身也会在多个层次被缓存：浏览器缓存、操作系统（OS）缓存、本地网络缓存、ISP 缓存。如果这些缓存层都无法命中，浏览器才会发起真正的递归 DNS 查询（详见《What Happens When You Type a URL Into Your Browser?》）。

第三步：DNS 查找——互联网的"电话簿"如何工作

DNS（Domain Name System）就像一本地址簿：它把人类可读的域名（如google.com）翻译成机器可读的 IP 地址（如142.251.46.238）。这一过程在《How Does the Domain Name System (DNS) Lookup Work?》中有详细讲解。

DNS 服务器的层级结构

为了支撑海量查询，DNS 服务器采用层级树状结构组织，共有三层基础服务器：

根名称服务器（Root Name Server，.）：存储所有顶级域（TLD）名称服务器的 IP 地址。全球逻辑上共有 13 个根名称服务器。
顶级域名称服务器（TLD Name Server）：存储权威名称服务器的 IP 地址。TLD 有多种类型，例如通用顶级域（.com、.org）、国家代码顶级域（.us）、测试顶级域（.test）。
权威名称服务器（Authoritative Name Server）：为 DNS 查询提供最终的实际答案。你可以通过 GoDaddy、Namecheap 等域名注册商注册自己的权威名称服务器。

一次完整的 DNS 查询流程

以google.com为例，一次完整的递归 DNS 查询共 8 步：

浏览器将google.com发送给 DNS 解析器（DNS resolver）；
解析器向 DNS 根名称服务器发起查询；
根服务器向解析器返回顶级域 DNS 服务器的地址（本例中为.com）；
解析器向.com顶级域服务器发起请求；
TLD 服务器返回google.com的权威名称服务器 IP 地址；
DNS 解析器向该域名的名称服务器发起查询；
权威名称服务器向解析器返回google.com的 IP 地址；
DNS 解析器将 IP 地址（如142.251.46.238）返回给最初发起请求的浏览器。

按照 YSlow 的统计，一次 DNS 查询平均耗时约20–120 毫秒——这正是为什么缓存如此重要：一次未命中的 DNS 查询就可能消耗掉上百毫秒。

常见的 DNS 记录类型

了解 DNS 解析后，有必要认识其中涉及的记录类型。仓库中的《DNS Record Types You Should Know》总结了 8 种最常用的 DNS 记录：

记录类型	全称	作用
A	Address	将域名映射到 IPv4 地址，是最基础的记录
AAAA	Address (IPv6)	类似 A 记录，但映射到 IPv6 地址
CNAME	Canonical Name	将一个域名别名指向另一个域名，常用于子域名指向主域名
PTR	Pointer	提供反向 DNS 查询，将 IP 地址映射回域名，常用于验证服务器真实性
MX	Mail Exchange	将邮件流量导向正确的邮件服务器
NS	Name Server	指定该域名的权威 DNS 服务器
SRV	Service	为特定服务（如 VoIP）指定主机和端口
TXT	Text	允许管理员添加可读文本，常用于 SPF 等邮件安全验证记录

第四步：TCP 三次握手——建立可靠连接的基石

拿到 IP 地址后，浏览器需要与服务器建立 TCP 连接。TCP 提供可靠的、面向连接的通信，其建立过程被称为三次握手（three-way handshake）。以 HTTP 1.1 为例：

客户端发送SYN报文，请求建立连接；
服务器回应SYN-ACK报文，确认并同步；
客户端发送ACK报文，确认收到。

至此连接建立，双方可以开始可靠地传输数据。TCP 是 HTTP 1.1 与 HTTP 2 的底层传输协议，它保证了报文不丢失、不乱序，但也带来了握手开销——这是后续 HTTP 3 迁移到基于 UDP 的 QUIC 协议的重要原因之一（详见《HTTP/1 → HTTP/2 → HTTP/3》）。

补充：HTTPS 场景下的握手延伸

如果你访问的是https://google.com，在 TCP 握手之后还会叠加一层TLS 握手（详见《How does HTTPS work?》）：

客户端发送client hello，携带它支持的加密算法（cipher suites）与最新的 TLS 版本；
服务器回应server hello，确认算法与版本，并下发包含公钥、主机名、有效期等信息的 SSL 证书，客户端校验证书；
客户端生成会话密钥（session key），用服务器的公钥加密后发送；服务器用私钥解密，得到同一把会话密钥；
此后双方用这把会话密钥（对称加密）建立安全的双向加密通道。

HTTPS 之所以在数据传输阶段改用对称加密，原因有二：安全性——非对称加密是单向的，若服务器用公钥加密数据返回给客户端，任何人都能用公开的公钥解密；服务器资源——非对称加密的数学开销很大，不适合长时间会话中的大量数据传输。

第五步：HTTP 请求与响应——浏览器与服务器的对话

TCP（以及必要的 TLS）连接建立后，浏览器向服务器发送 HTTP 请求。以example.com/phone为例，请求报文形如：

GET /phone HTTP/1.1 Host: example.com

服务器处理请求后返回响应。成功响应（状态码 200）的报文可能如下：

HTTP/1.1 200 OK Date: Sun, 30 Jan 2022 00:01:01 GMT Server: Apache Content-Type: text/html; charset=utf-8 <!DOCTYPE html> <html lang="en"> Hello world </html>

响应体中包含 HTML、CSS 和 JS 文件——浏览器后续的全部渲染工作，都基于这批文件展开。

第六步：解析 HTML 与 CSS——构建 DOM 树和 CSSOM 树

浏览器收到 HTML 数据后立即开始解析，这一渲染流程在《How Browsers Render Web Pages》中有系统讲解：

解析 HTML，生成 DOM（Document Object Model）树：浏览器将收到的 HTML 逐字节解析，转换为内存中的 DOM 树结构；
解析 CSS，生成 CSSOM（CSS Object Model）树：CSS 文件被加载并解析为 CSSOM；
合并 DOM 树与 CSSOM 树，构建渲染树（Render Tree）：渲染树映射了所有可见的 DOM 结构，会排除不可见元素（如<head>或display:none;的元素）。换言之，渲染树是 DOM 的"视觉化表示"。

第七步：JavaScript 执行与渲染管线

JavaScript 的执行

浏览器解析到<script>标签时，会交由 JavaScript 引擎执行。仓库中的《How does JavaScript Work?》总结了 JavaScript 的核心特性：

解释型语言：JS 由浏览器或 JS 引擎直接执行，而非预先编译为机器语言；现代引擎（如 V8）采用JIT（即时编译）技术，将代码编译为可直接执行的机器码；
函数是一等公民：函数可存入变量、作为参数传递、作为返回值返回；
动态类型：无需预先声明变量类型，类型可在运行时改变；
客户端异步执行：支持异步编程，文件读取、HTTP 请求、数据库查询等操作可在后台运行，完成后触发回调或 Promise，这对改善 Web 性能和用户体验至关重要；
基于原型（Prototype）的 OOP：对象可以从其他对象继承属性和方法；
自动垃圾回收：自动回收程序中不再使用的对象所占内存，防止内存泄漏、优化应用性能。

渲染管线的后续步骤

JavaScript 执行完毕后，浏览器继续渲染流程：

Layout（布局）：计算渲染树中每个元素的几何信息（位置、大小），这一步骤称为布局；
Painting（绘制）：布局完成后，渲染树被转换为屏幕上的实际内容，浏览器获取内容的绝对像素；
Display（显示）：浏览器将绝对像素交给 GPU，最终显示在页面上。

第八步：页面呈现——一条链路的终点，也是性能优化的起点

网页最终呈现在屏幕上，一次完整的"输入 → 呈现"旅程就此完成。整条链路中任何一环都可能成为性能瓶颈：

DNS 环节：平均 20–120 毫秒的查询耗时，依赖多层缓存加速；
TCP/TLS 环节：三次握手与 TLS 握手叠加，带来明显的往返延迟；
HTTP 环节：协议版本（HTTP/1.1 → HTTP/2 → HTTP/3）直接影响传输效率；
渲染环节：DOM/CSSOM 构建、布局与绘制全部阻塞在浏览器主线程上。

理解这条链路，不仅是为了面试，更是 Web 性能优化、网络问题排查（DNS 解析失败、连接超时、渲染卡顿）的必备知识框架。

在仓库中继续深入

本文所依赖的原始文档《What Happens When You Type google.com Into a Browser?》位于仓库的data/guides/目录，属于technical-interviews分类。该仓库通过 README.md 中的 TOC 组织全部指南，相关主题文档还包括：