From d2faea59dfadb72d7e5c892dcdbfb0ef5ab9702d Mon Sep 17 00:00:00 2001 From: Hiroaki Kawai Date: Sun, 21 Nov 2004 04:00:31 +0000 Subject: [PATCH] New Japanese translation. # flush the work we did at ApacheCon2004/SVN migration. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@106065 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/mod_cache.xml.ja | 390 ++++++++++++++++ docs/manual/mod/mod_disk_cache.xml.ja | 159 +++++++ docs/manual/mod/mod_proxy_ajp.xml.ja | 524 ++++++++++++++++++++++ docs/manual/mod/mod_proxy_balancer.xml.ja | 49 ++ 4 files changed, 1122 insertions(+) create mode 100644 docs/manual/mod/mod_cache.xml.ja create mode 100644 docs/manual/mod/mod_disk_cache.xml.ja create mode 100644 docs/manual/mod/mod_proxy_ajp.xml.ja create mode 100644 docs/manual/mod/mod_proxy_balancer.xml.ja diff --git a/docs/manual/mod/mod_cache.xml.ja b/docs/manual/mod/mod_cache.xml.ja new file mode 100644 index 0000000000..d59e6b0c8e --- /dev/null +++ b/docs/manual/mod/mod_cache.xml.ja @@ -0,0 +1,390 @@ + + + + + + + + + +mod_cache +URI をキーにしたコンテンツのキャッシュ +Experimental +mod_cache.c +cache_module + + + + これは実験的なモジュールです。文書もまだ開発中です... + + +

mod_cache はローカルのコンテンツやプロキシされた + コンテンツをキャッシュするために使われる RFC 2616 準拠の + HTTP コンテンツキャッシュを実装しています。mod_cache + の動作にはストレージを管理するモジュールが必要です。標準 + Apache 配布には二つストレージ管理モジュールが含まれています:

+ +
+
mod_disk_cache
+
ディスクを使用したストレージ管理機構を実装しています。
+ +
mod_mem_cache
+
メモリを使用したストレージ管理機構を実装しています。 + mod_mem_cache は次の二つのモードのどちらかで動作する + ように設定できます: オープンされているファイル記述子をキャッシュするモードか、 + ヒープ上でのオブジェクトの自体をキャッシュをするモードです。 + mod_mem_cache はローカルで生成されるコンテンツや、 + mod_proxy が + ProxyPass を使って設定されている + ときの (つまりリバースプロキシ での) バックエンドサーバの + コンテンツをキャッシュするのに使えます。
+
+ +

コンテンツのキャッシュへの保存と取得は URI に基づいたキーが使われます。 + アクセス保護のかけられているコンテンツはキャッシュされません。

+ + + + +
サンプル設定 + Sample httpd.conf + #
+ # Sample Cache Configuration
+ #
+ LoadModule cache_module modules/mod_cache.so
+
+ <IfModule mod_cache.c>
+ + #LoadModule disk_cache_module modules/mod_disk_cache.so
+ # If you want to use mod_disk_cache instead of mod_mem_cache, + # uncomment the line above and comment out the LoadModule line below. + <IfModule mod_disk_cache.c>
+ + CacheRoot c:/cacheroot
+ CacheSize 256
+ CacheEnable disk /
+ CacheDirLevels 5
+ CacheDirLength 3
+ + </IfModule>
+
+ LoadModule mem_cache_module modules/mod_mem_cache.so
+ <IfModule mod_mem_cache.c>
+ + CacheEnable mem /
+ MCacheSize 4096
+ MCacheMaxObjectCount 100
+ MCacheMinObjectSize 1
+ MCacheMaxObjectSize 2048
+ + </IfModule>
+ + </IfModule> + +
+ + +CacheEnable +指定したストレージ管理方式を使ってのキャッシュを有効にする +CacheEnable cache_type url-string +server configvirtual host + + + +

CacheEnable ディレクティブで mod_cache + モジュールが url-string 以下の URL をキャッシュするようにします。 + キャッシュストレージ管理方式は cache_type 引数で指定します。 + cache_type mem で、 + mod_mem_cache で実装されているメモリを使ったストレージ + 管理方式を使うように mod_cache に指示します。 + cache_type disk で、 + mod_disk_cache で実装されているディスクを使ったストレージ + 管理を使うように mod_cache に指示します。 + cache_type fd は mod_cache に + mod_mem_cache により実装されているファイル記述子の + キャッシュを使うように指示します。

