最終更新日: 2014年1月13日
Squid Home / Index

ディレクティブ: cache_peer

以前の名前:
動作条件:
デフォルト値: none
提案された設定:

階層における他の同類(peer)キャッシュを指定するのに以下形式を使用します。

cache_peer hostname type http-port icp-port [options]

例として:

# proxy icp
# hostname type port port options
# -------------------- -------- ----- ----- -----------
cache_peer parent.foo.net parent 3128 3130 default
cache_peer sib1.foo.net sibling 3128 3130 proxy-only
cache_peer sib2.foo.net sibling 3128 3130 proxy-only
cache_peer example.com parent 80 0 default
cache_peer cdn.example.com sibling 3128 0

type
'parent'(親)、'sibling'(兄弟)、または 'multicast'(マルチキャスト)のいずれか。

http-port:
peer がHTTP要求を受け入れるポート番号。
他のSquidプロキシの場合、これは通常3128です。
Webサーバの場合、これは通常80です。

icp-port:
隣接キャッシュにオブジェクトに関するを照会するために使用します。
peerが、ICPまたはHTCPをサポートしていない場合は0に設定します。
その他の詳細については、下記のICPとHTCPオプションを参照してください。
==== ICP オプション ====

これらのオプションを使用するときは、明示的 icp_port とicp_access を設定しなければなりません。
デフォルトはICPを用いた同類(peer)へ送信をさせません。
no-query:
隣接peerへのICPクエリ(照会)を無効にします。 キャッシュの状態に関わらずpeerへリクエストを渡したい場合に指定します。
multicast-responder
peerとしての名前がマルチキャストグループのメンバー名であることを示します。
ICP照会は peer に直接送信されませんが、ICPの返信はそれから受けとります。
closest-only
ICP_OP_MISSの返答について、CLOSEST_PARENT_MISSesを送るだろう。FIRST_PARENT_MISSesは決してない。
background-ping
ときどき、この隣接へのICP照会を送信します。
これを使用することで、隣接への往復時間(round trip time)が更新されます。通常は、重み付けされたラウンドロビンと組み合わせて使用されます。

==== HTCP オプション ====

これらのオプションを使用するときは、明示的に htcp_port と htcp_access を設定しなければなりません。
デフォルトは HTCP を用いた同類(peer)へ送信をさせません。
htcp:
隣接へのクエリに ICP の代わりに HTCP を送信します。
おそらく、"icp-port"の3130の代わりに4827に設定が必要でしょう。
このディレクティブは、以下に説明するオプションとのカンマ区切りでのリストを受け入れます
htcp=oldsquid
Squidの旧バージョン(2.5以前)にHTCPを送信します。
htcp=no-clr
近隣へHTCPを送信します。しかし、すべてのCLRリクエストを送信しません。 only-clrと共に使用することはできません。
htcp=only-clr
隣接へHTCPを送信します。しかし、CLRリクエスだけを送信します。これは、no-clrと共に使用することはできません。
htcp=no-purge-clr
それがPURGEリクエストに起因しない場合に限り、CLRを含むHTCPを隣接に送信します。
htcp=forward-clr
このプロキシが受信したすべてのHTCP CLRリクエストをpeerにフォワードします。

==== PEER 選択方法 ====

デフォルトの同類(peer)選択方法はICPで、これにより最初に応答したpeerを供給源として使用します。これらのオプションは、より良好な負荷バランシングのために使用することができます。

