O tipo mais comum de software encontrado nesses servidores será normalmente Apache e NGINX. Com a maioria dos provedores de hospedagem, isso é predeterminado pelo próprio provedor de hospedagem, embora certamente haja opções por aí que permitirão que você escolha manualmente a que prefere. Sendo esse o caso, o caso de uso por trás deste software é processar as solicitações recebidas para acessá-los.

O software em si é projetado para executar tarefas e lidar com um grande número de solicitações em um pequeno intervalo de tempo. Agora, a parte importante a notar aqui é que este software também precisa trabalhar com outros componentes específicos, portanto, precisa se adaptar. Para lhe dar um pouco mais de perspectiva, você precisará de um servidor com suporte HTTPS , como Apache ou NGINX, PHP , que é a linguagem por meio da qual muitos sistemas de gerenciamento de conteúdo são executados, como WordPress, e o software de banco de dados por trás disso, que provavelmente será MySQL.

Agora, a principal razão pela qual o Apache, assim como o Nginx, podem ser tão familiares para você é devido ao fato de que, juntos, ambos controlam mais de 50% do tráfego que você vê online, e ambos podem até mesmo lidar com diversos cargas de trabalho e trabalhar junto com outro software com facilidade.

No entanto, eles são vistos mais como palavras da moda, e muitas pessoas não sabem realmente o que são, o que fazem e como funcionam em segundo plano.

Apache: Uma Breve História

O Apache pode ser visto como este software de servidor HTTP atualmente em desenvolvimento pela Apache Software Foundation, que começou a trabalhar nele em 1999. Foi originalmente criado por Robert McCool em 1995 e é uma das opções mais populares normalmente encontradas em muitos hosts provedores lá fora. Isso se deve ao fato de possuir vasta documentação, a par do suporte integrado de outros projetos de software.

A principal razão pela qual a maioria dos administradores de rede tende a escolhê-lo é devido ao fato de que oferece um alto nível de flexibilidade e tem um sistema de módulos que é carregável dinamicamente e pode processar um grande número de linguagens integradas. Tudo isso é possível sem a necessidade de software externo, o que é único.

Um dos melhores aspectos e razões pelas quais você pode querer escolher este em vez de NGINX é devido ao fato de que ele é mantido por uma comunidade aberta de desenvolvedores em ASF, e é executado em Linux, tornando-o um dos componentes principais em a pilha LAMP . A pilha LAMP consiste em Linux, Apache, MySQL e PHP.

NGINX: Uma breve história

NGINX foi criado por Igor Sysoev. Ele tem uma história de fundo interessante na forma como foi criado como resposta a um problema conhecido como C10K , que era um desafio no qual os servidores web precisavam lidar com dezenas de milhares de conexões simultâneas como um requisito para a infraestrutura web moderna.

O desenvolvimento começou em 2002 e o lançamento inicial chegou ao mercado em 2004, tornando-o muito mais novo que o Apache, mas à medida que você aprende um pouco mais sobre ele, você pode perceber porque isso também é uma desvantagem.

Dito isso, o progresso foi alcançado por meio de uma arquitetura assíncrona orientada a eventos e, como tal, conseguiu crescer bastante em popularidade devido ao fato de ter um baixo impacto sobre os recursos, bem como a capacidade de escala facilmente. Na verdade, ele se especializou em servir conteúdo estático rapidamente e foi projetado para passar solicitações dinâmicas para outro software mais adequado para lidar com essa carga de trabalho.

Agora, a principal razão pela qual você pode ver que os administradores escolheram o NGINX em vez do Apache é devido ao fato de que ele é eficiente, tem um nível mais alto de capacidade de resposta e suporte de tráfego. O aspecto único do NGINX, entretanto, está no fato de que ele pode funcionar como um proxy reverso e também como um balanceador de carga. Isso permite que ele preencha muito mais funções do que o Apache.

Diferenças entre Apache e NGINX

Existem muitas diferenças entre estes dois, no entanto, com o objetivo de lhe dar uma perspectiva melhor de como tudo isso funciona, discutiremos os três aspectos principais com os quais você precisa se preocupar, e estes incluem gerenciamento de servidor, configuração de servidor , e módulos.

Gerenciamento de Solicitações

Quando se trata de gerenciamento de solicitações, o Apache aproveita os módulos de multiprocessamento ou MPMs para lidar com as conexões, e você pode escolher entre um total de três MPMs.

