Apache2.2 本身拥有如mod_proxy这样一系列优秀的模塊它们拥有一部分和mod_jk一样的功能（AJP Protocol），也能整合实现负载均衡

既然系统中的某个节点可能因为各种原因死掉，同application server 一样mod_proxy和mod_jk需要能够发現各种连接和通道的错误并作出反应。

mod_jk在过去几年就已经拥有了这样的技术优势现在有各种技术实现连接错误侦察和修复。从现在来看mod_jk在这方面比mod_proxy有更多的优势。

mod_jk是基于AJP协议的这个协议也通常被认为是二进制http协议。基于二进制协议主要考虑有两点，首先客户请求信息已经在web server被解码，就不用再把完整的请求数据发送给application server了；其次在web server 和 application server 之间，请求和返回 header信息不再是string形式而是两字节序列的原子形式，這样也就降低了网络带宽要求

但是，AJP协议有一个主要的限制就是packet的大小不能超过8K。最新的mod_jk和Tomcat使得这个限制可以加大到64K但是还是有限淛。mod_proxy也有限制最大的packet大小是8K.如果遇到较大的客户端请求就会出问题了，特别像有些客户SSO模块存储了大量的 session信息在cookies和header中如果在要支持大型客户端请求，唯一的解决方案是使用AJP http协议

AJP协议没有加密，不能够用在开放外部网络环境中在这样的环境中，web server和application server 直接的的通信可能会被***需要使用一定的SSL隧道技术保障数据安全。另外一个选择是使用https协议结合mod_proxy.但是https会稍微复杂一点需要在application

这样的性能更高效，因为数據只需进行一次解密但是使用不同的网卡进行通信、建设防火墙和路由才是保障web server和application server之间通信安全最好的解决方案。

另外有些观点认为將web server 和application server 放置在同一台物理机器上，他们直接通过内存进行通信这样可以加强整个系统的安全性。

最新的mod_jk比mod_proxy_balancer有更多的优势特性mod_jk额外拥有一些“商业特性”方法，可以根据实际 application server 反应时间设置负载均衡 mod_jk的“负责均衡维护”（load balancer maintenance）功能，能够有效的处理突发爆炸性的请求；当一个節点在维护的时候能够减少降低此间的的请求。这种情况需要大量的

server之前传送一些其他内容例如传送递静态内容等。在这种情况下時间发送到application server的请求比实际上web server接收到的客户端请求要少很多，它允许worker mpm的链接池大小设置比MaxThreadsPerChild更小

Windows和Netware版本的Apache httpd是完全线程的，所有他们的mpm和连接池大小可以设置处理更大的范围

那么什么时候使用哪一个呢？这依赖于你的架构如果你已经有了或者需要apache 2.2的功能，那么你可以再mod_proxy和mod_jk直接选择mod_jk在apache2.2上允许得很好。关键看你需要什么样的功能：

• 只有最基本的负载均衡器；

• 先进的节点失败侦察功能；
• 支持大型AJP 数据包
• 需要单独維护一个独立的模块；

我个人建议是如果有能力维护mod_jk模块的二进制版本尽量使用mod_jk。mod_proxy一直在更新但还缺少一些mod_jk的功能但是，如果你需要https囷一个简单的负载均衡就是用mod_proxy.