リバースプロキシーと HTTP リダイレクト¶

リバースプロキシーキャッシュとして、Traffic Server はオリジンサーバーの代わりにリクエストに応えます。Traffic Server はクライアントには通常のオリジンサーバーに見えるように設定されます。

リバースプロキシーキャッシュを理解する¶

フォワードプロキシーキャッシュ の場合、Traffic Server はコンテンツをリクエストしたクライアントに代わってオリジンサーバーへのリクエストを取り扱います。 リバースプロキシーキャッシュ ( サーバーアクセラレーション としても知られています) では Traffic Server がコンテンツを持っているオリジンサーバーに代わってプロキシーキャッシュとして振る舞う点が異なります。 Traffic Server はクライアントが接続しようとしているオリジンサーバーとなるように設定されます。典型的なシナリオとしては、オリジンサーバーの広告されたホスト名が本当のオリジンサーバーのように振る舞う Traffic Server へ解決され、 Traffic Server は必要に応じて本当のオリジンサーバーからコンテンツを取得した上で、クライアントのリクエストに直接応えます。

リバースプロキシーによる対応策¶

Traffic Server をリバースプロキシーとして使う方法はたくさんあります。以下はいくつかの例です。

使用頻度の高いオリジンサーバーの負荷を軽減する
地理的に離れた地域に効率的にコンテントを配信する。
センシティブな情報を含むオリジンサーバーにセキュリティを提供する。

使用頻度の高いオリジンサーバーの負荷を軽減する。¶

Traffic Server can accept requests on behalf of the origin server and improve the speed and quality of web serving by reducing load and hot spots on backup origin servers. For example, a web host can maintain a scalable Traffic Server system with a set of low-cost, low-performance, less-reliable PC origin servers as backup servers. In fact, a single Traffic Server can act as the virtual origin server for multiple backup origin servers, as shown in the figure below.

1組のオリジンサーバーのリバースプロキシーとして動く Traffic Server¶

分散した地域でのコンテンツの配信¶

Traffic Server は地理的に近接していないエリアにコンテンツを提供するオリジンサーバーを加速するためにリバースプロキシーモードで使用できます。キャッシュはレプリケーションよりもたいていは管理が簡単でコストパフォーマンスが良いです。例えば、高価な、国をまたぐコネクションを使ってリクエストやコンテンツを取得することなく大西洋の向こう側のミラーサイトとして Traffic Server を利用することができます。全データを複製しピークキャパシティを処理する用に構成しなければならないレプリケーションとは異なり、 Traffic Server はハードウェアの配信と保存のキャパシティを最適に利用するよう動的に順応します。 Traffic Server は自動的にコンテンツを新鮮に保つようにも設計されているので、リモートオリジンサーバーをアップデートする複雑さも除去できます。

オリジンサーバーへのセキュリティの提供¶

Traffic Server はオリジンサーバーにセキュリティを提供するためにリバースプロキシーモードで使用できます。もしファイアーウォールの内側にあるオリジンサーバーが安全にしておきたいセンシティブな情報を持っている場合、 Traffic Server をファイアーウォールの外側におき、そのオリジンサーバーのためのリバースプロキシーとして使用できます。外部のクライアントがそのオリジンサーバーにアクセスを試みるとリクエストは Traffic Server に向かいます。もし求められたコンテンツがセンシティブではない場合、それはキャッシュから提供されます。もしコンテンツがセンシティブでありキャッシュ不可能な場合、Traffic Server はオリジンサーバーからコンテンツを取得します (ファイアーウォールはオリジンサーバーへのアクセスを Traffic Server にのみ許します)。センシティブなコンテンツは安全なファイアーウォールの内側のオリジンサーバー上にあります。

リバースプロキシーの動作¶

ブラウザーがリクエストを行うとき、通常はリクエストを直接オリジンサーバーに送信します。 Traffic Server がリバースプロキシーモードになっているときはリクエストがオリジンサーバーに届く前に Traffic Server が横取りします。通常これはオリジンサーバーの DNS エントリー (オリジンサーバーの広告されたホスト名) を Traffic Server の IP アドレスに解決されるように設定すれば完了です。 Traffic Server がオリジンサーバーとして設定されている場合、ブラウザーはオリジンサーバーではなく Traffic Server に接続します。より詳しくは HTTP リバースプロキシーを見てください。

注釈

DNS の衝突を避けるため、オリジンサーバーのホスト名とその広告されたホスト名は同じであってはなりません。

