Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.