default
これはpeerが、peer選択の方法のいずれかによっても配置できない場合に、「最後の手段」として使用できる親キャッシュです。
複数指定した場合、最初に指定したものが使用されます。
round-robin
任意のICPクエリがない状態でのラウンドロビン方法の中で使用されるべき、ロード・バランスの親。
weight=N は、偏り(バイアス)を追加するために使用することができます。
weighted-round-robin
往復時間(round trip time)に基づいている各親の周期に、ラウンドロビン方式で使用されるべきロードバランスの親。
weight=N は、偏り(バイアス)を追加するために使用することができます。
carp
CARP配列として使用されるロードバランスの親。
リクエストは、CARP負荷分散ハッシュ関数に基づいてそのウェイトにより、親の間で分配される。
userhash
ロードバランスの親は、クライアントproxy_authやIDENTのユーザー名もとにします。
sourcehash
ロードバランスの親は、クライアントの送信元IPアドレスをもとにします。
multicast-siblings
"multicast"のキャッシュピアに使用される唯一のタイプ。
このマルチキャスト・グループのすべてのメンバーは「親"parent"」ではなく「兄弟"sibling"」の関係を持ちます。
これは、要求されたオブジェクトは、唯一の "親"キャッシュからフェッチされることになるマルチキャストグループです。
例えば、冗長Squidプロキシのプールを構成するときなどで、同じマルチキャストグループのメンバーであることは便利です。
==== PEER 選択オプション ====
weight=N
任意の重み付けによるピア選択メカニズム。ピアの選択に影響を与えるために使用する。
重み(weight)は整数でなければなりません。デフォルトは1であり、大きな重みがより好まれます。
ピアリングプロトコルを使用していない場合、このオプションは、親の選択に影響を与えない。
basetime=N
親の往復時間(round trip times)から減算する基準を指定します。
それは、どの親を呼び出すか推定する際に重みの計算の区分の前に引かれます。
rttが基準時間未満である場合、rttは最小値にセットされます。
ttl=N
このアドレスにマルチキャストICPクエリを送信するときに使用するTTLを指定します。
マルチキャストグループに送信するときにのみ有用。
ICPがランダムなホストから返答すると受け取れないので、'multicast-responder'オプションでピアを他のグループ・メンバーを形成しなければなりません。
no-delay
隣接へのアクセスが遅延プール(delay pools)に影響を及ぼすのを防ぐこと。
digest-url=URL
デフォルトの場所ではなく、指定されたURLの場所からこのホスト用キャッシュダイジェスト(ダイジェストが有効な場合)を取得する。

==== CARP オプション ====

carp-key=key-specification
完全なURLで、ピアに対してハッシュへの別のキーを使用します。
鍵仕様は、カンマ区切りリストで、キーワードは scheme, host, port, path, params で順序は重要ではありません。

==== アクセラレータ(ACCELERATOR) / リバースプロキシ(REVERSE-PROXY) オプション ====

originserver
この親は、オリジンサーバーとしてコンタクトされます。
ピアがウェブサーバである場合のアクセラレータでの設定で使用することを意図しています。
forceddomain=name
このピアに転送されるリクエストのHostヘッダを設定します。
サーバ(ピア)が特定のドメイン名を期待していて、クライアントが他の要求するアクセラレータの設定において便利。
例 example.com や www.example.com
no-digest
キャッシュダイジェストの要求を無効にします。
no-netdb-exchange
ICMP RTTデータベース(NetDB)の要求を無効にします。

==== 認証(AUTHENTICATION) オプション ====

login=user:password
これは、個人/workgroupと親のプロキシ認証が必要な場合。
注意:文字列にはURLエスケープを含むことができる。(例えば、スペースの%20のような)。%を記述する場合には%%とする。
login=PASSTHRU
クライアントからこのピアに受信したログインの詳細を送信。
両方の Proxy- と WWW-Authorization ヘッダは、ピアへの変更なしで渡されます。
これが機能するためにSquidでの認証は要求されません。

注意: これは、認証の任意のフォームを通過しますが、基本認証(Basic auth)については connection-auth オプションが使用されていない限り、基本的な認証はプロキシを介して動作します。
login=PASS
クライアントからこのピアに受信したログインの詳細を送信。
認証は、このオプションによって必要とされていません。

パスオンされたものに client-provided ヘッダーが無かった場合に、外部ACLの user= と password= の結果タグがあるならばユーザ名とパスワードとしてそれを代わりに送信します。

注意: proxy_authを2つのプロキシを組み合わせて実施する場合、HTTPのシングルサインログオンを行うには、それぞれのサーバで同じユーザデータベースを共有する必要があります。
また、これはピアにユーザのプロキシパスワードが公開されることを警告します。注意して利用すること。
login=*:password
固定パスワードを使用して、上流のキャッシュにユーザ名を送信します。
これは、ピアが別の管理ドメイン内にあるときに使用されることを意図されていて、依然として各ユーザを識別するために必要とである。
アスタリスクには、任意のユーザ名に追加されるいくつかの追加の情報が続くことができる。
これは、上記の login=username:password オプションと同様に、このプロキシからピアへのユーザ識別するために使用することができる。
login=NEGOTIATE
これは、個人/workgroupと親のセキュアプロキシ認証が必要な場合。
デフォルトのキータブまたは環境変数の KRB5_KTNAME での定義が最初のプリンシパルで使用されます。

警告: コネクションでは、複数のクライアントからの要求を送信することができる。
ネゴシエーションは、多くの場合、エンドツーエンドの認証とシングル・クライアントを前提としています。ここは厳密には正しくされない。
login=NEGOTIATE:principal_name
これは、個人/workgroupと親のセキュアプロキシ認証が必要な場合。
デフォルトのキータブまたは環境変数の KRB5_KTNAME での定義 がprincipal_name のプリンパルで使用されます。

