apache to tomcat: mod_jk vs mod_proxy

What are the advantages and disadvantages of using mod_jk and mod_proxy for fronting a tomcat instance with apache?

I've been using mod_jk in production for years but I've heard that it's "the old way" of fronting tomcat. Should I consider changing? Would there be any benefits?

Solution 1:

A pros/cons comparison for those modules exists on http://blog.jboss.org/

mod_proxy

* Pros:
      o No need for a separate module compilation and maintenance. mod_proxy,
        mod_proxy_http, mod_proxy_ajp and mod_proxy_balancer comes as part of 
        standard Apache 2.2+ distribution
      o Ability to use http https or AJP protocols, even within the same 
        balancer.
* Cons:
      o mod_proxy_ajp does not support large 8K+ packet sizes.
      o Basic load balancer
      o Does not support Domain model clustering

mod_jk

* Pros:
      o Advanced load balancer
      o Advanced node failure detection
      o Support for large AJP packet sizes
* Cons:
      o Need to build and maintain a separate module

Solution 2:

If you wish to stay in Apache land, you can also try the newer mod_proxy_ajp, which uses the AJP protocol to communicate with Tomcat instead of plain old HTTP, but which leverages mod_proxy to do the work.

Solution 3:

AJP vs HTTP

When using mod_jk, you are using the AJP. When using mod_proxy you will use HTTP or HTTPS. And this is essentially what makes all the difference.

The Apache JServ Protocol (AJP)

The Apache JServ Protocol (AJP) is a binary protocol that can proxy inbound requests from a web server through to an application server that sits behind the web server. AJP is a highly trusted protocol and should never be exposed to untrusted clients, which could use it to gain access to sensitive information or execute code on the application server.

Pros

• Easy to set up as the correct forwarding of HTTP headers is not required.
• It is less resource intensive because the TCP packets are forwarded in binary format instead of doing a costly HTTP exchange.

Cons

• Transferred data is not encrypted. It should only be used within trusted networks.

Hypertext Transfer Protocol (HTTP)

HTTP functions as a request–response protocol in the client–server computing model. A web browser, for example, may be the client and an application running on a computer hosting a website may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.

Pros

• Can be encrypted with SSL/TLS making it suitable for traffic across untrusted networks.
• It is flexible as it allows to modify the request before forwarding. For example, setting custom headers.

Cons

• More overhead as the correct forwarding of the HTTP headers has to be ensured.
• More resource intensive as the request is fully parsed before forwarding.