HTTP 权威指南 Notes

Joe的五金商店

第一部分 HTTP: Web 的基础

第一章 HTTP 概述

1.1 HTTP – 因特网的多媒体信使

HTTP (Hypertext Transfer Protocol, 超文本传输协议).

1.2 Web 客户端和服务器

HTTP 客户端和 HTTP 服务器共同构成了万维网的基本组件。

1.3 资源

Web resource 在 Web server 中。

1.3.1 媒体类型

MIME (Multipurpose Internet Mail Extension, 多用途因特网邮件扩展) 类型用来描述并标记多媒体内容.

Web 服务器会为所有 HTTP 对象数据附加一个 MIME 类型。

MIME 类型是一种文本标记，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠分隔，如:

• HTML 格式的文本文档由 text/html 类型来标记
  由此可见，MIME 类型不是特指一种类型.

1.3.2 URI

URI (Uniform Resource Identifier, 统一资源标识符). 唯一标识并定位信息资源.

URI 有两种形式:

• URL
• URN

1.3.3 URL

URL (Uniform Resource Locator), 描述一台特定服务器上某资源的特定位置.

URL 大都遵循一种标准格式，其包含三个部分:

1. 方案 (scheme), 即协议类型, 如: http://
2. 服务器的因特网地址，如: www.joes-hardware.com
3. 其余部分指定 Web 服务器上的某个资源，如: /specials/saw-blade.gif

1.3.4 URN

URN (Uniform Resource Name), 与目前的资源所在地无关，其作为特定内容的唯一名称使用。如: urn:ietf:rfc:2141

这种框架可以在对象从一处搬移到另一处时，保持稳定的访问名称。

1.4 事务

一个 HTTP 事务由一条请求命令和一个响应结果组成，这种通信是通过名为 HTTP 报文 (HTTP message) 的格式化数据块进行的。

1.4.1 方法

HTTP 支出几种不同的请求命令，这些命令被称为 HTTP 方法 (HTTP method). 每条 HTTP 请求报文都包含一个方法，这个方法会告诉服务器要执行什么动作。

5种常见的 HTTP 方法:

• GET, 从服务器向客户端发送命名资源
• PUT，将来自客户端的数据存储到一个命名的服务器资源中
• DELETE, 从服务器删除命名资源
• POST, 将客户端数据发送到一个服务器网关应用程序
• HEAD, 仅发送命名资源响应中的 HTTP 首部

1.4.2 状态码

每条 HTTP 响应报文返回时都会携带一个状态码，状态码是一个三位数字的代码。

几种常见的状态码:

• 200, OK, 文档正确返回
• 302，Redirect, 到其他地方获取资源
• 404, Not Found, 无法找到资源

1.4.3 Web 页面中可以包含多个对象

1.5 报文

从 Web 客户端发往 Web 服务器的 HTTP 报文称为请求报文 (request message), 从服务器发往客户端的报文称为响应报文 (response message).

其包含三个部分:

• 起始行
• 首部字段, 每个首部字段都包含一个名字和一个值，其用 : 分隔
• 主体, 可包含二进制数据

1.6 连接

1.6.1 TCP/IP

HTTP 协议位于 TCP 的上层，HTTP 使用 TCP 来传输其报文数据. TCP 位于 IP 上层。

1.6.2 连接、IP 地址及端口号

在 HTTP 客户端向服务器发送报文之前，需要用网际协议 (Internet Protocol, IP) 地址和端口号在客户端和服务器之间建立一条 TCP/IP 连接。

URL 中没有端口号，可以假设其有默认端口号。

1.6.3 一个使用 Telnet 的实例

Telnet 程序可以将键盘连接到某个目标 TCP 端口，并将此 TCP 端口的输出回送到显示屏上.

Telent 常用于远程终端会话，其几乎可以连接所有的 TCP 服务器。

使用 telnet 程序:

$ telnet www.baidu.com 80

其会输出三行内容表示已经建立好了连接，此时我们可以输入请求命令如:

