《图解HTTP》--第5章-与HTTP协作的Web服务器

读《图解HTTP》：代理、网关、隧道与缓存到底是什么？

本文是阅读《图解HTTP》第 5 章后的学习整理，结合个人理解做了少量补充。文中的流程图和表格用于概括本章概念，不使用原书截图，也不替代原书内容。

这篇文章解决什么问题

我们平时访问一个网站时，直觉上会以为浏览器直接连到了目标服务器。实际情况往往更复杂：请求可能先经过代理服务器，也可能经过网关、隧道、缓存服务器，最后才到达真正保存资源的服务器。

这一章主要讨论的就是这些与 HTTP 协作的 Web 服务器组件：

• 一台服务器如何承载多个网站：虚拟主机
• HTTP 请求在中途可能遇到哪些角色：代理、网关、隧道
• 为什么缓存能减少访问源服务器的次数
• 缓存服务器和客户端缓存分别是什么

一台服务器为什么能放多个网站：虚拟主机

HTTP/1.1 允许一台 HTTP 服务器搭建多个 Web 站点。物理上可能只有一台服务器，但使用虚拟主机功能后，表面上可以像多台服务器一样，分别承载不同域名的网站。

问题在于：多个域名经过 DNS 解析后，可能指向同一个 IP 地址。当请求到达服务器时，服务器需要知道客户端到底想访问哪个域名下的网站。

这个判断依赖 HTTP 请求中的Host首部。

GET /index.html HTTP/1.1 Host: blog.example.com

可以把虚拟主机的访问过程理解成这样：

域名 A

DNS 解析到同一台服务器

域名 B

HTTP 请求携带 Host 首部

服务器根据 Host 区分目标网站

所以，虚拟主机的核心不是“一台机器真的变成了多台机器”，而是服务器根据请求里的Host首部，把同一个 IP 上的不同域名区分开。

HTTP 请求路上的中间角色

HTTP 通信时，除了客户端和服务器，还可能存在一些用于转发通信数据的应用程序。书中重点介绍了三类：代理、网关、隧道。

它们都可以把请求转发给通信线路上的下一站服务器，也可以接收下一站服务器返回的响应，再转发给客户端。

代理：替客户端转发请求

代理是一种有转发功能的应用程序，扮演客户端和服务器之间的“中间人”角色。

它的基本行为是：

请求

不改变请求 URI，转发请求

响应

响应

客户端

代理服务器

源服务器

持有资源实体的服务器被称为源服务器。代理从客户端接收请求后，会把请求转发给前方持有资源的目标服务器；源服务器返回的响应也会先经过代理，再传给客户端。

在 HTTP 通信中，可以级联多台代理服务器。每次通过代理转发请求或响应时，需要追加Via首部，用来标记经过的主机信息。

客户端

代理 proxy1

代理 proxy2

源服务器

使用代理服务器的理由包括：

• 利用缓存减少网络带宽流量
• 在组织内部针对特定 URI 进行访问控制
• 获取访问日志

书中还按两个维度给代理分类：

网关：让 HTTP 连接到非 HTTP 服务

网关和代理的工作机制很相似，也会转发其他服务器的通信数据。不同的是，网关能让通信线路上的服务器提供非 HTTP 协议服务。

对客户端来说，网关有时就像自己拥有资源的源服务器一样处理请求，客户端未必能察觉通信目标其实是网关。

转换为非 HTTP 协议通信

处理结果

HTTP 响应

客户端 HTTP 请求

网关

非 HTTP 服务器/后端系统

书中举到的例子包括：

• 网关连接数据库，使用 SQL 语句查询数据
• Web 购物网站通过网关和信用卡结算系统联动

网关还能提高通信的安全性，例如在客户端与网关之间的通信线路上加密，以确保连接安全。

隧道：建立一条安全通信线路

隧道是在相隔较远的客户端和服务器之间进行中转，并保持双方通信连接的应用程序。

它的目的，是按要求建立一条与其他服务器的通信线路，并使用 SSL 等加密手段进行通信，确保客户端能与服务器安全通信。

通过隧道建立安全通信线路

客户端

隧道

服务器

隧道本身不会解析 HTTP 请求，而是把请求保持原样中转给之后的服务器。通信双方断开连接时，隧道也会结束。

代理、网关、隧道的区别

这三个概念容易混在一起，可以用下面这张表快速区分：

一句话记忆：

代理偏“转发”，网关偏“转换”，隧道偏“透明传输”。

缓存为什么能让 Web 更快

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。

利用缓存，可以减少对源服务器的访问，从而节省通信流量和通信时间。缓存服务器属于代理服务器的一种，也就是缓存代理。

缓存服务器的基本工作方式可以概括为：

没有缓存

已有缓存

有效

需要确认或已失效

客户端请求资源

缓存服务器内是否已有资源副本？

向源服务器请求资源

转发响应时复制资源并保存

返回给客户端

缓存是否仍然有效？

向源服务器确认有效性

必要时重新获取新资源

缓存的优势在于：如果某个资源已经被缓存，客户端就可以从缓存服务器获取资源，源服务器也不必反复处理相同请求。

但缓存并不是只要存在就一定能直接使用。书中强调，即使缓存服务器中有缓存，也可能因为客户端要求、缓存有效期、源服务器资源更新等因素，需要向源服务器确认资源的有效性。若判断缓存失效，缓存服务器会再次从源服务器获取新资源。

客户端也有缓存

缓存不仅可以存在于缓存服务器内，也可以存在于客户端浏览器中。

浏览器缓存如果有效，就不必再向服务器请求相同资源，可以直接从本地磁盘读取。和缓存服务器一样，当浏览器判断缓存过期后，也会向源服务器确认资源有效性；如果缓存已经失效，就会再次请求新资源。

补充理解：缓存相关首部要到后面一起看

第 5 章主要讲“缓存是什么、缓存服务器和客户端缓存怎么工作”。具体的缓存控制细节，会在 HTTP 首部相关内容里展开。

实际排查缓存问题时，常见会关注这些字段：

• Cache-Control
• Expires
• ETag
• Last-Modified
• Age

其中no-cache和no-store很容易混淆：no-cache不是“完全不缓存”，而是“使用缓存前需要确认有效性”；真正不保存内容的是no-store。

实践：用 curl 观察 Host、代理和缓存首部

下面是结合开发场景的补充实践，不是原书中的命令示例。

1. 通过 Host 首部模拟访问虚拟主机

curl -H "Host: www.example.com" http://192.168.1.100/ curl -H "Host: blog.example.com" http://192.168.1.100/

同一个 IP 地址可以因为Host不同而路由到不同站点。

2. 通过 HTTP 代理发送请求

curl -x http://proxy.example.com:8080 -v http://www.example.com/

如果链路中存在代理，可以重点观察是否出现Via等字段。

3. 查看缓存相关响应首部

curl -I https://www.example.com/ \ | grep -i "cache-control\|expires\|etag\|last-modified\|age"

常见需要关注的字段包括：

• Cache-Control
• Expires
• ETag
• Last-Modified
• Age