No gerenciamento de tráfego empresarial, serviços HTTP, TCP e Layer4 não são a mesma coisa. Para tráfego HTTP, headers, cookies, paths, pontuações WAAP e regras de conteúdo são relevantes. Para TCP, o gerenciamento de conexões, terminação SSL e SNI dominam. Na Layer4, protocolo em nível de kernel, algoritmo e comportamento de persistência são o que impulsiona as decisões. Se essas diferenças não forem modeladas explicitamente, os operadores encontram configurações que não podem funcionar em seu contexto atual.
Em abordagens tradicionais, o tipo de serviço frequentemente fica espalhado entre objetos, perfis, telas ou blocos de configuração manual separados. Os operadores precisam memorizar quais funcionalidades se aplicam a cada tipo de tráfego. Uma regra de header no lugar errado, uma configuração WAAP no serviço errado ou uma expectativa de Camada 7 em um fluxo Layer4 — tudo se traduz em erros em tempo de execução e tempo desperdiçado.
Um segundo problema é gerenciar múltiplos grupos de backend sob um único serviço. Enviar requisições de leitura e escrita para destinos diferentes, separar tráfego mobile e desktop, ou executar grupos de serviço regionais sob um único ponto de entrada é tratado como uma funcionalidade separada na maioria das plataformas — adicionando peso conceitual ao que deveria ser um requisito de roteamento direto.
A abordagem correta é declarar o tipo de serviço explicitamente dentro de um único objeto de pool e fazer a matriz de funcionalidades se filtrar automaticamente. Múltiplos grupos de backend devem ser suportados sob o mesmo pool, enquanto os operadores veem apenas as opções relevantes sem serem sobrecarregados por detalhes técnicos desnecessários.
O modelo de Três Tipos de Serviço do TR7 reduz essa complexidade: o tipo de serviço é escolhido no início, as funcionalidades apropriadas aparecem automaticamente e os grupos de backend são gerenciados dentro do mesmo modelo de configuração.
O TR7 torna o tipo de serviço o switch central da configuração e organiza toda a visibilidade de funcionalidades em torno dessa escolha arquitetural.
O operador cria um pool escolhendo HTTP, TCP ou Layer4. Essa única seleção determina quais ações, verificações de integridade e funcionalidades de tráfego estarão disponíveis a partir desse ponto.
A matriz central de funcionalidades define quais ações são válidas para cada tipo de serviço. A interface exibe apenas as configurações que fazem sentido para o tipo de pool selecionado; opções tecnicamente inválidas nunca aparecem para o operador.
Todo pool começa com um grupo de backend padrão, e grupos adicionais podem ser adicionados conforme necessário. O tráfego é roteado para o grupo relevante por meio de lógica de ACL e regras.
O tipo de serviço é a decisão arquitetural que afeta toda a matriz de funcionalidades do pool. Em vez de converter um pool existente para um tipo diferente, o caminho recomendado é criar um novo pool e realizar uma migração controlada.
O modelo de Três Tipos de Serviço entrega as capacidades certas no lugar certo para tráfego HTTP, TCP e Layer4.
O tipo HTTP é usado para comportamento de proxy completo de Camada 7. WAAP, regras conscientes de conteúdo, manipulação de headers e cookies, redirect, captcha, cache de resposta, compressão e integração com AAM são significativos nesse tipo. Opções ALPN h2 e http/1.1 podem ser incluídas no comportamento do serviço HTTP. HTTP é a escolha certa quando são necessárias tomadas de decisão detalhadas, transformação e política de segurança para tráfego de aplicações e APIs.
O tipo TCP é usado para serviços que precisam de terminação ou passthrough de SSL sobre um fluxo de conexão de Camada 4. Roteamento baseado em SNI, inspeção de TLS hello e gerenciamento de conexões TCP são proeminentes aqui. Necessidades de persistência específicas de TCP, como persistência de cookie RDP, podem ser atendidas nesse tipo. Funções de protocolo como MQTT e FIX também podem fortalecer a lógica de decisão no nível TCP.
O tipo Layer4 é usado para o modelo de distribuição de alto desempenho que opera no nível de kernel. Algoritmos IPVS, modos NAT, DR e TUN podem ser aplicados a fluxos TCP, UDP ou agnósticos de protocolo. Nenhuma inspeção de Camada 7 é realizada nesse tipo; as decisões são baseadas em IP, porta, protocolo e lógica de persistência. Esta é a arquitetura certa para DNS, telecom ou serviços puros de Camada 4 onde baixa latência é essencial.
Todo pool tem pelo menos um grupo de backend padrão. Esse grupo carrega o conjunto de destinos primário do serviço e o algoritmo de balanceamento de carga. Quando nenhuma regra de roteamento adicional é escrita, o tráfego é encaminhado para esse grupo padrão. O modelo mantém serviços simples diretos enquanto permite expansão para cenários avançados.
Grupos como `be-mobile`, `be-desktop`, `be-eu`, `be-us`, `be-readonly` ou `be-writes` podem ser criados sob um único pool. Cada grupo pode ter seu próprio conjunto de destinos, perfil de verificação de integridade e comportamento de tráfego. Condições de ACL e regras direcionam requisições para o grupo apropriado. Isso torna uma arquitetura multi-destino gerenciável sob um único ponto de entrada.
As regras podem ser aplicadas apenas no grupo de backend, em ambos os lados de frontend e grupo, ou em um grupo nomeado específico. Esse modelo de segmentação torna o escopo de cada regra explícito. Por exemplo, uma transformação de header, comportamento de integridade ou condição de roteamento pode ser definida exclusivamente para um grupo. O operador separa diferentes fatias de tráfego dentro do mesmo serviço de forma controlada.
CORS, criptografia de cookie, adicionar header, deletar header, reescrita de path, normalização de URI e autorização são ações exclusivas de HTTP. Gerenciamento de conexões TCP e opções de persistência específicas de TCP aparecem apenas no tipo TCP. Ações como silent log, regra manual, tabela de quarentena, deny e mascaramento de IP podem ser usadas em múltiplos tipos. Como a interface aplica essa separação automaticamente, os operadores nunca enfrentam a ação errada no tipo de serviço errado.
Contagem máxima de conexões e limites de taxa de conexão podem ser definidos no nível do pool. Limites superiores individuais de conexão também podem ser aplicados por destino de backend. Esse modelo ajuda a proteger tanto o serviço geral quanto os destinos individuais sob tráfego intenso. As configurações de capacidade são planejadas de acordo com o tipo de serviço, comportamento de tráfego e recursos de hardware.
O modelo de Três Tipos de Serviço é considerado junto com restrições de mudança de tipo, geração de configuração, monitoramento de integridade, caminhos de estatísticas e comportamento de auditoria.
O tipo de serviço não pode ser alterado após a criação como uma configuração simples. Os tipos HTTP, TCP e Layer4 exigem cada um uma matriz de funcionalidades diferente, caminho de processamento diferente e geração de configuração diferente. Quando uma mudança de tipo é necessária, a abordagem correta é criar um novo pool e realizar uma migração controlada.
Se um ACL em uma regra de grupo de backend é definido no lado do frontend ou no lado do grupo depende do destino pretendido. Essa distinção esclarece em qual estágio do processamento de tráfego a regra se aplica. Ela evita que condições colocadas no lugar errado perturbem o comportamento do serviço.
Cada grupo de backend é emitido como um bloco de configuração separado. O grupo padrão é definido separadamente dos grupos adicionais, e as regras são vinculadas aos seus respectivos destinos. Essa estrutura beneficia tanto a legibilidade da configuração quanto os cenários de rollback.
Quando a configuração apropriada é habilitada no tipo HTTP, as opções ALPN h2 e http/1.1 podem ser usadas em conexões do lado do servidor. Essa configuração só é significativa em um contexto de serviço HTTP. O comportamento HTTP de Camada 7 não deve ser esperado de tipos TCP ou Layer4.
No tipo TCP, uma decisão de roteamento pode ser tomada inspecionando o campo SNI na mensagem TLS hello. Isso é usado para separar serviços TLS para destinos diferentes sem realizar o parsing completo de HTTP. As decisões baseadas em SNI devem ser planejadas cuidadosamente dependendo dos requisitos de passthrough versus terminação.
No tipo Layer4, as estatísticas vêm dos mecanismos de distribuição em nível de kernel, e não do caminho de proxy de Camada 7. Comportamento idêntico ao das estatísticas de proxy HTTP ou TCP não deve ser assumido. Os operadores que monitoram serviços Layer4 devem usar a fonte de estatísticas apropriada.
Equipes de SaaS podem gerenciar tráfego de API sob visibilidade completa de Camada 7 usando o tipo HTTP. WAAP, validação JWT, regras conscientes de conteúdo e roteamento baseado em path são aplicados dentro do mesmo modelo de serviço.
Equipes corporativas podem gerenciar serviços orientados a conexão que exigem terminação SSL, passthrough ou persistência por IP de origem usando o tipo TCP. Serviços que não precisam de funcionalidades HTTP de Camada 7 são servidos com um modelo mais simples.
Equipes de telecom e infraestrutura podem distribuir tráfego UDP no nível de kernel usando o tipo Layer4. Algoritmos IPVS e opções de persistência habilitam entrega de serviço de baixa latência e focada em protocolo.
Equipes de e-commerce podem criar grupos como `be-variant-a` e `be-variant-b` sob o mesmo serviço HTTP. Condições baseadas em ACL ou hash direcionam o tráfego para experiências diferentes de forma controlada.
Gerencie tráfego HTTP, TCP e Layer4 em um único modelo de configuração — construa uma arquitetura de destino flexível com grupos de backend. Vamos fazer um tour em uma configuração ao vivo no seu ambiente.