Apache Tomcat 连接器 - AJP 协议参考

原始文档由 Dan Milstein 撰写，[email protected]，时间为 2000 年 12 月。本文档由一个 xml 文件生成，以便更轻松地集成到 Tomcat 文档中。

本文档描述了 Apache JServ 协议版本 1.3（以下简称 ajp13）。显然，目前没有关于该协议工作原理的文档。本文档旨在弥补这一缺陷，以便为 JK 维护人员以及希望将该协议移植到其他地方（例如，移植到 jakarta 4.x）的人员提供便利。

我不是该协议的设计者之一——我相信 Gal Shachor 是最初的设计者。本文档中的所有内容均取自我在 tomcat 3.x 代码中发现的实际实现。我希望它有用，但我不能保证其完全准确。我也不清楚为什么做出某些设计决策。在我能够做到的地方，我提供了一些对某些选择做出可能性的理由，但那只是我的猜测。总体而言，Shachor 编写的 C 代码非常简洁易懂（尽管几乎完全没有文档）。我已经清理了 Java 代码，我认为它相当易读。

根据 Gal Shachor 发送给 jakarta-dev 邮件列表的电子邮件，JK（以及 ajp13）的最初目标是通过以下方式扩展 mod_jserv 和 ajp12（我只包括与 Web 服务器和 servlet 容器之间的通信相关的目标）

• 提高性能（特别是速度）。
• 添加对 SSL 的支持，以便 isSecure() 和 getScheme() 可以在 servlet 容器中正常运行。客户端证书和密码套件将作为请求属性提供给 servlet。

ajp13 协议是面向数据包的。出于性能原因，可能选择二进制格式而不是更易读的纯文本。Web 服务器通过 TCP 连接与 servlet 容器通信。为了减少昂贵的套接字创建过程，Web 服务器将尝试保持与 servlet 容器的持久 TCP 连接，并对多个请求/响应周期重复使用连接。

一旦连接被分配给特定请求，在请求处理周期终止之前，它将不会用于任何其他请求。换句话说，请求不会通过连接多路复用。这使得连接两端的代码更加简单，尽管它确实导致一次打开更多连接。

一旦 Web 服务器打开与 servlet 容器的连接，该连接可以处于以下状态之一

• 空闲
  没有请求通过此连接处理。
• 已分配
  连接正在处理特定请求。

一旦连接被分配来处理特定请求，基本请求信息（例如 HTTP 头等）将以高度浓缩的形式通过连接发送（例如，通用字符串被编码为整数）。该格式的详细信息如下所示在请求数据包结构中。如果请求有正文（内容长度 > 0），则在紧随其后的单独数据包中发送该正文。

此时，servlet 容器可能已准备好开始处理请求。在处理过程中，它可以将以下消息发回 Web 服务器

• SEND_HEADERS
  将一组头发送回浏览器。
• SEND_BODY_CHUNK
  将一部分正文数据发送回浏览器。
• GET_BODY_CHUNK
  如果尚未传输所有数据，则从请求中获取更多数据。这是必需的，因为数据包具有固定的最大大小，并且可以将任意数量的数据包含在请求正文中（例如，对于上传的文件）。（注意：这与 HTTP 分块传输无关）。
• END_RESPONSE
  完成请求处理周期。

每条消息都附带一个格式不同的数据包。有关详细信息，请参见下面的响应数据包结构。

此协议继承了 XDR 的一部分，但在很多方面有所不同（例如，没有 4 字节对齐）。

AJP13 对所有数据类型使用网络字节顺序。

此协议中有四种数据类型：字节、布尔值、整数和字符串。

字节

单个字节。

布尔值

单个字节，1 = true，0 = false。在某些地方，使用其他非零值作为 true（即 C 风格）可能有效，但在其他地方则无效。

整数

0 到 2^16（32768）范围内的数字。存储在 2 个字节中，高位字节在前。

字符串

可变大小的字符串（长度受 2^16 限制）。先将长度打包到两个字节中进行编码，然后是字符串（包括终止符“\0”）。请注意，编码的长度不包括尾随的“\0”——它类似于strlen。这在 Java 方面会造成一些混乱，其中充斥着奇怪的自动增量语句来跳过这些终止符。我相信这样做是为了让 C 代码在读取 servlet 容器发回的字符串时能够额外高效——使用终止符 \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 的请求标头，则没有发送第二个请求标头数据包的规定（我认为对于响应标头已正确处理，尽管我不确定）。我不知道是否有办法将超过 8K 的数据放入该初始请求标头集，但我敢打赌有办法（将长 Cookie 与长 SSL 信息和大量环境变量结合起来，你应该可以轻松达到 8K）。我认为在这种情况下，连接器会在尝试发送任何标头之前失败，但我并不确定。

身份验证呢？Web 服务器和容器之间的连接似乎没有任何身份验证。这让我觉得有潜在危险。