O Mundo dos Servidores Web: Apache vs. Nginx

Introdução ao Apache e Nginx

Os servidores web e protocolos são projetados para permitir que os usuários visualizem páginas web. Eles enviam uma solicitação para visualizar um documento que é aceita pelo servidor. O host então, essencialmente, serve o documento ou informação ao visualizador. O servidor web desempenha um papel central ao permitir que você visualize e acesse páginas web no seu navegador.

Existem muitos servidores web que você pode usar para este propósito. Entre os mais populares estão Nginx e Apache. De fato, esses servidores estão hospedando a maioria dos sites atualmente disponíveis na internet.

O Apache e o Nginx são bastante semelhantes em muitos aspectos. Para começar, ambos os servidores web são de código aberto. Isso significa que qualquer pessoa no mundo pode usá-los sem custo absoluto. Mas existem muitos recursos que são exclusivos de cada um dos servidores. Essas características especiais os tornam mais adequados para várias aplicações e propósitos.

Para ajudar você a decidir qual servidor web é superior ou ideal para você, compararemos o Nginx e o Apache. A comparação será realizada através de uma série de parâmetros essenciais que são críticos para os usuários dos servidores web. Vamos começar!

Visão Geral Básica

Começaremos com uma visão geral dos dois servidores web. Tanto o Apache quanto o Nginx construíram ótimas reputações na comunidade. Eles são aclamados por seus desempenhos e usados por várias organizações de grande nome ao redor do mundo.

Apache

O Apache surgiu em 1995. Robert McCool desenvolveu este servidor HTTP sob a Apache Software Foundation, daí o nome. Desde o seu lançamento, centenas de milhares de pessoas em todo o mundo têm usado o Apache.

Sua enorme popularidade significa que muitos softwares e fontes de terceiros colaboram com ele frequentemente. Portanto, se você está procurando por uma boa rede de suporte com muitas integrações, o Apache é o ideal para você. O Apache também é preferível para muitas pessoas porque é mais dinâmico e flexível. Ele também oferece uma maior variedade de linguagens que pode interpretar.

Nginx

Nginx é um servidor web relativamente mais novo, lançado em 2004. É o resultado dos esforços de Igor Syosev para lidar com algo que hoje é conhecido como o problema C10K. Esse problema surgiu quando começou a ficar difícil para os servidores lidarem com grandes volumes de tráfego. À medida que mais e mais pessoas começaram a usar a internet, os servidores de sites começaram a ficar sobrecarregados. A incapacidade desses servidores de lidar com milhares de conexões ao mesmo tempo fazia com que os sites caíssem e falhassem.

O Nginx foi lançado para tentar resolver esse problema. É por isso que sua arquitetura possui um design incrivelmente leve, capaz de funcionar com recursos e hardware limitados. Embora seja mais adequado para funcionar com conteúdo estático, ele também pode se integrar com softwares que lidam adequadamente com conteúdo dinâmico.

Capacidades de Manipulação de Tráfego

Agora que temos uma ideia básica de cada um dos servidores, podemos nos aprofundar em mais detalhes. O primeiro recurso com o qual começaremos são as capacidades de tráfego e manipulação dos servidores individuais. Este é um dos principais pontos que separam essas duas plataformas. Suas arquiteturas funcionam em princípios diferentes quando se trata de lidar com múltiplas conexões simultaneamente.

Apache

O Apache usa algo chamado MPM - Módulos de Multiprocessamento. Os administradores usam uma variedade de MPMs para manipular e modificar a arquitetura de manipulação de conexões. Parte do apelo do servidor web Apache é a flexibilidade que sua arquitetura oferece. Essa infraestrutura baseada em módulos que divide o processamento em threads individuais e em grupos facilita o dimensionamento e a adaptação a diferentes tipos de conexões.

Vamos dar uma olhada em alguns dos módulos individuais usados no Apache:

• mpm_prefork

O primeiro é o mpm_prefork. Este é um módulo de processamento responsável por lidar com as requisições de entrada dos visitantes. Ele cria uma thread ou processo filho para lidar com uma conexão em qualquer momento dado. Isso significa que se o número de requisições for menor que o número de processos, o mpm_prefork é bastante eficiente em sua função.

As requisições são processadas rapidamente, pois um processo filho separado processa cada uma individualmente. Mas isso também significa que se o número de requisições exceder o número de processos, isso pode desacelerar as coisas consideravelmente. Como resultado, a etapa de processamento de requisições consome muita RAM.

• mpm_worker

Como já sabemos, uma thread é responsável por uma conexão. Este módulo vai um passo além e permite gerenciar múltiplas threads ao mesmo tempo. Este é um módulo muito mais escalável em comparação com o mpm_prefork, que apresenta dificuldades além de um certo limite. Novas conexões podem se conectar a uma thread imediatamente, em vez de terem que esperar.

