NGINX vs. Apache: Como Escolher o Melhor Servidor Web NGINX vs. Apache: Como Escolher o Melhor Servidor Web

Imagine isso: você está procurando tênis novos, encontra uma boa oferta e decide conferir no site.

Você espera por 10 segundos… 20 segundos… e o site simplesmente não carrega. Você cansa de esperar e vai para outro site. Veja o que provavelmente aconteceu: o site de tênis provavelmente gastou muito tempo e dinheiro em imagens chamativas e designs elegantes, mas tudo isso é em vão se demorar uma eternidade para carregar.

A internet está cheia de sites lentos.

A página de destino móvel média leva 22 segundos para carregar, e isso é péssimo para os negócios.

Um estudo da Portent descobriu que um site que carrega em menos de um segundo tem uma taxa de conversão três vezes maior do que um site que leva cinco segundos para carregar.

Agora, o que isso tem a ver com nossa comparação entre NGINX e Apache?

Um fator importante que afeta a velocidade do site é o seu servidor web — o software que entrega suas páginas aos visitantes.

Apache e NGINX são dois dos servidores web mais proeminentes que existem.

Em julho de 2024, a w3techs relata que o NGINX alimenta mais de 34% dos sites, enquanto o Apache suporta 29,4%.

Isso faz do NGINX o vencedor claro? Ainda não.

Ambos os servidores web funcionam de maneira diferente para diferentes casos de uso. Neste guia, vamos dar uma olhada nas diferenças entre Apache e NGINX e explicar o que procurar ao escolher um servidor.

Comece Agora.

O que são Servidores Web?

Os servidores web são aplicações de software que funcionam em um servidor físico e lidam com as solicitações de usuários.

Quando você digita uma URL como “google.com”, seu navegador envia uma solicitação ao servidor web, que armazena os arquivos necessários para executar o site.

O servidor então envia de volta o conteúdo apropriado, seja HTML, CSS, JavaScript, imagens ou outro tipo.

Os servidores web lidam com muitas tarefas importantes nos bastidores:

• Gerenciando conexões e requisições HTTP
• Encaminhando requisições para a aplicação backend correta se necessário (como PHP, Python ou Ruby on Rails)
• Lendo e escrevendo arquivos do disco para servir ativos estáticos
• Aplicando políticas de segurança
• Comprimindo conteúdo para transmissão mais rápida
• Registrando requisições para análise

Agora que cobrimos como os servidores web funcionam, vamos ver como o NGINX e o Apache abordam essas tarefas.

O que é Apache?

O servidor HTTP Apache, comumente chamado de Apache, é um popular software de servidor web de código aberto criado por Robert McCool e lançado em 1995. É baseado no servidor HTTPd da NCSA.

A Apache Software Foundation, uma organização sem fins lucrativos que apoia projetos de software de código aberto, desenvolveu e continua a mantê-lo.

Por muitos anos, o Apache foi o servidor web mais utilizado no mundo, alimentando muitos sites. De fato, ele teve um papel significativo no crescimento da World Wide Web em seus primeiros dias.

Algumas das principais funcionalidades e benefícios do Apache são:

• Arquitetura modular: Sua funcionalidade pode ser estendida por meio de módulos para diferentes recursos e idiomas.
• Funciona em vários sistemas operacionais: Apache é construído para ser multiplataforma para hospedar seu servidor web em qualquer sistema operacional, incluindo Linux, Windows e macOS.
• Documentação extensa e uma grande comunidade: Ajuda usuários e desenvolvedores a resolver problemas e desenvolver melhores soluções enquanto trabalham juntos.
• Configuração flexível: Os arquivos .htaccess podem facilitar mudanças de configuração específicas para diretórios para os usuários.
• Recursos de segurança: Apache possui uma boa segurança devido à sua natureza de código aberto e atualizações regulares para corrigir vulnerabilidades e bugs.

Dito isso, o Apache tem algumas limitações:

• Maior uso de memória: Utiliza mais memória do que o NGINX, especialmente ao lidar com várias conexões simultâneas.
• Mais lento sob cargas pesadas: Pode ser mais lento do que o NGINX ao servir arquivos estáticos, especialmente sob cargas pesadas.
• Desafiador para desenvolvedores desenvolverem e manterem: Ao longo dos anos, a crescente complexidade de sua base de código tornou mais desafiador construir e manter.

O que é NGINX?

O NGINX (pronunciado “Engine X”) é um software de servidor web gratuito, de código aberto e de alto desempenho, lançado pela primeira vez em 2004. Foi criado por Igor Sysoev, um engenheiro de software russo, para resolver o problema de lidar com muitos usuários acessando um site simultaneamente, o que era um desafio para outros servidores web como o Apache.

