从输入 URL 到页面显示，中间发生了什么？

输入 https://neoapp.top，按下回车。一个看似普通的动作，其实把网络中的多层协议连成了一条链。下面沿着常见的 HTTPS 请求路径走一遍。

第一步：找到服务器

域名是方便人记忆的名字，建立连接还需要目标地址。浏览器和操作系统会先检查已有的解析缓存；没有可用结果时，再向 DNS 解析器查询。

可以把 DNS 理解为一张分布式的地址簿。它并不是每次都从根服务器查起，缓存与记录的 TTL 会影响实际查询路径。

# 查询 IPv4 地址
dig neoapp.top A +short

# 查询 IPv6 地址
dig neoapp.top AAAA +short

解析成功不等于网站可用。地址可能指错，端口也可能没有开放。排查时，应当分别确认「名字是否正确」和「服务是否能连接」。

第二步：建立安全连接

以新建的 HTTP/1.1 或 HTTP/2 连接为例，客户端先通过 TCP 与服务端建立连接，然后进行 TLS 握手。浏览器会校验证书的域名、有效期和信任链，并协商保护后续通信所需的参数。

HTTP/3 则运行在基于 UDP 的 QUIC 上，连接建立方式有所不同。因此，「访问网页一定先进行 TCP 三次握手」并不是适用于所有情况的结论。

浏览器 → DNS 解析 → 连接建立 → TLS
                         ↓
浏览器 ← HTML / CSS / JS ← HTTP 请求与响应

第三步：交换 HTTP 消息

客户端用请求方法、路径和请求头说明自己想要什么，服务器通过状态码、响应头和响应体作答。例如：

GET / HTTP/1.1
Host: neoapp.top
Accept: text/html

返回 200 表示请求成功，301 或 308 表示永久重定向，404 表示没有找到资源。状态码描述请求结果，不能直接代替业务是否成功的判断。

第四步：把文档变成像素

浏览器解析 HTML，构建 DOM；解析 CSS，得到样式信息。随后进行布局，决定元素的位置与尺寸，再经过绘制、合成等步骤将页面呈现出来。

HTML 中的样式表、脚本和图片还可能触发更多请求。脚本执行、字体加载和样式依赖都会影响用户什么时候看到内容，以及什么时候可以操作页面。

用工具验证直觉

# 查看响应头与重定向
curl -I https://neoapp.top

# 查看一次请求的阶段耗时，单位为秒
curl -o /dev/null -s -w \
'DNS: %{time_namelookup}\nTCP: %{time_connect}\nTLS: %{time_appconnect}\n首字节: %{time_starttransfer}\n总耗时: %{time_total}\n' \
https://neoapp.top

这些时间通常从请求开始累计计算，不能直接当作每个阶段的独立耗时。结合浏览器开发者工具里的 Network 面板，才能更清楚地区分连接、等待和下载。

一次页面访问不是单一事件，而是一条可以逐段观察的链路。遇到问题时，先判断故障在哪一层，通常比反复刷新更有帮助。

继续阅读

EOF / 感谢阅读继续探索 ↗