• mpm_event

O mpm_event é responsável por manter as conexões keep-alive. O objetivo principal deste módulo é evitar que o sistema fique sobrecarregado devido a requisições keep-alive. Ele faz isso dedicando uma thread a uma conexão mesmo sem a presença de uma requisição ativa. A thread permanecerá dedicada enquanto a conexão estiver ativa. Quaisquer requisições recebidas são transferidas para threads desocupadas.

Nginx

Ao contrário do Apache, o Nginx foi construído com um propósito muito específico em mente. Nós já conhecíamos os problemas que surgiam com conexão e escalabilidade a este nível. É por isso que ele usa um algoritmo que é assíncrono e não bloqueante. Ele não dedica threads individuais para cada conexão. Em vez disso, o Nginx produz inúmeros processos worker que são capazes de lidar com milhares de conexões ao mesmo tempo.

O princípio de funcionamento por trás da arquitetura do Nginx é o mecanismo de loop rápido. Este algoritmo está constantemente processando eventos e monitorando-os. Isso significa que os processos são orientados a eventos e cada processo worker está comprometido apenas com suas próprias conexões. Todas as conexões de um processo worker estão localizadas em um loop de eventos. Aqui, elas coexistem e passam por processamento de forma assíncrona com as outras conexões sob este worker específico.

O principal benefício de tal arquitetura é que ela permite uma grande capacidade de escalabilidade. Isso se torna especialmente aplicável se você tiver recursos limitados ou quiser trabalhar com hardware mínimo. Mesmo se você estiver enfrentando grandes volumes de tráfego, haverá pouco impacto no uso de RAM. Isso ocorre porque você não está gerando threads individuais para cada conexão.

Lidando com Conteúdo Estático e Dinâmico

Outro parâmetro que podemos usar para comparar os dois servidores web é como eles lidam com estático e conteúdo dinâmico.

Apache

O Apache usa um método baseado em arquivos para lidar com conteúdo estático. Seu sistema de processamento MPM permite que ele trabalhe com este método convencional.

Quando se trata de processar conteúdo dinâmico, o Apache pode fazer isso sem precisar de ajuda de componentes externos. Você pode habilitar os processadores dinâmicos carregando um módulo. Este módulo processará o conteúdo analisando a linguagem e, em seguida, incorporando o processador relevante no worker.

O principal benefício de não ter que usar componentes externos para processar conteúdo dinâmico é evidente durante a configuração e coordenação. É muito mais fácil coordenar apenas componentes internos entre si.

Nginx

A maior diferença entre a maneira como o Apache e o Nginx lidam com o conteúdo é que o Nginx é simplesmente incapaz de processar conteúdo dinâmico internamente. Ele precisa ser emparelhado com um componente externo para processar requisições de conteúdo dinâmico. Isso significa que você precisará usar seu servidor Nginx em conjunto com um processador externo. O componente receberá a requisição de PHP/conteúdo dinâmico, irá processá-lo e, em seguida, enviá-lo de volta para o servidor.

Como a informação precisa ser transmitida entre os dois componentes, você precisará coordenar a comunicação entre eles. Você terá que determinar quantas conexões deseja permitir e configurar o protocolo. Você terá que usar o protocolo que possa ser lido e compreendido pelo Nginx, como HTTP, FastCGI, SCGI, uWSGI ou memcache, entre outros.

Por outro lado, o Nginx se sai muito bem com o tratamento de conteúdo estático. Ele precisa de ajuda de fontes externas para fazer isso. Ele também só ativará o intérprete quando precisar dele. Este é um dos benefícios de usar o Nginx. O intérprete não está embutido no processo. Isso significa que ele só estará presente para o processamento de conteúdo dinâmico.

Diretórios de Conteúdo: Configuração Distribuída vs Centralizada

Cada servidor web possui seu próprio diretório de conteúdo. Um dos parâmetros mais críticos para avaliar o Apache e o Nginx é se eles permitem ou não a configuração em nível de diretório.

Apache

Existem certos arquivos ocultos nos diretórios de conteúdo que contêm diretivas. Estes são os arquivos .htaccess. Com o Apache, você pode interpretar essas diretivas por diretório. Assim, quando você envia uma solicitação, o Apache inspeciona o caminho do arquivo para encontrar um arquivo .htaccess. Quando o encontra, ele interpreta e aplica as diretivas contidas nele imediatamente. Apache não reiniciará o servidor para implementar essas diretivas.

O processo definido acima permite a configuração descentralizada dos diretórios no servidor web. A configuração descentralizada é útil para reescritas de URL, implementação de restrições de acesso, confirmação de autorizações e definição de políticas de cache.

