RFC3040：Internet Web Replication and Caching Taxonomy，January 2001
本备忘录的状态
本备忘录为 Internet 社区提供信息。它没有指定任何类型的 Internet 标准。本备忘录的分发不受限制。
版权声明
版权所有 (C) 互联网协会 (2001)。版权所有。
梗概
本备忘录指定了今天部署的 Web 复制和缓存基础设施的标准术语和分类法。它介绍了当今在该应用领域中使用的标准概念和协议。目前已部署的采用这些技术的解决方案旨在建立标准分类法。缓存代理的已知问题包含在标题为“已知 HTTP 代理/缓存问题”的文档中，不属于本文档的一部分。本文档介绍了开放协议并指向每个协议的已发布材料。
1、 介绍
自 1990 年推出以来，万维网已从简单的客户端服务器模型演变为复杂的分布式体系结构。这种演变主要是由于与指数增长相关的扩展问题。已经出现了不同的范例和解决方案来满足特定的要求。为满足这种增长需求而采用的两个核心基础架构组件是复制和缓存。在许多情况下，需要 Web 缓存和复制服务能够共存。
本备忘录指定了当今 Internet 中部署的 Web 复制和缓存基础设施的标准术语和分类法。本文档的主要目标是建立对该应用领域的共同理解和参考点。
还预计本文档将用于创建标准架构框架，以在包括副本和缓存的网络中提供高效、可靠和可预测的服务。
本备忘录检查的某些协议仅由公司技术白皮书或正在进行的文档指定。包含此类参考资料是为了证明此类协议的存在、它们在当今 Internet 中的实验部署，或帮助读者理解该技术领域。
当今的 Web 复制和缓存中使用了许多协议，包括开放的和专有的。大多数开放协议包括 DNS [8]、Cache Digests [21][10]、CARP [14]、HTTP [1]、ICP [2]、PAC [12]、SOCKS [7]、WPAD [13] , 和 WCCP [18] [19]。这些协议及其在缓存和复制环境中的使用将在下面讨论。
2、 术语
以下术语提供了 Web 复制和缓存社区中使用的常用术语的定义。在可能的情况下，基本术语取自 HTTP/1.1 规范 [1]，并包含在此处以供参考。一阶和二阶衍生是根据这些基本项构造的，以帮助定义该区域内存在的关系。
常用且与 RFC 2616 和本文档中的定义相反的术语将突出显示。
2.1、 基本条款
这些术语中的大部分均来自 RFC 2616 [1]，并在此处包含以供参考。
client/客户端（取自 [1]）
为发送请求而建立连接的程序。
server/服务器（取自 [1]）
接受连接以便通过发送回响应来服务请求的应用程序。任何给定的程序都可以既是客户端又是服务器；我们对这些术语的使用仅指程序为特定连接执行的角色，而不是程序的一般功能。同样，任何服务器都可以充当源服务器、代理、网关或隧道，根据每个请求的性质切换行为。
proxy/代理（取自 [1]）
一种中间程序，它既充当服务器又充当客户端，以便代表其他客户端发出请求。请求在内部提供服务，或者通过将它们（可能经过翻译）传递到其他服务器。代理必须实现本规范的客户端和服务器要求。“透明代理”是不修改超出代理身份验证和识别所需的请求或响应的代理。“非透明代理”是修改请求或响应以向用户代理提供一些附加服务的代理，例如组注释服务、媒体类型转换、协议缩减或匿名过滤。除非明确声明透明或非透明行为，否则 HTTP 代理要求适用于两种类型的代理。
注意：术语“透明代理”指的是 [1] 中描述的语义透明代理，而不是缓存社区中通常理解的。我们建议始终为术语“透明代理”加上前缀以避免混淆（例如，“网络透明代理”）。但是，请参阅下面的“拦截代理”的定义。
上述需要同时实现 HTTP/1.1 的服务器和客户端要求的条件仅适用于非网络透明代理。
cache/缓存（取自 [1]）
程序的响应消息的本地存储以及控制其消息存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户端或服务器都可能包含缓存，但充当隧道的服务器不能使用缓存。
注意：单独使用的术语“缓存”通常表示“缓存代理”。
注意：缓存还有其他动机，例如减少服务器负载（作为减少响应时间的进一步手段）。
cacheable/可缓存（取自 [1]）
如果允许缓存存储响应消息的副本以用于回答后续请求，则响应是可缓存的。确定 HTTP 响应可缓存性的规则在第 13 节中定义。即使资源是可缓存的，对于缓存是否可以将缓存副本用于特定请求，也可能存在其他限制。
gateway/网关（取自 [1]）
充当某些其他服务器的中介的服务器。与代理不同，网关接收请求就好像它是所请求资源的源服务器一样；发出请求的客户端可能不知道它正在与网关通信。
tunnel/隧道（取自 [1]）
在两个连接之间充当盲中继的中间程序。一旦激活，隧道就不会被视为 HTTP 通信的一方，尽管隧道可能是由 HTTP 请求发起的。当中继连接的两端都关闭时，隧道将不复存在。
replication/复制
“在不同的计算机（通常是服务器）上创建和维护数据库或文件系统的副本。” - 免费在线计算词典 (Free Online Dictionary of Computing，FOLDOC)
inbound/outbound/入站/出站（取自 [1]）
入站和出站是指消息的请求和响应路径：“入站”表示“向源服务器行进”，“出站”表示“向用户代理行进”。
network element/网元
在源和目标之间引入多条路径的网络设备，对 HTTP 透明。
2.2、 一阶衍生项
下列术语是以上述基本术语为基础构建的。
origin server/源服务器（取自 [1]）
给定资源驻留或将被创建的服务器。
user agent/用户代理（取自 [1]）
发起请求的客户端。这些通常是浏览器、编辑器、蜘蛛（网络遍历机器人）或其他最终用户工具。
caching proxy/缓存代理
带有缓存的代理，充当客户端的服务器，以及服务器的客户端。
缓存代理通常称为“代理缓存”或简称为“缓存”。在提到缓存代理时，术语“代理”也经常被误用。
surrogate/代理
网关与源服务器位于同一位置，或位于网络中的不同点，授权代表一个或多个源服务器进行操作，并且通常与一个或多个源服务器密切合作。响应通常从内部缓存传送。
代理可以从源服务器或另一个源服务器的委托派生缓存条目。在某些情况下，代理可能会传送此类请求。
如果源服务器和代理之间存在密切合作，则可以修改某些协议要求，包括 [1] 中的缓存控制指令。此类修改尚未完全指定。
通常称为“反向代理”和“（原始）服务器加速器”的设备都更恰当地定义为代理。
reverse proxy/反向代理
参见“surrogate”。
server accelerator/服务器加速器
参见“surrogate”。
2.3、 二阶衍生
以下术语进一步建立在一阶衍生上：
master origin server/主源服务器
资源的最终版本所在的原始服务器。
replica origin server/副本源服务器
一个原始服务器持有一个资源的副本，但它可以作为客户端请求的权威参考。
content consumer/内容消费者
通过使用用户代理发起入站请求的用户或系统。
browser/浏览器
充当内容消费者的内容呈现设备的用户代理的特殊实例。
2.4、 拓扑项
添加了以下定义来描述缓存设备拓扑：
user agent cache/用户代理缓存
用户代理程序中的缓存。
local caching proxy/本地缓存代理
用户代理连接到的缓存代理。
intermediate caching proxy/中间缓存代理
从内容消费者的角度来看，所有参与缓存网格的缓存都不是用户代理的本地缓存代理。
cache server/缓存服务器
由本地和中间缓存代理发出的请求的服务器，但不充当代理。
cache array/缓存阵列
一组缓存代理，在逻辑上充当一个服务，并在整个阵列中划分资源名称空间。也称为“扩散阵列”或“缓存集群”。
caching mesh/缓存网格
一组松散耦合的协作代理服务器和（可选）缓存服务器或集群，它们独立运行，但使用缓存间通信协议在它们之间共享可缓存的内容。
2.5、 代理的自动使用
网络管理员可能希望强制或促进客户端对代理的使用，从而在网络本身或用户代理中的自动系统内启用此类配置，以便内容消费者无需知道任何此类配置问题。
下面给出了描述此类配置的术语。
automatic user-agent proxy configuration/自动用户代理代理配置
发现一个或多个代理的可用性以及用户代理的自动配置以使用它们的技术。代理的使用对内容消费者是透明的，但对用户代理不透明。在这个意义上也使用术语“自动代理配置”。
traffic interception/流量拦截
使用网络元素检查网络流量以确定是否应该重定向的过程。
traffic redirection/流量重定向
将客户端请求从执行流量拦截的网络元素重定向到代理。用于部署（缓存）代理而无需手动重新配置单个用户代理，或强制使用代理，否则此类使用不会发生。
拦截代理（又名“透明代理”、“透明缓存”） 缓存社区中使用术语“透明代理”来描述用户代理中零配置使用的代理。这种使用对用户代理来说有些透明。由于与 [1] 的差异（参见上文“代理”的定义），以及反对使用“透明”一词，我们引入术语“拦截代理”来描述从执行流量的网络元素接收重定向流量的代理拦截。
拦截代理通过流量重定向过程接收入站流量。 （此类代理由网络管理员部署，以促进或要求使用代理提供的适当服务）。与部署拦截代理相关的问题在文档“已知的 HTTP 代理/缓存问题”[23] 中有所描述。拦截代理的使用需要对用户代理进行零配置，就像直接与源服务器通信一样。
3、 分布式系统关系
本节确定分布式复制和缓存环境中存在的关系。定义了这些关系后，后面的部分将描述每个关系中使用的通信协议。
3.1、 复制关系
以下部分描述了客户端和副本之间以及副本本身之间的关系。
3.1.1、 客户端到副本
客户端可以与一个或多个副本源服务器以及主源服务器进行通信。 （在没有副本服务器的情况下，客户端像正常情况一样直接与源服务器交互。）
用于使客户端能够使用其中一个副本的协议可以在第 4 节中找到。
3.1.2、 副本间
这是主源服务器和副本源服务器之间的关系，以在第 3.1.1 节所示的关系中复制客户端访问的数据集。
这种关系中使用的协议可以在第 5 节中找到。
3.2、 代理关系
（缓存）代理和缓存服务器相互通信以及与用户代理通信的方式有很多种。
3.2.1、 客户端到非拦截代理
对于一些或所有请求，客户端可以与零个或多个代理进行通信。在通信结果导致没有使用代理的情况下，关系是客户端和（副本）源服务器之间的关系（参见第 3.1.1 节）。
此外，用户代理可以与额外的服务器进行交互 - 代表代理运行以实现自动用户代理代理配置的目的。
在这些关系中使用的方案和协议可以在第 6 节中找到。
3.2.2、 客户端代理到源服务器
对于针对一个或多个源服务器的请求，客户端可以与零个或多个代理通信。 在不使用代理的情况下，客户端直接与源服务器通信。 在使用代理的情况下，客户端就像与源服务器一样进行通信。 代理完成来自其内部缓存的请求，或充当通往源服务器的网关或隧道。
3.2.3、 代理间
代理间关系以网格（松散耦合）和集群（紧耦合）的形式存在。
3.2.3.1、（缓存）代理网格
在（缓存）代理的松散耦合网格中，通信可以在同级之间以及与一个或多个父级之间发生在同一级别。
（包含客户端仅用于说明目的）
入站请求可以基于确定该父代是否更适合解析请求而路由到多个中间（缓存）代理之一。
例如，在上图中，Cache Server C 和 Intermediate Caching Proxy B 是 Local Caching Proxy A 的 peer，只有当 A 请求的资源已经存在于 B 或 C 上时才可以使用。 Intermediate Caching Proxies D & E是 A 的父级，A 可以选择使用哪个来解决特定请求。
A & B 之间的关系仅在缓存环境中有意义，而 A & D 和 A & E 之间的关系也适用于 D 或 E 是非缓存代理的情况。
在这些关系中使用的协议可以在第 7.1 节中找到。
3.2.3.2、（缓存）代理阵列
在用户代理可能与代理有关系的情况下，它可能与在紧密耦合的网格中排列的代理阵列有关系。
这种关系中使用的协议可以在第 7.2 节中找到。
3.2.4、 网元到缓存代理
执行流量拦截的网络元素可以选择将来自客户端的请求重定向到阵列内的特定代理。 （它也可以选择不重定向流量，这种情况下是客户端和（副本）源服务器之间的关系，请参见第 3.1.1 节。）
拦截代理可以直接在流量流中——在这种情况下拦截网元和拦截代理构成同一硬件系统的一部分——或者可以是路径外的，需要拦截网元重定向流量到另一个网段。在后一种情况下，通信协议使拦截网络元件能够在拦截代理变得（不）可用时停止和开始重定向流量。这些协议的详细信息可以在第 8 节中找到。
4、 副本选择
本节介绍客户端和副本源 Web 服务器之间的协作和通信中使用的方案和协议。理想的情况是发现一个最佳的副本源服务器供客户端通信。最优性是基于策略的决策，通常基于邻近性，但也可能基于其他标准，例如负载。
4.1、 导航超链接
最著名的参考资料：
这份备忘录。
描述：
最简单的客户端复制通信机制。这利用嵌入在指向各个副本源服务器的网页中的超链接 URI。内容消费者手动选择他们希望使用的副本源服务器的链接。
安全：
依赖于与适当的 URI 方案相关联的协议安全性。
部署：
可能是最常部署的客户端到副本通信机制。与人类无处不在的互操作性。
提交者：
文档编辑器。
4.2、 副本 HTTP 重定向
最著名的参考资料：
这份备忘录。
描述：
将客户端与副本源服务器连接的一种简单且常用的机制是使用 HTTP 重定向。通过使用 HTTP [1] 协议响应代码，例如 302“Found”或 307“Temporary Redirect”，客户端被重定向到最佳副本源服务器。客户端与副本源服务器之一建立 HTTP 通信。最初联系的副本源服务器然后可以选择接受服务或再次重定向客户端。有关 HTTP 响应代码的信息，请参阅 HTTP/1.1 [1] 中的第 10.3 节。
安全：
完全依赖于 HTTP 安全性。
部署：
在一些大型网站上观察到。在 Internet 中的使用程度未知。
提交者：
文档编辑器。
4.3、 DNS 重定向
最著名的参考文献：
* RFC 1794：DNS 对负载平衡就近性的支持 [8]
* 本备忘录
描述：
域名服务 (Domain Name Service，DNS) 提供了更复杂的客户端到副本通信机制。这是由 DNS 服务器根据服务质量策略对解析的 IP 地址进行排序来完成的。当客户端解析源服务器的名称时，增强型 DNS 服务器将副本源服务器的可用 IP 地址从最佳副本开始，以最不理想的副本结束。
安全：
完全依赖 DNS 安全性和其他可用于确定排序顺序的协议。
部署：
在许多大型网站和大型 ISP 网络托管服务中观察到。互联网的使用程度未知，但据信正在增加。
提交者：
文档编辑器。
5、 副本间通信
本节介绍主源服务器和副本源服务器之间的协作和通信。用于在源服务器之间复制数据集。
5.1、 批量驱动复制
最著名的参考资料：
这份备忘录。
描述：
要更新的副本源服务器发起与主源服务器的通信。通信是根据排队的事务按时间间隔建立的，这些事务被安排为延迟处理。调度机制的策略各不相同，但一般都是在指定的时间重新发生。一旦建立通信，数据集就被复制到发起副本源服务器。
安全：
依赖于用于传输数据集的协议。 FTP [4] 和 RDIST 是最常见的协议。
部署：
在 Internet 上同步镜像站点非常常见。
提交者：
文档编辑器。
5.2、 需求驱动复制
最著名的参考资料：
这份备忘录。
描述：
由于客户端的需求，副本源服务器按需获取内容。当客户端请求不在副本源服务器/代理的数据集中的资源时，会尝试通过从主源服务器获取资源并将其返回给请求客户端来解决请求。
安全：
依赖于用于传输资源的协议。 FTP [4]、Gopher [5]、HTTP [1] 和 ICP [2] 是最常见的协议。
部署：
在几个大型网站上观察到。在 Internet 中的使用程度未知。
提交者：
文档编辑器。
5.3、 同步复制
最著名的参考资料：
这份备忘录。
描述：
复制源服务器使用同步策略和专门的副本协议进行协作，以保持副本数据集的一致性。同步策略范围从紧密连贯（几分钟）到松散连贯（几个小时或更长时间）。更新发生在基于所采用的一致性模型的同步时间限制的副本之间，并且通常仅采用增量的形式。
安全：
所有已知的协议都使用强加密密钥交换方法，这些方法基于 Kerberos 共享秘密模型或公钥/私钥 RSA 模型。
部署：
在少数地点观察到，主要是在大学校园。
提交者：
文档编辑器。
笔记：
编辑们知道至少有两个开源协议——AFS 和 CODA——以及来自 Novell 的专有 NRS 协议。
6、 用户代理到代理配置
本节介绍用户代理和代理之间的配置、协作和通信。
6.1、 手动代理配置
最著名的参考资料：
这份备忘录。
描述：
每个用户必须通过提供与代理协议和本地策略有关的信息来配置她的用户代理。
安全：
做错事的可能性很高；每个用户单独设置首选项。
部署：
广泛部署，在当前所有浏览器中使用。大多数浏览器还支持其他选项。
提交者：
文档编辑器。
6.2、 代理自动配置（Proxy Auto Configuration，PAC）
最著名的参考资料：
《导航器代理自动配置文件格式》[12]
描述：
为每个访问的 URL 执行从 Web 服务器检索的 JavaScript 脚本，以确定用于访问资源的适当代理（如果有）。用户代理必须配置为在启动时请求此脚本。没有引导机制，需要手动配置。
尽管手动配置，代理配置的过程通过将其集中在脚本中的一个位置来简化。
安全：
每个组织的通用策略是可能的，但仍需要初始手动配置。 PAC 比“手动代理配置”更好，因为 PAC 管理员可以在没有进一步用户干预的情况下更新代理配置。
PAC 文件的互操作性不高，因为不同浏览器对同一脚本的解释略有不同，可能会导致不良影响。
部署：
在 Netscape Navigator 和 Microsoft Internet Explorer 中实现。
提交者：
文档编辑器。
6.3、 缓存阵列路由协议 (Cache Array Routing Protocol，CARP) v1.0
最著名的参考文献：
* “缓存阵列路由协议”[14]（正在进行中）
* “缓存阵列路由协议 (CARP) v1.0 规范”[15]
* “缓存阵列路由协议和 Microsoft 代理服务器 2.0” [16]
描述：
用户代理可以直接使用 CARP 作为基于散列函数的代理选择机制。它们需要配置集群信息的位置。
安全：
正在进行的规范工作中未涵盖安全注意事项。
部署：
在 Microsoft 代理服务器 Squid 中实现。通过 PAC 脚本在用户代理中实现。
提交者：
文档编辑器。
6.4、 Web代理自动发现协议（WPAD）
最著名的参考资料：
“Web 代理自动发现协议（Web Proxy Auto-Discovery Protocol）”[13]（正在进行中）
描述：
WPAD 使用一组预先存在的 Internet 资源发现机制来执行 Web 代理自动发现。
WPAD 的唯一目标是定位 PAC URL [12]。 WPAD 没有指定将使用哪些代理。 WPAD 提供 PAC URL，然后 PAC 脚本按照上面定义的方式运行，为每个资源请求选择代理。
WPAD 协议规定了以下内容：
* 如何将每种机制用于 Web 代理自动发现的特定目的
* 执行机制的顺序
* WPAD 兼容的用户代理必须尝试的最小机制集
WPAD 使用的资源发现机制如下：
* 动态主机配置协议 DHCP
* 服务位置协议 SLP
* 使用 DNS A 记录的“众所周知的别名”
* DNS SRV记录
* DNS TXT 记录中的“服务：URL”
安全：
依赖于 DNS 和 HTTP 安全。
部署：
在一些用户代理和缓存代理服务器中实现。两个以上独立的实现。
提交者：
乔什·科恩
7、 代理间通信
7.1、 松散耦合的代理间通信
本节介绍缓存代理之间的协作和通信。
7.1.1、 互联网缓存协议（ICP）
最著名的参考资料：
RFC 2186：Internet 缓存协议 (Internet Cache Protocol，ICP)，版本 2 [2]
描述：
代理使用 ICP 来查询有关 Web 资源的其他（缓存）代理，以查看请求的资源是否存在于其他系统上。
ICP 使用 UDP。由于 UDP 是未经修正的网络传输协议，因此可以通过 ICP 损失来计算网络拥塞和可用性的估计。这种基本的损失测量与往返时间一起提供了一种缓存负载平衡方法。
安全：
参见 RFC 2187 [3]
ICP 不传达有关与资源关联的 HTTP 标头的信息。 HTTP 标头可能包括访问控制和缓存指令。由于代理请求资源的可用性，并随后使用 HTTP 检索它们，因此可能会发生错误的缓存命中（对象存在于缓存中，但不能被同级访问就是一个例子）。
ICP 遭受 UDP 的所有安全问题。
部署：
广泛部署。大多数当前的缓存代理实现都以某种形式支持 ICP。
提交者：
文档编辑器。
也可以看看：
“互联网缓存协议扩展”[17]（正在进行中）
7.1.2、 超文本缓存协议
最著名的参考资料：
RFC 2756 超文本缓存协议 (Hyper Text Caching Protocol，HTCP/0.0) [9]
描述：
HTCP 是一种用于发现 HTTP 缓存代理和缓存数据、管理 HTTP 缓存代理集以及监控缓存活动的协议。
HTCP 请求包括 HTTP 标头材料，而 ICPv2 不包括，使 HTCP 回复能够更准确地描述由于对同一资源的后续 HTTP 请求而可能发生的行为。
安全：
可选地使用 HMAC-MD5 [11] 共享秘密身份验证。如果不使用身份验证，协议会受到攻击。
部署：
HTCP 是在 Squid 和“Web 网关拦截器”中实现的。
提交者：
文档编辑器。
7.1.3、 缓存摘要
最著名的参考文献：
* “缓存摘要规范 - 版本 5”[21]
* “摘要缓存：可扩展的广域 Web 缓存共享协议”[10]（见注释）
描述：
缓存摘要是对与以前的缓存间通信机制（例如 Internet 缓存协议 (ICP) [2] 和超文本缓存协议 [9]）相关的延迟和拥塞问题的响应。与这些协议不同，缓存摘要支持缓存代理和缓存服务器之间的对等互连，而无需为每个入站请求进行请求-响应交换。相反，缓存中的内容摘要（摘要）由与其对等的其他系统获取。使用缓存摘要可以以相对较高的准确度确定给定资源是否由特定系统缓存。
缓存摘要既是一种交换协议，也是一种数据格式。
安全：
如果摘要的内容是敏感的，则应予以保护。任何通常用于保护 HTTP 连接的方法都可以应用于缓存摘要。
“特洛伊木马”攻击目前在网格中是可能的：系统 A 可以为系统 B 构建一个假对等摘要，并在请求时将其提供给 B 的对等。通过这种方式，A 可以将流量导向/来自 B。这个问题的影响通过将缓存摘要从一个系统传输到另一个系统的“拉”模型最小化。
缓存摘要提供有关 URL 级别的对等缓存内容的知识。因此，它们不规定特定级别的策略管理，可用于在任何级别（用户、组织等）实施各种策略。
部署：
Squid 支持缓存摘要。
缓存网格：NLAR Mesh； TF-CACHE Mesh（欧洲学术网络
提交者：
[21]是Alex Rousskov，[10]是Pei Cao。
注意：Summary Cache [10] 的技术是威斯康星大学麦迪逊分校正在申请专利的技术。
7.1.4、 缓存预填充
最著名的参考资料：
“预填充缓存 - 卫星概览”[20]（正在进行中）
描述：
缓存预填充是一种推送缓存实现。它特别适用于 IP 多播网络，因为它允许将预选资源同时插入目标多播组内的缓存中。缓存预填充的不同实现已经存在，尤其是在卫星环境中。然而，这种推送缓存仍然没有标准，供应商提出了基于专用设备或使用预填充模块扩展的公共域缓存的解决方案。
安全：
依赖于所采用的缓存间协议。
部署：
在两个商业内容分发服务提供商中观察到。
提交者：
伊万·洛夫里克
7.2、 紧耦合的缓存间通信
7.2.1 缓存阵列路由协议 (CARP) v1.0
另见第 6.3 节
最著名的参考文献：
* “缓存阵列路由协议”[14]（正在进行中）
* “缓存阵列路由协议 (Cache Array Routing Protocol，CARP) v1.0 规范”[15]
* “缓存阵列路由协议和 Microsoft 代理服务器 2.0” [16]
描述：
CARP 是一种散列函数，用于在一组代理之间划分 URL 空间。 CARP 中包含代理阵列成员表的定义以及下载此信息的方法。
实现 CARP v1.0 的用户代理可以分配 URL 请求并将其智能路由到代理阵列的任何成员。由于通过这些代理对请求进行排序，消除了缓存内容的重复，并且可以提高全局缓存命中率。
安全：
正在进行的规范工作中未涵盖安全注意事项。
部署：
在缓存代理服务器中实现。两个以上独立的实现。
提交者：
文档编辑器。
8、 网元通信
本节介绍代理和网元之间的协作和通信。这种网络元件的示例包括路由器和交换机。通常用于部署拦截代理和/或扩散阵列。
8.1、 网页缓存控制协议（WCCP）
最著名的参考文献：
“Web 缓存控制协议（Web Cache Control Protocol）”[18][19]（正在进行中）
注意：用于此协议的名称各不相同，有时称为“Web 缓存协调协议（Web Cache Coordination Protocol）”，但通常仅称为“WCCP”以避免混淆
描述：
WCCP V1 在用作重定向网络元素的路由器和路径外拦截代理之间运行。该协议允许一个或多个代理向单个路由器注册以接收重定向的流量。它还允许代理之一，即指定代理，向路由器指示重定向的流量如何在整个阵列中分布。
WCCP V2 还在多个路由器和代理之间运行。
安全：
WCCP V1 没有安全功能。
WCCP V2 提供了可选的协议数据包认证。
部署：
网络元素：WCCP 部署在各种 Cisco 路由器上。
缓存代理：WCCP 部署在许多供应商的缓存代理上。
提交者：
大卫福斯特
文档编辑器。
8.2、 网元控制协议（NECP）
最著名的参考资料：
“NECP：网络元素控制协议（Network Element Control Protocol）”[22]（进行中）
描述：
NECP 为网络元素提供了了解服务器功能、可用性以及有关哪些流可以和不可以服务的提示的方法。这允许网络元素跨服务器群执行负载平衡、重定向到拦截代理以及切入群无法提供服务的流。
安全：
可选地使用 HMAC-SHA-1 [11] 共享秘密身份验证以及复杂的序列号来提供中等强度的安全性。如果不使用身份验证，协议会受到攻击。
部署：
目前未知；一些网络元素和缓存代理供应商已表示有意实施该协议。
提交者：
加里汤姆林森
8.3、 SOCKS
最著名的参考资料：
RFC 1928 SOCKS 协议版本 5 [7]
描述：
SOCKS 主要用作防火墙协议的缓存代理。尽管防火墙不符合上述狭义的网络元素定义，但它们是网络基础设施的一个组成部分。当与防火墙结合使用时，SOCKS 会在缓存代理和防火墙之间提供经过身份验证的隧道。
安全：
一个广泛的框架提供了多种身份验证方法。目前，已知可用的有 SSL、CHAP、DES、3DES。
部署：
SOCKS 在 Internet 中被广泛部署。
提交者：
文档编辑器。
9. 安全考虑
本文档提供了 Web 缓存和复制的分类法。没有详细描述推荐的做法、架构和协议。
根据定义，复制和缓存涉及资源的复制。制作和保存临时或永久副本存在法律影响；这些不在这里介绍。
本备忘录中提及的每个协议的安全性信息在前面的部分及其随附的文档中提供。 HTTP 安全性在 RFC 2616 [1] 的第 15 节（HTTP/1.1 规范）中进行了讨论，在 RFC 1945 [6]（HTTP/1.0 规范）中的讨论范围较小。 RFC 2616 包含 HTTP 代理的安全注意事项。
缓存代理与其他应用程序级代理具有相同的安全问题。这些安全注意事项不包括应用程序级代理。当通信中涉及代理时，基于 IP 号码的身份验证是有问题的。此处不讨论细节。
9.1、 认证
对网络资源的请求以及对此类请求的响应可能会被定向到副本和/或可能会流经中间代理。需要保持通信的完整性，以确保防止访问丢失和意外更改。
9.1.1、 中间人攻击
HTTP 代理是中间人，是中间人攻击的理想场所。对此的讨论可以在 RFC 2616 [1] 的第 15 节中找到。
9.1.2、 可信第三方
代理必须被信任以代表源服务器和/或客户端运行，或者它必须充当隧道。当向客户端呈现缓存对象时，客户端需要信任缓存代理代表源服务器进行操作。
副本可以从源服务器获得认证。
9.1.3、 基于IP号的认证
当通过代理连接时，基于客户端 IP 号的身份验证是有问题的，因为身份验证设备只能访问代理的 IP 号。对此的一个（有问题的）解决方案是让代理欺骗客户端的 IP 号以进行入站请求。
基于 IP 号码的身份验证假设保留了 Internet 的端到端属性。对于包含拦截代理的环境，通常情况并非如此。
9.2、 隐私
9.2.1、 可信第三方
使用复制服务时，必须同时信任副本源服务器和副本选择系统。
通过自动副本选择方法或在代理内重定向流量可能会引入最终用户和/或源服务器必须信任的第三方。在拦截代理的情况下，通信的两个端点通常都不知道此类第三方。未知的第三方可能有安全隐患。
代理和副本选择服务都可以访问聚合访问信息。代理通常知道每个使用它的客户端的访问，这些信息比单个源服务器持有的信息更敏感。
9.2.2、 日志和法律影响
来自代理的日志应该保持安全，因为它们提供有关用户及其行为模式的信息。代理的日志甚至比 Web 服务器日志更敏感，因为来自用户群的每个请求都经过代理。来自副本源服务器的日志可能需要合并以从服务中获取汇总统计信息，并且跨境传输日志可能会产生法律影响。在某些国家/地区，日志处理受到法律限制。
Web 复制和缓存系统中的对象安全和隐私要求与整个 Internet 中的要求相同。唯一可靠的解决方案是强密码术。端到端加密经常使资源无法缓存，例如 SSL 加密的 Web 会话。
9.3、 服务安全
9.3.1、 拒绝服务
任何流量重定向都容易在重定向点受到拒绝服务攻击，代理和副本选择服务都可能重定向流量。
通过攻击代理，可能会拒绝大量客户端访问所有服务器。
有人认为，拦截代理的引入是一种拒绝服务攻击，因为互联网的端到端性质在内容消费者不知情的情况下被破坏了。
9.3.2、 重放攻击
根据定义，缓存代理是一种重放攻击。
9.3.3、 愚蠢的代理配置
很容易有一个愚蠢的配置，这会损害内容消费者的服务。这是代理最常见的安全问题。
9.3.4、 受版权保护的临时副本
世界上的立法力量正在考虑临时副本的问题，如保存在复制和缓存系统中的那些，是否合法。复制和缓存的法律含义受当地法律的约束。
缓存代理需要保留协议输出，包括标头。复制服务需要保留对象的来源。
9.3.5、 应用层访问
缓存代理是流量路径中的应用程序级组件，它可以让入侵者访问以前只能在无代理世界中的网络级别获得的信息。某些网络级设备可能需要物理访问才能获取敏感信息。应用级组件的引入可能需要额外的系统安全性。
10、 致谢
编辑要感谢以下人员的帮助：David Forster、Alex Rousskov、Josh Cohen、John Martin、John Dilley、Ivan Lovric、Joe Touch、Henrik Nordstrom、Patrick McManus、Duane Wessels、Wojtek Sylwestrzak、Ted Hardie、Misha Rabinovich 、拉里·马斯特、基思·摩尔、罗伊·菲尔丁、帕特里克·法特斯特罗姆、希拉里·奥尔曼、马克·诺丁汉和奥斯卡·巴图纳。
参考
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [2] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997. [3] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), Version 2", RFC 2187, September 1997. [4] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [5] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, "The Internet Gopher Protocol", RFC 1436, March 1993. [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [7] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [8] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [9] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000. [10] Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of ACM SIGCOMM'98 pp. 254-265, September 1998. [11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [12] Netscape, Inc., "Navigator Proxy Auto-Config File Format", March 1996, <URL:http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html>. [13] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web Proxy Auto-Discovery Protocol", Work in Progress. [14] Valloppillil, V. and K. Ross, "Cache Array Routing Protocol", Work in Progress. [15] Microsoft Corporation, "Cache Array Routing Protocol (CARP) v1.0 Specifications, Technical Whitepaper", August 1999, <URL:http://www.microsoft.com/Proxy/Guide/carpspec.asp>. [16] Microsoft Corporation, "Cache Array Routing Protocol and Microsoft Proxy Server 2.0, Technical White Paper", August 1998, <URL:http://www.microsoft.com/proxy/documents/CarpWP.exe>. [17] Lovric, I., "Internet Cache Protocol Extension", Work in Progress. [18] Cieslak, M. and D. Forster, "Cisco Web Cache Coordination Protocol V1.0", Work in Progress. [19] Cieslak, M., Forster, D., Tiwana, G. and R. Wilson, "Cisco Web Cache Coordination Protocol V2.0", Work in Progress. [20] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a cache - A satellite overview", Work in Progress. [21] Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest specification - version 5", December 1998, <URL:http://www.squid-cache.org/CacheDigest/cache-digest-v5.txt>. [22] Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig, P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson, "NECP: The Network Element Control Protocol", Work in Progress. [23] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", Work in Progress.
完整的版权声明
版权所有 (C) 互联网协会 (2001)。版权所有。
本文件及其译文可能会被复制和提供给他人，并且可以全部或部分地准备、复制、出版和分发对其进行评论或以其他方式解释或协助其实施的衍生作品，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文档本身，例如通过删除版权声明或对 Internet 协会或其他 Internet 组织的引用，除非出于制定 Internet 标准的需要，在这种情况下，版权程序定义在必须遵循 Internet 标准流程，或按照要求将其翻译成英语以外的语言。
上述授予的有限权限是永久性的，不会被互联网协会或其继任者或受让人撤销。
本文档和其中包含的信息按“原样”提供，互联网协会和互联网工程工作队不提供所有明示或暗示的保证，包括但不限于任何保证，即使用此处的信息不会侵犯任何有关适销性或特定用途适用性的权利或任何默示保证。
致谢
RFC 编辑器功能的资金目前由互联网协会提供。
