Apache vs Nginx: Considerações Práticas

Postado em 28 de janeiro de 2015 Vista 731.1k APACHE NGINX CONCEPTUAL

Introdução
Apache e Nginx são os dois servidores web de código aberto mais comuns do
mundo. Juntos, eles são responsáveis por atender mais de 50% do tráfego na
internet. Ambas as soluções são capazes de lidar com diversas cargas de trabalho e
trabalhar com outros softwares para fornecer uma pilha completa de web.

Enquanto o Apache e o Nginx compartilham muitas qualidades, eles não devem ser
considerados inteiramente intercambiáveis. Cada um deles se destaca a sua
maneira e é importante compreender as situações em que talvez seja necessário
reavaliar seu servidor web de escolha. Este artigo será dedicado a uma discussão
de como cada servidor apaga em várias áreas.

Visão geral
Antes de mergulhar nas diferenças entre o Apache e o Nginx, vamos dar uma
olhada no fundo desses dois projetos e suas características gerais.
 Apache
O Servidor HTTP Apache foi criado por Robert McCool em 1995 e foi desenvolvido
sob a direção da Apache Software Foundation desde 1999. Como o servidor web
HTTP é o projeto original da fundação e é, de longe, o seu software mais popular,
muitas vezes referido simplesmente como "Apache".

O servidor web Apache foi o servidor mais popular na internet desde 1996. Por
causa desta popularidade, o Apache beneficia de ótima documentação e suporte
integrado de outros projetos de software.

O Apache é muitas vezes escolhido pelos administradores por sua flexibilidade,

poder e suporte generalizado. É extensível através de um sistema de módulo
carregável dinamicamente e pode processar um grande número de idiomas
interpretados sem conectar-se a software separado.

Nginx
Em 2002, a Igor Sysoev começou a trabalhar com o Nginx como resposta ao
problema do C10K, que foi um desafio para os servidores da Web começar a lidar
com dez mil conexões simultâneas como requisito para a web moderna. O
lançamento público inicial foi feito em 2004, cumprindo esse objetivo, confiando em
uma arquitetura assíncrona, baseada em eventos.

A Nginx cresceu em popularidade desde o seu lançamento devido à sua utilização

leve dos recursos e sua capacidade de se dimensionar facilmente em hardware
mínimo. O Nginx se destaca em fornecer conteúdo estático rapidamente e é
projetado para transferir pedidos dinâmicos para outro software que seja mais
adequado para essas finalidades.

Nginx é frequentemente selecionado pelos administradores quanto à eficiência e

capacidade de resposta dos recursos sob carga. Os advogados recebem o foco da
Nginx nos principais recursos do servidor web e do proxy.

Arquitetura de manipulação de conexão

Uma grande diferença entre o Apache e o Nginx é a maneira real de lidar com
conexões e tráfego. Isso proporciona talvez a diferença mais significativa na forma
como eles respondem a diferentes condições de tráfego.

Apache
O Apache fornece uma variedade de módulos de processamento múltiplo (Apache
chama esses MPMs) que determinam como os pedidos do cliente são tratados.
Basicamente, isso permite que os administradores troquem facilmente sua
arquitetura de gerenciamento de conexões. Esses são:
• mpm_prefork: este módulo de processamento engloba processos com um único
segmento cada um para lidar com o pedido. Cada criança pode lidar com uma única
conexão por vez. Enquanto o número de pedidos for inferior ao número de
processos, este MPM é muito rápido. No entanto, o desempenho se degrada
rapidamente após os pedidos superarem o número de processos, portanto, esta não
é uma boa escolha em muitos cenários. Cada processo tem um impacto
significativo no consumo de RAM, portanto, este MPM é difícil de dimensionar de
forma eficaz. Isso ainda pode ser uma boa opção, embora seja usado em conjunto
com outros componentes que não são construídos com threads em mente. Por
exemplo, o PHP não é seguro por thread, então este MPM é recomendado como a
única maneira segura de trabalhar com mod_php , o módulo Apache para o
processamento desses arquivos.
• mpm_worker: este módulo engloba processos que cada um pode gerenciar vários
tópicos. Cada um desses tópicos pode lidar com uma única conexão. Os tópicos são
muito mais eficientes do que os processos, o que significa que este MPM escala
melhor do que o MPM prefork. Uma vez que existem mais threads do que processos,
isso também significa que novas conexões podem ter um fio livre imediatamente,
em vez de ter que esperar por um processo gratuito.
• mpm_event: Este módulo é semelhante ao módulo do trabalhador na maioria das
situações, mas é otimizado para lidar com as conexões keep-alive. Ao usar o MPM
do trabalhador, uma conexão manterá um segmento, independentemente de uma
solicitação estar ativamente feita, desde que a conexão seja mantida viva. O evento
MPM lida com conexões válidas ao reservar threads dedicados para lidar com
manter conexões vivas e transferir pedidos ativos para outros tópicos. Isso evita
que o módulo fique atolado por solicitações keep-alive, permitindo uma execução
mais rápida. Isso foi marcado como estável com o lançamento do Apache 2.4.
Como você pode ver, o Apache fornece uma arquitetura flexível para escolher
diferentes algoritmos de conexão e gerenciamento de solicitação. As escolhas
oferecidas são principalmente uma função da evolução do servidor e a crescente
necessidade de concorrência à medida que a paisagem da internet mudou.

