Web服务请求网页的简化流程

你输入网址，敲下回车。简化屏幕一闪，流程页面出来了。求网这中间发生了什么？简化大多数人不会去想，但如果你写过几天代码，流程或者单纯对“为什么有时候网页卡住”感到好奇，求网这件事就值得拆开看看。简化

先从浏览器本身说起。流程它拿到你输入的求网 https://example.com 之后，第一件事不是简化直接去找那个网站，而是流程先问系统：这个域名对应的 IP 地址是多少？这一步叫 DNS 解析。系统里可能已经有缓存，求网路由器里也可能有，简化运营商那边也可能有。流程如果都没有，就得一层层往上问，直到根域名服务器告诉你“去问 .com 的服务器”，然后 .com 再告诉你“去问 example.com 的权威服务器”。整个过程快的时候几毫秒，慢的时候能让你盯着空白页发呆好几秒。我见过有人把 DNS 服务器改成 8.8.8.8 之后，打开某些网站的速度肉眼可见地变快了，就是这个环节在起作用。

拿到 IP 之后，浏览器开始和服务器建立连接。如果是 HTTP，就是简单的三次握手：你发 SYN，服务器回 SYN+ACK，你再回 ACK。听起来很抽象，换成大白话就是：“在吗？”“在，你呢？”“我也在。” 连接建立好了。但现在是 HTTPS 的天下，中间还要多几步 TLS 握手。双方要协商用哪种加密算法，要验证证书是不是真的，要交换密钥。这一步比三次握手复杂得多，往返次数也更多。所以 HTTPS 网站第一次打开往往比 HTTP 慢一点，不是错觉。

连接建好之后，浏览器开始发请求。一个典型的请求长这样：

GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 ... Accept: text/html

这里面 GET 是方法，表示“我要拿东西”。/index.html 是路径，告诉服务器我要哪个文件。Host 头很重要，因为同一台服务器上可能跑着好几个网站，服务器靠这个字段来判断你到底想访问哪一个。没有它，服务器可能直接给你返回一个默认页面，或者干脆报错。

服务器收到请求，开始处理。它可能只是从硬盘上读一个静态的 HTML 文件，也可能要跑一段程序，查数据库，拼出动态内容。这中间的耗时差异巨大。静态文件几毫秒就返回了，动态页面如果数据库查询慢，或者程序写得有问题，等上几秒甚至几十秒都正常。我见过一个后台管理系统，每次打开首页都要等七八秒，后来发现是某个统计查询忘了加索引，全表扫描了几十万行数据。加完索引，瞬间降到两百毫秒。用户可不管背后是什么原因，他们只觉得“这网站真烂”。

服务器把响应发回来。响应里包含状态码，比如 200 表示成功，404 表示找不到，500 表示服务器内部错误。还有响应头，告诉浏览器这个内容是什么类型、有多长、能不能缓存。然后是响应体，也就是实际的 HTML 内容。浏览器拿到 HTML 之后，开始解析。遇到 <link> 标签就去下载 CSS，遇到 <script> 标签就去下载 JavaScript。这些资源可能来自同一个服务器，也可能来自 CDN。每多一个资源，就多一次请求，多一次连接建立（或者复用连接）。所以网页元素越多，加载越慢，这是物理规律，优化只能缓解，不能消除。

浏览器一边下载资源，一边构建 DOM 树和 CSSOM 树，然后合并成渲染树，接着计算布局，最后把像素画到屏幕上。这个过程叫关键渲染路径。如果 JavaScript 阻塞了 DOM 构建，页面就会白屏。所以有经验的开发者会把 <script> 放在 <body> 末尾，或者加上 defer、async 属性。这些都是血泪教训换来的最佳实践。

整个流程走完，你看到了页面。如果中途某个环节出了问题——DNS 解析失败、连接超时、服务器返回 500、某个关键 CSS 没加载出来——你看到的就是错误页、空白页或者排版错乱的页面。排查问题的时候，打开浏览器开发者工具的 Network 面板，每个请求的耗时、状态码、响应头都列得清清楚楚。那是最直观的线索。

所以下次网页加载慢的时候，别光骂运营商。可能是 DNS 慢，可能是 TLS 握手慢，可能是服务器处理慢，可能是某个资源太大，也可能是 JavaScript 执行太久。每一层都有嫌疑，每一层也都可能优化。