Ao longo dos anos, vários conectores foram desenvolvidos para permitir que o Apache httpd se comunique com o Tomcat, que usou diversos protocolos. Ao pesquisar na Web para obter informações sobre como fazer isso, não é incomum encontrar alguns conselhos realmente ruins e desatualizados. Então, primeiro de tudo, as únicas opções que você deve considerar para isso são:
- mod_jk
- mod_proxy_http
- mod_proxy_ajp
Todas as outras opções não são suportadas há vários anos, portanto você deve evitar mod_jk2, mod_jserv, mod_webapp e qualquer outro módulo que não seja discutido aqui. Existem três acima de tudo, atualmente são suportados e estão todos ativamente desenvolvidos.
Minha experiência em fornecer suporte a clientes em $ work é que atualmente um cliente típico não tem mais probabilidade de acertar um bug no mod_proxy_ajp do que em mod_jk ou mod_proxy_http. (Há alguns anos o mod_proxy_ajp não era tão maduro, mas hoje em dia não vejo nenhuma diferença.)
Isso nos leva à pergunta crunch: HTTP (mod_proxy_http) ou AJP (mod_proxy_ajp ou mod_jk)? E a resposta? Depende! Ambos os protocolos têm seus pontos strongs e fracos. Qual é o certo para você dependerá de suas circunstâncias. Os fatores que normalmente afetam essa escolha são:
- Um protocolo / módulo já está em uso?
- A comunicação entre o httpd e o Tomcat precisa ser criptografada?
- O httpd terminal SSL, mas as informações SSL, precisam ser transmitidas para o Tomcat?
Se você já estiver usando mod_jk, mod_proxy_http ou mod_proxy_ajp e atender a todos os seus requisitos, provavelmente não será um bom motivo para alterá-lo. Seria melhor manter o que você está usando atualmente e ter consistência nas instâncias do httpd.
Se você precisar criptografar a comunicação entre o httpd e o Tomcat, isso é significativamente mais fácil com o mod_proxy_http, já que você pode simplesmente mudar do http para o protocolo https. mod_jk e mod_proxy_ajp usam o protocolo AJP que não suporta criptografia, então você tem que implementar isso separadamente através de um túnel SSH, IPSec ou similar. Isso pode adicionar complexidade de configuração significativa ao canal de comunicação httpd-Tomcat.
Quando o httpd encerra o SSL, fornecendo os atributos SSL expostos (duas diretivas simples), mod_jk e mod_proxy_ajp transmitem automaticamente essas informações para o Tomcat e o Tomcat o disponibiliza para aplicativos da Web sem qualquer configuração adicional necessária. Para obter o mesmo resultado com o mod_proxy_http, é necessário que o httpd seja configurado para adicionar as informações do SSL como cabeçalhos http, e uma válvula precisa ser configurada no Tomcat para extrair essas informações e disponibilizá-las para os aplicativos da web. Tornar as informações SSL disponíveis para o Tomcat é, portanto, um pouco mais complicado com o mod_proxy_http.
mod_jk e mod_proxy_ * também possuem estilos de configuração muito diferentes. As diretivas mod_proxy_ * são consistentes com outras diretivas httpd, ao passo que mod_jk usa um arquivo de propriedades externo. Para administradores de sistema familiarizados com o httpd, a abordagem mod_jk pode parecer um pouco estranha.
Em resumo:
- Se você precisar criptografar o canal httpd para o Tomcat, use mod_proxy_http
- Se você precisar expor informações SSL ao seu aplicativo da web, use mod_jk ou mod_proxy_ajp
- Se você já estiver usando um desses módulos, a alteração provavelmente causará mais problemas do que salva
- Devido a uma escolha completamente livre, eu usaria mod_proxy_http apenas porque a configuração é mais consistente com outros módulos httpd, é ligeiramente mais fácil depurar com o Wireshark e pode usar seus conectores HTTP existentes no Tomcat.
Veja também uma apresentação que eu escrevi ( link ) e os comentários adicionais de Rainer Jung sobre essa apresentação ( link )