Nginx
Nginx entrou em cena após o Apache, com mais consciência dos problemas de
concorrência que enfrentarão sites à escala. Aproveitando esse conhecimento, o
Nginx foi projetado desde o início para usar um algoritmo de manipulação de
conexão assíncrona, não bloqueável e com base em eventos.

O Nginx gera processos de trabalho, cada um dos quais pode lidar com milhares de
conexões. Os processos de trabalho realizam isso implementando um mecanismo
de loop rápido que verifica continuamente e processa eventos. Desacoplar o
trabalho real das conexões permite que cada trabalhador se preocupe com uma
conexão somente quando um novo evento foi disparado.

Cada uma das conexões manipuladas pelo trabalhador são colocadas dentro do
loop de eventos onde elas existem com outras conexões. Dentro do ciclo, os
eventos são processados de forma assíncrona, permitindo que o trabalho seja
manipulado de forma não bloqueadora. Quando a conexão é fechada, ela é
removida do loop.

Esse estilo de processamento de conexão permite que o Nginx escala incrivelmente

longe com recursos limitados. Uma vez que o servidor é de um único thread e os
processos não são gerados para lidar com cada nova conexão, a memória e o uso
da CPU tendem a permanecer relativamente consistentes, mesmo em tempos de
carga pesada.

Conteúdo estático vs dinâmico

Em termos de casos de uso do mundo real, uma das comparações mais comuns
entre o Apache e o Nginx é a maneira pela qual cada servidor lida com pedidos de
conteúdo estático e dinâmico.

Apache
Os servidores Apache podem lidar com conteúdo estático usando seus métodos
convencionais baseados em arquivos. O desempenho dessas operações é
principalmente uma função dos métodos MPM descritos acima.

O Apache também pode processar conteúdo dinâmico incorporando um

processador do idioma em questão em cada uma de suas instâncias de trabalho.
Isso permite que ele execute conteúdo dinâmico dentro do próprio servidor web
sem ter que confiar em componentes externos. Esses processadores dinâmicos
podem ser habilitados através do uso de módulos dinamicamente carregáveis.

A capacidade da Apache de lidar com conteúdo dinâmico internamente significa

que a configuração de processamento dinâmico tende a ser mais simples. A
comunicação não precisa ser coordenada com uma peça adicional de software e os
módulos podem ser facilmente trocados se os requisitos de conteúdo mudarem.

Nginx
O Nginx não possui capacidade para processar conteúdo dinâmico nativamente.
Para lidar com PHP e outros pedidos de conteúdo dinâmico, o Nginx deve passar
para um processador externo para execução e aguardar o retorno do conteúdo
renderizado. Os resultados podem então ser retransmitidos para o cliente.

Para os administradores, isso significa que a comunicação deve ser configurada

entre Nginx e o processador em um dos protocolos. Nginx sabe falar (http, FastCGI,
SCGI, uWSGI, memcache). Isso pode complicar as coisas ligeiramente,
especialmente quando se tenta antecipar o número de conexões a permitir, como
uma conexão adicional será usada para cada chamada para o processador.
No entanto, esse método também possui algumas vantagens. Uma vez que o
intérprete dinâmico não está incorporado no processo de trabalho, sua sobrecarga
somente estará presente para conteúdo dinâmico. O conteúdo estático pode ser
servido de forma direta e o intérprete só será contatado quando necessário. O
Apache também pode funcionar desta maneira, mas, assim, remove os benefícios
na seção anterior.

Configuração Distribuída versus Centralizada

