浏览器里敲下网址，工作回车。原理页面出来了。工作这中间发生了什么？原理大多数人不会去想，但这套机制每天支撑着几十亿次点击，工作值得拆开看看。原理

先纠正一个常见误解：Web服务器不是工作一台机器，而是原理一个跑在机器上的软件程序。Nginx、工作Apache、原理IIS，工作这些名字指的原理是软件。它们蹲在某个IP地址的工作某个端口上（通常是80或443），像前台接待员一样，原理等着有人来问事。工作

一次请求的完整路径

当你在浏览器输入 example.com/index.html，浏览器先做DNS解析，把域名翻译成IP地址，比如 93.184.216.34。然后它建立一条TCP连接——三次握手，这个大家都知道。如果是HTTPS，还要多几轮TLS协商，交换证书、生成会话密钥。这些做完，浏览器才真正开始发HTTP请求。

请求本身是一段纯文本，长这样：

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

服务器收到这串字节，开始解析。它先看请求方法——GET、POST、PUT、DELETE，各有各的语义。再看路径 /index.html，这决定了它要去文件系统的哪个位置找东西。

服务器内部在忙什么

拿Nginx举例。它采用事件驱动的异步架构，一个worker进程能同时处理几千条连接。请求进来后，Nginx根据配置文件里的 location 块决定怎么处理：是直接返回磁盘上的静态文件，还是转发给后端的应用服务器（比如跑Python的Gunicorn或跑Java的Tomcat）。

如果是静态文件，Nginx会打开文件描述符，读取内容，拼上响应头，发回去。响应头里带着状态码——200表示一切正常，404表示没找到，301是永久重定向。这些数字不是随便定的，每个都有明确含义。

如果是动态请求，比如用户登录，Nginx把请求转给后端。后端代码查数据库、渲染模板、生成HTML，再把结果交回Nginx，由Nginx发回浏览器。这中间可能还隔着Redis缓存、消息队列，一层套一层。

一个容易被忽略的细节

HTTP是无状态的。服务器默认不记得你上一次来过。那购物车怎么实现的？靠Cookie和Session。服务器在响应头里塞一个 Set-Cookie，浏览器存下来，下次请求自动带上。服务器拿到Cookie，去Session存储里找对应的数据，这才“认出”你。

我见过不少人以为服务器会主动推送数据。其实HTTP是请求-响应模型，服务器不会无缘无故找你。WebSocket和SSE是后来打的补丁，本质上还是在HTTP握手之后升级协议，绕开了这个限制。

性能数字背后的现实

一台配置普通的Nginx服务器，处理静态文件能做到每秒几万次请求。听起来很多？但一个现代网页平均要发70到100个请求——图片、CSS、JS、字体，每个都要走一遍上面的流程。所以有了CDN，把静态资源分散到离用户更近的节点；有了HTTP/2，在一条连接上多路复用；有了缓存头，让浏览器别反复问同一个问题。

这些优化手段，说到底都是在跟延迟较劲。光在光纤里跑，从北京到纽约一个来回至少130毫秒。服务器处理再快，也架不住物理距离。所以工程师想尽办法让请求少跑几趟、让数据提前放在手边。

下次页面秒开的时候，可以想想背后这台“接待员”做了多少事。它不神秘，只是一套设计得足够简洁、又足够灵活的规则，撑起了整个Web。