************************
The Apache Proxy Modules
So far, we have spoken loosely of mod_proxy. However, it's a little more complicated than that. In keeping with Apache's modular architecture, mod_proxy is itself modular, and a typical proxy server will need to enable several modules. Those relevant to proxying and this article include:
mod_proxy: The core module deals with proxy infrastructure and configuration and managing a proxy request.
mod_proxy_http: This handles fetching documents with HTTP and HTTPS.
mod_proxy_ftp: This handles fetching documents with FTP.
mod_proxy_connect: This handles the CONNECT method for secure (SSL) tunneling.
mod_proxy_ajp: This handles the AJP protocol for Tomcat and similar backend servers.
mod_proxy_balancer implements clustering and load-balancing over multiple backends.
mod_cache, mod_disk_cache, mod_mem_cache: These deal with managing a document cache. To enable caching requires mod_cache and one or both of disk_cache and mem_cache.
mod_proxy_html: This rewrites HTML links into a proxy's address space.
mod_xml2enc: This supports internationalisation (i18n) on behalf of mod_proxy_html and other markup-filtering modules. space.
mod_headers: This modifies HTTP request and response headers.
mod_deflate: Negotiates compression with clients and backends.
Having mentioned the modules, I'm going to ignore caching for the remainder of this article. You may want to add it if you are concerned about the load on your network or origin servers, but the details are outside the scope of this article. I'm also going to ignore all non-HTTP protocols, and load balancing.
**********************
We can configure Tomcat with Apache with number of connectors to communicate back and forth. Tomcat uses a variety of protocols. I would be writing down with the mostly used in production environment
mod_proxy_http
mod_proxy_ajp
mod_jk
All above module are good and of Production use, the only thing is that how you are using your current architecture. I found mod_jk and mod_proxy_http above mod_proxy_ajp.
To decide what we are going to use, we need to answer some questions like,
Do we want encrypted communication between apache and tomcat
Does ssl need to terminate on apache and then communication between apache and tomcat is without ssl
If you are using mod_jk or mod_proxy_http and it meets all of your requirements then there is no good reason to change it.
If you need to encrypt the communication between apache and Tomcat then this is significantly easier with mod_proxy_http when you can just switch from the http to the https protocol.
Where apache terminates the SSL, providing the SSL attributes are exposed (two simple directives) then mod_jk automatically passes this information to Tomcat and Tomcat makes it available to web applications without any additional configuration required. To achieve the same result with mod_proxy_http requires apache to be configured to add the SSL information as http headers and a Valve needs to be configured in Tomcat to extract this information and to make it available to web applications. Making SSL information available to Tomcat is therefore a little more complicated with mod_proxy_http.
mod_jk and mod_proxy_http also have very different configuration styles. The mod_proxy_http directives are consistent with other apache directives whereas mod_jk uses an external property file.
Pros and Cons:
mod_proxy
Pros:
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
Ability to use http https or AJP protocols, even within the same
balancer.
Cons:
mod_proxy_ajp does not support large 8K+ packet sizes.
Basic load balancer
Does not support Domain model clustering
mod_jk
Pros:
Advanced load balancer
Advanced node failure detection
Support for large AJP packet sizes
Cons:
o Need to build and maintain a separate module
My Thought:
If you need to encrypt the apache to Tomcat channel, use mod_proxy_http
If you need to expose SSL information to your web application, use mod_jk
References: http://www.tomcatexpert.com/blog/2010/06/16/deciding-between-modjk-modproxyhttp-and-modproxyajp
The Apache Proxy Modules
So far, we have spoken loosely of mod_proxy. However, it's a little more complicated than that. In keeping with Apache's modular architecture, mod_proxy is itself modular, and a typical proxy server will need to enable several modules. Those relevant to proxying and this article include:
mod_proxy: The core module deals with proxy infrastructure and configuration and managing a proxy request.
mod_proxy_http: This handles fetching documents with HTTP and HTTPS.
mod_proxy_ftp: This handles fetching documents with FTP.
mod_proxy_connect: This handles the CONNECT method for secure (SSL) tunneling.
mod_proxy_ajp: This handles the AJP protocol for Tomcat and similar backend servers.
mod_proxy_balancer implements clustering and load-balancing over multiple backends.
mod_cache, mod_disk_cache, mod_mem_cache: These deal with managing a document cache. To enable caching requires mod_cache and one or both of disk_cache and mem_cache.
mod_proxy_html: This rewrites HTML links into a proxy's address space.
mod_xml2enc: This supports internationalisation (i18n) on behalf of mod_proxy_html and other markup-filtering modules. space.
mod_headers: This modifies HTTP request and response headers.
mod_deflate: Negotiates compression with clients and backends.
Having mentioned the modules, I'm going to ignore caching for the remainder of this article. You may want to add it if you are concerned about the load on your network or origin servers, but the details are outside the scope of this article. I'm also going to ignore all non-HTTP protocols, and load balancing.
**********************
We can configure Tomcat with Apache with number of connectors to communicate back and forth. Tomcat uses a variety of protocols. I would be writing down with the mostly used in production environment
mod_proxy_http
mod_proxy_ajp
mod_jk
All above module are good and of Production use, the only thing is that how you are using your current architecture. I found mod_jk and mod_proxy_http above mod_proxy_ajp.
To decide what we are going to use, we need to answer some questions like,
Do we want encrypted communication between apache and tomcat
Does ssl need to terminate on apache and then communication between apache and tomcat is without ssl
If you are using mod_jk or mod_proxy_http and it meets all of your requirements then there is no good reason to change it.
If you need to encrypt the communication between apache and Tomcat then this is significantly easier with mod_proxy_http when you can just switch from the http to the https protocol.
Where apache terminates the SSL, providing the SSL attributes are exposed (two simple directives) then mod_jk automatically passes this information to Tomcat and Tomcat makes it available to web applications without any additional configuration required. To achieve the same result with mod_proxy_http requires apache to be configured to add the SSL information as http headers and a Valve needs to be configured in Tomcat to extract this information and to make it available to web applications. Making SSL information available to Tomcat is therefore a little more complicated with mod_proxy_http.
mod_jk and mod_proxy_http also have very different configuration styles. The mod_proxy_http directives are consistent with other apache directives whereas mod_jk uses an external property file.
Pros and Cons:
mod_proxy
Pros:
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
Ability to use http https or AJP protocols, even within the same
balancer.
Cons:
mod_proxy_ajp does not support large 8K+ packet sizes.
Basic load balancer
Does not support Domain model clustering
mod_jk
Pros:
Advanced load balancer
Advanced node failure detection
Support for large AJP packet sizes
Cons:
o Need to build and maintain a separate module
My Thought:
If you need to encrypt the apache to Tomcat channel, use mod_proxy_http
If you need to expose SSL information to your web application, use mod_jk
References: http://www.tomcatexpert.com/blog/2010/06/16/deciding-between-modjk-modproxyhttp-and-modproxyajp
No comments:
Post a Comment