在浏览器输入一个 URL 后，互联网到底发生了什么？

引言：回车之后的一秒钟

在地址栏输入 https://www.example.com/index.html 并按下回车，页面通常在一秒内出现。这一秒里发生的事，拆开看是一份不小的工程清单：一次全球分布式的名字查询、至少两个往返的连接协商、一段跨越十几台路由器的传输、几十个后续资源请求，以及一次从字节到像素的渲染。

这个过程值得被完整走一遍，原因有二。其一，它是理解计算机网络的最好入口——链路上的每一站都对应一个协议层，走完一遍就摸到了整个协议栈的轮廓。其二，它是本专题的地图：本文只负责把每一站指认出来，站内的机制细节留给后续各篇逐一展开。

交互演示

图中用往返时延（Round-Trip Time，RTT）而不是毫秒作为刻度，因为毫秒数完全取决于两端的距离，而距离带来的时延有一个无法绕开的物理下限。切换到「连接复用」可以看出：第二次访问省下的不是处理时间，而是 DNS 查询与两次握手所需的往返。这条线索贯穿全文。

一、URL 解析：把一行字符拆成任务单

统一资源定位符（Uniform Resource Locator，URL）看起来像一整个字符串，浏览器读到的是一张结构化的任务单。以 https://www.example.com/index.html 为例，它被拆成四个要素：

要素	值	决定什么
协议（scheme）	`https`	用哪套应用层规则对话，以及默认端口 443
主机名（host）	`www.example.com`	去找谁
端口（port）	443（https 默认值，被省略）	到达之后敲哪扇门
路径（path）	`/index.html`	要这台机器上的哪份资源

这类似于填一张快递单：协议是运输方式，主机名是城市，端口是小区门牌，路径是具体楼层。拆开之后，浏览器的后续动作完全由这张单子驱动——要加密还是明文、连哪个地址的哪个端口、请求里写什么路径，此时已经全部确定。

完整语法（RFC 3986 与 WHATWG URL 标准）还包含查询串与片段两段。把它们补上，六段信息的去向差别很明显：

交互演示

其中最容易被误解的是片段：# 之后的内容在请求发出前就被浏览器截断，服务器永远看不到它，因此它只能用于页面内定位，不能承载需要服务端处理的参数。而查询串会随请求发送，也会进入服务器日志与 Referer 头，不适合放置敏感信息。

还有三个发生在此刻的隐含动作：浏览器先判断输入的是网址还是搜索词；随后把非 ASCII 域名按 Punycode 转换为 ASCII 形式；再检查 HTTP 严格传输安全（HTTP Strict Transport Security，HSTS）策略，把历史访问中声明过「只走加密」的站点直接从 http 升级为 https，不给中间人降级的机会。最后检查本地缓存，若这份资源仍新鲜，链路到此为止，根本不会接触网络。下面的讨论按缓存全部未命中的完整路径展开。

二、DNS：从主机名到 IP 地址

任务单上的主机名是给人类看的名字，网络层只认数字地址。把 www.example.com 翻译成 IP 地址的系统是域名系统（Domain Name System，DNS）——一个分布在全球的层级化数据库。

它像查一本分层组织的通讯录：先查自己手边的便签，再查桌上的通讯录，都没有才逐级问「谁负责管理这个区」。精确地说，查询沿四级缓存与三级服务器推进：

浏览器缓存：刚访问过的域名直接命中，耗时不足 1 ms，这是绝大多数重复访问的实际情况；
操作系统缓存与 hosts 文件：系统级缓存，以及本地静态映射；
递归解析器：通常由运营商或公共 DNS（如 114.114.114.114、8.8.8.8）提供，它收下查询后代为跑完全程——「递归」指的就是这种代查行为；
根 → 顶级域 → 权威：递归解析器先问根服务器「.com 归谁管」，再问 .com 顶级域服务器「example.com 的权威在哪」，最后从权威服务器拿到 A 记录本身。

交互演示

这条链路的关键在于根与顶级域服务器从不直接回答地址，它们只回答「去问谁」。正是这种逐级委派，让全球域名可以分散管理，任何一级都不必知道全部信息。根服务器只有 13 组逻辑标识（A 到 M），但通过任播技术在全球部署了上千个节点实例，查询通常落在物理上最近的一个。

答案返回时自带生存时间（Time To Live，TTL），沿途每一级缓存都按 TTL 留存副本——这是 DNS 能在全球规模下保持秒级以内响应的核心设计。

两个值得记住的事实。第一，DNS 查询默认跑在用户数据报协议（User Datagram Protocol，UDP）的 53 端口上，一问一答两个报文，不为它先建连接。第二，缓存既是性能的来源也是故障的来源——修改域名解析后「为什么没生效」，答案几乎总是某级缓存的 TTL 尚未到期。需要变更解析时，提前把 TTL 调小，等旧值过期后再修改，是常规做法。

三、TCP 与 TLS：接通管道，再为管道上锁

拿到 IP 地址后，浏览器请操作系统建立传输通道。这一步分两段：先用传输控制协议（Transmission Control Protocol，TCP）接通，再用传输层安全（Transport Layer Security，TLS）加密。

