Servidores Web narrado
direto do paddock.

Etapa 01 mureta + garagem

Para que serve um servidor web

Luzes apagadas! A primeira curva já cobra a decisão que define a corrida inteira: o que fica no colo do piloto e o que vai pra mureta. As melhores equipes ganham GP no box, e uma parada de Red Bull em menos de dois segundos prova que a operação ao redor do piloto decide tanto quanto o carro. Bora entender por quê.

Imagine uma equipe que sobe uma aplicação Node.js e a deixa atendendo direto na porta 3000, sem nada na frente dela. No começo funciona bem, mas o produto cresce e uma série de dores aparece, e nenhuma delas tem a ver com a lógica de negócio: servir arquivos estáticos passa a competir pelo mesmo processo que roda a aplicação, renovar o certificado HTTPS exige mexer no código e reiniciar o processo, distribuir tráfego entre réplicas vira uma decisão manual a cada requisição, e não existe nenhuma camada filtrando bots antes de eles baterem direto na aplicação. Traduzindo pro cockpit: é o piloto que, além de pilotar, teria que gerenciar o próprio rádio criptografado, decidir sozinho a estratégia de stint e ainda barrar quem invade o box. Ninguém corre assim.

Como funciona

Cada um desses problemas é de infraestrutura de borda, não de regra de negócio. Resolver todos dentro do próprio código da aplicação mistura responsabilidades que deveriam estar separadas, e é exatamente esse conjunto de responsabilidades que um servidor web como o Apache HTTP Server ou o Nginx assume.

Analogia: pense na mureta e na garagem da sua equipe. Sem elas, o piloto teria que descobrir sozinho a estratégia, cuidar da própria comunicação segura e ainda vigiar quem entra no box. Com uma operação central, chega tudo num único ponto (a mureta), que decide o que repassar ao piloto, barra quem não tem credencial e cuida das tarefas comuns (rádio, telemetria, cronometragem) sem tirar a concentração de quem está no carro. O servidor web é essa mureta da sua infraestrutura: o ponto por onde toda requisição HTTP entra antes de chegar (ou não) até a sua aplicação.

Um servidor web moderno assume, tipicamente, as seis funções dos cartões abaixo. Vale lembrar que essa peça de software é veterana de guerra: o Apache HTTP Server teve seu primeiro lançamento em 1995, ou seja, mais de 30 anos de pista.

As seis funções de um servidor web moderno

O cabeçalho Server denuncia quem te atende

 # /etc/nginx/conf.d/default.conf
server {
    listen 80;                       # a porta que o Nginx escuta
    server_name localhost;           # o domínio que este bloco atende
 
    location / {
        root /usr/share/nginx/html;  # a pasta onde estão os arquivos estáticos
        index index.html;           # arquivo servido quando a URL termina em "/"
    }
}

Comandos essenciais desta etapa

Mão na massa

Dois containers no ar, um curl pra ler o cabeçalho Server, e você já sente a mureta respondendo antes do piloto entrar no carro. Sem pressa de bater tempo nessa: é volta de reconhecimento de traçado.

