你在浏览器输入网址并回车，几秒后就看到了页面。但这短短几秒内，发生了极其密集的物理协作。
网页加载的本质，就是你的设备（客户端）跨越千山万水，找别人的电脑（服务器）要一份文本文件。
这不是随口一要就能拿到，机器必须经过以下 6 道关卡。
第 1 关：切碎 URL (拆解目标)
你输入的 https://baidu.com/en-US/ 叫 URL。机器首先会把它分成三个切片：
- https:// (协议)：规定了客户端跟服务器对话必须遵守的语言格式。
- baidu.com (域名)：帮服务器取的网名，方便人脑记忆，但机器读不懂。
- /en-US/ (路径)：指明你要拿的是服务器那台机器上，哪个文件夹下面的具体文件。
第 2 关：DNS 查询 (翻地址本)
底层网络通信全靠认 IP 地址（如 151.101.129.217），它根本不认识 baidu.com 这种方便人类记忆的拼音缩写。
所以浏览器必须停下来，去查一个名为 DNS 服务器 的巨型互联网通讯录，找到这个域名对应的服务器真实 IP 地址。
核心定律：就近查找原则 (多级缓存)
跨网络查 DNS 极慢。为了加快速度，机器会按离自己远近优先翻缓存：先看浏览器自己存了没 ➔ 再看你电脑系统存了没 ➔ 再问你家路由器 ➔ 全没有，最后才去远端查询 DNS 主服务器。一旦找到就立刻停手。这些缓存咋来的？只要你以前访问过一次这个网站，或者这台路由器上别人访问过，机器就会默默把“域名和 IP 的对应关系”抄在小本上存一阵子。下次再来，直接翻本子，省去跨网提问的时间。
第 3 关：建立 TCP 连接 (修通物理公路)
拿到真实 IP 后，客户端和服务器依然不能直接传文件。因为互联网的底层物理线路极其不可靠，经常丢包掉线。
所以它们必须先建立一条带有确认与重传机制的虚拟管道这就叫 TCP 连接。机器通过经典的三次握手（来回对发寥寥几次试探包），确保双方收发通道都没瘫痪，这条路才算获批通车。
第 4 关：发 HTTP 请求 (递交订单单据)
路终于修通了。浏览器顺着管子，向远端的服务器递交一份极其严格的提货单HTTP 请求。
这份订单是一段纯文本，里面核心只写着一条指令：GET /en-US/ HTTP/1.1（即：我要拿你硬盘上 /en-US 里的文件，咱们用 1.1 版本的 HTTP 标准格式对话）。
第 5 关：服务器拆包回传 (切碎发货)
服务器查验订单后，找出了你要的 HTML 文本。但它绝对不会一次性将这 2MB 的大文件整个发回去。
如果一次性全发，只要发到 99% 时由于你进了电梯丢了 1 秒钟的信号，整个 2MB 就只能重头再发。频繁重传巨大的文件，会迅速耗尽服务器带宽，导致极其恐怖的网络堵塞。
为了对抗丢包，服务器必须把完整的文本文件，切碎成几百上千个碎片（数据包）。每个碎片贴上一个编号标签（如 3/1000），像漫天撒网一样扔向互联网公路。中途哪个包不幸丢了，你的手机就只通知服务器单独重传那几 KB 的碎片即可，极大的解决了网络拥堵问题。
常见的发货暗号 (状态码)：
在正式发送包裹之前，服务器会先快速回甩一个三位数的包裹单状态码，含义如下：
- 200：文件找到了，订单通过，开始朝你丢包裹。
- 404：对不起，你的路径给错了，这台服务器里查无此文件。
- 500 / 503：这台主服务器内部代码崩溃了，或者被挤爆断电了。
第 6 关：拼装
那几百个切碎的文本包裹碎片，陆续接收到你的设备里。
一旦包裹被全部收齐，浏览器的底层收发器会立刻根据标签编号，把它们原封不动地重新拼合成那份完整的带有尖括号的纯文本（HTML 等）。
至此，长途跋涉向别人要一份文件的网络加载任务彻底完结。
紧接着，机器便会立刻开始 5 道引擎渲染流水线（解析 DOM 树 ➔ CSSOM 树 ➔ 最终绘制），把这份纯文本，画成精美的可交互网页。
至于浏览器具体是如何把代码一步步渲染成画面的？下一章我们接着拆解。