Um dos benefícios do arquivo .htaccess é que o usuário, que não possui autenticação, pode controlar e modificar pelo menos algum aspecto do conteúdo que está visualizando em seu navegador. É por isso que o Apache é frequentemente usado por provedores de hospedagem compartilhada. Os provedores de serviços têm acesso autorizado à configuração central. Os clientes conseguem exercer controle sobre determinados diretórios sem ter acesso à configuração principal.

Se desejar, é possível desativar a interpretação do .htaccess no Apache.

Nginx

Ao contrário do Apache, o Nginx não funciona com arquivos .htaccess. Isso o torna comparativamente menos flexível. No entanto, o Nginx traz uma série de melhorias em seu estilo de configuração. Para começar, ele é capaz de processar solicitações em uma velocidade muito maior do que o Apache. Isso ocorre porque ele não busca, lê, interpreta e depois implementa cada arquivo .htaccess que encontra em seu caminho. Em vez de pesquisar cada diretório pai, o Nginx faz apenas uma busca de diretório por solicitação.

Além disso, o Nginx tem uma grande vantagem de segurança sobre o Apache. O Nginx não entrega nenhuma parte da configuração dos diretórios de conteúdo a usuários individuais, ao contrário do Apache. Embora você possa estar mantendo medidas de segurança rigorosas, quem garante que os usuários individuais consigam fazer o mesmo? Com o Nginx, você mantém o controle sobre o status de segurança e a configuração de toda a rede de diretórios.

Interpretação de Solicitações

Outra forma de diferenciar os dois servidores é a maneira como eles interpretam as solicitações.

Apache

Quando o servidor recebe uma solicitação, ele a interpreta e a conecta aos recursos do sistema relevantes. Ele interpreta a solicitação como um recurso físico no sistema de arquivos ou como uma URI localização.

Ao interpretar como um recurso físico, ele usa os blocos <Directory> ou <Files>. Este é o método de interpretação padrão para o servidor. Ele pega a raiz do documento. Em seguida, segue o host e o número da porta na solicitação para encontrar o arquivo relevante na árvore de documentos.

A localização URI, por outro lado, precisa de uma avaliação abstrata. Portanto, o Apache emprega os blocos <Location> para recursos abstratos em vez de trabalhar com o sistema de arquivos.

Existem várias outras alternativas ao uso do sistema padrão baseado em arquivos além do URI. Por exemplo, você pode usar a diretiva Alias para encontrar um local alternativo para mapear. Você também pode fazer uso de variantes de expressão para tornar a configuração do sistema de arquivos mais flexível.

Nginx

Enquanto o Apache nasceu para ser um servidor web, o Nginx desempenha um papel duplo como servidor web e servidor proxy. É por isso que, em vez de se inclinar para o sistema de arquivos, o Nginx prefere trabalhar com URIs. Você pode visualizar essa preferência pelo fato de não haver como especificar a configuração para um diretório do sistema de arquivos no Nginx. Ele pode, no entanto, traduzir para o sistema de arquivos se e quando necessário.

Server e location são os blocos de configuração usados principalmente no Nginx. O primeiro interpreta o host que está sendo solicitado. O segundo corresponde às partes da URI após o host e a porta. Como resultado, o servidor interpreta a solicitação como um local de URI em vez de um arquivo real no sistema.

Devido ao seu sistema de interpretação baseado em URI, o Nginx é capaz de desempenhar seu papel como servidor web, servidor proxy e servidor de e-mail. Como ele não se refere ao sistema de arquivos ao interpretar a solicitação, é compreensível por que ele também não implementa arquivos .htaccess.

Sistemas de Módulos

Embora tanto o Apache quanto o Nginx ofereçam suporte a sistemas de módulos para extensão, existem algumas diferenças importantes em seus funcionamentos internos.

Apache

Com o Apache, você pode carregar e descarregar módulos dinamicamente ao executar o servidor. O núcleo permanece no centro dos processos e os módulos servem para estender a funcionalidade. Você pode usar esses módulos acopláveis para realizar uma série de tarefas. As opções são praticamente infinitas com a vasta biblioteca do Apache.

Na verdade, você pode até modificar a função do núcleo do servidor usando módulos como o mod_php. Como mencionamos antes, este módulo permite embutir um interpretador PHP nos processos de trabalho individuais. Isso é útil quando você precisa processar conteúdo dinâmico.

Mas a história não termina aí. Você também pode adicionar módulos para habilitar funções como autenticação de cliente, fortalecimento do servidor (hardening), cache, reescrita de URL, proxies, limitação de taxa, compressão, bem como criptografia.

Nginx