TCP 三次握手交换三个报文：客户端发 SYN（我想建立连接，我的起始序列号是 x），服务器回 SYN-ACK（收到，我的起始序列号是 y），客户端再回 ACK（收到，可以开始了）。它像打电话时的互相确认：「听得到吗」「听得到，你呢」「我也听得到」——说完这三句，双方都知道彼此能收能发。精确地说，握手的目的是同步双方的初始序列号，并确认双向可达；只握两次，服务器无法确认客户端真能收到自己的应答，还可能被网络中延迟滞留的旧连接请求骗出一个空连接。

TLS 握手紧随其后。TLS 1.3（RFC 8446）把密钥协商与证书验证压缩进一个往返：双方交换密钥材料，算出只有彼此知道的会话密钥；服务器出示证书，浏览器沿着证书链验证到内置的根证书，确认对端确实是目标站点。证书体系本身的运作方式，本站的 SSL 系列有专门讨论，例如默克尔树证书如何重建后量子时代的信任。此后所有 HTTP 报文都经加密与完整性校验后才进入 TCP。

这两段握手的代价可以精确计算：TCP 一个 RTT，TLS 1.3 再一个，合计约 2 个 RTT。RTT 的价值取决于物理距离——而物理距离由光速锁定，无法压缩。

一次往返的时间尺度——光速在光纤中约 20 万公里/秒。同城往返 5 ms 与跨太平洋往返 150 ms 之间没有优化空间，协议能省的只有往返的次数。

同城访问时，2 个 RTT 约 10 ms，无感；跨太平洋时则是 300 ms 起步，仅建立安全连接就已超过半秒预算的边缘。既然单次往返的时间由距离锁定，协议演进能做的只剩一件事：减少次数。

交互演示

四种组合的差别正是近十年传输层演进的全部内容：TLS 1.2 需要两个往返完成握手，TLS 1.3 让客户端在第一个报文里就带上密钥份额，压缩到一个；QUIC 把传输层握手与加密握手合并，首次连接只用一个往返；0-RTT 则复用此前保存的会话密钥，请求与握手一同发出。

0-RTT 的代价必须说清楚：这部分数据不具备重放保护，攻击者截获后可以重复发送，因此只适用于重复执行不产生副作用的请求。这是一个典型取舍——用安全边界换一次往返。

QUIC 选择建立在 UDP 之上而非改造 TCP，同样是工程权衡：TCP 实现在操作系统内核与大量中间设备里，任何修改都需要漫长的部署周期；而 UDP 之上的协议可以随浏览器与服务器软件一起更新。

四、分层与转发：数据包在路上的形态

连接建立后，请求报文出发。它在路上的形态由分层决定：每一层只解决一个问题，并在数据前面加上自己需要的一小段头部。

交互演示

自上而下，四层各自回答一个问题：应用层的 HTTP 说明「要哪个资源」；传输层的 TCP 头写入端口，让数据能交付到对端机器上的具体进程，并用序列号为可靠传输做准备；网络层的 IP 头写入源与目的地址，这是跨越整个互联网寻址的依据；链路层的以太网帧头写入下一跳设备的媒体访问控制地址（Media Access Control Address，MAC 地址），负责把数据送到线缆另一端的相邻设备。

这里还有一个约束：以太网单帧最多承载 1500 字节，称为最大传输单元（Maximum Transmission Unit，MTU）。超过这个长度的数据必须拆成多个报文分别发送。

包出发之后，互联网协议（Internet Protocol，IP）规定的转发方式是一场接力：每台路由器只读 IP 头里的目的地址，查路由表选出下一跳，把包交过去，不关心包里装的是什么，也不记得自己转发过什么。

接力中有一个容易被忽略的事实：帧头每跳重写，IP 头全程不动。IP 地址标记的是整场旅程的终点，而 MAC 地址只标记当前这一跳的两端。包每经过一台路由器，旧的以太网帧头被拆掉，按下一跳的 MAC 地址（由地址解析协议（Address Resolution Protocol，ARP）查明）重新封装。同时 IP 头中的 TTL 字段减一——这是防止路由环路让包无限打转的保险丝，减到零即丢弃。

第一跳还有一道额外工序：家庭路由器执行网络地址转换（Network Address Translation，NAT），把 RFC 1918 私有地址（如 192.168.x.x）改写成公网地址与端口。整个小区的设备共享一个公网出口，正是靠这张改写表维持。

一个数据包的逐跳之旅——注意观察封装栈：以太网帧头在每一跳被拆掉重写，IP 头只有 TTL 递减，HTTP 数据全程未被中间设备读取。播放或手动逐跳查看。

分层的价值在这两张图之间显现：把有线换成无线，改变的只是最外层的帧头，上面三层一个字节都不用改；把 TCP 换成 QUIC，HTTP 的语义也保持不变。traceroute 输出的每一行，就是这场接力中的一跳。

五、HTTP：应用层的请求与响应

加密通道就绪，浏览器终于说出此行要说的话。超文本传输协议（HyperText Transfer Protocol，HTTP）的请求报文是一段结构简单的文本：