Para os administradores, uma das diferenças mais facilmente aparentes entre esses
dois pedaços de software é se a configuração do nível de diretório é permitida
dentro dos diretórios de conteúdo.

Apache
O Apache inclui uma opção para permitir a configuração adicional por diretório por
inspeção e interpretação de diretrizes em arquivos ocultos dentro dos próprios
diretórios de conteúdo. Esses arquivos são conhecidos como arquivos .htaccess .

Uma vez que esses arquivos residem dentro dos próprios diretórios de conteúdo, ao
lidar com um pedido, o Apache verifica cada componente do caminho para o
arquivo solicitado para um arquivo .htaccess e aplica as diretrizes encontradas
dentro. Isso efetivamente permite a configuração descentralizada do servidor web,
que é frequentemente usado para implementar reescritos de URL, restrições de
acesso, autorização e autenticação, até mesmo políticas de cache.

Enquanto os exemplos acima podem ser configurados no arquivo de configuração

principal do Apache, os arquivos .htaccess têm algumas vantagens importantes.
Primeiro, uma vez que estes são interpretados cada vez que são encontrados ao
longo de um caminho de solicitação, eles são implementados imediatamente sem
recarregar o servidor. Em segundo lugar, permite permitir que usuários não
privilegiados controlem certos aspectos de seu próprio conteúdo da web sem lhes
dar controle sobre todo o arquivo de configuração.

Isso fornece uma maneira fácil para certos softwares da Web, como sistemas de
gerenciamento de conteúdo, para configurar seu ambiente sem fornecer acesso ao
arquivo de configuração central. Isso também é usado por provedores de
hospedagem compartilhada para manter o controle da configuração principal, ao
mesmo tempo em que os clientes controlam seus diretórios específicos.

Nginx
O Nginx não interpreta os arquivos .htaccess nem fornece nenhum mecanismo para
avaliar a configuração por diretório fora do arquivo de configuração principal. Isso
pode ser menos flexível do que o modelo Apache, mas tem suas próprias
vantagens.
A melhoria mais notável em relação ao sistema .htaccess de configuração de nível
de diretório é um desempenho aumentado. Para uma configuração Apache típica
que pode permitir .htaccess em qualquer diretório, o servidor verificará esses
arquivos em cada um dos diretórios principais que levem ao arquivo solicitado, para
cada solicitação. Se um ou mais arquivos .htaccess forem encontrados durante essa
pesquisa, eles devem ser lidos e interpretados. Ao não permitir anulações de
diretório, o Nginx pode atender solicitações mais rapidamente fazendo uma única
pesquisa de diretório e arquivo lido para cada solicitação (assumindo que o arquivo
é encontrado na estrutura de diretório convencional).

Outra vantagem é relacionada à segurança. A distribuição do acesso à configuração

do nível do diretório também distribui a responsabilidade da segurança para
usuários individuais, que talvez não sejam confiáveis para lidar com esta tarefa.
Garantir que o administrador mantenha o controle sobre todo o servidor da Web
pode evitar alguns erros de segurança que podem ocorrer quando o acesso é dado
a outras partes.

Tenha em mente que é possível desativar .htaccess interpretação no Apache se

essas preocupações ressoam com você.

Interpretação baseada em arquivo versus URI

Como o servidor web interpreta pedidos e os mapeia para recursos reais no sistema
é outra área em que esses dois servidores diferem.

Apache
O Apache fornece a capacidade de interpretar uma solicitação como um recurso
físico no sistema de arquivos ou como uma localização URI que pode precisar de
uma avaliação mais abstrata. Em geral, para o antigo Apache usa blocos
<Directory> ou <Files> , enquanto utiliza blocos <Location> para recursos mais
abstratos.

Como o Apache foi projetado desde o início como um servidor web, o padrão
geralmente é interpretar pedidos como recursos do sistema de arquivos. Começa
tomando a raiz do documento e anexando a parte da solicitação seguindo o número
do host e da porta para tentar encontrar um arquivo real. Basicamente, a hierarquia
do sistema de arquivos é representada na web como a árvore de documentos
disponíveis.

O Apache fornece uma série de alternativas para quando a solicitação não

corresponde ao sistema de arquivos subjacente. Por exemplo, uma diretiva Alias
pode ser usada para mapear para um local alternativo. O uso dos blocos <Location>
é um método de trabalho com o URI em vez do sistema de arquivos. Existem
também variantes de expressão regulares que podem ser usadas para aplicar a
configuração de forma mais flexível em todo o sistema de arquivos.
Embora o Apache tenha a capacidade de operar tanto no sistema de arquivos
subjacente quanto no espaço web, ele se encaixa fortemente em métodos de
sistema de arquivos. Isso pode ser visto em algumas das decisões de design,
incluindo o uso de arquivos .htaccess para configuração por diretório. O Apache
dedica-se a avisar contra o uso de blocos baseados em URI para restringir o acesso
quando o pedido espelha o sistema de arquivos subjacente.

