20.4 缓存的重定向方法

1. WCCP 重定向

Cisco 系统公司开发的 WCCP 可以使路由器将 Web 流量重定向到代理缓存中去。WCCP 负责路由器和缓存服务器之间的通信，这样路由器就可以对缓存进行验证(确保它们已启动且正在运行)，在缓存之间进行负载均衡，并将特定类型的流量发送给特定的缓存了。WCCP 版本 2(WCCP2)是个开放的协议。这里我们会探讨 WCCP2。

1. WCCP 重定向工作流程

1. 启动包含了一些支持 WCCP 的路由器和缓存的网络，这些路由器和缓存之间可以相互通信。
2. 一组路由器及其目标缓存构成一个 WCCP 服务组。服务组的配置说明了要将何种流量发往何处、流量是如何发送的以及如何在服务组的缓存之间进行负载均衡。
3. 如果服务组配置为重定向 HTTP 流量，服务组中的路由器就会将 HTTP 请求发送给服务组中的缓存。
4. HTTP 请求抵达服务组中的路由器时，路由器会(根据对请求 IP 地址的散列，或者“掩码/值”的配对策略)选择服务组中的某个缓存为请求提供服务。
5. 路由器向缓存发送请求分组，可以用缓存的 IP 地址来封装分组，也可以通过 IP MAC 转发来实现。
6. 如果缓存无法为请求提供服务，就将分组返回给路由器进行普通的转发。
7. 服务组中的成员会互相交换心跳报文，不断验证对方的可用性。

2. WCCP2 报文

• WCCP2 报文有 4 种：
  
• WCCP2_HERE_I_AM 的报文格式为:

WCCP Message HeaderSecurity Info ComponentService Info ComponentWeb-cache Identity Info Component Web-cache View Info Component Capability Info Component ( 可选 ) Command Extension Component ( 可选 )

• WCCP2_I_SEE_YOU 的报文格式为:

WCCP Message Header Security Info ComponentService Info ComponentRouter Identity Info Component Router View Info Component Capability Info Component ( 可选 ) Command Extension Component ( 可选 )

• WCCP2_REDIRECT_ASSIGN 的报文格式为:

WCCP Message HeaderSecurity Info ComponentService Info ComponentAssignment Info Component, or Alternate Assignment Component

• WCCP2_REMOVAL_QUERY 的报文格式为:

WCCP Message Header Security Info Component Service Info Component Router Query Info Component

3. 报文组件

• 每条 WCCP2 报文都由一个首部和一些组件构成。WCCP 首部信息包含报文类型 (Here I Am、I See You、Assignment 或 Removal Query)、WCCP 版本和报文长度 (不包括首部的长度)。
• 每个组件都以一个描述组件类型和长度的 4 字节首部开始。组件长度不包括组件首部的长度。
• WCCP2 报文组件：
  
  

4. 服务组

• 服务组(service group)由一组支持 WCCP 的路由器和缓存组成，它们之间可以交换 WCCP 报文。路由器会向服务组中的缓存发送 Web 流量。服务组的配置确定了如何将流量分配到服务组的缓存中去。路由器和缓存会在 Here I Am 和 I See You 报文中交换服务组的配置信息。

5. GRE 分组封装

• 支持 WCCP 的路由器会用服务器的 IP 地址将 HTTP 分组封装起来，将其重定向到特定的服务器上去。
• 分组封装中还包含了 IP 首部的 proto 字段，用来说明通用路由器封装(GRE)。proto 字段的存在告诉接收代理，它有一个封装的分组。分组被封装起来，客户端的 IP 地址就不会丢失了。下图显示了 GRE 分组的封装过程。
  

6. WCCP 的负载均衡

• 除了路由功能之外，WCCP 路由器还可以在几个接收服务器之间进行负载均衡。 WCCP 路由器及其接收服务器会交换心跳报文(heartbeat message)，以便相互通知自己处于启动运行状态。
• 如果某特定接收服务器停止发送心跳报文，WCCP 路由器就会将请求流量直接发送到因特网上，而不会将其重定向给那个节点。节点重新提供服务时，WCCP 路由器会再次开始接收心跳报文，并继续向节点发送请求流量。

2. 因特网缓存协议