GET/tools.html HTTP/1.1

nc 程序可以方便地操纵基于 UDP 和 TCP 的流量.

1.7 协议版本

目前仍使用的版本:

• HTTP/0.9
• HTTP/1.0
• HTTP/1.0+
• HTTP/1.1
• HTTP/2.0

1.8 Web 的结构组件

较为重要的应用程序:

• 代理, 位于客户端和服务器之间的 HTTP 中间实体
• 缓存, HTTP 仓库，使常用页面的副本可以保存在离客户端更近的地方
• 网关, 连接其他应用程序的特殊的 Web 服务器
• 隧道, 对 HTTP 通信报文进行盲转发的特殊代理
• Agent 代理, 发起自动 HTTP 请求的半智能 Web 客户端

1.8.1 代理

代理还可以对请求和响应进行过滤。

1.8.2 缓存

客户端从附近缓存下载文档会比从远程 Web 服务器下载快得多.

1.8.3 网关

gateway, 作为其他服务器的中间实体使用。通常用于将 HTTP 流量转换成其他的协议.

1.8.4 隧道

HTTP 隧道的一种常见用途是通过 HTTP 连接承载加密的安全套接字层 (SSL, Secure Socket Layer) 流量，使其可以穿过只允许 Web 流量通过的防火墙。

1.8.5 Agent 代理

是代表客户发起 HTTP 请求的客户端程序。

所有发布 Web 请求的应用程序都是 HTTP Agent 代理.

第二章 URL 与资源

2.1 浏览因特网资源

URL 为应用程序提供了一种访问资源的手段。

2.2 URL 的语法

URL 语法会随方案的不同而有所不同.

大部分 URL 都遵循通用的 URL 语法，而且不同 URL 方案的风格和语法都有不少重叠。

浏览器通常会用其他应用程序来处理特殊的资源.

由9部分构成的通用格式:

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

解释:

2.2.1 方案 – 使用什么协议

方案，告诉负责解析 URL 的应用程序应该使用什么协议。

方案名是大小写无关的，https:// 和 HTTPS:// 等价。

2.2.2 主机与端口

主机组件标识了因特网上能够访问资源的宿主机器。如用域名或 IP 地址来表示主机名.

http://www.jows-hardware.com:80/index.html
http://161.58.228.45:80/index.html

端口组件标识了服务器正在监听的网络端口。

2.2.3 用户名和密码

如果某应用程序使用的 URL 方案要求输入用户名和密码，但用户没有提供，它通常会插入一个默认的用户名和密码。

2.2.4 路径

URL 的路径组件说明了资源位于服务器的什么地方。

可以用字符 “/“ 将 HTTP URL 的路径组件划分成一些路径段 (path segment), 每个路径段都有自己的参数 (param) 组件。

2.2.5 参数

负责解析 URL 的应用程序需要这些协议参数来访问资源。

FTP 有两种传输模式:

• 二进制
• 文本形式

2.2.6 查询字符串

很多资源，比如数据库服务，都是可以通过提问题或进行查询来缩小所请求资源的类型范围。

按照常规，很多网关都希望查询字符串以一系列 “名=值” 对的形式出现，名值对之间用字符 “&” 分隔:

https://www.joes-hardware.com/inventory-check.cgi?item=12731&color=blue

2.2.7 片段

HTTP 服务器通常只处理整个对象，而不是对象的片段，客户端不能将片段传送给服务器，浏览器从服务器获得了整个资源后，会根据片段来显示你感兴趣的那部分资源。

2.3 URL 快捷方式

2.3.1 相对 URL

URL 有两种方式:

• 绝对 URL, 其包含访问资源所需的全部信息
• 相对 URL, 需借助基础 (base) URL 进行解析
  
  

基础 URL

转换处理的第一步就是找到基础 URL.

基础 URL 可以来自:

• 在资源中显示提供，如在 HTML 文档中包含一个定义了基础 URL 的 HTML 标记 <BASE>.
• 封装资源的基础 URL, 将它所属资源的 URL 作为基础
• 没有基础 URL