+ +

(下の例のように) CacheEnable ディレクティブの + URL 空間が重複しているときは、該当するストレージ方式を順に試して、 + 実際にリクエストの処理ができると、その方式で処理します。 + ストレージ管理方式が実行される順番は設定ファイル中の + CacheEnable の順番により決定されます。

+ + + CacheEnable mem /manual
+ CacheEnable fd /images
+ CacheEnable disk /
+ + + + + +CacheDisable +特定の URL をキャッシュしない +CacheDisable url-string +server configvirtual host + + + +

CacheDisable ディレクティブで + mod_cache モジュールが url-string 以下の + URL をキャッシュしないようにします。

+ + 例 + CacheDisable /local_files + + + + + +CacheMaxExpire +ドキュメントをキャッシュする最大時間を秒数で現したもの +CacheMaxExpire seconds +CacheMaxExpire 86400 (一日) +server configvirtual host + + + +

CacheMaxExpire ディレクティブは、 + キャッシュする HTTP ドキュメントを、元のサーバ問い合わせないまま最大何秒 + 保持してもよいかを指定します。つまり、ドキュメントは最大でこの秒数間分古く + なることになります。この最大値は、(訳注:レスポンス中で)ドキュメントと共に + ドキュメントの期日が提供されている場合でも適用されます。

+ + + CacheMaxExpire 604800 + + + + + +CacheDefaultExpire +期日が指定されていないときにドキュメントをキャッシュするデフォルトの期間 +CacheDefaultExpire seconds +CacheDefaultExpire 3600 (1時間) +server configvirtual host + + + +

CacheDefaultExpire ディレクティブはドキュメントに + 期日 (expiry) や最終修正時刻 (last-modified) が指定されていない場合の + デフォルトの時間を指定します。CacheMaxExpire + ディレクティブで指定された値はこの設定を上書きしません。

+ + + CacheDefaultExpire 86400 + + + + + +CacheIgnoreNoLastMod +応答に Last Modified が無くても気にしないようにする +CacheIgnoreNoLastMod On|Off +CacheIgnoreNoLastMod Off +server configvirtual host + + + +

通常、Last-Modified による最終修正時刻の無いドキュメントはキャッシュ + されません。(例えば mod_include による処理のときなどに) + Last-Modified 時刻が消去されたり、そもそも最初から提供されていない + 状況があります。CacheIgnoreNoLastMod ディレクティブは + Last-Modified 日時が指定されていないドキュメントでも、それ無しで + キャッシュするように指定することができます。ドキュメントに + 最終修正時刻 (Last-Modified) 期日 (expiry) がない場合は、期日の + 生成に CacheDefaultExpire が使われます。

+ + + CacheIgnoreNoLastMod On + + + + + +CacheIgnoreCacheControl +クライアントがコンテンツをキャッシュしないように指示しても無視する。 +CacheIgnoreCacheControl On|Off +CacheIgnoreCacheControl Off +server configvirtual host + + + +

no-cache ヘッダや no-store ヘッダのあるドキュメントは通常キャッシュ + されません。CacheIgnoreCacheControl ディレクティブ + でこの動作を上書きできるようになります。 + CacheIgnoreCacheControl On とするとサーバに + ドキュメントに no-cache や no-store ヘッダがあったとしてもドキュメントを + キャッシュするように指示します。認証を必要とするドキュメントは決して + キャッシュされません。

+ + + CacheIgnoreCacheControl On + + + + + +CacheLastModifiedFactor +LastModified の日付に基づいて Expiry の日付を計算するための重みを +指定する + +CacheLastModifiedFactor float +CacheLastModifiedFactor 0.1 +server configvirtual host + + + +

ドキュメントに Last-Modified の日付が無いけれども Expiry の日付が + あるというときに、Expiry 日を最終修正時刻からの経過時間として計算する + ようにできます。Expiry 日を次の計算式に従って生成するのですが、 + そのときに使われる factor を + CacheLastModifiedFactor ディレクティブで指定します。 +