Primeiro, você tem o mpm-prefork, que é este módulo que pode criar um processo de thread único para lidar com cada solicitação. Cada um desses processos pode lidar com uma única conexão.

Então você tem o pmp-workerque é este módulo que pode iniciar um processo multi-threaded, com o thread exato que é capaz de gerenciar uma única conexão.

Finalmente, você tem mpm_event, e este é um módulo que funciona de forma semelhante ao, mpm_workerexceto que é otimizado para manter as conexões ativas.

Agora, o apache permite que você escolha qual módulo deseja usar, e você pode trocá-los conforme a necessidade.

Vamos comparar isso com o funcionamento do NGINX . Ele pode gerenciar muito mais solicitações usando menos recursos e é isso que o torna muito mais eficiente. Para fazer isso, no entanto, ele usa uma abordagem orientada a eventos e isso significa que ele usa um processo multi-threaded, onde cada thread pode lidar com várias conexões.

Configuração do Servidor

Discutindo a configuração do servidor, o Apache usa arquivos .htaccess para definir regras específicas . Essas regras se tornam uma parte fundamental de como tudo funciona em termos de tratamento de solicitações de entrada, e esses arquivos incluem tudo, desde regras de redirecionamento a limites de memória.

A beleza do Apache aqui está no fato de que ele permite que você configure arquivos .htaccess individualmente, e este é o caso para cada diretório na árvore do servidor. Isso significa que cada arquivo .htaccess executado em um caminho de solicitação precisa ser interpretado separadamente e pode demorar um pouco mais para ser executado como resultado.

Quando vemos a outra extremidade desse espectro, o NGINX realmente não oferece esse nível de flexibilidade, e você tem um único arquivo que tem a responsabilidade de governar todo o processo, o que o torna mais rápido, embora você perca em termos de flexibilidade.

Módulos

É aqui que o Apache brilha.

No NGINX, você não pode realmente desabilitar os módulos uma vez que eles são compilados, pois eles devem ser compilados no núcleo do NGINX para que você possa usá-los.

No entanto, quando se trata do Apache, você tem módulos que agem como complementos que podem ser usados ​​junto com o software do servidor para estender sua funcionalidade. Já que é um pouco mais velho,O Apache tem uma seleção maior desses módulos e ainda permite que você os instale, habilite e desabilite de acordo com sua necessidade específica.

Conteúdo Estático e Dinâmico

Quando se trata de cenários de caso de uso do mundo real em termos de Apache e NGINX, você idealmente está olhando para a maneira como cada servidor lida com as solicitações de conteúdo estático e dinâmico.

Os servidores Apache podem lidar com conteúdo estático por meio do uso de métodos baseados em arquivos mais convencionais. O desempenho dessas operações é função do método MPM.

Agora, o apache também pode processar conteúdo dinâmico incorporando um processador da linguagem que você está usando em cada uma de suas instâncias específicas, e isso é o que permite a execução de conteúdo dinâmico dentro do servidor web sem a necessidade de depender de componentes externos. .

O Apache se destaca no fato de que pode lidar com conteúdo dinâmico internamente, e isso significa que a configuração pode ser mais simples como resultado. A comunicação não precisa ser coordenada com nenhum outro software e os módulos podem ser trocados se a qualquer momento suas necessidades específicas mudarem.

Discutindo o NGINX , ele realmente não tem a capacidade de processar conteúdo dinâmico , pelo menos não nativamente. Na verdade, para processar e lidar com o PHP e também com outras solicitações de conteúdo dinâmico, o NGINX precisa passar para um processador externo para sua execução e esperar que o conteúdo renderizado seja enviado de volta. Isso, por sua vez, resulta em um período um pouco mais longo para o processamento.

Na verdade, a comunicação deve ser configurada primeiro entre o NGINX e também o processador por meio de um dos protocolos com os quais o NGINX pode se comunicar, incluindo http, FastCGI, SCGI , wUSGI e memcache.

Como você já deve ter notado, isso pode complicar um pouco as coisas, e se você está tentando antecipar o número de conexões, uma conexão adicional deve ser usada para cada chamada para o próprio processador.

Configurações distribuídas e centralizadas

Se você é um administrador, ou apenas deseja se tornar um, e esse é o principal motivo pelo qual está lendo este artigo, você deve saber que uma das diferenças mais importantes entre as duas partes do software discutidas aqui é se o diretório a configuração de nível é permitida nos próprios diretórios de conteúdo .

