浏览器与web服务器交互的过程

你在地址栏敲下 example.com 然后回车，屏幕闪了一下，器w器交页面出来了。服务这中间大概几百毫秒，过程但发生的浏览事情比大多数人想得要碎。浏览器不是器w器交“打开”网页，它是服务跟服务器来回吵了一小会儿架，才把东西拼出来给你看。过程

第一步其实是浏览找路。浏览器先问系统：example.com 在哪？器w器交系统翻自己的 hosts 文件，没找到，服务就去问 DNS 服务器。过程这个过程像你打电话问总机要分机号，浏览总机可能还要问别的器w器交总机。拿到 IP 地址之后，服务浏览器才真正开始跟服务器搭话。

搭话之前得先握手。TCP 三次握手，老生常谈，但细节有意思：浏览器发个 SYN，服务器回 SYN-ACK，浏览器再 ACK。这就像两个人对暗号，确认双方都能听见。如果是 HTTPS，还得再来一轮 TLS 握手，交换密钥、验证证书。我见过一个证书链配错的站点，浏览器直接甩脸子，连 HTML 都不给你看。那会儿你看到的不是网页，是浏览器自己的报错页。

握手完了，浏览器终于能发请求了。一个典型的 HTTP 请求长这样：

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml ...

注意那个 User-Agent。服务器经常根据这个字段决定给你发什么。你用手机访问某些老站点，会被重定向到 m.example.com，就是因为服务器看到了你 UA 里的 “Mobile”。这招现在被用滥了，有时候你伪装成 Googlebot，还能骗过一些粗心的服务器。

服务器收到请求，开始干活。它可能直接读磁盘上的 HTML 文件，也可能跑一段 PHP 或 Python 代码去查数据库。我见过一个朋友写的服务器，每次请求都重新读一遍配置文件，结果并发一上来就卡死。服务器处理完，拼出一个响应：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234

<!DOCTYPE html>...

浏览器拿到响应，先看状态码。200 就往下走，404 就显示“找不到”，500 就显示“服务器内部错误”。然后看 Content-Type，决定是当 HTML 解析，还是当图片显示，还是当文件下载。这里有个坑：如果服务器把 CSS 文件的 MIME 类型写成 text/plain，浏览器会拒绝应用样式，页面光秃秃的，你查半天才发现是服务器配置问题。

HTML 开始解析，浏览器边读边构建 DOM 树。遇到 <link rel="stylesheet"> 就去下载 CSS，遇到 <script> 就暂停解析去下载并执行 JS。这就是为什么把 <script> 放在 <head> 里会阻塞页面渲染。我以前接手过一个项目，首页加载要 8 秒，就是因为 head 里塞了六个同步脚本。后来改成 defer，直接降到 1 秒多。

CSS 和 JS 都到位了，浏览器才真正开始渲染：计算样式、布局、绘制、合成。你看到页面从白屏到出现内容，中间可能经历了多次重绘。有时候你看到文字先出来，图片后出来，就是因为图片的下载和渲染被排在了后面。

整个过程中，浏览器和服务器可能来回好几次。比如 HTML 里引用了三个图片、两个 CSS、一个 JS，浏览器就得再发六次请求。HTTP/1.1 默认开启 Keep-Alive，复用同一个 TCP 连接，省去反复握手的开销。HTTP/2 更进一步，一个连接上可以并行发多个请求，还能压缩头部。但很多老服务器还在用 HTTP/1.1，你打开 DevTools 的 Network 面板，能看到请求排队，那就是浏览器在等前面的请求完成。

最后，页面加载完了，但交互才刚刚开始。你点一个按钮，可能触发 AJAX 请求，浏览器又跟服务器聊上了。整个过程循环往复，直到你关掉标签页。所以下次页面卡住，别只怪网速，可能是服务器在某个环节磨蹭，或者浏览器被一个同步脚本堵住了。打开开发者工具，看看时间线，比瞎猜有用得多。