+ +

expiry-period = time-since-last-modified-date * factor + expiry-date = current-date + expiry-period

+ +

例えば、ドキュメントが 10 時間前に最後に修正されていて、 + factor が 0.1 であれば、期日は 10*0.1 = 1 時間に + 設定されます。現在時刻が 3:00pm であれば、計算された期日は + 3:00pm + 1hour = 4:00pm になります。

+ +

期日が CacheMaxExpire で設定されている値 + より大きくなってしまっている場合は、CacheMaxExpire + の設定値が優先されます。

+ + + CacheLastModifiedFactor 0.5 + + + + + +CacheForceCompletion +リクエストがキャンセルされてもキャッシュを完了するかどうかを +決める送られたドキュメントの割合を指定する。 +CacheForceCompletion Percentage +CacheForceCompletion 60 +server configvirtual host + + + +

通常、応答がキャッシュされてクライアントに送られている最中に + リクエストがキャンセルされると、応答の処理は中止されて、キャッシュの + エントリも削除されます。CacheForceCompletion + ディレクティブは、リクエストがキャンセルされても、キャッシュ処理を + 完了まで続けるかどうかのしきい値を指定します。

+ +

しきい値は 1 と 100 の間で指定する + 割合です。0 ではデフォルトが使われます。 + 100 では、完全に送信が完了したドキュメントのみを + キャッシュします。60 から 90 の間の値が推奨値です。

+ + + CacheForceCompletion 80 + + + 注: + この機能は現時点では実装されていません。 + + + + + +CacheIgnoreHeaders +指定された HTTP ヘッダをキャッシュに保存しない。 + +CacheIgnoreHeaders header-string [header-string] ... +CacheIgnoreHeaders None +server configvirtual host + + + +

RFC 2616 によると、hop-by-hop HTTP ヘッダはキャッシュには保管されません。 + 以下のヘッダは hop-by-hop ヘッダに該当しますので、 + CacheIgnoreHeaders + の設定に関係なくキャッシュには保管されません:

+
    +
  • Connection
    • +
  • Keep-Alive
    • +
  • Proxy-Authenticate
    • +
  • Proxy-Authorization
    • +
  • TE
    • +
  • Trailers
    • +
  • Transfer-Encoding
    • +
  • Upgrade
    • +
+ +

CacheIgnoreHeaders で + キャッシュに保管しない追加の HTTP ヘッダを指定します。 + 例えば、クッキーをキャッシュに保管しないようにした方がよい場合も + あるでしょう。

+ +

CacheIgnoreHeaders の引数は、 + キャッシュに保管しない HTTP ヘッダを空白区切りにしたリスト形式です。 + キャッシュに保管しないヘッダが hop-by-hop ヘッダだけの場合 + (RFC 2616 準拠の動作のとき) は、 + CacheIgnoreHeaders を None + に設定できます。

+ + 例 1 + CacheIgnoreHeaders Set-Cookie + + + 例 2 + CacheIgnoreHeaders None + + + 警告: + Expires のような適切のキャッシュ管理のために必要な + ヘッダが CacheIgnoreHeaders の設定により + 保管されていないときは、mod_cache の動作は定義されていません。 + + + + + diff --git a/docs/manual/mod/mod_disk_cache.xml.ja b/docs/manual/mod/mod_disk_cache.xml.ja new file mode 100644 index 0000000000..802a4ab251 --- /dev/null +++ b/docs/manual/mod/mod_disk_cache.xml.ja @@ -0,0 +1,159 @@ + + + + + + + + + +mod_disk_cache +URI をキーにしたコンテンツキャッシュストレージ管理 +Experimental +mod_disk_cache.c +disk_cache_module + + + + これは実験的なモジュールです。ドキュメンテーションもまだ開発中です... + + +

mod_disk_cache はディスクを使用したストレージ + 管理機構を実装しています。主に + mod_proxy と組み合わせて使われます。

+ +

コンテンツのキャッシュへの保存と取得は URI に基づいたキーが使われます。 + アクセス保護のかけられているコンテンツはキャッシュされません。

+ + 注: +

mod_disk_cache は + mod_cache を必要とします

+ + + + +CacheRoot +キャッシュファイルが保管されるルートディレクトリ +CacheRoot directory +server configvirtual host + + + +