• ICP(因特网缓存协议)允许缓存在其兄弟缓存中查找命中内容。如果某个缓存中没有 HTTP 报文所请求的内容，它可以查明内容是否在附近的兄弟缓存中，如果在，就从那里获取内容，以避免查询原始服务器而带来的更多开销。
• 可以把 ICP 当作一个缓存集群协议。HTTP 请求报文的最终目的地可以通过一系列的 ICP 查询确定，从这个角度来说，它就是一个重定向协议。
• ICP 是一个对象发现协议。它会同时去询问附近的多个缓存，看看它们的缓存中是否有特定的 URL。附近的缓存如果有那个 URL 的话，就会返回一个简短的报文 HIT，如果没有，就返回 MISS。然后，缓存就可以打开一条到拥有此对象的邻居缓存的 HTTP 连接了。
• ICP 是很简单直接的。ICP 报文是一个以网络字节序表示的 32 位封装结构，这样更便于进行解析。为了提高效率，可以由 UDP 数据报承载其报文。UDP 是一种不可靠的因特网协议，说明在传输的过程中数据可能会被破坏，因此使用 ICP 的程序要具有超时功能，以检测丢失的数据报。
• 简要描述一下 ICP 报文中的部分信息：
  
  • Opcode(操作码)：Opcode 是个 8 位的二进制值，用以描述 ICP 报文的含义。基本的 opcode 包括 ICP_OP_QUERY 请求报文和 ICP_OP_HIT 和 ICP_OP_MISS 响应报文。
  • 版本：8 位的版本号描述了 ICP 协议的版本编号。Squid 使用的 ICP 版本记录在 RFC 2186 第 2 版中。
  • 报文长度：以字节为单位的 ICP 报文总长。因为只有 16 位，所以 ICP 报文的长度不能超过 16383 字节。URL 通常都小于 16 KB，如果超过这个长度，很多 Web 应用程序就无法处理它了。
  • 请求编号：支持 ICP 的缓存会用请求编号来记录多个同时发起的请求和响应。ICP 应答报文数必须与触发应答的 ICP 请求报文数相同。
  • 选项：32 位的 ICP 选项字段是个包含了若干标记的位矢量，这些标记可用来修改 ICP 的行为。ICPv2 定义了两个标记，这两个标记都会修改 ICP_OP_QUERY 请求。ICP_FLAG_HIT_OBJ 标记用来启动或禁止在 ICP 响应中返回文档数据。ICP_ FLAG_SRC_RTT 标记请求由兄弟缓存测量的、到原始服务器的环回时间的估计值。
  • 可选数据：保留了 32 位的可选数据用于可选特性。ICPv2 使用了可选数据的低 16 位来装载从兄弟缓存到原始服务器的可选环回时间的估计值。
  • 发送端主机地址：承载了报文发送端 32 位 IP 地址的著名字段。实际中并未使用。
  • 净荷：净荷内容的变化取决于报文的类型。对 ICP_OP_QUERY 来说，净荷是一个 4 字节的原始请求端主机地址，后面跟着一个由 NUL 结尾的 URL。对 ICP_OP_ HIT_OBJ 来说，净荷是一个由 NUL 结尾的 URL，后面跟着一个 16 位的对象长度，接着是对象数据。

3. 缓存阵列路由协议

• 代理服务器通过拦截来自单个用户的请求，提供所请求 Web 对象的缓存副本，极大地降低了发往因特网的流量。但随着用户数的增加，大量流量可能会使代理服务器自身超载。
• 对此问题的一种解决方案就是使用多个代理服务器将负载分散到一组服务器上。CARP(缓存阵列路由协议)是微软公司和网景公司提出的一个标准，通过这个协议来管理一组代理服务器，使这组代理服务器对用户来说就像一个逻辑缓存一样。
• CARP 是 ICP 的一个替代品。CARP 和 ICP 都允许管理者通过使用多个代理服务器来提高性能。下面讨论 CARP 与 ICP 的区别，用 CARP 代替 ICP 的优缺点以及 CARP 协议实现上的一些技术细节。
• ICP 中出现缓存未命中时，代理服务器会用 ICP 报文格式来查询附近的缓存，以确定 Web 对象是否存在。附近的缓存会以 HIT 或 MISS 进行响应，请求代理服务器会用这些响应来选择能够获取到对象的最适当的位置。如果 ICP 代理服务器是以层次结构排列的，未命中的查询会被提交给其父代理。
  
• 注意，通过 ICP 协议连接起来的每个代理服务器都是将内容进行了冗余镜像的独立缓存服务器，这就说明在不同的代理服务器之间复制 Web 对象条目是可行的。
• 相反，用 CARP 连接起来的一组服务器会被当作一个大型的服务器，其中每个组件服务器都只包含全部缓存文档中的一部分。通过对某个 Web 对象的 URL 应用散列函数，CARP 就可以将此对象映射到特定的代理服务器上去。每个 Web 对象都有一个唯一的家，所以我们可以通过单次查找确定对象的位置，而无须去查询集合中配置的每个代理服务器。
  