O trabalho de Sysoev no NGINX começou em 2002. Ele tinha como objetivo resolver o “problema C10k” — lidar com 10.000 conexões simultâneas.

Sua visão era de um servidor rápido, estável e escalável. Esse foco em desempenho faz com que o NGINX seja excepcionalmente bom na entrega de conteúdo estático, como páginas HTML, imagens e arquivos CSS.

Além de sua velocidade, o NGINX se destaca como um proxy reverso. Ele recebe solicitações dos usuários e as encaminha inteligentemente para outros servidores, como o Apache ou aplicações web, otimizando a utilização dos recursos.

Algumas das principais vantagens do NGINX são:

• Tratamento concorrente: NGINX lida com muitos usuários simultaneamente sem exigir memória excessiva ou poder de CPU.
• Fácil de configurar: NGINX possui um formato de arquivo de configuração simples e intuitivo que ajuda os usuários a configurar facilmente o servidor web de acordo com seu caso de uso.
• Várias funcionalidades de desempenho: NGINX possui muitos recursos embutidos para balanceamento de carga, Cache, e segurança de sites com criptografia SSL/TLS.
• Oferece suporte a IMAP e POP3: NGINX também funciona como um servidor proxy de e-mail, suportando protocolos como IMAP e POP3.

Entretanto, existem algumas desvantagens em usar o NGINX:

• As configurações padrão não são ótimas: Os algoritmos de balanceamento de carga padrão podem não sempre performar de maneira ótima em cada situação.
• Sem compiladores de linguagem nativos: Não possui suporte nativo para geração de sites dinâmicos usando linguagens server-side como PHP ou Python. No entanto, você pode contornar isso com uma extensão de terceiros.

Apache vs. NGINX: Quais são as diferenças?

Apache já foi a principal escolha como servidor web. No entanto, o NGINX rapidamente assumiu a liderança no mercado e agora é popular entre muitos sites de alto tráfego.

Se você planeja trabalhar com dedicated hosting, escolher o servidor web certo é uma decisão importante.

Então, o que diferencia esses dois?

Vamos dar uma olhada mais de perto.

Detalhes	Servidor HTTP Apache	NGINX
Fundado	1995	2004
Termos de licenciamento	Licença Apache 2.0	Licença BSD de 2 cláusulas
Compatibilidade com sistemas operacionais	Windows, Linux, macOS, sistemas baseados em Unix	Windows, Linux, macOS, sistemas baseados em Unix
Suporte ao protocolo WebSocket	Sim	Sim (introduzido na versão 1.3.13)
Suporte a proxy reverso	Sim	Sim
Configuração de host virtual	Suportado	Suportado
Cache	Disponível através de módulos	Incorporado ao núcleo
Consumo de recursos (memória)	Alto	Baixo
Formato de configuração e instalação	Baseado em texto	Baseado em texto (sintaxe mais simples)
Recursos de segurança	suporte ao mod_security oferece configuração flexível de regras e controle de acesso	Filtragem avançada, limitação de taxa, suporte integrado para mitigação de DDoS e desempenho SSL/TLS
Comunicação criptografada (SSL/TLS)	Suportado	Suportado
Manuseio de conexões simultâneas	Bom	Altamente eficiente
Desempenho de escalonamento	Bom	Excepcional
Funcionalidade de distribuição de carga	Alcançável com módulos	Recurso integrado
Desempenho geral e velocidade	Satisfatório	Duas vezes mais rápido que o Apache

Arquitetura e Concorrência

Uma das diferenças mais significativas entre NGINX e Apache é como eles lidam com as solicitações recebidas internamente.

Isso tem um impacto substancial no desempenho e na eficiência de recursos.

Arquitetura Baseada em Processos do Apache

O Apache segue um modelo baseado em processos, gerando uma nova thread ou processo para cada solicitação recebida.

Esses processos ou threads são gerenciados por Módulos de Multi-Processamento (MPMs):

• Prefork MPM: O modelo original do Apache. Cada processo tem um único thread e lida com uma conexão por vez. É simples, mas pode consumir muita memória.
• Worker MPM: Utiliza múltiplos threads por processo, cada um lidando com uma conexão. É melhor que o prefork em termos de memória, mas tráfego pesado e solicitações intensivas de recursos ainda podem sobrecarregar a CPU, levando a problemas de desempenho.
• Event MPM: Semelhante ao worker MPM, mas otimizado para conexões keep-alive (dispositivos que não podem ser desconectados do servidor). No entanto, ainda não é totalmente assíncrono.