解析相对引用

通常称作分解 (decomposing) URL, 将1基础和相对 URL 划分成组件。

2.3.2 自动扩展 URL

用户不需要输入完整的 URL, 因为浏览器会自动扩展。

以下两种方式:

• 主机名扩展
• 历史扩展

2.4 各种令人头疼的字符

2.4.1 URL 字符集

通过转义序列, 就可以用 US-ASCII 字符集的有限子集对任意字符值或数据进行编码.

2.4.2 编码机制

为了避开安全自负即表示法带来的限制，人们设计了一种编码机制，用来在 URL 中表示各种不安全的字符。

这种编码机制就是通过一种”转义”表示法来表示不安全字符的，这种转义表示法包含:

• 一个百分号 (%)
• 百分号后跟着两个表示字符 ASCII 码的十六进制数

2.4.3 字符限制

即特殊字符，使用原意时需转义:

2.5 方案的世界

常见的方案及格式:

第三章 HTTP 报文

3.1 报文流

HTTP 报文是在 HTTP 应用程序之间发送的数据块。

报文在客户端、服务器和代理之间流动，术语 “流入”, “流出”, “上游”, “下游” 都是用来描述报文方向的。

3.1.1 报文

HTTP 使用术语 流入 (inbound) 和 流出 (outbound) 来描述事务处理 (transaction) 的方向。

“流入” 是流向服务器方向，”流出” 是流向用户 Agent 代理方向。

3.1.2 报文向下游流动

不管是请求报文还是响应报文，所有报文都会向下游 (downstream) 流动。所有报文的发送者都在接收者的上游 (upstream).

3.2 报文的组成部分

每条报文都包含一条来自客户端的请求，活着一条来自服务器的响应。

其包含三个部分:

Content-Type 行说明了主体是什么。

Content-Length 行说明了主体有多大。

3.2.1 报文的语法

请求报文格式:

<method> <request-URL> <version> # 这是请求行，字段用空格分隔
<headers>

<entity-body>

响应报文格式:

<version> <status> <reason-phrase> # 这是响应行，也由空格分隔字段
<headers>

<entity-body>

一组 HTTP 首部总应该以一个空行结束，甚至即使没有首部和实体的主体部分也应如此.

有些服务器会实现一些自己的请求方法，这些附加的方法是对 HTTP 规范的扩展，被称为扩展方法.

原因短语是响应起始行中的最后一个组件. 它为状态码提供了文本形式的解释.

版本号不会被当做小数处理，版本中的每个数字都会被当做一个单独的数字来处理，因此，在比较 HTTP 版本时，每个数字都必须要单独进行比较，以便确定哪个版本更高, 如: HTTP/2.22 比 HTTP/2.3 的版本高.

3.2.3 首部

每个 HTTP 首部都有一种简单的语法: 名字后面跟着冒号 : , 然后跟上可选的空格，再跟上字段值，最后是一个 CRLF.

首部延续行

将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符.

3.2.4 实体的主体部分

HTTP 报文的第三部分是可选的实体主体部分，实体的主体是 HTTP 报文的负荷，就是 HTTP 要传输的内容。

3.2.5 版本 0.9 的报文

3.3 方法

如果一台服务器要与 HTTP 1.1 兼容，那么只要为其资源实现 GET 方法和 HEAD 方法就可以了.

3.3.1 安全方法

HTTP 定义了一组被称为安全方法的方法，GET 方法和 HEAD 方法都被认为是安全的。

3.3.2 GET

GET 是最常用的方法，通常用于请求服务器发送某个资源.

3.3.3 HEAD

HEAD 方法和 GET 方法的行为很类似，但服务器在响应中只返回首部。不会反悔实体的主体部分.

3.3.4 PUT

向服务器写入文档。

3.3.5 POST

通常用于支持 HTML 的表单。

3.3.6 TRACE