HTTP リバースプロキシー¶

リバースプロキシーモードでは、Traffic Server は HTTP リクエストをウェブサーバーの代わりに受け取ります。下の図はリバースプロキシーモードの Traffic Server がどのようにクライアントからの HTTP リクエストを受け取るのかを説明しています。

上の図は次のステップを説明しています。

クライアントブラウザが www.host.com の 80 番ポートに HTTP リクエストを送信します。Traffic Server はオリジンサーバーとして振る舞っているのでこのリクエストを受け取ります(オリジンサーバーの広告されたホスト名は Traffic Server へ解決されるように広告されています)。
Traffic Server は :file:remap.config` ファイル内にあるマップルールを見つけ、リクエストを指定されたオリジンサーバー (``realhost.com) にリマップします。
もしリクエストにキャッシュから応えられなかった場合、 Traffic Server はオリジンサーバーへの HTTP コネクションを開き (あるいはもっとありそうなことは、事前に確立済みの既存の接続を使い)、コンテンツを取得し、場合によってはコンテンツを将来使用するためにキャッシュします。
もしリクエストがキャッシュにヒットしコンテンツが新鮮であるか、ステップ 3 のためにコンテンツが Traffic Server から配信可能な場合は、 Traffic Server はリクエストされたオブジェクトをキャッシュからクライアントに直接送信します。

注釈

Traffic Server はオリジンサーバーからの自身のキャッシュを更新する際、キャッシュデータベースを更新しながら同時にクライアントにコンテンツを配信します。リクエストされたオブジェクトを含むクライアントへのレスポンスは Traffic Server がオリジンサーバーからの完全なレスポンスヘッダーを受信したらすぐに開始されます。

HTTP リバースプロキシーを設定するためには、次のタスクを行う必要があります

remap.config ファイルにマッピングルールを作成する (HTTP リクエスト用マッピングルールの作成を参照してください) 。
```
map http://www.host.com http://realhost.com
```
リバースプロキシーオプションを有効にする ( HTTP リバースプロキシーの有効化を参照してください)。

上のタスクに加え、省略可能な HTTP リバースプロキシーオプションの設定を行うこともできます。

オリジンサーバーのリダイレクトレスポンスを扱う¶

オリジンサーバーはしばしばブラウザーを他のページにリダイレクトするためにリダイレクトレスポンスを返します。例えば、オリジンサーバーが過負荷になった場合には負荷の少ないサーバーへブラウザーをリダイレクトするかもしれません。オリジンサーバーはウェブページが異なる場所に移動された場合にもリダイレクトを行います。 Traffic Server がリバースプロキシーとして設定されている場合、ブラウザーが他のオリジンサーバーではなく Traffic Server にリダイレクトされるように、リダイレクト先をオリジンサーバーから書き換えなければなりません。

リダイレクト先を書き直すために、Traffic Server はリバースマップルールを使用します。 proxy.config.url_remap.pristine_host_hdr を有効にしていない限り(それがデフォルトです)、一般的には各マップルールに対してリバースマップルールを用意すべきです。リバースマップルールを作成するには HTTP リクエスト用マッピングルールの使用を参照してください。

HTTP リクエスト用マッピングルールの使用¶

Traffic Server は HTTP リバースプロキシー用に2タイプのマッピングルールを使用します。

マップルール¶

マップルール はクライアントのリクエストに含まれる URL をコンテンツが存在する場所に変換します。 Traffic Server がリバースプロキシーモードで HTTP クライアントリクエストを受け取ると、相対 URL とヘッダーから完全な URL を組み立てます。そしてその完全な URL と remap.config ファイル内のターゲット URL とを比較し、マッチするものを探します。ターゲット URL にマッチするリクエスト URL は次の条件を満たさなければなりません。

URL のスキームが同じであること。
URL のホストが同じであること。もしリクエスト URL が修飾されていないホスト名を含んでいる場合、完全修飾されたホスト名を含むターゲット URL にはマッチしません。
ポートが同じであること。もし URL にポートが指定されていない場合、その URL スキームのデフォルトのポートが使用されます。
ターゲット URL のパス部分がリクエスト URL のパスの先頭と一致すること。

Traffic Server がマッチするものを見つけた場合、リクエスト URL をマップルールの置換 URL に変換します。リクエスト URL のホストとパスを置換 URL に一致するようにセットします。もし URL がパスのプレフィックスを持っている場合、 Traffic Server はターゲット URL のパスからプレフィックスを取り除き、置換 URL のパス部分と置き換えます。もしリクエスト URL にマッチするものが 2 つあった場合、 Traffic Server は remap.config ファイル内で先にマッチするほうを適用します。

リバースマップルール¶

リバースマップルール はクライアントがオリジンサーバーに直接アクセスする代わりに Traffic Server にリダイレクトされるようにするために、オリジンサーバーのリダイレクトレスポンス内の URL を Traffic Server に向かうように変換します。例えば、 www.molasses.com というオリジンサーバーに /pub というディレクトリがあり、クライアントがそのオリジンサーバーに /pub のリクエストを送信すると、オリジンサーバーはリクエストされたものがドキュメントではなくディレクトリであることを知らせるために Loacation http://realhost.com/pub/ ヘッダーによるリダイレクトで応答するかもしれません。 (リダイレクトの一般的な使われ方はクライアントがドキュメントを正しくブックマークできるようにする URL の正規化です。)

Traffic Server は (オリジンサーバーからリダイレクト指示を受けた) クライアントが Traffic Server をバイパスしてオリジンサーバーに直接アクセスすることを防ぐために reverse_map ルールを使用します。クライアントが壁にぶつかる多くのケースは realhost.com が実際にはクライアントには解決できない場合です。(例: ファイアーウォールでポートが塞がれている、到達不可能な LAN の IP で動いている)

マップルールとリバースマップルールはどちらも ターゲット (オリジン) URL と置換 (宛先) URL で構成されます。 マップルール では、ターゲット URL は Traffic Server を指し、置換 URL はオリジナルコンテントがある場所を指しています。 リバースマップルール では、ターゲット URL はオリジナルコンテントがある場所を指し、置換 URL は Traffic Server を指しています。 Traffic Server はマッピングルールを Traffic Server の config ディレクトリにある :file:``remap.config` に保存します。

