Apache Traffic Server 6.2 - en to ja translation catalogue (190 entries)

en: HTTP Proxy Caching
ja: HTTP プロキシーキャッシュ

en: HTTP proxy caching enables you to store copies of frequently-accessed web objects (such as documents, images, and articles) and then serve this information to users on demand. It improves performance and frees up Internet bandwidth for other tasks.
ja: HTTP プロキシーキャッシュは頻繁にアクセスされる (ドキュメント、イメージや記事などの) ウェブオブジェクトのコピーを保管することを可能にし、この情報を必要に応じてユーザに配信することを可能にします。これによりパフォーマンスを改善しインターネットのバンド幅を開放して他の作業に使えるようにします。

en: Understanding HTTP Web Proxy Caching
ja: HTTP ウェブプロキシーキャッシュの理解

en: Internet users direct their requests to web servers all over the Internet. A caching server must act as a *web proxy server* so it can serve those requests. After a web proxy server receives requests for web objects, it either serves the requests or forwards them to the *origin server* (the web server that contains the original copy of the requested information). The Traffic Server proxy supports *explicit proxy caching*, in which the user's client software must be configured to send requests directly to the Traffic Server proxy. The following overview illustrates how Traffic Server serves a request.
ja: インターネットのユーザーはインターネットのいたるところに有るウェブサーバにリクエストを送ります。キャッシュサーバーはこれらのリクエストに応答できるように *ウェブプロキシサーバー* として振る舞わなければなりません。ウェブプロキシサーバーはウェブオブジェクトへのリクエストを受け取った後、リクエストに応答するかオリジンサーバー (リクエストされた情報の原本を保管しているウェブサーバー) に転送します。 Traffic Server のプロキシーは *明示的なプロキシーキャッシュ* をサポートし、ユーザーのクライアントソフトウェアは Traffic Server プロキシーに直接リクエストを送るように設定されなければいけません。以降の概要では Traffic Server がリクエストにどのように応答するかを説明します。

en: Traffic Server receives a client request for a web object.
ja: Traffic Server がウェブオブジェクトへのクライアントリクエストを受け取ります。

en: Using the object address, Traffic Server tries to locate the requested object in its object database (*cache*).
ja: オブジェクトのアドレスを用いて Traffic Server はリクエストされたオブジェクトがオブジェクトデータベース (*キャッシュ*) 内に存在するかどうかと、存在する場合はその位置を特定しようとします。

en: If the object is in the cache, then Traffic Server checks to see if the object is fresh enough to serve. If it is fresh, then Traffic Server serves it to the client as a *cache hit* (see the figure below).
ja: オブジェクトがキャッシュにある場合は、 Traffic Server はオブジェクトが提供するのに十分新鮮かどうかを確認します。新鮮な場合、 Traffic Server はそれを *キャッシュヒット* としてクライアントに提供します (下図参照)。

en: A cache hit
ja: キャッシュヒット

en: If the data in the cache is stale, then Traffic Server connects to the origin server and checks if the object is still fresh (a :term:`revalidation`). If it is, then Traffic Server immediately sends the cached copy to the client.
ja: キャッシュのデータが古い場合、 Traffic Server はオリジンサーバーへ接続し、オブジェクトが依然新しいかどうか確認します。( :term:`再確認` ) 新しい場合、 Traffic Server はすぐにキャッシュしているコピーをクライアントに送ります。

en: If the object is not in the cache (a *cache miss*) or if the server indicates the cached copy is no longer valid, then Traffic Server obtains the object from the origin server. The object is then simultaneously streamed to the client and the Traffic Server local cache (see the figure below). Subsequent requests for the object can be served faster because the object is retrieved directly from cache.
ja: オブジェクトがキャッシュに無い場合 (*キャッシュミス*) やサーバーがキャッシュしたコピーをもはや有効ではないと判断した場合、 Traffic Server はオリジンサーバーからオブジェクトを取得します。オブジェクトはクライアントと Traffic Server のローカルキャッシュに同時に流されます。(下の図を見てください) 続いて起こるオブジェクトへのリクエストはよりはやく提供することができます。それはオブジェクトがキャッシュから直接検索されるからです。

en: A cache miss
ja: キャッシュミス

en: Caching is typically more complex than the preceding overview suggests. In particular, the overview does not discuss how Traffic Server ensures freshness, serves correct HTTP alternates, and treats requests for objects that cannot or should not be cached. The following sections discuss these issues in greater detail.
ja: 一般的にキャッシュは前述の概要で説明したものよりも複雑です。 詳しく述べると、概要では Traffic Server がどのように新鮮さを保証し、正しい HTTP オブジェクトの代替を提供し、キャッシュできないもしくはするべきではないオブジェクトへのリクエストを扱うかについて説明されていませんでした。次の章はこれらのことについてとても詳しく説明します。

en: Ensuring Cached Object Freshness
ja: キャッシュされたオブジェクトの新鮮さの保証

en: When Traffic Server receives a request for a web object, it first tries to locate the requested object in its cache. If the object is in cache, then Traffic Server checks to see if the object is fresh enough to serve. For HTTP objects, Traffic Server supports optional author-specified expiration dates. Traffic Server adheres to these expiration dates; otherwise, it picks an expiration date based on how frequently the object is changing and on administrator-chosen freshness guidelines. Objects can also be revalidated by checking with the origin server to see if an object is still fresh.
ja: Traffic Server がウェブオブジェクトへのリクエストを受け取った際、最初にリクエストされたオブジェクトをキャッシュから探します。オブジェクトがキャッシュにある場合、 Traffic Server はオブジェクトが提供するのに十分新しいかどうかを確認します。 Traffic Server は HTTP オブジェクトに作成者が指定した有効期限をサポートしています。 Traffic Server はこれらの有効期限を固く守ります。つまり、どれだけ頻繁にオブジェクトが変更されるかと、管理者が選んだフレッシュネスガイドラインに基づいて、有効期限を選択します。オブジェクトはまた、依然として新しいかどうかをオリジンサーバーへ見に行くことにより、再確認されます。

en: HTTP Object Freshness
ja: HTTP オブジェクトの新鮮さ

en: Traffic Server determines whether an HTTP object in the cache is fresh by checking the following conditions in order:
ja: Traffic Server はキャッシュにある HTTP オブジェクトが新鮮かどうかを下記の条件で順番に判定します。

en: **Checking the** ``Expires`` **or** ``max-age`` **header**
ja: ``Expires`` **や** ``max-age`` **ヘッダーの確認**

en: Some HTTP objects contain ``Expires`` headers or ``max-age`` headers that explicitly define how long the object can be cached. Traffic Server compares the current time with the expiration time to determine if the object is still fresh.
ja: いくつかの HTTP オブジェクトは ``Expire`` ヘッダーや ``max-age`` ヘッダーを含んでいます。これらはオブジェクトがどれくらいの期間キャッシュできるかどうかを明確に定義しています。 Traffic Server はオブジェクトが新しいかどうかを決定するために、現在時刻と有効期限を比較します。

en: **Checking the** ``Last-Modified`` **/** ``Date`` **header**
ja: ``Last-Modified`` **/** ``Date`` **ヘッダーの確認**

en: If an HTTP object has no ``Expires`` header or ``max-age`` header, then Traffic Server can calculate a freshness limit using the following formula::
ja: HTTP オブジェクトが ``Expire`` ヘッダーや ``max-age`` ヘッダーを持っていない場合、 Traffic Server はフレッシュネスリミットを次の式で計算します。

