URL、DNS 与连接建立
浏览器网络这一层里,很多问题表面看像“接口慢”或“页面打不开”,实际根子可能在请求真正发出去之前。
这条链路通常会经过:
- URL 解析
- DNS 查询
- 连接建立
- TLS 握手
- 请求发送
- 首字节返回
把这条线理顺之后,很多性能问题和网络故障会更容易定位。
从输入一个地址开始,会先发生什么
最常见的顺序可以先记成这样:
- 浏览器解析 URL
- 查缓存、查 DNS
- 建立连接
- HTTPS 站点做 TLS 握手
- 发请求
- 收到响应首字节
- 浏览器继续处理 HTML、CSS、JS
这条链路里,前面几步如果慢,页面还没到渲染阶段就已经掉速了。
URL 先拆哪几部分
一个 URL 最常见会拆成这些:
https://example.com:443/path?tab=1#section
- 协议:
https - 域名:
example.com - 端口:
443 - 路径:
/path - 查询参数:
?tab=1 - hash:
#section
为什么这层值得前端单独看
因为很多问题并不是请求逻辑本身,而是:
- query 拼错
- hash 只影响前端,不会发给服务端
- 同源判断和协议 / 域名 / 端口直接相关
- 相对路径、绝对路径、资源路径很容易混
MDN 的 URL API 文档也很适合配合这一层一起看。
DNS 在做什么
DNS 的作用很直接:把域名解析成 IP 地址。
浏览器发起请求前,至少得知道目标主机在哪。
DNS 常见查询顺序,先记住大概就够了
- 浏览器缓存
- 操作系统缓存
- 路由器或本地网络缓存
- ISP DNS
- 权威 DNS
前端平时不一定要深究每一跳,但要知道:
- DNS 本身就可能是耗时来源
- 域名很多、第三方资源很多时,DNS 开销会累积
- 首次访问和复访的体验可能不一样
连接建立怎么理解
HTTP
通常基于 TCP。
HTTPS
通常是 TCP 连接之后再做 TLS 握手。
HTTP/3
通常基于 QUIC / UDP。
所以“一个请求出去”并不只是发一个报文,前面还有连接准备成本。
TCP 握手为什么和前端有关
虽然三次握手属于传输层,但前端仍然要关心它,因为:
- 新建连接有成本
- 域名拆得太散,会增加连接数
- 弱网环境下,建连时间本身就会影响首屏
这也是为什么:
- CDN
- 资源复用
- keep-alive
- HTTP/2 多路复用
会直接影响前端体验。
TLS 握手为什么值得单独看
HTTPS 比 HTTP 更安全,但也多了一段握手流程。
这层会带来:
- 证书校验
- 加密套件协商
- 会话建立
前端更该关心的是结果:
- 所有主资源和子资源都应该优先走 HTTPS
- 混合内容会被浏览器拦截
- 安全上下文能力会受协议影响
从时间指标上怎么观察这条链路
浏览器性能面板里经常能看到这些阶段:
- DNS Lookup
- Initial Connection
- SSL
- TTFB
- Content Download
如果页面慢,先看慢在:
- 域名解析
- 连接建立
- TLS
- 服务端响应
- 资源下载
这个排查顺序会比只说“接口很慢”更具体。
TTFB 到底怎么看
TTFB,Time to First Byte,通常表示从请求开始到收到首字节的时间。
它背后可能包含:
- DNS
- 连接建立
- TLS
- 服务端处理
- 回包开始
所以 TTFB 高,并不自动等于“后端逻辑慢”。
也可能是:
- DNS 慢
- 网络慢
- 建连慢
- CDN 回源慢
前端高频会踩的几类问题
1. 第三方域名太多
广告、埋点、图标、字体、图片、地图服务一多,DNS 和连接成本会迅速堆高。
2. 首屏关键资源分散在很多域名
这样会增加:
- DNS 查询数
- TCP / TLS 连接数
- 首屏等待时间
3. 只盯着接口耗时,不看建连耗时
很多“接口慢”的问题,Network 面板里其实是卡在连接前半段。
4. 误把 hash 当服务端参数
#fragment 不会发给服务端,这在路由、锚点、OAuth 回跳排查时很常见。
DevTools 里最值得先看什么
前端排查网络问题时,最先看这几项通常最有效:
- 请求发往哪个域名
- DNS 是否耗时明显
- 连接是否复用
- 是否有 SSL / handshake 时间
TTFB高不高- 状态码和响应头是什么
和这组其他文章怎么配合看
- 想继续看协议层差异:看
HTTP 与 HTTPS - 想继续看缓存:看
浏览器缓存 - 想继续看性能指标:看
浏览器性能指标与观察能力