HTTP プロキシーキャッシュ¶

HTTP プロキシーキャッシュは頻繁にアクセスされる (ドキュメント、イメージや記事などの) ウェブオブジェクトのコピーを保管することを可能にし、この情報を必要に応じてユーザに配信することを可能にします。これによりパフォーマンスを改善しインターネットのバンド幅を開放して他の作業に使えるようにします。

HTTP ウェブプロキシーキャッシュの理解¶

インターネットのユーザーはインターネットのいたるところに有るウェブサーバにリクエストを送ります。キャッシュサーバーはこれらのリクエストに応答できるように ウェブプロキシサーバー として振る舞わなければなりません。ウェブプロキシサーバーはウェブオブジェクトへのリクエストを受け取った後、リクエストに応答するかオリジンサーバー (リクエストされた情報の原本を保管しているウェブサーバー) に転送します。 Traffic Server のプロキシーは 明示的なプロキシーキャッシュ をサポートし、ユーザーのクライアントソフトウェアは Traffic Server プロキシーに直接リクエストを送るように設定されなければいけません。以降の概要では Traffic Server がリクエストにどのように応答するかを説明します。

Traffic Server がウェブオブジェクトへのクライアントリクエストを受け取ります。
オブジェクトのアドレスを用いて Traffic Server はリクエストされたオブジェクトがオブジェクトデータベース (キャッシュ) 内に存在するかどうかと、存在する場合はその位置を特定しようとします。
オブジェクトがキャッシュにある場合は、 Traffic Server はオブジェクトが提供するのに十分新鮮かどうかを確認します。新鮮な場合、 Traffic Server はそれを キャッシュヒット としてクライアントに提供します (下図参照)。

キャッシュヒット¶
キャッシュのデータが古い場合、 Traffic Server はオリジンサーバーへ接続し、オブジェクトが依然新しいかどうか確認します。( 再確認 ) 新しい場合、 Traffic Server はすぐにキャッシュしているコピーをクライアントに送ります。
オブジェクトがキャッシュに無い場合 (キャッシュミス) やサーバーがキャッシュしたコピーをもはや有効ではないと判断した場合、 Traffic Server はオリジンサーバーからオブジェクトを取得します。オブジェクトはクライアントと Traffic Server のローカルキャッシュに同時に流されます。(下の図を見てください) 続いて起こるオブジェクトへのリクエストはよりはやく提供することができます。それはオブジェクトがキャッシュから直接検索されるからです。

キャッシュミス¶

一般的にキャッシュは前述の概要で説明したものよりも複雑です。詳しく述べると、概要では Traffic Server がどのように新鮮さを保証し、正しい HTTP オブジェクトの代替を提供し、キャッシュできないもしくはするべきではないオブジェクトへのリクエストを扱うかについて説明されていませんでした。次の章はこれらのことについてとても詳しく説明します。

キャッシュされたオブジェクトの新鮮さの保証¶

Traffic Server がウェブオブジェクトへのリクエストを受け取った際、最初にリクエストされたオブジェクトをキャッシュから探します。オブジェクトがキャッシュにある場合、 Traffic Server はオブジェクトが提供するのに十分新しいかどうかを確認します。 Traffic Server は HTTP オブジェクトに作成者が指定した有効期限をサポートしています。 Traffic Server はこれらの有効期限を固く守ります。つまり、どれだけ頻繁にオブジェクトが変更されるかと、管理者が選んだフレッシュネスガイドラインに基づいて、有効期限を選択します。オブジェクトはまた、依然として新しいかどうかをオリジンサーバーへ見に行くことにより、再確認されます。

HTTP オブジェクトの新鮮さ¶

Traffic Server はキャッシュにある HTTP オブジェクトが新鮮かどうかを下記の条件で順番に判定します。

Expires や max-age ヘッダーの確認

いくつかの HTTP オブジェクトは Expire ヘッダーや max-age ヘッダーを含んでいます。これらはオブジェクトがどれくらいの期間キャッシュできるかどうかを明確に定義しています。 Traffic Server はオブジェクトが新しいかどうかを決定するために、現在時刻と有効期限を比較します。
Last-Modified / Date ヘッダーの確認