CacheRoot ディレクティブはキャッシュファイルを + 保管するためのディスク上のディレクトリを指定します。mod_disk_cache モジュールが Apache サーバにロードされて + いるか、組み込まれていれば、このディレクティブは必ず + 定義しなければなりません。 + CacheRoot の値を指定しなければ、 + 設定ファイルの処理でエラーになります。CacheDirLevels ディレクティブと CacheDirLength ディレクティブが + 指定されたルートディレクトリ下のディレクトリ構成を定義します。

+ + + CacheRoot c:/cacheroot + + + + + +CacheDirLevels +キャッシュのサブディレクトリの深さの数 +CacheDirLevels levels +CacheDirLevels 3 +server configvirtual host + + + +

CacheDirLevels ディレクティブはキャッシュの + サブディレクトリの深さを設定します。キャッシュデータは CacheRoot ディレクトリから + このディレクトリの深さ分下のディレクトリに保存されます。

+ + +

CacheDirLevels* + CacheDirLength の + 結果は 20 以内でなければなりません。

+ + + + CacheDirLevels 5 + + + + + +CacheDirLength +サブディレクトリ名の文字数 +CacheDirLength length +CacheDirLength 2 +server configvirtual host + + + +

CacheDirLength ディレクティブはキャッシュ + 階層の各サブディレクトリの文字数を設定します。

+ + +

CacheDirLevels* + CacheDirLength の + 結果は 20 以内でなければなりません。

+ + + + CacheDirLength 4 + + + + + +CacheMinFileSize +キャッシュに保管されるドキュメントの最小限の (バイトでの) 大きさ +CacheMinFileSize bytes +CacheMinFileSize 1 +server configvirtual host + + + +

CacheMinFileSize ディレクティブは、ドキュメントを + キャッシュするかどうかを判定する、最小のサイズをバイト数で設定します。

+ + + CacheMinFileSize 64 + + + + + +CacheMaxFileSize +キャッシュに保管されるドキュメントの最大の (バイトでの) サイズ +CacheMaxFileSize bytes +CacheMaxFileSize 1000000 +server configvirtual host + + + +

CacheMaxFileSize ディレクティブは、ドキュメントを + キャッシュするかどうかを判定する、最大のサイズをバイト数で設定します。

+ + + CacheMaxFileSize 64000 + + + + + diff --git a/docs/manual/mod/mod_proxy_ajp.xml.ja b/docs/manual/mod/mod_proxy_ajp.xml.ja new file mode 100644 index 0000000000..7c5881bf76 --- /dev/null +++ b/docs/manual/mod/mod_proxy_ajp.xml.ja @@ -0,0 +1,524 @@ + + + + + + + + + +mod_proxy_ajp +mod_proxy で AJP +をサポートするためのモジュール +Extension +proxy_ajp.c +proxy_ajp_module + + +

本モジュールには mod_proxy が必要です。 + Apache JServ Protocol version 1.3 (以降 AJP13) + をサポートします。

+ +

AJP13 プロトコルを扱えるようにするには + mod_proxy と mod_proxy_ajp + をサーバに組み込む必要があります。

+ + 警告 +

安全なサーバにするまでプロクシ機能は有効にしないでください。 + オープンプロキシサーバはあなた自身のネットワークにとっても、 + インターネット全体にとっても危険です。

+ + + +mod_proxy + +
プロトコルの概要 +

AJP13 プロトコルはパケット指向です。 + 可読なプレーンテキスト形式ではなくバイナリ形式になったのは、 + おそらくパフォーマンス上の理由によります。 + ウェブサーバはサーブレットコンテナと TCP コネクションで通信します。 + ソケット生成は重い処理なので、負荷を減らすために、サーブレットコンテナとの + TCP 接続を維持し、複数のリクエスト・レスポンス処理サイクルに対して一つの + コネクションを使いまわすようになっています。

+

あるリクエストにコネクションが割り当てられると、その処理サイクルが + 完了するまで他のものに使われることはありません。 + つまりコネクション上では、リクエストの同時処理は行われません。 + このため、コネクション両端での実行するコードを簡潔にできる一方で、 + 同時に開くコネクションは多くなっています。

