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
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.
今日の展開として、このメモは標準的な用語やウェブ複製およびキャッシングインフラの分類を指定します。これは、このアプリケーションドメイン内で、今日使用される標準的な概念、およびプロトコルを紹介します。これらの技術を採用し、現在展開ソリューションは、標準的な分類法を確立するために提示されています。キャッシングプロキシとの既知の問題は、「既知の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
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年の導入以来、ワールド・ワイド・ウェブは、複雑な分散アーキテクチャに簡単なクライアントサーバモデルから進化してきました。この進化は、主に、指数関数的な成長に関連したスケーリングの問題に駆動されました。明確なパラダイムとソリューションは、特定の要件を満たすために浮上しています。この成長の需要を満たすために採用されている2つのコアインフラストラクチャコンポーネントは、レプリケーションとキャッシュされています。多くの場合、共存することができるようにする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.
このメモは標準的な用語、今日インターネット上に配備された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.
また、この文書はレプリカとキャッシュの両方を含んでいるウェブで、効率的で信頼性の高い、かつ予測可能なサービスのための標準的なアーキテクチャ・フレームワークの作成に使用されることが期待されます。
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.
今日のウェブ複製およびキャッシュに採用オープンと独自の両方の多くのプロトコルは、あります。オープンプロトコルの大部分は、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複製およびキャッシングコミュニティ内で使用される一般的な用語の定義を提供します。基地用語は、[1] HTTP / 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]から取られた）キャッシュ可能。 HTTPレスポンスのキャッシュ可能性を決定するためのルールは、リソースがキャッシュ可能である場合でも、セクション13で定義され、キャッシュが特定の要求のためにキャッシュされたコピーを使用できるかどうかに追加の制約があってもよいです。
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]から取られた）2つの接続間のブラインドリレーとして動作している仲介プログラム。トンネルは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]から取られた）ユーザエージェント。これらは、しばしばブラウザ、エディタ、クモ（ウェブ横断ロボット）、または他のエンドユーザツールです。
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.
オリジンサーバと同じ場所に配置代理ゲートウェイ、またはネットワーク内の別のポイントで、代わって操作する権限を委譲し、通常、1つまたは複数のオリジンサーバとの緊密な協力で働きます。応答は、典型的には、内部キャッシュから配信されています。
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.
コンテンツの消費者のためのコンテンツ提示装置として機能し、ユーザエージェントのブラウザA特別なインスタンス。
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".
キャッシュアレイのキャッシュプロキシのクラスタ、1つのサービスとして論理的に作用し、アレイ間でのリソースの名前空間を分割します。また、「拡散配列」または「キャッシュ・クラスタ」として知られています。
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.
キャッシングは、独立して作用するが、キャッシュ間の通信プロトコルを使用して、自身の間でキャッシュ可能なコンテンツを共有し、proxy-協働及び（任意に）キャッシュ・サーバ、またはクラスタの疎結合集合をメッシュ。
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 |
-----------------
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に示すような関係にクライアントによってアクセスされるデータセットを複製するために、マスターオリジンサーバ（S）及び複製オリジンサーバとの間の関係です。
------------------ ----------------- ------------------
| 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 |
-----------------
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.
クライアントは、1つまたは複数のオリジンサーバに対する要求のために、ゼロ以上の代理と通信することができます。サロゲートを使用しない場合は、クライアントはオリジンサーバと直接通信します。サロゲートを使用する場合、クライアントはオリジンサーバと通信しているかのよう。サロゲートは、その内部キャッシュからの要求を満たす、またはオリジンサーバへのゲートウェイまたはトンネルとして機能します。
-------------- -------------- --------------
| 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.
（キャッシュ）プロキシの疎結合メッシュ内に、通信は、ピア間で同じレベルで起こり、および1つまたは複数の親を持つことができます。
--------------------- ---------------------
-----------| 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.
インバウンド要求は、その親が要求を解決するに適しているかどうかの決意に基づいて、中間体（キャッシュ）プロキシのうちの1つにルーティングすることができます。
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＆DとA＆Eとの間の関係はまた、DまたはEが非キャッシング・プロキシである場合に適切であるがA＆Bとの間の関係のみ、キャッシング環境で理にかなっています。
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 |----- ^ ^
--------------------- ^ ^ | |
^ ^ | |--- |
| |----- |
--------------------------
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 |
------------
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.
その場合、インターセプトネットワーク要素と同一のハードウェアシステムの傍受プロキシ形部に - - 傍受プロキシはインライントラフィックの流れの直接的であってもよいし、アウトオブパスであってもよいし、トラフィックをリダイレクトするためにインターセプトネットワーク要素を必要とします別のネットワークセグメントに。後者の場合、通信プロトコルが停止して傍受プロキシは（UN）が利用可能になったときにトラフィックをリダイレクト開始するインターセプトネットワーク要素を有効にします。これらのプロトコルの詳細については、セクション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.
説明：レプリカ通信メカニズムへのクライアントの最も簡単。これは、個々のレプリカ発生源サーバをポイントするWebページに埋め込まれたハイパーリンクの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応答コードについては、[1] HTTP / 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.
展開：大規模なWebサイトの数で観測。インターネットでの使用の程度は不明です。
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 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.
説明：ドメインネームサービス（DNS）は、レプリカ通信機構により洗練されたクライアントを提供します。これは、ソートサービスポリシーの品質に基づいてIPアドレスを解決DNSサーバによって達成されます。クライアントはオリジンサーバの名前を解決すると、強化された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.
展開：大規模なWebサイトや大規模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.
このセクションでは、マスター - とreplica-オリジンサーバ間の協力とコミュニケーションを説明しています。オリジンサーバ間のデータ・セットを複製に使用されます。
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.
展開：インターネットでのミラーサイトの同期のための非常に一般的。
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]、ゴーファー[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.
注：編集者は、少なくとも2つのオープンソースのプロトコルを知っている - AFSとCODA - ならびにノベルから独自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.
説明：ウェブサーバから取得するJavaScriptスクリプトがリソースにアクセスするために使用される適切なプロキシ（もしあれば）を決定するためにアクセス各URLに対して実行されます。ユーザエージェントは、起動時にこのスクリプトを要求するように設定する必要があります。何のブートストラップメカニズムは、手動設定が必要である、ありません。
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 configuration" since PAC administrators may update the proxy configuration without further user intervention.
セキュリティ：一般的な可能性、組織ごとのポリシーが、まだ初期の手動設定が必要です。 PACは、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 Proxy Server 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.
展開：マイクロソフトProxyサーバ、イカで実装されています。 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は、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
*ウェブプロキシ自動検出の特定の目的のために、各メカニズムを使用する方法
* 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
*動的ホスト構成プロトコルDHCP
* Service Location Protocol SLP
*サービスロケーションプロトコル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]
最もよく知られている参照：RFC 2186インターネットキャッシュプロトコル（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は、要求されたリソースは、他のシステム上に存在しているかどうかを確認するために、ウェブリソースに関する他の（キャッシング）プロキシを照会するためにプロキシによって使用されます。
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]
セキュリティ：[3] RFC 2187を参照してください。
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)
参照：「インターネットキャッシュ・プロトコル拡張」[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要求はICPv2はないが、HTCPを有効にすると、より正確に同じリソースの後続のHTTP要求の結果として生じる挙動を記述するのに応答し、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はイカと「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)
*「要約キャッシュ：スケーラブルな広域のWeb Cacheの共有プロトコル」[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.
説明：キャッシュダイジェストは、待ち時間と、インターネットキャッシュプロトコル（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.
「トロイの木馬」攻撃がメッシュに現在可能です：システムA Aは、システムBのために偽のピアダイジェストを作成し、要求された場合Bのピアにそれを提供することができます。 Aは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のメッシュ（欧州の学術ネットワーク
Submitter: Alex Rousskov for [21], Pei Cao for [10].
投稿者：[21]のためにアレックスRousskov、[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.
展開：2つの商用コンテンツ配信サービスプロバイダで観測されました。
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 Proxy Server 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)
最もよく知られている参照：「ウェブキャッシュ制御プロトコル」[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はリダイレクトネットワーク要素とアウトオブパス傍受プロキシとしてルータ機能との間で実行されます。プロトコルは、単一のルータに登録するための1つ以上のプロキシがリダイレクトされたトラフィックを受信することができます。また、リダイレクトされたトラフィックは、アレイ全体に分散された方法をルータに指示するプロキシの1つ、指定されたプロキシを、ことができます。
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.
投稿者：デビッド・フォスタードキュメントの編集者。
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、3DESが利用可能であることが知られています。
Deployment: SOCKS is widely deployed in the Internet.
展開：SOCKSは、インターネットで広く展開されています。
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のセキュリティは、RFC 2616のセクション15 [1]は、HTTP / 1.1仕様、及び[6]、HTTP / 1.0仕様RFC 1945年より少ない程度で議論されています。 RFC 2616は、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プロキシは、男性・イン・ザ・ミドル、のman-in-the-middle攻撃のための最適な場所です。この議論は、RFC 2616のセクション15に見出される[1]。
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番号に基づいて認証には問題があります。これに対する1つの（問題の）解決策は、インバウンド要求に対するクライアントの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番号に基づいて認証がインターネットのエンド・ツー・エンドのプロパティが保存されていることを前提としています。これは、一般的に傍受プロキシを含む環境の場合はそうではありません。
When using a replication service, one must trust both the replica origin server and the replica selection system.
レプリケーションサービスを使用する場合は、1レプリカオリジンサーバとレプリカ選択システムの両方を信頼する必要があります。
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.
それは大でインターネットにあるように、オブジェクトのセキュリティとプライバシーのための要件は、ウェブ複製およびキャッシュ・システムで同じです。唯一の信頼性の高いソリューションは、強力な暗号化技術です。エンドツーエンドの暗号化は、頻繁に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.
編集者は、彼らの支援のために次のことを感謝したいと思います：デヴィッド・フォースター、アレックスRousskov、ジョシュ・コーエン、ジョン・マーティン、ジョン・ディリー、イヴァン・ラブリック、ジョー・タッチ、ヘンリクノードストローム、パトリック・マクマナス、デュアン・ウェッセル、WojtekさんSylwestrzak、テッドハーディー、ミーシャRabinovich 、ラリーMasinter、キースムーア、ロイ・フィールディング、パトリックFaltstrom、ヒラリーオーマン、マーク・ノッティンガムとオスカー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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[2] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997.
[2]ウェッセル、D.及びK. Claffy、 "インターネットキャッシュプロトコル（ICP）、バージョン2"、RFC 2186、1997年9月。
[3] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), Version 2", RFC 2187, September 1997.
[3]ウェッセル、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]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル（FTP）"、STD 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.、リンドナー、P.、ジョンソン、D.、トーリー、D.およびB.アルベルティ、 "インターネットゴーファープロトコル"、RFC 1436、1993年3月。
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[6]バーナーズ=リー、T.、フィールディング、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]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。
[8] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[8]ブリスコ、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.ウェッセルズ、 "ハイパーテキスト・キャッシングプロトコル（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]ファン、L.、曹操、P.、アルメイダ、J.およびA.ブローダー、 "要約キャッシュ：スケーラブルな広域のWeb Cacheの共有プロトコル"、ACM SIGCOMM'98 PPの議事録254から265、9月。 1998。
[11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[11] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、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]ネットスケープ社、 "ナビゲータープロキシ自動設定ファイルフォーマット"、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]ゴーティエ、P.、コーエン、J.、ダンスミア、M.とC.パーキンス、 "Webプロキシ自動検出プロトコル"、ProgressのWork。
[14] Valloppillil, V. and K. Ross, "Cache Array Routing Protocol", Work in Progress.
[14] Valloppillil、V.およびK.ロス、 "キャッシュアレイルーティングプロトコル"、ProgressのWork。
[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]マイクロソフトコーポレーション、 "キャッシュアレイルーティングプロトコルおよびMicrosoft Proxy Server 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.フォスター、 "シスコの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.、フォースター、D.、Tiwana、G.およびR.ウィルソン、 "シスコの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-エスポジト、 "事前充填キャッシュ - 衛星の概要"、ProgressのWork。
[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]ハミルトン、M.、Rousskov、A.とD.ウェッセル、 "キャッシュダイジェスト仕様 - バージョン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.、エルソン、J.、Beheshti、H.、Chankhunthod、A.、ダンツィヒ、P.、ジャラン、R.、Neerdaels、C.、Shroeder、T.とG.トムリンソン、「NECP。ネットワーク要素制御プロトコル」が進行中で働いています。
[23] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", Work in Progress.
[23]クーパー、I.およびJ.ディリー、 "既知のHTTPプロキシ/キャッシュ問題"、ProgressのWork。
Authors' Addresses
著者のアドレス
Ian Cooper Equinix, Inc. 2450 Bayshore Parkway Mountain View, CA 94043 USA
イアン・クーパーエクイニクス社2450ベイショアパークウェイマウンテンビュー、CA 94043 USA
Phone: +1 650 316 6065 EMail: icooper@equinix.com
電話：+1 650 316 6065 Eメール：icooper@equinix.com
Ingrid Melve UNINETT Tempeveien 22 Trondheim N-7465 Norway
イングリッドMelve UNINETT Tempeveien 22トロンハイムN-7465ノルウェー
Phone: +47 73 55 79 07 EMail: Ingrid.Melve@uninett.no
電話：+47 73 55 79 07 Eメール：Ingrid.Melve@uninett.no
Gary Tomlinson CacheFlow Inc. 12034 134th Ct. NE, Suite 201 Redmond, WA 98052 USA
ゲイリー・トムリンソンCacheFlow Inc.の12034 134番目のCt。 NE、スイート201レドモンド、WA 98052 USA
Phone: +1 425 820 3009 EMail: gary.tomlinson@cacheflow.com
電話：+1 425 820 3009 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。