HTTP オブジェクトが Expire ヘッダーや max-age ヘッダーを持っていない場合、 Traffic Server はフレッシュネスリミットを次の式で計算します。
```
freshness_limit = ( date - last_modified ) * 0.10
```
ここで date はオブジェクトのサーバーレスポンスヘッダー内の日時で、 last_modified は Last-Modified の日時です。 Last-Modified ヘッダーが無い場合は、 Traffic Server はオブジェクトがキャッシュに書かれた日時を使用します。 0.10 (10パーセント) という値はあなたのニーズにより適合するように増やしたり減らしたりすることができます。新鮮さの計算のための期間要素の変更を参照してください。

計算されたフレッシュネスリミットは最小値と最大値に制約されます。詳細は絶対フレッシュネスリミットの設定を参照してください。
絶対フレッシュネスリミットの確認

Expires ヘッダーを持たない HTTP オブジェクトまたは Last-Modified ヘッダーと Date ヘッダーの両方を持たない HTTP オブジェクトに対して Traffic Server は最大と最小のフレッシュネスリミットを使用します。絶対フレッシュネスリミットの設定を参照してください。
cache.config 内の 再確認ルールを確認

再確認ルールは特定の HTTP オブジェクトにフレッシュネスリミットを適用します。特定のドメインや IP アドレスから取得されたオブジェクト、特定の正規表現に URL がマッチするオブジェクト、特定のクライアントからリクエストされたオブジェクト、などに対してフレッシュネスリミットを設定することが出来ます。 cache.config を参照してください。

新鮮さの計算のための期間要素の変更¶

オブジェクトが有効期限に関する情報を持っていない場合、 Traffic Server は Last-Modified と Date ヘッダーから新鮮さを見積もります。デフォルトでは Traffic Server は最後に更新されてからの経過時間の 10 % キャッシュします。必要に応じて、増減することができます。

新鮮さの計算のための期間要素を変更するには：

proxy.config.http.cache.heuristic_lm_factor の値を変更してください。
設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

絶対フレッシュネスリミットの設定¶

いくつかのオブジェクトは Expires ヘッダーを持っていない、あるいは Last-Modified ヘッダーと Date ヘッダーの両方を持っていません。どれだけの時間がこれらのオブジェクトがキャッシュ内で新鮮と見なされるかを制御するには 絶対フレッシュネスリミット を指定してください。

絶対フレッシュネスリミットを指定するには：

records.yaml 内の proxy.config.http.cache.heuristic_min_lifetime 変数と proxy.config.http.cache.heuristic_max_lifetime 変数を編集してください。
設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

必須ヘッダーの記述¶

To further ensure freshness of the objects in the cache, Traffic Server by default caches only HTTP objects with Expires or max-age headers. It can also be configured to cache all objects (including objects with no headers). Different configurations of header requirements would have a noticeable effect on cache hit rate. For instance, if Traffic Server is configured to cache only HTTP objects with Expires or max-age headers (the default setting), then the cache hit rate will be noticeably reduced (since very few objects will have explicit expiration information).

Traffic Server に特定のヘッダを持つオブジェクトをキャッシュするように設定するには:

records.yaml 内の proxy.config.http.cache.required_headers の値を変更してください。
設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

Cache-Control ヘッダー¶

キャッシュ内のオブジェクトが新鮮であっても、クライアントかサーバーがキャッシュからオブジェクトを取得することを妨げるような自身の制約を課すことがしばしばあります。例えば、クライアントがキャッシュから取得したのではないオブジェクトをリクエストするかもしれませんし、キャッシュの取得を許可したとしてもオブジェクトは 10 分より長くキャッシュされることは許可されません。

Traffic Server はキャッシュされたオブジェクトを提供か判定するためにクライアントのリクエストヘッダーとサーバーのレスポンスヘッダーの両方に含まれる Cache-Control ヘッダーを調べます。 Cache-Control ヘッダーはオブジェクトをキャッシュから提供するかどうかに以下のように作用します。