Estes são todos bons módulos, mas eles têm uma grande desvantagem: o Apache deve criar novos processos ou threads para cada conexão recebida e destruí-los ao terminar. Ele tenta gerenciar isso pré-criando alguns processos ociosos com antecedência.

No entanto, se várias pessoas desejarem se conectar ao site simultaneamente, o Apache pode exceder seu pool existente, e então ele precisa criar mais processos rapidamente. Isso leva tempo e consome memória.

Este modelo funciona perfeitamente bem para sites de tráfego baixo a médio. Mesmo assim, o Apache pode começar a sobrecarregar sites com muitas conexões simultâneas.

Todos esses processos separados não são super eficientes. Mesmo com o evento MPM, o Apache não pode escapar completamente do modelo de uma thread por conexão.

Arquitetura Orientada a Eventos do NGINX

NGINX adota uma abordagem muito diferente. Em vez de processos ou threads separados para cada conexão, NGINX utiliza uma arquitetura assíncrona, orientada a eventos.

Eis como funciona: 

• O NGINX possui um processo principal (geralmente um por núcleo de CPU) que gerencia vários processos de trabalho. Cada trabalhador pode lidar com milhares de conexões simultâneas. Não há necessidade de os trabalhadores gerarem novas threads ou direcionarem cada solicitação a um processo dedicado.
• Em vez disso, os trabalhadores têm um loop de eventos onde eles observam eficientemente novos eventos em conexões existentes usando os mecanismos do sistema operacional, como kqueue ou epoll. Isso permite que eles manipulem várias conexões dentro de uma única thread. Quando um evento ocorre, como uma nova solicitação que chega ou um servidor backend respondendo, o NGINX o encaminha rapidamente para um espaço livre no trabalhador.
• Isso é muito mais eficiente do que o modelo do Apache. O NGINX pode atender um número massivo de solicitações com uma pegada de memória muito pequena. Ele escala incrivelmente bem, razão pela qual é usado em muitos dos sites mais movimentados da web.

A desvantagem é que o NGINX não pode incorporar interpretadores de código como o Apache faz.

Então, quando você deseja executar código PHP ou Python, o NGINX envia solicitações para um gerenciador de processos FastCGI separado como php-fpm. Este processo executa o código e o traduz para algo que o navegador do usuário possa entender.

Por outro lado, Apache pode executar linguagens como PHP, Perl e Python dentro de seus processos.

Já que o NGINX não pode, o arquivo de configuração pode se tornar um pouco mais complexo.

Os ganhos de desempenho, no entanto, geralmente superam o incômodo.

Desempenho

NGINX é conhecido por ser altamente performático ao servir arquivos estáticos como páginas HTML, imagens, CSS e JavaScript.

A arquitetura baseada em eventos ajuda, mas o NGINX também possui alguns outros truques.

Primeiro, ao contrário do Apache, o NGINX não precisa passar pelo cache e acessar o disco para cada solicitação. Ele pode servir arquivos diretamente do disco. Além disso, o NGINX elimina a sobrecarga que vem com a verificação de permissões e o bloqueio de arquivos.

O Apache apresenta esses problemas porque cada solicitação é um processo, e se um processo está modificando algo, o outro processo não pode usar o mesmo arquivo simultaneamente.

Embora sites menores não percebam esse gargalo devido à rapidez com que as coisas são processadas nos bastidores, um site grande com alguns milhares de solicitações por segundo começará a ver esses problemas desacelerando a experiência do usuário.

NGINX também possui um Cache de arquivos integrado. Na primeira solicitação de um arquivo, o NGINX o lê do disco e o coloca em seu Cache. Solicitações futuras para esse arquivo podem ser atendidas incrivelmente rápido diretamente da memória, sem tocar no disco. Ele também invalida automaticamente os dados em Cache se o arquivo no disco mudar.

Essas otimizações fazem a diferença. Em testes comparativos, o NGINX pode servir arquivos estáticos cerca de três vezes mais rápido que o Apache, especialmente conforme o número de solicitações simultâneas aumenta.

Um bônus: isso também pode ajudar você a melhorar seus principais indicadores web, dando-lhe um pequeno impulso no Google.

O Apache não é lento, também. Você simplesmente precisa gastar tempo ajustando-o para que funcione corretamente. Ele também é capaz de servir arquivos estáticos muito rapidamente.

Mas NGINX é a escolha certa se você deseja um servidor web de alto desempenho assim que desempacotado.

Configuração e Sintaxe