en: where *date* is the date in the object's server response header and *last_modified* is the date in the ``Last-Modified`` header. If there is no ``Last-Modified`` header, then Traffic Server uses the date the object was written to cache. The value ``0.10`` (10 percent) can be increased or reduced to better suit your needs. Refer to `Modifying Aging Factor for Freshness Computations`_.
ja: ここで *date* はオブジェクトのサーバーレスポンスヘッダー内の日時で、 *last_modified* は ``Last-Modified`` の日時です。 ``Last-Modified`` ヘッダーが無い場合は、 Traffic Server はオブジェクトがキャッシュに書かれた日時を使用します。 ``0.10`` (10パーセント) という値はあなたのニーズにより適合するように増やしたり減らしたりすることができます。 `新鮮さの計算のための期間要素の変更`_ を参照してください。

en: The computed freshness limit is bound by a minimum and maximum value. Refer to `Setting Absolute Freshness Limits`_ for more information.
ja: 計算されたフレッシュネスリミットは最小値と最大値に制約されます。詳細は `絶対フレッシュネスリミットの設定`_ を参照してください。

en: **Checking the absolute freshness limit**
ja: **絶対フレッシュネスリミットの確認**

en: For HTTP objects that do not have ``Expires`` headers or do not have both ``Last-Modified`` and ``Date`` headers, Traffic Server uses a maximum and minimum freshness limit. Refer to `Setting Absolute Freshness Limits`_.
ja: ``Expires`` ヘッダーを持たない HTTP オブジェクトまたは ``Last-Modified`` ヘッダーと ``Date`` ヘッダーの両方を持たない HTTP オブジェクトに対して Traffic Server は最大と最小のフレッシュネスリミットを使用します。 `絶対フレッシュネスリミットの設定`_ を参照してください。

en: **Checking revalidate rules in** :file:`cache.config`
ja: :file:`cache.config` 内の **再確認ルールを確認**

en: Revalidate rules apply freshness limits to specific HTTP objects. You can set freshness limits for objects originating from particular domains or IP addresses, objects with URLs that contain specified regular expressions, objects requested by particular clients, and so on. Refer to :file:`cache.config`.
ja: 再確認ルールは特定の HTTP オブジェクトにフレッシュネスリミットを適用します。特定のドメインや IP アドレスから取得されたオブジェクト、特定の正規表現に URL がマッチするオブジェクト、特定のクライアントからリクエストされたオブジェクト、などに対してフレッシュネスリミットを設定することが出来ます。 :file:`cache.config` を参照してください。

en: Modifying Aging Factor for Freshness Computations
ja: 新鮮さの計算のための期間要素の変更

en: If an object does not contain any expiration information, then Traffic Server can estimate its freshness from the ``Last-Modified`` and ``Date`` headers. By default, Traffic Server stores an object for 10% of the time that elapsed since it last changed. You can increase or reduce the percentage according to your needs.
ja: オブジェクトが有効期限に関する情報を持っていない場合、 Traffic Server は ``Last-Modified`` と ``Date`` ヘッダーから新鮮さを見積もります。デフォルトでは Traffic Server は最後に更新されてからの経過時間の 10 % キャッシュします。 必要に応じて、増減することができます。

en: To modify the aging factor for freshness computations:
ja: 新鮮さの計算のための期間要素を変更するには：

en: Change the value for :ts:cv:`proxy.config.http.cache.heuristic_lm_factor`.
ja: :ts:cv:`proxy.config.http.cache.heuristic_lm_factor` の値を変更してください。

en: Run the :option:`traffic_ctl config reload` command to apply the configuration changes.
ja: 設定変更を適用するために :option:`traffic_ctl config reload` コマンドを実行してください。

en: Setting Absolute Freshness Limits
ja: 絶対フレッシュネスリミットの設定

en: Some objects do not have ``Expires`` headers or do not have both ``Last-Modified`` and ``Date`` headers. To control how long these objects are considered fresh in the cache, specify an *absolute freshness limit*.
ja: いくつかのオブジェクトは ``Expires`` ヘッダーを持っていない、あるいは ``Last-Modified`` ヘッダーと ``Date`` ヘッダーの両方を持っていません。どれだけの時間がこれらのオブジェクトがキャッシュ内で新鮮と見なされるかを制御するには *絶対フレッシュネスリミット* を指定してください。

en: To specify an absolute freshness limit:
ja: 絶対フレッシュネスリミットを指定するには：

en: Edit the variables :ts:cv:`proxy.config.http.cache.heuristic_min_lifetime` and :ts:cv:`proxy.config.http.cache.heuristic_max_lifetime` in :file:`records.config`.
ja: :file:`records.config` 内の :ts:cv:`proxy.config.http.cache.heuristic_min_lifetime` 変数と :ts:cv:`proxy.config.http.cache.heuristic_max_lifetime` 変数を編集してください。

en: Specifying Header Requirements
ja: 必須ヘッダーの記述

en: To further ensure freshness of the objects in the cache, configure Traffic Server to cache only objects with specific headers. By default, Traffic Server caches all objects (including objects with no headers); you should change the default setting only for specialized proxy situations. If you configure Traffic Server to cache only HTTP objects with ``Expires`` or ``max-age`` headers, then the cache hit rate will be noticeably reduced (since very few objects will have explicit expiration information).
ja: よりいっそうキャッシュしているオブジェクトの新鮮さを確かめるために、特定のヘッダーを持っているオブジェクトだけをキャッシュするように Traffic Server を設定することができます。デフォルトでは Traffic Server は(ヘッダーがないものも含む)全てのオブジェクトをキャッシュします。特別なプロキシーの状況の場合のみデフォルト設定を変更するべきです。Traffic Server を ``Expires`` もしくは ``max-age`` ヘッダーを持つオブジェクトだけをキャッシュするように設定した場合、キャッシュヒット率は明らかに下がるでしょう。(とても少ないオブジェクトしか明確な有効期限の情報をもっていないと考えられるためです。)

en: To configure Traffic Server to cache objects with specific headers:
ja: Traffic Server に特定のヘッダを持つオブジェクトをキャッシュするように設定するには:

en: Change the value for :ts:cv:`proxy.config.http.cache.required_headers` in :file:`records.config`.
ja: :file:`records.config` 内の :ts:cv:`proxy.config.http.cache.required_headers` の値を変更してください。

en: Cache-Control Headers
ja: Cache-Control ヘッダー

en: Even though an object might be fresh in the cache, clients or servers often impose their own constraints that preclude retrieval of the object from the cache. For example, a client might request that a object not be retrieved from a cache, or if it does allow cache retrieval, then it cannot have been cached for more than 10 minutes.
ja: キャッシュ内のオブジェクトが新鮮であっても、クライアントかサーバーがキャッシュからオブジェクトを取得することを妨げるような自身の制約を課すことがしばしばあります。例えば、クライアントがキャッシュから取得したのではないオブジェクトをリクエストするかもしれませんし、キャッシュの取得を許可したとしてもオブジェクトは 10 分より長くキャッシュされることは許可されません。

en: Traffic Server bases the servability of a cached object on ``Cache-Control`` headers that appear in both client requests and server responses. The following ``Cache-Control`` headers affect whether objects are served from cache:
ja: Traffic Server はキャッシュされたオブジェクトを提供か判定するためにクライアントのリクエストヘッダーとサーバーのレスポンスヘッダーの両方に含まれる ``Cache-Control`` ヘッダーを調べます。 ``Cache-Control`` ヘッダーはオブジェクトをキャッシュから提供するかどうかに以下のように作用します。