客户端发起一个请求时这个请求可能要穿过防火墙、代理、网关或其他一些应用程序，每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子.

TRACE 方法只要用于诊断。

3.3.7 OPTIONS

该方法请求 Web 服务器告知其支持的各种功能。

3.3.8 DELETE

请求服务器删除请求 URL 所指定的资源.

客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求.

3.4 状态码

HTTP 状态码被分成五大类。

状态码为客户端提供了一种理解事务处理结果的便捷方式.

3.4.1 100 ~ 199 – 信息性状态码

3.4.2 200 ~ 299 – 成功状态码

3.4.3 300 ~ 399 – 重定向状态码

重定向状态码要么告诉客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。

3.4.4 400 ~ 499 – 客户端错误状态码

3.4.5 500 ~ 599 – 服务器错误状态码

服务器自身出错了.

3.5 首部

在请求和响应报文中都可以用首部来提供信息,有些首部是某种报文专用的，有些首部更通用一些。

五个主要类型:

• 通用首部
• 请求首部
• 响应首部
• 实体首部
• 扩展首部

3.5.1 通用首部

这些首部提供了与报文相关的最基本的信息。

3.5.2 请求首部

请求首部是在请求报文中有意义的首部，用于说明是谁或什么在发送请求、请求源自何处，或者客户端的喜好及能力.

Accept 首部

条件请求首部

为请求加上某些限制

安全请求首部

要求客户端在获取特定的资源之前，先对自身进行认证。

代理请求首部

3.5.3 响应首部

响应首部为客户端提供了一些额外信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令.

协商首部

就是资源有多种，可以考虑要哪个。

安全响应首部

HTTP 的质询/响应认证机制的响应侧.

3.5.3 实体首部

提供了有关实体及其内容的大量信息.

内容首部

与实体内容有关的信息.

实体缓存首部

提供了与被缓存实体有关的信息.

第四章 连接管理

HTTP 连接是 HTTP 报文传输的关键通道.

4.1 TCP 连接

世界上几乎所有的 HTTP 通信都是由 TCP/IP 承载的.

4.1.1 TCP 的可靠数据管道

HTTP 连接实际上就是 TCP 连接及其使用规则。

TCP 为 HTTP 提供了一条可靠的比特传输管道.

4.1.2 TCP 流是分段的、由 IP 分组传送

TCP 的数据是通过 IP 数据报的小数据块来发送的.

HTTPS 就是在 HTTP 和 TCP 之间插入了一个密码加密层.

每个 IP 数据报都包括:

• 一个 IP 分组首部
• 一个 TCP 首段
• 一个 TCP 数据块

4.1.3 保持 TCP 连接持续不断地运行

在任何时刻计算机都可以有几条 TCP 连接处于打开状态。TCP 是通过端口号来保持所有这些连接持续不断地运行.

端口号和雇员使用的电话分机号很类似.

IP 地址可以将你连接到正确的计算机，而端口号则可以将你连接到正确的应用程序上去.

TCP 连接是通过 4 个值来识别的:

• 源 IP 地址
• 源端口号
• 目的 IP 地址
• 目的端口号
  这 4 个值一起唯一定义了一条连接。

4.1.4 用 TCP 套接字编程

操作系统提供了一些操纵其 TCP 连接的工具：

通信过程:

4.2 对 TCP 性能的考虑

HTTP 事务的性能在很大程度上取决于底层 TCP 通道的性能。

4.2.1 HTTP 事务的时延

4.3 HTTP 连接的处理

4.3.1 常被误解的 Connection 首部

HTTP 允许在客户端和最终的源端服务器之间存在一串 HTTP 中间实体.

在某些情况下，两个相邻的 HTTP 应用程序会为它们共享的连接应用一组选项。

HTTP 的 Connection 首部字段中有一个由逗号分隔的连接标签列表，用于指定不会传播到其他连接中的选项.

4.3.2 串行事务处理时延

第二部分 HTTP 结构

第5章 Web 服务器

5.1 各种形状和尺寸的 Web 服务器