NGINX e Apache possuem diferentes filosofias de configuração.

O Apache é famoso por suas extensas opções de configuração. Além do apache2.conf, você deve adicionar suas regras e configurações ao arquivo .htaccess .

Os arquivos de configuração usam uma sintaxe semelhante ao XML e oferecem incrível flexibilidade. O Apache possui uma extensa lista de diretivas que você pode usar para ajustar todos os aspectos do comportamento do servidor.

Você pode definir opções de configuração globalmente ou substituí-las para diretórios específicos ou hosts virtuais.

O verdadeiro poder do Apache vem de seu vasto ecossistema de módulos. Uma enorme variedade de módulos oficiais e de terceiros do Apache permite que você faça tudo, desde reescrita de URL até filtragem de segurança e cache avançado. Para usar um módulo, você o carrega em sua configuração do Apache.

O lado negativo é que a configuração do Apache pode se tornar complexa rapidamente, especialmente para configurações sofisticadas. Diretivas podem se sobrepor umas às outras em cadeias de herança complicadas. As opções de configuração muitas vezes são divididas em vários arquivos em diferentes subdiretórios da pasta principal config. É super flexível, mas leva algum tempo para dominar.

A configuração do NGINX, por outro lado, visa simplicidade e legibilidade. Aqui não há arquivo .htaccess. Você simplesmente configura os sites no seu NGINX.conf junto com a pasta sites-enabled, e está tudo pronto.

A sintaxe adota estilos de linguagens de programação comuns. Ainda é poderosa, mas não tão extensa quanto o Apache.

Em vez de módulos, o NGINX possui um conjunto menor de diretivas principais e funcionalidades que já vêm integradas. Todas as suas opções para uma determinada funcionalidade geralmente estão em um único bloco juntas (encerradas entre chaves { }).

Algumas funcionalidades avançadas como balanceamento de carga e Cache são configuradas no principal NGINX.conf, não separadas em arquivos auxiliares.

O resultado é que os arquivos de configuração do NGINX tendem a ser mais enxutos e mais acessíveis para ler e configurar do que os volumosos arquivos do Apache, mas você ainda pode fazer muito com eles.

Segurança

NGINX e Apache são projetos de código aberto com grandes comunidades ativas de desenvolvedores trabalhando constantemente para identificar e corrigir vulnerabilidades. Ambos recebem atualizações de segurança regulares e têm um bom histórico de resolução de problemas rapidamente.

Isso dito, existem algumas diferenças em como eles abordam a segurança.

Aqui estão alguns pontos chave a considerar:

• Modularidade: A arquitetura modular do Apache significa que você só precisa habilitar os recursos que usa, minimizando a superfície de ataque. Com o NGINX, muitos recursos padrão são incorporados diretamente ao núcleo, o que alguns podem argumentar que o torna menos flexível do ponto de vista da segurança.
• Filtragem de solicitações: O NGINX possui um poderoso motor de filtragem de solicitações integrado que pode ajudar a bloquear ataques web comuns como injeção de SQL e cross-site scripting (XSS). O Apache possui capacidades semelhantes por meio de módulos como mod_security.
• Configuração de SSL/TLS: Ambos os servidores suportam SSL/TLS para conexões criptografadas, mas diz-se frequentemente que o NGINX é mais fácil de configurar. Ele possui documentação mais clara e padrões de segurança mais seguros por padrão.
• Isolamento de processos: O uso pelo NGINX de um único processo mestre com vários processos de trabalho pode ajudar a isolar áreas problemáticas. Os MPMs prefork e worker do Apache podem fornecer isolamento a nível de processo similar, mas ao custo de usar mais recursos.
• Mitigação de DDoS: A arquitetura orientada a eventos do NGINX e o manejo eficiente de conexões simultâneas tornam-no uma escolha popular para mitigar ataques DDoS de pequeno a médio porte. Alguns módulos adicionais e ajustes também podem tornar o Apache resistente a ataques DDoS.

Conteúdo Dinâmico, Módulos e Ecossistema

Apache há muito é a escolha preferida para servir conteúdo dinâmico porque integra facilmente linguagens do lado do servidor. Com os MPMs prefork e worker, você pode compilar suporte para linguagens como PHP, Python e Perl diretamente no binário do Apache.

O Apache executará então um interpretador dentro de cada um dos seus processos trabalhadores. Isso é simples e eficaz — o Apache pode encaminhar solicitações para arquivos .php para seu interpretador PHP integrado e obter a saída renderizada de volta.