+

サーブレットコンテナへのコネクションを開いた後は、コネクションの状態は + 次のどれかになります:

+
    +
  • Idle
    コネクション上で処理されているリクエストはありません。
    • +
  • Assigned
    コネクションはリクエストを処理中です。
    • +
+

コネクションが特定のリクエストにアサインされると、基本的な情報 (例えば + HTTP ヘッダ等) が圧縮された形 (例えば通常の文字列は整数にエンコードされます) + で転送されます。詳細は下記の「リクエストパケットの構造」を参照してください。 + リクエストにボディが存在 (content-length > 0) すれば、 + 基本的な情報の直後に別パケットで転送されます。

+

この時点でおそらく、サーブレットコンテナは処理を開始できるようになります。 + ですので、次のメッセージをウェブサーバに戻して知らせられるようになります。

+
    +
  • SEND_HEADERS
    ブラウザにヘッダを送信します。
    • +
  • SEND_BODY_CHUNK
    ブラウザにボディデータのチャンクを送ります。 +
    • +
  • GET_BODY_CHUNK
    リクエストのデータを全て受け取り終わっていないときに、 + 残っているデータを受け取ります。パケットにある定まった最大長があり、任意の + 大きさのデータがリクエストのボディとして含まれうる場合 + (例えばファイルのアップロードの場合) に必要となります。 + (注: HTTP のチャンク転送とは関連ありません。)
    • +
  • END_RESPONSE
    リクエスト処理サイクルを終了します。
    • +
+

個々のメッセージはそれぞれ異なるデータパケット形式になっています。 + 後述の「レスポンスパケットの構造」を参照してください。

+
+ +
基本パケット構造 +

このプロトコルには XDR から受け継いだ部分が少しありますが、多くの点で + 異なります (例えば 4 バイトアライメントでないことなど) 。

+

バイトオーダー: 個々のバイトのエンディアンがどうなっているかは、 + 私は詳しくないのですが、リトルエンディアンになっていると思います。 + XDR 仕様でそうなっているのと、素晴らしいことに sys/socket ライブラリが + (C で) そういう風にできているのでそうなのだと思いました。 + ソケット呼び出しの内部についてより詳しい方がいらっしゃいましたら、 + ご教授ください。

+

プロトコルには 4 つのデータタイプがあります: byte, boolean, + integer, string です。

+
+
Byte
バイト一つです。
+
Boolean
+
バイト一つで、1 = true, 0 = false です。 + (C のように) 非零を真として扱ってしまうと、ある場合は動くかもしれませんし、 + 動かないかもしれません。
+
Integer
+
0 から 2^16 (32768) の範囲の数字。高次の 2 バイトが + 先に格納されます。
+
String
+
可変長の文字列 (2^16 が長さの上限) 。長さ情報のパケット 2 バイトの後に + 文字列 (終端文字 '\0' を含む) が続く形式でエンコードされます。 + エンコードされている長さ情報は最後の '\0' をカウントしない + ことに注意してください――これは strlen と同様です。 + これらの終端文字をスキップするために、あまり意味の無いインクリメント文 + をたくさん書かないといけないのは、 + Java の側から見ると少し紛らわしく感じられるかもしれません。 + こうなった理由はおそらく、Servlet コンテナから返される文字列を読み出す時に、 + 効率よく C のコードを書けるようにする――サーブレットから返される + 文字列は \0 文字で終端されているので、C のコードではわざわざコピーをせずに、 + 一つのバッファへのリファレンスを取り回すように書くことができる―― + ためだと思われます。 + '\0' 文字がない場合は、C では文字列の規則に合うようにコピーしなければ + いけなくなってしまいます。
+
+ +
パケットサイズ +

多くのコードでそうなっているのですが、パケットサイズの最大サイズは + 8 * 1024 (8K) です。パケットの実際の長さはヘッダに + エンコードされて入っています。

+
+
パケットヘッダ +

サーバからコンテナに送出されるパケットは 0x1234 で始まります。 + コンテナからサーバに送られるパケットは AB (ASCII コード A と + ASCII コード B) で始まります。この二バイトの後に、ペイロード長が (上記の形式で) + 続きます。このため、ペイロード長の最大値は 2^16 にできるように思えますが、 + 実際にはコードでは最大値は 8K に設定されています。