en: 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. You can configure Traffic Server to ignore client ``no-cache`` headers. Refer to `Configuring Traffic Server to Ignore Client no-cache Headers`_ for more information.
ja: クライアントからの ``no-cache`` ヘッダーは Traffic Server にどんなオブジェクトもキャッシュから直接提供すべきでないことを伝えます。クライアントリクエストに含まれる場合は、 Traffic Server は常にオブジェクトをオリジンサーバーから取得します。 Traffic Server がクライアントの ``no-cache`` ヘッダーを無視するように設定することも出来ます。詳細は `クライアントの no-cache ヘッダーを無視する Traffic Server の設定`_ を参照してください。

en: The ``max-age`` header, sent by servers, is compared to the object age. If the age is less than ``max-age``, then the object is fresh and can be served from the Traffic Server cache.
ja: サーバーからの ``max-age`` ヘッダーはオブジェクトの経過時間と比べられます。経過時間が ``max-age`` より小さければオブジェクトは新鮮であり、 Traffic Server のキャッシュから提供することが出来ます。

en: The ``min-fresh`` header, sent by clients, is an *acceptable freshness tolerance*. This means that the client wants the object to be at least this fresh. Unless a cached object remains fresh at least this long in the future, it is revalidated.
ja: クライアントからの ``min-fresh`` ヘッダーは *受け入れ可能な新鮮さの範囲* です。これはクライアントがオブジェクトは最低でもこの新鮮さを持つことを要求していることを意味します。キャッシュされたオブジェクトが将来最低でもこの新鮮さを保持していなければ、再確認されます。

en: The ``max-stale`` header, sent by clients, permits Traffic Server to serve stale objects provided they are not too old. Some browsers might be willing to take slightly stale objects in exchange for improved performance, especially during periods of poor Internet availability.
ja: クライアントからの ``max-stale`` ヘッダーは Traffic Server に古すぎない失効したオブジェクトを配信することを許可します。いくつかのブラウザーは特に貧弱なインターネット環境にあるような場合パフォーマンスを向上させるため、わずかに失効したオブジェクトを受け取ることを望むかもしれません。

en: Traffic Server applies ``Cache-Control`` servability criteria after HTTP freshness criteria. For example, an object might be considered fresh but will not be served if its age is greater than its ``max-age``.
ja: Traffic Server は ``Cache-Control`` による提供可能解析を HTTP フレッシュネス解析の後に行います。例えば、オブジェクトが新鮮だと判定されても経過時間が ``max-age`` より大きければ提供されないでしょう。

en: Revalidating HTTP Objects
ja: HTTP オブジェクトの再確認

en: When a client requests an HTTP object that is stale in the cache, Traffic Server revalidates the object. A *revalidation* is a query to the origin server to check if the object is unchanged. The result of a revalidation is one of the following:
ja: クライアントがリクエストした HTTP オブジェクトがキャッシュにあるが新鮮ではない場合、 Traffic Server はオブジェクトを再確認します。 *再確認* とはオリジンサーバーでオブジェクトが変更されていないことを問い合わせることです。再確認の結果は以下のいずれかです:

en: If the object is still fresh, then Traffic Server resets its freshness limit and serves the object.
ja: オブジェクトが依然として新鮮な場合、 Traffic Server はフレッシュネスリミットをリセットして、そのオブジェクトを配信します。

en: If a new copy of the object is available, then Traffic Server caches the new object (thereby replacing the stale copy) and simultaneously serves the object to the client.
ja: オブジェクトの新しいコピーが有効な場合、 Traffic Server は新しいオブジェクトをキャッシュします。(従って、新鮮ではないコピーは置き換えられます) また、同時にオブジェクトをクライアントに配信します。

en: If the object no longer exists on the origin server, then Traffic Server does not serve the cached copy.
ja: オブジェクトがオリジンサーバー上に存在しない場合、 Traffic Server はキャッシュしたコピーを配信しません。

en: If the origin server does not respond to the revalidation query, then Traffic Server serves the stale object along with a ``111 Revalidation Failed`` warning.
ja: オリジンサーバーが再確認の問い合わせに応答しない場合、 Traffic Server は ``111 Revalidation Failed`` 警告と共に新鮮ではないオブジェクトを配信します。

en: By default, Traffic Server revalidates a requested HTTP object in the cache if it considers the object to be stale. Traffic Server evaluates object freshness as described in `HTTP Object Freshness`_. You can reconfigure how Traffic Server evaluates freshness by selecting one of the following options:
ja: デフォルトでは Traffic Server はリクエストされた HTTP オブジェクトが新鮮ではないと考えられる場合に再確認します。 Traffic Server のオブジェクトの新鮮さの評価については `HTTP オブジェクトの新鮮さ`_ で述べられています。次のオプションの一つを選ぶことによって、 Traffic Server が新鮮さを評価する方法を再設定することができます。

en: Always revalidate HTTP objects in the cache with the origin server.
ja: 常にキャッシュの中の HTTP オブジェクトをオリジンサーバーへ再確認します。

en: Never revalidate HTTP objects in the cache with the origin server.
ja: オリジンサーバーへ HTTP オブジェクトを再確認することはありません。

en: Revalidate all HTTP objects without ``Expires`` or ``Cache-Control`` headers.
ja: ``Expires`` や ``Cache-Control`` ヘッダーのない全ての HTTP オブジェクトを再確認します。

en: To configure how Traffic Server revalidates objects in the cache, you can set specific revalidation rules in :file:`cache.config`.
ja: Traffic Server がキャッシュしているオブジェクトを再確認する方法を設定するには :file:`cache.config` に特定の再確認のルールを設定してください。

en: To configure revalidation options
ja: 再確認のオプションを設定するには

en: Edit the variable :ts:cv:`proxy.config.http.cache.when_to_revalidate` in :file:`records.config`.
ja: :file:`records.config` の :ts:cv:`proxy.config.http.cache.when_to_revalidate` を編集してください。

en: Pushing Content into the Cache
ja: コンテンツのキャッシュへのプッシュ

en: Traffic Server supports the HTTP ``PUSH`` method of content delivery. Using HTTP ``PUSH``, you can deliver content directly into the cache without client requests.
ja: Traffic Server はコンテンツ配信に HTTP ``PUSH`` メソッドをサポートして います。HTTP ``PUSH`` を使用すると、クライアントからのリクエスト無しに直接コンテンツをキャッシュの中に入れることができます。

en: Configuring Traffic Server for PUSH Requests
ja: PUSH リクエスト用の Traffic Server の設定

en: Before you can deliver content into your cache using HTTP ``PUSH``, you must configure Traffic Server to accept ``PUSH`` requests.
ja: HTTP ``PUSH`` を使用してコンテンツをキャッシュの中に入れる前に、 Traffic Server が ``PUSH`` リクエストを受け入れるように設定する必要があります。

en: Edit :file:`ip_allow.config` to allow ``PUSH`` from the appropriate addresses.
ja: file:`ip_allow.config` を変更して適切なアドレスからの ``PUSH`` を許可してください。

en: Update :ts:cv:`proxy.config.http.push_method_enabled` in :file:`records.config`::
ja: :file:`records.config` の :ts:cv:`proxy.config.http.push_method_enabled` を更新してください ::

en: Run the command :option:`traffic_ctl config reload` to apply the configuration changes.
ja: 設定変更を適用するために :option:`traffic_ctl config reload` を実行してください。

en: Understanding HTTP PUSH
ja: HTTP PUSH の理解