警告: コネクションでは、複数のクライアントからの要求を送信することができる。
ネゴシエーションは、多くの場合、エンドツーエンドの認証とシングル・クライアントを前提としています。ここは厳密には正しくされない。
connection-auth=on|off
ピアが Microsoftの認証をサポートしている場合に、そこからのチャレンジ(challenges)の受信を無視する必要があります。
デフォルトではautoとなっており、自動的にピアの状態を判断しています。

==== SSL / HTTPS / TLS オプション ====

ssl
SSL / TLSでこのピアへの暗号化接続を行う。
sslcert=/path/to/ssl/certificate
このピアへの接続時に使用するSSLのクライアント証明書。
sslkey=/path/to/ssl/key
上記のsslcertに対応するSSLのプライベートキー。
'sslkey'が指定されていない場合は、'sslcert'には証明書とプライベートキーの両方が結合され含まれているものとして参照される。
sslversion=1|2|3|4|5|6
このピアへの接続時に使用するSSLバージョン
1 = 自動 (default)
2 = SSL v2 only
3 = SSL v3 only
4 = TLS v1.0 only
5 = TLS v1.1 only
6 = TLS v1.2 only
sslcipher=...
このピアに接続するときに使用する有効なSSL暗号のリスト。
ssloptions=...
SSL実装オプションを指定:
NO_SSLv2        SSLv2の使用を許可しない
NO_SSLv3        SSLv3の使用を許可しない
NO_TLSv1        TLSv1.0の使用を許可しない
NO_TLSv1_1      TLSv1.1の使用を許可しない
NO_TLSv1_2      TLSv1.2の使用を許可しない
SINGLE_DH_USE   テンポラリ / 短命(temporary/ephemeral)のDHキー交換を使用するときは、
                必ず新しいキーを作成する。
ALL             OpenSSLによる「無害」であることが示唆された、さまざまなバグの回避策を有効にする。
                これはいくつかの攻撃でSSL / TLSの強度が低下することに注意。

より完全なリストについては、OpenSSLのSSL_CTX_set_optionsマニュアルを参照してください。

sslcafile=...
ピア(peer)の証明書を検証するときに使用する追加のCA証明書を含むファイル。

sslcapath=...
ピア(peer)証明書を検証するときに使用する追加のCA証明書が格納されたディレクトリ。

sslcrlfile=...
ピア証明書を検証する場合、証明書失効リストファイルを使用します。

sslflags=...
SSL実装を変更する各種フラグを指定:
DONT_VERIFY_PEER
ベリファイ(確認)に失敗しても証明書を受け入れます。

NO_DEFAULT_CA
OpenSSLのに組み込まれたデフォルトのCAリストを使用しません。

DONT_VERIFY_DOMAIN
ピア証明書のサーバー名と一致するかどうかを検証しません。
ssldomain=
証明書で広告されるピア名。
受け取ったピア証明書の正当性を検証するために使用します。
指定しない場合、ピア(peer)のホスト名が使用されます。

front-end-https
マイクロソフトOWAの前でのSSLのフロントエンドとしてSquidを使用する際に必要な"Front-End-Https: On"ヘッダを有効にします。
このヘッダの詳細については、MSのKBの文書 Q307347 を参照してください。
autoに設定すると、https://のURLのリクエストの転送の場合にのみヘッダーに追加されます。

==== 一般的(GENERAL) オプション ====

connect-timeout=N
ピアとの接続タイムアウト。
peer_connect_timeout も参照してください。

connect-fail-limit=N
この回数だけピアへの接続を失敗した場合に、ピアはダウンしているマークされる。デフォルトは10。

allow-miss
兄弟ピアに要求を転送するときにSquidの only-if-cached 使用を無効にします。
これは兄弟ピアへのicp_hit_staleの場合に有用です。
このオプションによる転送のループの可能性があるので、このオプションを使用して双方向のピアリングを避ける必要があります。
たとえば、ソースがピアである場合に cache_peer_access を拒否するようにピアからの要求を拒否します。

max-conn=N
Squidはピアに開く可能性の接続の量をこの数で制限する。

name=xxx
ピアへのユニークな名前。
同じホストが異なるポートで複数のピアを持っている場合に必要です。
この名前は、ピアを見分けるためにcache_peer_accessや同じようなディレクティブで使用することができます。
ピア名のACLタイプは、発信アクセスの制御でこれを使用することができます。

no-tproxy
このピアに要求を転送するときに、クライアント偽装のTPROXYサポートを使用しません。
代わりに通常のアドレスを使用します。
これは spoof_client_ip ACLを上書きします。

proxy-only
ピアから取ってきたオブジェクトは、ローカルに保存されません。

Topへ戻る

Copyright© 1998-2014 ROBATA.ORG