A distinção de camada OSI que continua importando
O conceito de balanceamento de carga é simples: distribuir requisições recebidas entre várias instâncias de serviço para que nenhum servidor fique sobrecarregado e a aplicação permaneça disponível. O interessante é como você toma essa decisão de distribuição. A divisão mais consequente está entre Layer 4 e Layer 7.
Layer 4 Load Balancing opera na camada de transporte do modelo OSI — TCP e UDP. O balanceador vê o IP de origem, IP de destino e portas de uma conexão; nada mais. Toma sua decisão de distribuição com base nesses campos de cabeçalho e então passa os bytes sem inspecionar o payload. O protocolo de aplicação pode ser HTTP, MySQL, Kafka ou um protocolo binário customizado — o balanceador não sabe e não se importa.
Layer 7 Load Balancing opera na camada de aplicação — HTTP, HTTPS, gRPC, WebSocket. O balanceador analisa cada requisição, lê o caminho URL, cabeçalhos, cookies e método, e toma decisões de roteamento baseadas nesse conteúdo. Pode também transformar requisições em trânsito: compressão, reescrita de cabeçalhos, terminação TLS, cache.
Layer 7 é mais poderoso que Layer 4 e mais caro que Layer 4. A escolha entre os dois depende de se o protocolo de aplicação tem forma HTTP e se as capacidades extras valem o custo por conexão.
Quando Layer 4 é a escolha certa
Cenários onde L4 é a resposta certa compartilham uma propriedade: analisar o conteúdo da aplicação é desnecessário ou não cabe no orçamento.
Protocolos não-HTTP são o exemplo mais claro da categoria. Para bancos de dados (MySQL, PostgreSQL), filas de mensagens (Kafka, RabbitMQ), e-mail (SMTP) e serviços TCP customizados, o balanceador não precisa entender o conteúdo da aplicação — distribuição por porta e taxa de conexão funciona bem.
Requisitos de desempenho puro também apontam para L4. A sobrecarga por conexão de L4 é a mais baixa porque não há análise de aplicação. Para serviços TCP de alto volume onde cada microssegundo importa — plataformas de trading sensíveis a latência, backends de jogos em tempo real, workloads similares — L4 é a ferramenta certa.
Criptografia ponta a ponta é outro caso L4. Quando TLS deve terminar na aplicação em vez do balanceador — mandato regulatório, isolamento multi-tenant, chaves controladas pelo cliente — L4 passa TLS de forma transparente. O balanceador nunca vê o texto plano.
Por fim, se lógica de distribuição simples é suficiente, L4 roda com menos sobrecarga operacional. Se round-robin, hash de IP de origem ou least-connections bastam e roteamento baseado em URL não é necessário, L4 é mais leve e mais fácil de raciocinar.
Quando Layer 7 é a escolha certa
O que distingue L7 é sua capacidade de tomar decisões de roteamento e transformação baseadas no conteúdo da aplicação. Sem essa capacidade, a maioria das aplicações web modernas não funcionaria.
O roteamento baseado em URL é o caso mais comum. Enviar caminhos diferentes para clusters de serviço diferentes — /api/v1/users para um cluster, /api/v1/orders para outro, /static/* para uma CDN — não é possível com L4 porque L4 não vê os caminhos.
Roteamento baseado em cabeçalho ou cookie também requer L7. Testes A/B, fixação de versão (X-Service-Version: 2.5 roteia para uma implantação específica), afinidade de sessão por ID de sessão de aplicação e roteamento por cliente via cabeçalho — todos exigem ler o conteúdo da aplicação.
Terminação TLS também é trabalho L7. SSL offload termina TLS no balanceador, liberando os serviços do trabalho criptográfico; permite gerenciamento centralizado de certificados; permite inspeção WAF. A WAF precisa de texto plano para ver ataques; isso não acontece sem L7.
Recursos cientes da aplicação — compressão, cache, reescrita de requisição, health checks baseados em conteúdo (o serviço retorna 200 em /health, não apenas aceita uma conexão) e degradar HTTP/2 para HTTP/1.1 para serviços legados — também requerem L7.
Observabilidade em nível de aplicação segue a mesma lógica. Latência por endpoint, taxa de erro por URL, detecção de consultas lentas — esses exigem ver requisições, não conexões. L7 expõe esses dados; L4 vê apenas o nível de conexão.
O ponto central é este: se você está decidindo com base no conteúdo da aplicação, L7 é obrigatório. Se decide apenas no nível de conexão, L4 é suficiente.
Comparação direta
| Dimensão | Layer 4 | Layer 7 |
|---|---|---|
| Camada OSI | Transporte (TCP/UDP) | Aplicação (HTTP, HTTPS, gRPC, WebSocket) |
| Entradas de roteamento | IP de origem, IP de destino, portas | URL, cabeçalhos, cookies, método, corpo |
| Tratamento TLS | Pass-through | Terminar ou pass-through |
| Sobrecarga por conexão | A mais baixa | Maior (análise requerida) |
| Algoritmos de distribuição | Round-robin, hash IP origem, least-connections | Todos os algoritmos L4 mais roteamento por conteúdo, peso por URL |
| Integração WAF | Não possível (sem visibilidade de conteúdo) | Nativa |
| Observabilidade | Nível de conexão | Nível de requisição |
| Caso de uso típico | Proxy de banco de dados, jogos, RTMP, SMTP | Aplicações web, APIs, microsserviços |
Implantações modernas usam ambos
A decisão raramente é "L4 ou L7" para uma infraestrutura inteira. É tomada por aplicação — às vezes por listener.
Um padrão empresarial típico combina ambos os modos. L7 na borda para tráfego HTTPS de usuários; L4 para tráfego interno leste-oeste onde o protocolo é nativamente TCP e o orçamento de latência é apertado; L7 novamente onde o tráfego leste-oeste roda sobre RPC em HTTP, como gRPC.
A questão arquitetônica é se uma única implantação de balanceador pode lidar com ambos os modos, ou se a organização deve operar produtos L4 e L7 separados. A abordagem de produtos separados era historicamente comum porque L4 e L7 tinham requisitos de implementação diferentes — L4 queria rede kernel-bypass, L7 queria análise HTTP rica. ADCs modernos fecharam essa lacuna; o mesmo aparelho lida com ambos os modos via configuração por listener.
O benefício operacional de combiná-los é o mesmo de qualquer consolidação: um produto para implantar, uma superfície de observabilidade, um conjunto de runbooks operacionais, um caminho de upgrade. Para organizações que antes operavam produtos L4 e L7 de fornecedores separados, consolidar em um único ADC é frequentemente a maior simplificação operacional disponível.
Como o TR7 Load Balancer lida com ambos os modos
O Load Balancer (LB) do TR7 carrega ambos os modos L4 e L7 no mesmo aparelho via configuração por listener. Uma única implantação pode hospedar estes listeners lado a lado: um listener L7 na 443 lidando com tráfego web HTTPS com WAF e aceleração SSL; um listener L4 na 5432 lidando com conexões PostgreSQL com afinidade por IP origem; outro listener L7 na 8080 lidando com serviços gRPC internos com mTLS. Todos configurados juntos, compartilhando observabilidade e um único ciclo de vida de upgrade.
A aceleração por hardware aplica-se a ambos os modos. As conexões L4 se beneficiam do processamento de pacotes kernel-bypass; as conexões L7 se beneficiam da terminação TLS descarregada e da análise HTTP/2 / HTTP/3. O mesmo aparelho físico pode carregar milhares de serviços TCP L4 concorrentemente com milhares de sessões HTTPS L7; o limite é o envelope de hardware, não uma licença ou feature gate por modo.
Para organizações escolhendo entre fornecedores em 2026, a pergunta "este LB suporta tanto L4 quanto L7?" não é mais um diferenciador; a maioria suporta. Os diferenciadores são a história operacional (um produto ou dois), a história de observabilidade (unificada ou dividida) e a história de modernização (HTTP/3, TLS 1.3, suporte de criptografia pós-quântica). O TR7 se posiciona em torno desses três eixos; a capacidade L4 e L7 é a entrada.
L4 + L7 em uma única plataforma
TR7 Load Balancer carrega os modos L4 e L7 no mesmo aparelho, com aceleração por hardware para ambos. Uma superfície de observabilidade, um caminho de upgrade, ambos os modos disponíveis por listener.
Conheça o TR7 Load Balancer