en: ``PUSH`` uses the HTTP 1.1 message format. The body of a ``PUSH`` request contains the response header and response body that you want to place in the cache. The following is an example of a ``PUSH`` request::
ja: ``PUSH`` は HTTP 1.1 メッセージフォーマットを使用します。 ``PUSH`` リクエストのボディはキャッシュに入れたいレスポンスヘッダーとレスポンスボディを含みます。下記は ``PUSH`` リクエストの例です。

en: Your ``PUSH`` headers must include ``Content-length``, the value for which must include both headers and body byte counts. The value is not optional, and an improper (too large or too small) value will result in undesirable behavior.
ja: あなたの ``PUSH`` ヘッダーは ``Content-Length`` を含まなければなりません。 ``Content-Length`` の値はヘッダーとボディーのバイト数を含まなければなりません。この値は省略可能ではなく、不適切な (大きすぎる、あるいは小さすぎる) 値は望ましくない振る舞いを引き起こします。

en: Tools that will help manage pushing
ja: プッシュを手助けするツール

en: Traffic Server comes with a Perl script for pushing, :program:`tspush`, which can assist with understanding how to write scripts for pushing content yourself.
ja: Traffic Server にはプッシュのための Perl スクリプト :program:`tspush` が同梱されており、あなた自身がコンテンツをプッシュするスクリプトをどのように書けばよいかを理解する助けになり得ます。

en: Pinning Content in the Cache
ja: コンテンツのキャッシュへのピン留め

en: The *Cache Pinning Option* configures Traffic Server to keep certain HTTP objects in the cache for a specified time. You can use this option to ensure that the most popular objects are in cache when needed and to prevent Traffic Server from deleting important objects. Traffic Server observes ``Cache-Control`` headers and pins an object in the cache only if it is indeed cacheable.
ja: *キャッシュのピン留めオプション* は特定の時間の間 HTTP オブジェクトをキャッシュに確実に入れておくように Traffic Server を設定します。最もポピュラーなオブジェクトが必要とされるときにキャッシュされていることと、 Traffic Server が重要なオブジェクトを削除することを防ぐことを確実にしたい際にこのオプションが使えます。 Traffic Server は ``Cache-Control`` ヘッダーを監視し、本当にキャッシュ可能な場合にオブジェクトをキャッシュに留めます。

en: To set cache pinning rules:
ja: キャッシュを留めるルールを設定するためには

en: Enable :ts:cv:`proxy.config.cache.permit.pinning` in :file:`records.config`::
ja: :file:`records.config` の :ts:cv:`proxy.config.cache.permit.pinning` を有効にしてください。

en: Add a rule in :file:`cache.config` for each URL you want Traffic Server to pin in the cache. For example::
ja: Traffic Server にキャッシュに留めさせたい URL 毎に :file:`cache.config` にルールを追加してください。例:

en: Caching HTTP Objects
ja: HTTP オブジェクトのキャッシュ

en: When Traffic Server receives a request for a web object that is not in the cache, it retrieves the object from the origin server and serves it to the client. At the same time, Traffic Server checks if the object is cacheable before storing it in its cache to serve future requests.
ja: Traffic Server がキャッシュしていないウェブオブジェクトへのリクエストを受け取った際、オリジンサーバーからオブジェクトを回収し、クライアントに配信します。その際に、 Traffic Server は将来のリクエストに備えてキャッシュに保存する前に、オブジェクトがキャッシュ可能かどうか確認します。

en: Traffic Server responds to caching directives from clients and origin servers, as well as directives you specify through configuration options and files.
ja: Traffic Server は設定オプションやファイルに指定したディレクティブと同じように、クライアントやオリジンサーバーからのキャッシュのディレクティブに反応します。

en: Client Directives
ja: クライアントディレクティブ

en: By default, Traffic Server does not cache objects with the following request headers:
ja: デフォルトでは Traffic Server は次のリクエストヘッダーを持つオブジェクトをキャッシュしません。

en: To configure Traffic Server to ignore this request header, refer to `Configuring Traffic Server to Ignore Client no-cache Headers`_.
ja: このリクエストヘッダーを無視するように Traffic Server を設定するには `クライアントの no-cache ヘッダーを無視する Traffic Server の設定`_ を参照してください。

en: ``Cookie`` (for text objects)
ja: ``Cookie`` (テキストオブジェクトに対して)

en: Configuring Traffic Server to Ignore Client no-cache Headers
ja: クライアントの no-cache ヘッダーを無視する Traffic Server の設定

en: By default, Traffic Server strictly observes client ``Cache-Control: no-cache`` directives. If a requested object contains a ``no-cache`` header, then Traffic Server forwards the request to the origin server even if it has a fresh copy in cache. You can configure Traffic Server to ignore client ``no-cache`` directives such that it ignores ``no-cache`` headers from client requests and serves the object from its cache.
ja: デフォルトでは Traffic Server はクライアントの ``Cache-Control: no-cache`` ディレクティブを正確に守ります。リクエストされたオブジェクトが ``no-cache`` を含んでいる場合、 Traffic Server はキャッシュのコピーが新鮮であったとしても、オリジンサーバーにリクエストを転送します。 Traffic Server がクライアントからの ``no-cache`` ディレクティブを無視するように設定することもできます。この場合、クライアントからのリクエストの ``no-cache`` ヘッダーを無視して、キャッシュからオブジェクトを配信します。

en: Edit :ts:cv:`proxy.config.http.cache.ignore_client_no_cache` in :file:`records.config`. ::
ja: :file:`records.config` の :ts:cv:`proxy.config.http.cache.ignore_client_no_cache` を編集してください。

en: Origin Server Directives
ja: オリジンサーバーディレクティブ

en: By default, Traffic Server does not cache objects with the following response headers:
ja: デフォルトでは Traffic Server は次のレスポンスヘッダーを持つオブジェクトをキャッシュしません。

en: To configure Traffic Server to ignore ``WWW-Authenticate`` headers, refer to `Configuring Traffic Server to Ignore WWW-Authenticate Headers`_.
ja: ``WWW-Authenticate`` ヘッダーを無視するように Traffic Server を設定 するには `WWW-Authenticate ヘッダーを無視する Traffic Server の設定`_ を参照してください。

en: To configure Traffic Server to ignore ``no-cache`` headers, refer to `Configuring Traffic Server to Ignore Server no-cache Headers`_.
ja: ``no-cache`` ヘッダーを無視するように Traffic Server を設定するには `サーバーの no-cache ヘッダーを無視する Traffic Server の設定`_ を参照してください。

en: ``Expires`` header with a value of 0 (zero) or a past date.
ja: 値が 0 (ゼロ)もしくは過去の日付の ``Expires`` ヘッダー

en: Configuring Traffic Server to Ignore Server no-cache Headers
ja: サーバーの no-cache ヘッダーを無視する Traffic Server の設定

en: By default, Traffic Server strictly observes ``Cache-Control: no-cache`` directives. A response from an origin server with a ``no-cache`` header is not stored in the cache and any previous copy of the object in the cache is removed. If you configure Traffic Server to ignore ``no-cache`` headers, then Traffic Server also ignores ``no-store`` headers. The default behavior of observing ``no-cache`` directives is appropriate in most cases.
ja: デフォルトでは Traffic Server は ``Cache-Control: no-cache`` ディレクティブを正確に守ります。 ``no-cache`` ヘッダーが付いているオリジンサーバーからのレスポンスはキャッシュに保存されません。また、以前キャッシュされたオブジェクトのコピーは削除されます。 ``no-cache`` ヘッダーを無視するように Traffic Server を設定した場合、 Traffic Server は ``no-store`` ヘッダーも無視します。 ``no-cache`` ディレクティブを守るデフォルトの振る舞いはほとんどの場合に適切です。

