RFC2187 日本語訳
2187 Application of Internet Cache Protocol (ICP), version 2. D.Wessels, K. Claffy. September 1997. (Format: TXT=51662 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Wessels
Request for Comments: 2187 K. Claffy
Category: Informational National Laboratory for Applied
Network Research/UCSD
September 1997
コメントを求めるワーキンググループD.ウェセルズの要求をネットワークでつないでください: 2187 K.はカテゴリをClaffyします: 適用されたネットワーク研究/UCSD1997年9月のための情報の国家の研究所
Application of Internet Cache Protocol (ICP), version 2
インターネットCacheプロトコル(ICP)の応用、バージョン2
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use.
このドキュメントはICPv2(インターネットCacheプロトコルバージョン2、RFC2186)のアプリケーションについてウェブキャッシュに説明します。 ICPv2はウェブキャッシュの中のコミュニケーションに使用される軽量のメッセージ・フォーマットです。 いくつかの独立しているキャッシュ実現が現在ICP[3、5]を使用します、使用を実行して、配備して、広げようとするもののためにICPの既存の実用的な用途を成文化するのを重要にして。
ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFC2186) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior.
ICP質問と回答は隣人キャッシュにおける、URL(または、物)の存在について言及します。 キャッシュは、物を検索する最も適切な位置を選択するのにICPメッセージを交換して、集まっている情報を使用します。 仲間ドキュメント(RFC2186)はプロトコル自体の形式と構文について説明します。 本書では私たちはウェブ交通現象の他の局面とのICP展開、効率、セキュリティ、および相互作用の問題に焦点を合わせます。
Table of Contents
目次
1. Introduction................................................. 2
2. Web Cache Hierarchies........................................ 3
3. What is the Added Value of ICP?.............................. 5
4. Example Configuration of ICP Hierarchy....................... 5
4.1. Configuring the `proxy.customer.org' cache................. 6
4.2. Configuring the `cache.isp.com' cache...................... 6
5. Applying the Protocol........................................ 7
5.1. Sending ICP Queries........................................ 8
5.2. Receiving ICP Queries and Sending Replies.................. 10
5.3. Receiving ICP Replies...................................... 11
5.4. ICP Options................................................ 13
6. Firewalls.................................................... 14
7. Multicast.................................................... 14
8. Lessons Learned.............................................. 16
8.1. Differences Between ICP and HTTP........................... 16
1. 序論… 2 2. ウェブキャッシュ階層構造… 3 3. ICPのAdded Valueは何ですか? 5 4. ICP階層構造の例の構成… 5 4.1. 'proxy.customer.org'キャッシュを構成します… 6 4.2. 'cache.isp.com'キャッシュを構成します… 6 5. プロトコルを適用します… 7 5.1. 送付ICP質問… 8 5.2. ICP質問と発信を受けるのは返答します… 10 5.3. ICPを受けるのは返答します… 11 5.4. ICPオプション… 13 6. ファイアウォール… 14 7. マルチキャスト… 14 8. レッスンは学びました… 16 8.1. ICPとHTTPの違い… 16
Wessels & Claffy Informational [Page 1] RFC 2187 ICP September 1997
[1ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
8.2. Parents, Siblings, Hits and Misses......................... 16
8.3. Different Roles of ICP..................................... 17
8.4. Protocol Design Flaws of ICPv2............................. 17
9. Security Considerations...................................... 18
9.1. Inserting Bogus ICP Queries................................ 19
9.2. Inserting Bogus ICP Replies................................ 19
9.3. Eavesdropping.............................................. 20
9.4. Blocking ICP Messages...................................... 20
9.5. Delaying ICP Messages...................................... 20
9.6. Denial of Service.......................................... 20
9.7. Altering ICP Fields........................................ 21
9.8. Summary.................................................... 22
10. References................................................... 23
11. Acknowledgments.............................................. 24
12. Authors' Addresses........................................... 24
8.2. 両親、兄弟は、当たって、消えます… 16 8.3. ICPの異なる役割… 17 8.4. ICPv2の設計上の欠陥について議定書の中で述べてください… 17 9. セキュリティ問題… 18 9.1. にせのICP質問を挿入します… 19 9.2. にせのICPを挿入するのは返答します… 19 9.3. 盗み聞きます… 20 9.4. ICPメッセージを妨げます… 20 9.5. ICPメッセージを遅らせます… 20 9.6. サービス妨害… 20 9.7. ICP分野を変更します… 21 9.8. 概要… 22 10. 参照… 23 11. 承認… 24 12. 作者のアドレス… 24
1. Introduction
1. 序論
ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information for use in selecting the most appropriate location from which to retrieve an object.
ICPはウェブキャッシュの中で交信するのに使用される軽量のメッセージ・フォーマットです。 ICPは、隣人キャッシュにおける、URLの存在に関してヒントを交換するのに使用されます。 キャッシュは、物を検索する最も適切な位置を選択することにおける使用のために情報を収集するためにICP質問と回答を交換します。
This document describes the implementation of ICP in software. For a description of the protocol and message format, please refer to the companion document (RFC2186). We avoid making judgments about whether or how ICP should be used in particular Web caching configurations. ICP may be a "net win" in some situations, and a "net loss" in others. We recognize that certain practices described in this document are suboptimal. Some of these exist for historical reasons. Some aspects have been improved in later versions. Since this document only serves to describe current practices, we focus on documenting rather than evaluating. However, we do address known security problems and other shortcomings.
このドキュメントはソフトウェアにおける、ICPの実現について説明します。 プロトコルとメッセージ・フォーマットの記述について、仲間ドキュメント(RFC2186)を参照してください。 私たちが、判断をするのを避ける、使用されるべきであるか、またはICPは、構成をキャッシュしながら、特定のウェブにどのように使用されるべきであるか。 ICPはいくつかの状況における「ネットの勝利」と、他のものの「純損失」であるかもしれません。 私たちは、本書では説明されたある種の慣例が準最適であると認めます。 これらの或るものは歴史的な理由で存在しています。 いくつかの局面が後のバージョンで改良されました。 このドキュメントが、現在の実務について説明するのに役立つだけであるので、私たちは、評価するよりむしろ記録するのは焦点を合わせます。 しかしながら、私たちは知られている警備上の問題と他の短所を記述します。
The remainder of this document is written as follows. We first describe Web cache hierarchies, explain motivation for using ICP, and demonstrate how to configure its use in cache hierarchies. We then provide a step-by-step description of an ICP query-response transaction. We then discuss ICP interaction with firewalls, and briefly touch on multicasting ICP. We end with lessons with have learned during the protocol development and deployement thus far, and the canonical security considerations.
このドキュメントの残りは以下の通り書かれています。 私たちは、最初にウェブキャッシュ階層構造について説明して、ICPを使用するために動機について説明して、キャッシュ階層構造でどう使用を構成するかを示します。 そして、私たちはICP質問応答取引の段階的な記述を提供します。 私たちは、次に、ファイアウォールとのICP相互作用について議論して、簡潔にマルチキャスティングICPに触れます。 私たちがレッスンで終わる、これまでのところプロトコルの開発とdeployementの間、学んだ、そして、正準なセキュリティ問題。
ICP was initially developed by Peter Danzig, et. al. at the University of Southern California as a central part of hierarchical caching in the Harvest research project[3].
et ICPは初めはピーター・ダンツィグによって開発されました、アル。ハーベストの研究における階層的なキャッシュの中央の部分としての南カリフォルニア大学では、[3]を映し出してください。
Wessels & Claffy Informational [Page 2] RFC 2187 ICP September 1997
[2ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
2. Web Cache Hierarchies
2. ウェブキャッシュ階層構造
A single Web cache will reduce the amount of traffic generated by the clients behind it. Similarly, a group of Web caches can benefit by sharing another cache in much the same way. Researchers on the Harvest project envisioned that it would be important to connect Web caches hierarchically. In a cache hierarchy (or mesh) one cache establishes peering relationships with its neighbor caches. There are two types of relationship: parent and sibling. A parent cache is essentially one level up in a cache hierarchy. A sibling cache is on the same level. The terms "neighbor" and "peer" are used to refer to either parents or siblings which are a single "cache-hop" away. Figure 1 shows a simple hierarchy configuration.
ただ一つのウェブキャッシュはクライアントによってそれの後ろで発生した交通の量を減少させるでしょう。 同様に、ウェブキャッシュのグループは、大体同じようなやり方で別のキャッシュを共有することによって、利益を得ることができます。 それが重要である思い描かれたハーベストプロジェクトの研究者はウェブキャッシュを階層的に接続します。 キャッシュ階層構造(かみ合う)に、1つのキャッシュが隣人キャッシュとのじっと見る関係を確立します。 関係の2つのタイプがあります: 親と兄弟。 親キャッシュは本質的にはキャッシュ階層構造で上がっている1つのレベルです。 兄弟キャッシュが同じレベルにあります。 用語「隣人」と「同輩」は、両親か兄弟のどちらかについて言及するのに使用されます(遠くの単一の「キャッシュホップ」です)。 図1は簡単な階層構造構成を示しています。
But what does it mean to be "on the same level" or "one level up?" The general flow of document requests is up the hierarchy. When a cache does not hold a requested object, it may ask via ICP whether any of its neighbor caches has the object. If any of the neighbors does have the requested object (i.e., a "neighbor hit"), then the cache will request it from them. If none of the neighbors has the object (a "neighbor miss"), then the cache must forward the request either to a parent, or directly to the origin server. The essential difference between a parent and sibling is that a "neighbor hit" may be fetched from either one, but a "neighbor miss" may NOT be fetched from a sibling. In other words, in a sibling relationship, a cache can only ask to retrieve objects that the sibling already has cached, whereas the same cache can ask a parent to retrieve any object regardless of whether or not it is cached. A parent cache's role is
しかし、それは、「同じレベルかそれともある平らな上?」であると何を意味するか。 階層構造の上に資料請求の一般的な流れがあります。 キャッシュが要求された物を保持しないとき、それは、ICPを通して隣人キャッシュのどれかには物があるかどうか尋ねるかもしれません。 隣人のどれかに要求された物(すなわち、「隣人ヒット」)があると、キャッシュは彼らからそれを要求するでしょう。 隣人のだれも物(「隣人ミス」)を持っていないなら、キャッシュは親、または、直接起源サーバに要求を転送しなければなりません。親と兄弟の本質的な相違は「隣人ヒット」がどちらかからとって来られるかもしれませんが、「隣人ミス」は兄弟からとって来られないかもしれないということです。 言い換えれば、兄弟関係では、キャッシュは、兄弟が既にキャッシュした物を検索するように頼むことができるだけですが、同じキャッシュは、それがキャッシュされるかどうかにかかわらずあらゆる物を検索するように親に頼むことができます。 親キャッシュの役割はそうです。
Wessels & Claffy Informational [Page 3] RFC 2187 ICP September 1997
[3ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
T H E I N T E R N E T
===========================
| ||
| ||
| ||
| ||
| +----------------------+
| | |
| | PARENT |
| | CACHE |
| | |
| +----------------------+
| ||
DIRECT ||
RETRIEVALS ||
| ||
| HITS
| AND
| MISSES
| RESOLVED
| ||
| ||
| ||
V \/
+------------------+ +------------------+
| | | |
| LOCAL |/--------HITS-------| SIBLING |
| CACHE |\------RESOLVED-----| CACHE |
| | | |
+------------------+ +------------------+
| | | | |
| | | | |
| | | | |
V V V V V
===================
CACHE CLIENTS
T H E N I T EのR N E T=========================== | || | || | || | || | +----------------------+ | | | | | 親| | | キャッシュ| | | | | +----------------------+ | || ダイレクト|| RETRIEVALS|| | || | ヒット| AND| ミス| 決議されています。| || | || | || V\/+------------------+ +------------------+ | | | | | ローカル|/--------ヒット-------| 兄弟| | キャッシュ|\------決議されています。-----| キャッシュ| | | | | +------------------+ +------------------+ | | | | | | | | | | | | | | | V V V V V=================== キャッシュクライアント
FIGURE 1: A Simple Web cache hierarchy. The local cache can retrieve hits from sibling caches, hits and misses from parent caches, and some requests directly from origin servers.
1図: Simpleウェブキャッシュ階層構造。 ローカルなキャッシュは、親キャッシュ、およびいくつかの要求から直接起源サーバから兄弟キャッシュからヒットを検索できて、当たって、消えます。
to provide "transit" for the request if necessary, and accordingly parent caches are ideally located within or on the way to a transit Internet service provider (ISP).
要求のための「トランジット」を提供するために、それに従って、必要なら、そして、親キャッシュは道以内かトランジットインターネットのサービスプロバイダー(ISP)への道の上に理想的に位置しています。
Squid and Harvest allow for complex hierarchical configurations. For example, one could specify that a given neighbor be used for only a certain class of requests, such as URLs from a specific DNS domain.
イカとハーベストは複雑な階層的な構成を考慮します。 例えば、1つは、与えられた隣人が、あるクラスの要求だけに使用されると指定するかもしれません、特定のDNSドメインからのURLなどのように。
Wessels & Claffy Informational [Page 4] RFC 2187 ICP September 1997
[4ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
Additionally, it is possible to treat a neighbor as a sibling for some requests and as a parent for others.
さらに、いくつかの要求と他のもののための親として兄弟として隣人を扱うのは可能です。
The cache hierarchy model described here includes a number of features to prevent top-level caches from becoming choke points. One is the ability to restrict parents as just described previously (by domains). Another optimization is that the cache only forwards cachable requests to its neighbors. A large class of Web requests are inherently uncachable, including: requests requiring certain types of authentication, session-encrypted data, highly personalized responses, and certain types of database queries. Lower level caches should handle these requests directly rather than burdening parent caches.
ここで説明されたキャッシュ階層構造モデルはふさわしい難所からトップレベルキャッシュを防ぐ多くの特徴を入れます。 1つは以前に(ドメインのそばで)ただ説明されているとして両親を制限する能力です。 別の最適化はキャッシュがキャッシュ可能要求を隣人に転送するだけであるということです。 以下を含んでいて、多人数のクラスのウェブ要求は本来非キャッシュ可能です。 あるタイプに認証を要求する要求(セッションでコード化されたデータ)が応答、およびあるタイプのデータベース質問を非常に個人化しました。 下のレベルキャッシュは親キャッシュを負うより直接むしろこれらの要求を扱うべきです。
3. What is the Added Value of ICP?
3. ICPのAdded Valueは何ですか?
Although it is possible to maintain cache hierarchies without using ICP, the lack of ICP or something similar prohibits the existence of sibling meta-communicative relationships, i.e., mechanisms to query nearby caches about a given document.
ICPを使用しないでキャッシュ階層構造を維持するのが可能ですが、ICPか何か同様のものの不足は、与えられたドキュメントに関して近いキャッシュについて質問するためにすなわち、兄弟のメタコミュニケーションの関係、メカニズムの存在を禁止します。
One concern over the use of ICP is the additional delay that an ICP query/reply exchange contributes to an HTTP transaction. However, if the ICP query can locate the object in a nearby neighbor cache, then the ICP delay may be more than offset by the faster delivery of the data from the neighbor. In order to minimize ICP delays, the caches (as well as the protocol itself) are designed to return ICP requests quickly. Indeed, the application does minimal processing of the ICP request, most ICP-related delay is due to transmission on the network.
ICPの使用に関する1つの心配がICP質問/回答交換がHTTP取引に寄付する追加遅れです。 次に、ICP遅れがICP質問が近くに住んでいる人キャッシュで物の場所を見つけることができるならどのようにそうしても、オフセットより隣人からのデータのさらに速い配送で多くになってください。 ICP遅れを最小にして、キャッシュ(プロトコル自体と同様に)は、すばやく要求をICPに返すように設計されています。 本当に、アプリケーションはICP要求の最小量の処理をして、ICP最も関連の遅れはネットワークにおけるトランスミッションのためです。
ICP also serves to provide an indication of neighbor reachability. If ICP replies from a neighbor fail to arrive, then either the network path is congested (or down), or the cache application is not running on the ICP-queried neighbor machine. In either case, the cache should not use this neighbor at this time. Additionally, because an idle cache can turn around the replies faster than a busy one, all other things being equal, ICP provides some form of load balancing.
また、ICPは、隣人の可到達性のしるしを供給するのに役立ちます。 ICPが到着するように隣人やり損ないから返答するなら、ネットワーク経路は混雑している(or down)であるかキャッシュアプリケーションがICPによって質問された隣人マシンで動いていません。 どちらの場合ではも、キャッシュはこのとき、この隣人を使用するべきではありません。 さらに、活動していないキャッシュが忙しいもの、他のすべてのものより速い回答の周りで等しくなることができるので、ICPは何らかのフォームのロードバランシングを提供します。
4. Example Configuration of ICP Hierarchy
4. ICP階層構造の例の構成
Configuring caches within a hierarchy requires establishing peering relationships, which currently involves manual configuration at both peering endpoints. One cache must indicate that the other is a parent or sibling. The other cache will most likely have to add the first cache to its access control lists.
階層構造の中でキャッシュを構成するのは、じっと見る関係を確立するのを必要とします(現在、ともにじっと見ている終点で手動の構成にかかわります)。 1つのキャッシュが、もう片方が親か兄弟であることを示さなければなりません。 もう片方のキャッシュはたぶん最初のキャッシュをアクセスコントロールリストに追加しなければならないでしょう。
Wessels & Claffy Informational [Page 5] RFC 2187 ICP September 1997
[5ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
Below we show some sample configuration lines for a hypothetical situation. We have two caches, one operated by an ISP, and another operated by a customer. First we describe how the customer would configure his cache to peer with the ISP. Second, we describe how the ISP would allow the customer access to its cache.
以下では、私たちが仮定している状況のためにいくつかのサンプル構成線を見せています。 私たちには、2つのキャッシュがあります、そして、1つはISPで作動しました、そして、別のものは顧客で作動しました。 まず最初に、私たちは顧客がISPでじっと見るためにどう彼のキャッシュを構成するだろうかを説明します。 2番目に、私たちはISPがどうキャッシュへの顧客アクセスを許すだろうかを説明します。
4.1. Configuring the `proxy.customer.org' cache
4.1. 'proxy.customer.org'キャッシュを構成します。
In Squid, to configure parents and siblings in a hierarchy, a `cache_host' directive is entered into the configuration file. The format is:
Squidでは、階層構造で両親と兄弟を構成するために、'キャッシュ_ホスト'指示は構成ファイルに入れられます。 形式は以下の通りです。
cache_host hostname type http-port icp-port [options]
キャッシュ_ホストホスト名タイプhttp-ポートicp-ポート[オプション]
Where type is either `parent', `sibling', or `multicast'. For our example, it would be:
タイプがどちらかの'親'であるところでは、'兄弟'、または'マルチキャスト'です。 私たちの例に関しては、それは以下の通りでしょう。
cache_host cache.isp.com parent 8080 3130
キャッシュ_ホストcache.isp.com親8080 3130
This configuration will cause the customer cache to resolve most cache misses through the parent (`cgi-bin' and non-GET requests would be resolved directly). Utilizing the parent may be undesirable for certain servers, such as servers also in the customer.org domain. To always handle such local domains directly, the customer would add this to his configuration file:
この構成で、顧客キャッシュは親を通したほとんどのキャッシュミスを決議するでしょう('cgi-bin'と非GET要求は直接決議されるでしょう)。 customer.orgドメインでもサーバなどのあるサーバに、親を利用するのは望ましくないかもしれません。 いつも直接そのような局所領域を扱うために、顧客は彼の構成ファイルにこれを追加するでしょう:
local_domain customer.org
地方の_ドメインcustomer.org
It may also be the case that the customer wants to use the ISP cache only for a specific subset of DNS domains. The need to limit requests this way is actually more common for higher levels of cache hierarchies, but it is illustrated here nonetheless. To limit the ISP cache to a subset of DNS domains, the customer would use:
また、顧客がDNSドメインの特定の部分集合にだけISPキャッシュを使用したがっているのは、事実であるかもしれません。 より高いレベルのキャッシュ階層構造には、このように要求を制限する必要性は実際により一般的ですが、それはここでそれにもかかわらず、例証されます。 ISPキャッシュをDNSドメインの部分集合に制限するのに、顧客は以下を使用するでしょう。
cache_host_domain cache.isp.com com net org
キャッシュ_ホスト_ドメインcache.isp.com comネットorg
Then, any requests which are NOT in the .com, .net, or .org domains would be handled directly.
そして、.com、.net、または.orgドメインのそうでないどんな要求も直接扱われるでしょう。
4.2. Configuring the `cache.isp.com' cache
4.2. 'cache.isp.com'キャッシュを構成します。
To configure the query-receiving side of the cache peer relationship one uses access lists, similar to those used in routing peers. The access lists support a large degree of customization in the peering relationship. If there are no access lines present, the cache allows the request by default.
キャッシュ同輩関係1質問を受信する側を構成するのはアクセスリストを使用します、ルーティング同輩で使用されるものと同様です。 アクセスリストはじっと見る関係における、大きい度の改造を支持します。 どんな存在しているアクセス回線もなければ、キャッシュはデフォルトで要求を許します。
Wessels & Claffy Informational [Page 6] RFC 2187 ICP September 1997
[6ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
Note that the cache.isp.com cache need not explicitly specify the customer cache as a peer, nor is the type of relationship encoded within the ICP query itself. The access control entries regulate the relationships between this cache and its neighbors. For our example, the ISP would use:
cache.isp.comキャッシュが同輩として明らかに顧客キャッシュを指定する必要はないことに注意してください、そして、関係のタイプはICP質問自体の中でコード化されません。 アクセス管理エントリーはこのキャッシュとその隣人との関係を規制します。 私たちの例のために、ISPは以下を使用するでしょう。
acl src Customer proxy.customer.org
http_access allow Customer
icp_access allow Customer
acl src Customer proxy.customer.org http_アクセスはアクセスがCustomerを許容するCustomer icp_を許容します。
This defines an access control entry named `Customer' which specifies a source IP address of the customer cache machine. The customer cache would then be allowed to make any request to both the HTTP and ICP ports (including cache misses). This configuration implies that the ISP cache is a parent of the customer.
これは顧客キャッシュマシンのソースIPアドレスを指定する'顧客'というアクセス管理エントリーを定義します。 そして、顧客キャッシュは両方へのどんな要求もHTTPとICPポートにすることができるでしょう(キャッシュミスを含んでいて)。 この構成は、ISPキャッシュが顧客の親であることを含意します。
If the ISP wanted to enforce a sibling relationship, it would need to deny access to cache misses. This would be done as follows:
ISPが兄弟関係を実施したいなら、それは、キャッシュするアクセスが消えることを否定する必要があるでしょうに。 これは以下の通り完了しているでしょう:
miss_access deny Customer
ミス_アクセスはCustomerを否定します。
Of course the ISP should also communicate this to the customer, so that the customer will change his configuration from parent to sibling. Otherwise, if the customer requests an object not in the ISP cache, an error message is generated.
また、もちろん、ISPはこれを顧客に伝えるべきです、顧客が彼の構成を親から兄弟に変えるように。 さもなければ、顧客がいずれかのISPキャッシュで物を要求しないなら、エラーメッセージは発生します。
5. Applying the Protocol
5. プロトコルを適用します。
The following sections describe the ICP implementation in the Harvest[3] (research version) and Squid Web cache[5] packages. In terms of version numbers, this means version 1.4pl2 for Harvest and version 1.1.10 for Squid.
以下のセクションはハーベスト[3](研究バージョン)とSquidウェブキャッシュ[5]パッケージにおけるICP実現について説明します。 バージョン番号に関して、これはハーベストのためのバージョン1.4pl2とSquidのためのバージョン1.1.10を意味します。
The basic sequence of events in an ICP transaction is as follows:
ICP取引における出来事の基本的な系列は以下の通りです:
1. Local cache receives an HTTP[1] request from a cache client.
1. ローカルなキャッシュはキャッシュクライアントからHTTP[1]要求を受け取ります。
2. The local cache sends ICP queries (section 5.1).
2. ローカルなキャッシュは質問(セクション5.1)をICPに送ります。
3. The peer cache(s) receive the queries and send ICP replies
(section 5.2).
3. ピアキャッシュは、質問を受けて、回答(セクション5.2)をICPに送ります。
4. The local cache receives the ICP replies and decides where to
forward the request (section 5.3).
4. ローカルなキャッシュは、ICP回答を受け取って、要求(セクション5.3)をどこに転送するかを決めます。
Wessels & Claffy Informational [Page 7] RFC 2187 ICP September 1997
[7ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
5.1. Sending ICP Queries
5.1. 送付ICP質問
5.1.1. Determine whether to use ICP at all
5.1.1. 全くICPを使用するかどうか決定してください。
Not every HTTP request requires an ICP query to be sent. Obviously, cache hits will not need ICP because the request is satisfied immediately. For origin servers very close to the cache, we do not want to use any neighbor caches. In Squid and Harvest, the administrator specifies what constitutes a `local' server with the `local_domain' and `local_ip' configuration options. The cache always contacts a local server directly, never querying a peer cache.
あらゆるHTTP要求が、ICP質問が送られるのを必要とするというわけではありません。 明らかに、要望がすぐに応じているので、キャッシュヒットはICPを必要としないでしょう。 起源サーバのために、キャッシュの非常に近くでは、どんな隣人キャッシュも使用したいと思いません。 Squidとハーベストでは、管理者は'地方の_ドメイン'と'地方の_ip'設定オプションで'地方'のサーバを構成することを指定します。 ピアキャッシュについて決して質問しないで、キャッシュはいつも直接ローカルサーバに連絡します。
There are other classes of requests that the cache (or the administrator) may prefer to forward directly to the origin server. In Squid and Harvest, one such class includes all non-GET request methods. A Squid cache can also be configured to not use peers for URLs matching the `hierarchy_stoplist'.
キャッシュ(または、管理者)が、直接起源サーバに転送するのを好むかもしれないという他のクラスの要求があります。Squidとハーベストでは、そのようなクラスの1つはすべての非GET要求方法を含んでいます。 また、'階層構造_stoplist'に合っているURLに同輩を使用しないようにSquidキャッシュを構成できます。
In order for an HTTP request to yield an ICP transaction, it must:
ICP取引をもたらすというHTTP要求の注文では、そうしなければなりません:
o not be a cache hit
o aがキャッシュでなかったなら、当たってください。
o not be to a local server
o ローカルサーバには、ありません。
o be a GET request, and
o そしてGET要求になってください。
o not match the `hierarchy_stoplist' configuration.
o '階層構造_stoplist'構成を合わせてください。
We call this a "hierarchical" request. A "non-hierarchical" request is one that doesn't generate any ICP traffic. To avoid processing requests that are likely to lower cache efficiency, one can configure the cache to not consult the hierarchy for URLs that contain certain strings (e.g. `cgi_bin').
私たちは、これを「階層的な」要求と呼びます。 「非階層的な」要求は少しのICP交通も発生させないものです。 キャッシュ効率を下げそうな要求を処理するのを避けるなら、1つは、あるストリング(例えば、'管路気中送電_容器')を含むURLのために階層構造に相談しないようにキャッシュを構成できます。
5.1.2. Determine which peers to query
5.1.2. どの同輩について質問したらよいか決定してください。
By default, a cache sends an ICP_OP_QUERY message to each peer, unless any one of the following are true:
デフォルトで、以下のいずれも本当でない場合、キャッシュはICP_OP_QUERYメッセージを各同輩に送ります:
o Restrictions prevent querying a peer for this request, based on
the configuration directive `cache_host_domain', which specifies
a set of DNS domains (from the URLs) for which the peer should
or should not be queried. In Squid, a more flexible directive
('cache_host_acl') supports restrictions on other parts of the
request (method, port number, source, etc.).
o 同輩は制限によってこの要求のために質問できません、質問されるべきであるか、または同輩が質問されるべきでない1セットのDNSドメイン(URLからの)を指定する構成指示'キャッシュ_ホスト_ドメイン'に基づいて。 Squidでは、よりフレキシブルな指示('_ホスト_aclをキャッシュする')は要求(方法、ポートナンバー、ソースなど)の他の部分の上で制限をサポートします。
Wessels & Claffy Informational [Page 8] RFC 2187 ICP September 1997
[8ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
o The peer is a sibling, and the HTTP request includes a "Pragma:
no-cache" header. This is because the sibling would be asked to
transit the request, which is not allowed.
o 同輩が兄弟であり、HTTP要求がaを含んでいる、「Pragma:」 「キャッシュがありません」ヘッダー。 トランジットへの要求(許容されていない)は兄弟に尋ねられるでしょう、したがって、これがそうです。
o The peer is configured to never be sent ICP queries (i.e. with
the `no-query' option).
o 同輩は、ICP質問(すなわち、'質問がありません'オプションがある)を決して、送らないように構成されます。
If the determination yields only one queryable ICP peer, and the Squid configuration directive `single_parent_bypass' is set, then one can bypass waiting for the single ICP response and just send the HTTP request directly to the peer cache.
決断が1人のqueryable ICP同輩だけをもたらして、Squid構成指示'単一の_親_迂回'が設定されるなら、1つは、ただ一つのICP応答の待ちを迂回させて、ただHTTP要求を直接ピアキャッシュに送ることができます。
The Squid configuration option `source_ping' configures a Squid cache to send a ping to the original source simultaneous with its ICP queries, in case the origin is closer than any of the caches.
Squid設定オプション'ソース_ピング'はICP質問で同時の一次資料にピングを送るためにSquidキャッシュを構成します、起源がキャッシュのどれかより近くにあるといけないので。
5.1.3. Calculate the expected number of ICP replies
5.1.3. ICP回答の予想された数について計算してください。
Harvest and Squid want to maximize the chance to get a HIT reply from one of the peers. Therefore, the cache waits for all ICP replies to be received. Normally, we expect to receive an ICP reply for each query sent, except:
取り入れてください。そうすれば、Squidは同輩のひとりからHIT回答を得る機会を最大にしたがっています。 したがって、キャッシュは、すべてのICP回答が受け取られるのを待っています。 通常、私たちは、以下を除いて、送られた各質問のためのICP回答を受け取ると予想します。
o When the peer is believed to be down. If the peer is down Squid
and Harvest continue to send it ICP queries, but do not expect
the peer to reply. When an ICP reply is again received from the
peer, its status will be changed to up.
o 同輩が下がっていると信じられているとき。 同輩が下がっているなら、Squidとハーベストは、ICP質問をそれに送り続けていますが、同輩が返答すると予想しません。 ICP回答がいつ再び同輩から受け取られるかを状態を変えるでしょう。
The determination of up/down status has varied a little bit as
the Harvest and Squid software evolved. Both Harvest and Squid
mark a peer down when it fails to reply to 20 consecutive ICP
queries. Squid also marks a peer down when a TCP connection
fails, and up again when a diagnostic TCP connection succeeds.
ほんの少しハーベストとSquidソフトウェアが発展したように上/下に状態の決断は異なりました。 20の連続したICP質問に答えないと、ハーベストとSquidの両方が同輩を記録します。 診断TCP接続が成功すると、イカも再び、TCP接続が失敗すると下がっていて、上がった状態で同輩をマークします。
o When sending to a multicast address. In this case we'll
probably expect to receive more than one reply, and have no way
to definitively determine how many to expect. We discuss
multicast issues in section 7 below.
o マルチキャストアドレスに発信するとき。 この場合、私たちは、1つ以上の回答を受け取って、いくつ予想するかを決定的に決定する方法を全く持っていないとたぶん予想するつもりです。 私たちは下のセクション7でマルチキャスト問題について議論します。
5.1.4. Install timeout event
5.1.4. タイムアウト出来事をインストールしてください。
Because ICP uses UDP as underlying transport, ICP queries and replies may sometimes be dropped by the network. The cache installs a timeout event in case not all of the expected replies arrive. By default Squid and Harvest use a two-second timeout. If object retrieval has not commenced when the timeout occurs, a source is selected as described in section 5.3.9 below.
ICPが輸送の基礎となるとしてUDPを使用するので、ICP質問と回答は時々ネットワークによって落とされるかもしれません。 予想された回答のすべてが到着するといけないというわけではないので、キャッシュはタイムアウト出来事をインストールします。 デフォルトで、Squidとハーベストは2秒のタイムアウトを使用します。 タイムアウトが起こるとき、物の検索が始まっていないなら、ソースはセクション5.3.9未満で説明されるように選ばれます。
Wessels & Claffy Informational [Page 9] RFC 2187 ICP September 1997
[9ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
5.2. Receiving ICP Queries and Sending Replies
5.2. ICP質問を受けて、回答を送ります。
When an ICP_OP_QUERY message is received, the cache examines it and decides which reply message is to be sent. It will send one of the following reply opcodes, tested for use in the order listed:
ICP_OP_QUERYメッセージが受信されているとき、キャッシュは、それを調べて、送るために応答メッセージがどれであるかを決めます。 それはリストアップされたオーダーにおける使用がないかどうかテストされた以下の回答opcodesの1つを送るでしょう:
5.2.1. ICP_OP_ERR
5.2.1. ICP_オプアート_は間違えます。
The URL is extracted from the payload and parsed. If parsing fails, an ICP_OP_ERR message is returned.
URLは、ペイロードから抽出されて、分析されます。 構文解析が失敗するなら、ICP_OP_ERRメッセージを返します。
5.2.2. ICP_OP_DENIED
5.2.2. _が否定したICP_オプアート
The access controls are checked. If the peer is not allowed to make this request, ICP_OP_DENIED is returned. Squid counts the number of ICP_OP_DENIED messages sent to each peer. If more than 95% of more than 100 replies have been denied, then no reply is sent at all. This prevents misconfigured caches from endlessly sending unnecessary ICP messages back and forth.
アクセス管理はチェックされます。 同輩がこの要求をすることができないなら、ICP_OP_DENIEDを返します。 イカは各同輩に送られたICP_OP_DENIEDメッセージの数を数えます。 100以上の回答の95%以上を否定したなら、回答を全く送りません。 これは、misconfiguredキャッシュが不要なICPメッセージを前後に際限なく送るのを防ぎます。
5.2.3. ICP_OP_HIT
5.2.3. ICP_オプアート_ヒット
If the cache reaches this point without already matching one of the previous opcodes, it means the request is allowed and we must determine if it will be HIT or MISS, so we check if the URL exists in the local cache. If so, and if the cached entry is fresh for at least the next 30 seconds, we can return an ICP_OP_HIT message. The stale/fresh determination uses the local refresh (or TTL) rules.
キャッシュが既に前のopcodesの合っている1つなしでこのポイントに達するなら、それが、要求が許されていて、私たちが、それがHITかさんになるかを決心しなければならないことを意味するので、私たちは、URLがローカルなキャッシュで存在するかどうかチェックします。 そうだとすれば、キャッシュされたエントリーが次の30秒間、新鮮であるなら、私たちはICP_OP_HITメッセージを返すことができます。 地方がリフレッシュする聞き古した新鮮な決断用途(または、TTL)は統治されます。
Note that a race condition exists for ICP_OP_HIT replies to sibling peers. The ICP_OP_HIT means that a subsequent HTTP request for the named URL would result in a cache hit. We assume that the HTTP request will come very quickly after the ICP_OP_HIT. However, there is a slight chance that the object might be purged from this cache before the HTTP request is received. If this happens, and the replying peer has applied Squid's `miss_access' configuration then the user will receive a very confusing access denied message.
競合条件がICP_OP_HIT回答のために兄弟同輩に存在することに注意してください。 ICP_OP_HITは、命名されたURLを求めるその後のHTTP要求がキャッシュヒットをもたらすことを意味します。 私たちは、HTTP要求が非常にすばやくICP_OP_HITに続くと思います。 しかしながら、HTTP要求が受信されている前にこのキャッシュが物から追放されるかもしれないというわずかな見込みがあります。 これが起こって、返答している同輩がSquidの'ミス_アクセス'構成を適用したなら、ユーザは非常に紛らわしいアクセス拒否メッセージを受け取るでしょう。
5.2.3.1. ICP_OP_HIT_OBJ
5.2.3.1. ICP_オプアート_は_OBJに当りました。
Before returning the ICP_OP_HIT message, we see if we can send an ICP_OP_HIT_OBJ message instead. We can use ICP_OP_HIT_OBJ if:
ICP_OP_HITメッセージを返す前に、私たちは、代わりにICP_OP_HIT_OBJメッセージを送ることができるかどうかを見ます。 私たちがICP_OP_HIT_OBJを使用できる、:
o The ICP_OP_QUERY message had the ICP_FLAG_HIT_OBJ flag set.
o ICP_OP_QUERYメッセージで、ICP_FLAG_HIT_OBJ旗を設定しました。
Wessels & Claffy Informational [Page 10] RFC 2187 ICP September 1997
[10ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
o The entire object (plus URL) will fit in an ICP message. The
maximum ICP message size is 16 Kbytes, but an application may
choose to set a smaller maximum value for ICP_OP_HIT_OBJ
replies.
o 全体の物(プラスURL)はICPメッセージをうまくはめ込むでしょう。 最大のICPメッセージサイズは16キロバイトですが、アプリケーションは、ICP_OP_HIT_OBJ回答によりわずかな最大値を設定するのを選ぶかもしれません。
Normally ICP replies are sent immediately after the query is received, but the ICP_OP_HIT_OBJ message cannot be sent until the object data is available to copy into the reply message. For Squid and Harvest this means the object must be "swapped in" from disk if it is not already in memory. Therefore, on average, an ICP_OP_HIT_OBJ reply will have higher latency than ICP_OP_HIT.
通常、質問が受け取られている直後ICP回答を送りますが、物のデータが応答メッセージにコピーするために利用可能になるまで、ICP_OP_HIT_OBJメッセージは送ることができません。 Squidとハーベストに関しては、それがメモリに既にないなら、これは、物がディスクから「交換されなければならないこと」を意味します。 したがって、ICP_OP_HIT_OBJ回答には、平均的に、ICP_OP_HITより高い潜在があるでしょう。
5.2.4. ICP_OP_MISS_NOFETCH
5.2.4. _ICP_オプアートミス_NOFETCH
At this point we have a cache miss. ICP has two types of miss replies. If the cache does not want the peer to request the object from it, it sends an ICP_OP_MISS_NOFETCH message.
ここに、私たちはキャッシュを取り逃がさせます。 ICPには、2つのタイプのミス回答があります。 キャッシュが、同輩がそれから物を要求する必要がないなら、それはICP_OP_さん_NOFETCHメッセージを送ります。
5.2.5. ICP_OP_MISS
5.2.5. ICP_オプアート_ミス
Finally, an ICP_OP_MISS reply is returned as the default. If the replying cache is a parent of the querying cache, the ICP_OP_MISS indicates an invitation to fetch the URL through the replying cache.
最終的に、デフォルトとしてICP_OPさんという_回答人を返します。 返答キャッシュが質問キャッシュの親であるなら、ICP_OP_さんは返答キャッシュを通してURLをとって来る招待状を示します。
5.3. Receiving ICP Replies
5.3. ICP回答を受け取ります。
Some ICP replies will be ignored; specifically, when any of the following are true:
いくつかのICP回答が無視されるでしょう。 以下のどれかが明確に本当であるときに:
o The reply message originated from an unknown peer.
o 応答メッセージは未知の同輩から発しました。
o The object named by the URL does not exist.
o URLによって指定された物は存在していません。
o The object is already being fetched.
o 物は既にとって来られています。
5.3.1. ICP_OP_DENIED
5.3.1. _が否定したICP_オプアート
If more than 95% of more than 100 replies from a peer cache have been ICP_OP_DENIED, then such a high denial rate most likely indicates a configuration error, either locally or at the peer. For this reason, no further queries will be sent to the peer for the duration of the cache process.
ピアキャッシュからの100以上の回答の95%以上がICP_OP_DENIEDであるなら、そのような高い否定率はたぶん局所的か同輩における構成誤りを示します。 この理由で、キャッシュプロセスの持続時間のためにさらなる質問を全く同輩に送らないでしょう。
5.3.2. ICP_OP_HIT
5.3.2. ICP_オプアート_ヒット
Object retrieval commences immediately from the replying peer.
オブジェクト検索はすぐ返答している同輩から始まります。
Wessels & Claffy Informational [Page 11] RFC 2187 ICP September 1997
[11ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
5.3.3. ICP_OP_HIT_OBJ
5.3.3. ICP_オプアート_は_OBJに当りました。
The object data is extracted from the ICP message and the retrieval is complete. If there is some problem with the ICP_OP_HIT_OBJ message (e.g. missing data) the reply will be treated like a standard ICP_OP_HIT.
オブジェクトデータはICPメッセージから抜粋されます、そして、検索は完全です。 ICP_OP_HIT_OBJメッセージ(例えば、欠測値)に関する何らかの問題があると、回答は標準の_ICP_OP HITのように扱われるでしょう。
5.3.4. ICP_OP_SECHO
5.3.4. ICP_オプアート_SECHO
Object retrieval commences immediately from the origin server because the ICP_OP_SECHO reply arrived prior to any ICP_OP_HIT's. If an ICP_OP_HIT had arrived prior, this ICP_OP_SECHO reply would be ignored because the retrieval has already started.
ICP_OP_SECHO回答がHITのどんなICP_OP_ところの前でも到着したので、オブジェクト検索はすぐ発生源サーバから始まります。 ICP_OP_HITが優先的に到着したなら、検索が既に始まったので、このICP_OP_SECHO回答は無視されるでしょう。
5.3.5. ICP_OP_DECHO
5.3.5. ICP_オプアート_DECHO
An ICP_OP_DECHO reply is handled like an ICP_OP_MISS. Non-ICP peers must always be configured as parents; a non-ICP sibling makes no sense. One serious problem with the ICP_OP_DECHO feature is that since it bounces messages off the peer's UDP echo port, it does not indicate that the peer cache is actually running -- only that network connectivity exists between the pair.
ICP_OP_DECHO回答は_ICPのように扱われて、両親としていつもOP_ミシシッピー州Non-ICP同輩を構成しなければならないということです。 非ICP兄弟は意味をなさないです。 ICP_OP_DECHOの特徴の1つの深刻な問題は同輩のUDPエコーポートでメッセージを弾ませるのでピアキャッシュは実際に稼働しています--ネットワークの接続性が組の間に存在するだけであるのを示さないということです。
5.3.6. ICP_OP_MISS
5.3.6. ICP_オプアート_ミス
If the peer is a sibling, the ICP_OP_MISS reply is ignored. Otherwise, the peer may be "remembered" for future use in case no HIT replies are received later (section 5.3.9).
同輩が兄弟、_OP_さんが無視されると返答するICPであるなら。 さもなければ、同輩は、後で(セクション5.3.9)HIT回答を全く受け取らないといけないので、今後の使用のために「覚えていられるかもしれません」。
Harvest and Squid remember the first parent to return an ICP_OP_MISS message. With Squid, the parents may be weighted so that the "first parent to miss" may not actually be the first reply received. We call this the FIRST_PARENT_MISS. Remember that sibling misses are entirely ignored, we only care about misses from parents. The parent miss RTT's can be weighted because sometimes the closest parent is not the one people want to use.
取り入れてください。そうすれば、SquidはICP_OPさんという_メッセージ人を返す最初の親を覚えています。 Squidと共に、両親は、「いなくて寂しい最初の親」が実際に受け取られた最初の回答でないように重荷を負わせられるかもしれません。 _兄弟ミスはPARENT_ミシシッピー州Rememberですが、無視されて、私たちは、これを完全にFIRSTと呼んで、両親からミスを心配するだけです。 時々最も近い親が1人の人が欲しいということでないので、親ミスRTTのものに使用に重みを加えることができます。
Also, recent versions of Squid may remember the parent with the lowest RTT to the origin server, using the ICP_FLAG_SRC_RTT option. We call this the CLOSEST_PARENT_MISS.
また、Squidの最近のバージョンは最も低いRTTと共に発生源サーバに親を覚えているかもしれません、ICP_FLAG_SRC_RTTオプションを使用して。 私たちは、CLOSEST_PARENT_ミシシッピー州にこれに電話をします。
5.3.7. ICP_OP_MISS_NOFETCH
5.3.7. _ICP_オプアートミス_NOFETCH
This reply is essentially ignored. A cache must not forward a request to a peer that returns ICP_OP_MISS_NOFETCH.
この回答は本質的には無視されます。 キャッシュはICP_OP_さん_NOFETCHを返す同輩に要求を転送してはいけません。
Wessels & Claffy Informational [Page 12] RFC 2187 ICP September 1997
[12ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
5.3.8. ICP_OP_ERR
5.3.8. ICP_オプアート_は間違えます。
Silently ignored.
静かに無視されています。
5.3.9. When all peers MISS.
5.3.9. いつのすべての同輩ミシシッピー州
For ICP_OP_HIT and ICP_OP_SECHO the request is forwarded immediately. For ICP_OP_HIT_OBJ there is no need to forward the request. For all other reply opcodes, we wait until the expected number of replies have been received. When we have all of the expected replies, or when the query timeout occurs, it is time to forward the request.
ICP_OP_HITとICP_OP_SECHOに関しては、すぐに、要求を転送します。 ICP_OP_において、そこのHIT_OBJは要求を転送する必要性ではありません。 他のすべての回答opcodesを、私たちは回答の予想された数を受け取るまで待ちます。 私たちには予想された回答のすべてがあるか、または質問タイムアウトが起こるとき、もう要求を転送するべき時間です。
Since MISS replies were received from all peers, we must either select a parent cache or the origin server.
すべての同輩から回答さんを受け取ったので、私たちは親キャッシュか発生源サーバを選択しなければなりません。
o If the peers are using the ICP_FLAG_SRC_RTT feature, we forward
the request to the peer with the lowest RTT to the origin
server. If the local cache is also measuring RTT's to origin
servers, and is closer than any of the parents, the request is
forwarded directly to the origin server.
o 同輩がICP_FLAG_SRC_RTTの特徴を使用しているなら、私たちは発生源サーバへの最も低いRTTをもっている同輩に要求を転送します。ローカルなキャッシュはまた、発生源サーバにRTTのものを測定していて、両親のどれかより近くにあるなら、直接発生源サーバに要求を転送します。
o If there is a FIRST_PARENT_MISS parent available, the request
will be forwarded there.
o FIRST_PARENTさんという手があいている_親人がいると、要求をそこに転送するでしょう。
o If the ICP query/reply exchange did not produce any appropriate
parents, the request will be sent directly to the origin server
(unless firewall restrictions prevent it).
o ICP質問/回答交換がどんな適切な両親も生産しなかったなら、直接発生源サーバに要求を送るでしょう(ファイアウォール制限がそれを防がないなら)。
5.4. ICP Options
5.4. ICPオプション
The following options were added to Squid to support some new features while maintaining backward compatibility with the Harvest implementation.
以下のオプションは、ハーベスト実装との後方の互換性を維持している間、いくつかの新機能をサポートするためにSquidに加えられました。
5.4.1. ICP_FLAG_HIT_OBJ
5.4.1. ICP_旗の_は_OBJに当りました。
This flag is off by default and will be set in an ICP_OP_QUERY message only if these three criteria are met:
この旗は、デフォルトでオフであり、これらの3つの評価基準が満たされる場合にだけ、ICP_OP_QUERYメッセージに設定されるでしょう:
o It is enabled in the cache configuration file with `udp_hit_obj
on'.
o それはキャッシュ構成ファイルで'udp_が_objに当って、オンにしました'で可能にされます。
o The peer must be using ICP version 2.
o 同輩はICPバージョン2を使用しなければなりません。
o The HTTP request must not include the "Pragma: no-cache" header.
o HTTP要求が含んではいけない、「Pragma:」 「キャッシュがありません」ヘッダー。
Wessels & Claffy Informational [Page 13] RFC 2187 ICP September 1997
[13ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
5.4.2. ICP_FLAG_SRC_RTT
5.4.2. ICP_旗の_SRC_RTT
This flag is off by default and will be set in an ICP_OP_QUERY message only if these two criteria are met:
この旗は、デフォルトでオフであり、これらの2つの評価基準が満たされる場合にだけ、ICP_OP_QUERYメッセージに設定されるでしょう:
o It is enabled in the cache configuration file with `query_icmp
on'.
o それはキャッシュ構成ファイルで'_がicmpする質問'で可能にされます。
o The peer must be using ICP version 2.
o 同輩はICPバージョン2を使用しなければなりません。
6. Firewalls
6. ファイアウォール
Operating a Web cache behind a firewall or in a private network poses some interesting problems. The hard part is figuring out whether the cache is able to connect to the origin server. Harvest and Squid provide an `inside_firewall' configuration directive to list DNS domains on the near side of a firewall. Everything else is assumed to be on the far side of a firewall. Squid also has a `firewall_ip' directive so that inside hosts can be specified by IP addresses as well.
ファイアウォールの後ろ、または、私設のネットワークでウェブキャッシュを操作すると、いくつかのおもしろい問題が引き起こされます。取り入れて、固い部分は、キャッシュが発生源サーバに接続できるかどうか理解しています。Squidは、DNSドメインをファイアウォールの手前側に記載するために'内部_ファイアウォール'構成指示を前提とします。 他の何もかもがファイアウォールを越してあると思われます。 また、イカには'ファイアウォール_ip'指示が、また、IPアドレスでホストの中のそれを指定できるようにあります。
In a simple configuration, a Squid cache behind a firewall will have only one parent cache (which is on the firewall itself). In this case, Squid must use that parent for all servers beyond the firewall, so there is no need to utilize ICP.
簡単な構成では、ファイアウォールの後ろのSquidキャッシュは1つの親キャッシュ(ファイアウォール自体の上にある)しか持たないでしょう。 この場合Squidがファイアウォールを超えたすべてのサーバにその親を使用しなければならないので、ICPを利用する必要は全くありません。
In a more complex configuration, there may be a number of peer caches also behind the firewall. Here, ICP may be used to check for cache hits in the peers. Occasionally, when ICP is being used, there may not be any replies received. If the cache were not behind a firewall, the request would be forwarded directly to the origin server. But in this situation, the cache must pick a parent cache, either randomly or due to configuration information. For example, Squid allows a parent cache to be designated as a default choice when no others are available.
より複雑な構成には、ファイアウォールの後ろにも多くのピアキャッシュがあるかもしれません。 ここで、ICPは、キャッシュヒットがないかどうか同輩でチェックするのに使用されるかもしれません。 ICPが使用されているとき、時折、どんな受け取られていている回答もないかもしれません。 ファイアウォールの後ろにキャッシュがないなら、直接発生源サーバに要求を転送するでしょうに。しかし、この状況で、キャッシュは、無作為か設定情報のため親キャッシュを選ばなければなりません。 どんな他のものも手があいていないとき、例えば、Squidは、親キャッシュがデフォルト選択として指定されるのを許容します。
7. Multicast
7. マルチキャスト
For efficient distribution, a cache may deliver ICP queries to a multicast address, and neighbor caches may join the multicast group to receive such queries.
効率的な分配のために、キャッシュはマルチキャストアドレスへの質問をICPに提供するかもしれません、そして、隣人キャッシュはそのような質問を受けるためにマルチキャストグループに加わるかもしれません。
Current practice is that caches send ICP replies only to unicast addresses, for several reasons:
現在の習慣はキャッシュがいくつかの理由によるユニキャストアドレスだけに関する回答をICPに送るということです:
o Multicasting ICP replies would not reduce the number of packets
sent.
o 減少しないICPがパケットの数を返答するマルチキャスティングが発信しました。
Wessels & Claffy Informational [Page 14] RFC 2187 ICP September 1997
[14ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
o It prevents other group members from receiving unexpected
replies.
o それによって、他のグループのメンバーは予期しない返答を受けることができません。
o The reply should follow unicast routing paths to indicate
(unicast) connectivity between the receiver and the sender since
the subsequent HTTP request will be unicast routed.
o 回答は、その後のHTTP要求がユニキャストになるので受信機と送付者の間の(ユニキャスト)の接続性が掘られたのを示すためにユニキャストルーティング経路に続くべきです。
Trust is an important aspect of inter-cache relationships. A Web cache should not automatically trust any cache which replies to a multicast ICP query. Caches should ignore ICP messages from addresses not specifically configured as neighbors. Otherwise, one could easily pollute a cache mesh by running an illegitimate cache and having it join a group, return ICP_OP_HIT for all requests, and then deliver bogus content.
信頼は相互キャッシュ関係の重要な一面です。 ウェブキャッシュは自動的にマルチキャストICP質問に返答するどんなキャッシュも任せるべきではありません。 キャッシュは隣人として明確に構成されなかったアドレスからのICPメッセージを無視するべきです。 さもなければ、1つは、違法なキャッシュを述べて、仲間に入らせることによって容易にキャッシュメッシュを汚染して、すべての要求のためにICP_OP_HITを返して、次に、にせの内容を提供するかもしれません。
When sending to multicast groups, cache administrators must be careful to use the minimum multicast TTL required to reach all group members. Joining a multicast group requires no special privileges and there is no way to prevent anyone from joining "your" group. Two groups of caches utilizing the same multicast address could overlap, which would cause a cache to receive ICP replies from unknown neighbors. The unknown neighbors would not be used to retrieve the object data, but the cache would constantly receive ICP replies that it must always ignore.
マルチキャストグループに発信するとき、キャッシュ管理者はTTLがすべてのグループのメンバーに届くのを必要とした最小のマルチキャストを使用するのに慎重であるに違いありません。 マルチキャストグループに加わるのは特権を全く必要としません、そして、だれでも「your」のグループに加わるのを防ぐ方法が全くありません。 同じマルチキャストアドレスを利用するキャッシュの2つのグループ(キャッシュに未知の隣人からICP回答を受け取らせる)が重なることができました。 未知の隣人はオブジェクトデータを検索するのに使用されないでしょうが、キャッシュは絶えずそれがいつも無視しなければならないICP回答を受け取るでしょう。
To prevent an overlapping cache mesh, caches should thus limit the scope of their ICP queries with appropriate TTLs; an application such as mtrace[6] can determine appropriate multicast TTLs.
重なっているキャッシュを防ぐために、かみ合ってください、そして、その結果、キャッシュは適切なTTLsとの彼らのICP質問の範囲を制限するべきです。 mtrace[6]などのアプリケーションは適切なマルチキャストTTLsを決定できます。
As mentioned in section 5.1.3, we need to estimate the number of expected replies for an ICP_OP_QUERY message. For unicast we expect one reply for each query if the peer is up. However, for multicast we generally expect more than one reply, but have no way of knowing exactly how many replies to expect. Squid regularly (every 15 minutes) sends out test ICP_OP_QUERY messages to only the multicast group peers. As with a real ICP query, a timeout event is installed and the replies are counted until the timeout occurs. We have found that the received count varies considerably. Therefore, the number of replies to expect is calculated as a moving average, rounded down to the nearest integer.
セクション5.1.3で言及されるように、私たちは、ICP_OP_QUERYメッセージのための予想された回答の数を見積もる必要があります。 ユニキャストのために、同輩が起きているなら、私たちは各質問あたり1つの回答を予想します。 しかしながら、マルチキャストのために、私たちは、一般に1つ以上の回答を予想しますが、ちょうどいくつの回答を予想するかを知る方法を全く持っていません。 定期的の(15分毎)のイカはテストICP_OP_QUERYメッセージをマルチキャストグループの同輩だけに出します。 本当のICP質問で、タイムアウトイベントがインストールされて、タイムアウトが起こるまで回答が数えられるので。 私たちは、容認されたカウントがかなり異なるのがわかりました。 したがって、予想する回答の数は最も近い整数まで一周した移動平均線として計算されます。
Wessels & Claffy Informational [Page 15] RFC 2187 ICP September 1997
[15ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
8. Lessons Learned
8. レッスンは学びました。
8.1. Differences Between ICP and HTTP
8.1. ICPとHTTPの違い
ICP is notably different from HTTP. HTTP supports a rich and sophisticated set of features. In contrast, ICP was designed to be simple, small, and efficient. HTTP request and reply headers consist of lines of ASCII text delimited by a CRLF pair, whereas ICP uses a fixed size header and represents numbers in binary. The only thing ICP and HTTP have in common is the URL.
ICPはHTTPと著しく異なっています。 HTTPは豊かで高性能のセットの特徴をサポートします。 対照的に、ICPは、簡単で、小さく、効率的になるように設計されました。 HTTP要求と回答ヘッダーはCRLF組によって区切られたASCIIテキストの系列から成ります、ICPが固定サイズヘッダーを使用して、バイナリーの数を表しますが。 ICPとHTTPが共通である唯一のものがURLです。
Note that the ICP message does not even include the HTTP request method. The original implementation assumed that only GET requests would be cachable and there would be no need to locate non-GET requests in neighbor caches. Thus, the current version of ICP does not accommodate non-GET requests, although the next version of this protocol will likely include a field for the request method.
ICPメッセージがHTTP要求メソッドを含んでさえいないことに注意してください。 オリジナルの実装はGET要求だけがキャッシュ可能であるだろう、隣人キャッシュには非GET要求の場所を見つける必要は全くないと仮定しました。 したがって、ICPの最新版は非GET要求に対応しません、このプロトコルの次のバージョンがおそらく要求メソッドのための分野を含むでしょうが。
HTTP defines features that are important for caching but not expressible with the current ICP protocol. Among these are Pragma: no-cache, If-Modified-Since, and all of the Cache-Control features of HTTP/1.1. An ICP_OP_HIT_OBJ message may deliver an object which may not obey all of the request header constraints. These differences between ICP and HTTP are the reason we discourage the use of the ICP_OP_HIT_OBJ feature.
HTTPは現在のICPプロトコルでキャッシュに重要な、しかし、表現できない特徴を定義します。 このうち、Pragmaがあります: HTTP/1.1のCache-コントロール機能のキャッシュがなく、以来変更されたIf、およびすべて。 ICP_OP_HIT_OBJメッセージは要求ヘッダー規制のすべてに従わないかもしれないオブジェクトを提供するかもしれません。 ICPとHTTPのこれらの違いは私たちがICP_OP_HIT_OBJの特徴の使用に水をさしている理由です。
8.2. Parents, Siblings, Hits and Misses
8.2. 両親、兄弟、ヒット、およびさん
Note that the ICP message does not have a field to indicate the intent of the querying cache. That is, nowhere in the ICP request or reply does it say that the two caches have a sibling or parent relationship. A sibling cache can only respond with HIT or MISS, not "you can retrieve this from me" or "you can not retrieve this from me." The querying cache must apply the HIT or MISS reply to its local configuration to prevent it from resolving misses through a sibling cache. This constraint is awkward, because this aspect of the relationship can be configured only in the cache originating the requests, and indirectly via the access controls configured in the queried cache as described earlier in section 4.2.
ICPメッセージには分野がないことに注意して、質問キャッシュの意図を示してください。 それはいて、どこにも、ICP要求か回答では、それは、2つのキャッシュには兄弟か親関係があることを示しません。 兄弟キャッシュが「あなたは私からこれを検索できること」ではなく、HITかさんと共に応じることができるだけですか、または「あなたは私からこれを検索できません」。 質問キャッシュは、ミスを決議するのから兄弟キャッシュまでそれを防ぐためにHITか回答さんを地方の構成に適用しなければなりません。 この規制は厄介です、要求を溯源するキャッシュだけ、および間接的により早くセクション4.2で説明されるように質問されたキャッシュで構成されたアクセス制御で関係のこの局面を構成できるので。
Wessels & Claffy Informational [Page 16] RFC 2187 ICP September 1997
[16ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
8.3. Different Roles of ICP
8.3. ICPの異なる役割
There are two different understandings of what exactly the role of ICP is in a cache mesh. One understanding is that ICP's role is only object location, specifically, to provide hints about whether or not a named object exists in a neighbor cache. An implied assumption is that cache hits are highly desirable, and ICP is used to maximize the chance of getting them. If an ICP message is lost due to congestion, then nothing significant is lost; the request will be satisfied regardless.
ICPの役割がキャッシュメッシュのいったい何であるかに関する2回の異なった疎通があります。 1つの理解がICPの役割がオブジェクト位置にすぎないということである、明確に、提供するのは命名されたオブジェクトが隣人キャッシュで存在するかどうかと暗示します。 暗示している仮定はキャッシュヒットが非常に望ましく、ICPがそれらを得るという機会を最大にするのに使用されるということです。 ICPメッセージが混雑のため失われているなら、重要でないものは何でも無くなっています。 要望は不注意に応じるでしょう。
ICP is increasingly being tasked to fill a more complex role: conveying cache usage policy. For example, many organizations (e.g. universities) will install a Web cache on the border of their network. Such organizations may be happy to establish sibling relationships with other, nearby caches, subject to the following terms:
ICPは、より複雑な役割をいっぱいにするためにますます仕事を課されています: キャッシュ用法方針を伝えます。 例えば、多くの組織(例えば、大学)がそれらのネットワークの境界にウェブキャッシュをインストールするでしょう。 そのような組織は次の用語を条件とした他の、そして、近いキャッシュとの兄弟関係を確立するので、満足であるかもしれません:
o Any of the organization's customers or users may request any
object (cached or not).
o 組織の顧客かユーザのいずれもどんなオブジェクト(キャッシュされる)も要求するかもしれません。
o Anyone may request an object already in the cache.
o だれでも既にキャッシュでオブジェクトを要求するかもしれません。
o Anyone may request any object from the organization's servers
behind the cache.
o だれでもキャッシュの後ろで組織のサーバからどんなオブジェクトも要求するかもしれません。
o All other requests are denied; specifically, the organization
will not provide transit for requests in which neither the
client nor the server falls within its domain.
o 他のすべての要求が否定されます。 明確に、組織はクライアントもサーバもドメインの中で転ばない要求のためのトランジットを提供しないでしょう。
To successfully convey policy the ICP exchange must very accurately predict the result (hit, miss) of a subsequent HTTP request. The result may often depend on other request fields, such as Cache- Control. So it's not possible for ICP to accurately predict the result without more, or perhaps all, of the HTTP request.
首尾よく方針を伝えるために、ICP交換は非常に正確に、その後のHTTP要求の結果(当たってください、そして、消える)を予測しなければなりません。 結果はしばしばCacheコントロールなどの他の要求フィールドに依存するかもしれません。 それで、ICPが以上も、または恐らくすべてなしで結果を正確に予測するのは、HTTP要求で可能ではありません。
8.4. Protocol Design Flaws of ICPv2
8.4. ICPv2のプロトコル設計上の欠陥
We recognize certain flaws with the original design of ICP, and make note of them so that future versions can avoid the same mistakes.
私たちがICPの当初の設計がある、ある欠点を認めて、それらのメモを作るので、将来のバージョンは同じ誤りを避けることができます。
o The NULL-terminated URL in the payload field requires stepping
through the message an octet at a time to find some of the
fields (i.e. the beginning of object data in an ICP_OP_HIT_OBJ
message).
o ペイロード分野のNULLによって終えられたURLは、一度に分野のいくつかが(すなわち、ICP_OP_HIT_OBJメッセージのオブジェクトデータの始まり)であることがわかるためにメッセージを通して八重奏を踏むのを必要とします。
Wessels & Claffy Informational [Page 17] RFC 2187 ICP September 1997
[17ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
o Two fields (Sender Host Address and Requester Host Address) are
IPv4 specific. However, neither of these fields are used in
practice; they are normally zero-filled. If IP addresses have a
role in the ICP message, there needs to be an address family
descriptor for each address, and clients need to be able to say
whether they want to hear IPv6 responses or not.
o 2つの分野(送付者Host AddressとRequester Host Address)がIPv4特有です。 しかしながら、これらの分野のどちらも実際には使用されません。 通常、それらは無いっぱいにされます。 IPアドレスにICPメッセージにおける役割があるなら、各アドレスのためのアドレスファミリー記述子があるのが必要です、そして、クライアントは彼らがIPv6応答を聞きたがっているかどうか言うことができる必要があります。
o Options are limited to 32 option flags and 32 bits of option
data. This should be more like TCP, with an option descriptor
followed by option data.
o オプションは32個のオプション旗と32ビットのオプションデータに制限されます。 これはさらにオプションデータがオプション記述子のあとに続いているTCPに似るべきです。
o Although currently used as the cache key, the URL string no
longer serves this role adequately. Some HTTP responses now
vary according to the requestor's User-Agent and other headers.
A cache key must incorporate all non-transport headers present
in the client's request. All non-hop-by-hop request headers
should be sent in an ICP query.
o 現在キャッシュキーとして使用されますが、URLストリングはもう適切にこの役割を受けません。 要請者のUser-エージェントと他のヘッダーに従って、いくつかのHTTP応答が現在、異なります。 キャッシュキーはクライアントのところに出席しているヘッダーが要求するすべての非輸送を取り入れなければなりません。 ICP質問で非ホップごとのすべての要求ヘッダーを送るべきです。
o ICPv2 uses different opcode values for queries and responses.
ICP should use the same opcode for both sides of a two-sided
transaction, with a "query/response" indicator telling which
side is which.
o ICPv2は質問と応答に異なったopcode値を使用します。 ICPは二面のトランザクションの両側に同じopcodeを使用するはずであり、「質問/応答」インディケータが、側がどれであるかを言っていて、どれですか?
o ICPv2 does not include any authentication fields.
o ICPv2はどんな認証分野も含んでいません。
9. Security Considerations
9. セキュリティ問題
Security is an issue with ICP over UDP because of its connectionless nature. Below we consider various vulnerabilities and methods of attack, and their implications.
コネクションレスな本質のためにセキュリティはUDPの上のICPの問題です。 以下では、私たちが様々な脆弱性、攻撃のメソッド、およびそれらの含意を考えます。
Our first line of defense is to check the source IP address of the ICP message, e.g. as given by recvfrom(2). ICP query messages should be processed if the access control rules allow the querying address access to the cache. However, ICP reply messages must only be accepted from known neighbors; a cache must ignore replies from unknown addresses.
私たちの防御の第一線はICPメッセージのソースIPアドレスをチェックすることです、例えば、recvfrom(2)が与えられているように。 アクセス制御規則がキャッシュへのアドレスアクセスを質問に許すなら、ICP質問メッセージは処理されるべきです。 しかしながら、知られている隣人からICP応答メッセージを受け入れるだけでよいです。 キャッシュは未知のアドレスから回答を無視しなければなりません。
Because we trust the validity of an address in an IP packet, ICP is susceptible to IP address spoofing. In this document we address some consequences of IP address spoofing. Normally, spoofed addresses can only be detected by routers, not by hosts. However, the IP Authentication Header[7,8] can be used underneath ICP to provide cryptographic authentication of the entire IP packet containing the ICP protocol, thus eliminating the risk of IP address spoofing.
私たちがIPパケットのアドレスの正当性を信じるので、ICPはIPアドレススプーフィングに影響されやすいです。 本書では私たちはIPアドレススプーフィングのいくつかの結果を扱います。 通常、ルータはホストに検出されるのではなく、偽造しているアドレスを検出できるだけです。 しかしながら、ICPプロトコルを含んでいて、全体のIPパケットの暗号の認証を提供するのにICPの下でIP Authentication Header[7、8]を使用できます、その結果、IPアドレススプーフィングの危険を排除します。
Wessels & Claffy Informational [Page 18] RFC 2187 ICP September 1997
[18ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
9.1. Inserting Bogus ICP Queries
9.1. にせのICP質問を挿入します。
Processing an ICP_OP_QUERY message has no known security implications, so long as the requesting address is granted access to the cache.
ICP_OP_QUERYメッセージを処理するのにおいて、知られているセキュリティ意味が全くありません、キャッシュへのアクセスが要求アドレスに承諾される限り。
9.2. Inserting Bogus ICP Replies
9.2. にせのICP回答を挿入します。
Here we are concerned with a third party generating ICP reply messages which are returned to the querying cache before the real reply arrives, or before any replies arrive. The third party may insert bogus ICP replies which appear to come from legitimate neighbors. There are three vulnerabilities:
ここで、私たちは本当の回答が到着する前、またはどんな回答も到着する前に質問キャッシュに返される応答メッセージをICPに生成する第三者に関係があります。 第三者は正統の隣人から来るように見えるにせのICP回答を挿入するかもしれません。 3つの脆弱性があります:
o Preventing a certain neighbor from being used
o 確信している隣人が使用されるのを防ぎます。
If a third-party could send an ICP_OP_MISS_NOFETCH reply back
before the real reply arrived, the (falsified) neighbor would
not be used.
本当の回答が到着する前に第三者がICP_OP_さん_NOFETCH回答を送ることができるなら、(改竄されます)隣人は使用されないでしょうに。
A third-party could blast a cache with ICP_OP_DENIED messages
until the threshold described in section 5.3.1 is reached,
thereby causing the neighbor relationship to be temporarily
terminated.
セクション5.3.1で説明された敷居に達するまで、第三者はICP_OP_DENIEDメッセージでキャッシュを爆破できました、その結果、隣人関係が一時終えられることを引き起こします。
o Forcing a certain neighbor to be used
o 確信している隣人は使用させられます。
If a third-party could send an ICP_OP_HIT reply back before the
real reply arrived, the (falsified) neighbor would be used.
This may violate the terms of a sibling relationship; ICP_OP_HIT
replies mean a subsequent HTTP request will also be a hit.
本当の回答が到着する前に第三者がICP_OP_HIT回答を送ることができるなら、(改竄されます)隣人は使用されるでしょうに。 これは兄弟関係の用語に違反するかもしれません。 ICP_OP_HIT回答は、また、その後のHTTP要求がヒットになることを意味します。
Similarly, if bogus ICP_OP_SECHO messages can be generated, the
cache would retrieve requests directly from the origin server.
同様に、にせのICP_OP_SECHOメッセージを生成することができるなら、キャッシュは直接発生源サーバからの要求を検索するでしょう。
o Cache poisoning
o キャッシュ中毒
The ICP_OP_HIT_OBJ message is especially sensitive to security
issues since it contains actual object data. In combination
with IP address spoofing, this option opens up the likely
possibility of having the cache polluted with invalid objects.
実際のオブジェクトデータを含んでいるので、ICP_OP_HIT_OBJメッセージは安全保障問題に特に機密です。 IPアドレススプーフィングと組み合わせて、このオプションは無効のオブジェクトでキャッシュを汚染させるありそうな可能性を開けます。
Wessels & Claffy Informational [Page 19] RFC 2187 ICP September 1997
[19ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
9.3. Eavesdropping
9.3. 盗聴
Multicasting ICP queries provides a very simple method for others to "snoop" on ICP messages. If enabling multicast, cache administrators should configure the application to use the minimum required multicast TTL, using a tool such as mtrace[6]. Note that the IP Encapsulating Security Payload [7,9] mechanism can be used to provide protection against eavesdropping of ICP messages.
ICPが質問するマルチキャスティングは他のものがICPメッセージで「詮索する」非常に簡単なメソッドを提供します。 マルチキャストを可能にするなら、キャッシュ管理者は最小の必要なマルチキャストTTLを使用するためにアプリケーションを構成するべきです、mtrace[6]などのツールを使用して。 ICPメッセージの盗聴に対する保護を提供するのにIP Encapsulating Security有効搭載量[7、9]メカニズムを使用できることに注意してください。
Eavesdropping on ICP traffic can provide third parties with a list of URLs being browsed by cache users. Because the Requestor Host Address is zero-filled by Squid and Harvest, the URLs cannot be mapped back to individual host systems.
ICPトラフィックを立ち聞きすると、キャッシュユーザによってブラウズされるURLのリストを第三者に提供できます。 Requestor Host AddressがSquidとハーベストによって無いっぱいにされるので、個々のホストシステムにURLを写像であって戻しできません。
By default, Squid and Harvest do not send ICP messages for URLs containing `cgi-bin' or `?'. These URLs sometimes contain sensitive information as argument parameters. Cache administrators need to be aware that altering the configuration to make ICP queries for such URLs may expose sensitive information to outsiders, especially when multicast is used.
デフォルトで、Squidとハーベストは'cgi-bin'を含むURLへのICPメッセージか'?'を送りません。 これらのURLは議論パラメタとして時々機密情報を含んでいます。 キャッシュ管理者は、作る構成を変更するとICPがそのようなURLのために質問する機密情報が部外者に暴露するかもしれないのを意識している必要があります、特にマルチキャストが使用されているとき。
9.4. Blocking ICP Messages
9.4. ICPメッセージを妨げます。
Intentionally blocked (or discarded) ICP queries or replies will appear to reflect link failure or congestion, and will prevent the use of a neighbor as well as lead to timeouts (see section 5.1.4). If all messages are blocked, the cache will assume the neighbor is down and remove it from the selection algorithm. However, if, for example, every other query is blocked, the neighbor will remain "alive," but every other request will suffer the ICP timeout.
故意に妨げられて、(捨てられる)のICP質問か回答が、リンクの故障か混雑を反映するように見えて、隣人の使用を防いで、タイムアウトに通じるでしょう(セクション5.1.4を見てください)。 すべてのメッセージが妨げられると、キャッシュは、隣人が下がっていると仮定して、選択アルゴリズムからそれを取り除くでしょう。 しかしながら、例えば、他のあらゆる質問が妨げられると、隣人は「生きていた」ままで残るでしょうが、他のあらゆる要求がICPタイムアウトを受けるでしょう。
9.5. Delaying ICP Messages
9.5. ICPメッセージを遅らせます。
The neighbor selection algorithm normally waits for all ICP MISS replies to arrive. Delaying queries or replies, so that they arrive later than they normally would, will cause additional delay for the subsequent HTTP request. Of course, if messages are delayed so that they arrive after the timeout, the behavior is the same as "blocking" above.
通常、隣人選択アルゴリズムは、すべてのICP MISS回答が到着するのを待っています。 通常、そうするだろうより遅く到着するように質問か回答を遅らせると、追加遅れはその後のHTTP要求のために引き起こされるでしょう。 もちろん、メッセージがタイムアウトの後に到着するように遅らせられるなら、振舞いは上で「妨げること」と同じです。
9.6. Denial of Service
9.6. サービス妨害
A denial-of-service attack, where the ICP port is flooded with a continuous stream of bogus messages has three vulnerabilities:
サービス不能攻撃であり、にせのメッセージの連続したストリームはICPポートで浸水するところに3つの脆弱性を持っています:
o The application may log every bogus ICP message and eventually
fill up a disk partition.
o アプリケーションは、あらゆるにせのICPメッセージを登録して、結局、ディスクパーティションを満たすかもしれません。
Wessels & Claffy Informational [Page 20] RFC 2187 ICP September 1997
[20ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
o The socket receive queue may fill up, causing legitimate
messages to be dropped.
o ソケットは、満たすかもしれなくて、下げられるべき正統のメッセージを引き起こしながら、待ち行列を受けます。
o The host may waste some CPU cycles receiving the bogus messages.
o ホストはにせのメッセージを受け取るいくつかのCPUサイクルを浪費するかもしれません。
9.7. Altering ICP Fields
9.7. ICP分野を変更します。
Here we assume a third party is able to change one or more of the ICP reply message fields.
ここで、私たちは、第三者がICP応答メッセージ分野の1つ以上を変えることができると思います。
Opcode
Opcode
Changing the opcode field is much like inserting bogus messages
described above. Changing a hit to a miss would prevent the peer
from being used. Changing a miss to a hit would force the peer to
be used.
opcode分野を変えるのは、上で説明されたにせのメッセージを挿入しているようです。 ヒットをミスに変えるのは、同輩が使用されるのを防ぐでしょう。 ミスをヒットに変えるので、同輩はやむを得ず使用されるでしょう。
Version
バージョン
Altering the ICP version field may have unpredictable consequences
if the new version number is recognized and supported. The
receiving application should ignore messages with invalid version
numbers. At the time of this writing, both version numbers 2 and
3 are in use. These two versions use some fields (e.g. Options)
in a slightly different manner.
ICPバージョン分野を変更するのにおいて、新しいバージョン番号が認識されて、サポートされるなら、予測できない結果があるかもしれません。 受信アプリケーションは無効のバージョン番号があるメッセージを無視するべきです。 この書くこと時点で、両方のバージョンNo.2と3は使用中です。 これらの2つのバージョンがわずかに異なった方法でいくつかの分野(例えば、Options)を使用します。
Message Length
メッセージ長
An incorrect message length should be detected by the receiving
application as an invalid ICP message.
不正確なメッセージ長は無効のICPメッセージとして受信アプリケーションで検出されるべきです。
Request Number
リクエスト番号
The request number is often used as a part of the cache key.
Harvest does not use the request number. Squid uses the request
number in conjunction with the URL to create a cache key.
Altering the request number will cause a lookup of the cache key
to fail. This is similar to blocking the ICP reply altogether.
リクエスト番号はキャッシュキーの一部としてしばしば使用されます。 収穫はリクエスト番号を使用しません。 イカは、キャッシュキーを作成するのにURLに関連してリクエスト番号を使用します。 リクエスト番号を変更すると、失敗するように主要なキャッシュのルックアップは引き起こされるでしょう。 これは全体でICP回答を妨げるのと同様です。
Wessels & Claffy Informational [Page 21] RFC 2187 ICP September 1997
[21ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
There is no requirement that a cache use both the URL and the
request number to locate HTTP requests with outstanding ICP
queries (however both Squid and Harvest do). The request number
must always be the same in the query and the reply. However, if
the querying cache uses only the request number to locate pending
requests, there is some possibility that a replying cache might
increment the request number in the reply to give the false
impression that the two caches are closer than they really are.
In other words, assuming that there are a few ICP requests "in
flight" at any given time, incrementing the reply request number
trick the querying cache into seeing a smaller round-trip time
than really exists.
URLと要求の両方がHTTPの場所を見つけるように付番するキャッシュ使用が傑出しているICPと共に質問(しかしながら、Squidとハーベストがする両方)を要求するという要件が全くありません。 リクエスト番号は質問と回答でいつも同じであるに違いありません。 しかしながら、質問キャッシュが未定の要求の場所を見つけるのにリクエスト番号だけを使用するなら、2つのキャッシュが本当より近くにあるという間違った印象を与えるために、回答には返答キャッシュがリクエスト番号を増加するかもしれない何らかの可能性があります。 言い換えれば、「飛行」といういくつかのICP要求がその時々であると仮定して、回答リクエスト番号を増加して、質問キャッシュが本当に存在しているより小さい往復の時間に遭遇するようにだましてください。
Options
オプション
There is little risk in having the Options bitfields altered. Any
option bit must only be set in a reply if it was also set in a
query. Changing a bit from clear to set is detectable by the
querying cache, and such a message must be ignored. Changing a
bit from set to clear is allowed and has no negative side effects.
Options bitfieldsを変更させるのにおいてリスクがほとんどありません。 また、それが質問で設定されたなら、回答でどんなオプションビットも設定するだけでよいです。 少し変化する、はっきりと、セットするのは質問キャッシュで検出可能であり、そのようなメッセージを無視しなければなりません。 クリアするためにセットから少し変化するのは、許容されていて、有害な副作用を全く持っていません。
Option Data
オプションデータ
ICP_FLAG_SRC_RTT is the only option which uses the Option Data
field. Altering the RTT values returned here can affect the
neighbor selection algorithm, either forcing or preventing the use
of a neighbor.
ICP_FLAG_SRC_RTTはOption Data分野を使用する唯一のオプションです。 ここに返されたRTT値を変更すると、隣人選択アルゴリズムに影響できます、隣人の使用を強制するか、または防いで。
URL
URL
The URL and Request Number are used to generate the cache key.
Altering the URL will cause a lookup of the cache key to fail, and
the ICP reply to be entirely ignored. This is similar to blocking
the ICP reply altogether.
URLとRequest Numberは、キャッシュキーを生成するのに使用されます。 URLを変更するのに、失敗するように主要なキャッシュのルックアップ、およびICP回答を完全に無視するでしょう。 これは全体でICP回答を妨げるのと同様です。
9.8. Summary
9.8. 概要
o ICP_OP_HIT_OBJ is particularly vulnerable to security problems
because it includes object data. For this, and other reasons,
its use is discouraged.
o オブジェクトデータを含んでいるので、ICP_OP_HIT_OBJは特に警備上の問題に被害を受け易いです。 これ、および他の理由で、使用はお勧めできないです。
o Falsifying, altering, inserting, or blocking ICP messages can
cause an HTTP request to fail only in two situations:
o ICPメッセージを改竄するか、変更するか、挿入するか、または妨げると、2つの状況だけに失敗するというHTTP要求は引き起こされる場合があります:
- If the cache is behind a firewall and cannot directly
connect to the origin server.
- キャッシュがファイアウォールの後ろにあって、直接発生源サーバに接続できないなら。
Wessels & Claffy Informational [Page 22] RFC 2187 ICP September 1997
[22ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
- If a false ICP_OP_HIT reply causes the HTTP request to be
forwarded to a sibling, where the request is a cache miss
and the sibling refuses to continue forwarding the request
on behalf of the originating cache.
- 誤ったICP_OP_HIT回答が兄弟に送られるというHTTP要求を引き起こすか、そして、要求がどこでのキャッシュミスであるか、そして、兄弟は、起因するキャッシュを代表して要求を転送し続けるのを拒否します。
o Falsifying, altering, inserting, or blocking ICP messages can
easily cause HTTP requests to be forwarded (or not forwarded) to
certain neighbors. If the neighbor cache has also been
compromised, then it could serve bogus content and pollute a
cache hierarchy.
o ICPメッセージを改竄するか、変更するか、挿入するか、または妨げると、確信している隣人に送られるという(または、進められません)HTTP要求は容易に引き起こされる場合があります。 また、隣人キャッシュが感染されたなら、それは、にせの内容に役立って、キャッシュ階層構造を堕落するかもしれません。
o Blocking or delaying ICP messages can cause HTTP request to be
further delayed, but still satisfied.
o ICPメッセージを妨げるか、または遅らせると、さらに遅らせられますが、まだ満たされているというHTTP要求は引き起こされる場合があります。
10. References
10. 参照
[1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, January 1997.
[1] etフィールディング、R.、アル、「ハイパーテキストはHTTP/1.1インチと、RFC2068、UCアーバイン1997年1月にプロトコルを移します」。
[2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994.
[2] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、CERN、ゼロックスPARC、ミネソタ大学、1994年12月。
[3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and Wessels D., "The Harvest Information Discovery and Access System", Internet Research Task Force - Resource Discovery, http://harvest.transarc.com/.
[3] インターネット研究課題は、射手M.、ダンツィグP.、ハーディーD.、Manber U.、シュワルツM.、ウェセルズD.、および「収穫情報発見とアクセスシステム」と強制します--リソース発見( http://harvest.transarc.com/ )。
[4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National Laboratory for Applied Network Research, http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz.
[4] 適用されたネットワークのための国家の研究所が、ウェセルズD.と、Claffy K.と、「ICPとイカウェブキャッシュ」と研究する、 http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz 。
[5] Wessels D., "The Squid Internet Object Cache", National Laboratory for Applied Network Research, http://squid.nlanr.net/Squid/
[5] ウェセルズD.、「イカインターネットオブジェクトキャッシュ」、適用されたネットワーク調査のための国家の研究所、 http://squid.nlanr.net/Squid/
[6] mtrace, Xerox PARC, ftp://ftp.parc.xerox.com/pub/net- research/ipmulti/.
[6]mtrace、ゼロックスPARC、 ftp://ftp.parc.xerox.com/pub/net- research/ipmulti/。
[7] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995.
[7] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、NRL、1995年8月。
[8] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995.
[8] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、NRL、1995年8月。
[9] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, NRL, August 1995.
[9] アトキンソン、R.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC1827、NRL、1995年8月。
Wessels & Claffy Informational [Page 23] RFC 2187 ICP September 1997
[23ページ]RFC2187ICP1997年9月の情報のウェセルズとClaffy
11. Acknowledgments
11. 承認
The authors wish to thank Paul A Vixie <paul@vix.com> for providing excellent feedback on this document, Martin Hamilton <martin@mrrl.lut.ac.uk> for pushing the development of multicast ICP, Eric Rescorla <ekr@terisa.com> and Randall Atkinson <rja@home.net> for assisting with security issues, and especially Allyn Romanow for keeping us on the right track.
作者がポールA Vixie <paul@vix.com に感謝したがっている、gt;、このドキュメント、マーチン Hamilton <martin@mrrl.lut.ac.uk の素晴らしいフィードバックを提供する、gt;、マルチキャストICP、エリック Rescorla <ekr@terisa.com の開発を押す、gt;、ランドル Atkinson <rja@home.net 、gt;、正しい軌道の上に私たちを閉じ込めるために安全保障問題、および特にアリンRomanowを助けるために。
12. Authors' Addresses
12. 作者のアドレス
Duane Wessels National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093
カリフォルニア ホプキン・ドライブラ・ホーヤ、適用されたネットワーク研究10100 92093へのドウェイン・ウェセルズ国家の研究所
EMail: wessels@nlanr.net
メール: wessels@nlanr.net
K. Claffy National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093
K.はカリフォルニア ホプキン・ドライブラ・ホーヤ、適用されたネットワーク研究10100 92093に国家の研究所をClaffyします。
EMail: kc@nlanr.net
メール: kc@nlanr.net
Wessels & Claffy Informational [Page 24]
ウェセルズとClaffy情報です。[24ページ]
一覧
スポンサーリンク
