[要約] RFC 3040は、インターネットのウェブレプリケーションとキャッシュの分類に関するものであり、その目的は、異なるキャッシュアーキテクチャの分類と比較を提供することです。
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
インターネット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.
Copyright（c）The Internet Society（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
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は、単純なクライアントサーバーモデルから複雑な分散アーキテクチャに進化してきました。この進化は、主に指数関数的な成長に関連するスケーリングの問題のために駆動されてきました。特定の要件を満たすために、明確なパラダイムとソリューションが登場しています。この成長の需要を満たすために採用されている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.
また、このドキュメントは、レプリカとキャッシュの両方を含む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]から取得され、参照のためにここに含まれています。この領域内に存在する関係を定義するのに役立つ1次および2次導関数は、これらの基本用語から構築されます。
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]から取得）応答を送信してリクエストをサービスするために接続を受け入れるアプリケーションプログラム。特定のプログラムは、クライアントとサーバーの両方になることができる場合があります。これらの用語の使用とは、プログラムの機能全般ではなく、特定の接続に対してプログラムによって実行される役割のみを指します。同様に、すべてのサーバーは、各リクエストの性質に基づいて、Origin Server、Proxy、Gateway、またはTunnelとして機能し、スイッチング動作として機能します。
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]から取得）他のサーバーの仲介者として機能するサーバー。プロキシとは異なり、ゲートウェイは要求されたリソースのOrigin Serverであるかのようにリクエストを受信します。要求するクライアントは、ゲートウェイと通信していることを認識していない場合があります。
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]から取られた）インバウンドとアウトバウンドは、メッセージのリクエストと応答パスを指します。「インバウンド」は「Origin Serverに向かって移動する」を意味し、「アウトバウンド」は「ユーザーエージェントに向かって移動する」を意味します。
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.
Origin Server（[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.
SURROGATE ORIGIN SERVERまたはネットワーク内の異なるポイントで共同住宅を交換し、1つ以上のOriginサーバーの代わりに運用し、通常は緊密な協力に取り組む権限を委任しました。通常、応答は内部キャッシュから配信されます。
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.
Surrogatesは、Origin ServerまたはOrigin Serverの代表者の別のサーバーからキャッシュエントリを導き出すことができます。場合によっては、代理人がそのような要求をトンネルすることがあります。
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.
Origin ServersとSurrogatesの間に密接な協力が存在する場合、これにより[1]のキャッシュ制御指令を含むいくつかのプロトコル要件の変更が可能になります。 このような変更はまだ完全に指定されていません。
Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as surrogates.
一般的に「リバースプロキシ」と「（Origin）サーバーアクセラレータ」と呼ばれるデバイスは、どちらもサロゲートとしてより適切に定義されています。
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.
Master Origin Serverリソースの決定的なバージョンが存在するOrigin Server。
replica origin server An origin server holding a replica of a resource, but which may act as an authoritative reference for client requests.
Replica Origin Serverリソースのレプリカを保持しているOrigin Serverですが、クライアントリクエストの権威ある参照として機能する場合があります。
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".
キャッシュ配列は、プロキシをキャッシュするクラスターをキャッシュし、論理的に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.
キャッシュメッシュメッシュ協力的なプロキシおよび（オプションでは）キャッシュサーバー、またはクラスターのゆるく結合したセットは、独立して行動しますが、キャッシュ間コミュニケーションプロトコルを使用して自分の間でキャッシュ可能なコンテンツを共有します。
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.
自動ユーザーエージェントプロキシ構成1つ以上のプロキシの可用性と、それらを使用するユーザーエージェントの自動構成を発見する手法。プロキシの使用は、コンテンツコンシューマーに対しては透明ですが、ユーザーエージェントに対しては透明です。この意味で「自動プロキシ構成」という用語も使用されます。
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.)
クライアントは、1つ以上のレプリカ起源サーバーと、マスターオリジンサーバーと通信する場合があります。（レプリカサーバーがない場合、クライアントは通常のケースと同様にOrigin Serverと直接対話します。）
------------------ ----------------- ------------------
| 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.
クライアントがレプリカの1つを使用できるようにするために使用されるプロトコルは、セクション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に示されている関係でクライアントがアクセスするデータセットを複製するために、Master Origin ServerとReplica Origin Serversの関係です。
------------------ ----------------- ------------------
| 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).
クライアントは、一部またはすべてのリクエストについて、ゼロ以上のプロキシと通信する場合があります。通信の結果がプロキシを使用しない場合、関係はクライアントと（レプリカ）Origin Serverの間にあります（セクション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 Serverと直接通信します。サロゲートが使用される場合、クライアントはOrigin Serverを使用して通信します。サロゲートは、内部キャッシュからの要求を満たすか、Origin Serverへのゲートウェイまたはトンネルとして機能します。
-------------- -------------- --------------
| 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のいずれかに存在する場合にのみ使用できます。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 |----- ^ ^
--------------------- ^ ^ | |
^ ^ | |--- |
| |----- |
--------------------------
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.)
トラフィックインターセプトを実行するネットワーク要素は、クライアントからアレイ内の特定のプロキシにリクエストをリダイレクトすることを選択できます。（トラフィックをリダイレクトしないことも選択できます。その場合、関係はクライアントと（レプリカ）Origin Serverの間です。セクション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.
インターセプトプロキシは、トラフィックの流れの直接的なインラインである可能性があります。その場合、ネットワーク要素と傍受プロキシフォームパーツの部分を同じハードウェアシステムの部分 - またはパス外である可能性があります。別のネットワークセグメントへ。この後者の場合、通信プロトコルにより、インターセプトプロキシが利用可能になったときに、インターセプトネットワーク要素を停止およびリダイレクトのリダイレクトを開始できます。これらのプロトコルの詳細は、セクション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ページに埋め込まれたハイパーリンクURISを使用します。コンテンツコンシューマーは、使用したいReplica Origin Serverのリンクを手動で選択します。
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 "FOUND"、または307「一時リダイレクト」を使用して、最適なレプリカ起源サーバーにリダイレクトされます。クライアントは、Replica Origin Serverの1つとHTTP通信を確立します。最初に連絡されたReplica Origin Serverは、サービスを受け入れるか、クライアントをリダイレクトすることを選択できます。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.
展開：多くの大規模な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サーバーによって実現されます。クライアントがOrigin Serverの名前を解決すると、拡張された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.
このセクションでは、マスターとレプリカオリジンのサーバー間の協力とコミュニケーションについて説明します。Origin Server間のデータセットの複製で使用されます。
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.
説明：更新されるレプリカ起源サーバーは、Master Origin Serverとの通信を開始します。通信は、延期された処理が予定されているキューに基づいた間隔で確立されます。スケジューリングメカニズムのポリシーはさまざまですが、通常、指定された時間に再発生しています。通信が確立されると、データセットが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.
説明：レプリカ起源サーバーは、クライアントの需要のために必要に応じてコンテンツを取得します。クライアントがReplica Origin Server/Surrogateのデータセットにないリソースを要求すると、Master Origin Serverからリソースを取得してリクエストクライアントに返すことにより、リクエストを解決する試みが行われます。
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.
展開：いくつかの大規模なWebサイトで観察されます。インターネットでの使用程度は不明です。
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）と、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]
最もよく知られている参照：「ナビゲータープロキシAutoConfigファイル形式」[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.
説明：Webサーバーから取得した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]
* 「キャッシュアレイルーティングプロトコル（car）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.
展開：Microsoft Proxy Server、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は、既存のインターネットリソース発見メカニズムのコレクションを使用して、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
* 動的ホスト構成プロトコルDHCP
* Service Location Protocol SLP
* サービスロケーションプロトコルSLP
* "Well Known Aliases" using DNS A records
* DNS A Recordsを使用した「よく知られているエイリアス」
* 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.
展開：一部のユーザーエージェントとキャッシュプロキシサーバーに実装されています。2つ以上の独立した実装。
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は、プロキシによって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)
参照：「インターネットキャッシュプロトコル拡張」[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 Gateway Interceptor」に実装されています。
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キャッシュ共有プロトコル」[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は、システムBの偽のピアダイジェストを構築し、要求された場合に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.
展開：キャッシュダイジェストはイカでサポートされています。
Cache Meshes: NLANR Mesh; TF-CACHE Mesh (European Academic networks
キャッシュメッシュ：NLANRメッシュ。TFキャッシュメッシュ（欧州アカデミックネットワーク
Submitter: Alex Rousskov for [21], Pei Cao for [10].
提出者：[21]のAlex Rousskov、[10]のPEI CAO。
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-Multicastネットワークに特に適合しています。特に衛星コンテキストでは、キャッシュの事前充填のさまざまな実装がすでに存在しています。ただし、この種のプッシュキャッシングについてはまだ標準はありません。ベンダーは、専用の機器や、事前に埋めるモジュールで拡張されたパブリックドメインキャッシュに基づいてソリューションを提案しています。
Security: Relies on the inter-cache protocols being employed.
セキュリティ：採用されているキャッシュ間プロトコルに依存しています。
Deployment: Observed in two commercial content distribution service providers.
展開：2つの商用コンテンツ配信サービスプロバイダーで観察されます。
Submitter: Ivan Lovric
提出者：Ivan Lovric
Also see Section 6.3 Best known references:
また、セクション6.3の最もよく知られている参照を参照してください。
* "Cache Array Routing Protocol" [14] (work in progress)
* 「キャッシュアレイルーティングプロトコル」[14]（進行中の作業）
* "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]
* 「キャッシュアレイルーティングプロトコル（car）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.
展開：キャッシュプロキシサーバーに実装されています。2つ以上の独立した実装。
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は、リダイレクトネットワーク要素として機能するルーターと、パス外のインターセプトプロキシの間を実行します。このプロトコルにより、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.
提出者：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ソックスプロトコルバージョン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.
説明：ソックスは、主にファイアウォールプロトコルへのキャッシュプロキシとして使用されます。ファイアウォールは、上記の狭く定義されたネットワーク要素定義に準拠していませんが、ネットワークインフラストラクチャの不可欠な部分です。ファイアウォールと組み合わせて使用する場合、ソックスはキャッシュプロキシとファイアウォールの間に認証されたトンネルを提供します。
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.
展開：ソックスはインターネットに広く展開されています。
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 [1]のセクション15、HTTP/1.1仕様、およびRFC 1945 [6]、HTTP/1.0仕様ではそれほどではありません。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プロキシは中間の男性であり、中間の攻撃に最適な場所です。これの議論は、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.
プロキシは、Origin Serverおよび/またはクライアントに代わって行動することを信頼する必要があります。または、トンネルとして機能する必要があります。キャッシュされたオブジェクトをクライアントに提示するとき、クライアントは、Origin Serverに代わって行動するためにキャッシュプロキシを信頼する必要があります。
A replica may get accreditation from the origin server.
レプリカは、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.
レプリケーションサービスを使用する場合、Replica Origin ServerとReplica選択システムの両方を信頼する必要があります。
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.
プロキシとレプリカ選択サービスの両方が、集約されたアクセス情報にアクセスできる場合があります。通常、プロキシは、各クライアントが使用しているアクセスについて知っています。これは、単一のOriginサーバーが保持している情報よりも感度が高い情報です。
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レプリケーションとキャッシュシステムで同じです。唯一の信頼できるソリューションは、強力な暗号化です。エンドツーエンドの暗号化は、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.
編集者は、デビッド・フォースター、アレックス・ルウスコフ、ジョシュ・コーエン、ジョン・マーティン、ジョン・ディリー、イヴァン・ロブリック、ジョー・タッチ、ヘンリック・ノードストロム、パトリック・マクマナス、デュアン・ウェッセル、ウォジテク・シルウェストルザック、テッド・ハーディー、ミシャ・ラビノヴィッチ、Larry Masinter、Keith Moore、Roy Fielding、Patrik Faltstrom、Hilarie Orman、Mark Nottingham、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、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」、RFC 2186、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）」、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.、Lindner、P.、Johnson、D.、Torrey、D.およびB. Alberti、「The Internet Gopher Protocol」、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。and H. Frystyk、「HyperText Transfer Protocol-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 Protocolバージョン5」、RFC 1928、1996年3月。
[8] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[8] Brisco、T。、「Load Balancingの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、「Hyper Text Caching Protocol（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 Sigcomm98pp。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：メッセージ認証のためのキードハッシング」、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] Netscape、Inc。、「Navigator Proxy auto-configファイル形式」、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 Proxy Auto-Discovery Protocol」、進行中の作業。
[14] Valloppillil, V. and K. Ross, "Cache Array Routing Protocol", Work in Progress.
[14] Valloppillil、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] Microsoft Corporation、「キャッシュアレイルーティングプロトコル（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 Corporation、「キャッシュアレイルーティングプロトコルとMicrosoft Proxy Server 2.0、Technical White Paper」、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。and D. Forster、「Cisco Web Cache Cache Coordination Protocol 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 Cache Cache Coordination Protocol V2.0」、Work in Progress。
[20] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a cache - A satellite overview", Work in Progress.
[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。and D. Wessels、「Cache Digest仕様 - バージョン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。and 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 Bayshore Parkway Mountain View、CA 94043 USA
Phone: +1 650 316 6065
EMail: icooper@equinix.com
Ingrid Melve UNINETT Tempeveien 22 Trondheim N-7465 Norway
Ingrid Melve Uninett Tempeveien 22 Trondheim N-7465ノルウェー
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
Gary Tomlinson Cacheflow Inc. 12034 134th Ct。NE、スイート201レドモンド、ワシントン州98052 USA
Phone: +1 425 820 3009
EMail: gary.tomlinson@cacheflow.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。