Nginx
Nginx foi criado para ser um servidor web e um servidor proxy. Devido à arquitetura
necessária para essas duas funções, ela funciona principalmente com URIs,
traduzindo para o sistema de arquivos quando necessário.

Isso pode ser visto em algumas das formas em que os arquivos de configuração
Nginx são construídos e interpretados. O Nginx não fornece um mecanismo para
especificar a configuração de um diretório do sistema de arquivos e, em vez disso,
analisa o próprio URI.

Por exemplo, os blocos de configuração primários para Nginx são blocos de server e
location . O bloco do server interpreta o host que está sendo solicitado, enquanto os
blocos de location são responsáveis por partes correspondentes do URI que vem
após o host e a porta. Neste ponto, o pedido está sendo interpretado como URI, não
como um local no sistema de arquivos.

Para arquivos estáticos, todos os pedidos eventualmente precisam ser mapeados

para um local no sistema de arquivos. Primeiro, o Nginx seleciona os blocos de
servidor e localização que irão lidar com a solicitação e, em seguida, combinará a
raiz do documento com o URI, adaptando qualquer coisa necessária de acordo com
a configuração especificada.

Isso pode parecer semelhante, mas os pedidos de análise principalmente como URIs
em vez de locais de sistema de arquivos permitem que o Nginx funcione mais
facilmente nas funções de servidor da Web, do correio e do proxy. O Nginx é
configurado simplesmente definindo como responder a diferentes padrões de
solicitação. O Nginx não verifica o sistema de arquivos até que esteja pronto para
atender a solicitação, o que explica por que ele não implementa uma forma de
arquivos .htaccess .

Módulos
Tanto o Nginx quanto o Apache são extensíveis através de sistemas de módulos,
mas a maneira como funcionam diferem significativamente.
 Apache
O sistema de módulos do Apache permite que você carregue ou descarregue
módulos dinamicamente para satisfazer suas necessidades durante o
funcionamento do servidor. O núcleo do Apache está sempre presente, enquanto os
módulos podem ser ativados ou desativados, adicionando ou removendo
funcionalidades adicionais e conectando-se ao servidor principal.

O Apache usa essa funcionalidade para tarefas de grande variedade. Devido à

maturidade da plataforma, existe uma vasta biblioteca de módulos disponíveis.
Estes podem ser usados para alterar algumas das funcionalidades principais do
servidor, como mod_php , que incorpora um intérprete PHP em cada funcionário em
execução.

Os módulos não se limitam ao processamento de conteúdo dinâmico, no entanto.

Entre outras funções, eles podem ser usados para reescrever URLs, autenticar
clientes, endurecer o servidor, registrar, armazenar em cache, compactar, proxying,
limitar taxas e criptografar. Os módulos dinâmicos podem prolongar
consideravelmente a funcionalidade do núcleo sem muito trabalho adicional.

Nginx
O Nginx também implementa um sistema de módulos, mas é bastante diferente do
sistema Apache. No Nginx, os módulos não são carregáveis dinamicamente,
portanto, eles devem ser selecionados e compilados no software principal.

Para muitos usuários, isso tornará o Nginx muito menos flexível. Isto é
especialmente verdadeiro para os usuários que não estão confortáveis mantendo
seus próprios softwares compilados fora do sistema de embalagem convencional de
sua distribuição. Enquanto os pacotes das distribuições tendem a incluir os módulos
mais utilizados, se você precisar de um módulo não padrão, você terá que criar o
servidor a partir da fonte.

Os módulos Nginx ainda são muito úteis, e eles permitem que você dite o que
deseja do seu servidor, incluindo apenas a funcionalidade que você pretende usar.
Alguns usuários também podem considerar isso mais seguro, pois os componentes
arbitrários não podem ser conectados ao servidor. No entanto, se seu servidor
estiver em uma posição em que isso seja possível, provavelmente já está
comprometido.

Os módulos Nginx permitem muitas das mesmas capacidades que os módulos

