Network Working Group I. Cooper
Request for Comments: 3040 Equinix, Inc.
Category: Informational I. Melve
UNINETT
G. Tomlinson
CacheFlow Inc.
January 2001
Network Working Group I. Cooper
Request for Comments: 3040 Equinix, Inc.
Category: Informational I. Melve
UNINETT
G. Tomlinson
CacheFlow Inc.
January 2001
Internet Web Replication and Caching Taxonomy
Internet Web复制和缓存分类法
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in the document titled "Known HTTP Proxy/Caching Problems", and are not part of this document. This document presents open protocols and points to published material for each protocol.
本备忘录规定了目前部署的web复制和缓存基础架构的标准术语和分类。它介绍了目前在这个应用领域中使用的标准概念和协议。目前使用这些技术部署的解决方案用于建立标准分类法。名为“已知HTTP代理/缓存问题”的文档中介绍了缓存代理的已知问题，这些问题不属于本文档的一部分。本文档介绍开放式协议，并指出每个协议的已发布材料。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Base Terms . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 First order derivative terms . . . . . . . . . . . . . . . 6
2.3 Second order derivatives . . . . . . . . . . . . . . . . . 7
2.4 Topological terms . . . . . . . . . . . . . . . . . . . . 7
2.5 Automatic use of proxies . . . . . . . . . . . . . . . . . 8
3. Distributed System Relationships . . . . . . . . . . . . . 9
3.1 Replication Relationships . . . . . . . . . . . . . . . . 9
3.1.1 Client to Replica . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Inter-Replica . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Proxy Relationships . . . . . . . . . . . . . . . . . . . 10
3.2.1 Client to Non-Interception Proxy . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Base Terms . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 First order derivative terms . . . . . . . . . . . . . . . 6
2.3 Second order derivatives . . . . . . . . . . . . . . . . . 7
2.4 Topological terms . . . . . . . . . . . . . . . . . . . . 7
2.5 Automatic use of proxies . . . . . . . . . . . . . . . . . 8
3. Distributed System Relationships . . . . . . . . . . . . . 9
3.1 Replication Relationships . . . . . . . . . . . . . . . . 9
3.1.1 Client to Replica . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Inter-Replica . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Proxy Relationships . . . . . . . . . . . . . . . . . . . 10
3.2.1 Client to Non-Interception Proxy . . . . . . . . . . . . . 10
3.2.2 Client to Surrogate to Origin Server . . . . . . . . . . . 10
3.2.3 Inter-Proxy . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 11
3.2.3.2 (Caching) Proxy Arrays . . . . . . . . . . . . . . . . . . 12
3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 12
4. Replica Selection . . . . . . . . . . . . . . . . . . . . 13
4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 13
4.2 Replica HTTP Redirection . . . . . . . . . . . . . . . . . 14
4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 14
5. Inter-Replica Communication . . . . . . . . . . . . . . . 15
5.1 Batch Driven Replication . . . . . . . . . . . . . . . . . 15
5.2 Demand Driven Replication . . . . . . . . . . . . . . . . 16
5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 16
6. User Agent to Proxy Configuration . . . . . . . . . . . . 17
6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 17
6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 17
6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 18
6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 18
7. Inter-Proxy Communication . . . . . . . . . . . . . . . . 19
7.1 Loosely coupled Inter-Proxy Communication . . . . . . . . 19
7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 19
7.1.2 Hyper Text Caching Protocol . . . . . . . . . . . . . . . 20
7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 22
7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 22
7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 22
8. Network Element Communication . . . . . . . . . . . . . . 23
8.1 Web Cache Control Protocol (WCCP) . . . . . . . . . . . . 23
8.2 Network Element Control Protocol (NECP) . . . . . . . . . 24
8.3 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . 25
9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 26
9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 26
9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 26
9.1.3 Authentication based on IP number . . . . . . . . . . . . 26
9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 26
9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 27
9.3 Service security . . . . . . . . . . . . . . . . . . . . . 27
9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 27
9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 27
9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 28
9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 28
9.3.5 Application level access . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28
References . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
Full Copyright Statement . . . . . . . . . . . . . . . . . 32
3.2.2 Client to Surrogate to Origin Server . . . . . . . . . . . 10
3.2.3 Inter-Proxy . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 11
3.2.3.2 (Caching) Proxy Arrays . . . . . . . . . . . . . . . . . . 12
3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 12
4. Replica Selection . . . . . . . . . . . . . . . . . . . . 13
4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 13
4.2 Replica HTTP Redirection . . . . . . . . . . . . . . . . . 14
4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 14
5. Inter-Replica Communication . . . . . . . . . . . . . . . 15
5.1 Batch Driven Replication . . . . . . . . . . . . . . . . . 15
5.2 Demand Driven Replication . . . . . . . . . . . . . . . . 16
5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 16
6. User Agent to Proxy Configuration . . . . . . . . . . . . 17
6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 17
6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 17
6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 18
6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 18
7. Inter-Proxy Communication . . . . . . . . . . . . . . . . 19
7.1 Loosely coupled Inter-Proxy Communication . . . . . . . . 19
7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 19
7.1.2 Hyper Text Caching Protocol . . . . . . . . . . . . . . . 20
7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 22
7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 22
7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 22
8. Network Element Communication . . . . . . . . . . . . . . 23
8.1 Web Cache Control Protocol (WCCP) . . . . . . . . . . . . 23
8.2 Network Element Control Protocol (NECP) . . . . . . . . . 24
8.3 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . 25
9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 26
9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 26
9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 26
9.1.3 Authentication based on IP number . . . . . . . . . . . . 26
9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 26
9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 27
9.3 Service security . . . . . . . . . . . . . . . . . . . . . 27
9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 27
9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 27
9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 28
9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 28
9.3.5 Application level access . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28
References . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
Full Copyright Statement . . . . . . . . . . . . . . . . . 32
Since its introduction in 1990, the World-Wide Web has evolved from a simple client server model into a complex distributed architecture. This evolution has been driven largely due to the scaling problems associated with exponential growth. Distinct paradigms and solutions have emerged to satisfy specific requirements. Two core infrastructure components being employed to meet the demands of this growth are replication and caching. In many cases, there is a need for web caches and replicated services to be able to coexist.
自1990年引入以来，万维网已经从一个简单的客户机-服务器模型演变为一个复杂的分布式体系结构。这种演变主要是由于与指数增长相关的规模问题。不同的范例和解决方案已经出现，以满足特定的需求。为满足这一增长的需求而采用的两个核心基础架构组件是复制和缓存。在许多情况下，需要web缓存和复制服务才能共存。
This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure deployed in the Internet today. The principal goal of this document is to establish a common understanding and reference point of this application domain.
本备忘录规定了目前部署在Internet上的web复制和缓存基础架构的标准术语和分类。本文档的主要目标是建立对该应用领域的共同理解和参考点。
It is also expected that this document will be used in the creation of a standard architectural framework for efficient, reliable, and predictable service in a web which includes both replicas and caches.
此外，本文档还将用于创建标准体系结构框架，以便在包含副本和缓存的web中提供高效、可靠和可预测的服务。
Some of the protocols which this memo examines are specified only by company technical white papers or work in progress documents. Such references are included to demonstrate the existence of such protocols, their experimental deployment in the Internet today, or to aid the reader in their understanding of this technology area.
本备忘录审查的一些协议仅由公司技术白皮书或在建工程文件规定。包括这些参考文献是为了证明这些协议的存在，它们在当今互联网上的实验部署，或者帮助读者理解这一技术领域。
There are many protocols, both open and proprietary, employed in web replication and caching today. A majority of the open protocols include DNS [8], Cache Digests [21][10], CARP [14], HTTP [1], ICP [2], PAC [12], SOCKS [7], WPAD [13], and WCCP [18][19]. These protocols, and their use within the caching and replication environments, are discussed below.
目前，在web复制和缓存中使用了许多协议，包括开放协议和专有协议。大多数开放协议包括DNS[8]、缓存摘要[21][10]、CARP[14]、HTTP[1]、ICP[2]、PAC[12]、SOCKS[7]、WPAD[13]和WCCP[18][19]。下面将讨论这些协议及其在缓存和复制环境中的使用。
The following terminology provides definitions of common terms used within the web replication and caching community. Base terms are taken, where possible, from the HTTP/1.1 specification [1] and are included here for reference. First- and second-order derivatives are constructed from these base terms to help define the relationships that exist within this area.
以下术语提供了web复制和缓存社区中常用术语的定义。在可能的情况下，基本术语取自HTTP/1.1规范[1]，并包含在此处以供参考。一阶和二阶导数由这些基本项构成，以帮助定义该区域内存在的关系。
Terms that are in common usage and which are contrary to definitions in RFC 2616 and this document are highlighted.
突出显示了与RFC 2616和本文件中定义相反的常用术语。
The majority of these terms are taken as-is from RFC 2616 [1], and are included here for reference.
这些术语中的大多数是从RFC 2616[1]中提取的，包括在这里以供参考。
client (taken from [1]) A program that establishes connections for the purpose of sending requests.
客户端（取自[1]）为发送请求而建立连接的程序。
server (taken from [1]) An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
服务器（取自[1]）一个应用程序，它接受连接，以便通过发送回响应来服务请求。任何给定的程序都可以既是客户机又是服务器；我们对这些术语的使用仅指程序为特定连接执行的角色，而不是指程序的总体功能。同样，任何服务器都可以充当源服务器、代理、网关或隧道，根据每个请求的性质进行切换。
proxy (taken from [1]) An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
代理（取自[1]）一种中间程序，它同时充当服务器和客户端，以代表其他客户端发出请求。请求由内部提供服务，或者通过将请求传递到其他服务器（可能需要翻译）来提供服务。代理必须实现本规范的客户机和服务器要求。“透明代理”是指不修改超出代理身份验证和标识要求的请求或响应的代理。“非透明代理”是修改请求或响应以便向用户代理提供一些附加服务的代理，例如组注释服务、媒体类型转换、协议缩减或匿名过滤。除非明确说明了透明或非透明行为，否则HTTP代理要求适用于这两种类型的代理。
Note: The term "transparent proxy" refers to a semantically transparent proxy as described in [1], not what is commonly understood within the caching community. We recommend that the term "transparent proxy" is always prefixed to avoid confusion (e.g., "network transparent proxy"). However, see definition of "interception proxy" below.
注意：术语“透明代理”指的是[1]中描述的语义透明代理，而不是缓存社区中通常理解的。我们建议始终在术语“透明代理”前面加上前缀，以避免混淆（例如，“网络透明代理”）。但是，请参见下面“拦截代理”的定义。
The above condition requiring implementation of both the server and client requirements of HTTP/1.1 is only appropriate for a non-network transparent proxy.
上述要求实现HTTP/1.1的服务器和客户端要求的条件仅适用于非网络透明代理。
cache (taken from [1]) A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
缓存（取自[1]）程序的响应消息本地存储和控制其消息存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户端或服务器都可能包含缓存，但缓存不能由充当隧道的服务器使用。
Note: The term "cache" used alone often is meant as "caching proxy".
注：单独使用的术语“缓存”通常指“缓存代理”。
Note: There are additional motivations for caching, for example reducing server load (as a further means to reduce response time).
注意：缓存还有其他动机，例如减少服务器负载（作为减少响应时间的进一步手段）。
cacheable (taken from [1]) A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
可缓存（取自[1]）如果允许缓存存储响应消息的副本以用于应答后续请求，则响应是可缓存的。第13节定义了确定HTTP响应可缓存性的规则。即使资源是可缓存的，缓存是否可以将缓存副本用于特定请求也可能存在其他限制。
gateway (taken from [1]) A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.
网关（取自[1]）充当其他服务器中介的服务器。与代理不同，网关接收请求就像它是请求资源的源服务器一样；请求客户端可能不知道它正在与网关通信。
tunnel (taken from [1]) An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed.
隧道（取自[1]）作为两个连接之间的盲中继的中间程序。一旦激活，隧道就不会被视为HTTP通信的一方，尽管隧道可能是由HTTP请求启动的。当中继连接的两端关闭时，隧道停止存在。
replication "Creating and maintaining a duplicate copy of a database or file system on a different computer, typically a server." - Free Online Dictionary of Computing (FOLDOC)
复制“在不同的计算机（通常是服务器）上创建和维护数据库或文件系统的副本。”-免费在线计算词典（FOLDOC）
inbound/outbound (taken from [1]) Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent".
入站/出站（取自[1]）入站和出站是指消息的请求和响应路径：“入站”表示“向源服务器移动”，“出站”表示“向用户代理移动”。
network element A network device that introduces multiple paths between source and destination, transparent to HTTP.
网元在源和目标之间引入多条路径的网络设备，对HTTP透明。
The following terms are constructed taking the above base terms as foundation.
以上述基本术语为基础构建以下术语。
origin server (taken from [1]) The server on which a given resource resides or is to be created.
源服务器（取自[1]）给定资源所在或将要创建的服务器。
user agent (taken from [1]) The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
用户代理（取自[1]）发起请求的客户端。这些工具通常是浏览器、编辑器、爬行器（web遍历机器人）或其他最终用户工具。
caching proxy A proxy with a cache, acting as a server to clients, and a client to servers.
缓存代理具有缓存的代理，充当客户端的服务器和服务器的客户端。
Caching proxies are often referred to as "proxy caches" or simply "caches". The term "proxy" is also frequently misused when referring to caching proxies.
缓存代理通常被称为“代理缓存”或简称为“缓存”。在提到缓存代理时，“代理”一词也经常被误用。
surrogate A gateway co-located with an origin server, or at a different point in the network, delegated the authority to operate on behalf of, and typically working in close co-operation with, one or more origin servers. Responses are typically delivered from an internal cache.
代理网关与源服务器位于同一位置，或位于网络中的不同点，被授予代表一个或多个源服务器运行的权限，并且通常与一个或多个源服务器密切合作。响应通常从内部缓存传递。
Surrogates may derive cache entries from the origin server or from another of the origin server's delegates. In some cases a surrogate may tunnel such requests.
代理可以从源服务器或源服务器的另一个代理派生缓存项。在某些情况下，代理可以通过隧道传输此类请求。
Where close co-operation between origin servers and surrogates exists, this enables modifications of some protocol requirements, including the Cache-Control directives in [1]. Such modifications have yet to be fully specified.
如果源服务器和代理服务器之间存在密切合作，则可以修改某些协议要求，包括[1]中的缓存控制指令。此类修改尚未完全明确。
Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as surrogates.
通常被称为“反向代理”和“（原始）服务器加速器”的设备都更适合定义为代理。
reverse proxy See "surrogate".
反向代理请参见“代理”。
server accelerator See "surrogate".
服务器加速器请参阅“代理”。
The following terms further build on first order derivatives:
以下术语进一步建立在一阶导数的基础上：
master origin server An origin server on which the definitive version of a resource resides.
主源服务器资源的最终版本所在的源服务器。
replica origin server An origin server holding a replica of a resource, but which may act as an authoritative reference for client requests.
副本源服务器保存资源副本的源服务器，但可以作为客户端请求的权威参考。
content consumer The user or system that initiates inbound requests, through use of a user agent.
内容使用者通过使用用户代理发起入站请求的用户或系统。
browser A special instance of a user agent that acts as a content presentation device for content consumers.
浏览器用户代理的特殊实例，用作内容使用者的内容呈现设备。
The following definitions are added to describe caching device topology:
添加以下定义以描述缓存设备拓扑：
user agent cache The cache within the user agent program.
用户代理缓存用户代理程序中的缓存。
local caching proxy The caching proxy to which a user agent connects.
本地缓存代理用户代理连接到的缓存代理。
intermediate caching proxy Seen from the content consumer's view, all caches participating in the caching mesh that are not the user agent's local caching proxy.
中间缓存代理从内容使用者的视图中可以看到，参与缓存网格的所有缓存都不是用户代理的本地缓存代理。
cache server A server to requests made by local and intermediate caching proxies, but which does not act as a proxy.
缓存服务器本地和中间缓存代理发出的请求的服务器，但不充当代理。
cache array A cluster of caching proxies, acting logically as one service and partitioning the resource name space across the array. Also known as "diffused array" or "cache cluster".
缓存阵列缓存代理的集群，在逻辑上充当一个服务，并在整个阵列中划分资源名称空间。也称为“扩散阵列”或“缓存群集”。
caching mesh a loosely coupled set of co-operating proxy- and (optionally) caching-servers, or clusters, acting independently but sharing cacheable content between themselves using inter-cache communication protocols.
caching mesh一组松散耦合的协作代理和（可选）缓存服务器或集群，它们独立运行，但使用缓存间通信协议在它们之间共享可缓存内容。
Network administrators may wish to force or facilitate the use of proxies by clients, enabling such configuration within the network itself or within automatic systems in user agents, such that the content consumer need not be aware of any such configuration issues.
网络管理员可能希望强制或促进客户端使用代理，从而在网络本身内或在用户代理中的自动系统内启用此类配置，从而内容消费者不需要知道任何此类配置问题。
The terms that describe such configurations are given below.
下面给出了描述此类配置的术语。
automatic user-agent proxy configuration The technique of discovering the availability of one or more proxies and the automated configuration of the user agent to use them. The use of a proxy is transparent to the content consumer but not to the user agent. The term "automatic proxy configuration" is also used in this sense.
自动用户代理代理配置发现一个或多个代理的可用性以及用户代理使用它们的自动配置的技术。代理的使用对内容消费者透明，但对用户代理不透明。术语“自动代理配置”也在这个意义上使用。
traffic interception The process of using a network element to examine network traffic to determine whether it should be redirected.
流量拦截使用网元检查网络流量以确定是否应重定向的过程。
traffic redirection Redirection of client requests from a network element performing traffic interception to a proxy. Used to deploy (caching) proxies without the need to manually reconfigure individual user agents, or to force the use of a proxy where such use would not otherwise occur.
流量重定向客户端请求从执行流量拦截的网元重定向到代理。用于部署（缓存）代理，而无需手动重新配置单个用户代理，或在不使用代理的情况下强制使用代理。
interception proxy (a.k.a. "transparent proxy", "transparent cache") The term "transparent proxy" has been used within the caching community to describe proxies used with zero configuration within the user agent. Such use is somewhat transparent to user agents. Due to discrepancies with [1] (see definition of "proxy" above), and objections to the use of the word "transparent", we introduce the term "interception proxy" to describe proxies that receive redirected traffic flows from network elements performing traffic interception.
拦截代理（也称为“透明代理”、“透明缓存”）术语“透明代理”在缓存社区中用于描述在用户代理中零配置使用的代理。这种使用对于用户代理来说是透明的。由于与[1]存在差异（见上文“代理”的定义），并且反对使用“透明”一词，我们引入术语“拦截代理”来描述从执行流量拦截的网络元件接收重定向流量的代理。
Interception proxies receive inbound traffic flows through the process of traffic redirection. (Such proxies are deployed by network administrators to facilitate or require the use of appropriate services offered by the proxy). Problems associated with the deployment of interception proxies are described in the
拦截代理通过流量重定向过程接收入站流量。（此类代理由网络管理员部署，以方便或要求使用代理提供的适当服务）。中描述了与部署拦截代理相关的问题
document "Known HTTP Proxy/Caching Problems" [23]. The use of interception proxies requires zero configuration of the user agent which act as though communicating directly with an origin server.
文档“已知HTTP代理/缓存问题”[23]。使用拦截代理需要零配置用户代理，就像直接与源服务器通信一样。
This section identifies the relationships that exist in a distributed replication and caching environment. Having defined these relationships, later sections describe the communication protocols used in each relationship.
本节确定分布式复制和缓存环境中存在的关系。在定义了这些关系之后，后面的章节将描述每个关系中使用的通信协议。
The following sections describe relationships between clients and replicas and between replicas themselves.
以下各节描述了客户端和副本之间以及副本本身之间的关系。
A client may communicate with one or more replica origin servers, as well as with master origin servers. (In the absence of replica servers the client interacts directly with the origin server as is the normal case.)
客户端可以与一个或多个副本源服务器以及主源服务器通信。（在没有副本服务器的情况下，客户端会像正常情况一样直接与源服务器交互。）
------------------ ----------------- ------------------
| Replica Origin | | Master Origin | | Replica Origin |
| Server | | Server | | Server |
------------------ ----------------- ------------------
\ | /
\ | /
-----------------------------------------
| Client to
----------------- Replica Server
| Client |
-----------------
------------------ ----------------- ------------------
| Replica Origin | | Master Origin | | Replica Origin |
| Server | | Server | | Server |
------------------ ----------------- ------------------
\ | /
\ | /
-----------------------------------------
| Client to
----------------- Replica Server
| Client |
-----------------
Protocols used to enable the client to use one of the replicas can be found in Section 4.
用于使客户端能够使用其中一个副本的协议可以在第4节中找到。
This is the relationship between master origin server(s) and replica origin servers, to replicate data sets that are accessed by clients in the relationship shown in Section 3.1.1.
这是主源服务器和副本源服务器之间的关系，用于复制客户端在第3.1.1节所示关系中访问的数据集。
------------------ ----------------- ------------------
| Replica Origin |-----| Master Origin |-----| Replica Origin |
| Server | | Server | | Server |
------------------ ----------------- ------------------
------------------ ----------------- ------------------
| Replica Origin |-----| Master Origin |-----| Replica Origin |
| Server | | Server | | Server |
------------------ ----------------- ------------------
Protocols used in this relationship can be found in Section 5.
此关系中使用的协议见第5节。
There are a variety of ways in which (caching) proxies and cache servers communicate with each other, and with user agents.
（缓存）代理和缓存服务器之间以及与用户代理之间的通信方式多种多样。
A client may communicate with zero or more proxies for some or all requests. Where the result of communication results in no proxy being used, the relationship is between client and (replica) origin server (see Section 3.1.1).
对于某些或所有请求，客户端可以与零个或多个代理进行通信。如果通信结果导致未使用代理，则客户机和（副本）源服务器之间存在关系（见第3.1.1节）。
----------------- ----------------- -----------------
| Local | | Local | | Local |
| Proxy | | Proxy | | Proxy |
----------------- ----------------- -----------------
\ | /
\ | /
-----------------------------------------
|
-----------------
| Client |
-----------------
----------------- ----------------- -----------------
| Local | | Local | | Local |
| Proxy | | Proxy | | Proxy |
----------------- ----------------- -----------------
\ | /
\ | /
-----------------------------------------
|
-----------------
| Client |
-----------------
In addition, a user agent may interact with an additional server - operated on behalf of a proxy for the purpose of automatic user agent proxy configuration.
此外，为了自动配置用户代理代理，用户代理可以与代表代理操作的附加服务器交互。
Schemes and protocols used in these relationships can be found in Section 6.
这些关系中使用的方案和协议见第6节。
A client may communicate with zero or more surrogates for requests intended for one or more origin servers. Where a surrogate is not used, the client communicates directly with an origin server. Where a surrogate is used the client communicates as if with an origin server. The surrogate fulfills the request from its internal cache, or acts as a gateway or tunnel to the origin server.
对于一个或多个源服务器的请求，客户端可以与零个或多个代理进行通信。如果未使用代理，客户端将直接与源服务器通信。在使用代理的情况下，客户端就像与源服务器通信一样进行通信。代理项从其内部缓存完成请求，或充当到源服务器的网关或隧道。
-------------- -------------- --------------
| Origin | | Origin | | Origin |
| Server | | Server | | Server |
-------------- -------------- --------------
\ | /
\ | /
-----------------
| Surrogate |
| |
-----------------
|
|
------------
| Client |
------------
-------------- -------------- --------------
| Origin | | Origin | | Origin |
| Server | | Server | | Server |
-------------- -------------- --------------
\ | /
\ | /
-----------------
| Surrogate |
| |
-----------------
|
|
------------
| Client |
------------
Inter-Proxy relationships exist as meshes (loosely coupled) and clusters (tightly coupled).
代理间关系以网格（松散耦合）和簇（紧密耦合）的形式存在。
Within a loosely coupled mesh of (caching) proxies, communication can happen at the same level between peers, and with one or more parents.
在（缓存）代理的松散耦合网格中，对等方之间以及与一个或多个父级之间可以在同一级别进行通信。
--------------------- ---------------------
-----------| Intermediate | | Intermediate |
| | Caching Proxy (D) | | Caching Proxy (E) |
|(peer) --------------------- ---------------------
-------------- | (parent) / (parent)
| Cache | | ------/
| Server (C) | | /
-------------- | /
(peer) | ----------------- ---------------------
-------------| Local Caching |-------| Intermediate |
| Proxy (A) | (peer)| Caching Proxy (B) |
----------------- ---------------------
|
|
----------
| Client |
----------
--------------------- ---------------------
-----------| Intermediate | | Intermediate |
| | Caching Proxy (D) | | Caching Proxy (E) |
|(peer) --------------------- ---------------------
-------------- | (parent) / (parent)
| Cache | | ------/
| Server (C) | | /
-------------- | /
(peer) | ----------------- ---------------------
-------------| Local Caching |-------| Intermediate |
| Proxy (A) | (peer)| Caching Proxy (B) |
----------------- ---------------------
|
|
----------
| Client |
----------
Client included for illustration purposes only
包含的客户机仅供说明之用
An inbound request may be routed to one of a number of intermediate (caching) proxies based on a determination of whether that parent is better suited to resolving the request.
基于对父级是否更适合解析请求的确定，可以将入站请求路由到多个中间（缓存）代理之一。
For example, in the above figure, Cache Server C and Intermediate Caching Proxy B are peers of the Local Caching Proxy A, and may only be used when the resource requested by A already exists on either B or C. Intermediate Caching Proxies D & E are parents of A, and it is A's choice of which to use to resolve a particular request.
例如，在上图中，缓存服务器C和中间缓存代理B是本地缓存代理A的对等方，并且只能在A请求的资源已经存在于B或C上时使用。中间缓存代理D&E是A的父级，并且由A选择使用哪个来解析特定请求。
The relationship between A & B only makes sense in a caching environment, while the relationships between A & D and A & E are also appropriate where D or E are non-caching proxies.
A&B之间的关系仅在缓存环境中才有意义，而A&D和A&E之间的关系也适用于D或E是非缓存代理的情况。
Protocols used in these relationships can be found in Section 7.1.
这些关系中使用的协议见第7.1节。
Where a user agent may have a relationship with a proxy, it is possible that it may instead have a relationship with an array of proxies arranged in a tightly coupled mesh.
在用户代理可能与代理具有关系的情况下，它可能与排列在紧密耦合网格中的代理阵列具有关系。
----------------------
---------------------- |
--------------------- | |
| (Caching) Proxy | |-----
| Array |----- ^ ^
--------------------- ^ ^ | |
^ ^ | |--- |
| |----- |
--------------------------
----------------------
---------------------- |
--------------------- | |
| (Caching) Proxy | |-----
| Array |----- ^ ^
--------------------- ^ ^ | |
^ ^ | |--- |
| |----- |
--------------------------
Protocols used in this relationship can be found in Section 7.2.
该关系中使用的协议见第7.2节。
A network element performing traffic interception may choose to redirect requests from a client to a specific proxy within an array. (It may also choose not to redirect the traffic, in which case the relationship is between client and (replica) origin server, see Section 3.1.1.)
执行流量拦截的网元可以选择将来自客户端的请求重定向到阵列中的特定代理。（它也可以选择不重定向流量，在这种情况下，客户端和（副本）源服务器之间的关系，请参见第3.1.1节。）
----------------- ----------------- -----------------
| Caching Proxy | | Caching Proxy | | Caching Proxy |
| Array | | Array | | Array |
----------------- ----------------- -----------------
\ | /
-----------------------------------------
|
--------------
| Network |
| Element |
--------------
|
///
|
------------
| Client |
------------
----------------- ----------------- -----------------
| Caching Proxy | | Caching Proxy | | Caching Proxy |
| Array | | Array | | Array |
----------------- ----------------- -----------------
\ | /
-----------------------------------------
|
--------------
| Network |
| Element |
--------------
|
///
|
------------
| Client |
------------
The interception proxy may be directly in-line of the flow of traffic - in which case the intercepting network element and interception proxy form parts of the same hardware system - or may be out-of-path, requiring the intercepting network element to redirect traffic to another network segment. In this latter case, communication protocols enable the intercepting network element to stop and start redirecting traffic when the interception proxy becomes (un)available. Details of these protocols can be found in Section 8.
截取代理可以直接与流量保持一致——在这种情况下，截取网元和截取代理构成同一硬件系统的一部分——或者可能不在路径上，要求截取网元将流量重定向到另一个网段。在后一种情况下，通信协议使拦截网元能够在拦截代理变得（不）可用时停止并开始重定向流量。有关这些协议的详细信息，请参见第8节。
This section describes the schemes and protocols used in the cooperation and communication between client and replica origin web servers. The ideal situation is to discover an optimal replica origin server for clients to communicate with. Optimality is a policy based decision, often based upon proximity, but may be based on other criteria such as load.
本节介绍客户端和副本源web服务器之间的协作和通信中使用的方案和协议。理想的情况是发现一个最佳的副本源服务器，以便客户端与之通信。优化是一种基于策略的决策，通常基于邻近性，但也可能基于其他标准，如负载。
Best known reference: This memo.
最著名的参考资料：这份备忘录。
Description: The simplest of client to replica communication mechanisms. This utilizes hyperlink URIs embedded in web pages that point to the individual replica origin servers. The content consumer manually selects the link of the replica origin server they wish to use.
描述：最简单的客户端到副本通信机制。这利用嵌入在指向单个副本源服务器的网页中的超链接URI。内容使用者手动选择要使用的副本源服务器的链接。
Security: Relies on the protocol security associated with the appropriate URI scheme.
安全性：依赖于与相应URI方案关联的协议安全性。
Deployment: Probably the most commonly deployed client to replica communication mechanism. Ubiquitous interoperability with humans.
部署：可能是最常见的部署客户端到副本的通信机制。与人类普遍存在的互操作性。
Submitter: Document editors.
提交者：文档编辑器。
Best known reference: This memo.
最著名的参考资料：这份备忘录。
Description: A simple and commonly used mechanism to connect clients with replica origin servers is to use HTTP redirection. Clients are redirected to an optimal replica origin server via the use of the HTTP [1] protocol response codes, e.g., 302 "Found", or 307 "Temporary Redirect". A client establishes HTTP communication with one of the replica origin servers. The initially contacted replica origin server can then either choose to accept the service or redirect the client again. Refer to section 10.3 in HTTP/1.1 [1] for information on HTTP response codes.
描述：连接客户端和副本源服务器的一种简单且常用的机制是使用HTTP重定向。通过使用HTTP[1]协议响应代码，例如302“找到”或307“临时重定向”，将客户端重定向到最佳副本源服务器。客户端与其中一个副本源服务器建立HTTP通信。然后，最初联系的副本源服务器可以选择接受服务或再次重定向客户端。有关HTTP响应代码的信息，请参阅HTTP/1.1[1]中的第10.3节。
Security: Relies entirely upon HTTP security.
安全性：完全依赖于HTTP安全性。
Deployment: Observed at a number of large web sites. Extent of usage in the Internet is unknown.
部署：在许多大型网站上观察到。互联网的使用程度不得而知。
Submitter: Document editors.
提交者：文档编辑器。
Best known references:
最著名的参考文献：
* RFC 1794 DNS Support for Load Balancing Proximity [8]
* RFC 1794 DNS对负载平衡邻近性的支持[8]
* This memo
* 这份备忘录
Description: The Domain Name Service (DNS) provides a more sophisticated client to replica communication mechanism. This is accomplished by DNS
描述：域名服务（DNS）提供了更复杂的客户端到副本的通信机制。这是通过DNS实现的
servers that sort resolved IP addresses based upon quality of service policies. When a client resolves the name of an origin server, the enhanced DNS server sorts the available IP addresses of the replica origin servers starting with the most optimal replica and ending with the least optimal replica.
根据服务质量策略对解析的IP地址进行排序的服务器。当客户端解析源服务器的名称时，增强型DNS服务器将对副本源服务器的可用IP地址进行排序，从最佳副本开始，以最佳副本结束。
Security: Relies entirely upon DNS security, and other protocols that may be used in determining the sort order.
安全性：完全依赖于DNS安全性和可用于确定排序顺序的其他协议。
Deployment: Observed at a number of large web sites and large ISP web hosted services. Extent of usage in the Internet is unknown, but is believed to be increasing.
部署：在许多大型网站和大型ISP web托管服务上观察到。互联网的使用程度不得而知，但据信正在增加。
Submitter: Document editors.
提交者：文档编辑器。
This section describes the cooperation and communication between master- and replica- origin servers. Used in replicating data sets between origin servers.
本节介绍主服务器和副本源服务器之间的协作和通信。用于在源服务器之间复制数据集。
Best known reference: This memo.
最著名的参考资料：这份备忘录。
Description: The replica origin server to be updated initiates communication with a master origin server. The communication is established at intervals based upon queued transactions which are scheduled for deferred processing. The scheduling mechanism policies vary, but generally are re-occurring at a specified time. Once communication is established, data sets are copied to the initiating replica origin server.
描述：要更新的副本源服务器启动与主源服务器的通信。根据为延迟处理而安排的排队事务，以一定的间隔建立通信。调度机制策略各不相同，但通常在指定时间重新出现。建立通信后，数据集将复制到发起复制源服务器。
Security: Relies upon the protocol being used to transfer the data set. FTP [4] and RDIST are the most common protocols observed.
安全性：依赖于用于传输数据集的协议。FTP[4]和RDIST是最常见的协议。
Deployment: Very common for synchronization of mirror sites in the Internet.
部署：在Internet上同步镜像站点非常常见。
Submitter: Document editors.
提交者：文档编辑器。
Best known reference: This memo.
最著名的参考资料：这份备忘录。
Description: Replica origin servers acquire content as needed due to client demand. When a client requests a resource that is not in the data set of the replica origin server/surrogate, an attempt is made to resolve the request by acquiring the resource from the master origin server, returning it to the requesting client.
描述：副本源服务器根据客户机的需要获取内容。当客户端请求的资源不在副本源服务器/代理服务器的数据集中时，会尝试通过从主源服务器获取资源并将其返回给请求客户端来解决该请求。
Security: Relies upon the protocol being used to transfer the resources. FTP [4], Gopher [5], HTTP [1] and ICP [2] are the most common protocols observed.
安全性：依赖于用于传输资源的协议。FTP[4]、Gopher[5]、HTTP[1]和ICP[2]是观察到的最常见的协议。
Deployment: Observed at several large web sites. Extent of usage in the Internet is unknown.
部署：在几个大型网站上观察到。互联网的使用程度不得而知。
Submitter: Document editors.
提交者：文档编辑器。
Best known reference: This memo.
最著名的参考资料：这份备忘录。
Description: Replicated origin servers cooperate using synchronized strategies and specialized replica protocols to keep the replica data sets coherent. Synchronization strategies range from tightly coherent (a few minutes) to loosely coherent (a few or more hours). Updates occur between replicas based upon the synchronization time constraints of the coherency model employed and are generally in the form of deltas only.
描述：复制源服务器使用同步策略和专用副本协议进行协作，以保持副本数据集的一致性。同步策略的范围从紧密一致（几分钟）到松散一致（几小时或更长时间）。根据所采用的一致性模型的同步时间约束，副本之间会发生更新，并且通常仅以增量的形式进行更新。
Security: All of the known protocols utilize strong cryptographic key exchange methods, which are either based upon the Kerberos shared secret model or the public/private key RSA model.
安全性：所有已知的协议都使用强加密密钥交换方法，这些方法要么基于Kerberos共享密钥模型，要么基于公钥/私钥RSA模型。
Deployment: Observed at a few sites, primarily at university campuses.
部署：在一些地点观察，主要是在大学校园。
Submitter: Document editors.
提交者：文档编辑器。
Note: The editors are aware of at least two open source protocols - AFS and CODA - as well as the proprietary NRS protocol from Novell.
注意：编辑们知道至少两个开源协议——AFS和CODA——以及Novell的专有NRS协议。
This section describes the configuration, cooperation and communication between user agents and proxies.
本节描述用户代理和代理之间的配置、协作和通信。
Best known reference: This memo.
最著名的参考资料：这份备忘录。
Description: Each user must configure her user agent by supplying information pertaining to proxied protocols and local policies.
描述：每个用户必须通过提供有关代理协议和本地策略的信息来配置其用户代理。
Security: The potential for doing wrong is high; each user individually sets preferences.
安全性：犯错的可能性很高；每个用户单独设置首选项。
Deployment: Widely deployed, used in all current browsers. Most browsers also support additional options.
部署：广泛部署，用于所有当前浏览器。大多数浏览器还支持其他选项。
Submitter: Document editors.
提交者：文档编辑器。
Best known reference: "Navigator Proxy Auto-Config File Format" [12]
最著名的参考：“导航器代理自动配置文件格式”[12]
Description: A JavaScript script retrieved from a web server is executed for each URL accessed to determine the appropriate proxy (if any) to be used to access the resource. User agents must be configured to request this script upon startup. There is no bootstrap mechanism, manual configuration is necessary.
描述：对访问的每个URL执行从web服务器检索的JavaScript脚本，以确定用于访问资源的适当代理（如果有）。必须将用户代理配置为在启动时请求此脚本。没有引导机制，需要手动配置。
Despite manual configuration, the process of proxy configuration is simplified by centralizing it within a script at a single location.
尽管需要手动配置，但通过将代理配置集中在单个位置的脚本中，简化了代理配置过程。
Security: Common policy per organization possible but still requires initial manual configuration. PAC is better than "manual proxy
安全性：每个组织可能有通用策略，但仍需要初始手动配置。PAC优于“手动代理”
configuration" since PAC administrators may update the proxy configuration without further user intervention.
配置”，因为PAC管理员可以更新代理配置，而无需进一步的用户干预。
Interoperability of PAC files is not high, since different browsers have slightly different interpretations of the same script, possibly leading to undesired effects.
PAC文件的互操作性不高，因为不同的浏览器对同一脚本的解释略有不同，可能导致不期望的效果。
Deployment: Implemented in Netscape Navigator and Microsoft Internet Explorer.
部署：在Netscape Navigator和Microsoft Internet Explorer中实现。
Submitter: Document editors.
提交者：文档编辑器。
Best known references:
最著名的参考文献：
* "Cache Array Routing Protocol" [14] (work in progress)
* “缓存阵列路由协议”[14]（正在进行中）
* "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]
* “缓存阵列路由协议（CARP）v1.0规范”[15]
* "Cache Array Routing Protocol and Microsoft Proxy Server 2.0" [16]
* “缓存阵列路由协议和Microsoft代理服务器2.0”[16]
Description: User agents may use CARP directly as a hash function based proxy selection mechanism. They need to be configured with the location of the cluster information.
描述：用户代理可以直接使用CARP作为基于哈希函数的代理选择机制。它们需要配置集群信息的位置。
Security: Security considerations are not covered in the specification works in progress.
安全：正在进行的规范工程中未包含安全注意事项。
Deployment: Implemented in Microsoft Proxy Server, Squid. Implemented in user agents via PAC scripts.
部署：在Microsoft代理服务器Squid中实现。通过PAC脚本在用户代理中实现。
Submitter: Document editors.
提交者：文档编辑器。
Best known reference: "The Web Proxy Auto-Discovery Protocol" [13] (work in progress)
最著名的参考文献：“Web代理自动发现协议”[13]（正在进行中）
Description: WPAD uses a collection of pre-existing Internet resource discovery mechanisms to perform web proxy auto-discovery.
描述：WPAD使用一组预先存在的Internet资源发现机制来执行web代理自动发现。
The only goal of WPAD is to locate the PAC URL [12]. WPAD does not specify which proxies will be used. WPAD supplies the PAC URL, and the PAC script then operates as defined above to choose proxies per resource request.
WPAD的唯一目标是定位PAC URL[12]。WPAD没有指定将使用哪些代理。WPAD提供PAC URL，然后PAC脚本按照上面的定义进行操作，为每个资源请求选择代理。
The WPAD protocol specifies the following:
WPAD协议规定了以下内容：
* how to use each mechanism for the specific purpose of web proxy auto-discovery
* 如何将每种机制用于web代理自动发现的特定目的
* the order in which the mechanisms should be performed
* 执行机制的顺序
* the minimal set of mechanisms which must be attempted by a WPAD compliant user agent
* 符合WPAD的用户代理必须尝试的最小机制集
The resource discovery mechanisms utilized by WPAD are as follows:
WPAD使用的资源发现机制如下：
* Dynamic Host Configuration Protocol DHCP
* 动态主机配置协议
* Service Location Protocol SLP
* 服务定位协议
* "Well Known Aliases" using DNS A records
* 使用DNS A记录的“已知别名”
* DNS SRV records
* DNS SRV记录
* "service: URLs" in DNS TXT records
* DNS TXT记录中的“服务：URL”
Security: Relies upon DNS and HTTP security.
安全性：依赖于DNS和HTTP安全性。
Deployment: Implemented in some user agents and caching proxy servers. More than two independent implementations.
部署：在一些用户代理和缓存代理服务器中实现。两个以上的独立实现。
Submitter: Josh Cohen
提交人：乔希·科恩
This section describes the cooperation and communication between caching proxies.
本节介绍缓存代理之间的协作和通信。
Best known reference: RFC 2186 Internet Cache Protocol (ICP), version 2 [2]
最著名的参考文献：RFC2186互联网缓存协议（ICP），第2版[2]
Description: ICP is used by proxies to query other (caching) proxies about web resources, to see if the requested resource is present on the other system.
描述：代理使用ICP查询有关web资源的其他（缓存）代理，以查看请求的资源是否存在于其他系统上。
ICP uses UDP. Since UDP is an uncorrected network transport protocol, an estimate of network congestion and availability may be calculated by ICP loss. This rudimentary loss measurement provides, together with round trip times, a load balancing method for caches.
ICP使用UDP。由于UDP是一种未经修正的网络传输协议，因此可以通过ICP损耗计算网络拥塞和可用性的估计值。这种基本的损耗测量与往返时间一起，为缓存提供了一种负载平衡方法。
Security: See RFC 2187 [3]
安全性：见RFC 2187[3]
ICP does not convey information about HTTP headers associated with resources. HTTP headers may include access control and cache directives. Since proxies ask for the availability of resources, and subsequently retrieve them using HTTP, false cache hits may occur (object present in cache, but not accessible to a sibling is one example).
ICP不传递有关与资源关联的HTTP头的信息。HTTP头可能包括访问控制和缓存指令。由于代理请求资源的可用性，然后使用HTTP检索资源，因此可能会出现错误的缓存命中（例如，缓存中存在对象，但兄弟姐妹无法访问）。
ICP suffers from all the security problems of UDP.
ICP面临UDP的所有安全问题。
Deployment: Widely deployed. Most current caching proxy implementations support ICP in some form.
部署：广泛部署。当前大多数缓存代理实现都以某种形式支持ICP。
Submitter: Document editors.
提交者：文档编辑器。
See also: "Internet Cache Protocol Extension" [17] (work in progress)
另请参见：“Internet缓存协议扩展”[17]（正在进行中）
Best known reference: RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) [9]
最著名的参考文献：RFC 2756超文本缓存协议（HTCP/0.0）[9]
Description: HTCP is a protocol for discovering HTTP caching proxies and cached data, managing sets of HTTP caching proxies, and monitoring cache activity.
描述：HTCP是一种用于发现HTTP缓存代理和缓存数据、管理HTTP缓存代理集和监视缓存活动的协议。
HTCP requests include HTTP header material, while ICPv2 does not, enabling HTCP replies to more accurately describe the behaviour that would occur as a result of a subsequent HTTP request for the same resource.
HTCP请求包含HTTP头材料，而ICPv2则不包含，这使得HTCP回复能够更准确地描述由于后续HTTP请求相同资源而发生的行为。
Security: Optionally uses HMAC-MD5 [11] shared secret authentication. Protocol is subject to attack if authentication is not used.
安全性：可选使用HMAC-MD5[11]共享秘密身份验证。如果不使用身份验证，则协议会受到攻击。
Deployment: HTCP is implemented in Squid and the "Web Gateway Interceptor".
部署：HTCP在Squid和“Web网关拦截器”中实现。
Submitter: Document editors.
提交者：文档编辑器。
Best known references:
最著名的参考文献：
* "Cache Digest Specification - version 5" [21]
* “缓存摘要规范-版本5”[21]
* "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol" [10] (see note)
* “摘要缓存：一种可扩展的广域网缓存共享协议”[10]（见注释）
Description: Cache Digests are a response to the problems of latency and congestion associated with previous inter-cache communication mechanisms such as the Internet Cache Protocol (ICP) [2] and the Hyper Text Cache Protocol [9]. Unlike these protocols, Cache Digests support peering between caching proxies and cache servers without a request-response exchange taking place for each inbound request. Instead, a summary of the contents in cache (the Digest) is fetched by other systems that peer with it. Using Cache Digests it is possible to determine with a relatively high degree of accuracy whether a given resource is cached by a particular system.
描述：缓存摘要是对与以前的缓存间通信机制（如Internet缓存协议（ICP）[2]和超文本缓存协议[9]）相关的延迟和拥塞问题的响应。与这些协议不同，缓存摘要支持缓存代理和缓存服务器之间的对等，而无需为每个入站请求进行请求-响应交换。相反，缓存中内容的摘要（摘要）由与其对等的其他系统获取。使用缓存摘要，可以相对高精度地确定给定资源是否由特定系统缓存。
Cache Digests are both an exchange protocol and a data format.
缓存摘要既是一种交换协议，也是一种数据格式。
Security: If the contents of a Digest are sensitive, they should be protected. Any methods which would normally be applied to secure an HTTP connection can be applied to Cache Digests.
安全性：如果摘要的内容是敏感的，它们应该受到保护。通常用于保护HTTP连接的任何方法都可以应用于缓存摘要。
A 'Trojan horse' attack is currently possible in a mesh: System A A can build a fake peer Digest for system B and serve it to B's peers if requested. This way A can direct traffic toward/from B. The impact of this problem is minimized by the 'pull' model of transferring Cache Digests from one system to another.
目前，mesh中可能存在“特洛伊木马”攻击：系统A可以为系统B构建一个虚假的对等摘要，并根据请求将其提供给B的对等方。通过这种方式，A可以将流量引导到B/从B。通过将缓存摘要从一个系统传输到另一个系统的“拉”模型，可以将此问题的影响降至最低。
Cache Digests provide knowledge about peer cache content on a URL level. Hence, they do not dictate a particular level of policy management and can be used to implement various policies on any level (user, organization, etc.).
缓存摘要在URL级别提供有关对等缓存内容的知识。因此，它们不指定特定级别的策略管理，可以用于在任何级别（用户、组织等）上实施各种策略。
Deployment: Cache Digests are supported in Squid.
部署：Squid中支持缓存摘要。
Cache Meshes: NLANR Mesh; TF-CACHE Mesh (European Academic networks
缓存网格：NLANR网格；TF-CACHE Mesh（欧洲学术网络）
Submitter: Alex Rousskov for [21], Pei Cao for [10].
提交人：Alex Rousskov代表[21]，Pei Cao代表[10]。
Note: The technology of Summary Cache [10] is patent pending by the University of Wisconsin-Madison.
注意：摘要高速缓存技术（10）是威斯康星大学麦迪逊的专利申请。
Best known reference: "Pre-filling a cache - A satellite overview" [20] (work in progress)
最著名的参考文献：“预填充缓存-卫星概览”[20]（正在进行中）
Description: Cache pre-filling is a push-caching implementation. It is particularly well adapted to IP-multicast networks because it allows preselected resources to be simultaneously inserted into caches within the targeted multicast group. Different implementations of cache pre-filling already exist, especially in satellite contexts. However, there is still no standard for this kind of push-caching and vendors propose solutions either based on dedicated equipment or public domain caches extended with a pre-filling module.
描述：缓存预填充是一种推送缓存实现。它特别适合于IP多播网络，因为它允许预选资源同时插入到目标多播组内的缓存中。缓存预填充的不同实现已经存在，特别是在卫星环境中。然而，这种推式缓存仍然没有标准，供应商提出了基于专用设备或使用预填充模块扩展的公共域缓存的解决方案。
Security: Relies on the inter-cache protocols being employed.
安全性：依赖于所采用的缓存间协议。
Deployment: Observed in two commercial content distribution service providers.
部署：在两个商业内容分发服务提供商中观察到。
Submitter: Ivan Lovric
提交人：伊万·洛弗里克
Also see Section 6.3
另见第6.3节
Best known references:
最著名的参考文献：
* "Cache Array Routing Protocol" [14] (work in progress)
* “缓存阵列路由协议”[14]（正在进行中）
* "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]
* “缓存阵列路由协议（CARP）v1.0规范”[15]
* "Cache Array Routing Protocol and Microsoft Proxy Server 2.0" [16]
* “缓存阵列路由协议和Microsoft代理服务器2.0”[16]
Description: CARP is a hashing function for dividing URL-space among a cluster of proxies. Included in CARP is the definition of a Proxy Array Membership Table, and ways to download this information.
描述：CARP是一个散列函数，用于在代理集群中划分URL空间。CARP中包括代理数组成员表的定义，以及下载此信息的方法。
A user agent which implements CARP v1.0 can allocate and intelligently route requests for the URLs to any member of the Proxy Array. Due to the resulting sorting of requests through these proxies, duplication of cache contents is eliminated and global cache hit rates may be improved.
实现CARP v1.0的用户代理可以将URL请求分配并智能地路由到代理阵列的任何成员。由于通过这些代理对请求进行排序，消除了缓存内容的重复，并且可以提高全局缓存命中率。
Security: Security considerations are not covered in the specification works in progress.
安全：正在进行的规范工程中未包含安全注意事项。
Deployment: Implemented in caching proxy servers. More than two independent implementations.
部署：在缓存代理服务器中实现。两个以上的独立实现。
Submitter: Document editors.
提交者：文档编辑器。
This section describes the cooperation and communication between proxies and network elements. Examples of such network elements include routers and switches. Generally used for deploying interception proxies and/or diffused arrays.
本节描述代理和网元之间的协作和通信。此类网络元件的示例包括路由器和交换机。通常用于部署拦截代理和/或扩散阵列。
Best known references: "Web Cache Control Protocol" [18][19] (work in progress)
最著名的参考文献：“Web缓存控制协议”[18][19]（正在进行中）
Note: The name used for this protocol varies, sometimes referred to as the "Web Cache Coordination Protocol", but frequently just "WCCP" to avoid confusion
注意：此协议使用的名称各不相同，有时称为“Web缓存协调协议”，但通常仅为“WCCP”，以避免混淆
Description: WCCP V1 runs between a router functioning as a redirecting network element and out-of-path interception proxies. The protocol allows one or more proxies to register with a single router to receive redirected traffic. It also allows one of the proxies, the designated proxy, to dictate to the router how redirected traffic is distributed across the array.
描述：WCCP V1在作为重定向网元的路由器和路径外拦截代理之间运行。该协议允许一个或多个代理向单个路由器注册，以接收重定向的流量。它还允许其中一个代理（指定代理）向路由器指示重定向流量在阵列中的分布方式。
WCCP V2 additionally runs between multiple routers and the proxies.
WCCP V2还可以在多个路由器和代理之间运行。
Security: WCCP V1 has no security features. WCCP V2 provides optional authentication of protocol packets.
安全性：WCCP V1没有安全功能。WCCP V2提供协议数据包的可选身份验证。
Deployment: Network elements: WCCP is deployed on a wide range of Cisco routers. Caching proxies: WCCP is deployed on a number of vendors' caching proxies.
部署：网络元素：WCCP部署在广泛的Cisco路由器上。缓存代理：WCCP部署在许多供应商的缓存代理上。
Submitter: David Forster Document editors.
提交人：David Forster文档编辑器。
Best known reference: "NECP: The Network Element Control Protocol" [22] (work in progress)
最著名的参考文献：“NECP：网元控制协议”[22]（正在进行中）
Description: NECP provides methods for network elements to learn about server capabilities, availability, and hints as to which flows can and cannot be serviced. This allows network elements to perform load balancing across a farm of servers, redirection to interception proxies, and cut-through of flows that cannot be served by the farm.
描述：NECP为网络元素提供了了解服务器功能、可用性的方法，以及关于哪些流可以和哪些流不能被服务的提示。这允许网元跨服务器场执行负载平衡，重定向到拦截代理，并切断服务器场无法提供服务的流。
Security: Optionally uses HMAC-SHA-1 [11] shared secret authentication along with complex sequence numbers to provide moderately strong security. Protocol is subject to attack if authentication is not used.
安全性：可选地使用HMAC-SHA-1[11]共享秘密身份验证以及复杂序列号来提供中等强度的安全性。如果不使用身份验证，则协议会受到攻击。
Deployment: Unknown at present; several network element and caching proxy vendors have expressed intent to implement the protocol.
部署：目前未知；一些网元和缓存代理供应商已表示有意实现该协议。
Submitter: Gary Tomlinson
提交人：加里·汤姆林森
Best known reference: RFC 1928 SOCKS Protocol Version 5 [7]
最著名的参考文献：RFC 1928 SOCKS协议版本5[7]
Description: SOCKS is primarily used as a caching proxy to firewall protocol. Although firewalls don't conform to the narrowly defined network element definition above, they are a integral part of the network infrastructure. When used in conjunction with a firewall, SOCKS provides a authenticated tunnel between the caching proxy and the firewall.
描述：SOCKS主要用作防火墙协议的缓存代理。虽然防火墙不符合上面狭义定义的网元定义，但它们是网络基础设施的组成部分。当与防火墙结合使用时，SOCKS在缓存代理和防火墙之间提供经过身份验证的隧道。
Security: An extensive framework provides for multiple authentication methods. Currently, SSL, CHAP, DES, 3DES are known to be available.
安全性：广泛的框架提供了多种身份验证方法。目前已知SSL、CHAP、DES和3DE可用。
Deployment: SOCKS is widely deployed in the Internet.
部署：SOCKS广泛部署在Internet上。
Submitter: Document editors.
提交者：文档编辑器。
This document provides a taxonomy for web caching and replication. Recommended practice, architecture and protocols are not described in detail.
本文档提供了web缓存和复制的分类。未详细描述推荐的实践、体系结构和协议。
By definition, replication and caching involve the copying of resources. There are legal implications of making and keeping transient or permanent copies; these are not covered here.
根据定义，复制和缓存涉及资源的复制。制作和保存临时或永久副本会产生法律影响；这里不包括这些。
Information on security of each protocol referred to by this memo is provided in the preceding sections, and in their accompanying documentation. HTTP security is discussed in section 15 of RFC 2616 [1], the HTTP/1.1 specification, and to a lesser extent in RFC 1945 [6], the HTTP/1.0 specification. RFC 2616 contains security considerations for HTTP proxies.
本备忘录提及的每项协议的安全性信息见前述章节及其随附文件。HTTP安全性在HTTP/1.1规范RFC 2616[1]的第15节中讨论，在较小程度上在HTTP/1.0规范RFC 1945[6]中讨论。RFC2616包含HTTP代理的安全注意事项。
Caching proxies have the same security issues as other application level proxies. Application level proxies are not covered in these security considerations. IP number based authentication is problematic when a proxy is involved in the communications. Details are not discussed here.
缓存代理与其他应用程序级代理具有相同的安全问题。这些安全注意事项不包括应用程序级代理。当通信中涉及代理时，基于IP号码的身份验证存在问题。这里不讨论细节。
Requests for web resources, and responses to such requests, may be directed to replicas and/or may flow through intermediate proxies. The integrity of communication needs to be preserved to ensure protection from both loss of access and from unintended change.
对web资源的请求以及对此类请求的响应可定向到副本和/或可通过中间代理进行。需要保持通信的完整性，以确保防止访问丢失和意外更改。
HTTP proxies are men-in-the-middle, the perfect place for a man-in-the-middle-attack. A discussion of this is found in section 15 of RFC 2616 [1].
HTTP代理是中间人，是中间人攻击的完美场所。RFC 2616[1]第15节对此进行了讨论。
A proxy must either be trusted to act on behalf of the origin server and/or client, or it must act as a tunnel. When presenting cached objects to clients, the clients need to trust the caching proxy to act on behalf on the origin server.
必须信任代理以代表源服务器和/或客户端，或者代理必须充当隧道。当向客户端呈现缓存对象时，客户端需要信任缓存代理以代表源服务器。
A replica may get accreditation from the origin server.
副本可以从源服务器获得认证。
Authentication based on the client's IP number is problematic when connecting through a proxy, since the authenticating device only has access to the proxy's IP number. One (problematic) solution to this is for the proxy to spoof the client's IP number for inbound requests.
通过代理连接时，基于客户端IP号的身份验证存在问题，因为身份验证设备只能访问代理的IP号。一个（有问题的）解决方案是代理为入站请求伪造客户端的IP号。
Authentication based on IP number assumes that the end-to-end properties of the Internet are preserved. This is typically not the case for environments containing interception proxies.
基于IP号码的身份验证假定保留了Internet的端到端属性。对于包含拦截代理的环境，情况通常不是这样。
When using a replication service, one must trust both the replica origin server and the replica selection system.
使用复制服务时，必须同时信任副本源服务器和副本选择系统。
Redirection of traffic - either by automated replica selection methods, or within proxies - may introduce third parties the end user and/or origin server must to trust. In the case of interception proxies, such third parties are often unknown to both end points of the communication. Unknown third parties may have security implications.
通过自动副本选择方法或在代理内重定向流量可能会引入最终用户和/或源服务器必须信任的第三方。在拦截代理的情况下，通信的两个端点通常都不知道这样的第三方。未知的第三方可能具有安全影响。
Both proxies and replica selection services may have access to aggregated access information. A proxy typically knows about accesses by each client using it, information that is more sensitive than the information held by a single origin server.
代理和副本选择服务都可以访问聚合的访问信息。代理通常知道使用它的每个客户端的访问，这些信息比单个源服务器所持有的信息更敏感。
Logs from proxies should be kept secure, since they provide information about users and their patterns of behaviour. A proxy's log is even more sensitive than a web server log, as every request from the user population goes through the proxy. Logs from replica origin servers may need to be amalgamated to get aggregated statistics from a service, and transporting logs across borders may have legal implications. Log handling is restricted by law in some countries.
来自代理的日志应该保持安全，因为它们提供有关用户及其行为模式的信息。代理的日志甚至比web服务器日志更敏感，因为来自用户群的每个请求都要通过代理。可能需要合并来自副本源服务器的日志，以从服务中获得聚合统计信息，并且跨国界传输日志可能具有法律意义。在一些国家，日志处理受到法律的限制。
Requirements for object security and privacy are the same in a web replication and caching system as it is in the Internet at large. The only reliable solution is strong cryptography. End-to-end encryption frequently makes resources uncacheable, as in the case of SSL encrypted web sessions.
web复制和缓存系统中对对象安全性和隐私的要求与整个Internet中的要求相同。唯一可靠的解决方案是强加密。端到端加密经常使资源不可缓存，例如SSL加密的web会话。
Any redirection of traffic is susceptible to denial of service attacks at the redirect point, and both proxies and replica selection services may redirect traffic.
任何流量重定向都容易在重定向点受到拒绝服务攻击，代理和副本选择服务都可能重定向流量。
By attacking a proxy, access to all servers may be denied for a large set of clients.
通过攻击代理，可能会拒绝大量客户端对所有服务器的访问。
It has been argued that introduction of an interception proxy is a denial of service attack, since the end-to-end nature of the Internet is destroyed without the content consumer's knowledge.
有人认为，引入拦截代理是一种拒绝服务攻击，因为互联网的端到端性质在内容消费者不知情的情况下被破坏。
A caching proxy is by definition a replay attack.
根据定义，缓存代理是重播攻击。
It is quite easy to have a stupid configuration which will harm service for content consumers. This is the most common security problem with proxies.
很容易出现愚蠢的配置，这将损害内容消费者的服务。这是代理最常见的安全问题。
The legislative forces of the world are considering the question of transient copies, like those kept in replication and caching system, being legal. The legal implications of replication and caching are subject to local law.
全世界的立法力量都在考虑暂时拷贝的问题，比如那些保存在复制和缓存系统中的拷贝，是否合法。复制和缓存的法律影响受当地法律约束。
Caching proxies need to preserve the protocol output, including headers. Replication services need to preserve the source of the objects.
缓存代理需要保留协议输出，包括头。复制服务需要保留对象的源。
Caching proxies are application level components in the traffic flow path, and may give intruders access to information that was previously only available at the network level in a proxy-free world. Some network level equipment may have required physical access to get sensitive information. Introduction of application level components may require additional system security.
缓存代理是流量路径中的应用程序级组件，可以让入侵者访问以前只有在无代理世界中的网络级可用的信息。某些网络级设备可能需要物理访问才能获取敏感信息。引入应用程序级组件可能需要额外的系统安全性。
The editors would like to thank the following for their assistance: 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, Larry Masinter, Keith Moore, Roy Fielding, Patrik Faltstrom, Hilarie Orman, Mark Nottingham and Oskar Batuner.
编辑们要感谢以下各方的帮助：大卫·福斯特、亚历克斯·罗斯科夫、乔什·科恩、约翰·马丁、约翰·迪利、伊万·洛弗里克、乔·图奇、亨里克·诺德斯特罗姆、帕特里克·麦克马纳斯、杜安·韦塞尔、沃杰克·西尔维斯特扎克、泰德·哈代、米莎·拉比诺维奇、拉里·马斯滕、基思·摩尔、罗伊·菲尔丁、帕特里克·法茨特罗姆、希拉里·奥曼、，马克·诺丁汉和奥斯卡·巴图纳。
References
工具书类
[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.
[1] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[2] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997.
[2] Wessels，D.和K.Claffy，“互联网缓存协议（ICP），第2版”，RFC2186，1997年9月。
[3] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), Version 2", RFC 2187, September 1997.
[3] Wessels，D.和K.Claffy，“互联网缓存协议（ICP）的应用，第2版”，RFC 2187，1997年9月。
[4] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[4] Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准9，RFC 959，1985年10月。
[5] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, "The Internet Gopher Protocol", RFC 1436, March 1993.
[5] Anklesaria，F.，McCahill，M.，Lindner，P.，Johnson，D.，Torrey，D.和B.Alberti，“互联网地鼠协议”，RFC 1436，1993年3月。
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[6] Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[7] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[7] Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.和L.Jones，“SOCKS协议版本5”，RFC 19281996年3月。
[8] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[8] Brisco，T.，“DNS对负载平衡的支持”，RFC 1794，1995年4月。
[9] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000.
[9] Vixie，P.和D.Wessels，“超文本缓存协议（HTCP/0.0）”，RFC 2756，2000年1月。
[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.
[10] Fan，L.，Cao，P.，Almeida，J.和A.Broder，“摘要缓存：一种可扩展的广域网缓存共享协议”，ACM SIGCOMM'98论文集，第254-265页，1998年9月。
[11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[11] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[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>.
[12] Netscape，Inc.，“导航器代理自动配置文件格式”，1996年3月，<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.
[13] Gauthier，P.，Cohen，J.，Dunsmuir，M.和C.Perkins，“Web代理自动发现协议”，正在进行中。
[14] Valloppillil, V. and K. Ross, "Cache Array Routing Protocol", Work in Progress.
[14] Valloppill，V.和K.Ross，“缓存阵列路由协议”，正在进行中。
[15] Microsoft Corporation, "Cache Array Routing Protocol (CARP) v1.0 Specifications, Technical Whitepaper", August 1999, <URL:http://www.microsoft.com/Proxy/Guide/carpspec.asp>.
[15] 微软公司，“缓存阵列路由协议（CARP）v1.0规范，技术白皮书”，1999年8月，<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>.
[16] 微软公司，“缓存阵列路由协议和微软代理服务器2.0，技术白皮书”，1998年8月，<URL:http://www.microsoft.com/proxy/documents/CarpWP.exe>.
[17] Lovric, I., "Internet Cache Protocol Extension", Work in Progress.
[17] Lovric，I.，“互联网缓存协议扩展”，正在进行中。
[18] Cieslak, M. and D. Forster, "Cisco Web Cache Coordination Protocol V1.0", Work in Progress.
[18] Cieslak，M.和D.Forster，“Cisco Web缓存协调协议V1.0”，正在进行中。
[19] Cieslak, M., Forster, D., Tiwana, G. and R. Wilson, "Cisco Web Cache Coordination Protocol V2.0", Work in Progress.
[19] Cieslak，M.，Forster，D.，Tiwana，G.和R.Wilson，“Cisco Web缓存协调协议V2.0”，正在进行中。
[20] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a cache - A satellite overview", Work in Progress.
[20] Goutard，C.，Lovric，I.和E.Maschio Esposito，“预填充缓存-卫星概览”，工作正在进行中。
[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>.
[21] Hamilton，M.，Rousskov，A.和D.Wessels，“缓存摘要规范-第5版”，1998年12月，<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.
[22] Cerpa，A.，Elson，J.，Beheshti，H.，Chankhunthod，A.，Danzig，P.，Jalan，R.，Neerdaels，C.，Shroeder，T.和G.Tomlinson，“NECP：网元控制协议”，正在进行中。
[23] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", Work in Progress.
[23] Cooper，I.和J.Dilley，“已知的HTTP代理/缓存问题”，正在进行中。
Authors' Addresses
作者地址
Ian Cooper Equinix, Inc. 2450 Bayshore Parkway Mountain View, CA 94043 USA
Ian Cooper Equinix，Inc.美国加利福尼亚州海岸公园山景城2450号，邮编94043
Phone: +1 650 316 6065
EMail: icooper@equinix.com
Phone: +1 650 316 6065
EMail: icooper@equinix.com
Ingrid Melve UNINETT Tempeveien 22 Trondheim N-7465 Norway
英格丽德·梅尔夫·尤尼特·坦佩维安22挪威特隆赫姆N-7465
Phone: +47 73 55 79 07
EMail: Ingrid.Melve@uninett.no
Phone: +47 73 55 79 07
EMail: Ingrid.Melve@uninett.no
Gary Tomlinson CacheFlow Inc. 12034 134th Ct. NE, Suite 201 Redmond, WA 98052 USA
加里·汤姆林森CacheFlow公司，邮编：12034，第134届Ct。美国华盛顿州雷德蒙市东北201室，邮编：98052
Phone: +1 425 820 3009
EMail: gary.tomlinson@cacheflow.com
Phone: +1 425 820 3009
EMail: gary.tomlinson@cacheflow.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。