The no-cache header, sent by clients, tells Traffic Server that it should not serve any objects directly from the cache. When present in a client request, Traffic Server will always obtain the object from the origin server. By default, Traffic Server ignores this header. You can configure Traffic Server to honor client no-cache headers. Refer to Configuring Traffic Server to Honor Client no-cache Headers for more information.
サーバーからの max-age ヘッダーはオブジェクトの経過時間と比べられます。経過時間が max-age より小さければオブジェクトは新鮮であり、 Traffic Server のキャッシュから提供することが出来ます。
クライアントからの min-fresh ヘッダーは 受け入れ可能な新鮮さの範囲 です。これはクライアントがオブジェクトは最低でもこの新鮮さを持つことを要求していることを意味します。キャッシュされたオブジェクトが将来最低でもこの新鮮さを保持していなければ、再確認されます。
クライアントからの max-stale ヘッダーは Traffic Server に古すぎない失効したオブジェクトを配信することを許可します。いくつかのブラウザーは特に貧弱なインターネット環境にあるような場合パフォーマンスを向上させるため、わずかに失効したオブジェクトを受け取ることを望むかもしれません。

Traffic Server は Cache-Control による提供可能解析を HTTP フレッシュネス解析の後に行います。例えば、オブジェクトが新鮮だと判定されても経過時間が max-age より大きければ提供されないでしょう。

HTTP オブジェクトの再確認¶

クライアントがリクエストした HTTP オブジェクトがキャッシュにあるが新鮮ではない場合、 Traffic Server はオブジェクトを再確認します。 再確認 とはオリジンサーバーでオブジェクトが変更されていないことを問い合わせることです。再確認の結果は以下のいずれかです:

オブジェクトが依然として新鮮な場合、 Traffic Server はフレッシュネスリミットをリセットして、そのオブジェクトを配信します。
オブジェクトの新しいコピーが有効な場合、 Traffic Server は新しいオブジェクトをキャッシュします。(従って、新鮮ではないコピーは置き換えられます) また、同時にオブジェクトをクライアントに配信します。
オブジェクトがオリジンサーバー上に存在しない場合、 Traffic Server はキャッシュしたコピーを配信しません。
オリジンサーバーが再確認の問い合わせに応答しない場合、 Traffic Server は 111 Revalidation Failed 警告と共に新鮮ではないオブジェクトを配信します。

デフォルトでは Traffic Server はリクエストされた HTTP オブジェクトが新鮮ではないと考えられる場合に再確認します。 Traffic Server のオブジェクトの新鮮さの評価については HTTP オブジェクトの新鮮さで述べられています。次のオプションの一つを選ぶことによって、 Traffic Server が新鮮さを評価する方法を再設定することができます。

Traffic Server considers all HTTP objects in the cache to be stale:: 常にキャッシュの中の HTTP オブジェクトをオリジンサーバーへ再確認します。
Traffic Server considers all HTTP objects in the cache to be fresh:: オリジンサーバーへ HTTP オブジェクトを再確認することはありません。
Traffic Server considers all HTTP objects without Expires or Cache-control headers to be stale:: Expires や Cache-Control ヘッダーのない全ての HTTP オブジェクトを再確認します。

Traffic Server がキャッシュしているオブジェクトを再確認する方法を設定するには cache.config に特定の再確認のルールを設定してください。

再確認のオプションを設定するには

records.yaml の proxy.config.http.cache.when_to_revalidate を編集してください。
設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

コンテンツのキャッシュへのプッシュ¶

Traffic Server はコンテンツ配信に HTTP PUSH メソッドをサポートしています。HTTP PUSH を使用すると、クライアントからのリクエスト無しに直接コンテンツをキャッシュの中に入れることができます。

PUSH リクエスト用の Traffic Server の設定¶

HTTP PUSH を使用してコンテンツをキャッシュの中に入れる前に、 Traffic Server が PUSH リクエストを受け入れるように設定する必要があります。

