从 URL 到页面展示，还有哪些你忽略的底层细节？（DNS 与传输篇）

上一篇文章我们用「浏览器多进程架构」为主线，拆解了从输入 URL 到页面渲染的完整导航过程。很多读者反馈：DNS 和传输层部分还值得再挖深一点 ------ 面试时能不能多讲一些「IP 地址背后的事」？数据到底是怎么从服务器跑到浏览器的？

今天我们就顺着这条链路，把 DNS 的兜底逻辑 、负载均衡 、OSI 模型下的数据封包一次讲透，让你在面试中再往底层迈一步。

一、DNS 返回的 IP，并不是最终服务器的 IP

很多人以为 DNS 解析后直接拿到的是真实 Web 服务器的 IP，其实不是。

你可以亲自在 Chrome 地址栏输入 chrome://net-internals/#dns，就能看到浏览器缓存的 DNS 记录。查询一个大型网站，返回的经常是一个 IP 数组（多个地址），而不是单个 IP。

这就是分布式服务器集群 所带来的现象。真正和浏览器通信的通常是一台 反向代理服务器（比如 Nginx），它充当"媒婆"的角色：

请求先到这台 Nginx 代理
代理背后有成百上千台真实业务服务器
代理根据负载均衡策略，选择一台把请求转发过去

负载均衡怎么选服务器？

常见的策略有：

轮询：按顺序一台一台分配
加权轮询：配置高的机器多承担一些请求
最少连接数：谁当前任务少就发给谁
IP 哈希：让同一用户的请求落到同一台服务器（便于 session 保持）

这样一来，即使某台服务器宕机，代理也能把流量导到健康节点，用户几乎无感知。

二、离你最近的 IP：CDN 的地域性调度

DNS 解析还有一个高级技能：根据你的地理位置，返回离你最近的节点 IP。

很多大厂在全国（甚至全球）部署机房，DNS 解析服务会通过用户的 Local DNS 出口 IP 判断你的城市，然后返回附近机房的 Nginx 代理 IP。这就是 CDN 就近接入的底层逻辑。

比如在北京访问 douyin.com，DNS 可能解析到北京的边缘节点；到了上海出差，解析结果会变成上海的节点。不仅降低了延迟，也分散了源站压力。

小技巧：你可以用 nslookup 或 ping 测试域名在不同网络下的 IP，能看到 CDN 调度的效果。

三、本地 DNS 的"后门"：hosts 文件

在 DNS 查询链路中，有一个优先级很高却常被开发者忽略的环节：操作系统 hosts 文件。

Windows 路径：

makefile 复制代码

C:\Windows\System32\drivers\etc\hosts

macOS / Linux 路径：

bash 复制代码

/etc/hosts

它可以手动定义域名到 IP 的映射，比如：

复制代码

127.0.0.1  douyin.com

这样访问 douyin.com 时，浏览器就直接走本地回环地址，完全跳过 DNS 解析。

实际开发中的妙用

本地开发时，将测试域名指向 127.0.0.1，就能用真实域名测试 cookie、token 等域名相关逻辑。
线上故障应急时，有时会临时修改 hosts 跳过故障 DNS 或直奔某台服务器。

注意，localhost 这类特殊域名甚至不需解析，操作系统就直接识别成环回地址。

四、数据如何上路：OSI 七层模型形象理解

DNS 拿到 IP 之后，浏览器开始和服务器建立连接，真正传输数据。

这就进入到了经典的 OSI 七层模型（实际互联网更多用 TCP/IP 四层），从下往上看数据的变化：

物理层

网线、光纤、无线电波。传输的最底层是 0 和 1 的电信号或光信号。
数据链路层

数据被加上 MAC 地址（每台上网设备的唯一硬件标识），组成数据帧。
复制代码
```
目标 MAC + 源 MAC + 数据
```
网络层

加上 IP 地址，让数据能够跨网络到达目标主机。
复制代码
```
目标 IP + 源 IP + MAC + 数据
```
传输层

再加上 TCP 或 UDP 协议头 。TCP 头部包含序号、确认号、窗口大小等，保证可靠性。
复制代码
```
TCP 头（序号...）+ IP + MAC + 数据
```

这就像寄快递：

物理层是公路/飞机
链路层是小区收发室（MAC）
网络层是城市和街道（IP）
传输层是快递公司的签收规则（保证不丢件、不乱序）

五、TCP：可靠传输的规矩

HTTP 协议基于 TCP，而 TCP 为了保证数据完整有序，制定了一套规矩：

1. 拆包与并发传输

服务器要返回一个 HTML 文件，可能几十 KB 甚至几百 KB。TCP 不会一次性全部扔到网上，而会切分成固定大小（MSS）的数据包，分批次、多通道并发发送。

这样即使某个包卡住了，其他包也能继续前进，提高效率。

2. 序号与排序

每个包在 TCP 头部都带着序号，接收端按序号重新拼装数据。

即使包到达的顺序是乱的（因为网络路由不同），也能重新排好。

3. 丢包重发

如果发送方一段时间没收到某个包的确认（ACK），就认为丢包，触发自动重传。这就是 TCP 可靠性的保障。

对比 UDP：UDP 不建立连接、不保证顺序、不重传，但速度快，适合直播、视频会议等对实时性要求高的场景。

4. 三次握手本质

我们在上一篇文章提过三次握手，其实它的核心就是同步双方的初始序号，确认彼此收发能力正常。只有握手完成后，浏览器才会发送真正的 HTTP 请求。

六、落地到面试：你能这样说

当面试官问起"DNS 过程中做了什么"，你可以这样组织语言：

浏览器先查本地缓存（含 chrome://net-internals/#dns 记录）和操作系统 hosts 文件。
没有命中，则逐级向上递归查询，直到拿到 IP（很可能是一个反向代理 IP）。
这个 IP 背后通常是 Nginx 等代理，代理根据负载均衡策略将请求转发到内部某台真实服务器。
同时 CDN 会通过 DNS 智能解析，返回离用户最近的边缘节点 IP。

问到数据传输，可以补充：

物理层、链路层、网络层、传输层的逐层封包过程
TCP 通过拆包、序号、重传来保证可靠性，而 UDP 牺牲可靠性换取速度
三次握手是为了同步序号、验证双方收发能力

这样，不仅讲清了前端视角的请求全过程，还向下扎到了网络架构和传输原理，能充分展示你的计算机基础。

掌握这些细节，你再回答那道经典面试题时，就不再是"表面流程复读机"，而是一个能讲出"为什么"和"底层发生了什么"的开发者。下一期我们可以继续聊聊 HTTPS 的 TLS 握手，敬请期待。