en: To configure Traffic Server to ignore server ``no-cache`` headers:
ja: サーバーの ``no-cache`` ヘッダーを無視するように Traffic Server を設定するには :

en: Edit :ts:cv:`proxy.config.http.cache.ignore_server_no_cache` in :file:`records.config`. ::
ja: :file:`records.config` の :ts:cv:`proxy.config.http.cache.ignore_server_no_cache ` を編集してください。

en: Configuring Traffic Server to Ignore WWW-Authenticate Headers
ja: WWW-Authenticate ヘッダーを無視する Traffic Server の設定

en: By default, Traffic Server does not cache objects that contain ``WWW-Authenticate`` response headers. The ``WWW-Authenticate`` header contains authentication parameters the client uses when preparing the authentication challenge response to an origin server.
ja: デフォルトでは Traffic Server は ``WWW-Authenticate`` レスポンスヘッダーを含むオブジェクトをキャッシュしません。 ``WWW-Authenticate`` ヘッダーはクライアントがオリジンサーバーへのチャレンジレスポンス認証の際に使う認証パラメーターを含んでいます。

en: When you configure Traffic Server to ignore origin server ``WWW-Authenticate`` headers, all objects with ``WWW-Authenticate`` headers are stored in the cache for future requests. However, the default behavior of not caching objects with ``WWW-Authenticate`` headers is appropriate in most cases. Only configure Traffic Server to ignore server ``WWW-Authenticate`` headers if you are knowledgeable about HTTP 1.1.
ja: オリジンサーバーの ``WWW-Authenticate`` ヘッダーを無視するように Traffic Server を設定した場合、 ``WWW-Authenticate`` ヘッダーを持つ全てのオブジェクトは次のリクエストの為にキャッシュに保存されます。しかし、 ``WWW-Authenticate`` ヘッダーを持つオブジェクトをキャッシュしないデフォルトの振る舞いは多くの場合に適切です。 ``WWW-Authenticate`` ヘッダーを無視するように Traffic Server を設定するのは HTTP 1.1 に精通してる場合にだけにしてください。

en: To configure Traffic Server to ignore server ``WWW-Authenticate`` headers:
ja: ``WWW-Authenticate`` ヘッダーを無視するように Traffic Server を設定するには :

en: Edit :ts:cv:`proxy.config.http.cache.ignore_authentication` in :file:`records.config`. ::
ja: :file:`records.config` の :ts:cv:`proxy.config.http.cache.ignore_authentication ` を編集してください。

en: Configuration Directives
ja: 設定ディレクティブ

en: In addition to client and origin server directives, Traffic Server responds to directives you specify through configuration options and files.
ja: クライアントやオリジンサーバーのディレクティブに加えて、 Traffic Server は設定オプションやファイルを通じて設定したディレクティブにも反応します。

en: You can configure Traffic Server to do the following:
ja: 次のように Traffic Server を設定することができます。

en: Not cache any HTTP objects. Refer to `Disabling HTTP Object Caching`_.
ja: どんな HTTP オブジェクトもキャッシュしない ( `HTTP オブジェクトキャッシュの無効化`_ 参照)

en: Cache *dynamic content*. That is, objects with URLs that end in ``.asp`` or contain a question mark (``?``), semicolon (``;``), or ``cgi``. For more information, refer to `Caching Dynamic Content`_.
ja: *動的コンテンツ* をキャッシュする。 ``.asp`` で終わったり、クエスチョンマーク (``?``)、セミコロン (``;``) や ``cgi`` を含んでいたりする URL のオブジェクト。より詳しくは `動的コンテンツのキャッシュ`_ を参照してください。

en: Cache objects served in response to the ``Cookie:`` header. Refer to `Caching Cookied Objects`_.
ja: ``Cookie:`` ヘッダーに対して返されるオブジェクトをキャッシュする。 `クッキーオブジェクトのキャッシュ`_ を参照してください。

en: Observe ``never-cache`` rules in :file:`cache.config`.
ja: :file:`cache.config` ファイルの ``never-cache`` ルールに従う。

en: Disabling HTTP Object Caching
ja: HTTP オブジェクトキャッシュの無効化

en: By default, Traffic Server caches all HTTP objects except those for which you have set ``never-cache`` as :ref:`action rules <cache-config-format-action>` in :file:`cache.config`. You can disable HTTP object caching so that all HTTP objects are served directly from the origin server and never cached, as detailed below.
ja: デフォルトでは Traffic Server は :file:`cache.config` ファイルに設定した ``never-cache`` :ref:`アクションルール <cache-config-format-action>` を除く全ての HTTP オブジェクトをキャッシュします。後述するように HTTP オブジェクトがオリジンサーバーから直接配信され、決してキャッシュされな いように HTTP オブジェクトのキャッシュを無効化することができます。

en: To disable HTTP object caching manually:
ja: HTTP オブジェクトキャッシュを手動で無効化するには :

en: Caching Dynamic Content
ja: 動的コンテンツのキャッシュ

en: A URL is considered dynamic if it ends in ``.asp`` or contains a question mark (``?``), a semicolon (``;``), or ``cgi``. By default, Traffic Server caches dynamic content. You can configure the system to ignore dynamic looking content, although this is recommended only if the content is truly dynamic, but fails to advertise so with appropriate ``Cache-Control`` headers.
ja: ``.asp`` で終わったり、クエスチョンマーク (``?``)、セミコロン (``;``) や ``cgi`` を含んでいたりする URL  は動的であると考えられます。デフォルトでは Traffic Server は動的コンテンツをキャッシュします。コンテンツが本当に動的である場合にだけ推奨されますが、適切な ``Cache-Control`` ヘッダーによって伝えることができないとき、動的だと思われるコンテンツを無視するようにシステムを設定することができます。

en: To configure Traffic Server's cache behaviour in regard to dynamic content:
ja: 動的コンテンツに配慮した Traffic Server の振る舞いを設定するには :

en: Edit :ts:cv:`proxy.config.http.cache.cache_urls_that_look_dynamic` in :file:`records.config`. To disable caching, set the variable to ``0``, and to explicitly permit caching use ``1``. ::
ja: :file:`records.config` の :ts:cv:`proxy.config.http.cache.cache_urls_that_look_dynamic` を編集してください。キャッシュを無効にするには ``0`` に設定し、明示的にキャッシュを許可するには ``1`` に設定してください。 ::

en: Caching Cookied Objects
ja: クッキーオブジェクトのキャッシュ

en: You can reconfigure Traffic Server to:
ja: 次のように Traffic Server を設定し直すことができます。

en: Not cache cookied content of any type.
ja: クッキーを含む全てのコンテンツをキャッシュしない

en: Cache cookied content that is of image type only.
ja: クッキーを含む画像のみキャッシュする

en: Cache all cookied content regardless of type.
ja: タイプを考慮せずクッキーを含む全てのコンテンツをキャッシュする

en: To configure how Traffic Server caches cookied content:
ja: クッキーを含むコンテンツをどのようにキャッシュするか Traffic Server を設定するには :

en: Edit :ts:cv:`proxy.config.http.cache.cache_responses_to_cookies` in :file:`records.config`.
ja: :file:`records.config` の :ts:cv:`proxy.config.http.cache.cache_responses_to_cookies` を編集してください。