Veja, o apache inclui esta opção para permitir configuração adicional por diretório por meio da inspeção, bem como as diretivas de interpretação em arquivos ocultos dentro dos próprios diretórios de conteúdo. Esses arquivos, conforme discutido anteriormente, são os arquivos .htaccess.

Esses arquivos residem nos próprios diretórios de conteúdo e, quando tratam de uma solicitação, o Apache precisa verificar cada componente ao longo do caminho para o arquivo solicitado em busca de um arquivo .htaccess que aplica as diretivas encontradas nele.

Isso permite a configuração descentralizada do próprio servidor da web e é freqüentemente usado para a implementação de regravações de URL , restrições de acesso , autorização e até autenticação junto com outras políticas de cache.

Na outra extremidade do espectro, você tem o NGINX, que na verdade não interpreta os arquivos .htaccess .

Ele nem mesmo fornece um mecanismo para avaliar qualquer configuração por diretório, fora de seu arquivo de configuração principal.

Como tal, é muito menos flexível do que o modelo Apache , mas oferece certas vantagens não encontradas no Apache.

Veja, .htaccess pode levar a um melhor desempenho . Isso se deve ao fato de que a configuração mais básica do Apache permite .htaccess Em qualquer diretório, permite que o servidor verifique cada um dos arquivos nos diretórios pais que levam ao arquivo solicitado. Se um ou mais arquivos .htaccess forem encontrados durante a pesquisa, eles podem ser lidos e interpretados.

Agora, por não permitir substituições de diretório, o NGINX pode atender a solicitações mais rapidamente , fazendo uma única pesquisa de diretório e leitura de arquivo para cada solicitação.

Agora, outra vantagem que você obtém é uma vantagem relacionada à segurança, em que distribuir o acesso à configuração no nível do diretório também distribui a responsabilidade pela segurança para usuários individuais, que podem não ser confiáveis ​​para lidar com essa tarefa, por exemplo.

Uma análise aprofundada dos módulos

Como mencionado anteriormente, tanto o NGINX quanto o Apache são extensíveis por meio de sistemas de módulo; no entanto, eles funcionam de maneira um pouco diferente quando se trata de seus casos de uso e também de implementação.

Como mencionado anteriormente, o Apache tem este sistema de módulo que permite que você carregue e descarregue dinamicamente quaisquer módulos que você precisa em um determinado período de tempo, agora, o núcleo do apache está sempre presente e os módulos podem ser ligados ou desligados durante a adição ou removendo qualquer funcionalidade adicional.

Devido a isso o Apache pode usar esta funcionalidade para uma grande variedade de tarefas, e devido à maturidade da plataforma, existe uma extensa biblioteca de módulos disponíveis.

O NGINX implementa outro sistema de módulo e é diferente de várias maneiras. Veja, no espectro de coisas do NGINX, os módulos não são carregáveis ​​dinamicamente e devem ser selecionados e compilados no software principal.

Para a maioria dos usuários, isso fará NGINX muito menos flexível. Eles são úteis porque permitem que você determine exatamente o que deseja do seu servidor, incluindo apenas a funcionalidade de que você realmente precisa. Eles também podem permitir muitos dos recursos que os módulos Apache têm, como compactação, limitação de taxa, registro, reescrita, geolocalização, autenticação, criptografia e muito mais.

Arquivo versus interpretação baseada em URI

Em outras palavras, esta é uma análise de como o servidor da web pode interpretar solicitações, bem como mapeá-las nos recursos do sistema.

Discutir o Apache a esse respeito fornece essa capacidade de interpretar uma solicitação como um recurso físico no sistema de arquivos; no entanto, pode ser um local de URI que pode exigir uma avaliação abstrata.

O Apache usa Directoryou Filebloqueia e usa Locationblocos para recursos abstratos.

O Apache foi projetado como um servidor da web , portanto, o método padrão de interpretar solicitações é como recursos do sistema de arquivos. Ele rastreia a raiz do documento e anexa a posição das solicitações que seguem o host e o número da porta para tentar encontrar o arquivo em questão.

Quando se trata de NGINX , ele foi originalmente desenvolvido para funcionar tanto como um servidor web quanto como um servidor proxy . Ele funciona com URIs e se traduz no sistema de arquivos quando necessário. Isso significa que os arquivos de configuração do NGINX são construídos e interpretados e não fornece um mecanismo para especificar a configuração de um diretório do sistema de arquivos e analisa o próprio URI.