“Web 服务器” 可以用来表示 Web 服务器的软件，也可以用来表示提供 Web 页面的特定设备或计算机.

5.1.1 Web 服务器的实现

5.1.2 通用软件 Web 服务器

5.1.3 Web 服务器设备

Web server appliance 是预先打包好的软硬件解决方案.

5.1.3 嵌入式 Web 服务器

5.2 最小的 Perl Web 服务器

5.3 实际的 Web 服务器会做些什么

1. 建立连接
2. 接收请求
3. 处理请求
4. 访问资源
5. 构建响应
6. 发送响应
7. 记录事务处理过程，会将与已完成事务有关的内容记录在一个日志文件中

5.4 第一步 – 接收客户端连接

5.4.1 处理新连接

Web 服务器可以随意拒绝或立即关闭任意一条连接。

5.4.2 客户端主机名识别

可以用 “反向 DNS” 对大部分 Web 服务器进行配置，以便将客户端 IP 地址转换成客户端主机名。

主机名查找可能会花费很长时间，这样会降低 Web 事务处理的速度.

可以用配置指令 HostnameLookups 启用 Apache 的主机查找功能.

5.4.3 通过 ident 确定客户端用户

有些 Web 服务器还支持 IETF 的 idnet 协议，服务器可以通过 ident 协议找到发起 HTTP 连接的用户名.

如果客户端支持 ident 协议，就在 TCP 端口 113 上监听 ident 请求.

可以通过 Apache 的 IdentityCheck on 指令告知 Apache Web 服务器使用 ident 查找功能.

5.5 第二步 – 接收请求报文

连接上有数据到达时，Web 服务器会从网络连接中读取数据，并将请求报文中的内容解析出来。

5.5.1 报文的内部表示法

有些 Web 服务器还会用便于进行报文操作的内部数据结构来存储请求报文.

5.5.2 连接的输入/输出处理结构

不同的 Web 服务器结构会以不同的方式为请求服务:

• 单线程 Web 服务器
• 多进程及多线程 Web 服务器
• 复用 I/O 的服务器
• 复用的多线程 Web 服务器

5.6 第三步 – 处理请求

5.7 第四步 – 对资源的映射及访问

在 Web 服务器将内容传送给客户端之前，要将请求报文中的 URI 映射为 Web 服务器上适当的内容或内容生成器.

5.7.1 docroot

文档的根目录即 document root (docroot).

最简单的资源映射形式就是用请求 URI 作为名字来访问 Web 服务器文件系统中的文件.

虚拟托管的 docroot

虚拟托管的 Web 服务器会在同一台 Web 服务器上提供多个 Web 站点，每个站点在服务器上都有自己独有的文档根目录。

用户的主目录 docroot

Docroot 的另一种常见应用是在 Web 服务器上为人们提供私有的 Web 站点. 通常会把那些以斜杠和波浪号 (/~) 开始，后面跟着用户名的 URI 映射为此用户的私有文档根目录.

5.7.2 目录列表

Web 服务器可以接收对目录 URL 的请求，其路径可以解析为一个目录。

大多数 Web 服务器都会去查找目录中一个名为 index.html 或 index.htm 的文件来代表此目录。如果用户请求的是一个目录的 URL, 而且这个目录中有一个名为 index.html (或 index.htm) 的文件，服务器就会返回那个文件的内容.

在 Apache Web 服务器上，可以用配置命令 DirectoryIndex 来配置要作为默认目录文件使用的文件名集合。指令 DirectoryIndex 会按照优先顺序列出所有可以作为目录索引文件使用的文件名.

5.7.3 动态内容资源的映射

5.8 第五步 – 构建响应

5.9 第六步 – 发送响应

5.10 第七部 – 记录日志

第六章 代理

Web 代理 (proxy) 服务器是网络的中间实体，代理位于客户端和服务器之间，在各端点之间来回传送 HTTP 报文.

6.1 Web 的中间实体

HTTP 的代理服务既是 Web 服务器又是 Web 客户端。