en: Forcing Object Caching
ja: オブジェクトの強制キャッシュ

en: You can force Traffic Server to cache specific URLs (including dynamic URLs) for a specified duration, regardless of ``Cache-Control`` response headers.
ja: ``Cache-Control`` レスポンスヘッダーを無視して、特定の期間に特定の URL (動的 URL も含む) をキャッシュすることを Traffic Server に強制することができます。

en: To force document caching:
ja: ドキュメントを強制的にキャッシュするには :

en: Add a rule for each URL you want Traffic Server to pin to the cache :file:`cache.config`::
ja: Traffic Server にキャッシュに留めさせたい URL 毎に :file:`cache.config` にルールを追加してください。

en: Caching HTTP Alternates
ja: HTTP オブジェクトの代替のキャッシュ

en: 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 specify additional request and response headers for specific ``Content-Type`` values that Traffic Server will identify as alternates for caching. You can also limit the number of alternate versions of an object allowed in the cache.
ja: いくつかの同一の URL へ複数のオブジェクトを回答するオリジンサーバーもあります。これらのオブジェクトのコンテンツはサーバーが異なる言語ごとにコンテンツを配信したり、異なるブラウザ毎にプレゼンテーションスタイルを用意していたり、異なるドキュメントフォーマット (HTML, XML) を提供しているか等により、多岐にわたります。同一オブジェクトの異なるバージョンは *代替* と呼ばれ、``Vary`` レスポンスヘッダーに基づいて Traffic Server にキャッシュされます。 Traffic Server がキャッシュする代替を判別する特別な ``Content-Type`` をリクエストやレスポンスヘッダに追加することができます。キャッシュする代替バージョンの数を制限することもできます。

en: Configuring How Traffic Server Caches Alternates
ja: Traffic Server がキャッシュする代替の設定

en: To configure how Traffic Server caches alternates:
ja: Traffic Server が代替をキャッシュするように設定するには :

en: Edit the following variables in :file:`records.config`:
ja: :file:`records.config` の次の変数を編集してください :

en: If you specify ``Cookie`` as the header field on which to vary in the above variables, make sure that the variable :ts:cv:`proxy.config.http.cache.cache_responses_to_cookies` is set appropriately.
ja: 上の変数に ``Cookie`` を切り替えるためのヘッダーフィールドとして指定した場合、 :ts:cv:`proxy.config.http.cache.cache_responses_to_cookies` が適切にセットされていることを確認してください。

en: Limiting the Number of Alternates for an Object
ja: オブジェクトの代替数の制限

en: You can limit the number of alternates Traffic Server can cache per object (the default is 3).
ja: Traffic Server がオブジェクト毎にキャッシュする代替数を制限することができます。(デフォルトは 3 です)

en: Large numbers of alternates can affect Traffic Server cache performance because all alternates have the same URL. Although Traffic Server can look up the URL in the index very quickly, it must scan sequentially through available alternates in the object store.
ja: 全ての代替は同一の URL を持つため、代替の数が多いと Traffic Server のキャッシュパフォーマンスに影響を与えるかもしれません。Traffic Server はインデックス中の URL をとても高速に検索しますが、キャッシュストアの中に使用可能な代替があるかはシーケンシャルにスキャンしなければなりません。

en: To alter the limit on the number of alternates:
ja: オブジェクトの代替数の制限を変更するには :

en: Edit :ts:cv:`proxy.config.cache.limits.http.max_alts` in :file:`records.config`. ::
ja: :file:`records.config` の :ts:cv:`proxy.config.cache.limits.http.max_alts` を編集してください ::

en: Using Congestion Control
ja: 輻輳制御

en: The *Congestion Control* option enables you to configure Traffic Server to stop forwarding HTTP requests to origin servers when they become congested. Traffic Server then sends the client a message to retry the congested origin server later.
ja: *輻輳制御* オプションはオリジンサーバーが混雑しているときに Traffic Server が HTTP リクエストを転送することを止めることを可能にします。 Traffic Server はその後、混雑してるオリジンサーバーに後でリトライするメッセージをクライアントに送ります。

en: To enable this option:
ja: このオプションを有効にするには :

en: Set :ts:cv:`proxy.config.http.congestion_control.enabled` to ``1`` in :file:`records.config`. ::
ja: :file:`records.config` の :ts:cv:`proxy.config.http.congestion_control.enabled` を ``1`` にセットしてください ::

en: Create rules in :file:`congestion.config` to specify:
ja: ルールを作成して :file:`congestion.config` ファイルに次のように記述してください :

en: Which origin servers Traffic Server tracks for congestion.
ja: Traffic Server がどのオリジンサーバーの輻輳を監視するか

en: The timeouts Traffic Server uses, depending on whether a server is congested.
ja: Traffic Server がサーバーが輻輳したかの基準にするタイムアウト

en: The page Traffic Server sends to the client when a server becomes congested.
ja: サーバーが輻輳したときに Traffic Server がクライアントへ送信するページ

en: Whether Traffic Server tracks the origin servers by IP address or by hostname.
ja: Traffic Server が IP アドレス毎に追跡するか、ホストネーム毎に追跡するかどうか

en: Using Transaction Buffering Control
ja: トランザクションバッファリング制御

en: By default, I/O operations are run at full speed, as fast as either Traffic Server, the network, or the cache can support. This can be problematic for large objects if the client side connection is significantly slower. In such cases the content will be buffered in ram while waiting to be sent to the client. This could potentially also happen for ``POST`` requests if the client connection is fast and the origin server connection slow. If very large objects are being used this can cause the memory usage of Traffic Server to become `very large <https://issues.apache.org/jira/browse/TS-1496>`_.
ja: デフォルトでは I/O オペレーションは Traffic Server やネットワークやキャッシュが実行できる限り速くフルスピードで実行されます。これはクライアント側のコネクションが遅い場合に、大きなオブジェクトにとって問題になる可能性があります。このような場合、クライアントに送られるのを待っている間、コンテンツはメモリにバッファーされます。これはクライアントのコネクションが早く、オリジンサーバーのコネクションが遅い場合に ``POST`` リクエストでも発生し得ます。とても大きなオブジェクトが使われているとこれは Traffic Server のメモリ使用量がとても大きくなる原因になり得ます。 `very large <https://issues.apache.org/jira/browse/TS-1496>`_

en: Although this is intended primarily to limit the memory usage of Traffic Server it can also serve as a crude rate limiter by setting a buffer limit and then throttling the client side connection either externally or via a transform. This will cause the connection to the origin server to be limited to roughly the client side connection speed.
ja: 主に Traffic Server のメモリ使用量を制限することを意図していますが、これはまた大雑把なレートリミッターも提供します。これはバッファーリミットの設定と、外部やトランスフォームの影響により、クライアント側のコネクションを減速させることによります。これはオリジンサーバーへのコネクションがクライアント側のコネクションスピードにより大まかに制限されることをもたします。

en: Traffic Server does network I/O in large chunks (32K or so) and therefore the granularity of transaction buffering control is limited to a similar precision.
ja: Traffic Server はネットワーク I/O をラージチャンク(32K など) で行います。よって、トランザクションバッファリングコントロールの粒度は同じような値に制限されています。

en: The buffer size calculations include all elements in the transaction, including any buffers associated with :ref:`transform plugins <developer-plugins-http-transformations>`.
ja: バッファーサイズの計算はトランザクションの全ての要素を含んでいます。これは :ref:`transform plugins <developer-plugins-http-transformations>` に紐づけられているどんなバッファーも含みます。