Apoiar

Devido ao fato de que o Apache já existe há muito tempo, o servidor tem um suporte incrível. Existe uma enorme biblioteca de documentação original e de terceiros que está disponível para o servidor núcleo e, como resultado, isso agiliza muito as coisas para novos administradores.

É importante notar que O Apache também recebe muito mais suporte de terceiros, devido ao fato de ter uma maior participação de mercado e estar disponível por um longo período de tempo. As pessoas se sentem confortáveis ​​com isso, entendem e apóiam isso.

NGINX tem um maior nível de suporte, no entanto, ele só cresce na medida em que sua implementação cresce. Em outras palavras, quanto mais pessoas acabarem usando, maior o nível de suporte que ele realmente terá.

Ao longo de sua história, foi difícil encontrar documentação em inglês devido ao fato de ter sido originalmente desenvolvida na Rússia, então as instruções eram em russo, porém conforme crescia, a documentação foi sendo preenchida, e hoje em dia existem muitos recursos disponíveis online .

Nível de segurança em cada opção

O Apache mantém os sites seguros e até oferece tratamento de ataque DDoS junto com o que é conhecido como mod_evasive módulo , e este módulo responde a ataques HTTP, DoS , DDoS e de força bruta .

Na outra extremidade do espectro, você tem NGINX, que tem uma base de código significativamente menor em comparação . No entanto, isso nem sempre é uma desvantagem, pois há menos código a ser comprometido. Ele também possui uma lista de avisos de segurança e pode proteger bem o seu site.

Apache e NGINX combinados

Analisando o que são e como funcionam os dois, há grandes chances de você ter uma perspectiva melhor de como cada um deles funciona. Agora, você pode estar pensando consigo mesmo, como faço para aproveitar as vantagens de ambos?

Quando olhamos como a maioria dos outros usuários os combina, você descobrirá que o NGINX é usado na frente do Apache como esse proxy reverso , pois isso permite que o NGINX trate de todas as solicitações dos clientes e, como tal, tira proveito de sua velocidade de processamento rápida, bem como a capacidade de lidar com muitas conexões simultaneamente.

Agora, o NGINX é especializado em conteúdo estático , já que os arquivos são servidos de forma rápida e direta. Para conteúdo dinâmico, ele pode enviar a solicitação ao Apache , que processa os resultados e retorna a página renderizada.

Esta configuração funcionará excepcionalmente bem devido ao fato de que permite que o NGINX funcione para classificação, uma vez que pode lidar com todas as solicitações e repassar aquelas que não pode para o Apache.

Você pode até adicionar outros servidores de back-end, se necessário, com esta configuração.

Ao combiná-los, você está essencialmente obtendo o melhor dos dois mundos . O único problema que pode surgir é quando ambos ouvem as mesmas portas, portanto, quando você dá a eles portas diferentes para ouvir, a funcionalidade do sistema estará em um nível ideal.

Resumo

Tanto o Apache quanto o NGINX desempenham uma função específica no mercado e servem para se adequar a um público diferente.

Por que escolher o Apache em vez do NGINX

Quando você precisa acessar os arquivos .htaccess devido ao fato de que pode substituir as configurações de todo o sistema em uma base por diretório por meio deles, o que pode fornecer um desempenho ideal para o seu servidor.

Quando você tem limitações funcionais devido ao fato de que os módulos abrem muitas possibilidades para você que você simplesmente não encontrará no NGINX.

Por que escolher o NGINX em vez do Apache

Quando você está carregando conteúdo estático rápido devido ao fato de que ele pode lidar com arquivos estáticos de um diretório específico muito mais rápido do que o Apache.

Quando você tem um site de alto tráfego, ele pode fornecer o conteúdo para muitas pessoas sem perder velocidade. Os processos do servidor upstream nunca são bloqueados devido ao fato de que o NGINX pode processar várias solicitações de conteúdo estático simultaneamente.

Se você quiser escolher qual funciona melhor para você, bem, isso dependerá muito de seus casos de uso e requisitos específicos. Na maioria das vezes, o serviço de hospedagem que você escolher terá esse serviço pré-determinado para você, portanto, tome cuidado antes de decidir escolher um.

Escolha aquele que é perfeito para suas necessidades específicas, pois provavelmente você ficará com ele por muitos e muitos anos.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.