+ + + + + + + + + + + + + + + + + + + +
パケット形式 (Server->Container)
Byte01234...(n+3)
Contents0x120x34データ長 (n)Data
+ + + + + + + + + + + + + + + + + + + +
パケット形式 (Container->Server)
Byte01234...(n+3)
ContentsABデータ長 (n)Data
+

ほとんどのパケットで、ペイロードの最初のバイトがメッセージの型をエンコード + しています。例外はサーバからコンテナに送られるリクエストボディパケットです + ――これらは標準的なパケット形式 (0x1234 とパケット長) + ですが、その後に続くプレフィックスコードがありません。

+

ウェブサーバは次のメッセージをサーブレットコンテナに送出できます。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
コードパケットの型意味
2Forward Requestリクエスト処理サイクルを後続のデータとともに開始する。
7Shutdownウェブサーバがコンテナに、コンテナを終了するように伝える。
8Pingウェブサーバがコンテナに制御を受け持つように伝える + (セキュアログインフェーズ) 。
10CPingウェブサーバがコンテナに CPong で即座に応答するように伝える。
noneDataサイズ (2 バイト) とそれに続くボディデータ。
+

基本的なセキュリティを確保するため、ホストされているマシンと同一の + マシンからのリクエストに対してのみ、コンテナは実際に Shutdown + を実行します。

+

最初の Data パケットは、Forward Request + の直後にウェブサーバから送られます。

+

サーブレットコンテナはウェブサーバに、次のタイプのメッセージを送ることが + できます :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
コードパケットの型意味
3Send Body Chunkサーブレットコンテナからウェブサーバに + (そしておそらくそのままブラウザに)、ボディのチャンクを送る。
4Send Headersサーブレットコンテナからウェブサーバに (そしておそらくそのままブラウザに) + レスポンスヘッダを送る。
5End Responseレスポンス (つまりリクエスト処理サイクル) 終了の目印を送る。 +
6Get Body Chunkまだ全て転送されていない場合、残っているリクエストのデータを受け取る。 +
9CPong 応答CPing リクエストに応答する。
+

上記メッセージは、それぞれ内部構造が異なっています。詳細は下記をご覧ください。 +

+
+
+
リクエストパケット構造 +

サーバからコンテナへ送られるメッセージが + Forward Request 型の場合 :