HTTP リクエスト用マッピングルールの作成¶

マッピングルールを作成するには :

remap.config ファイルにマップルールとリバースマップルールを入力してください。
設定の変更を反映するにはコマンド traffic_ctl config reload を実行してください。

HTTP リバースプロキシーの有効化¶

リバースプロキシーを有効にするには :

Edit proxy.config.reverse_proxy.enabled in records.yaml.
```
CONFIG proxy.config.reverse_proxy.enabled INT 1
```
設定の変更を反映するにはコマンド traffic_ctl config reload を実行してください。

省略可能な HTTP リバースプロキシーオプションの設定¶

Traffic Server は records.yaml でいくつかのリバースプロキシー設定オプションを提供し次のことを可能にします。

Traffic Server がリクエストを変換する際にホストヘッダーの情報を維持するように設定する。 proxy.config.url_remap.pristine_host_hdr を参照してください。
Traffic Server がマッピングルールのリストに存在するオリジンサーバーへのリクエストのみに応えるように設定する。結果として、リストに存在しないオリジンサーバーへのリクエストは処理されません。 proxy.config.url_remap.remap_required を参照してください。
古めのクライアントから届くリクエスト (例 Host ヘッダーを含まないもの) のリダイレクト先となる代替 URL を指定する。 proxy.config.header.parse.no_host_url_redirect を参照してください。

これらの設定の変更を反映するにはコマンド traffic_ctl config reload を実行してください。

HTTP リクエストのリダイレクト¶

Traffic Server をどのオリジンサーバーにもコンタクトさせることなく HTTP リクエストをリダイレクトするように設定できます。例えば、http://www.ultraseek.com へのすべてのリクエストを```http://www.server1.com/products/portal/search/`` にリダイレクトする場合はすべての www.ultraseek.com への HTTP リクエストは直接 www.server1.com/products/portal/search に向かいます。

Traffic Server を恒久的または一時的なリダイレクトを行うように設定できます。 恒久的なリダイレクト はブラウザーがブックマークを更新できるように URL の変更を (HTTP ステータスコード 301 を返すことで) ブラウザーに通知します。 一時的なリダイレクト は今回のリクエストに限った URL の変更を (HTTP ステータスコード 307 を返すことで)ブラウザーに通知します。

リダイレクトルールをセットするには :

各リダイレクトごとに remap.config ファイルにマッピングルールを入力してください。
設定の変更を反映するにはコマンド traffic_ctl config reload を実行してください。

例¶

次の設定は www.server1.com へのすべての HTTP リクエストを恒久的に www.server2.com へリダイレクトします。

redirect http://www.server1.com http://www.server2.com