6.1.1 私有和共享代理

代理服务器可以使某个客户端专用的，也可以是很多客户端共享的。

单个客户端专用的代理称为私有代理.

众多客户端共享的代理被称为公共代理. 其成本效率高，更容易管理.

6.1.2 代理与网关的对比

代理连接的是两个或多个使用相同协议的应用程序。

网关连接的是两个或多个使用不同协议的端点。其扮演的是”协议转换器”的角色.

6.2 为什么使用代理

代理服务器可以看到并接触到所有流过的 HTTP 流量，所以代理可以监视流量并对其进行修改。

可以用反向代理来提高访问慢速 Web 服务器上公共内容时的性能，这些反向代理通常被称为服务器加速器 (server accelerator).

6.3 代理会去往何处

6.3.1 代理服务器的部署

部署代理的几种方式:

• 出口代理，将代理固定在本地网络的出口点，以便控制本地网络与大型因特网之间的流量.
• 访问 (入口) 代理，将代理放在 ISP 访问点上，用以处理来自客户的聚合请求.
• 反向代理, 部署在网络边缘，在 Web 服务器之前，作为替代物 (即反向代理) 使用, 在那里它们可以处理所有传送给 Web 服务器的请求, 并只在必要时向 Web 服务器请求资源. 反向代理通常会直接冒用 Web 服务器的名字和 IP 地址
• 网络交换代理, 将具有足够处理能力的代理放在网络之间的因特网对等交换点上，通过缓存来减轻因特网节点的拥塞，并对流量进行监视

6.3.2 代理的层次结构 (proxy hierarchy)

报文会从一个代理传给另一个代理.

靠近服务器的代理为父代理.

靠近客户端的代理为子代理

代理层次结构的内容路由

代理层次结构可以是动态的, 即并不是单一的路线。

6.3.3 代理是如何获取流量的

有四种常见方式可以使客户流量流向代理:

• 修改客户端, 手动将客户端配置为使用代理服务器
• 修改网络,
• 修改 DNS 的命名空间
• 修改 Web 服务器

6.4 客户端的代理设置

所有现代的 Web 浏览器都允许用户对代理使用进行配置。

几种方法:

• 手工配置
• 预先配置浏览器
• 代理的自动配置
• WPAD 的代理发现

6.5 与代理请求有关的一些棘手问题

6.5.1 代理 URI 与服务器 URI 不同

除了这一点之外，Web 服务器报文和 Web 代理报文的语法是一样的。

客户端向 Web 服务器发送请求时，请求行中只包含部分 URI (URI 中不包含方案、主机或端口).

客户端向代理发送请求时，请求行中则包含完整的 URI.

6.5.2 与虚拟主机一样的问题

6.5.3 拦截代理会收到部分 URI

6.6 追踪报文

6.6.2 Via 首部

Via 首部字段列出了与报文途径的每个中间节点有关的信息.

报文每经过一个节点，都必须将这个中间节点添加到 Via 列表的末尾.

Via 的语法

由逗号 , 分隔。

每个 waypoint 最多包含四个组件:

• 可选的协议名
• 必选的协议版本
• 必选的节点名
• 可选的描述性注释

Via 的请求和响应路径

请求和响应通常都是通过同一条 TCP 连接传输的，响应报文会沿着与请求报文相同的路径回传。

Via 与网关

有些代理会为使用非 HTTP 协议的服务提供网关的功能，Via 首部记录了这些协议转换.

Server 和 Via 首部

Server 响应首部字段对原始服务器使用的软件进行了描述:

Server: Apache/1.3.14 (Unix) PHP/4.0.4

Via 的隐私和安全问题

当代理服务器作为网络防火墙的一部分使用时，是不应该转发防火墙后面那些主机的名字和端口号的.

如果不允许进行 Via 节点名转发，作为安全防线的一部分使用的代理就应该用适当的假名来取代那台主机的名字.

6.6.2 TRACE 方法