en: Transaction buffering control can be enabled globally by using configuration variables or by :c:func:`TSHttpTxnConfigIntSet` in a plugin.
ja: トランザクションバッファーコントロールは設定変数を使ってグローバルに有効化することもできます。また :c:func:`TSHttpTxnConfigIntSet` を使用してプラグインの中で有効化することもできます。

en: Value
ja: 値

en: Variable
ja: 変数

en: :c:func:`TSHttpTxnConfigIntSet` key
ja: :c:func:`TSHttpTxnConfigIntSet` キー

en: Enable buffering
ja: バッファーの有効化

en: Set high water
ja: high water の設定

en: Set low water
ja: low water の設定

en: Be careful to always have the low water mark equal or less than the high water mark. If you set only one, the other will be set to the same value.
ja: low water マークは high water マークと常に同じか少ないことに注意してください。一方だけを設定すると、もう一方は同じ値に設定されます。

en: If using :c:func:`TSHttpTxnConfigIntSet`, it must be called no later than :c:data:`TS_HTTP_READ_RESPONSE_HDR_HOOK`.
ja: :c:func:`TSHttpTxnConfigIntSet` を使う場合、`TS_HTTP_READ_RESPONSE_HDR_HOOK` より後ろで呼んではいけません。

en: Reducing Origin Server Requests (Avoiding the Thundering Herd)
ja: オリジンサーバーへのリクエストの削減(Thundering Herd 問題を避ける)

en: When an object can not be served from cache, the request will be proxied to the origin server. For a popular object, this can result in many near simultaneous requests to the origin server, potentially overwhelming it or associated resources. There are several features in Traffic Server that can be used to avoid this scenario.
ja: オブジェクトがキャッシュから配信されない場合、リクエストはオリジンサーバーにプロキシーされます。ポピュラーなオブジェクトにとって、これはオリジンサーバーへ多くの同じ様なリクエストを送り、可能性としては計り知れない程の関連したリソースを使うかもしれません。 Traffic Server にはこのシナリオを避けられるいくつかの機能があります。

en: When Traffic Server goes to fetch something from origin, and upon receiving the response, any number of clients can be allowed to start serving the partially filled cache object once background_fill_completed_threshold % of the object has been received.
ja: Traffic Server がオリジンからオブジェクトをフェッチしに行くとき、そしてレスポンスを受け取るとき、受け取ったオブジェクトの background_fill_completed_threshold % が満たされた部分的キャッシュオブジェクトを配信することがどんな数のクライアントにも許されています。

en: While some other HTTP proxies permit clients to begin reading the response immediately upon the proxy receiving data from the origin server, ATS does not begin allowing clients to read until after the complete HTTP response headers have been read and processed. This is a side-effect of ATS making no distinction between a cache refresh and a cold cache, which prevents knowing whether a response is going to be cacheable.
ja: 他の HTTP プロキシーはオリジンサーバーからデータを受け取ったらすぐにクライアントがレスポンスを読み始めることを許可していますが、ATS は完全なレスポンスヘッダーを受け取るまでクライアントが読み始めることを許可しません。これは ATS がキャッシュリフレッシュとコールドキャッシュを区別しておらず、そのためレスポンスがキャッシュ可能なものか知る方法がないことの副作用です。

en: As non-cacheable responses from an origin server are generally due to that content being unique to different client requests, ATS will not enable read-while-writer functionality until it has determined that it will be able to cache the object.
ja: オリジンサーバーからのキャッシュ出来ないレスポンスは一般的は異なるクライアントリクエストに対してユニークなコンテンツなので、 ATS はオブジェクトをキャッシュ出来ると判断するまで read-while-writer を有効にはしません。

en: The following settings must be made in :file:`records.config` to enable read-while-writer functionality in ATS::
ja: ATS で read-while-writer 機能を有効にするには :file:`records.config` で以下の設定を行う必要があります ::

en: All four configurations are required, for the following reasons:
ja: 次の理由により、４つ全ての設定が必要です。

en: :ts:cv:`proxy.config.cache.enable_read_while_writer` being set to ``1`` turns the feature on, as it is off (``0``) by default.
ja: :ts:cv:`proxy.config.cache.enable_read_while_writer` を ``1`` にセットすると機能を on にします。デフォルトでは off (0) です。

en: The background fill feature (both :ts:cv:`proxy.config.http.background_fill_active_timeout` and :ts:cv:`proxy.config.http.background_fill_completed_threshold`) should be allowed to kick in for every possible request. This is necessary in the event the writer (the first client session to request the object, which triggered ATS to contact the origin server) goes away. Another client session needs to take over the writer.
ja: バックグラウンドフィル機能 (:ts:cv:`proxy.config.http.background_fill_active_timeout` と :ts:cv:`proxy.config.http.background_fill_completed_threshold` の両方) は全てのあり得るリクエストでキックされることが許可されているべきです。 writer (ATSがオリジンサーバーへ接続するトリガーとなったオブジェクトリクエストの最初のクライアントセッション) が出て行った場合にこれは重要となります。他のクライアントセッションが writer を引継ぐ必要があります。

en: As such, you should set the background fill timeouts and threshold to zero; this assures they never time out and are always allowed to kick in.
ja: そのようにするには、バックグラウンドフィルタイムアウトを設定し、境界点をゼロにするべきです。これは彼らがタイムアウトせずに、キックインすることを常に許可されることを保証します。

en: The :ts:cv:`proxy.config.cache.max_doc_size` should be unlimited (set to 0), since the object size may be unknown, and going over this limit would cause a disconnect on the objects being served.
ja: :ts:cv:`proxy.config.cache.max_doc_size` は無制限(0)に設定されているべきです。オブジェクトサイズは (訳注: 事前には) 分からないからです。この制限を超えると配信されているオブジェクトのコネクションの切断を引き起こすかもしれません。

en: Once these are enabled, you have something that is very close, but not quite the same, to Squid's Collapsed Forwarding.
ja: 一度これらが有効化されると、Squid の Collapesd Forwarding にとても近いが異なるものものができます。

en: In addition to the above settings, the settings :ts:cv:`proxy.config.cache.read_while_writer.max_retries` and :ts:cv:`proxy.config.cache.read_while_writer_retry.delay` allow to control the number of retries TS attempts to trigger read-while-writer until the download of first fragment of the object is completed::
ja: 上記の設定に加えて、 :ts:cv:`proxy.config.cache.read_while_writer.max_retries` と :ts:cv:`proxy.config.cache.read_while_writer_retry.delay` の設定はオブジェクトの最初のフラグメントのダウンロードが完了するまで TS が read-while-writer をトリガーすることを試みる回数を制御できます ::

en: Traffic Server can be set to attempt to revalidate an object before it becomes stale in cache. :file:`records.config` contains the settings::
ja: Traffic Server はキャッシュが新鮮でなくなる前に、オブジェクトの再確認を試みるように設定することもできす。:file:`records.config` に次の設定があります ::

en: For every request for an object that occurs :ts:cv:`proxy.config.http.cache.fuzz.time` before (in the example above, 240 seconds) the object is set to become stale, there is a small chance (:ts:cv:`proxy.config.http.cache.fuzz.probability` == 0.5%) that the request will trigger a revalidation request to the origin.
ja: オブジェクトが新鮮でないとセットされるよりも :ts:cv:`proxy.config.http.cache.fuzz.time` (上の例では 240 秒) だけ経過時間が短いオブジェクトへの全てのリクエストには、オリジンへの再確認リクエストを引き起こすわずかな可能性 ( :ts:cv:`proxy.config.http.cache.fuzz.probability` == 0.5% ) があります。