+ 
+AJP13_FORWARD_REQUEST :=
+    prefix_code      (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
+    method           (byte)
+    protocol         (string)
+    req_uri          (string)
+    remote_addr      (string)
+    remote_host      (string)
+    server_name      (string)
+    server_port      (integer)
+    is_ssl           (boolean)
+    num_headers      (integer)
+    request_headers *(req_header_name req_header_value)
+    attributes      *(attribut_name attribute_value)
+    request_terminator (byte) OxFF
+
+

request_headers は次のような構造になっています : + 

+req_header_name := 
+    sc_req_header_name | (string)  [see below for how this is parsed]
+
+sc_req_header_name := 0xA0xx (integer)
+
+req_header_value := (string)
+
 +

属性 はオプションで、次のような構造をしています :

+ 
+attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+
+
+

もっとも重要なヘッダは content-length だということに + 注意してください。コンテナは次のパケットを探すかどうかを、 + それを見て決めるからです。

+
Forward Request 要素の詳細な説明 +
+
Request prefix +

リクエストについては全て、この値は 2 になります。他の Prefix コードの詳細は + 上記をご覧ください。

+
+
Method +

HTTP メソッドは 1 バイトにエンコードされます :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Command NameCode
OPTIONS1
GET2
HEAD3
POST4
PUT5
DELETE6
TRACE7
PROPFIND8
PROPPATCH9
MKCOL10
COPY11
MOVE12
LOCK13
UNLOCK14
ACL15
REPORT16
VERSION-CONTROL17
CHECKIN18
CHECKOUT19
UNCHECKOUT20
SEARCH21
MKWORKSPACE22
UPDATE23
LABEL24
MERGE25
BASELINE_CONTROL26
MKACTIVITY27
+

今後の ajp13 バージョンでは、この一覧にない、今後追加されるメソッドを + 送るかもしれません。

+
+
protocol, req_uri, remote_addr, remote_host, server_name, + server_port, is_ssl +

これらはまさに文字通りのものです。どれも必要で、リクエストの毎回につき + 送られます。

+
+
Headers +

request_headers の構造は次のようなものです : + まずヘッダの数 num_headers がエンコードされます。 + 次にヘッダ名 req_header_name / 値 req_header_value + の組が続きます。効率のため、一般的なヘッダは整数でエンコードして転送します。 + ヘッダ名が基本ヘッダの一覧に無い場合は、通常通り (文字列として、長さ + プレフィックス付きで) 転送されます。一般的なヘッダ + sc_req_header_name の一覧とそのコードは次の通りです + (どれも大文字小文字を区別します) :

+ + + + + + + + + + + + + + + + + + + +
名前コードの値コード名
accept0xA001SC_REQ_ACCEPT
accept-charset0xA002SC_REQ_ACCEPT_CHARSET +
accept-encoding0xA003SC_REQ_ACCEPT_ENCODING +
accept-language0xA004SC_REQ_ACCEPT_LANGUAGE +
authorization0xA005SC_REQ_AUTHORIZATION
connection0xA006SC_REQ_CONNECTION
content-type0xA007SC_REQ_CONTENT_TYPE
content-length0xA008SC_REQ_CONTENT_LENGTH
cookie0xA009SC_REQ_COOKIE
cookie20xA00ASC_REQ_COOKIE2
host0xA00BSC_REQ_HOST
pragma0xA00CSC_REQ_PRAGMA
referer0xA00DSC_REQ_REFERER
user-agent0xA00ESC_REQ_USER_AGENT
+

これを読み込む Java のコードでは、最初の 2 バイト整数を取り込み、 + 目印になるバイト '0xA0' であれば、ヘッダ名の配列の + インデックスを使います。先頭バイトが 0xA0 でない場合は、 + 先頭 2 バイトは文字列長を表す整数であると解釈し、読み込みはじめます。

+

ヘッダ名の長さは 0x9999 (==0xA000 -1) 以上にならないという + 仮定の下に動いていて、少しあいまいですが合理的な挙動になっています。

+ 注: + content-length ヘッダはとても重要です。 + 存在していて非ゼロであれば、リクエストにはボディがある (例えば POST + リクエスト) と推測し、そのボディを取り込むために + 直後のパケットを入力ストリームから読み込みはじめます。 + +
+
属性 +

? プレフィックスで始まる属性 (例 ?context) + は。省略可能です。それぞれ属性の型を示す 1 バイトのコードと、 + 値の文字列が続きます。 + これらは順不同で送ることができます (C のコードは常に下の一覧順に + 送るようですが) 。 + オプションの属性のリストの最後には、特別な終了コードが送られます。 + コードの一覧は :

+ + + + + + + + + + + + + + +
InformationCode ValueNote
?context0x01未実装 +
?servlet_path0x02未実装 +
?remote_user0x03
?auth_type0x04
?query_string0x05
?jvm_route0x06
?ssl_cert0x07
?ssl_cipher0x08
?ssl_session0x09
?req_attribute0x0AName (the name of the + attribute follows)
?ssl_key_size0x0B
are_done0xFFrequest_terminator
+

context と servlet_path は現在の C の + コードではセットされていません。また、ほとんどの Java のコードでも、 + このフィールドで何が送られても無視されます (これらのコードの後に文字列が + 送られると壊れるものもあります)。 + これがバグなのか、単に未実装なのか、歴史的経緯で残っているコードなのか + 分かりませんが、コネクションの両側ともで見当たりません。

+

remote_user と auth_type はおそらく + HTTP レベルの認証を参照していて、リモートユーザのユーザ名と認証に使用した + タイプ (例 Basic, Digest) についてやり取りします。

+

query_string, ssl_cert, + ssl_cipher, ssl_session + は HTTP と HTTPS の対応する部分を参照します。

+

jvm_route はスティッキーセッションのサポート―― + ロードバランスしている複数のサーバ中の特定の Tomcat インスタンスと、 + ユーザのセッションとを紐付ける機能――に使われます。

+

この基本属性一覧に無いものについては、req_attribute + コード 0x0A 経由で属性を何個でも送ることができます。 + 属性の名前と値の文字列の組を、それぞれこのコードの直後に送ります。 + 環境変数はこの方法で伝えられます。

+

最後に属性が全て送信された後に、属性の終端を示す 0xFF + が送出されます。この信号は属性の一覧の終わりを示すと同時に、リクエスト + パケットの終端をも示しています。

+
+
+ +
レスポンスパケット構造 +

コンテナがサーバに送り返すことのできるメッセージ:

+ 
+AJP13_SEND_BODY_CHUNK :=
+  prefix_code   3
+  chunk_length  (integer)
+  chunk        *(byte)
+
+
+AJP13_SEND_HEADERS :=
+  prefix_code       4
+  http_status_code  (integer)
+  http_status_msg   (string)
+  num_headers       (integer)
+  response_headers *(res_header_name header_value)
+
+res_header_name :=
+    sc_res_header_name | (string)   [see below for how this is parsed]
+
+sc_res_header_name := 0xA0 (byte)
+
+header_value := (string)
+
+AJP13_END_RESPONSE :=
+  prefix_code       5
+  reuse             (boolean)
+
+
+AJP13_GET_BODY_CHUNK :=
+  prefix_code       6
+  requested_length  (integer)
+
+
詳細 :
+
Send Body Chunk +

チャンクは基本的にはバイナリデータで、ブラウザに直接送られます。

+
+
Send Headers +

ステータスコードとメッセージが通常の HTTP の通信にはあります (例 + 200 と OK)。レスポンスヘッダ名は、 + リクエストヘッダ名と同様の方法でエンコードされます。 + コードと文字列の判別方法の詳細に関しては、上記の header_encoding + を参照してください。 + 一般的なヘッダのコードは :

+ + + + + + + + + + + + + +
名前コードの値
Content-Type0xA001
Content-Language0xA002
Content-Length0xA003
Date0xA004
Last-Modified0xA005
Location0xA006
Set-Cookie0xA007
Set-Cookie20xA008
Servlet-Engine0xA009
Status0xA00A
WWW-Authenticate0xA00B
+

コードかヘッダ文字列の直後には、ヘッダの値がエンコードされます。

+
+
End Response +

リクエスト処理サイクルの終了を知らせます。reuse フラグが真 + (==1) の場合、現在使用している TCP コネクションは次の新しい + リクエストに使えるようになります。reuse が偽 (C のコードでは + 1 以外の全て) の場合は、コネクションを閉じることになります。

+
+
Get Body Chunk +

(ボディのサイズが大きすぎて最初のパケットに収まらない場合や、 + リクエストがチャンク転送された場合などには、) コンテナはリクエストからの + データ読み込み要求をします。サーバ側はそれに対して、最小 + request_length 最大 (8186 (8 Kbytes - 6)) + の範囲で、未転送で残っているリクエストボディの大きさのデータを + 送り返します。
+ ボディにそれ以上データが残っていない場合 (つまりサーブレットが + ボディの最後を超えて読み込もうとした場合) 、サーバは + ペイロード長 0 の空パケット(0x12,0x34,0x00,0x00) + を送り返します。

+
+
+ + + diff --git a/docs/manual/mod/mod_proxy_balancer.xml.ja b/docs/manual/mod/mod_proxy_balancer.xml.ja new file mode 100644 index 0000000000..9c914d78dd --- /dev/null +++ b/docs/manual/mod/mod_proxy_balancer.xml.ja @@ -0,0 +1,49 @@ + + + + + + + + + +mod_proxy_balancer +負荷分散のための mod_proxy 拡張 +Extension +proxy_balancer.c +proxy_balancer_module +2.1 以降 + + +

本モジュールには mod_proxy が必要です。 + HTTP, FTP と AJP13 + プロトコルのロードバランス機能を持っています。

+ +

ですから、 ロードバランスを有効にする場合 mod_proxy + と mod_proxy_balancer がサーバに組み込まれて + いなければいけません。

+ + 警告 +

安全なサーバにするまでプロクシ機能は有効にしないでください。 + オープンプロキシサーバはあなた自身のネットワークにとっても、 + インターネット全体にとっても危険です。

+ + +mod_proxy + + -- 2.50.1