RFC3040 日本語訳
3040 Internet Web Replication and Caching Taxonomy. I. Cooper, I.Melve, G. Tomlinson. January 2001. (Format: TXT=63257 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group I. Cooper
Request for Comments: 3040 Equinix, Inc.
Category: Informational I. Melve
UNINETT
G. Tomlinson
CacheFlow Inc.
January 2001
コメントを求めるワーキンググループI.桶屋要求をネットワークでつないでください: 3040年のEquinix Inc.カテゴリ: 情報のI.のMelve UNINETT G.トムリンスンCacheFlow株式会社2001年1月
Internet Web Replication and Caching Taxonomy
インターネットウェブ模写と分類学をキャッシュすること。
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 2.1基地のTerms. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2Firstは.72.4のTopological用語. . . . . . . . . . . . . . . . . . . . 7 2.5Automaticが使用するプロキシ. . . . . . . . . . . . . . . . . 8 3の.62.3個のSecondオーダー派生物を派生している用語に注文します。 分散システム関係. . . . . . . . . . . . . 9 3.1模写関係、.93.1、.1クライアント、レプリカ. . . . . . . . . . . . . . . . . . . . 9 3.1.2相互レプリカ.93.2、プロキシ関係、.103.2、.1クライアント、非妨害プロキシ. . . . . . . . . . . . . 10
Cooper, et al. Informational [Page 1] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[1ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
3.2.2 Client to Surrogate to Origin Server . . . . . . . . . . . 10
3.2.3 Inter-Proxy . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 11
3.2.3.2 (Caching) Proxy Arrays . . . . . . . . . . . . . . . . . . 12
3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 12
4. Replica Selection . . . . . . . . . . . . . . . . . . . . 13
4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 13
4.2 Replica HTTP Redirection . . . . . . . . . . . . . . . . . 14
4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 14
5. Inter-Replica Communication . . . . . . . . . . . . . . . 15
5.1 Batch Driven Replication . . . . . . . . . . . . . . . . . 15
5.2 Demand Driven Replication . . . . . . . . . . . . . . . . 16
5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 16
6. User Agent to Proxy Configuration . . . . . . . . . . . . 17
6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 17
6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 17
6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 18
6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 18
7. Inter-Proxy Communication . . . . . . . . . . . . . . . . 19
7.1 Loosely coupled Inter-Proxy Communication . . . . . . . . 19
7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 19
7.1.2 Hyper Text Caching Protocol . . . . . . . . . . . . . . . 20
7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 22
7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 22
7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 22
8. Network Element Communication . . . . . . . . . . . . . . 23
8.1 Web Cache Control Protocol (WCCP) . . . . . . . . . . . . 23
8.2 Network Element Control Protocol (NECP) . . . . . . . . . 24
8.3 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . 25
9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 26
9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 26
9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 26
9.1.3 Authentication based on IP number . . . . . . . . . . . . 26
9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 26
9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 27
9.3 Service security . . . . . . . . . . . . . . . . . . . . . 27
9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 27
9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 27
9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 28
9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 28
9.3.5 Application level access . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28
References . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
Full Copyright Statement . . . . . . . . . . . . . . . . . 32
3.2.2 クライアント、.3.1(キャッシュする)プロキシが.113.2に網の目にかける発生源サーバ. . . . . . . . . . . 10 3.2.3相互プロキシ.113.2への代理に、.3.2(キャッシュする)プロキシはプロキシ. . . . . . . . . . . . . 12 4をキャッシュすることへの.123.2.4ネットワーク要素を整列させます。 レプリカ選択. . . . . . . . . . . . . . . . . . . . 13 4.1ナビゲーションは.134.2にハイパーリンクします。レプリカHTTPリダイレクション. . . . . . . . . . . . . . . . . 14 4.3DNSリダイレクション. . . . . . . . . . . . . . . . . . . . . 14 5。 相互レプリカコミュニケーション. . . . . . . . . . . . . . . 15 5.1のバッチの駆動模写. . . . . . . . . . . . . . . . . 15 5.2の要求の駆動模写. . . . . . . . . . . . . . . . 16 5.3は模写. . . . . . . . . . . . . . . . . 16 6を同時にさせました。 Proxy Configuration. . . . . . . . . . . . 17 6.1Manual Proxy Configuration. . . . . . . . . . . . . . . . 17 6.2Proxy Auto Configuration(PAC). . . . . . . . . . . . . . 17 6.3Cache Arrayルート設定プロトコル(CARP)v1.0. . . . . . . . . 18 6.4ウェブProxy Auto-発見プロトコル(WPAD). . . . . . . . . 18 7のユーザエージェント。 相互Proxy Communication.197.1LooselyはInter-プロキシCommunication. . . . . . . . 19 7.1.1インターネットCacheプロトコル(ICP). . . . . . . . . . . . . . 19 7.1.2Hyper Text Cachingプロトコル. . . . . . . . . . . . . . . 20 7.1を結合しました; 3はCache PreをいっぱいにしているDigest. . . . . . . . . . . . . . . . . . . . . . . 21 7.1.4.227.2Tightly Coupled Inter-キャッシュCommunication. . . . . . . . 22 7.2.1Cache Arrayルート設定プロトコル(CARP)v1.0. . . . . . . . . 22 8をキャッシュします。 要素コミュニケーション. . . . . . . . . . . . . . 23 8.1ウェブキャッシュ制御プロトコル(WCCP). . . . . . . . . . . . 23 8.2ネットワーク要素制御プロトコル(NECP). . . . . . . . . 24 8.3ソックス. . . . . . . . . . . . . . . . . . . . . . . . . . 25 9をネットワークでつないでください。 セキュリティConsiderations. . . . . . . . . . . . . . . . . 25 9.1Authentication、.269.1、.1Man、.269.1.2Trusted第三者. . . . . . . . . . . . . . . . . . . 26 9.1.3AuthenticationがIP No.. . . . . . . . . . . . 26 9.2Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 26 9.2.1Trusted第三者. . . . . . . . . . . . . . . . . . . 26 9.2に基礎づけた中央攻撃; 2つのログと法的な含意. . . . . . . . . . . . . . . 27 9.3Serviceセキュリティ、.279.3、.1Denial、サービス. . . . . . . . . . . . . . . . . . . . 27 9.3.2Replay攻撃では、プロキシ. . . . . . . . . . . . . 28 9.3.4Copyrighted一時的の.279.3.3Stupid構成は.289.3の.5のApplicationの平らなアクセス. . . . . . . . . . . . . . . . . 28 10をコピーします。 作者の.28の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . 28のものが.31の完全な著作権宣言文. . . . . . . . . . . . . . . . . 32を扱う承認
Cooper, et al. Informational [Page 2] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[2ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
1. Introduction
1. 序論
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年の序論以来、WWWは簡単なクライアントサーバモデルから複雑な分配されたアーキテクチャに発展しています。 主に急激な増加に関連しているスケーリング問題のためこの発展を運転してあります。 異なったパラダイムとソリューションは、決められた一定の要求を満たすために現れました。 この成長の需要にこたえるのに使われる2つのコアインフラストラクチャコンポーネントは、模写とキャッシュです。 多くの場合、ウェブキャッシュと模写されたサービスが共存できる必要があります。
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.
このメモは今日インターネットで配布されているウェブ模写とキャッシュインフラストラクチャの標準の用語と分類学を指定します。 このドキュメントの主な目的はこのアプリケーションドメインの一般的な理解と基準点を確立することです。
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]を入れます、Cache Digests[21][10]、CARP[14]、HTTP[1]、ICP[2]、PAC[12]、SOCKS[7]、WPAD[13]、およびWCCP[18][19]。 以下でこれらのプロトコル、およびキャッシュと模写環境の中の彼らの使用について議論します。
2. Terminology
2. 用語
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.
以下の用語は、ウェブ模写の中で使用されて、共同体をキャッシュしながら、一般的な用語の定義を提供します。 基地の用語は、可能であるところで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.
一般的な用法であって、RFC2616で定義に合わない用語とこのドキュメントは目立ちます。
Cooper, et al. Informational [Page 3] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[3ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
2.1 Base Terms
2.1 基地の用語
The majority of these terms are taken as-is from RFC 2616 [1], and are included here for reference.
これらの用語の大部分が、RFC2616[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のクライアント要件の両方の実装を必要とする上記の状態は適切です。
Cooper, et al. Informational [Page 4] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[4ページ]のRFC3040インターネットウェブ模写と2001年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応答のcacheabilityを決定するための規則はセクション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]) ある他のサーバのための仲介者として機能するサーバから取って. aと異なってプロキシ、ゲートウェイはまるでそれが要求されたリソースのための発生源サーバであるかのように要求を受け取ります。 要求しているクライアントはそれがゲートウェイで交信する予定であるのを意識していないかもしれません。
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)
模写、「異なったコンピュータ、通常サーバでデータベースかファイルシステムの写本を作成して、維持する」、--ComputingのOnline Dictionaryを解放してください(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に見え透いたソースと目的地の間の複数の経路を導入する要素Aネットワークデバイスをネットワークでつないでください。
Cooper, et al. Informational [Page 5] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[5ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
2.2 First order derivative terms
2.2/1に派生している用語を注文してください。
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.
クライアントへのサーバ、およびサーバへのクライアントとして機能して、キャッシュでプロキシAプロキシをキャッシュします。
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.
ゲートウェイと発生源サーバ、またはネットワークにおける異なったポイントで共同場所を見つけて、密接な協力で作動して、通常働く権威を代表として派遣した代理A、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]にCache-コントロール指示を含んでいて。 そのような変更はまだ完全に指定されているというわけではありません。
Devices commonly known as "reverse proxies" and "(origin) server
accelerators" are both more properly defined as surrogates.
「逆のプロキシ」と「(発生源)サーバアクセラレータ」として一般的に知られているデバイスはともにより適切に代理と定義されます。
reverse proxy
See "surrogate".
リバースプロキシSee「代理。」
server accelerator
See "surrogate".
サーバアクセルSee「代理。」
Cooper, et al. Informational [Page 6] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[6ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
2.3 Second order derivatives
2.3 2番目のオーダー派生物
The following terms further build on first order derivatives:
次の用語は最初に、オーダー派生物の上にさらに建てられます:
master origin server
An origin server on which the definitive version of a resource
resides.
リソースの決定的なバージョンがある発生源サーバAn発生源サーバをマスタリングしてください。
replica origin server
An origin server holding a replica of a resource, but which may
act as an authoritative reference for client requests.
リソースのレプリカを保持するクライアント要求の正式の参照として機能するかもしれないレプリカ発生源サーバAn発生源サーバ。
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特別なインスタンス。
2.4 Topological terms
2.4 位相的な用語
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.
地方、プロキシをキャッシュして、キャッシュしているプロキシはどのaユーザエージェントに接するか。
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.
満足している消費者の意見(プロキシをキャッシュしながら地方でユーザエージェントのものではなく、キャッシュメッシュに参加するすべてのキャッシュ)からプロキシSeenをキャッシュする中間的。
cache server
A server to requests made by local and intermediate caching
proxies, but which does not act as a proxy.
プロキシをキャッシュしながら地方的で中間的によってされた要求へのプロキシとして務めないキャッシュサーバAサーバ。
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つのサービスとして論理的に機能して、スペースというリソース名を仕切る配列Aクラスタをキャッシュしてください。 また、「拡散している配列」か「キャッシュクラスタ」として、知られています。
Cooper, et al. Informational [Page 7] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[7ページ]のRFC3040インターネットウェブ模写と2001年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.
メッシュをキャッシュして、緩く結合したセットの協力関係を持っているプロキシと(任意に)キャッシュサーバか、クラスタにもかかわらず、単独行動を取りますが、共有が、相互キャッシュ通信プロトコルを使用することで自分たちの間の内容を「キャッシュ-可能」します。
2.5 Automatic use of proxies
2.5 プロキシの自動使用
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.
トラフィック妨害を実行するネットワーク要素からプロキシまでのクライアント要求のトラフィックリダイレクションRedirection。 手動で個々のユーザエージェントを再構成するか、またはそうでなければそのような使用が起こらないところにプロキシの使用を強制する必要性なしでプロキシを配布するのにおいて(キャッシュします)、使用されています。
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
妨害プロキシはトラフィックリダイレクションのプロセスを通してインバウンドトラフィック流れを受けます。 (そのようなプロキシはプロキシによって提供された適切なサービスの使用を容易にするか、または必要とするようにネットワーク管理者によって配布されます。) 妨害プロキシの展開に関連している問題は説明されます。
Cooper, et al. Informational [Page 8] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[8ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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]を記録してください。 妨害プロキシの使用はユーザエージェントの構成を全く必要としません(まるで発生源サーバと共に直接伝達するかのように行動します)。
3. Distributed System Relationships
3. 分散システム関係
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.
このセクションは分配された模写と環境をキャッシュする際に存在する関係を特定します。 これらの関係を定義したので、後のセクションは各関係に使用される通信プロトコルについて説明します。
3.1 Replication Relationships
3.1 模写関係
The following sections describe relationships between clients and replicas and between replicas themselves.
以下のセクションはクライアントとレプリカとレプリカ自体との関係について説明します。
3.1.1 Client to Replica
3.1.1 レプリカへのクライアント
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つ以上のレプリカ発生源サーバ、およびマスター発生源サーバで交信するかもしれません。 (レプリカサーバがないとき、直接発生源サーバがそのままな状態でクライアントは正常なケースを相互作用させます。)
------------------ ----------------- ------------------
| 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でクライアントがレプリカの1つを使用するのを可能にするのに使用されるプロトコルは見つけることができます。
3.1.2 Inter-Replica
3.1.2 相互レプリカ
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で示された関係でアクセスするデータセットを模写するためにはマスター発生源サーバとレプリカ発生源サーバとの関係です。
Cooper, et al. Informational [Page 9] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[9ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
------------------ ----------------- ------------------
| Replica Origin |-----| Master Origin |-----| Replica Origin |
| Server | | Server | | Server |
------------------ ----------------- ------------------
------------------ ----------------- ------------------ | レプリカ発生源|-----| マスター発生源|-----| レプリカ発生源| | サーバ| | サーバ| | サーバ| ------------------ ----------------- ------------------
Protocols used in this relationship can be found in Section 5.
セクション5でこの関係に使用されるプロトコルは見つけることができます。
3.2 Proxy Relationships
3.2 プロキシ関係
There are a variety of ways in which (caching) proxies and cache servers communicate with each other, and with user agents.
どの(キャッシュします)プロキシとキャッシュサーバが互いにコミュニケートするか、そして、およびユーザエージェントがいるさまざまな道があります。
3.2.1 Client to Non-Interception Proxy
3.2.1 非妨害プロキシへのクライアント
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でこれらの関係に使用される体系とプロトコルは見つけることができます。
3.2.2 Client to Surrogate to Origin Server
3.2.2 発生源サーバへの代理へのクライアント
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つ以上の発生源のためにサーバを意図しました。 代理が使用されていないところに、クライアントは発生源サーバと共に直接伝達します。代理が使用されているところに、クライアントは発生源サーバで交信します。代理はゲートウェイかトンネルとして内部キャッシュ、または行為から要求を発生源サーバに実現させます。
Cooper, et al. Informational [Page 10] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[10ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
-------------- -------------- --------------
| Origin | | Origin | | Origin |
| Server | | Server | | Server |
-------------- -------------- --------------
\ | /
\ | /
-----------------
| Surrogate |
| |
-----------------
|
|
------------
| Client |
------------
-------------- -------------- -------------- | 発生源| | 発生源| | 発生源| | サーバ| | サーバ| | サーバ| -------------- -------------- -------------- \ | / \ | / ----------------- | 代理| | | ----------------- | | ------------ | クライアント| ------------
3.2.3 Inter-Proxy
3.2.3 相互プロキシ
Inter-Proxy relationships exist as meshes (loosely coupled) and clusters (tightly coupled).
相互Proxy関係はメッシュ(緩く結合される)とクラスタ(密結合)として存在しています。
3.2.3.1 (Caching) Proxy Meshes
3.2.3.1 (キャッシュします)プロキシメッシュ
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 |
----------
--------------------- --------------------- -----------| 中間的| | 中間的| | | プロキシ(D)をキャッシュします。| | プロキシ(E)をキャッシュします。| |(同輩) --------------------- --------------------- -------------- | (親) /(親)| キャッシュ| | ------/ | サーバ(C)| | / -------------- | /(同輩)| ----------------- --------------------- -------------| 地方のキャッシュ|-------| 中間的| | プロキシ(A)| (同輩)| プロキシ(B)をキャッシュします。| ----------------- --------------------- | | ---------- | クライアント| ----------
Client included for illustration purposes only
イラスト目的だけのために含まれていたクライアント
Cooper, et al. Informational [Page 11] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[11ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
An inbound request may be routed to one of a number of intermediate (caching) proxies based on a determination of whether that parent is better suited to resolving the request.
本国行きの要求は多くの要求を決議するのに適していたその親が、より良いかどうかに関する決断に基づく(キャッシュします)中間的プロキシのひとりに発送されるかもしれません。
For example, in the above figure, Cache Server C and Intermediate Caching Proxy B are peers of the Local Caching Proxy A, and may only be used when the resource requested by A already exists on either B or C. Intermediate Caching Proxies D & E are parents of A, and it is A's choice of which to use to resolve a particular request.
C.Intermediate Caching Proxies D&EはAの両親です、そして、例えば、Cache Server CとIntermediate Caching Proxy Bは上図では、Local Caching Proxy Aの同輩であり、Aによって要求されたリソースがBに既に存在するときだけ、使用されるかもしれませんか、それは特定の要求を決心に使用する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でこれらの関係に使用されるプロトコルは見つけることができます。
3.2.3.2 (Caching) Proxy Arrays
3.2.3.2 (キャッシュします)プロキシ配列
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でこの関係に使用されるプロトコルは見つけることができます。
3.2.4 Network Element to Caching Proxy
3.2.4 プロキシをキャッシュすることへのネットワーク要素
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は見ます。)
Cooper, et al. Informational [Page 12] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[12ページ]のRFC3040インターネットウェブ模写と2001年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でこれらのプロトコルの詳細を見つけることができます。
4. Replica Selection
4. レプリカ選択
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.
このセクションはクライアントとレプリカ発生源ウェブサーバーとの協力とコミュニケーションで使用される体系とプロトコルについて説明します。 理想的な状況はコミュニケートするクライアントのために最適のレプリカ発生源サーバを発見することです。 最適は、方針に基づいている決定ですが、しばしば近接に基づいていますが、負荷などの他の評価基準に基づくかもしれません。
4.1 Navigation Hyperlinks
4.1 ナビゲーションはハイパーリンクします。
Best known reference:
This memo.
最もよく知られている参照: このメモ。
Description:
The simplest of client to replica communication mechanisms. This
utilizes hyperlink URIs embedded in web pages that point to the
individual replica origin servers. The content consumer manually
selects the link of the replica origin server they wish to use.
記述: レプリカコミュニケーションメカニズムこれへの最も純真なクライアントは個々のレプリカ発生源サーバを示すウェブページに埋め込まれたハイパーリンクURIを利用します。 満足している消費者は手動で彼らが使用したがっているレプリカ発生源サーバのリンクを選択します。
Cooper, et al. Informational [Page 13] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[13ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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.
Submitter: エディタを記録してください。
4.2 Replica HTTP Redirection
4.2 レプリカHTTPリダイレクション
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の使用で最適のレプリカ発生源サーバに向け直される、「一時的である、再直接、」 クライアントはレプリカ発生源サーバの1つとのHTTPコミュニケーションを確立します。 そして、初めは連絡されたレプリカ発生源サーバは、サービスを受け入れるか、または再びクライアントを向け直すのを選ぶことができます。 HTTP応答コードの情報のためのHTTP/1.1[1]のセクション10.3を参照してください。
Security:
Relies entirely upon HTTP security.
セキュリティ: HTTPセキュリティを完全に当てにします。
Deployment:
Observed at a number of large web sites. Extent of usage in the
Internet is unknown.
展開: 多くの大きいウェブサイトでは、観測されます。 インターネットの用法の範囲は未知です。
Submitter:
Document editors.
Submitter: エディタを記録してください。
4.3 DNS Redirection
4.3 DNSリダイレクション
Best known references:
最もよく知られている参照:
* RFC 1794 DNS Support for Load Balancing Proximity [8]
* ロードバランシングの近接のRFC1794DNSサポート[8]
* This memo
* このメモ
Description:
The Domain Name Service (DNS) provides a more sophisticated client
to replica communication mechanism. This is accomplished by DNS
記述: Domain Name Service(DNS)はレプリカコミュニケーションメカニズムにより洗練されたクライアントを供給します。 これはDNSによって達成されます。
Cooper, et al. Informational [Page 14] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[14ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
servers that sort resolved IP addresses based upon quality of
service policies. When a client resolves the name of an origin
server, the enhanced DNS server sorts the available IP addresses
of the replica origin servers starting with the most optimal
replica and ending with the least optimal replica.
決心しているIPアドレスを分類するサーバが方針をサービスの質に基礎づけました。 クライアントが発生源サーバの名前を決議すると、高められたDNSサーバは最も最適のレプリカから始まって、最も最適でないレプリカで終わるレプリカ発生源サーバの利用可能なIPアドレスを分類します。
Security:
Relies entirely upon DNS security, and other protocols that may be
used in determining the sort order.
セキュリティ: ソート順序を決定する際に使用されるかもしれないDNSセキュリティ、および他のプロトコルを完全に当てにします。
Deployment:
Observed at a number of large web sites and large ISP web hosted
services. Extent of usage in the Internet is unknown, but is
believed to be increasing.
展開: 多くの大きいウェブサイトと大きいISPウェブ接待されたサービスのときに、観測されます。 インターネットの用法の範囲は、未知ですが、増加していると信じられています。
Submitter:
Document editors.
Submitter: エディタを記録してください。
5. Inter-Replica Communication
5. 相互レプリカコミュニケーション
This section describes the cooperation and communication between master- and replica- origin servers. Used in replicating data sets between origin servers.
このセクションはマスターとレプリカ発生源サーバの協力とコミュニケーションについて説明します。 発生源サーバの間でデータセットを模写する際に、使用されています。
5.1 Batch Driven Replication
5.1 バッチの駆動模写
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.
Submitter: エディタを記録してください。
Cooper, et al. Informational [Page 15] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[15ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
5.2 Demand Driven Replication
5.2 要求の駆動模写
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.
Submitter: エディタを記録してください。
5.3 Synchronized Replication
5.3 連動している模写
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.
セキュリティ: 知られているプロトコルのすべてがメソッド、どれがケルベロス共有秘密キーモデルに基づいているか、そして、または公衆/秘密鍵RSAがモデル化する強い暗号化キー交換を利用します。
Deployment:
Observed at a few sites, primarily at university campuses.
展開: いくつかのサイトにおいて主として大学構内で観測されます。
Submitter:
Document editors.
Submitter: エディタを記録してください。
Cooper, et al. Informational [Page 16] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[16ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
Note:
The editors are aware of at least two open source protocols - AFS
and CODA - as well as the proprietary NRS protocol from Novell.
以下に注意してください。 エディタはノベルからの独占NRSプロトコルと同様に少なくとも2つのオープンソースプロトコル(AFSとCODA)を意識しています。
6. User Agent to Proxy Configuration
6. プロキシ構成へのユーザエージェント
This section describes the configuration, cooperation and communication between user agents and proxies.
このセクションはユーザエージェントとプロキシとの構成、協力、およびコミュニケーションについて説明します。
6.1 Manual Proxy Configuration
6.1 手動のプロキシ構成
Best known reference:
This memo.
最もよく知られている参照: このメモ。
Description:
Each user must configure her user agent by supplying information
pertaining to proxied protocols and local policies.
記述: 各ユーザは、proxiedプロトコルとローカルの方針に情報関係を供給することによって、彼女のユーザエージェントを構成しなければなりません。
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.
Submitter: エディタを記録してください。
6.2 Proxy Auto Configuration (PAC)
6.2 プロキシの自動構成(PAC)
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
セキュリティ: 可能な組織あたりの共通政策にもかかわらず、スチール写真は初期の手動の構成を必要とします。 PACは「手動のプロキシ」より良いです。
Cooper, et al. Informational [Page 17] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[17ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
configuration" since PAC administrators may update the proxy
configuration without further user intervention.
PAC管理者以来の「構成」はさらなるユーザ介入なしでプロキシ構成をアップデートするかもしれません。
Interoperability of PAC files is not high, since different
browsers have slightly different interpretations of the same
script, possibly leading to undesired effects.
PACファイルの相互運用性は高くはありません、異なったブラウザには同じスクリプトのわずかに異なった解釈があるので、ことによると望まれない効果に通じて。
Deployment:
Implemented in Netscape Navigator and Microsoft Internet Explorer.
展開: ネットスケープナビゲータとMicrosoft Internet Explorerでは、実装されます。
Submitter:
Document editors.
Submitter: エディタを記録してください。
6.3 Cache Array Routing Protocol (CARP) v1.0
6.3 キャッシュArrayルート設定プロトコル(CARP)v1.0
Best known references:
最もよく知られている参照:
* "Cache Array Routing Protocol" [14] (work in progress)
* 「キャッシュ配列ルーティング・プロトコル」[14](処理中の作業)
* "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]
* 「キャッシュArrayルート設定プロトコル(CARP)v1.0 Specifications」[15]
* "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"
[16]
* 「配列ルーティング・プロトコルとマイクロソフトをProxyサーバ2インチキャッシュしてください」[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.
Submitter: エディタを記録してください。
6.4 Web Proxy Auto-Discovery Protocol (WPAD)
6.4 ウェブプロキシ自動発見プロトコル(WPAD)
Best known reference:
"The Web Proxy Auto-Discovery Protocol" [13] (work in progress)
最もよく知られている参照: 「ウェブプロキシ自動発見プロトコル」[13](処理中の作業)
Description:
WPAD uses a collection of pre-existing Internet resource discovery
mechanisms to perform web proxy auto-discovery.
記述: WPADは、ウェブプロキシ自動発見を実行するのに先在のインターネット資料発見メカニズムの収集を使用します。
Cooper, et al. Informational [Page 18] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[18ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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
* Dynamic Host Configuration Protocol DHCP
* Service Location Protocol SLP
* サービス位置のプロトコルSLP
* "Well Known Aliases" using DNS A records
* DNS A記録を使用する「井戸Known Aliases」
* 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
Submitter: ジョッシュ・コーエン
7. Inter-Proxy Communication
7. 相互プロキシコミュニケーション
7.1 Loosely coupled Inter-Proxy Communication
7.1 緩く結合したInter-プロキシCommunication
This section describes the cooperation and communication between caching proxies.
このセクションはプロキシをキャッシュするところの協力とコミュニケーションについて説明します。
7.1.1 Internet Cache Protocol (ICP)
7.1.1 インターネットキャッシュプロトコル(ICP)
Best known reference:
RFC 2186 Internet Cache Protocol (ICP), version 2 [2]
最もよく知られている参照: RFC2186インターネットCacheプロトコル(ICP)、バージョン2[2]
Cooper, et al. Informational [Page 19] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[19ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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]
セキュリティ: RFC2187を見てください。[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を使用することでそれらを検索するので、誤ったキャッシュヒットは起こるかもしれません(兄弟には、キャッシュで現在の、しかし、アクセスしやすくないオブジェクトは1つの例です)。
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.
Submitter: エディタを記録してください。
See also:
"Internet Cache Protocol Extension" [17] (work in progress)
参照: 「インターネットキャッシュプロトコル拡大」[17](処理中の作業)
7.1.2 Hyper Text Caching Protocol
7.1.2 プロトコルをキャッシュする超-テキスト
Best known reference:
RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) [9]
最もよく知られている参照: プロトコル(HTCP/0.0)をキャッシュするRFC2756超-テキスト[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要求の結果、起こるふるまいについて説明するのを可能にして。
Cooper, et al. Informational [Page 20] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[20ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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と「ウェブゲートウェイ迎撃戦闘機」で実装されます。
Submitter:
Document editors.
Submitter: エディタを記録してください。
7.1.3 Cache Digest
7.1.3 キャッシュダイジェスト
Best known references:
最もよく知られている参照:
* "Cache Digest Specification - version 5" [21]
* 「Digest Specificationをキャッシュしてください--バージョン5インチ」[21]
* "Summary Cache: A Scalable Wide-Area Web Cache Sharing
Protocol" [10] (see note)
* 「概要キャッシュ:」 「プロトコルを共有するスケーラブルな広い領域ウェブキャッシュ」[10](注意を見ます)
Description:
Cache Digests are a response to the problems of latency and
congestion associated with previous inter-cache communication
mechanisms such as the Internet Cache Protocol (ICP) [2] and the
Hyper Text Cache Protocol [9]. Unlike these protocols, Cache
Digests support peering between caching proxies and cache servers
without a request-response exchange taking place for each inbound
request. Instead, a summary of the contents in cache (the Digest)
is fetched by other systems that peer with it. Using Cache
Digests it is possible to determine with a relatively high degree
of accuracy whether a given resource is cached by a particular
system.
記述: キャッシュDigestsはインターネットCacheプロトコル(ICP)[2]やHyper Text Cacheプロトコル[9]などの前の相互キャッシュコミュニケーションメカニズムに関連している潜在と混雑の問題への応答です。 これらのプロトコルと異なって、それぞれの本国行きの要求単位で起こる要求応答交換なしでプロキシとキャッシュサーバをキャッシュするとき、Cache Digestsはじっと見ることをサポートします。 代わりに、キャッシュ(Digest)におけるコンテンツの概要はそれでじっと見る他のシステムによってとって来られます。 Cache Digestsを使用して、比較的高精度で与えられたリソースが特定のシステムによってキャッシュされるかどうか決定するのは可能です。
Cache Digests are both an exchange protocol and a data format.
キャッシュDigestsは交換プロトコルとデータの形式の両方です。
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.
セキュリティ: Digestの内容が機密であるなら、それらは保護されるべきです。 通常、HTTPが接続であると機密保護するために適用されるどんなメソッドもCache Digestsに適用できます。
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のためににせの同輩Digestを造って、ビーズの同輩にそれをサービスできます。 AがB. この問題の影響からの/に向かって交通整理できるこの方法は1台のシステムから別のシステムまでCache Digestsを移す'牽引力'モデルによって最小にされます。
Cooper, et al. Informational [Page 21] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[21ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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.).
キャッシュDigestsはURLレベルに関するピアキャッシュ内容に関する知識を提供します。 したがって、それらは、特定のレベルの政策管理を書き取らないで、どんなレベル(ユーザ、組織など)に関する様々な政策も実施するのに使用できます。
Deployment:
Cache Digests are supported in Squid.
展開: キャッシュDigestsはSquidでサポートされます。
Cache Meshes: NLANR Mesh; TF-CACHE Mesh (European Academic
networks
メッシュをキャッシュしてください: NLANRはかみ合います。 TF-CACHE Mesh、(ヨーロッパのAcademicはネットワークでつなぎます。
Submitter:
Alex Rousskov for [21], Pei Cao for [10].
Submitter: [21]のためのアレックスRousskov、[10]のためのペイ・ツァオ。
Note: The technology of Summary Cache [10] is patent pending by the University of Wisconsin-Madison.
以下に注意してください。 Summary Cache[10]の技術はウィスコンシン-マディソンの大学による新案特許出願中です。
7.1.4 Cache Pre-filling
7.1.4 キャッシュプレ充填
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
Submitter: イワンLovric
7.2 Tightly Coupled Inter-Cache Communication
7.2 密結合相互キャッシュコミュニケーション
7.2.1 Cache Array Routing Protocol (CARP) v1.0
7.2.1 キャッシュArrayルート設定プロトコル(CARP)v1.0
Also see Section 6.3
また、セクション6.3を見てください。
Cooper, et al. Informational [Page 22] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[22ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
Best known references:
最もよく知られている参照:
* "Cache Array Routing Protocol" [14] (work in progress)
* 「キャッシュ配列ルーティング・プロトコル」[14](処理中の作業)
* "Cache Array Routing Protocol (CARP) v1.0 Specifications" [15]
* 「キャッシュArrayルート設定プロトコル(CARP)v1.0 Specifications」[15]
* "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"
[16]
* 「配列ルーティング・プロトコルとマイクロソフトをProxyサーバ2インチキャッシュしてください」[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に含まれているのは、Proxy Array Membership Table、およびこの情報をダウンロードする方法の定義です。
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を実装するユーザエージェントは、Proxy Arrayのどんなメンバーにも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.
Submitter: エディタを記録してください。
8. Network Element Communication
8. ネットワーク要素コミュニケーション
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.
このセクションはプロキシとネットワーク要素との協力とコミュニケーションについて説明します。 そのようなネットワーク要素に関する例はルータとスイッチを含んでいます。 一般に、妨害を配布するのにプロキシを使用する、そして/または、配列を拡散させました。
8.1 Web Cache Control Protocol (WCCP)
8.1 ウェブキャッシュ制御プロトコル(WCCP)
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
以下に注意してください。 このプロトコルに使用される名前は異なります、混乱を避けるために時々しかし、「ウェブキャッシュコーディネートプロトコル」、まさしく頻繁の"WCCP"と呼ばれて
Cooper, et al. Informational [Page 23] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[23ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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つ以上のプロキシが、向け直されたトラフィックを受けるためにただ一つのルータとともに記名することができます。 また、それで、プロキシのひとり、指定されたプロキシは、トラフィックがどれくらい向け直されるかをルータに配列の向こう側に分配されていた状態で決めることができます。
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はさまざまなシスコルータで配布されます。 プロキシをキャッシュします: ベンダーがプロキシを多くキャッシュするとき、WCCPは配布されます。
Submitter:
David Forster
Document editors.
Submitter: デヴィッドフォルスターDocumentエディタ。
8.2 Network Element Control Protocol (NECP)
8.2 ネットワーク要素制御プロトコル(NECP)
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.
展開: 現在のところの未知。 いくつかのネットワーク要素とキャッシュプロキシベンダーがプロトコルを実装する意図を述べました。
Cooper, et al. Informational [Page 24] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[24ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
Submitter:
Gary Tomlinson
Submitter: ゲーリー・トムリンスン
8.3 SOCKS
8.3 ソックス
Best known reference:
RFC 1928 SOCKS Protocol Version 5 [7]
最もよく知られている参照: RFC1928ソックスはバージョン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.
Submitter: エディタを記録してください。
9. Security Considerations
9. セキュリティ問題
This document provides a taxonomy for web caching and replication. Recommended practice, architecture and protocols are not described in detail.
このドキュメントはウェブキャッシュと模写に分類学を提供します。 推奨案、アーキテクチャ、およびプロトコルは詳細に説明されません。
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.
このメモで示されたそれぞれのプロトコルのセキュリティに関する情報を先行するセクション、およびそれらの付随のドキュメンテーションに提供します。 RFC2616[1]のセクション15、HTTP/1.1仕様とある程度RFC1945[6](HTTP/1.0仕様)でHTTPセキュリティについて議論します。 RFC2616はHTTPプロキシのためのセキュリティ問題を含んでいます。
Cooper, et al. Informational [Page 25] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[25ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
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番号に基づいている認証は問題が多いです。 ここで詳細について議論しません。
9.1 Authentication
9.1 認証
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.
ウェブリソースに関する要求、およびそのような要求への応答は、レプリカに向けられるかもしれない、そして/または、中間的プロキシを通して流れるかもしれません。 コミュニケーションの保全は、両方からの保護にアクセスの損失を確実にして、故意でないのから変化するように保存される必要があります。
9.1.1 Man in the middle attacks
9.1.1 中央攻撃でやれやれ
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プロキシは中央の男性、中の男性中央攻撃のためのぴったりの場所です。 この議論はRFC2616[1]のセクション15で見つけられます。
9.1.2 Trusted third party
9.1.2 信頼できる第三者機関
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.
レプリカは発生源サーバから認可を得るかもしれません。
9.1.3 Authentication based on IP number
9.1.3 IP番号に基づく認証
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番号に基づく認証は、終わりから終わりへのインターネットの特性が保持されると仮定します。 通常、これは妨害プロキシを含む環境のためのそうではありません。
9.2 Privacy
9.2 プライバシー
9.2.1 Trusted third party
9.2.1 信頼できる第三者機関
When using a replication service, one must trust both the replica origin server and the replica selection system.
模写サービスを利用するとき、レプリカ発生源サーバとレプリカ選択システムの両方を信じなければなりません。
Cooper, et al. Informational [Page 26] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[26ページ]のRFC3040インターネットウェブ模写と2001年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.
プロキシとサービスが近づく手段を持っているかもしれないレプリカ選択の両方がアクセス情報に集められました。 プロキシは各クライアントによるアクセスに関してそれを使用することで通常知っています、情報がただ一つの発生源サーバを固守したより機密の情報。
9.2.2 Logs and legal implications
9.2.2 ログと法的な含意
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.
彼らがユーザの情報と自分達のふるまいのパターンを提供するので、プロキシからのログは安全に保たれるべきです。 プロキシのログはウェブサーバーログよりさらに機密です、ユーザ人口からのあらゆる要求がプロキシを通るとき。 レプリカ発生源サーバからのログは、サービスから集められた統計を得るために合併される必要があるかもしれません、そして、境界の向こう側にログを輸送するのにおいて、法的な意味があるかもしれません。 ログ取り扱いはいくつかの国で法によって制限されます。
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の場合でウェブ・セッションを暗号化するとき、リソースは頻繁に「非-キャッシュ-可能」されます。
9.3 Service security
9.3 サービスセキュリティ
9.3.1 Denial of service
9.3.1 サービスの否定
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.
妨害プロキシの導入がサービス不能攻撃であると主張されました、終わりから終わりへのインターネットの性質が満足している消費者の知識なしで破壊されるので。
9.3.2 Replay attack
9.3.2 反射攻撃
A caching proxy is by definition a replay attack.
キャッシュしているプロキシは定義上反射攻撃です。
Cooper, et al. Informational [Page 27] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[27ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
9.3.3 Stupid configuration of proxies
9.3.3 プロキシの愚かな構成
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.
満足している消費者のためにサービスに害を及ぼす愚かな構成を持っているのはかなり簡単です。 これはプロキシに関する最も一般的な警備上の問題です。
9.3.4 Copyrighted transient copies
9.3.4 著作権がある一時的なコピー
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.
ヘッダーを含んでいて、出力されたプロトコルを保存するプロキシの必要性をキャッシュします。 復元サービスは、オブジェクトの源を保持する必要があります。
9.3.5 Application level access
9.3.5 アプリケーションレベルアクセス
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.
プロキシをキャッシュして、トラフィック流路のアプリケーションレベルコンポーネントであり、以前に単に無プロキシの世界のネットワークレベルで利用可能であった情報入手を侵入者に与えるかもしれません。 平らな設備が、物理的なアクセスが機密情報を得るのを必要としたかもしれない何らかのネットワーク。 アプリケーションレベルコンポーネントの導入は追加システムセキュリティを必要とするかもしれません。
10. Acknowledgements
10. 承認
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、ジョッシュ・コーエン、ジョン・マーチン、ジョンDilley、イワンLovric、ジョーTouch、Henrikノードストロム、パトリック・マクマナス、ドウェイン・ウェセルズ、Wojtek Sylwestrzak、テッド・ハーディー、ミーシャ・ラビノビチ、ラリーMasinter、キース・ムーア、ロイFielding、パトリクFaltstrom(Hilarie Orman)はノッティンガムとオスカー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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[2] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
Version 2", RFC 2186, September 1997.
[2] ウェセルズとD.とK.Claffy、「インターネットキャッシュプロトコル(ICP)、バージョン2インチ、RFC2186、1997年9月。」
[3] Wessels, D. and K. Claffy, "Application of Internet Cache
Protocol (ICP), Version 2", RFC 2187, September 1997.
[3] ウェセルズとD.とK.Claffy、「インターネットキャッシュプロトコル(ICP)の応用、バージョン2インチ、RFC2187、1997年9月。」
Cooper, et al. Informational [Page 28] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[28ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
[4] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
9, RFC 959, October 1985.
[4] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、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.アルベルティ、「インターネットゴーファープロトコル」、RFC1436、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インチ、RFC1945、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.ジョーンズ、「ソックスはバージョン5インチについて議定書の中で述べます、RFC1928、1996年3月。」
[8] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April
1995.
[8]Brisco、T.、「ロードバランシングのDNSサポート」、RFC1794、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)をキャッシュする超-テキスト」、RFC2756、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.Broder、「概要は以下をキャッシュします」。 「Scalable Wide-領域ウェブCache Sharingプロトコル」、ACM SIGCOMM98年のページのProceedings 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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[12] Netscape, Inc., "Navigator Proxy Auto-Config File Format",
March 1996,
<URL:http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-
live.html>.
[12]Netscape Inc.、「ナビゲータプロキシ自動コンフィグファイル形式」、1996年3月、<URL: http://www.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy- live.html>。
[13] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web
Proxy Auto-Discovery Protocol", Work in Progress.
[13] 「ウェブプロキシ自動発見プロトコル」というゴーティエア、P.、コーエン、J.、ダンスミュア、M.、およびC.パーキンスは進行中で働いています。
[14] Valloppillil, V. and K. Ross, "Cache Array Routing Protocol",
Work in Progress.
[14] 「キャッシュ配列ルーティング・プロトコル」というValloppillil、V.、およびK.ロスは進行中で働いています。
[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]マイクロソフト社、「キャッシュArrayルート設定プロトコル(CARP)v1.0 Specifications、Technical Whitepaper」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]マイクロソフト社、「プロトコルとマイクロソフトProxyサーバ2.0、技術的な白が紙を張るキャッシュ配列ルート設定」、1998年8月、<URL: http://www.microsoft.com/proxy/documents/CarpWP.exe >。
[17] Lovric, I., "Internet Cache Protocol Extension", Work in
Progress.
[17] I.、「インターネットキャッシュプロトコル拡大」というLovricは進行中で働いています。
Cooper, et al. Informational [Page 29] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[29ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
[18] Cieslak, M. and D. Forster, "Cisco Web Cache Coordination
Protocol V1.0", Work in Progress.
[18]CieslakとM.とD.フォルスター、「コクチマスウェブキャッシュコーディネートプロトコル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.ウィルソン、「コクチマスウェブキャッシュコーディネートプロトコルV2.0"、進行中の仕事。」
[20] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a
cache - A satellite overview", Work in Progress.
[20] グタール、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.ウェセルズ、「Digest仕様をキャッシュしてください--<URL: バージョン5インチ、1998年12月、 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.、Jalan、R.、Neerdaels、C.、Shroeder、T.、およびG.トムリンスン、「NECP:」 「ネットワーク要素制御プロトコル」、進行中の仕事。
[23] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems",
Work in Progress.
[23] 「知られているHTTPプロキシ/キャッシュ問題」というクーパー、I.、およびJ.Dilleyは進行中で働いています。
Cooper, et al. Informational [Page 30] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[30ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
Authors' Addresses
作者のアドレス
Ian Cooper Equinix, Inc. 2450 Bayshore Parkway Mountain View, CA 94043 USA
イアン桶屋Equinix Inc.2450Bayshore Parkwayカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 316 6065 EMail: icooper@equinix.com
以下に電話をしてください。 +1 6065年の650 316メール: icooper@equinix.com
Ingrid Melve UNINETT Tempeveien 22 Trondheim N-7465 Norway
イングリッドMelve UNINETT Tempeveien22トロンヘイムN-7465ノルウェー
Phone: +47 73 55 79 07 EMail: Ingrid.Melve@uninett.no
以下に電話をしてください。 +47 73 55 79 07はメールされます: Ingrid.Melve@uninett.no
Gary Tomlinson CacheFlow Inc. 12034 134th Ct. NE, Suite 201 Redmond, WA 98052 USA
ゲーリートムリンスンCacheFlow Inc.12034第134ct。 Ne、Suite201レッドモンド、ワシントン98052米国
Phone: +1 425 820 3009 EMail: gary.tomlinson@cacheflow.com
以下に電話をしてください。 +1 3009年の425 820メール: gary.tomlinson@cacheflow.com
Cooper, et al. Informational [Page 31] RFC 3040 Internet Web Replication & Caching Taxonomy January 2001
クーパー、他 情報[31ページ]のRFC3040インターネットウェブ模写と2001年1月に分類学をキャッシュすること。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Cooper, et al. Informational [Page 32]
クーパー、他 情報[32ページ]
一覧
スポンサーリンク