O sistema de módulos do Nginx é diferente no sentido de que você não pode carregar dinamicamente os módulos no servidor principal. Em vez disso, eles precisam ser coletados e compilados no software principal. Isso deixa a desejar em termos de flexibilidade e facilidade de uso. Embora os pacotes de distribuição tenham alguns módulos comuns, você terá que compilar o servidor para outros módulos. Portanto, você precisa saber como manter seu software compilado fora do sistema de empacotamento tradicional.

Apesar disso, a vantagem desse sistema de módulos não padrão é que ele oferece um alto grau de especificidade. Você pode personalizar seus módulos incorporando apenas as funcionalidades de que precisa. Isso permite que você deixe para trás os componentes desnecessários e evite riscos de segurança no processo. Ao mesmo tempo, você pode realizar as mesmas tarefas com os módulos do Nginx que realizaria com o Apache. Isso inclui reescrita de URL, registro de logs, autenticação e assim por diante.

Ecossistema e Suporte

Integrações e suporte de software são muito importantes quando se trata de servidores web. A seguir, exploraremos a compatibilidade e o suporte disponíveis para o Apache e o Nginx.

Apache

O Apache é uma plataforma mais antiga e popular. Assim, é compreensível que ele tenha uma gama maior de ferramentas e softwares de suporte em comparação com o Nginx. Há uma tonelada de documentação de terceiros à sua disposição para dar suporte ao servidor principal. Não apenas isso, mas você também pode combiná-lo com outros softwares para realizar tarefas específicas. Você pode adicionar essas ferramentas ao seu projeto ou ao seu pacote. Elas são capazes de se integrar facilmente dentro do ecossistema do Apache.

Nginx

Embora o Nginx esteja atrás do Apache nesse aspecto, ele certamente está fazendo o seu melhor para alcançá-lo. Cada vez mais pessoas estão adotando o Nginx à medida que percebem todo o seu potencial. O suporte para a plataforma continua a crescer junto com seu crescimento orgânico como um servidor web útil e de processamento rápido.

Um dos principais obstáculos de suporte que o Nginx teve que superar foi encontrar documentação no idioma inglês. Isso ocorre porque a maior parte do Nginx foi originalmente escrita em russo, incluindo a maior parte de sua documentação. No entanto, à medida que o servidor se espalhou e se tornou mais conhecido, muitos recursos de terceiros estão agora disponíveis no idioma universal.

Uma Solução Colaborativa?

Agora, você tem uma compreensão muito melhor dos componentes essenciais e do funcionamento interno do Apache e do Nginx. Embora sejam bastante diferentes um do outro, alguns usuários aproveitam esse fato para obter o melhor dos dois mundos. É isso mesmo - é possível usar o Apache e o Nginx juntos.

Convencionalmente, os usuários tendem a usar o Nginx como um proxy reverso e colocá-lo na frente do Apache. Isso permite compensar a falta de velocidade no tratamento e processamento de solicitações do Apache. O Nginx recebe e processa todas as solicitações enquanto está em sua velocidade máxima. Ele também permite lidar rapidamente com um grande número de solicitações simultâneas sem a necessidade de investir muitos recursos.

Outro recurso do Nginx que os usuários aproveitam é sua capacidade de lidar com conteúdo estático de maneira eficiente. Para compensar o fato de que o Nginx precisa de um componente externo para processar conteúdo dinâmico, podemos encaminhar o PHP e outras solicitações relevantes para o Apache por meio de um proxy. O Apache renderizará a solicitação em uma página web e a enviará de volta ao Nginx para que ele possa servir ao cliente.

Aqui estão alguns recursos que você pode encontrar em nosso blog que podem ajudar você a começar com ambos os servidores web:

Apache

• Instalando o Servidor Apache no Ubuntu 18.04: Um Guia Prático
• Configurando Virtual Hosts do Apache no Ubuntu 20.04
• Como Instalar a pilha Linux, Apache, MySQL, PHP (LAMP) no CentOS 7
• Protegendo o Apache com Let’s Encrypt no Ubuntu 18.04

Nginx

• Instalando o Nginx no Ubuntu 18.04
• Automatizar Renovações de Certificado SSL do LetsEncrypt para o Nginx
• Como Proteger o Nginx com Let’s Encrypt no Ubuntu 20.04
• Como Instalar a pilha LEMP (Linux, Nginx, MySQL PHP) no Ubuntu 20.04

Conclusão

No fim das contas, tanto o Apache quanto o Nginx têm seus pontos fortes e fracos. Não existem regras rígidas ou recomendações sobre qual servidor você deve usar para o seu projeto. Você é o melhor juiz para decidir o que funciona melhor para a sua aplicação com base em seus requisitos exclusivos.

Você precisa identificar os aspectos e recursos dos quais não pode abrir mão e escolher de acordo. Se for difícil tomar a decisão, você sempre pode optar por usar ambos os servidores juntos em uma solução personalizada.

Boa computação!