Edit ip_allow.yaml to allow PUSH from the appropriate addresses.
Update proxy.config.http.push_method_enabled in records.yaml:
```
CONFIG proxy.config.http.push_method_enabled INT 1
```
設定変更を適用するために traffic_ctl config reload を実行してください。

HTTP PUSH の理解¶

PUSH は HTTP 1.1 メッセージフォーマットを使用します。 PUSH リクエストのボディはキャッシュに入れたいレスポンスヘッダーとレスポンスボディを含みます。下記は PUSH リクエストの例です。

PUSH http://www.company.com HTTP/1.0
Content-length: 84

HTTP/1.0 200 OK
Content-type: text/html
Content-length: 17

<HTML>
a
</HTML>

重要

あなたの PUSH ヘッダーは Content-Length を含まなければなりません。 Content-Length の値はヘッダーとボディーのバイト数を含まなければなりません。この値は省略可能ではなく、不適切な (大きすぎる、あるいは小さすぎる) 値は望ましくない振る舞いを引き起こします。

プッシュを手助けするツール¶

Traffic Server にはプッシュのための Perl スクリプト tspush が同梱されており、あなた自身がコンテンツをプッシュするスクリプトをどのように書けばよいかを理解する助けになり得ます。

コンテンツのキャッシュへのピン留め¶

キャッシュのピン留めオプション は特定の時間の間 HTTP オブジェクトをキャッシュに確実に入れておくように Traffic Server を設定します。最もポピュラーなオブジェクトが必要とされるときにキャッシュされていることと、 Traffic Server が重要なオブジェクトを削除することを防ぐことを確実にしたい際にこのオプションが使えます。 Traffic Server は Cache-Control ヘッダーを監視し、本当にキャッシュ可能な場合にオブジェクトをキャッシュに留めます。

キャッシュを留めるルールを設定するためには

Enable proxy.config.cache.permit.pinning in records.yaml:
```
CONFIG proxy.config.cache.permit.pinning INT 1
```
Traffic Server にキャッシュに留めさせたい URL 毎に cache.config にルールを追加してください。例:
```
url_regex=^https?://(www.)?apache.org/dev/ pin-in-cache=12h
```
設定変更を適用するために traffic_ctl config reload を実行してください。

HTTP オブジェクトのキャッシュ¶

Traffic Server がキャッシュしていないウェブオブジェクトへのリクエストを受け取った際、オリジンサーバーからオブジェクトを回収し、クライアントに配信します。その際に、 Traffic Server は将来のリクエストに備えてキャッシュに保存する前に、オブジェクトがキャッシュ可能かどうか確認します。

Traffic Server は設定オプションやファイルに指定したディレクティブと同じように、クライアントやオリジンサーバーからのキャッシュのディレクティブに反応します。

クライアントディレクティブ¶

Configurations can be set to determine whether to cache objects with the following client directives (by default, Traffic Server caches objects with these request headers):

Cache-Control: no-store
Cache-Control: no-cache

To configure Traffic Server to honor the Cache-Control: no-store and Cache-Control: no-cache request headers, refer to Configuring Traffic Server to Honor Client no-cache Headers.
Cookie (テキストオブジェクトに対して)

By default, Traffic Server caches objects served in response to requests that contain cookies (even if the object is text). You can configure Traffic Server to not cache cookied content of any type, cache all cookied content, or cache cookied content that is of image type only. For more information, refer to Caching Cookied Objects.

Configuring Traffic Server to Honor Client no-cache Headers¶

By default, Traffic Server ignores client Cache-Control: no-cache directives. Even if a requested object contains a no-cache directive, Traffic Server serves the object from its cache. You can configure Traffic Server to honor this header and forward the request to the origin server even if it has a fresh copy in cache.

Likewise, by default Traffic Server also ignores client Cache-Control: no-store directives. Traffic Server caches response from the server regardless of the no-store headers from client requests.

You can configure Traffic Server to honor both of these client directives with the following:

