网络请求到底在后台干了啥？三步看懂底层原理

你点一下网页按钮，页面就刷新了；发个 API 请求，数据就回来了。但你有没有想过：这背后到底发生了什么？不是浏览器自动搞定的，而是有一套清晰、可追踪的底层流程。

第一步：DNS 查域名，就像查电话簿

你输入 https://api.example.com，浏览器第一件事不是连服务器，而是先问：“这个域名对应的 IP 地址是啥？”——它会查本地 DNS 缓存，查不到就去问运营商 DNS，再不行就层层往上问到根域名服务器。整个过程可能耗时几十毫秒，但你看不见。如果这一步卡住，浏览器地址栏就会一直转圈，连“连接超时”都不报，因为根本还没开始连。

你可以用命令行验证：

nslookup api.example.com

dig api.example.com +trace

第二步：TCP 握手建通道，三次确认才敢说话

拿到 IP 后，浏览器要和服务器“约个通话”。不是直接开讲，而是走标准 TCP 三次握手：

• 浏览器发：SYN（同步）→ “我想连你”
• 服务器回：SYN+ACK → “收到，我也想连”
• 浏览器再回：ACK → “好，那咱开始吧”

这三步缺一不可。中间任何一步丢包或超时（比如防火墙拦了 SYN），连接就建立失败。这时候 Chrome 开发者工具 Network 标签页里，请求状态会卡在 pending 或直接显示 net::ERR_CONNECTION_TIMED_OUT。

第三步：发 HTTP 报文，明文写清“我要啥”

通道建好后，浏览器才真正发出请求。别被“HTTP/HTTPS”吓住，它本质就是一段纯文本。比如 GET 请求长这样：

GET /v1/users?id=123 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json

注意最后两个 \r\n 是空行，代表 Header 结束。服务器收到后解析路径、参数、头信息，再返回响应。如果是 HTTPS，这段内容会在 TLS 层加密后再发出去，但握手（TLS 握手）是在 TCP 连接之后、HTTP 发送之前完成的。

排错时，用 curl -v 最直观：

curl -v https://api.example.com/v1/test

所以下次接口调不通，别急着改代码。先打开开发者工具 Network 面板，看请求卡在哪一列：Stalled？可能是 DNS 或队列问题；Connecting 老不动？大概率是网络或防火墙挡了 TCP；TLS handshake 耗时太久？证书或协议版本可能不兼容。