RFC2186 日本語訳
2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT=18808 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Wessels
Request for Comments: 2186 K. Claffy
Category: Informational National Laboratory for Applied
Network Research/UCSD
September 1997
コメントを求めるワーキンググループD.ウェセルズの要求をネットワークでつないでください: 2186 K.はカテゴリをClaffyします: 適用されたネットワーク研究/UCSD1997年9月のための情報の国家の研究所
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 version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages[3,5]. 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 to use in selecting the most appropriate location from which to retrieve an object.
このドキュメントは2個のWWWプロキシキャッシュパッケージ[3、5]の中の現在実装されるとしてのインターネットCacheプロトコル(ICPv2)のバージョン2について説明します。 ICPはウェブキャッシュの中で交信するのに使用される軽量のメッセージ・フォーマットです。 ICPは、隣人キャッシュにおける、URLの存在に関してヒントを交換するのに使用されます。 キャッシュは、オブジェクトを検索する最も適切な位置を選択する際に使用する情報を集めるためにICP質問と回答を交換します。
This document describes only the format and fields of ICP messages. A companion document (RFC2187) describes the application of ICP to Web caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use for their own purposes.
このドキュメントはICPメッセージの形式と分野だけについて説明します。 仲間ドキュメント(RFC2187)はICPのアプリケーションについてウェブキャッシュに説明します。 いくつかの独立しているキャッシュ実装が現在、ICPを使用して、私たちは、それら自身の目的の使用を実装して、配布して、広げようとするもののためにICPの既存の実用的な用途を成文化するのが重要であると考えます。
1. Introduction
1. 序論
ICP is a message format used for communicating between Web caches. Although Web caches use HTTP[1] for the transfer of object data, caches benefit from a simpler, lighter communication protocol. ICP is primarily used in a cache mesh to locate specific Web objects in neighboring caches. One cache sends an ICP query to its neighbors. The neighbors send back ICP replies indicating a "HIT" or a "MISS."
ICPはウェブキャッシュの間で交信するのに使用されるメッセージ・フォーマットです。 ウェブキャッシュはオブジェクトデータの転送にHTTP[1]を使用しますが、キャッシュは、より簡単で、より軽い通信プロトコルの利益を得ます。 ICPは、隣接しているキャッシュで特定のウェブオブジェクトの場所を見つけるのにキャッシュメッシュで主として使用されます。 1つのキャッシュがICP質問を隣人に送ります。 隣人はICP回答に「ヒット」か「ミシシッピー州」を示して戻させます。
Wessels & Claffy Informational [Page 1] RFC 2186 ICP September 1997
[1ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
In current practice, ICP is implemented on top of UDP, but there is no requirement that it be limited to UDP. We feel that ICP over UDP offers features important to Web caching applications. An ICP query/reply exchange needs to occur quickly, typically within a second or two. A cache cannot wait longer than that before beginning to retrieve an object. Failure to receive a reply message most likely means the network path is either congested or broken. In either case we would not want to select that neighbor. As an indication of immediate network conditions between neighbor caches, ICP over a lightweight protocol such as UDP is better than one with the overhead of TCP.
実際には、現在のICPはUDPの上で実装されますが、それがUDPに制限されるという要件が全くありません。 私たちは、UDPの上のICPがアプリケーションをキャッシュするウェブに重要な特徴を提供すると感じます。 ICP質問/回答交換は、通常1秒か2秒以内に急速に起こる必要があります。 キャッシュはオブジェクトを検索し始める前のそれより長い間、待つことができません。 応答メッセージを受け取らない場合、たぶんネットワーク経路が充血するか、または壊されることを意味します。 どちらの場合ではも、その隣人を選びたいと思わないでしょう。 隣人キャッシュの間の即座のネットワーク状態のしるしとして、UDPなどの軽量のプロトコルの上のICPはTCPのオーバーヘッドがある1より良いです。
In addition to its use as an object location protocol, ICP messages can be used for cache selection. Failure to receive a reply from a cache may indicate a network or system failure. The ICP reply may include information that could assist selection of the most appropriate source from which to retrieve an object.
オブジェクト位置のプロトコルとしての使用に加えて、キャッシュ選択にICPメッセージを使用できます。 キャッシュから回答を受け取らない場合、ネットワークかシステム障害を示すかもしれません。 ICP回答はオブジェクトを検索する最も適切なソースの選択を促進できた情報を含むかもしれません。
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]を映し出してください。
ICP Message Format
ICPメッセージ・フォーマット
The ICP message format consists of a 20-octet fixed header plus a variable sized payload (see Figure 1).
ICPメッセージ・フォーマットは20八重奏の固定ヘッダーと可変大きさで分けられたペイロードから成ります(図1を見てください)。
NOTE: All fields must be represented in network byte order.
以下に注意してください。 ネットワークバイトオーダーですべての分野を表さなければなりません。
Opcode
One of the opcodes defined below.
以下で定義されたopcodesのOpcode One。
Version
The ICP protocol version number. At the time of this writing,
both versions two and three are in use. This document describes
only version two. The version number field allows for future
development of this protocol.
ICPプロトコルバージョンが付番するバージョン。 この書くこと時点で、両方のバージョン2とthreeは使用中です。 このドキュメントはバージョンtwoだけについて説明します。 バージョンナンバーフィールドはこのプロトコルの今後の開発を考慮します。
Wessels & Claffy Informational [Page 2] RFC 2186 ICP September 1997
[2ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
Message Length
メッセージ長
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Version | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Host Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Payload |
/ /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode| バージョン| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リクエスト番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者ホスト・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 有効搭載量| / / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FIGURE 1: ICP message format.
1図: ICPメッセージ・フォーマット。
The total length (octets) of the ICP message. ICP messages MUST
not exceed 16,384 octets in length.
ICPメッセージの全長(八重奏)。 ICPメッセージは長さにおける1万6384の八重奏を超えてはいけません。
Request Number
An opaque identifier. When responding to a query, this value must
be copied into the reply message.
Number Anの不明瞭な識別子を要求してください。 質問に応じるとき、この値を応答メッセージにコピーしなければなりません。
Options
A 32-bit field of option flags that allows extension of this
version of the protocol in certain, limited ways. See "ICP Option
Flags" below.
ある、限られた道における、プロトコルのこのバージョンの拡大を許すオプション旗のオプションのAの32ビットの分野。 以下の「ICPオプション旗」を見てください。
Option Data
A four-octet field to support optional features. The following
ICP features make use of this field:
オプション機能をサポートするオプションのDataのA4八重奏の分野。 以下のICPの特徴はこの分野を利用します:
The ICP_FLAG_SRC_RTT option uses the low 16-bits of Option Data to
return RTT measurements. The ICP_FLAG_SRC_RTT option is further
described below.
ICP_FLAG_SRC_RTTオプションは、測定値をRTTに返すのにOption Dataの低16ビットを使用します。 ICP_FLAG_SRC_RTTオプションは以下でさらに説明されます。
Wessels & Claffy Informational [Page 3] RFC 2186 ICP September 1997
[3ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
Sender Host Address
The IPv4 address of the host sending the ICP message. This field
should probably not be trusted over what is provided by getpeer-
name(), accept(), and recvfrom(). There is some ambiguity over
the original purpose of this field. In practice it is not used.
IPv4が扱うICPメッセージを送るホストの送付者Host Address。 ()、およびrecvfrom()は、この分野がたぶんgetpeer名()によって提供されるものに関して信じられるべきでないと受け入れます。 この分野の初心の上に何らかのあいまいさがあります。 実際には、それは使用されていません。
Payload
The contents of the Payload field vary depending on the Opcode,
but most often it contains a null-terminated URL string.
しかし、Opcode、たいていそれによって、有効搭載量分野の内容が変える有効搭載量はヌルで終えられたURLストリングを含んでいます。
2. ICP Opcodes
2. ICP Opcodes
The following table shows currently defined ICP opcodes:
以下のテーブルショーは現在、ICP opcodesを定義しました:
Value Name
----- -----------------
0 ICP_OP_INVALID
1 ICP_OP_QUERY
2 ICP_OP_HIT
3 ICP_OP_MISS
4 ICP_OP_ERR
5-9 UNUSED
10 ICP_OP_SECHO
11 ICP_OP_DECHO
12-20 UNUSED
21 ICP_OP_MISS_NOFETCH
22 ICP_OP_DENIED
23 ICP_OP_HIT_OBJ
値の名----- ----------------- 0 1つのICP_オプアートの_の無効のICP_オプアート_質問2ICP_オプアート_ヒット3ICP_オプアート_ミス4ICP_オプアート_が5-9 未使用の10_ICPオプアート_SECHO11ICP_オプアート_DECHO12-20未使用で間違える、NOFETCH22ICP_オプアート_が23ICP_オプアート_を否定した21ICP_オプアート_ミス_は_OBJに当りました。
ICP_OP_INVALID
A place holder to detect zero-filled or malformed messages. A
cache must never intentionally send an ICP_OP_INVALID message.
ICP_OP_ERR should be used instead.
ICP_OP_INVALID Aは、無いっぱいにされたか奇形のメッセージを検出するために所有者を置きます。 キャッシュは故意にICP_OP_INVALIDメッセージを決して送ってはいけません。 ICP_OP_ERRは代わりに使用されるべきです。
ICP_OP_QUERY
A query message. NOTE this opcode has a different payload format
than most of the others. First is the requester's IPv4 address,
followed by a URL. The Requester Host Address is not that of the
cache generating the ICP message, but rather the address of the
caches's client that originated the request. The Requester Host
Address is often zero filled. An ICP message with an all-zero
Requester Host Address address should be taken as one where the
requester address is not specified; it does not indicate a valid
IPv4 address.
ICP_OP_QUERY Aはメッセージについて質問します。 これほどopcodeな注意には、他のものの大部分と異なったペイロード形式があります。 まず最初に、リクエスタのIPv4アドレスがあります、続いて、URLがあります。 Requester Host AddressはICPメッセージを生成するキャッシュのものではなく、むしろ要求を溯源したキャッシュsのクライアントのアドレスです。 しばしばRequester Host Addressはいっぱいにされたゼロです。 オールゼロRequester Host AddressアドレスがあるICP伝言は1としてリクエスタアドレスが指定されないところでみなされるべきです。 それは有効なIPv4アドレスを示しません。
Wessels & Claffy Informational [Page 4] RFC 2186 ICP September 1997
[4ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
ICP_OP_QUERY payload format:
ICP_OP_QUERYペイロード形式:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requester Host Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Null-Terminated URL /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リクエスタホスト・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | /ヌルで終えられたURL///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In response to an ICP_OP_QUERY, the recipient must return one of:
ICP_OP_HIT, ICP_OP_MISS, ICP_OP_ERR, ICP_OP_MISS_NOFETCH,
ICP_OP_DENIED, or ICP_OP_HIT_OBJ.
ICP_OP_QUERYに対応して、受取人は以下について1つを返さなければなりません。 ICP_オプアート_は当ったか、ICP_オプアート_が消えるか、ICP_オプアート_が、ICP_オプアート_ミス_NOFETCH、ICP_オプアート_が間違えることを否定したか、またはICP_オプアート_が_OBJに当りました。
ICP_OP_SECHO
Similar to ICP_OP_QUERY, but for use in simulating a query to an
origin server. When ICP is used to select the closest neighbor,
the origin server can be included in the algorithm by bouncing an
ICP_OP_SECHO message off it's echo port. The payload is simply
the null-terminated URL.
ICP、_ICP_OP_QUERYへのOP_SECHO Similar、発生源サーバに質問をシミュレートすることにおける使用がなければ. いつICPは最も近い隣人を選ぶのに使用されるか、そして、発生源サーバはそれでICP_OP_SECHOメッセージを弾ませるアルゴリズムに含まれているのが、エコーポートであるということであるかもしれません。 ペイロードは単にヌルで終えられたURLです。
NOTE: the echo server will not interpret the data (i.e. we could
send it anything). This opcode is used to tell the difference
between a legitimate query or response, random garbage, and an
echo response.
以下に注意してください。 エコー・サーバーはデータを解釈しないでしょう(すなわち、私たちは何でもそれに送ることができました)。 このopcodeは、正統の質問か応答と、無作為のゴミと、エコー応答の違いを言うのに使用されます。
ICP_OP_DECHO
Similar to ICP_OP_QUERY, but for use in simulating a query to a
cache which does not use ICP. When ICP is used to choose the
closest neighbor, a non-ICP cache can be included in the algorithm
by bouncing an ICP_OP_DECHO message off it's echo port. The
payload is simply the null-terminated URL.
ICP、_ICP_OP_QUERYにもかかわらず、中でICPを使用しないキャッシュに質問をシミュレートする使用のためのOP_DECHO Similar。 ICPが最も近い隣人を選ぶのに使用されるとき、非ICPキャッシュはそれでICP_OP_DECHOメッセージを弾ませるのによるアルゴリズムに含まれているのが、エコーポートであるということであるかもしれません。 ペイロードは単にヌルで終えられたURLです。
NOTE: one problem with this approach is that while a system's echo
port may be functioning perfectly, the cache software may not be
running at all.
以下に注意してください。 このアプローチに関する1つの問題はシステムのエコーポートが完全に機能しているかもしれない間キャッシュソフトウェアが全く動いていないかもしれないということです。
One of the following six ICP opcodes are sent in response to an ICP_OP_QUERY message. Unless otherwise noted, the payload must be the null-terminated URL string. Both the URL string and the Request Number field must be exactly the same as from the ICP_OP_QUERY message.
ICP_OP_QUERYメッセージに対応して以下の6ICP opcodesの1つを送ります。 別の方法で注意されない場合、ペイロードはヌルで終えられたURLストリングであるに違いありません。 URLストリングとRequest Number分野の両方がICP_OP_QUERYメッセージ現在、まさに同じでなければなりません。
Wessels & Claffy Informational [Page 5] RFC 2186 ICP September 1997
[5ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
ICP_OP_HIT
An ICP_OP_HIT response indicates that the requested URL exists in
this cache and that the requester is allowed to retrieve it.
ICP_OP_HIT An ICP_OP_HIT応答は、要求されたURLがこのキャッシュで存在して、リクエスタがそれを検索できるのを示します。
ICP_OP_MISS
An ICP_OP_MISS response indicates that the requested URL does not
exist in this cache. The querying cache may still choose to fetch
the URL from the replying cache.
ICP_OP_さんAn ICP_OP_応答さんは、要求されたURLがこのキャッシュで存在しないのを示します。 質問キャッシュは、返答キャッシュからURLをとって来るのをまだ選んでいるかもしれません。
ICP_OP_ERR
An ICP_OP_ERR response indicates some kind of error in parsing or
handling the query message (e.g. invalid URL).
ICP_OP_ERR An ICP_OP_ERR応答は質問メッセージ(例えば、無効のURL)を分析するか、または扱う際にある種の誤りを示します。
ICP_OP_MISS_NOFETCH
An ICP_OP_MISS_NOFETCH response indicates that this cache is up,
but is in a state where it does not want to handle cache misses.
An example of such a state is during a startup phase where a cache
might be rebuilding its object store. A cache in such a mode may
wish to return ICP_OP_HIT for cache hits, but not ICP_OP_MISS for
misses. ICP_OP_MISS_NOFETCH essentially means "I am up and
running, but please don't fetch this URL from me now."
ICP_OP_さん_NOFETCH An ICP__NOFETCH応答OP_さんは、このキャッシュが上がっているのを示しますが、それがキャッシュミスを扱いたがっていない状態にあります。 そのような状態に関する例が始動段階の間、キャッシュがオブジェクト店を再建しているかもしれないところにあります。 そのようなモードによるキャッシュはミスのためのICP_OP_さんではなく、キャッシュヒットのためにICP_OP_HITを返したがっているかもしれません。 ICP_OP_さん_NOFETCHは、「私が活動していますが、今、私からこのURLをとって来ないでください。」と本質的には意味します。
Note, ICP_OP_MISS_NOFETCH has a different meaning than
ICP_OP_MISS. The ICP_OP_MISS reply is an invitation to fetch the
URL from the replying cache (if their relationship allows it), but
ICP_OP_MISS_NOFETCH is a request to NOT fetch the URL from the
replying cache.
注意、ICP_OP_さん_NOFETCHには、_ミシシッピー州ICP_OP_さんが返答キャッシュからURLをとって来る招待状であると返答するICP_OPと異なった意味がありますが(それらの関係がそれを許容するなら)、ICP_OP_さん_NOFETCHは返答キャッシュからURLをとって来ないという要求です。
ICP_OP_DENIED
An ICP_OP_DENIED response indicates that the querying site is not
allowed to retrieve the named object from this cache. Caches and
proxies may implement complex access controls. This reply must be
be interpreted to mean "you are not allowed to request this
particular URL from me at this particular time."
ICP_OP_DENIED An ICP_OP_DENIED応答は、質問サイトがこのキャッシュから命名されたオブジェクトを検索できないのを示します。 キャッシュとプロキシは、複雑なアクセスがコントロールであると実装するかもしれません。 この回答はそうであるに違いありません。解釈されて、「今この時期に私からこの特定のURLを要求できません。」と意味してください。
Caches receiving a high percentage of ICP_OP_DENIED replies are
probably misconfigured. Caches should track percentage of all
replies which are ICP_OP_DENIED and disable a neighbor which
exceeds a certain threshold (e.g. 95% of 100 or more queries).
ICP_OP_DENIED回答の高率を受けるキャッシュがたぶんmisconfiguredされます。 キャッシュは、ICP_OP_DENIEDであるすべての回答の割合を追跡して、隣人を無効にするべきです(ある敷居(例えば、100以上の質問の95%)を超えています)。
Similarly, a cache should track the percent of ICP_OP_DENIED
messages that are sent to a given address. If the percent of
denied messages exceeds a certain threshold (e.g. 95% of 100 or
more), the cache may choose to ignore all subsequent ICP_OP_QUERY
messages from that address until some sort of administrative
intervention occurs.
同様に、キャッシュは与えられたアドレスに送られるICP_OP_DENIEDメッセージのパーセントを追跡するべきです。 否定されたメッセージのパーセントが、ある敷居(例えば、より100の95%)を超えているなら、キャッシュは、ある種の管理介入が起こるまでそのアドレスからのすべてのその後のICP_OP_QUERYメッセージを無視するのを選ぶかもしれません。
Wessels & Claffy Informational [Page 6] RFC 2186 ICP September 1997
[6ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
ICP_OP_HIT_OBJ
Just like an ICP_OP_HIT response, but the actual object data has
been included in this reply message. Many requested objects are
small enough that it is possible to include them in the query
response and avoid the need to make a subsequent HTTP request for
the object.
ICP_OP_HIT_OBJ JustはICP_OP_HIT応答が好きですが、実際のオブジェクトデータはこの応答メッセージに含まれています。 多くが、オブジェクトが質問応答にそれらを含んで、オブジェクトのためにその後のHTTP要求をする必要性を避けるのが可能であるほど小さいよう要求しました。
CAVEAT: ICP_OP_HIT_OBJ has some negative side effects which make
its use undesirable. It transfers object data without HTTP and
therefore bypasses the standard HTTP processing, including
authorization and age validation. Another negative side effect is
that ICP_OP_HIT_OBJ messages will often be much larger than the
path MTU, thereby causing fragmentation to occur on the UDP
packet. For these reasons, use of ICP_OP_HIT_OBJ is NOT
recommended.
警告: ICP_OP_HIT_OBJには、使用を望ましくなくするいくつかの有害な副作用があります。 それは、HTTPなしでオブジェクトデータを移して、したがって、承認と時代合法化を含む標準のHTTP処理を迂回させます。 別の有害な副作用はICP_OP_HIT_OBJメッセージが経路MTUよりしばしばはるかに大きくなるということです、その結果、断片化がUDPパケットの上に起こることを引き起こします。 これらの理由で、ICP_OP_HIT_OBJの使用は推薦されません。
A cache must not send an ICP_OP_HIT_OBJ unless the
ICP_FLAG_HIT_OBJ flag is set in the query message Options field.
ICP_FLAG_HIT_OBJ旗が質問メッセージOptions分野に設定されない場合、キャッシュはICP_OP_HIT_OBJを送ってはいけません。
ICP_OP_HIT_OBJ payload format:
ICP_OP_HIT_OBJペイロード形式:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Null-Terminated URL /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Object Data /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | /ヌルで終えられたURL///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オブジェクトサイズ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | /オブジェクトデータ///| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving application must check to make sure it actually
receives Object Size octets of data. If it does not, then it
should treat the ICP_OP_HIT_OBJ reply as though it were a normal
ICP_OP_HIT.
受信アプリケーションは、実際にデータのObject Size八重奏を受けるのを確実にするためにチェックしなければなりません。 そうしないなら、それは正常な_ICP_OP HITであるかのようにICP_OP_HIT_OBJ回答を扱うべきです。
NOTE: the Object Size field does not necessarily begin on a 32-bit
boundary as shown in the diagram above. It begins immediately
following the NULL byte of the URL string.
以下に注意してください。 Object Size分野は必ず上のダイヤグラムで示されるように32ビットの境界で始まるというわけではありません。 それはすぐに、URLストリングのNULLバイトに続き始めます。
Wessels & Claffy Informational [Page 7] RFC 2186 ICP September 1997
[7ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
UNRECOGNIZED OPCODES
ICP messages with unrecognized or unused opcodes should be
ignored, i.e. no reply generated. The application may choose to
note the anomalous behaviour in a log file.
認識されていないか未使用のopcodesがあるUNRECOGNIZED OPCODES ICPメッセージは無視されるべきです、すなわち、いいえが発生していた状態で返答します。 アプリケーションは、ログファイルにおける変則的なふるまいに注意するのを選ぶかもしれません。
3. ICP Option Flags
3. ICPオプション旗
0x80000000 ICP_FLAG_HIT_OBJ
This flag is set in an ICP_OP_QUERY message indicating that it is
okay to respond with an ICP_OP_HIT_OBJ message if the object data
will fit in the reply.
0×80000000 HIT_OBJ Thisが旗を揚げさせるICP_FLAG_はオブジェクトデータが回答をうまくはめ込むならICP_OP_HIT_OBJメッセージで応じるのがオーケーであることを示すICP_OP_QUERYメッセージでセットです。
0x40000000 ICP_FLAG_SRC_RTT
This flag is set in an ICP_OP_QUERY message indicating that the
requester would like the ICP reply to include the responder's
measured RTT to the origin server.
0×40000000 応答者を含むICP回答が発生源サーバにRTTを測定したようにSRC_RTT Thisが旗を揚げさせるICP_FLAG_はリクエスタがそうするのを示すICP_OP_QUERYメッセージで用意ができています。
Upon receipt of an ICP_OP_QUERY with ICP_FLAG_SRC_RTT bit set, a
cache should check an internal database of RTT measurements. If
available, the RTT value MUST be expressed as a 16-bit integer, in
units of milliseconds. If unavailable, the responder may either
set the RTT value to zero, or clear the ICP_FLAG_SRC_RTT bit in
the ICP reply. The ICP reply MUST not be delayed while waiting
for the RTT measurement to occur.
ICP_を受け取り次第、ICP_FLAG_SRC_RTTビットがあるOP_QUERYはセットして、キャッシュはRTT測定値の内部のデータベースをチェックするべきです。 利用可能であるなら、16ビットの整数としてユニットのミリセカンドでRTT値を言い表さなければなりません。 入手できないなら、応答者は、RTT値にICP回答でICP_FLAG_SRC_RTTビットをゼロに合わせるか、またはきれいにするように設定するかもしれません。 RTT測定が起こるのを待っている間、ICP回答は遅れてはいけません。
This flag is set in an ICP reply message (ICP_OP_HIT, ICP_OP_MISS,
ICP_OP_MISS_NOFETCH, or ICP_OP_HIT_OBJ) to indicate that the low
16-bits of the Option Data field contain the measured RTT to the
host given in the requested URL. If ICP_FLAG_SRC_RTT is clear in
the query then it MUST also be clear in the reply. If
ICP_FLAG_SRC_RTT is set in the query, then it may or may not be
set in the reply.
この旗はOption Data分野の低16ビットが要求されたURLで与えられているホストに測定RTTを含むのを示すICP応答メッセージ(ICP_OP_HIT、ICP_OP_さん、ICP__NOFETCH OP_さん、またはICP_OP_HIT_OBJ)でセットです。 また、ICP_FLAG_SRC_RTTが質問で明確であるなら、回答で明確であるに違いありません。 ICP_FLAG_SRC_RTTが質問で用意ができているなら、それは回答で設定されるかもしれません。
4. Security Considerations
4. セキュリティ問題
The security issues relating to ICP are discussed in the companion document, RFC2187.
仲間ドキュメント、RFC2187でICPに関連する安全保障問題について議論します。
Wessels & Claffy Informational [Page 8] RFC 2186 ICP September 1997
[8ページ]RFC2186ICP1997年9月の情報のウェセルズとClaffy
5. References
5. 参照
[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. Acknowledgments
6. 承認
The authors wish to thank Paul A Vixie <paul@vix.com> for providing excellent feedback on this document.
作者がポールA Vixie <paul@vix.com に感謝したがっている、gt;、このドキュメントの素晴らしいフィードバックを提供するために。
7. Authors' Addresses
7. 作者のアドレス
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 9]
ウェセルズとClaffy情報です。[9ページ]
一覧
スポンサーリンク