records.yaml の proxy.config.http.cache.ignore_client_no_cache を編集してください。
```
CONFIG proxy.config.http.cache.ignore_client_no_cache INT 0
```
設定変更を適用するために traffic_ctl config reload を実行してください。

オリジンサーバーディレクティブ¶

デフォルトでは Traffic Server は次のレスポンスヘッダーを持つオブジェクトをキャッシュしません。

Cache-Control: no-store
Cache-Control: no-cache

To configure Traffic Server to ignore no-cache and no-store headers, refer to Configuring Traffic Server to Ignore Server no-cache Headers.
Cache-Control: private
WWW-Authenticate

To configure Traffic Server to ignore WWW-Authenticate headers and cache the corresponding objects, refer to Configuring Traffic Server to Ignore WWW-Authenticate Headers.
値が 0 (ゼロ)もしくは過去の日付の Expires ヘッダー

サーバーの no-cache ヘッダーを無視する Traffic Server の設定¶

デフォルトでは Traffic Server は Cache-Control: no-cache ディレクティブを正確に守ります。 no-cache ヘッダーが付いているオリジンサーバーからのレスポンスはキャッシュに保存されません。また、以前キャッシュされたオブジェクトのコピーは削除されます。 no-cache ヘッダーを無視するように Traffic Server を設定した場合、 Traffic Server は no-store ヘッダーも無視します。 no-cache ディレクティブを守るデフォルトの振る舞いはほとんどの場合に適切です。

サーバーの no-cache ヘッダーを無視するように Traffic Server を設定するには :

records.yaml の proxy.config.http.cache.ignore_server_no_cache を編集してください。
```
CONFIG proxy.config.http.cache.ignore_server_no_cache INT 1
```
設定変更を適用するために traffic_ctl config reload を実行してください。

WWW-Authenticate ヘッダーを無視する Traffic Server の設定¶

デフォルトでは Traffic Server は WWW-Authenticate レスポンスヘッダーを含むオブジェクトをキャッシュしません。 WWW-Authenticate ヘッダーはクライアントがオリジンサーバーへのチャレンジレスポンス認証の際に使う認証パラメーターを含んでいます。

オリジンサーバーの WWW-Authenticate ヘッダーを無視するように Traffic Server を設定した場合、 WWW-Authenticate ヘッダーを持つ全てのオブジェクトは次のリクエストの為にキャッシュに保存されます。しかし、 WWW-Authenticate ヘッダーを持つオブジェクトをキャッシュしないデフォルトの振る舞いは多くの場合に適切です。 WWW-Authenticate ヘッダーを無視するように Traffic Server を設定するのは HTTP 1.1 に精通してる場合にだけにしてください。

WWW-Authenticate ヘッダーを無視するように Traffic Server を設定するには :

records.yaml の proxy.config.http.cache.ignore_authentication を編集してください。
```
CONFIG proxy.config.http.cache.ignore_authentication INT 1
```
設定変更を適用するために traffic_ctl config reload を実行してください。

設定ディレクティブ¶

クライアントやオリジンサーバーのディレクティブに加えて、 Traffic Server は設定オプションやファイルを通じて設定したディレクティブにも反応します。

次のように Traffic Server を設定することができます。

どんな HTTP オブジェクトもキャッシュしない ( HTTP オブジェクトキャッシュの無効化参照)
動的コンテンツ をキャッシュする。 .asp で終わったり、クエスチョンマーク (?)、セミコロン (;) や cgi を含んでいたりする URL のオブジェクト。より詳しくは動的コンテンツのキャッシュを参照してください。
Cookie: ヘッダーに対して返されるオブジェクトをキャッシュする。クッキーオブジェクトのキャッシュを参照してください。
cache.config ファイルの never-cache ルールに従う。

HTTP オブジェクトキャッシュの無効化¶

デフォルトでは Traffic Server は cache.config ファイルに設定した never-cache アクションルールを除く全ての HTTP オブジェクトをキャッシュします。後述するように HTTP オブジェクトがオリジンサーバーから直接配信され、決してキャッシュされないように HTTP オブジェクトのキャッシュを無効化することができます。

