mod_jk ou mod_proxy

Question

Eu tentei googling e os únicos artigos que encontrei comparando esses dois foram de 2005 até 2002. Eu configurei minha primeira instância do Tomcat para executar o Jira para um projeto que estou fazendo. Eu quero proxy isso através da porta 80 e apache. Pelo que posso dizer, posso facilmente encaminhar o tráfego usando o mod_proxy. Qual a diferença com o uso do mod_jk? Há alguma diferença de desempenho / segurança entre esses dois mods? Alguém tem alguma dica / experiência configurando o encaminhamento através do apache? Estou executando o debian Lenny.

    

Answer 1

O JIRA não suporta oficialmente colocar o tomcat atrás do apache, a menos que você use mod_proxy_http . A configuração recomendada é algo como isto

/etc/httpd/vhosts.d/jira.company.com.conf

...
ProxyPreserveHost On
<Location />
   ProxyPass http://localhost:8080/
</Location>
...

/opt/j2ee/domains/company.com/jira/tomcat/conf/server.xml

...
<Connector address="localhost" port="8080" URIEncoding="UTF-8"
   maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
   enableLookups="false" redirectPort="8443" acceptCount="100"
   debug="0" connectionTimeout="20000"
   proxyName="jira.company.com" proxyPort="80"
   disableUploadTimeout="true" /> 
...

Isso deve ser usado em http , deixe-me saber se você quer um exemplo para https

disclaimer: Atualmente sou funcionário da Atlassian, embora não trabalhe na equipe do JIRA

    

Answer 2

Ambos os métodos encaminham solicitações do apache para o tomcat. mod_proxy usa o HTTP que todos nós conhecemos um amor. mod_jk usa um protocolo binário AJP. As principais vantagens do mod_jk são:

• O AJP é um protocolo binário, portanto é um pouco mais rápido para os dois lados e usa um pouco menos de sobrecarga comparado ao HTTP, mas isso é mínimo.
• O AJP inclui informações como o nome do host original, o host remoto e a conexão SSL. Isso significa que ServletRequest.isSecure () funciona como esperado e que você sabe quem está se conectando a você e permite que você faça algum tipo de virtualhosting em seu código.

Uma pequena desvantagem é que o AJP é baseado em blocos de tamanho fixo e pode quebrar com cabeçalhos longos, particularmente URLs de solicitação com uma longa lista de parâmetros, mas você raramente deve estar em posição de ter 8K de parâmetros de URL. (Isso sugere que você estava fazendo errado. :))

A posição é um pouco complicada pela existência de mod_proxy_ajp. Entre eles, mod_jk é o mais maduro dos dois, mas mod_proxy_ajp funciona no mesmo framework que os outros módulos mod_proxy. Eu ainda não usei mod_proxy_ajp, mas consideraria fazer isso no futuro, já que mod_jk envolve configuração fora do Apache.

Dado uma escolha, eu preferiria um conector baseado em AJP, principalmente devido à minha segunda vantagem declarada, mais do que o aspecto de desempenho. Claro, se o Atlassian não suportar nada além de mod_proxy_http, isso amarra suas mãos um pouco, mas o mod_jk funciona com o JIRA.

    

Answer 3

Sim, há alguma diferença. No entanto, o que você escolher usar dependerá do seu aplicativo.

Como exemplo, o mod_proxy funcionará como um proxy reverso normal, que encaminhará apenas cabeçalhos regulares enquanto mod_jk funcionaria como um conector especial que encaminha não apenas cabeçalhos regulares mas também algumas outras variáveis de ambiente. Um símile pode ser desenhado para conectores scgi e fastcgi .

Para o propósito de trabalhar com JSP, você deve usar o mod_jk para o qual foi projetado. Use somente mod_proxy ao encaminhar apenas para servidores web regulares (isso pode lançar outros conectores ajp por trás deles).

[front apache]---proxy---[back apache]---ajp---[tomcat]
       |
       +--------- ajp----[tomcat]

Espero que isso ajude.

    

Answer 4

mod_proxy irá "mandar" todos os pedidos para o tomcat usando os conectores http normais.

mod_jk abre as conexões "ajp13" para o servidor tomcat, que são separadas dos conectores normais tomcat http e passam o tráfego dessa maneira.