en: When revalidation occurs, the requested object is no longer available to be served from cache. Subsequent requests for that object will be proxied to the origin.
ja: 再確認が発生すると、リクエストされたオブジェクトはもはやキャッシュから配信することはできなくなります。そのオブジェクトへの以降のリクエストはオリジンサーバーにプロキシーされるでしょう。

en: For objects getting a few requests per second, these settings would offer a fairly low probability of revalidating the cached object before it becomes stale. This feature is not typically necessary at those rates, though, since odds are only one or a small number of connections would hit origin upon the objects going stale.
ja: 秒間 2,3 リクエスト数しかないオブジェクトでは、これらの設定によりキャッシュされたオブジェクトが新鮮でなくなる前に再確認される確率は非常に低くなるでしょう。ですが、この機能はこれらの速度ではたいていは必要ではないでしょう。というのは新鮮でなくなるオブジェクトに対してオリジンサーバーにヒットする接続数は 1 か小さい数である確率が高いからです。

en: Once request raise rise, the same ``fuzz.probability`` leads to a greater chance the object may be revalidated before becoming stale. This can prevent multiple clients simultaneously triggering contact with the origin server under higher loads, as they would do if no fuzziness was employed for revalidations.
ja: 一旦リクエストの集中が発生すると、同じ ``fuzz.probability`` がオブジェクトが新鮮でなくなる前に再確認される可能性がより高くなることを引き起こします。これはより高い負荷の際に複数のクライアントが同時にオリジンサーバーへの接続を発生させることを妨げます。再確認に曖昧さ (fuzziness) が用いられなければそういう状況が発生していたことでしょう。

en: These settings are also overridable by remap rules and via plugins, so can be adjusted per request if necessary.
ja: これらの設定は remap ルールとプラグインによってオーバーライド可能ですので、必要ならリクエスト毎に調整することが出来ます。

en: A logarithmic like function between determines the revalidation evaluation start time (which will be between ``fuzz.min_time`` and ``fuzz.time``). As the object gets closer to expiring, the window start becomes more likely. By default this setting is not enabled, but should be enabled anytime you have objects with small TTLs. Note that this option predates overridable configurations, so you can achieve something similar with a plugin or :file:`remap.config` settings.
ja: 対数のような関数が再確認査定を始める時間を決定します。(その値は``fuzz.min_time`` と ``fuzz.time`` の間でしょう) 期限切れに近いオブジェクトでは、期間の始まりはより可能性が高くなります。デフォルトではこの設定は有効化されていません。しかし、TTL の小さなオブジェクトがある場合、いつでも有効化するべきです。このオプションは設定を上書きする前に起きることに注意してください。よって、プラグインや :file:`remap.config` 設定で同様なものを実現することができます。

en: These configuration options are similar to Squid's refresh_stale_hit configuration option.
ja: これらの設定オプションは Squid の refresh_stale_hit 設定オプションに似ています。

en: Open Read Retry Timeout
ja: Open Read リトライタイムアウト

en: The open read retry configurations attempt to reduce the number of concurrent requests to the origin for a given object. While an object is being fetched from the origin server, subsequent requests would wait :ts:cv:`proxy.config.http.cache.open_read_retry_time` milliseconds before checking if the object can be served from cache. If the object is still being fetched, the subsequent requests will retry :ts:cv:`proxy.config.http.cache.max_open_read_retries` times. Thus, subsequent requests may wait a total of (``max_open_read_retries`` x ``open_read_retry_time``) milliseconds before establishing an origin connection of its own. For instance, if they are set to ``5`` and ``10`` respectively, connections will wait up to 50ms for a response to come back from origin from a previous request, until this request is allowed through.
ja: オープンリードリトライ設定は与えられたオブジェクトに対してオリジンサーバーへの並列リクエストの数を減らすことを試みています。あるオブジェクトがオリジンサーバーからフェッチされている間、次のリクエストはオブジェクトがキャッシュから配信できるかどうかを確認する前に :ts:cv:`proxy.config.http.cache.open_read_retry_time` ミリ秒待ちます。オブジェクトが依然としてフェッチされている場合、次のリクエストは :ts:cv:`proxy.config.http.cache.max_open_read_retries` 回リトライします。すると、次のリクエストはオリジンサーバーへのコネクションを自分自身で確立する前に合計で (``max_open_read_retries`` x ``open_read_retry_time``) ミリ秒待ちます。例えばそれぞれ ``5`` や ``10`` にセットされた場合、このリクエストが許可されるまでコネクションは前回のリクエストがオリジンからレスポンスが帰ってくる間 50ms 待ちます。

en: These settings are inappropriate when objects are uncacheable. In those cases, requests for an object effectively become serialized. The subsequent requests would await at least ``open_read_retry_time`` milliseconds before being proxied to the origin.
ja: これらの設定はオブジェクトがキャッシュ不可能な場合、適切ではありません。これらの場合、オブジェクトへのリクエストは実際には直列になります。次のリクエストはオリジンにプロキシーされる前に少なくとも ``open_read_retry_time`` ミリ秒待たされるでしょう。

en: It is advisable that this setting be used in conjunction with `Read While Writer`_ for big (those that take longer than (``max_open_read_retries`` x ``open_read_retry_time``) milliseconds to transfer) cacheable objects. Without the read-while-writer settings enabled, while the initial fetch is ongoing, not only would subsequent requests be delayed by the maximum time, but also, those requests would result in unnecessary requests to the origin server.
ja: この設定は大きな (転送に (``max_open_read_retries`` x ``open_read_retry_time``) ミリ秒以上かかる) キャッシュ可能なオブジェクトの `Read While Writer`_ と共に使うように設定することが望ましいです。 read-while-writer 設定を有効化しないと、初回のフェッチが行われている間、次のリクエストが最大限遅れるだけではなく、結果としてオリジンサーバーへの不要なリクエストを発生させます。

en: Since ATS now supports setting these settings per-request or remap rule, you can configure this to be suitable for your setup much more easily.
ja: ATS はリクエスト毎や remap ルールに設定することをサポートしているので、これはより簡単に適切に設定することができます。

en: The configurations are (with defaults)::
ja: 設定 (とそのデフォルト値) は ::

en: The defaults are such that the feature is disabled and every connection is allowed to go to origin without artificial delay. When enabled, you will try ``max_open_read_retries`` times, each with an ``open_read_retry_time`` timeout.
ja: デフォルトはこの機能が無効化されていて、全てのコネクションはオリジンに人為的な遅延無しに行くことを許可されていることを意味します。有効化した場合、``open_read_retry_time`` タイムアウト毎に ``max_open_read_retries`` 回試すでしょう。

en: Open Write Fail Action
ja: Open Write 失敗時のアクション

en: In addition to the open read retry settings TS supports a new setting :ts:cv:`proxy.config.http.cache.open_write_fail_action` that allows to further reduce multiple concurrent requests hitting the origin for the same object by either returning a stale copy, in case of hit-stale or an error in case of cache miss for all but one of the requests.
ja: オープンリードリトライ設定に加えて TS は新しい設定 :ts:cv:`proxy.config.http.cache.open_write_fail_action` をサポートします。これは複数の同時リクエストが同じオブジェクトを求めてオリジンにヒットすることをより一層減らします。それは1つのリクエストを除く全てのリクエストに対して、 hit-stale の場合には新鮮でないコピーを返すかキャッシュミスの場合にはエラーを返すことで実現します。