• CARP 对代理服务器做出的确定性解析说明它无须向所有邻居发送查询，这也就意味着这种方法所需发送的缓存间报文会比较少。随着越来越多的代理服务器添加到配置系统中来，缓存系统集群的规模会变得相当大。但 CARP 的一个缺点就是，如果某个代理服务器不可用了，就要重新修改散列表以反映这种变化，而且必须重新配置现存代理服务器上的内容。如果代理服务器经常崩溃的话，这么做的开销可能会很高。相反，ICP 代理服务器中存在的冗余内容就表示它不需要重新配置。
• CARP 重定向方法要完成下列任务（以下 4 项任务可以由浏览器、插件执行，也可以在一个中间服务器上计算。）：
  
  • 保存一个参与 CARP 的代理服务器列表。周期性地查询这些代理服务器，看看它们是否仍然活跃。
  • 为每个参与的代理服务器计算一个散列函数。散列函数的返回值要考虑此代理所能处理的负载量。
  • 定义一个独立的散列函数，这个函数会根据所请求 Web 对象的 URL 返回一个数字。
  • 将 URL 散列函数的结果代入代理服务器的散列函数，得到一个数字阵列。这些数字中的最大值决定了要为这个 URL 使用的代理服务器。由于算出来的值是确定的，所以对同一个 Web 对象的后继请求会被转发给同一台代理服务器。
• 为每个代理服务器集群创建一个表，表中列出了集群中的所有服务器。表中的每个条目都应该包含全局参数的相关的信息，比如，负载因子、生存时间(TTL)、倒计数值和应该以何频率查询成员之类的全局参数。负载因子说明机器可以处理多少负载，这取决于那台机器的 CPU 速度和硬盘容量。可以通过 RPC 接口对此表进行远 程维护。只要表中的字段被 RPC 修改了，就可以使其对下游的客户端和代理可见，或将其发布给它们。这项发布工作是在 HTTP 中进行的，这样，所有的客户端或代理服务器就都可以在不引入另一种代理间协议的基础上消化表格信息了。客户端和代理服务器只用了一个知名 URL 来获取这张表。
• 所使用的散列函数必须能够确保 Web 对象在参与的代理服务器间是统计分布的。应该用代理服务器的负载因子来确定分配给那台代理的 Web 对象的统计概率。
• 总之，CARP 协议允许将一组代理服务器看成单个的集群缓存，而不是(像 ICP 中那样的)一组相互合作但又相互独立的缓存服务器。确定的请求解析路径会在一跳内找到某个特定的 Web 对象的家。这样会降低 ICP 在一组代理服务器中查找 Web 对象时常会产生的代理间流量。CARP 还可以避免在不同的代理服务器上存储 Web 对象的多个副本的问题，这样做的优点是缓存系统集群的 Web 对象存储容量较大，缺点是任意一个代理的故障都要改写现存代理的部分缓存内容。

4. 超文本缓存协议

• 之前我们讨论了 ICP，这个协议允许代理缓存向兄弟缓存查询文件是否存在。但设计 ICP 时考虑的是 HTTP/0.9 协议，因此，向兄弟缓存查询资源是否存在时，只允许缓存发送 URL。HTTP 版本 1.0 和 1.1 引入了很多新的请求首部，这些首部可以和 URL 一起用来确定文件是否匹配。因此，只在请求中发送 URL 可能无法得到精确的响应。
• HTCP(超文本缓存协议)允许兄弟缓存之间通过 URL 和所有的请求及响应首部来相互查询文档是否存在，以降低错误命中的可能。而且 HTCP 允许兄弟缓存监视或请求在对方的缓存中添加或删除所选中的文档，并修改对方已缓存文档的缓存策略。
• HTCP 报文的结构如下图所示。首部中包含了报文的长度和报文版本。数据部分开始是数据长度，包含了 opcode、响应代码、一些标记及 ID，最后是实际的数据。可选的认证部分跟在 Data 小节的后面。
  
• 报文字段的详细内容如下所述：
  
  • 首部：Header 部分包含 32 位的报文长度，8 位的主要协议版本和 8 位的次要协议版本。报文长度包含所有首部、数据和认证部分的长度。
  • 数据：Data 部分包含了 HTCP 报文，结构如上图所示。数据组件如下表所示。
    
    下表列出了 HTCP Opcode 代码及其相应的数据类型：
    

1. HTCP 认证

• HTCP 报文的认证部分是可选的。下表列出了它的认证组件。
  

2. 设置缓存策略

• SET 报文允许缓存请求对已缓存文档的缓存策略进行修改。下表给出了可以在 SET 报文中使用的首部：
  
• HTCP 允许通过查询报文将请求和响应首部发送给兄弟缓存，这样可以降低缓存查询中的错误命中率。通过进一步允许在兄弟缓存间交换策略信息，HTCP 还可以提高兄弟缓存之间的合作能力。