04 - Softwares
video: https://youtu.be/... no frontmatter da nota.Softwares
1. Definição e Papel na Stack HTTP
Software de protocolo HTTP é o conjunto de aplicações responsáveis por produzir, consumir, intermediar e proteger mensagens HTTP/HTTPS. O ecossistema HTTP é composto por quatro grandes famílias de softwares: servidores (origem), clientes (consumidores), proxies (intermediários) e WAFs (firewall de aplicação). Cada família implementa parcial ou totalmente as RFCs 7230-7235 (HTTP/1.1), RFC 7540 (HTTP/2) e RFC 9114 (HTTP/3).
Classificação Funcional
| Família | Função | Exemplos |
|---|---|---|
| Servidor | Recebe requisição, gera resposta | Apache, Nginx, IIS, Caddy, Lighttpd |
| Cliente | Inicia requisição | curl, wget, browsers, httpie |
| Proxy direto | Cliente → internet | Squid, Privoxy |
| Proxy reverso | Internet → servidor interno | Nginx, HAProxy, Varnish, Traefik |
| WAF | Filtra ataques L7 | ModSecurity, Cloudflare, AWS WAF |
| Cache | Acelera conteúdo estático | Varnish, Squid, Redis (HTTP cache) |
2. Servidores Web
Apache HTTP Server
Criado em 1995 (Rob McCool, NCSA), é o servidor web mais antigo ainda em uso. Sua arquitetura histórica é baseada em processos ou threads (MPM prefork, worker, event). O módulo mod_php permitiu rodar PHP dentro do processo do Apache, modelo dominante nos anos 2000.
- Linguagem: C
- Configuração:
.htaccess(diretórios),httpd.conf(global) - Market share: ~30% dos sites ativos (W3Techs, 2024, em queda)
- Ponto forte: flexibilidade via módulos dinâmicos (mod_rewrite, mod_ssl, mod_security)
- Ponto fraco: overhead por processo/thread em alta concorrência
Nginx
Lançado em 2004 por Igor Sysoev, é um servidor orientado a eventos, com modelo assíncrono single-thread (event loop com workers). Consegue manter dezenas de milhares de conexões simultâneas por processo worker. Tornou-se o servidor web mais usado desde 2019.
- Linguagem: C
- Configuração:
nginx.conf(sem equivalente a.htaccess) - Market share: ~34% dos sites ativos (W3Techs, 2024)
- Ponto forte: alta concorrência, reverse proxy de alta performance, balanceamento L7
- Ponto fraco: sem suporte dinâmico a módulos na edição open-source (exige recompilação)
IIS (Internet Information Services)
Servidor proprietário da Microsoft, integrado ao Windows Server desde NT 4.0 (1996). Executa aplicações ASP.NET nativamente via pipeline integrado. Suporta HTTP/2 e HTTP/3 desde as versões recentes.
- Linguagem: C++ (kernel mode + user mode)
- Configuração:
applicationHost.config(XML), ou via PowerShell (WebAdministration) - Market share: ~10% (predominante em ambientes Windows corporativos)
Caddy
Servidor moderno escrito em Go, lançado em 2015. Destaca-se por provisionar e renovar automaticamente certificados TLS via Let's Encrypt (ACME). Configuração minimalista em Caddyfile.
- Linguagem: Go
- Suporte nativo: HTTP/1.1, HTTP/2, HTTP/3 (QUIC) habilitado por padrão
- Caso de uso: deploys modernos, edge servers, projetos pequenos/médios
Lighttpd
Servidor leve lançado em 2003, otimizado para consumo mínimo de memória. Foi muito usado em embedded systems, roteadores e servidores de baixo desempenho. Implementa FastCGI de forma eficiente.
- Linguagem: C
- Caso de uso típico: dispositivos embarcados, Raspberry Pi, ambientes com restrição de RAM
3. Clientes HTTP
curl
Ferramenta de linha de comando criada por Daniel Stenberg em 1998. Suporta praticamente todos os protocolos de transferência (HTTP, HTTPS, FTP, FTPS, SCP, SFTP, LDAP, DICT, TELNET). É o cliente HTTP mais utilizado em scripts, automações e testes de API.
curl -X PUT https://api.exemplo.com/users/42 \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d '{"name":"Alice","email":"alice@ex.com"}'
wget
Cliente focado em download recursivo e espelhamento de sites. Suporta retomada de download (range requests), conversão de links para visualização offline e mirror de sites inteiros. Mais antigo que curl (1996).
httpie
Cliente moderno (Python) com saída colorida, sintaxe simplificada e JSON nativo. Útil para desenvolvimento e debug de APIs REST.
Browsers (Firefox, Chrome, Safari, Edge)
São os clientes HTTP completos, com renderização HTML/CSS/JS, cache persistente, suporte a cookies, CORS e websockets. A partir de 2023, todos suportam HTTP/3 por padrão.
4. Proxies
Proxy Direto (Forward Proxy)
Recebe requisições de clientes internos e encaminha para a internet. Usado para controle de acesso corporativo, filtragem de conteúdo e cache de banda. Implementação clássica: Squid (proxy direto e reverso, cache HTTP, ACLs).
Proxy Reverso
Recebe requisições da internet e encaminha para servidores internos. Cenário típico: balanceamento de carga, terminação TLS, cache e proteção.
| Software | Tipo | Destaque |
|---|---|---|
| Nginx | Reverso | Alta concorrência, low footprint |
| HAProxy | Reverso/L4 | Balanceamento L4/L7 com health-checks avançados |
| Varnish | Cache reverso | Cache HTTP em RAM, VCL (Varnish Configuration Language) |
| Traefik | Reverso | Nativo para containers (Docker/K8s), auto-discovery |
| Envoy | Reverso | Service mesh (Istio), gRPC, xDS API |
Varnish Cache
Especializado em cache HTTP, armazena respostas em memória RAM. A linguagem VCL permite lógica customizada de cache (ex: não cachear POST, cachear GET por 60s se status 200). Suporta ESI (Edge Side Includes) para montagem de páginas fragmentadas.
HAProxy
Load balancer L4/L7 de alta performance. Capaz de processar milhões de requisições por segundo em hardware moderno. Suporta algoritmos de balanceamento (round-robin, least-conn, source-hash), health checks ativos e passivos, e sticky sessions via cookie.
5. WAF (Web Application Firewall)
WAF opera na camada 7, inspecionando o conteúdo HTTP para identificar ataques que firewalls L3/L4 não detectam. Proteção típica contra OWASP Top 10: SQL Injection, XSS, CSRF, RFI/LFI, Path Traversal.
ModSecurity
Engine open-source mantida pelo Trustwave (agora Corero). Roda como módulo do Apache, Nginx ou IIS. Usa o conjunto de regras OWASP CRS (Core Rule Set), que detecta ataques via assinaturas. A versão 3.x é independente do Apache, com conector para Nginx.
Cloudflare WAF
WAF como serviço, executado na edge da CDN. Combina regras gerenciadas, machine learning e assinaturas. Filtra tráfego antes que chegue ao servidor de origem. Também oferece proteção contra DDoS L7.
AWS WAF / Azure Front Door
WAFs gerenciados em nuvem, integrados a outros serviços (ALB, CloudFront, API Gateway). Configuração via web ACLs com regras gerenciadas pela AWS e regras customizadas.
6. Comparativo de Servidores Web
| Servidor | Modelo | HTTP/3 | Config | Market Share | Licença |
|---|---|---|---|---|---|
| Nginx | Eventos | Parcial | nginx.conf | ~34% | BSD |
| Apache | Processos/Threads | Não | .htaccess/httpd.conf | ~30% | Apache 2.0 |
| IIS | Threads (Windows) | Sim | XML/PowerShell | ~10% | Proprietário |
| Caddy | Eventos (Go) | Sim | Caddyfile | <2% | Apache 2.0 |
| Lighttpd | Eventos | Não | lighttpd.conf | <1% | BSD |
| LiteSpeed | Eventos | Sim | WebAdmin | ~5% | Proprietário |
7. Boas Práticas de Seleção
- Sites estáticos e CDN: Nginx ou Caddy.
- Aplicações PHP legacy: Apache + mod_php, ou Nginx + PHP-FPM.
- Aplicações ASP.NET: IIS no Windows Server, ou Kestrel + YARP no Linux (.NET Core).
- Edge/microservices: Envoy, Traefik ou Caddy com HTTP/3.
- Balanceamento L4 crítico: HAProxy.
- Cache agressivo em RAM: Varnish.
- WAF on-premise: ModSecurity + OWASP CRS.
- WAF gerenciado: Cloudflare, AWS WAF, Imperva.
8. Resumo Técnico
| Atributo | Valor |
|---|---|
| Servidor mais usado | Nginx (~34%) |
| Cliente CLI padrão | curl |
| Proxy reverso mais comum | Nginx |
| Cache em RAM mais usado | Varnish |
| WAF open-source | ModSecurity |
| Protocolo suportado | HTTP/1.1, HTTP/2, HTTP/3 |
| RFCs de referência | 7230-7235, 7540, 9114 |
9. Conclusão
O ecossistema de softwares HTTP é maduro e diversificado. A escolha entre Apache, Nginx, Caddy ou IIS depende do tipo de workload (estático, dinâmico, microservices), do SO e do modelo operacional. Proxies reversos como Nginx, HAProxy e Varnish formam a espinha dorsal da maioria das arquiteturas web modernas, enquanto WAFs protegem a camada de aplicação contra ataques que firewalls tradicionais não conseguem detectar. O engenheiro de redes deve conhecer profundamente ao menos um servidor, um proxy reverso e um WAF, e entender os trade-offs de cada opção.