En la gestión de tráfico empresarial, los servicios HTTP, TCP y Layer4 no son la misma cosa. Para el tráfico HTTP, las cabeceras, las cookies, los paths, las puntuaciones WAAP y las reglas de contenido son relevantes. Para TCP, el manejo de conexiones, la terminación SSL y el SNI dominan. En Layer4, el protocolo a nivel de kernel, el algoritmo y el comportamiento de persistencia son los que guían las decisiones. Si estas diferencias no se modelan explícitamente, los operadores se encuentran con configuraciones que no pueden funcionar en su contexto actual.
En los enfoques tradicionales, el tipo de servicio a menudo se dispersa entre objetos separados, perfiles, pantallas o bloques de configuración manual. Los operadores deben memorizar qué funcionalidades aplican a qué tipo de tráfico. Una regla de cabecera en el lugar incorrecto, una configuración WAAP en el servicio incorrecto o una expectativa de Capa 7 en un flujo Layer4 se traducen en errores en tiempo de ejecución y tiempo perdido.
Un segundo problema es gestionar múltiples grupos de backends bajo un único servicio. Enviar solicitudes de lectura y escritura a distintos destinos, separar el tráfico móvil y de escritorio, o ejecutar grupos de servicio regionales bajo un único punto de entrada se trata como una funcionalidad separada en la mayoría de las plataformas — añadiendo peso conceptual a lo que debería ser un requisito de enrutamiento sencillo.
El enfoque correcto es declarar el tipo de servicio explícitamente dentro de un único objeto pool y hacer que la matriz de funcionalidades se filtre automáticamente. Deben soportarse múltiples grupos de backends bajo el mismo pool, mientras los operadores ven solo las opciones relevantes sin ser abrumados por detalles técnicos innecesarios.
El modelo de Tres Tipos de Servicio de TR7 reduce esta complejidad: el tipo de servicio se elige desde el principio, las funcionalidades apropiadas aparecen automáticamente y los grupos de backends se gestionan dentro del mismo modelo de configuración.
TR7 convierte el tipo de servicio en el interruptor central de la configuración y organiza toda la visibilidad de funcionalidades en torno a esa elección arquitectónica.
El operador crea un pool eligiendo HTTP, TCP o Layer4. Esa única selección determina qué acciones, comprobaciones de estado y funcionalidades de tráfico estarán disponibles a partir de entonces.
La matriz central de funcionalidades define qué acciones son válidas para qué tipo de servicio. La interfaz muestra solo las configuraciones significativas para el tipo de pool seleccionado; las opciones técnicamente inválidas nunca aparecen ante el operador.
Cada pool comienza con un grupo de backends predeterminado y se pueden añadir grupos adicionales según sea necesario. El tráfico se enruta al grupo relevante mediante lógica de ACL y reglas.
El tipo de servicio es la decisión arquitectónica que afecta a toda la matriz de funcionalidades del pool. En lugar de convertir un pool existente a un tipo diferente, la ruta recomendada es crear un nuevo pool y realizar una migración controlada.
El modelo de Tres Tipos de Servicio ofrece las capacidades correctas en el lugar correcto para el tráfico HTTP, TCP y Layer4.
El tipo HTTP se utiliza para el comportamiento completo de proxy de Capa 7. WAAP, reglas conscientes del contenido, manipulación de cabeceras y cookies, redirect, captcha, caché de respuestas, compresión e integración con AAM son significativos en este tipo. Las opciones ALPN h2 y http/1.1 pueden incluirse en el comportamiento del servicio HTTP. HTTP es la elección correcta cuando se necesitan toma de decisiones detallada, transformación y política de seguridad en el tráfico de aplicaciones y API.
El tipo TCP se utiliza para servicios que necesitan terminación SSL o passthrough sobre un flujo de conexión de Capa 4. El enrutamiento basado en SNI, la inspección de TLS hello y la gestión de conexiones TCP son prominentes aquí. Las necesidades de persistencia específicas de TCP, como la persistencia por cookie RDP, pueden abordarse en este tipo. Las funciones de protocolo como MQTT y FIX también pueden fortalecer la lógica de decisión a nivel TCP.
El tipo Layer4 se utiliza para el modelo de distribución de alto rendimiento que opera a nivel de kernel. Los algoritmos IPVS, NAT, DR y los modos TUN pueden aplicarse a flujos TCP, UDP o agnósticos al protocolo. En este tipo no se realiza inspección de Capa 7; las decisiones se basan en IP, puerto, protocolo y lógica de persistencia. Esta es la arquitectura correcta para DNS, telecomunicaciones o servicios de pura Capa 4 donde la baja latencia es esencial.
Cada pool tiene al menos un grupo de backends predeterminado. Este grupo lleva el conjunto de destinos principal del servicio y el algoritmo de balanceo de carga. Cuando no se escribe ninguna regla de enrutamiento adicional, el tráfico se reenvía a este grupo predeterminado. El modelo mantiene los servicios simples de forma directa a la vez que permite la expansión para escenarios avanzados.
Se pueden crear grupos como `be-mobile`, `be-desktop`, `be-eu`, `be-us`, `be-readonly` o `be-writes` bajo un único pool. Cada grupo puede tener su propio conjunto de destinos, perfil de comprobación de estado y comportamiento de tráfico. Las condiciones de ACL y reglas dirigen las solicitudes al grupo apropiado. Esto hace que una arquitectura multi-destino sea manejable bajo un único punto de entrada.
Las reglas pueden aplicarse solo en el grupo de backends, en ambos lados del frontend y del grupo, o en un grupo con nombre específico. Este modelo de segmentación hace explícito el alcance de cada regla. Por ejemplo, una transformación de cabecera, comportamiento de salud o condición de enrutamiento pueden definirse exclusivamente para un grupo. El operador separa diferentes segmentos de tráfico dentro del mismo servicio de forma controlada.
CORS, encriptación de cookies, añadir cabecera, eliminar cabecera, reescritura de paths, normalización URI y autorización son acciones exclusivas de HTTP. La gestión de conexiones TCP y las opciones de persistencia específicas de TCP aparecen solo en el tipo TCP. Acciones como silent log, regla manual, tabla de cuarentena, deny y enmascaramiento de IP pueden usarse en múltiples tipos. Dado que la interfaz aplica esta separación automáticamente, los operadores nunca tienen que lidiar con la acción incorrecta en el tipo de servicio incorrecto.
Los límites de número máximo de conexiones y tasa de conexiones pueden definirse a nivel de pool. También pueden aplicarse límites de conexión individuales por destino de backend. Este modelo ayuda a proteger tanto el servicio en general como los destinos individuales bajo tráfico intenso. La configuración de capacidad se planifica según el tipo de servicio, el comportamiento del tráfico y los recursos de hardware.
El modelo de Tres Tipos de Servicio se considera junto con las restricciones de cambio de tipo, la generación de configuración, el monitoreo de estado, las rutas de estadísticas y el comportamiento de auditoría.
El tipo de servicio no puede cambiarse tras la creación como un ajuste simple. Los tipos HTTP, TCP y Layer4 requieren cada uno una matriz de funcionalidades diferente, una ruta de procesamiento diferente y una generación de configuración diferente. Cuando se necesita un cambio de tipo, el enfoque correcto es crear un nuevo pool y realizar una migración controlada.
Si una ACL en una regla de grupo de backends se define en el lado del frontend o del grupo depende del destino previsto. Esta distinción aclara en qué etapa del procesamiento de tráfico se activa la regla. Evita que las condiciones colocadas en el lugar incorrecto perturben el comportamiento del servicio.
Cada grupo de backends se emite como un bloque de configuración separado. El grupo predeterminado se define por separado de los grupos adicionales, y las reglas se vinculan a sus destinos respectivos. Esta estructura beneficia tanto la legibilidad de la configuración como los escenarios de reversión.
Cuando se habilita la configuración apropiada en el tipo HTTP, las opciones ALPN h2 y http/1.1 pueden usarse en conexiones del lado del servidor. Esta configuración solo es significativa en el contexto de un servicio HTTP. No debe esperarse comportamiento HTTP de Capa 7 de los tipos TCP o Layer4.
En el tipo TCP, se puede tomar una decisión de enrutamiento inspeccionando el campo SNI en el mensaje TLS hello. Esto se usa para separar servicios TLS a diferentes destinos sin realizar un análisis HTTP completo. Las decisiones basadas en SNI deben planificarse cuidadosamente dependiendo de los requisitos de passthrough frente a terminación.
En el tipo Layer4, las estadísticas provienen de mecanismos de distribución a nivel de kernel en lugar de la ruta de proxy de Capa 7. No debe asumirse un comportamiento idéntico al de las estadísticas de proxy HTTP o TCP. Los operadores que monitorean servicios Layer4 deben usar la fuente de estadísticas apropiada.
Los equipos SaaS pueden gestionar el tráfico de API bajo visibilidad completa de Capa 7 usando el tipo HTTP. WAAP, validación JWT, reglas conscientes del contenido y enrutamiento basado en paths se aplican dentro del mismo modelo de servicio.
Los equipos empresariales pueden gestionar servicios orientados a conexión que requieren terminación SSL, passthrough o persistencia por IP de origen usando el tipo TCP. Los servicios que no necesitan funcionalidades HTTP de Capa 7 se sirven con un modelo más simple.
Los equipos de telecomunicaciones e infraestructura pueden distribuir el tráfico UDP a nivel de kernel usando el tipo Layer4. Los algoritmos IPVS y las opciones de persistencia permiten una entrega de servicio de baja latencia y enfocada en el protocolo.
Los equipos de e-commerce pueden crear grupos como `be-variant-a` y `be-variant-b` bajo el mismo servicio HTTP. Las condiciones basadas en ACL o hash dirigen el tráfico a diferentes experiencias de forma controlada.
Gestione el tráfico HTTP, TCP y Layer4 en un único modelo de configuración — construya una arquitectura de destinos flexible con grupos de backends. Le guiaremos en una configuración en vivo en su propio entorno.