A internet, como a conhecemos hoje, começou com sua “conquista” global nos anos 90. O protocolo “Web” inteiro pode ser resumido como uma solicitação de um visitante por um documento a partir de um endereço na web, com DNS e o sistema IP encaminhando tal solicitação para o computador correto. Este computador, que hospeda a página web solicitada, a “servirá” ao visitante.
Páginas web são, essencialmente, documentos HTML. Para ser capaz de servir páginas web diferentes aos visitantes, a máquina que as “serve” precisa ter um programa de servidor. Softwares como Nginx e Apache atendem solicitações, as analisam e entregam os documentos correspondentes para que sejam visualizados no navegador do visitante.
Nginx versus Apache
Nginx e Apache são servidores web populares usados para entregar páginas web ao navegador do usuário. Em nosso caso, ocorre a partir de um site WordPress hospedado. Alguns fatos rápidos:
- Apache foi lançado primeiro, em 1995, sendo o Nginx lançado em 2004.
- Ambos são usados por grandes empresas da Fortune 500 ao redor do mundo.
- A fatia de mercado do Nginx tem crescido constantemente ao longo dos anos.
- Em alguns casos, o Nginx tem uma vantagem competitiva em termos de desempenho.
Apache
Falaremos primeiro do Apache, uma vez que ele também foi o primeiro a ser lançado.
Após CERN httpd e NCSA HTTPd de Tim Berners-Lee surgirem nos primeiros anos da internet, o Apache – lançado em 1995 – conquistou rapidamente o mercado e se tornou o servidor web mais popular do mundo. Atualmente, continua ocupando essa posição no mercado, mas isso ocorre principalmente em virtude de seu legado. O Apache está sendo desenvolvido e mantido pela Apache Foundation, sob a licença Apache.
Existem duas histórias diferentes sobre como o Apache recebeu esse nome. Uma versão conta que o nome foi originado a partir da famosa herança nativo-americana, enquanto a outra diz que é uma piada com a expressão “servidor remendado” (“a patchy server”, em inglês), que foi seguida por vários patches de software lançados.
Linux
A grande fatia de mercado do Apache se dá, em parte, ao fato de que ele vem pré-instalado com as principais distribuições de Linux, como Red Hat/Centos e Ubuntu.
Um exemplo do papel importante do Apache dentro do mundo Linux é que seu nome de processamento de servidor é HTTPd, tornando o Apache um sinônimo de software de servidor web.
Além de ser o primeiro participante sério no mercado de servidores web, parte da proliferação do Apache se deve ao seu sistema de configuração e seu arquivo .htaccess.
.htaccess
Apache usa .htaccess para sua configuração. Existem muitos tutoriais que explicam como configurar, editar e trabalhar com esse arquivo, uma vez que ele oferece muita flexibilidade para definir a forma como o Apache atende solicitações que chegam. Alguns exemplos são: diferentes regras de redirecionamento, tamanho máximo de upload de arquivos, reescrita de URL, limites de memória, proteção de diretório (htpasswd), cabeçalho Expires, cabeçalho Cache-Control, cabeçalho encoding, cookies e manipulação de strings de consulta.
Por outro lado, a Kinsta usa Nginx, que não oferece suporte a arquivos .htaccess. No entanto, as configurações e regras de seus arquivos .htaccess podem ser facilmente “traduzidas” para a própria sintaxe de regras de reconfiguração do Nginx.
Um dos maiores prós do Apache é que, na raiz do servidor, – o principal diretório do website – cada nível ou pasta na árvore de diretórios pode ter seu próprio arquivo .htaccess com suas próprias configurações.
Em provedores de hospedagem compartilhada, isso é um sonho, pois podem oferecer a centenas de usuários na mesma máquina uma forma de configurarem como seus websites são servidos, sem que afetem os demais. Os clientes podem configurar diversos detalhes em um ambiente restrito de hospedagem compartilhada, sem nunca tocarem na configuração global do servidor.
Conforme a documentação oficial informa:
“Em geral, você só deve usar arquivos .htaccess quando não tiver acesso ao arquivo principal de configurações do servidor.”
Essa flexibilidade, no entanto, é oferecida em troca de desempenho, já que “habilitar arquivos .htaccess causa uma queda de desempenho, esteja você usando-os ou não!”
Toda vez que arquivos .htaccess são habilitados, o Apache precisa atravessar a árvore de diretórios inteira, desde a URL ou arquivo solicitado e passando por todos os níveis superiores até o diretório raiz do servidor, para então carregá-los a cada solicitação feita. Em seguida, precisa processar esses arquivos e reconfigurar a si mesmo para cada um dos diretórios que estiver configurado dessa forma.
Em websites WordPress, as coisas podem ficar ainda mais complexas. Um website WordPress comum pode ter centenas de solicitações vindas de diferentes diretórios.
Em diretórios do tipo /wp-content/uploads/aaaa/mm, geralmente existem solicitações múltiplas em um só carregamento de página, frequentemente formando diretórios diferentes para os meses. Depois, temos recursos estáticos do /wp-content/themes/tema-mae e recursos do /wp-content/themes/tema-filho: eles incluem javascript, arquivos css e imagens.
Também temos a pasta /wp-content/plugins com arquivos estáticos carregados, geralmente, em dezenas de subdiretórios de plugins. Para cada um desses recursos, o Apache precisa atravessar sua árvore inteira para buscar suas configurações.
Uma análise mostrou que uma instalação comum do WordPress, algo bastante normal nos websites em hospedagens compartilhadas, inclui 42 execuções .htaccess separadas e 249 buscas individuais pelo arquivo .htaccess.
E isso somente no nível do servidor web. O visitante ainda precisa esperar que o PHP processe e execute a pilha de camadas inteira do WordPress, para que crie uma consulta no banco de dados e a forneça ao MySQL, para que ele monte a página web e a entregue.
Módulos
Outro fator que tornou o Apache popular foi seu sistema de módulos dinâmicos.
Módulos – um recurso que permite aos usuários estender a funcionalidade do servidor web – existem tanto no Nginx quanto no Apache. O Apache permite que os usuários instalem módulos quando o servidor web já estiver instalado e implementado, para que consigam ativá-los/desativá-los conforme necessário. Distribuições baseadas em Debian possuem comandos que permitem ativar e desativar tais módulos sem precisar editar qualquer arquivo de configuração (a2enmod e a2dismod).
A lista oficial de módulos que acompanham a distribuição padrão do Apache pode ser encontrada aqui e inclui recursos como compressão, criptografia, registro e redirecionamentos para fatores mais avançados, como edição de solicitações e respostas com sintaxe avançada.
Nginx
Nginx (também escrito como nginx ou NGINX), entrou em cena em 2004, quando foi lançado publicamente pelo desenvolvedor russo Igor Sysoev. Conforme Owen Garrett, gerente de projetos do Nginx, disse:
“Nginx foi escrito especificamente para endereçar as limitações de desempenho dos servidores web Apache.”
O servidor foi criado primeiramente como uma ferramenta de escalonamento para o website rambler.ru, em 2002. Ele é disponibilizado em duas versões: uma de código aberto, com licença tipo BSD, e o Nginx Plus, com suporte e recursos adicionais para empresas.
Após ser lançado, o Nginx foi usado principalmente para servir arquivos estáticos e funcionar como um equilibrador de cargas ou proxy reverso à frente das instalações Apache. Conforme a rede evoluiu e a necessidade de ter cada pingo de velocidade e eficiência no uso de hardware surgiu, cada vez mais websites começaram a substituir completamente o Apache pelo Nginx, também devido ao fato de ser um software mais maduro.
Em março de 2019, a Nginx Inc foi adquirida pela F5 Networks por US $670 milhões. À época, conforme a Techcrunch relata, o servidor estava por trás de “375 milhões de websites com cerca de 1.500 clientes pagantes”.
De acordo com dados da w3techs, a fatia de mercado do Nginx tem crescido consistentemente, empurrando o Apache e o retirando de seu trono na primeira posição:
Esses dados dizem respeito ao panorama geral dos servidores web globais, mas se retirarmos a amostra dos maiores um milhão de websites, veremos que o Nginx já está no primeiro lugar faz algum tempo:
O Google Search Trends também parece refletir esse fato:
Uma pesquisa da Netcraft sugere que o Apache foi ultrapassado pelo Nginx em abril de 2019.
Configuração do Nginx
Nginx não possui um sistema de configurações como o Apache. Por isso, apesar de ser muito mais eficiente e rápido, ele não é amplamente implementado em provedores de hospedagem no varejo. Ele não brilha tanto em ambientes compartilhados como o Apache.
Por outro lado, como dissemos, ao não permitir configurações no nível do diretório, o Nginx tem uma vantagem significativa sobre o Apache. Existe um artigo na wiki do Nginx que compara o impacto de ambos sobre o desempenho:
Módulos Nginx
O sistema de módulos do Nginx é outro fator que o posiciona como uma escolha premium. Os módulos do Nginx precisam, em geral, estar habilitados durante o momento do desenvolvimento, o que significa que um domínio mais técnico é envolvido no processo e a adição pós-instalação dos módulos é um pouco mais complicada de ser realizada.
Em 2016, com a versão 1.9.11, as coisas mudaram e o repositório oficial/verificado de módulos dinâmicos passou a ser reservado aos usuários pagantes. Em maio de 2019, foi anunciado o início do desenvolvimento de suporte para QUIC e HTTP/3.
A Questão do Cache: Nginx vs Apache
Cache – se quisermos simplificar bastante – pode ser descrito como a preparação do conteúdo para os visitantes do website antes que eles façam suas visitas, para que quando estiverem “batendo na porta” você não precise procurar o conteúdo que estão buscando. Tudo já está pronto e você pode oferecê-lo a eles sem nenhum tipo de espera.
Assim como o Apache, a instalação comum do Nginx costumava ficar entre os servidores e o usuário final, para aliviar a queda de desempenho no resto da infraestrutura. Nesses casos, ele consegue armazenar conteúdo estático em cache sem a necessidade de procurá-lo todas as vezes no servidor de origem protegido.
Se usarmos o Nginx como um servidor web stand alone – como é o caso dos contêineres LXC da Kinsta – não há tal necessidade. O Nginx é muito eficiente em servir conteúdo estático por conta própria.
Há também a questão de cache dinâmico ou cache de página. No cenário de um website WordPress, isso significa armazenar todas as páginas do WordPress geradas para cada URL na memória ou no disco.
Cache FastCGI é disponibilizado de forma nativa na instalação padrão do Nginx. Ele é muito simples, poderoso e um dos recursos menos usados no Nginx.
Para fazer uma comparação com seus equivalentes do Apache, você precisa saber que o módulo mod_cache do Apache costuma apresentar erros e conflitos com outros módulos. Por isso, a solução de cache padrão implementada com o Apache é o acelerador Varnish HTTP. Embora o Varnish seja a solução dedicada da indústria, alguns testes recentes mostraram uma vantagem clara da ferramenta de cache do Nginx sobre ele.
Na Kinsta, usamos Nginx para cache dinâmico do WordPress, juntamente com um plugin de cache proprietário que oferece controle granular sobre as páginas armazenadas em cache e ativos estáticos armazenados pela CDN Kinsta.
Atendendo Solicitações: Nginx versus Apache
A maior diferença entre o Apache e o Nginx está na arquitetura subjacente da forma como atendem solicitações.
Apache processa solicitações em MPM-s ou Módulos de Multiprocessamento, que são “responsáveis por se conectarem às portas de rede na máquina, aceitar solicitações e despachar ‘processos filhos’ para que atendam as solicitações”.
O MPM mais antigo, que data dos primórdios do Apache, é o módulo prefork. Ele sozinho pode ser creditado pela má reputação de desempenho do Apache. Sob este módulo, o Apache gera um novo processo com um thread a cada solicitação.
Esse módulo, usado com o mod_php, significava que o servidor Apache incorporava um interpretador do PHP em cada processo, mesmo se tivesse que servir arquivos CSS ou imagens.
Isso era ineficiente. O módulo prefork acompanha o Apache como módulo padrão. Ele também restringe as conexões a HTTP/1.
Nos anos mais recentes, o Apache desenvolveu um trabalhador mpm multi-threaded e, em seguida, o evento mpm. Ambos aliviaram muitos dos problemas de desempenho do Apache. Mudar para o php-fpm tornou possível que o Apache continuasse sendo uma solução competitiva ainda hoje, além de eliminar o uso do .htaccess, embora isso acabe indo contra seu propósito.
Nginx usa uma arquitetura assíncrona, sem bloqueios e orientada por eventos.
Para explicar a diferença: no mundo Linux/Unix, os processos estão executando os programas.
Threads são um subconjunto de processos e podem existir múltiplos threads na execução de um processo. Pense nisso como diversas abas na janela de um navegador. Dessa forma, um programa pode impulsionar múltiplas CPUs e CPUs com diversos núcleos e threads para que executem mais rapidamente. Você pode ler Linus Torvalds elaborando as diferenças.
Em resumo, o Apache usa processos para cada conexão (e com trabalhadores mpm ele usa threads). Conforme o tráfego cresce, se torna caro demais rapidamente.
Podemos descrever a criação de um novo processo ou thread como ligar um computador ou iniciar os programas. Até mesmo o mais rápido dos computadores leva algum tempo para fazer isso. Com os websites de hoje em dia realizando centenas de solicitações no carregamento de uma única página, tudo se acumula rapidamente.
Eventos mpm vão um pouco mais além em termos de otimização, mas alguns testes mostram que não conseguem superar o Nginx. Especialmente quando se fala de arquivos estáticos, nos quais o Nginx serve até o dobro da quantidade de solicitações do Apache.
Idealmente, o Nginx tem um processo de trabalho por CPU/núcleo. A diferença dos processos de trabalho do Nginx é que cada um deles é capaz de atender a centenas de milhares de conexões da rede que chegam. Não há necessidade de criar novos threads ou processos a cada conexão.
Este é o motivo pelo qual as principais Redes de Fornecimento de Conteúdo, como Cloudflare, MaxCDN e nossa parceira KeyCDN – ou websites como Netflix – acreditam que o Nginx seja crucial para a entrega de seu conteúdo.
A lista de empresas que se beneficiam com o Nginx é muito longa para citar todas, por isso vamos encerrá-la com a Automattic, a empresa privada por trás do WordPress.com.
A Automattic converteu todos os seus equilibradores de carga para Nginx no WordPress.com em 2008 (você pode ler sobre isso aqui) e migrou sua pilha do servidor completamente para o Nginx.
Verificação na Vida Real
Se quisermos inspecionar o que um website em produção utiliza, podemos encontrar tais informações nos cabeçalhos de resposta HTTP. Isso significa que precisamos clicar com o botão direito em um website e selecionar Inspecionar. Nas ferramentas do desenvolvedor, escolheremos o painel de rede e recarregaremos o website. Veremos todos os recursos que o website carrega. Se selecionarmos qualquer recurso em particular na aba Cabeçalhos, em geral seremos capazes de observar informações do servidor. Se o website usa CDN, veremos algo como Cloudflare na linha do servidor ou Varnish, caso utilize um acelerador HTTP.
Esse é um exemplo de um website WordPress que usa uma configuração de hospedagem compartilhada comum, com cPanel, Apache e PHP:
Este é um website no Nginx:
No lado esquerdo, se expandirmos, também poderemos analisar o tempo de cada recurso e observar seu impacto no tempo total de carregamento da página.
Resumo
Neste artigo, me concentrei na comparação entre Nginx e Apache e expliquei as principais diferenças de arquitetura que ajudaram o Nginx a ganhar mais tração e atenção na batalha dos servidores web. Esses são traços importantes, que o proporcionam uma vantagem de desempenho em nossa indústria sedenta por recursos.
É claro que nem todo caso de utilização tem as mesmas prioridade e o Apache ou quaisquer outras ferramentas como Lighttpd, IIS, LiteSpeed e Caddy podem ser boas soluções.
Na Kinsta, usamos Nginx como parte de nossas soluções de hospedagem otimizada para desempenho voltadas ao WordPress e WooCommerce. Cada site WordPress é hospedado em seu próprio contêiner isolado, que possui todos os recursos de software necessários para rodá-lo (Nginx, Linux, PHP e MySQL). Esses recursos são 100% privados e não são compartilhados entre os demais sites.
Não deixe de conferir o Nginx e todos os nossos complementos premium. Você também pode checar nossos serviços de Hospedagem de Aplicações e Hospedagem de Banco de Dados para mais opções de hospedagem.
Tonino is an entrepreneur, Linux & OSS enthusiast, developer, and tech educator. He has over ten years of experience in development and has been in the blockchain space for 3+ years. When he's not coding, he writes for SitePoint and Alibaba Cloud, binge-watches the newest works of fiction on Netflix, and explores new travel destinations.
Excelente artigo!