This document refers to the 2.2 version of Apache httpd, which is no longer maintained. The active release is documented here. If you have not already upgraded, please follow this link for more information.
You may follow this link to go to the current version of this document.
| 説明: | mod_proxy で AJP
をサポートするためのモジュール |
|---|---|
| ステータス: | Extension |
| モジュール識別子: | proxy_ajp_module |
| ソースファイル: | mod_proxy_ajp.c |
本モジュールには mod_proxy が必要です。
Apache JServ Protocol version 1.3 (以降 AJP13)
をサポートします。
AJP13 プロトコルを扱えるようにするには
mod_proxy と mod_proxy_ajp
をサーバに組み込む必要があります。
安全なサーバにするまでプロクシ機能は有効にしないでください。 オープンプロキシサーバはあなた自身のネットワークにとっても、 インターネット全体にとっても危険です。
AJP13 プロトコルはパケット指向です。
可読なプレーンテキスト形式ではなくバイナリ形式になったのは、
おそらくパフォーマンス上の理由によります。
ウェブサーバはサーブレットコンテナと TCP コネクションで通信します。
ソケット生成は重い処理なので、負荷を減らすために、サーブレットコンテナとの
TCP 接続を維持し、複数のリクエスト・レスポンス処理サイクルに対して一つの
コネクションを使いまわすようになっています。
あるリクエストにコネクションが割り当てられると、その処理サイクルが 完了するまで他のものに使われることはありません。 つまりコネクション上では、リクエストの同時処理は行われません。 このため、コネクション両端での実行するコードを簡潔にできる一方で、 同時に開くコネクションは多くなっています。
サーブレットコンテナへのコネクションを開いた後は、コネクションの状態は 次のどれかになります:
コネクションが特定のリクエストにアサインされると、基本的な情報 (例えば
HTTP ヘッダ等) が圧縮された形 (例えば通常の文字列は整数にエンコードされます)
で転送されます。詳細は下記の「リクエストパケットの構造」を参照してください。
リクエストにボディが存在 (content-length > 0) すれば、
基本的な情報の直後に別パケットで転送されます。
この時点でおそらく、サーブレットコンテナは処理を開始できるようになります。 ですので、次のメッセージをウェブサーバに戻して知らせられるようになります。
個々のメッセージはそれぞれ異なるデータパケット形式になっています。 後述の「レスポンスパケットの構造」を参照してください。
このプロトコルには XDR から受け継いだ部分が少しありますが、多くの点で 異なります (例えば 4 バイトアライメントでないことなど) 。
バイトオーダー: 個々のバイトのエンディアンがどうなっているかは、 私は詳しくないのですが、リトルエンディアンになっていると思います。 XDR 仕様でそうなっているのと、素晴らしいことに sys/socket ライブラリが (C で) そういう風にできているのでそうなのだと思いました。 ソケット呼び出しの内部についてより詳しい方がいらっしゃいましたら、 ご教授ください。
プロトコルには 4 つのデータタイプがあります: byte, boolean, integer, string です。
1 = true, 0 = false です。
(C のように) 非零を真として扱ってしまうと、ある場合は動くかもしれませんし、
動かないかもしれません。0 から 2^16 (32768) の範囲の数字。高次の 2 バイトが
先に格納されます。strlen と同様です。
これらの終端文字をスキップするために、あまり意味の無いインクリメント文
をたくさん書かないといけないのは、
Java の側から見ると少し紛らわしく感じられるかもしれません。
こうなった理由はおそらく、Servlet コンテナから返される文字列を読み出す時に、
効率よく C のコードを書けるようにする――サーブレットから返される
文字列は 0円 文字で終端されているので、C のコードではわざわざコピーをせずに、
一つのバッファへのリファレンスを取り回すように書くことができる――
ためだと思われます。
'0円' 文字がない場合は、C では文字列の規則に合うようにコピーしなければ
いけなくなってしまいます。多くのコードでそうなっているのですが、パケットサイズの最大サイズは
8 * 1024 (8K) です。パケットの実際の長さはヘッダに
エンコードされて入っています。
サーバからコンテナに送出されるパケットは 0x1234 で始まります。
コンテナからサーバに送られるパケットは AB (ASCII コード A と
ASCII コード B) で始まります。この二バイトの後に、ペイロード長が (上記の形式で)
続きます。このため、ペイロード長の最大値は 2^16 にできるように思えますが、
実際にはコードでは最大値は 8K に設定されています。
ほとんどのパケットで、ペイロードの最初のバイトがメッセージの型をエンコード
しています。例外はサーバからコンテナに送られるリクエストボディパケットです
――これらは標準的なパケット形式 (0x1234 とパケット長)
ですが、その後に続くプレフィックスコードがありません。
ウェブサーバは次のメッセージをサーブレットコンテナに送出できます。
基本的なセキュリティを確保するため、ホストされているマシンと同一の
マシンからのリクエストに対してのみ、コンテナは実際に Shutdown
を実行します。
最初の Data パケットは、Forward Request
の直後にウェブサーバから送られます。
サーブレットコンテナはウェブサーバに、次のタイプのメッセージを送ることが できます :
上記メッセージは、それぞれ内部構造が異なっています。詳細は下記をご覧ください。
サーバからコンテナへ送られるメッセージが 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 だということに
注意してください。コンテナは次のパケットを探すかどうかを、
それを見て決めるからです。
リクエストについては全て、この値は 2 になります。他の Prefix コードの詳細は 上記をご覧ください。
HTTP メソッドは 1 バイトにエンコードされます :
今後の ajp13 バージョンでは、この一覧にない、今後追加されるメソッドを 送るかもしれません。
これらはまさに文字通りのものです。どれも必要で、リクエストの毎回につき 送られます。
request_headers の構造は次のようなものです :
まずヘッダの数 num_headers がエンコードされます。
次にヘッダ名 req_header_name / 値 req_header_value
の組が続きます。効率のため、一般的なヘッダは整数でエンコードして転送します。
ヘッダ名が基本ヘッダの一覧に無い場合は、通常通り (文字列として、長さ
プレフィックス付きで) 転送されます。一般的なヘッダ
sc_req_header_name の一覧とそのコードは次の通りです
(どれも大文字小文字を区別します) :
これを読み込む Java のコードでは、最初の 2 バイト整数を取り込み、
目印になるバイト '0xA0' であれば、ヘッダ名の配列の
インデックスを使います。先頭バイトが 0xA0 でない場合は、
先頭 2 バイトは文字列長を表す整数であると解釈し、読み込みはじめます。
ヘッダ名の長さは 0x9999 (==0xA000 -1) 以上にならないという
仮定の下に動いていて、少しあいまいですが合理的な挙動になっています。
content-length ヘッダはとても重要です。
存在していて非ゼロであれば、リクエストにはボディがある (例えば POST
リクエスト) と推測し、そのボディを取り込むために
直後のパケットを入力ストリームから読み込みはじめます。
? プレフィックスで始まる属性 (例 ?context)
は。省略可能です。それぞれ属性の型を示す 1 バイトのコードと、
値の文字列が続きます。
これらは順不同で送ることができます (C のコードは常に下の一覧順に
送るようですが) 。
オプションの属性のリストの最後には、特別な終了コードが送られます。
コードの一覧は :
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)
チャンクは基本的にはバイナリデータで、ブラウザに直接送られます。
ステータスコードとメッセージが通常の HTTP の通信にはあります (例
200 と OK)。レスポンスヘッダ名は、
リクエストヘッダ名と同様の方法でエンコードされます。
コードと文字列の判別方法の詳細に関しては、上記の header_encoding
を参照してください。
一般的なヘッダのコードは :
コードかヘッダ文字列の直後には、ヘッダの値がエンコードされます。
リクエスト処理サイクルの終了を知らせます。reuse フラグが真
(==1) の場合、現在使用している TCP コネクションは次の新しい
リクエストに使えるようになります。reuse が偽 (C のコードでは
1 以外の全て) の場合は、コネクションを閉じることになります。
(ボディのサイズが大きすぎて最初のパケットに収まらない場合や、
リクエストがチャンク転送された場合などには、) コンテナはリクエストからの
データ読み込み要求をします。サーバ側はそれに対して、最小
request_length 最大 (8186 (8 Kbytes - 6))
の範囲で、未転送で残っているリクエストボディの大きさのデータを
送り返します。
ボディにそれ以上データが残っていない場合 (つまりサーブレットが
ボディの最後を超えて読み込もうとした場合) 、サーバは
ペイロード長 0 の空パケット(0x12,0x34,0x00,0x00)
を送り返します。