HTTP オブジェクトキャッシュを手動で無効化するには :

Set proxy.config.http.cache.http to 0 in records.yaml.
```
CONFIG proxy.config.http.cache.http INT 0
```
設定変更を適用するために traffic_ctl config reload を実行してください。

動的コンテンツのキャッシュ¶

.asp で終わったり、クエスチョンマーク (?)、セミコロン (;) や cgi を含んでいたりする URL は動的であると考えられます。デフォルトでは Traffic Server は動的コンテンツをキャッシュします。コンテンツが本当に動的である場合にだけ推奨されますが、適切な Cache-Control ヘッダーによって伝えることができないとき、動的だと思われるコンテンツを無視するようにシステムを設定することができます。

動的コンテンツに配慮した Traffic Server の振る舞いを設定するには :

records.yaml の proxy.config.http.cache.cache_urls_that_look_dynamic を編集してください。キャッシュを無効にするには 0 に設定し、明示的にキャッシュを許可するには 1 に設定してください。
```
CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
```
設定変更を適用するために traffic_ctl config reload を実行してください。

クッキーオブジェクトのキャッシュ¶

By default, Traffic Server caches objects served in response to requests that contain cookies. This is true for all types of objects including text.

次のように Traffic Server を設定し直すことができます。

クッキーを含む全てのコンテンツをキャッシュしない
タイプを考慮せずクッキーを含む全てのコンテンツをキャッシュする
クッキーを含む画像のみキャッシュする
Cache all cookied content except text type.

It may be appropriate to configure Traffic Server to not cache cookied text content because object headers are stored along with the object, and personalized cookie header values could be saved with the object. With non-text objects, it is unlikely that personalized headers are delivered or used.

クッキーを含むコンテンツをどのようにキャッシュするか Traffic Server を設定するには :

records.yaml の proxy.config.http.cache.cache_responses_to_cookies を編集してください。
設定変更を適用するために traffic_ctl config reload を実行してください。

オブジェクトの強制キャッシュ¶

Cache-Control レスポンスヘッダーを無視して、特定の期間に特定の URL (動的 URL も含む) をキャッシュすることを Traffic Server に強制することができます。

ドキュメントを強制的にキャッシュするには :

Traffic Server にキャッシュに留めさせたい URL 毎に cache.config にルールを追加してください。
```
url_regex=^https?://(www.)?apache.org/dev/ ttl-in-cache=6h
```
設定変更を適用するために traffic_ctl config reload を実行してください。

HTTP オブジェクトの代替のキャッシュ¶

Some origin servers answer requests to the same URL with a variety of objects. The content of these objects can vary widely, according to whether a server delivers content for different languages, targets different browsers with different presentation styles, or provides different document formats (HTML, XML). Different versions of the same object are termed alternates and are cached by Traffic Server based on Vary response headers. You can also limit the number of alternate versions of an object allowed in the cache.

オブジェクトの代替数の制限¶

Traffic Server がオブジェクト毎にキャッシュする代替数を制限することができます。(デフォルトは 3 です)

重要

全ての代替は同一の URL を持つため、代替の数が多いと Traffic Server のキャッシュパフォーマンスに影響を与えるかもしれません。Traffic Server はインデックス中の URL をとても高速に検索しますが、キャッシュストアの中に使用可能な代替があるかはシーケンシャルにスキャンしなければなりません。

オブジェクトの代替数の制限を変更するには :

Edit proxy.config.cache.limits.http.max_alts in records.yaml.
```
CONFIG proxy.config.cache.limits.http.max_alts INT 5
```
設定変更を適用するために traffic_ctl config reload を実行してください。

トランザクションバッファリング制御¶

デフォルトでは I/O オペレーションは Traffic Server やネットワークやキャッシュが実行できる限り速くフルスピードで実行されます。これはクライアント側のコネクションが遅い場合に、大きなオブジェクトにとって問題になる可能性があります。このような場合、クライアントに送られるのを待っている間、コンテンツはメモリにバッファーされます。これはクライアントのコネクションが早く、オリジンサーバーのコネクションが遅い場合に POST リクエストでも発生し得ます。とても大きなオブジェクトが使われているとこれは Traffic Server のメモリ使用量がとても大きくなる原因になり得ます。 very large