GET /index.html HTTP/2
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept-Encoding: gzip, br
If-None-Match: "a1b2c3d4"

方法（GET）、路径、协议版本构成请求行；下面的头部各行是附加说明——Host 告诉共用同一 IP 的虚拟主机要访问哪个站点，Cookie 携带登录态。服务器的应答同样以文本开头：状态行（如 HTTP/2 200 OK）、响应头（内容类型、缓存指令），空行之后是 HTML 正文。

状态码是这套对话的速记：2xx 成功，3xx 重定向，4xx 客户端的错，5xx 服务器的错。日常访问里最常见的一次「隐藏对话」就是 301——输入裸域名，服务器先回一句「已永久迁移到 www.example.com」，浏览器拿着新地址自动再走一遍流程，用户看到的只是地址栏悄悄变化。

响应头中的缓存字段决定了后续访问的成本：Cache-Control 指定副本可以直接使用多久，在这段时间内浏览器不再发出请求；过期之后也不必重新下载全文，浏览器带上 If-None-Match 询问内容是否变化，未变则服务器返回 304 Not Modified，只有响应头，没有响应体。

主文档到手只是开始。HTML 里引用的样式表、脚本、图片、字体各自需要一次请求。按 HTTP Archive 的持续统计，中位数网页包含约 70 个请求、数 MB 的传输量。HTTP/1.1 靠浏览器并行开多条连接硬扛，HTTP/2 在单条连接内做多路复用，HTTP/3 把底层整个换成基于 UDP 的 QUIC——这段演进史留到阶段 7 与阶段 8 展开。

还有一个与拥塞控制有关的现象值得提前知道：连接刚建立时 TCP 的发送窗口很小，服务器不能一次把整个页面推出来，而要随着确认逐步放大窗口。因此一个较大的响应即使带宽充足，也需要多次往返才能传完。这是首屏资源应当尽量精简的机制来源。

六、渲染：从字节到像素

响应字节流抵达浏览器后，最后一站在本机完成。渲染管线的动作序列是：HTML 解析为文档对象模型（Document Object Model，DOM）树，CSS 解析为样式规则树，两树合并成只含可见节点的渲染树，随后布局算出每个盒子的几何位置，绘制把各层栅格化为像素，最后由 GPU 合成输出到屏幕。

这条管线里有一个影响性能数十年的细节：解析器遇到同步 JavaScript 会停下执行——脚本可能改写文档，浏览器不敢假设它不会。这是「脚本置底」「加 defer」等经验规则的机制来源，也是理解后续性能优化专题的地基。

渲染管线：从字节到像素——布局与绘制是开销大头。transform 与 opacity 动画只需重做合成一步，这是它们流畅的原因。

解析过程中每遇到一个外部资源——脚本、样式、图片、字体——浏览器就要为它重新走一遍前面的全部流程：可能需要新的 DNS 解析、新的连接、新的握手。一个引用了几十个第三方域名资源的页面，其代价往往不在总字节数，而在反复的连接建立。

七、全景地图与专题路线

走完一遍之后回看，整条链路恰好覆盖了网络分层的全部层级。把各层的职责与常见故障对应起来，就得到一张排查用的地图：

层	回答的问题	代表协议	出问题时的现象
应用层	要什么资源，怎么表达	HTTP、DNS	404、500、页面内容不对
安全层	对端是谁，内容会不会被看到	TLS	证书告警、连接被拒绝
传输层	交给哪个进程，如何保证不丢不乱	TCP、UDP、QUIC	连接超时、速度异常缓慢
网络层	送到互联网上的哪台机器	IP	目标不可达、路由环路
链路层	在这段线缆上交给谁	Ethernet、Wi-Fi	网卡不通、丢包率高

排查网络问题的顺序通常与此一致：先确认链路层通不通，再用 ping 与 traceroute 确认网络层能否到达，然后是传输层端口是否开放，最后才看应用层的响应内容。自下而上逐层排除，比在应用层反复猜测有效得多。

本专题后续的每一篇，对应这条链路上的一站：

计算机网络专题的九个阶段——顺序自下而上：先讲清数据如何在物理网络中流动，再讨论建立在其上的协议。本文是其中的阶段 0。

分层模型在这里的价值可以概括成一句话：每一层只与相邻层交接，只信任自己层内的约定。HTTP 不需要知道光纤怎么走，IP 不需要知道请求的是哪张图片——正是这种「各管一段」的分工，让四十多年前设计的架构能承载今天的互联网。

结语

回车之后的一秒钟，是四个协议层、几十台设备、上万公里光纤协同的结果。这条链路上没有哪一站格外复杂，复杂的是它们恰好严丝合缝地扣在一起。后续各篇的任务，是把本文指认过的每一站拆开，看清里面的齿轮。

术语速查

本文术语表——按「地址与名称 / 链路 / 网络 / 传输 / 安全 / 应用」六类组织，支持关键词搜索；后续各篇的词表将在此基础上扩充。

常见问题

关于这条链路的常见疑问——覆盖本文刻意略过的细节：DNS 的传输选择、握手次数的理由、缓存与 TTL、片段的去向，以及加密之后仍然可见的信息。

参考资料