用三个模拟器把输入 URL 到页面加载的过程跑一遍，比背面试题有用得多

很多人在准备面试或者学习网络协议时，习惯于背诵一套“输入 URL 后发生了什么”的标准答案。但这种记忆法在面对追问（比如：缓存失效了怎么走？为什么第一次请求慢？）时很容易露馅。我建议直接用模拟器跑一遍流程，把 DNS 解析、TCP 握手和数据传输这三个环节拆开看，这样你记住的是逻辑而不是文字。

DNS 解析环节：名字怎么变成 IP 地址

大多数人只能说出“域名解析”这个词，但很少有人能清晰描述递归查询的每一跳。我建议用 DNS Simulator 这种交互工具跑一遍，它把浏览器缓存、操作系统缓存、递归解析器、根服务器、TLD 服务器和权威 DNS 服务器的关系可视化了。

在实际操作中，你会发现几个关键点：

• 缓存优先级： 浏览器和 OS 缓存会先拦截请求。这就是为什么你修改了 DNS 记录后，由于 TTL（生存时间）的存在，不同设备生效时间不一致。
• 递归解析器的角色： 你的电脑并不直接去问根服务器，而是问递归解析器（比如 8.8.8.8），由它替你去跑完整个查询链条。
• 记录类型： 尝试切换 A、AAAA、CNAME 或 MX 记录，你会发现虽然记录类型不同，但查询机制完全一样。

连接建立环节：TCP 握手与 UDP 的区别

拿到 IP 后，浏览器得建立连接。面试官最爱问“为什么 TCP 需要握手而 UDP 不需要”，看一遍 TCP vs UDP 模拟器就明白了。

在这个模拟器里，你可以手动开启“丢包（Packet Loss）”模式，观察两种协议的反应：

• TCP 的行为： 你会看到 SYN → SYN-ACK → ACK 的三路握手过程。当开启丢包后，TCP 监测到序列号缺失，会触发重传机制，直到数据正确送达。
• UDP 的行为： 它只管发，丢了就丢了，没有任何重传逻辑。

这种对比能让你快速理解：TCP 保证的是有序、可靠的字节流，代价是握手耗时和重传开销；而 UDP 追求的是低延迟。顺便提一句，现在的 HTTP/3 跑在 QUIC 协议上，本质就是基于 UDP 重新构建了一套可靠性机制，目的就是为了干掉 TCP 握手的延迟。

请求响应环节：从连接到数据传输

最后一段路是从“连接建立”到“收到响应”。这部分最容易被含糊地概括为“发送请求并接收数据”，但实际中间经历了 TLS 握手、CDN 边缘节点拦截、负载均衡分发等环节。

如果你想在实操中验证这个过程，不需要模拟器，直接在 Chrome 浏览器里按 F12 打开 Network 面板，刷新页面，观察 Waterfall（瀑布流）图：

• DNS Lookup： 耗时通常在几毫秒到几十毫秒。
• Initial Connection： 这就是 TCP 握手时间。
• SSL/TLS： 这是加密握手，通常比 TCP 握手更慢。
• TTFB (Time to First Byte)： 从请求发出到收到第一个字节的时间。如果这个值很高，通常说明后端服务器处理慢或者网络链路太长。

通过这三个环节的拆解，你会发现网络请求不是一个简单的“请求-响应”循环，而是一系列精密的握手和缓存机制。