This problem can be ameliorated by controlling the amount of buffer space used by a transaction. A high water and low water mark are set in terms of bytes used by the transaction. If the buffer space in use exceeds the high water mark, the connection is throttled to prevent additional external data from arriving. Internal operations continue to proceed at full speed until the buffer space in use drops below the low water mark and external data I/O is re-enabled.

主に Traffic Server のメモリ使用量を制限することを意図していますが、これはまた大雑把なレートリミッターも提供します。これはバッファーリミットの設定と、外部やトランスフォームの影響により、クライアント側のコネクションを減速させることによります。これはオリジンサーバーへのコネクションがクライアント側のコネクションスピードにより大まかに制限されることをもたします。

Traffic Server はネットワーク I/O をラージチャンク(32K など) で行います。よって、トランザクションバッファリングコントロールの粒度は同じような値に制限されています。

バッファーサイズの計算はトランザクションの全ての要素を含んでいます。これは transform plugins に紐づけられているどんなバッファーも含みます。

Transaction buffering control can be enabled globally by using configuration variables or by TSHttpTxnConfigIntSet() in a plugin.

値	変数	`TSHttpTxnConfigIntSet()` key
バッファーの有効化	`proxy.config.http.flow_control.enabled`	`TS_CONFIG_HTTP_FLOW_CONTROL_ENABLED`
high water の設定	`proxy.config.http.flow_control.high_water`	`TS_CONFIG_HTTP_FLOW_CONTROL_HIGH_WATER_MARK`
low water の設定	`proxy.config.http.flow_control.low_water`	`TS_CONFIG_HTTP_FLOW_CONTROL_LOW_WATER_MARK`

low water マークは high water マークと常に同じか少ないことに注意してください。一方だけを設定すると、もう一方は同じ値に設定されます。

If using TSHttpTxnConfigIntSet(), it must be called no later than TS_HTTP_READ_RESPONSE_HDR_HOOK.

オリジンサーバーへのリクエストの削減(Thundering Herd 問題を避ける)¶

オブジェクトがキャッシュから配信されない場合、リクエストはオリジンサーバーにプロキシーされます。ポピュラーなオブジェクトにとって、これはオリジンサーバーへ多くの同じ様なリクエストを送り、可能性としては計り知れない程の関連したリソースを使うかもしれません。 Traffic Server にはこのシナリオを避けられるいくつかの機能があります。

Read While Writer¶

Traffic Server がオリジンからオブジェクトをフェッチしに行くとき、そしてレスポンスを受け取るとき、受け取ったオブジェクトの background_fill_completed_threshold % が満たされた部分的キャッシュオブジェクトを配信することがどんな数のクライアントにも許されています。

他の HTTP プロキシーはオリジンサーバーからデータを受け取ったらすぐにクライアントがレスポンスを読み始めることを許可していますが、ATS は完全なレスポンスヘッダーを受け取るまでクライアントが読み始めることを許可しません。これは ATS がキャッシュリフレッシュとコールドキャッシュを区別しておらず、そのためレスポンスがキャッシュ可能なものか知る方法がないことの副作用です。

オリジンサーバーからのキャッシュ出来ないレスポンスは一般的は異なるクライアントリクエストに対してユニークなコンテンツなので、 ATS はオブジェクトをキャッシュ出来ると判断するまで read-while-writer を有効にはしません。

ATS で read-while-writer 機能を有効にするには records.yaml で以下の設定を行う必要があります

CONFIG proxy.config.cache.enable_read_while_writer INT 1
CONFIG proxy.config.http.background_fill_active_timeout INT 0
CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
CONFIG proxy.config.cache.max_doc_size INT 0

次の理由により、４つ全ての設定が必要です。

proxy.config.cache.enable_read_while_writer を 1 にセットすると機能を on にします。デフォルトでは off (0) です。

