背景：我想将我们的Web服务器/应用程序服务器function分离到不同的机器上（逻辑上或物理上）。 也就是说，我想把一些资源投入到静态内容（静态HTML，图像，Javascript，CSS，video等等）中，并且希望将其他资源用于生成dynamicHTML（我的web应用程序恰好是ColdFusion应用程序，你可能会认为是任何J2EE应用程序）。
我熟悉几种J2EE供应商将其应用程序服务器与Web服务器连接的方法。 例如，Adobe提供了mod_jrun，Tomcat提供了mod_ajp，mod_proxy_ajp，＆mod_jk，Caucho（Resin）提供了mod_caucho等等。这些连接器中的几个允许负载平衡function。 我想他们正在与可以作为集群控制器的应用程序服务器的一部分进行通信。
我注意到的一件事是，这些连接器是用于Apache（通常在Windows上的IIS）使用。 我们正在考虑从Apache移到更轻的networking服务器之一，比如Nginx或Cherokee。 如果我这样做，似乎我不会有像上面提到的使用连接器的选项。 这些服务器文档中的一致性build议是只configuration其HTTP反向代理function，以便将它们连接到应用服务器（通过应用服务器的HTTP实现）。
我感兴趣的是您对HTTP和其他协议中使用的协议的性能影响的经验，就像我上面提到的那样。 我认为那些其他连接器的function要低得多，因此性能更高。 他们显然可以带来新的“function”，如上面提到的暴露应用程序服务器的负载平衡function。
所以你怎么看？ HTTP和Web应用程序层之间进行通信的简单性和灵活性是否比更多定制连接器的附加function更具吸引力？ 在规划这样一个我没有考虑过的多层架构时，是否还有其他问题？
在大型网站中有很多HTTP 反向代理的例子 ，所以我认为它在性能，扩展性或易pipe理性方面没有问题。
添加nginx或相当于在当前服务器之前进行负载均衡的function不会有太大的改变，当它不再增加值时，你将能够逐渐取代apache + mod_whatever。
在你太过分之前，我不得不承认，我没有真正的数据来回答你的问题。 我已经做了一些相对较小的mod_proxy_http与mod_proxy_ajp的testing，但结果是不确定的。
我的理解是，mod_jk已被弃用mod_proxy_ajp; 也mod_jk（根据我的经验）更难以configuration。
前端Web服务器和应用程序服务器之间的mod_proxy_ajp和mod_jk通信的方式本质上是HTTP的二进制forms，对于Web服务器和应用程序服务器来说，发送和接收的速度理想上会更快。 为了实现负载均衡，mod_proxy系列使用了mod_proxy_balancer，它与mod_proxy_http或mod_proxy_ajp一起工作。 底线是两者之间没有特征差异。