Apache. Por exemplo, os módulos Nginx podem fornecer suporte de proxy,
compressão, limitação de taxa, registro, reescrita, geolocalização, autenticação,
criptografia, transmissão e funcionalidade de correio.
 Suporte, Compatibilidade, Ecossistema e
Documentação
Um ponto importante a considerar é o que o processo real de iniciar e executar terá
a paisagem de ajuda disponível e suporte entre outros softwares.

Apache
Como o Apache tem sido popular há tanto tempo, o suporte para o servidor é
bastante onipresente. Existe uma grande biblioteca de documentação de primeira e
terceirização disponível para o servidor central e para cenários baseados em tarefas
envolvendo ligar o Apache com outro software.

Junto com a documentação, muitas ferramentas e projetos da Web incluem

ferramentas para inicializar-se dentro de um ambiente Apache. Isso pode ser
incluído nos próprios projetos, ou nos pacotes mantidos pela equipe de embalagem
da sua distribuição.

O Apache, em geral, terá mais suporte de projetos de terceiros simplesmente por

causa de sua participação no mercado e do tempo que ele está disponível. Os
administradores também são um pouco mais propensos a ter experiência
trabalhando com o Apache não só devido à sua prevalência, mas também porque
muitas pessoas começam em cenários de hospedagem compartilhada que
dependem quase exclusivamente do Apache devido aos recursos de gerenciamento
distribuídos .htaccess .

Nginx
O Nginx está experimentando um maior suporte à medida que mais usuários
adotam o seu perfil de desempenho, mas ainda há algumas tentativas de fazer em
algumas áreas-chave.

No passado, era difícil encontrar documentação abrangente em inglês sobre o

Nginx devido ao fato de que a maioria dos primeiros desenvolvimentos e
documentação estavam em russo. À medida que o interesse no projeto cresceu, a
documentação foi preenchida e agora há muitos recursos de administração no site
Nginx e através de terceiros.

No que diz respeito aos aplicativos de terceiros, o suporte e a documentação estão

se tornando cada vez mais disponíveis, e os mantenedores do pacote estão
começando, em alguns casos, a dar escolhas entre a configuração automática para
o Apache e o Nginx. Mesmo sem suporte, a configuração do Nginx para trabalhar
com software alternativo geralmente é direta, desde que o próprio projeto
documente seus requisitos (permissões, cabeçalhos, etc.).
 Usando o Apache e Nginx Juntos
Depois de superar os benefícios e limitações do Apache e do Nginx, você pode ter
uma ideia melhor de qual servidor é mais adequado às suas necessidades. No
entanto, muitos usuários acham que é possível aproveitar os pontos fortes de cada
servidor usando-os juntos.

A configuração convencional para esta parceria é colocar o Nginx na frente do

Apache como um proxy reverso. Isso permitirá que o Nginx atenda todos os pedidos
de clientes. Isso aproveita a velocidade de processamento rápido da Nginx e a
capacidade de lidar com um grande número de conexões simultaneamente.

Para o conteúdo estático, no qual o Nginx se destaca, os arquivos serão atendidos

rapidamente e diretamente para o cliente. Para o conteúdo dinâmico, por exemplo,
arquivos PHP, o Nginx irá solicitar a Apache, que pode processar os resultados e
retornar a página renderizada. Nginx pode então passar o conteúdo de volta para o
cliente.

Esta configuração funciona bem para muitas pessoas porque permite que o Nginx
funcione como uma máquina de classificação. Ele irá lidar com todos os pedidos
que pode e transmitir sobre aqueles que não tem capacidade nativa para servir. Ao
reduzir as solicitações, o servidor Apache é solicitado a lidar, podemos aliviar alguns
dos bloqueios que ocorrem quando um processo ou thread Apache está ocupado.

Esta configuração também permite escalar, adicionando servidores backend

adicionais, conforme necessário. O Nginx pode ser configurado para passar
facilmente a um conjunto de servidores, aumentando a capacidade de resiliência
desta configuração para falhas e desempenho.

Conclusão
Como você pode ver, o Apache e o Nginx são poderosos, flexíveis e capazes. Decidir
qual servidor é melhor para você é em grande parte uma função de avaliar seus
requisitos específicos e testes com os padrões que você espera ver.

Existem diferenças entre esses projetos que têm um impacto muito real sobre o
desempenho bruto, as capacidades e o tempo de implementação necessários para
que cada solução seja executada. No entanto, estes geralmente são o resultado de
uma série de trade offs que não devem ser desprezados casualmente. No final, não
há um servidor web de tamanho único, então use a solução que melhor se alinha
com seus objetivos.