代理服务器可以在转发报文时对其进行修改，可以添加、修改或删除首部，也可以将主体部分转换称不同的格式.

通过 HTTP/1.1 的 TRACE 方法，用户可以跟踪经代理链传输的请求报文，观察报文经过了哪些代理, 以及每个代理是如何对请求报文进行修改的。

可以使用 Max-Forwards 首部来限制 TRACE 和 OPTIONS 请求所经过的代替跳数.

Max-Forwards 请求首部字段包含了一个整数，用来说明这条请求报文还可以被转发的次数.

转发一次, Max-Forwards 后的整数减一。

6.7 代理认证

这种机制可以阻止对内容的请求，直到用户向代理提供了有效的访问权限证书为止.

6.8 代理的互操作性

6.8.1 处理代理不支持的首部和方法

代理必须对不认识的首部字段进行转发，而且必须维持同名首部字段的相对顺序.

6.8.2 OPTIONS: 发现对可选特性的支持

6.8.3 Allow 首部

Allow 实体首部字段列出了请求 URI 标识的资源所支持的方法列表，如果请求 URI 为 * ，列出的就是整个服务器所支持的方法列表.

第七章 缓存

Web 缓存是可以自动保存常见文档副本的 HTTP 设备.

7.1 冗余的数据传输

7.2 带宽瓶颈

7.3 瞬间拥塞

缓存在破坏瞬间拥塞 (Flash Crowds) 时非常重要.

7.4 距离时延

7.5 命中和未命中的

用已有的副本为某些到达缓存的请求提供服务，被称为缓存命中 (cache hit).

到达缓存的请求可能会由于没有副本可用，而被转发给原始服务器，被称为缓存未命中 (cache miss)

7.5.1 再验证

缓存需对它们保存的副本进行检测，判断是否为服务器上的最新副本。这被称为HTTP 再验证 (revalidaion).

大部分缓存只有在客户端发起请求，并且副本旧得足以需要检测的时候，才会对副本进行 revalidation.

使用 If-Modified-Since 首，告诉服务器，只有在缓存了对象的副本之后，又对其进行了修改下，才发送此对象.

7.5.2 命中率

由缓存提供服务的请求所占的比例被称为缓存命中率 (cache hit rate).

7.5.3 字节命中率

字节命中率表示的是缓存提供的字节在传输的所有字节中所占的比例。

7.5.4 区分命中和未命中的情况

客户端可以通过 Date 首部来判断响应是否来自缓存，将 Date 首部的值与当前时间进行比较，如果响应中的日期值比较早，客户端通常就可以认为这是一条缓存的响应.

7.6 缓存的拓扑结构

缓存可以是单个用户专用的，也可以是数千名用户共享的。

专用缓存被称为私有缓存 (private cache).

共享的缓存被称为公有缓存 (public cache).

7.6.1 私有缓存

Web 浏览器中有内建的私有缓存。

7.6.2 公有代理缓存

公有缓存是特殊的共享代理服务器, 被称为缓存代理服务器 (caching proxy server).

7.6.3 代理缓存的层次结构

7.6.4 网状缓存/内容路由以及对等缓存

有些网络结构会构建复杂的网状缓存 (cache mesh).

一种代理缓存会决定选择何种路由对内容进行访问、管理和传送，因此可将其称为内容路由 (content router).

缓存之间这些更为复杂的关系允许不同的组织互为对等 (peer) 实体，将它们的缓存连接起来以实现共赢。

提供可选的对等支持的缓存被称为兄弟缓存 (sibling cache).

7.7 缓存的处理步骤

对一条 HTTP GET 报文的基本缓存处理过程包括7个步骤:

1. 接受
2. 解析
3. 查询
4. 新鲜度检测
5. 创建响应
6. 发送
7. 日志

7.8 保持副本的新鲜

7.8.1 文档过期

通过特殊的 HTTP Cache-Control 首部和 Expires 首部，HTTP 让原始服务器向每个文档附加了一个 “过期日期”. 这些首部说明了在多长时间内可以将这些内容视为新鲜的。