バックグラウンドフィル機能 (proxy.config.http.background_fill_active_timeout と proxy.config.http.background_fill_completed_threshold の両方) は全てのあり得るリクエストでキックされることが許可されているべきです。 writer (ATSがオリジンサーバーへ接続するトリガーとなったオブジェクトリクエストの最初のクライアントセッション) が出て行った場合にこれは重要となります。他のクライアントセッションが writer を引継ぐ必要があります。

そのようにするには、バックグラウンドフィルタイムアウトを設定し、境界点をゼロにするべきです。これは彼らがタイムアウトせずに、キックインすることを常に許可されることを保証します。
proxy.config.cache.max_doc_size は無制限(0)に設定されているべきです。オブジェクトサイズは (訳注: 事前には) 分からないからです。この制限を超えると配信されているオブジェクトのコネクションの切断を引き起こすかもしれません。

一度これらが有効化されると、Squid の Collapesd Forwarding にとても近いが異なるものものができます。

上記の設定に加えて、 proxy.config.cache.read_while_writer.max_retries と proxy.config.cache.read_while_writer_retry.delay の設定はオブジェクトの最初のフラグメントのダウンロードが完了するまで TS が read-while-writer をトリガーすることを試みる回数を制御できます

CONFIG proxy.config.cache.read_while_writer.max_retries INT 10

CONFIG proxy.config.cache.read_while_writer_retry.delay INT 50

Open Read リトライタイムアウト¶

オープンリードリトライ設定は与えられたオブジェクトに対してオリジンサーバーへの並列リクエストの数を減らすことを試みています。あるオブジェクトがオリジンサーバーからフェッチされている間、次のリクエストはオブジェクトがキャッシュから配信できるかどうかを確認する前に proxy.config.http.cache.open_read_retry_time ミリ秒待ちます。オブジェクトが依然としてフェッチされている場合、次のリクエストは proxy.config.http.cache.max_open_read_retries 回リトライします。すると、次のリクエストはオリジンサーバーへのコネクションを自分自身で確立する前に合計で (max_open_read_retries x open_read_retry_time) ミリ秒待ちます。例えばそれぞれ 5 や 10 にセットされた場合、このリクエストが許可されるまでコネクションは前回のリクエストがオリジンからレスポンスが帰ってくる間 50ms 待ちます。

重要

これらの設定はオブジェクトがキャッシュ不可能な場合、適切ではありません。これらの場合、オブジェクトへのリクエストは実際には直列になります。次のリクエストはオリジンにプロキシーされる前に少なくとも open_read_retry_time ミリ秒待たされるでしょう。

この設定は大きな (転送に (max_open_read_retries x open_read_retry_time) ミリ秒以上かかる) キャッシュ可能なオブジェクトの Read While Writer と共に使うように設定することが望ましいです。 read-while-writer 設定を有効化しないと、初回のフェッチが行われている間、次のリクエストが最大限遅れるだけではなく、結果としてオリジンサーバーへの不要なリクエストを発生させます。

ATS はリクエスト毎や remap ルールに設定することをサポートしているので、これはより簡単に適切に設定することができます。

設定 (とそのデフォルト値) は

CONFIG proxy.config.http.cache.max_open_read_retries INT -1
CONFIG proxy.config.http.cache.open_read_retry_time INT 10

デフォルトはこの機能が無効化されていて、全てのコネクションはオリジンに人為的な遅延無しに行くことを許可されていることを意味します。有効化した場合、open_read_retry_time タイムアウト毎に max_open_read_retries 回試すでしょう。

Open Write 失敗時のアクション¶

オープンリードリトライ設定に加えて TS は新しい設定 proxy.config.http.cache.open_write_fail_action をサポートします。これは複数の同時リクエストが同じオブジェクトを求めてオリジンにヒットすることをより一層減らします。それは1つのリクエストを除く全てのリクエストに対して、 hit-stale の場合には新鮮でないコピーを返すかキャッシュミスの場合にはエラーを返すことで実現します。