Apache Tomcat コネクタ - AJP プロトコル リファレンス

元のドキュメントは Dan Milstein 氏（danmil@shore.net）によって2000年12月に書かれました。現在のドキュメントは、Tomcat ドキュメントへの統合を容易にするために、XML ファイルから生成されています。

これは、Apache JServ プロトコルバージョン 1.3 (以降 ajp13) について説明しています。現在、プロトコルの動作に関するドキュメントは存在しないようです。このドキュメントは、JK のメンテナや、プロトコルをどこか（例えば jakarta 4.x）に移植したい人のために、その状況を改善しようとする試みです。

私はこのプロトコルの設計者ではありません。元の設計者は Gal Shachor 氏だと考えています。このドキュメントの内容はすべて、tomcat 3.x のコードで見つけた実際の実装から派生したものです。これが役に立つことを願っていますが、完全な正確性を保証することはできません。また、なぜ特定の設計上の決定がなされたのかはわかりません。可能な限り、特定の選択の理由を推測してみましたが、それはあくまでも私の推測です。一般的に、Shachor 氏が書いた C コードは非常にきれいで理解しやすいものです（ほとんどドキュメント化されていませんが）。Java コードはクリーンアップしたので、 reasonably 可読性が高いと思います。

Gal Shachor 氏から jakarta-dev メーリングリストに送られたメールによると、JK (そして ajp13) の当初の目標は、mod_jserv と ajp12 を拡張することでした (Web サーバーとサーブレットコンテナ間の通信に関連する目標のみを記載しています)。

• パフォーマンスの向上 (特に速度)。
• SSL のサポートを追加することで、isSecure() と getScheme() がサーブレットコンテナ内で正しく機能するようにする。クライアント証明書と暗号スイートは、リクエスト属性としてサーブレットで利用できるようになります。

ajp13 プロトコルはパケット指向です。パフォーマンス上の理由から、より可読性の高いプレーンテキストではなく、バイナリ形式が選択されたと考えられます。Web サーバーは、TCP 接続を介してサーブレットコンテナと通信します。ソケット作成というコストのかかるプロセスを削減するために、Web サーバーはサーブレットコンテナへの永続的な TCP 接続を維持し、複数のリクエスト/レスポンスサイクルで接続を再利用しようとします。

接続が特定のリクエストに割り当てられると、リクエスト処理サイクルが終了するまで、他のリクエストには使用されません。つまり、リクエストは接続上で多重化されません。これにより、接続の両端のコードが大幅に簡素化されますが、一度に開かれる接続の数が増加します。

Web サーバーがサーブレットコンテナへの接続を開くと、接続は以下のいずれかの状態になります。

• アイドル
  この接続ではリクエストが処理されていません。
• 割り当て済み
  接続は特定のリクエストを処理しています。

接続が特定のリクエストを処理するために割り当てられると、基本的なリクエスト情報（HTTP ヘッダーなど）は、非常に圧縮された形式（例えば、一般的な文字列は整数としてエンコードされる）で接続を介して送信されます。その形式の詳細は、以下のリクエストパケット構造に記載されています。リクエストに本文がある場合 (content-length > 0)、それは直後に別のパケットで送信されます。

この時点で、サーブレットコンテナはリクエストの処理を開始できる状態になっているはずです。処理中に、サーブレットコンテナは Web サーバーに以下のメッセージを送信できます。

• SEND_HEADERS
  ブラウザにヘッダーのセットを送信します。
• SEND_BODY_CHUNK
  ブラウザに本文データのチャンクを送信します。
• GET_BODY_CHUNK
  リクエストデータがすべて転送されていない場合は、さらにデータを取得します。これは、パケットの最大サイズが固定されており、リクエストの本文には任意量のデータを含めることができるためです（例えば、ファイルのアップロード）。(注: これは HTTP チャンク転送とは関係ありません)。
• END_RESPONSE
  リクエスト処理サイクルを終了します。

各メッセージには、異なる形式のパケットデータが付属しています。詳細は、以下のレスポンスパケット構造を参照してください。

このプロトコルには XDR の影響が多少ありますが、多くの点で異なります (例えば、4 バイトアライメントがありません)。

AJP13 は、すべてのデータ型にネットワークバイトオーダーを使用します。

プロトコルには、バイト、ブール値、整数、文字列の 4 つのデータ型があります。

バイト

1 バイト。

ブール値

1 バイト。1 = true、0 = false。true として他のゼロ以外の値を使用する（つまり C スタイル）と、一部の場所では機能するかもしれませんが、他の場所では機能しません。

整数

0 から 2^16 (32768) の範囲の数値。上位バイトが先頭に来る 2 バイトで格納されます。

文字列

可変長の文字列 (長さは 2^16 で制限されます)。長さが最初に 2 バイトにパックされ、その後に文字列が続きます (終端文字 '\0' を含む)。エンコードされた長さに末尾の '\0' は含まれていないことに注意してください。これは strlen のようです。これは Java 側では少し混乱します。Java 側では、これらの終端文字をスキップするために、奇妙な自動インクリメント文が散らばっています。これが行われた理由は、サーブレットコンテナが送り返す文字列を読み取るときに C コードを非常に効率的にするためだと考えています。終端文字 \0 を使用すると、C コードはコピーすることなく、単一バッファへの参照を渡すことができます。\0 がない場合、C コードは文字列の概念を得るために、内容をコピーする必要があります。サイズ -1 (65535) はヌル文字列を示し、この場合は長さの後にデータが続きません。

サーバーからコンテナへの「リクエストの転送」タイプのメッセージの場合

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)

attributes はオプションで、以下の構造を持っています。

attribute_name := sc_a_name | (sc_a_req_attribute string)

attribute_value := (string)

最も重要なヘッダーは "content-length" であることに注意してください。これは、コンテナが直後に別のパケットを探すかどうかを決定するためです。

リクエストの転送の要素の詳細な説明。

コンテナがサーバーに返送できるメッセージ用。

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)

詳細

リクエストヘッダーが最大パケットサイズを超えた場合はどうなりますか？ 8Kを超えるリクエストヘッダーがある場合に、2番目のリクエストヘッダーパケットを送信する規定はありません（レスポンスヘッダーの場合は正しく処理されていると思いますが、確信はありません）。 8Kを超えるデータをリクエストヘッダーの初期セットに取得する方法があるかどうかはわかりませんが、あると確信しています（長いCookieと長いssl情報を多くの環境変数と組み合わせると、簡単に8Kに到達するはずです）。この場合、コネクタはヘッダーを送信しようとせずに失敗すると思いますが、確信はありません。

認証はどうですか？ Webサーバーとコンテナ間の接続の認証はないようです。これは潜在的に危険なように思われます。