NGINX não possui suporte integrado para linguagens do lado do servidor. Você precisa de um serviço separado como php-fpm que executa o interpretador de linguagem para rodar PHP, Python ou Ruby on Rails com o NGINX. O NGINX recebe solicitações e as encaminha para o backend, que processa o código e retorna uma resposta.

Isso dá um pouco mais de trabalho para configurar do que a abordagem tudo-em-um do Apache. No entanto, isso se encaixa na filosofia do NGINX de fazer uma coisa (servir solicitações) — e fazer isso bem.

Quanto a outras funcionalidades, o NGINX vem com um núcleo restrito de funcionalidades benéficas como balanceamento de carga, proxy, Cache, limitação de taxa, compressão e término SSL. No entanto, não se compara à incrível variedade do ecossistema de módulos do Apache. Com o Apache, você tem módulos para esquemas de autenticação, filtragem de conteúdo, linguagens de script embutidas e além.

Nem todos estes são únicos. NGINX pode executar muitas das mesmas tarefas, apenas de maneiras diferentes. No entanto, a biblioteca de módulos do Apache é bastante extensa.

Se existe alguma funcionalidade super específica de que você precisa, o Apache pode ter vantagem aqui.

Ainda assim, o conjunto de recursos do NGINX é robusto para a maioria das necessidades comuns de servidores web.

Uso Real, Desempenho e Comunidade

A popularidade do NGINX aumentou ao longo da última década.

Em 2022, ele alimenta mais de 34% de todos os sites globalmente, em comparação com aproximadamente 29% do Apache.

Uma coisa que você deve ter em mente: você não notará a diferença entre esses servidores web a menos que você tenha um grande site ou um servidor realmente pequeno.

Suponha que você goste das extensas opções de configuração do Apache e da abordagem tudo em um para conteúdo dinâmico. Os documentos do Apache são alguns dos melhores, e a comunidade é enorme caso você precise de ajuda.

O NGINX pode ser melhor se você estiver buscando máxima concorrência ou construindo um site enorme. Sua arquitetura é um pouco mais preparada para o futuro e construída para escalar. E a comunidade NGINX cresceu rapidamente. Os documentos são sólidos também; você pode encontrar muitos guias e suporte.

Apache vs. NGINX: Qual é o Mais Adequado para Você?

Não existe uma resposta única para o debate entre NGINX e Apache. No entanto, aqui estão algumas boas regras práticas para ajudá-lo a tomar a decisão.

O NGINX é melhor se:

• Você tem um site com muito tráfego.
• Você precisa servir uma grande quantidade de ativos estáticos rapidamente.
• Você está construindo uma arquitetura de microsserviços.
• Você prefere um estilo de configuração mais simplificado.
• Você está usando containers ou hospedagem na nuvem onde cada grama de memória é importante.

Apache é melhor se:

• Você precisa de compatibilidade profunda com recursos exclusivos do Apache como .htaccess.
• Você deseja módulos para funcionalidades super específicas.
• Você precisa executar aplicativos web antigos construídos para Apache e mod_php.
• Você simplesmente gosta do sistema de configuração do Apache.
• Seu servidor é principalmente uma caixa de desenvolvimento, e o desempenho é menos crítico.

Não existe uma regra que diga que você tem que escolher apenas um.

Executar o NGINX à frente do Apache como um proxy reverso é muito comum. Isso permite combinar a imbatível capacidade do NGINX de servir arquivos estáticos e processamento concorrente com o suporte abrangente a linguagens dinâmicas do Apache no backend — o melhor de dois mundos.

Conclusão

Apache e NGINX são ambos excelentes, portanto, escolher um é mais sobre o que melhor se adapta às suas necessidades.

Lembre-se, mesmo o servidor web mais robusto é apenas uma engrenagem na máquina. Portanto, se o site parecer lento, o software ou hardware do servidor web não deve necessariamente ser a primeira coisa a ser otimizada.

Cache mais inteligente, ajuste de banco de dados, otimização de código e hardware sólido podem ajudar a acelerar sua pilha mais do que passar horas ajustando NGINX ou Apache.

Se você precisa de um servidor para experimentar, experimente o VPS gerenciado da DreamHost. Com um VPS, você pode escolher quais softwares instalar, como o servidor deve responder às solicitações e mais. Além disso, com a flexibilidade de um VPS, você pode hospedar vários sites em um único servidor e dividir os recursos entre eles de acordo.

Além disso, todos os planos DreamPress agora vêm com NGINX.

A única maneira de encontrar uma configuração ideal é experimentar. Configure um VPS, instale NGINX e Apache, e veja qual funciona melhor para você!