1. Suba um container Nginx (docker run -d -p 8080:80 nginx:latest) e um container Apache (docker run -d -p 8081:80 httpd:latest).
2. Rode curl -I http://localhost:8080 e curl -I http://localhost:8081. Observe o cabeçalho Server de cada um: são dois softwares diferentes respondendo pela mesma tarefa. Dois fornecedores de mureta diferentes fazendo o mesmo trabalho.
3. Peça um caminho que não existe em cada um (curl -I http://localhost:8080/nao-existe) e observe o 404 Not Found. Essa resposta veio do servidor web, sem nenhuma aplicação ter sido acionada: a mureta barrou o pedido na entrada, o piloto nem soube que existiu.

Ficou claro: a mureta existe pra você só pilotar. Agora o traçado abre pra reta mais longa do circuito, a evolução do protocolo de rádio entre carro e box. Etapa 02, e é sobre ganhar milissegundos na comunicação.

Etapa 02 reta da evolução HTTP

HTTP e sua evolução, de 1.1 a QUIC/HTTP-3

Aqui a briga é por milissegundos na conversa entre carro e mureta, e três gerações de protocolo disputam o mesmo asfalto. Lembra de Mansell colado em Senna nas voltas finais de Mônaco 1992, mais rápido e sem conseguir passar? Head-of-line blocking é exatamente isso: o veloz travado atrás de quem foi na frente.

Duas cenas explicam por que o HTTP precisou evoluir, pensadas como duas falhas de comunicação entre carro e mureta. Cena 1: uma página de e-commerce carrega o HTML principal e mais 40 miniaturas de imagem; mesmo com conexões persistentes (keep-alive), o HTTP/1.1 processa uma requisição de cada vez dentro daquela conexão, então a segunda imagem só começa a baixar depois que a primeira chega por completo. É um rádio só: enquanto o engenheiro despeja uma transmissão longa, todos os outros recados esperam na fila. Cena 2: mesmo resolvida a cena 1, um usuário numa rede móvel instável ainda sente lentidão, porque basta um único pacote se perder no meio do caminho pra o carregamento inteiro travar até a retransmissão chegar, mesmo que o resto já tenha chegado. É o carro entrando no túnel de Mônaco: perde uma palavra do rádio e a mensagem inteira congela até repetir, mesmo que o resto já tivesse sido recebido.

Como funciona

Antes das versões, um fato estrutural do próprio HTTP: ele é um protocolo sem estado (stateless). Cada requisição é tratada de forma completamente independente, sem memória de requisições anteriores, como uma chamada de rádio isolada, que não carrega lembrança das chamadas anteriores. Isso torna o protocolo mais simples de escalar, mas exige mecanismos por cima dele (cookies, sessões) pra simular contexto entre requisições de um mesmo usuário. Na mureta, esse contexto vive no pit board e na telemetria acumulada, não na chamada de rádio em si.

HTTP/1.1, a versão clássica (1997): introduziu conexões persistentes (keep-alive), permitindo várias requisições e respostas na mesma conexão TCP, o que reduziu bastante a sobrecarga de abrir conexão nova a cada recurso. A limitação é o head-of-line blocking: se a primeira requisição demora, todas as seguintes, naquela mesma conexão, ficam esperando. Canal aberto, sim, mas uma transmissão por vez, e a longa segura a fila.

HTTP/2, a multiplexação (2015): resolve o head-of-line blocking da cena 1, na camada de aplicação, várias requisições e respostas trafegam simultaneamente pela mesma conexão TCP, sem uma bloquear a outra. É a telemetria moderna de um carro de 2026, que despeja dezenas de canais ao mesmo tempo pelo mesmo link (pressão de pneu, deploy de ERS, modo de asa ativa) sem que um canal segure o outro. Além disso trouxe priorização de recursos, compressão de cabeçalhos via HPACK e o Server Push (recurso que fez parte da especificação original, mas caiu em desuso: os principais navegadores removeram ou restringiram o suporte a ele desde 2022, porque o ganho raramente compensava a complexidade de usá-lo direito).

HTTP/3, QUIC sobre UDP: o HTTP/2 resolveu o head-of-line blocking na aplicação, mas o problema da cena 2 continua numa camada abaixo, o TCP garante que os bytes cheguem em ordem estrita, então, se um pacote se perde, tudo que veio depois dele espera pela retransmissão, mesmo pertencendo a um stream diferente do que travou. O HTTP/3 ataca isso trocando o TCP pelo QUIC (Quick UDP Internet Connections), que roda sobre UDP: cada stream é independente, e a perda de um pacote de um stream não trava os demais. É como ter cada canal de telemetria imune ao ruído dos outros: se a leitura de temperatura de freio some por um instante no túnel, o canal de GPS nem percebe. O ganho é maior em redes com perda de pacotes ou latência alta, o cenário típico de conexões móveis, ou seja, o carro nos trechos mais distantes e ruidosos de uma pista longa como Spa.

As três gerações, lado a lado

Perguntando ao próprio curl qual versão foi negociada

# Deixa o curl negociar livremente e mostra a versão usada na resposta
$ curl -so /dev/null -w 'Protocolo negociado: HTTP/%{http_version}\n' https://www.cloudflare.com
Protocolo negociado: HTTP/2
 
# Força HTTP/1.1, mesmo que o servidor suporte versões mais novas
$ curl --http1.1 -so /dev/null -w 'Protocolo negociado: HTTP/%{http_version}\n' https://www.cloudflare.com
Protocolo negociado: HTTP/1.1
 
# Força HTTP/3 (exige um curl compilado com suporte a QUIC)
$ curl --http3 -so /dev/null -w 'Protocolo negociado: HTTP/%{http_version}\n' https://www.cloudflare.com
Protocolo negociado: HTTP/3

Comandos essenciais desta etapa

Mão na massa

Três comandos curl, três versões de protocolo negociadas na sua frente. Cronometre o %{time_total} de cada uma e sinta na mão a diferença que cada geração trouxe. Essa aqui é volta de classificação.

1. Escolha um domínio que suporte HTTP/2 (por exemplo, www.cloudflare.com ou www.google.com) e rode os três comandos do exemplo acima. Observe o valor de %{http_version} mudando conforme a flag usada.
2. Rode curl -v --http2 https://www.cloudflare.com 2>&1 | grep -i "HTTP/2" e ache, no meio da saída detalhada, a linha que confirma a negociação da versão durante o handshake. É o aperto de mão do rádio antes da primeira transmissão de verdade.
3. Se o seu curl tiver suporte a HTTP/3, repita com --http3 e compare o tempo de resposta com -w "%{time_total}\n" nas três variantes.

Você viu o rádio limpar a fila e a telemetria ficar imune ao ruído. Agora o circuito estica pra um chicane técnico: dois intermediários que parecem gêmeos e fazem trabalhos opostos. Etapa 03, atenção na freada.

Etapa 03 chicane dos proxies

Forward Proxy e Reverse Proxy, os dois intermediários da web

Cuidado com essa sequência: forward proxy e reverse proxy são gêmeos que correm em direções opostas. Errar qual é qual aqui é perder o carro na zebra. Foco total nas próximas curvas.

Duas cenas simétricas, uma do lado do cliente e outra do lado do servidor. Pense num carro que precisa falar com o mundo (saída) e num box que precisa receber o mundo (entrada). Cena A: uma empresa quer que todo o tráfego de saída dos funcionários passe por um ponto de controle único, pra bloquear sites indesejados, registrar acessos por conformidade e evitar que o IP interno de cada máquina fique exposto direto pra internet. Cena B: a mesma empresa mantém cinco servidores de aplicação atrás de um único domínio público, e não faz sentido expor o IP de cada servidor individualmente, repetir a configuração do certificado TLS em cada um deles, nem deixar cada servidor decidir sozinho se aguenta receber mais uma conexão simultânea. Duas necessidades diferentes, mas com uma peça em comum: um intermediário entre quem pede e quem responde. A diferença está em qual lado esse intermediário representa e protege.

Como funciona

Forward Proxy, o intermediário de saída: fica posicionado entre um cliente (geralmente dentro de uma rede privada) e a internet, e é explicitamente configurado no lado do cliente (no navegador, no sistema operacional ou na aplicação). Analogia: é o empresário do piloto. O piloto não vai pessoalmente negociar com patrocinador ou responder à imprensa, fala com o empresário, que decide o que sai, negocia em nome dele e traz o resultado de volta. O patrocinador do outro lado nem sabe que a fala partiu do piloto, só enxerga o empresário. O piloto contratou aquele intermediário de propósito, exatamente como o cliente configura o forward proxy. Casos de uso: segurança e conformidade (forçar o tráfego por firewalls), controle de conteúdo (bloquear sites), anonimato e privacidade (mascarar o IP real do cliente) e cache (guardar respostas frequentes, economizando banda).

Reverse Proxy, o guardião inteligente da entrada: fica na borda da infraestrutura, recebendo requisições da internet e distribuindo-as para os servidores de aplicação por trás dele. É transparente para o cliente, ele nem sabe que existe. Analogia: é literalmente a mureta da Etapa 01, vista de outro ângulo, agora formalizada especificamente pra quando ela existe pra proteger e organizar o que está atrás dela. Pense na mureta da Ferrari recebendo todo o tráfego de fora e decidindo, pedido a pedido, se aquilo é assunto do carro do Hamilton ou do carro do Leclerc, já com respostas prontas pro que é rotina e barrando quem não deveria chegar perto dos carros. Funções principais: balanceamento de carga entre múltiplos backends, terminação de SSL/TLS centralizada (tirando essa carga de CPU dos backends), cache de conteúdo, uma primeira camada de segurança contra tráfego malicioso (bloquear ataques específicos como XSS normalmente exige regras adicionais de WAF, e não apenas o proxy puro), compressão (Gzip/Brotli) e roteamento inteligente entre diferentes serviços.

Resumindo no jargão do paddock: forward proxy é o empresário falando pelo piloto na saída, reverse proxy é a mureta recebendo o mundo na entrada. Mesmo tipo de intermediário, direções opostas.

Os dois lados do mesmo mecanismo

Um reverse proxy Nginx na frente de um backend simples

 # /etc/nginx/conf.d/proxy.conf
upstream backend_app {
    server 127.0.0.1:8000;         # o servidor de aplicação real, atrás do proxy
}
 
server {
    listen 80;
    server_name localhost;
 
    location / {
        proxy_pass http://backend_app;                    # encaminha a requisição pro backend
        proxy_set_header Host $host;                       # preserva o Host original do cliente
        proxy_set_header X-Real-IP $remote_addr;           # informa ao backend o IP real do cliente
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # cadeia de IPs, se houver mais de um proxy
    }
}

Comandos essenciais desta etapa

Mão na massa

Sobe o backend Python, configura o Nginx na frente, dá o reload e confere o cabeçalho Server com um curl: cada passo é um pneu trocado, faça na ordem e o carro sai do box limpo. Aviso de garagem: este exercício edita a configuração real do Nginx e recarrega o processo com nginx -s reload, então use um Nginx instalado no host (sudo apt install nginx), não o container nginx:latest da Etapa 01. Se preferir continuar no Docker, veja a adaptação sugerida na abertura do guia.

1. Suba o backend Python (python3 -m http.server 8000, numa pasta com um index.html qualquer) e configure o Nginx como no exemplo acima. Recarregue com nginx -s reload.
2. Rode curl -I http://localhost e observe o cabeçalho Server: nginx, mesmo com o conteúdo vindo do processo Python. A mureta na frente, o carro atrás.
3. Remova temporariamente a linha proxy_set_header X-Real-IP, recarregue, e raciocine sobre o que o backend passaria a enxergar: sem esse cabeçalho, ele só veria o IP do próprio Nginx.
4. Compare com o comando curl -x do forward proxy: repare que ali é você quem aponta explicitamente pro intermediário; no passo 2, você nem sabia que ele existia.

Empresário na saída, mureta na entrada: você não erra mais qual é qual. Agora vem a zona de frenagem mais pesada da pista, onde a estratégia de garagem do Apache decide quem sobrevive ao pico. Etapa 04.

Etapa 04 frenagem dos MPMs

Apache HTTP Server e os modelos de processamento (MPMs)

Aqui a pista cobra estratégia de garagem: como escalar seus mecânicos pra aguentar 5.000 carros querendo o box ao mesmo tempo. Escolher errado aqui custa caro. Pergunta pra Ferrari de Abu Dhabi 2010, que jogou um campeonato fora com a chamada de box errada no momento errado.

Cenário 1: um e-commerce rodando Apache com o modelo mais antigo de processamento recebe um pico de 5.000 conexões simultâneas numa promoção. Como cada conexão ganha um processo do sistema operacional inteiramente próprio e isolado, o servidor tenta abrir milhares de processos, cada um consumindo dezenas de megabytes só pra existir, antes mesmo de processar qualquer requisição. A memória se esgota, o sistema começa a paginar em disco, e o site trava justamente no pico de vendas. É a janela de pit stop sob safety car: os 22 carros querem entrar no box ao mesmo tempo, e se você exigisse uma equipe inteira e separada por carro, não haveria espaço nem gente no pit lane pra todos. Cenário 2, oposto: a mesma empresa depende de um módulo antigo, escrito sem cuidado de concorrência (não thread-safe), que precisa continuar funcionando. Trocar o modelo de processamento pra um baseado em threads compartilhando memória faria esse módulo corromper dados ou derrubar o processo de forma imprevisível. É aquela ferramenta legada de calibração que só funciona numa bancada isolada: numa bancada compartilhada, ela bagunça o trabalho de todos os outros mecânicos. Um cenário pede leveza pra escalar, o outro pede isolamento total pra sobreviver. O Apache resolve essa tensão deixando você escolher o modelo de concorrência, os MPMs (Multi-Processing Modules).

Como funciona

Analogia geral: pense na garagem e no jeito de escalar os mecânicos. Nesta etapa, uma conexão é um carro que chega pra ser atendido, um processo é um box independente com ferramentas e espaço próprios, e uma thread é um mecânico dentro daquele box compartilhando a mesma bancada.

Prefork MPM (não threaded): um processo filho independente é criado para cada conexão, completamente isolado dos demais. Vantagens: muito estável (um problema num processo não afeta os outros), ideal para módulos não thread-safe, alta compatibilidade com software legado. Desvantagens: alto consumo de memória e pouca escalabilidade sob alta concorrência. É comum ver o Prefork combinado com o mod_php (PHP embutido no processo do Apache, historicamente não thread-safe); a alternativa moderna é rodar o PHP como processo separado via PHP-FPM, com o Apache falando com ele por proxy, o que permite usar um MPM mais leve sem perder compatibilidade.

Worker MPM (multithreaded): cria múltiplos processos filhos, cada um rodando múltiplas threads, e cada thread atende uma conexão. Mais eficiente em memória que o Prefork e com melhor performance sob alta concorrência, mas como as threads de um mesmo processo compartilham memória, um erro grave numa thread pode corromper o processo filho inteiro que a hospeda, derrubando as conexões que aquele processo específico estava servindo (os demais processos e o processo mestre continuam de pé). É o mecânico que derruba a bancada e prejudica só a equipe daquele box; os outros boxes e o chefe de equipe seguem trabalhando. Por isso os módulos precisam ser thread-safe.

Event MPM (recomendado para produção): parte do modelo Worker, mas otimizado pro caso comum de conexões keep-alive abertas e ociosas, uma thread dedicada consegue vigiar várias conexões que estão só esperando, sem prender uma thread inteira de trabalho só pra segurar uma conexão parada. É o mecânico que não fica plantado ao lado de um carro que só está aguardando ordem, ele vigia vários carros em espera de uma vez e só age quando um deles de fato precisa. Eficiente para keep-alive, otimizado para alta concorrência e com suporte nativo a HTTP/2, mas exige módulos thread-safe e é mais complexo de configurar.

Os três MPMs lado a lado

Descobrindo e trocando o MPM ativo

# Mostra qual MPM está compilado/ativo no momento (saída resumida)
$ apachectl -V | grep -i mpm
Server MPM:     event
 
# Em distros Debian/Ubuntu, a2query mostra o módulo MPM habilitado
$ sudo a2query -M
event

Comandos essenciais desta etapa

Mão na massa

Descubra o MPM ativo, troque, e rode o Apache Bench antes e depois: a mesma máquina parando em 2 segundos ou em 4 só pela forma de escalar a equipe. Aviso de garagem: este exercício usa a2enmod/a2dismod e apachectl, comandos que atuam sobre um Apache instalado no host (sudo apt install apache2), não sobre o container httpd:latest da Etapa 01. O passo 3 também usa o ab: se não estiver instalado, rode sudo apt install apache2-utils antes de executá-lo.

1. Rode apachectl -V | grep -i mpm (ou httpd -V | grep -i mpm, dependendo da distro) no seu Apache e anote qual MPM está ativo agora.
2. Se o seu sistema usa Debian/Ubuntu, troque o MPM ativo com a2dismod/a2enmod e confirme a troca com a2query -M.
3. Rode um teste de carga simples contra o mesmo Apache, antes e depois da troca de MPM: ab -n 500 -c 50 http://localhost/. Compare as linhas Requests per second e Time per request entre as duas rodadas. Não espere um número mágico: o objetivo é sentir que a mesma máquina se comporta diferente só por causa do MPM escolhido, a mesma sensação de um pit stop que sai em 2 segundos ou em 4 dependendo de como a equipe foi escalada.

Box isolado por carro, bancada compartilhada por equipe, ou mecânico vigiando vários carros em espera: você já escolhe o formato da garagem conforme a corrida. Falta só a curva rápida final, onde o Nginx mostra por que nasceu pra essa era. Etapa 05.

Etapa 05 curva rápida do event loop

Nginx e a arquitetura orientada a eventos

Última parcial da volta, e é aqui que o chassi mais enxuto do grid brilha. O Nginx segue a regra de ouro dos projetistas de F1: primeiro simplifica, depois tira todo peso que não precisa estar ali. Vamos ver esse carro na sua melhor curva.

Cenário: uma aplicação com muitas conexões simultâneas de longa duração e majoritariamente ociosas (chat em tempo real, notificações push, keep-alive de APIs de aplicativos móveis). Mesmo com o Event MPM do Apache reduzindo o custo das conexões ociosas, o modelo continua fundamentado em reservar uma thread para cada conexão sendo ativamente processada. Escalar pra dezenas de milhares de conexões simultâneas significa escalar, na mesma proporção, a quantidade de threads e a memória que elas consomem, até esbarrar no limite prático de threads que conseguem coexistir com eficiência. Imagine querer um engenheiro dedicado por carro pra monitorar dezenas de milhares de carros ao mesmo tempo: não existe pit wall que comporte isso. Foi exatamente esse problema que o Nginx nasceu, do zero, pra resolver. Enquanto o Apache nasceu como servidor web tradicional e foi ganhando modelos de concorrência ao longo do tempo, o Nginx já foi concebido com uma arquitetura moderna em mente, pensada especialmente pra servir conteúdo estático e atuar como proxy reverso sob alta concorrência.

Como funciona

A diferença central do Nginx é a arquitetura assíncrona orientada a eventos (event-driven), bem diferente do modelo de thread ou processo dedicado por conexão. Analogia: pense num engenheiro de pista no telemetry wall, o painel gigante com a telemetria de todos os carros ao mesmo tempo. Ele não fica plantado olhando fixo pra um único carro esperando algo acontecer. Ele varre o painel inteiro e só age quando um evento dispara: um alerta de temperatura de pneu no carro do Russell, um pedido de undercut no carro do Antonelli. Um único engenheiro consegue monitorar a grade inteira assim, porque nunca fica bloqueado esperando um carro só.

No Apache, cada conexão ativa costuma ocupar uma thread ou processo dedicado enquanto durar (mesmo o Event MPM reserva uma thread só pra requisição sendo efetivamente processada, ele só evita gastar uma thread inteira em conexões apenas ociosas). Com 10 mil usuários conectados ao mesmo tempo, é preciso sustentar uma fração relevante de 10 mil threads ou processos consumindo memória. Seria como querer um engenheiro por carro pra uma grade de dez mil carros.

No Nginx, non-blocking I/O: quando uma operação de entrada/saída é necessária (ler do disco, esperar resposta de um backend), o worker registra um evento e passa a processar outra conexão, em vez de ficar parado esperando. O engenheiro registra "me avisa quando o dado do carro X chegar" e já vai cuidar do carro Y. O event loop é o loop de eventos que cada processo worker roda, gerenciando milhares de conexões com poucos recursos, a varredura contínua do telemetry wall. Quando o evento fica pronto, o worker é notificado e retoma exatamente de onde parou: o alerta pisca no painel, o engenheiro reage naquele carro e volta a varrer o resto.

Essa abordagem torna o Nginx muito eficiente, especialmente para conexões keep-alive e ociosas, exatamente o cenário do problema desta etapa. Benefícios práticos: menor consumo de memória, maior throughput, melhor latência e desempenho excelente como proxy reverso e balanceador de carga, inclusive na frente do próprio Apache.

Um cuidado, pra não vender ilusão: no telemetry wall real, um engenheiro humano tem limite de atenção e se perde com carros demais. O worker do Nginx não se cansa, ele processa cada evento em microssegundos e volta ao loop, e o gargalo passa a ser CPU e memória, não atenção. A imagem do engenheiro serve pra entender a lógica do event loop, não pra dizer que existe um humano ali dentro.

As peças do motor event-driven

Poucos processos, milhares de conexões

 # /etc/nginx/nginx.conf (trecho principal)
worker_processes auto;   # 1 processo worker por núcleo de CPU disponível
 
events {
    worker_connections 1024;   # cada worker aguenta até 1024 conexões simultâneas
    use epoll;                 # mecanismo de notificação de eventos do kernel Linux
}

Comandos essenciais desta etapa

Mão na massa

Conte os processos com ps aux, jogue carga com o ab e observe: o número de engenheiros no muro não muda, chegue quanto carro chegar. Aviso de garagem: assim como na Etapa 03, este exercício lê a configuração e observa processos de um Nginx instalado no host, não do container nginx:latest da Etapa 01. O passo 3 volta a usar o ab: instale com sudo apt install apache2-utils se ainda não tiver feito isso na Etapa 04.

1. Localize o nginx.conf do seu Nginx (nginx -t mostra o caminho no início da saída) e identifique as diretivas worker_processes e worker_connections.
2. Rode ps aux | grep '[n]ginx' e conte quantos processos aparecem. Compare com nproc (número de núcleos da sua máquina): o número de workers costuma ser igual ou próximo. Tantos engenheiros quanto núcleos disponíveis.
3. Gere carga com múltiplas conexões simultâneas: ab -n 1000 -c 200 http://localhost/. Durante o teste, rode ps aux | grep '[n]ginx' num segundo terminal. Observe: o número de processos não muda, mesmo com centenas de conexões simultâneas batendo no servidor. Os mesmos engenheiros no muro, chegando mais carro ou não.
4. Se tiver acesso a um Apache no mesmo tipo de teste, repita a carga nele e rode ps aux | grep '[a]pache2\|[h]ttpd'. Dependendo do MPM configurado, observe o número de processos ou threads crescer junto com a carga, ao contrário do que aconteceu com o Nginx. Ali a garagem contrata mecânico conforme o movimento, aqui o muro segue com a mesma equipe.

Poucos processos, um loop de eventos, e o Nginx dominando a borda de qualquer coisa, inclusive do próprio Apache. Você cruzou o traçado inteiro, do conteúdo estático ao event loop. Guarda o pit board, revisa o debrief com calma, e até a próxima corrida do campeonato.