Article delegate-ja/449 of [1-661] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A448@delegate-ja.ML_>]
Newsgroups: mail-lists.delegate-ja

[DeleGate-Ja] Re: [DeleGate-Ja] キャッシュの有効期限について(EXPIRE)
04 Jun 2010 18:38:41 GMT ysato@delegate.org (Yutaka Sato)
The DeleGate Project


In message <_A448@delegate-ja.ML_> on 06/04/10(17:52:41)
you Takashi Takamori <pweaqbrv6-aipitiezyktr.ml@ml.delegate.org> wrote:
 |こんにちは。日立の高森と申します。
 |
 |EXPIRE設定時の動作について、教えてください。
 |
 |例えば、現時点で下記のような設定がされているとします。
 |
 |    :
 |EXPIRE=1s
 |    :
 |
 |この設定の場合は、全てのキャッシュデータにおいて1秒以上経過したものは、
 |DeleGateがそのキャッシュデータを無視する動作になるかと思います。

無視する、わけではありません。

まず基本的なこととしてHTTPでは、キャッシュデータの日付より、サーバ上の元の
データが新しかった場合にだけ、元のデータの実体がサーバから返送されます。
サーバ上の元のデータに変更が無い場合には、サーバは、変更されてないという
事実だけを返します。
この際、キャッシュデータの日付として用いられるのが、キャッシュされたレスポンス
ヘッダ中の"Last-Modified:日付"であり、これがリクエストフィールドに
"If-Modified-Since:日付"としてサーバへ送られ、変更無しの場合にそれを通知する
レスポンスコードが"304"です。

さて、DeleGateでは、キャッシュデータを格納するキャッシュファイルの日付が
「EXPIRE」で指定する期限より新しい場合には、上記のようなサーバへの問い合わせ
は行なわず、DeleGateから即座に応答が返されます。
つまり、EXPIREは「キャッシュされた後、サーバへの問い合わせ(更新の確認)無しに
クライアント応答を返す期間」を指定しています。
EXPIREの期限内のキャッシュデータに対して、クライアントからのリクエストが
"If-Modified-Since" 付きで、変更が無い場合には、上述と同様な"304"応答が
クライアントに返されます。
また、もしサーバとの間の接続に何らかの問題が生じて、交信が不能になった場合
(応答が得られない場合)には、EXPIREの値によらず、キャッシュされたデータが
クライアントに返送されます。

つまり、EXPIRE=1s (1秒)で期待されるのは、サーバとの通信データ量の削減
(多くの場合サーバから返される応答は"304")と、サーバへの接続不可の際の
バックアップ機能ということになります。

ここで注意すべきことは、DeleGateが何らかのフィルター機能付きで動作している
場合、この機能がデフォルトでは無効にされていることです。具体的には、
"Last-Modified"で示されるデータの日付よりもDeleGateの構成日付(ETCDIR/params
下にあるパラメタセットの最終変更日付)が新しい場合には、"304"を返すべき状況
でも、データの実体付きで(応答コード"200"などで)レスポンスを返します。
これは、DeleGateで(応答に対して加工を行なう)フィルターを変更した場合には、
その新たなフィルターは、クライアントにキャッシュされたデータにも再適用されな
ければならないからです。

もう一点同様に注意すべきことは、DeleGateが何らかのフィルター機能付き、ある
いはキャッシュ付きで動作している場合に、かつそのホスト上で gzip 機能(Zlib)が
無効である場合には、サーバからの応答に対する圧縮が無効になるようになっている
ことです。こちらについては、最近のほとんどのUnix上ではデフォルトでZlibが
あるので問題ありません。Windows上では、DeleGateのバイナリと一緒に配布してい
るZlibのDLLが必要です。

さて、長くなりましたが、DeleGateのMITMを利用する場合、上述のような「フィルタ
機能付き」の動作とみなされるため、"304"応答によるデータ転送量の削減機能が
デフォルトでは働かないことがある(DeleGateの構成日付との関係による)、という
ことです。
SSLというフィルタそれ自体は、転送されるコンテンツに変更を加えない事は明らか
なので、この機能("304"応答から"200"応答への変換)は余計なお世話であり、特に
データの実体が大きい場合には、通信量を増やしてしまうことになります。
そこで、これを回避するために、最近(9.9.8-pre3で)導入されたのが、

  HTTPCONF=bugs:thru-304

というオプションです。このオプションを指定すると、上述のような("304"応答の
"200"応答への)変換は行なわれなくなります。
(将来のDeleGateの版では、これがデフォルトになる可能性があります)


 |そこで、下記のような条件の場合。。。
 | => httpsプロトコルでキャッシュされたものの有効期限は1日として、
 |   それ以外のものについての有効期限は1秒とする。
 |
 |下記のような定義で問題はないでしょうか?
 |    :
 |EXPIRE=1d:https:*:*
 |EXPIRE=1s
 |    :
 |
 |1. EXPIERを複数設定する場合、定義の順序性は存在するのでしょうか?
 |
 |    :
 |EXPIRE=1d:https:*:*
 |EXPIRE=1s
 |    :
 |と、
 |    :
 |EXPIRE=1s
 |EXPIRE=1d:https:*:*
 |    :
 |の意味は違う?

その通りです。
DeleGateのオプションで複数指定可能なものは、MOUNT以外は、与えられた順で
検査されて、最初に条件に適合したものが使われます。


 |2. EXPIREに設定するもので項目について、教えてください。
 |
 |-----抜粋-----
 |EXPIRE parameter*   ==  EXPIRE=validity[/custody][:connMap]
 |           connMap  ==  ProtoList:dstHostList:srcHostList
 |          validity  ==  period
 |           custody  ==  period
 |            period  ==  Num[d|h|m|s]
 |                    --  default: EXPIRE=1h
 |-----抜粋-----
 |
 |validity・・・キャッシュの有効期限
 |custody・・・・???
 |ProtoList・・・・・プロトコル
 |dstHostList・・・受信側(DeleGateからみてのサーバ)
 |srcHostList・・・送信側(DeleGateからみてのクライアント)
 |
 |custodyの意味がよく判りませんでした。。。

これは指定しても無視されます。
これは保管期限というつもりで導入する、つもりだったものだったと思いますが、
結局、条件に基づいてキャッシュを削除する機能は、実装しませんでした。

                   9 9  
┌─┐┬┌──┬┐ //\^^ ( e ); {Do the more with the less -- B. Fuller}
├─┤│└─┐│ / 877m\_<   >_ <URL:http://www.delegate.org/delegate/>
┴ └┴──┘┴──────────────────────────────
佐藤豊@情報技術研究部門.産業技術総合研究所(独立行政法人)

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V