在缓存文档过期之前，缓存可以以任意频率使用这些副本，而无需与服务器联系.

7.8.2 过期日期和使用期

Expires 首部使用绝对日期.

Cache-Control: max-age 首部使用相对时间 (以秒为单位).

7.8.3 服务器再验证

已缓存文档过期意味着到了要和服务器进行核对的时间，这种情况被称为 “服务器再验证”.

7.8.4 用条件方法进行再验证

HTTP 允许缓存向原始服务器发送一个 “条件 GET” , 请求服务器只有在文档与缓存中现有的副本不同时，才回送对象主体.

HTTP 定义了 5 个条件请求首部,对缓存再验证来说最有用的 2 个首部是:

• If-Modified-Since
• If-None-Match

所有的条件首部都以前缀 “If-“ 开头.j w

7.8.7 强弱验证器

实体标签和最近修改日期都是缓存验证器 (cache validator).

弱验证器允许对一些内容进行修改.

7.8.8 什么时候使用实体标签和最近修改日期

7.9 控制缓存的能力

第8章 集成点: 网关、隧道及中继

8.1 网关

网关 (gateway) 可以作为某种翻译器使用。

有些网关会自动将 HTTP 流量转换为其他协议，这样 HTTP 客户端无需了解其他协议，就可以与其他应用程序进行交互了。

客户端和服务器端网关

Web 网关在一侧使用 HTTP 协议，在另一侧使用另一种协议.

可以用一个斜杠来分隔客户端和服务器端协议，并以此对网关进行描述:

<客户端协议>/<服务器端协议>

8.2 协议网关

将 HTTP 流量导向网关时所使用的的方式与流量导向代理的方式相同。

8.2.1 HTTP/*: 服务器端 Web 网关

请求流入原始服务器时，服务器端 Web 网关会将客户端 HTTP 请求转换为其他协议.

8.2.2 HTTP/HTTPS: 服务器端安全网关

一个组织可以通过网关对所有输入 Web 的请求加密，以提供额外的隐私和安全性保护.

8.2.3 HTTPS/HTTP 客户端安全加速器网关

它们接受安全的 HTTPS 流量,对安全流量进行解密,并向 Web 服务器发送普通的 HTTP 请求.

这些网关中通常包含专用的解密硬件.

8.3 资源网关

最常见的网关, 应用程序服务器, 会将目标服务器与网关结合在一个服务器中实现.

CGI (Common Gateway Interface), 通用网关接口, 其为一个标准接口集, Web 服务器可以用它来装载程序以响应对特定 URL 的 HTTP 请求,并收集程序的输出数据,将其放在 HTTP 响应中回送.

服务器和网关是相互独立的应用程序.

8.3.1 CGI

CGI 应用程序是独立于服务器的,几乎可以用任意语言来实现.

CGI 很简单, 几乎所有的 HTTP 服务器都支持它.

CGI 应用程序对用户来说是不可见的.

8.3.2 服务器扩展 API

CGI 协议为外部翻译器与现有的 HTTP 服务提供了一种简洁的接口方式.

扩展 API 允许程序员将自己的代码嫁接到服务器上,或者用自己的代码将服务器的一个组件完整地替换出来.

8.4 应用程序接口和 Web 服务器

HTTP 可以作为一种连接应用程序的基础软件来使用.

应用程序之间要配合工作，所要交互的信息比 HTTP 首部所能表达的信息要复杂得多。

8.5 隧道

HTTP 的另一种用法 – Web 隧道 (Web tunnel), 这种方式可以通过 HTTP 应用程序访问使用非 HTTP 协议的应用程序。

Web 隧道允许用户通过 HTTP 链接发送非 HTTP 流量.

使用 Web 隧道最常见的原因就是要在 HTTP 连接中嵌入非 HTTP 流量，这样，这类流量就可以穿过只允许 Web 流量通过的防火墙了.

8.5.1 用 CONNECT 建立 HTTP 隧道