Cuando el tipo de servicio no está claramente modelado, las funcionalidades incorrectas aparecen en el lugar incorrecto y los errores operativos se vuelven inevitables.
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 paquete, 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.
Nuestro enfoque
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 tipo de servicio se selecciona al crear el pool
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.
Las acciones se filtran automáticamente por tipo de servicio
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.
Se pueden definir múltiples grupos de backends bajo un único servicio
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 no puede cambiarse tras la creación — se requiere un nuevo pool
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.
Capacidades
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 proporciona visibilidad completa de Capa 7 y seguridad de aplicaciones
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 centra en la gestión de conexiones y los escenarios SSL
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.
Cada servicio recibe sus propios núcleos — un pico HTTP no puede dejar sin recursos a un servicio UDP
Los servicios HTTP, TCP y UDP no solo comparten plataforma: cada servicio publicado recibe sus propios núcleos, su propia prioridad de CPU y su propio techo de memoria. Una campaña en el servicio web, una política WAF pesada en la API y una ráfaga DNS en el escuchador UDP se quedan cada una en su carril. Eso es lo que hace segura la consolidación densa: veinte servicios en un equipo se comportan como veinte equipos, sin veinte equipos.
El tipo Layer4 distribuye el tráfico TCP y UDP a nivel de paquete
El tipo Layer4 se utiliza para el modelo de distribución de alto rendimiento que opera a nivel de paquete. 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.
Balanceo de cortafuegos — el sándwich se mantiene simétrico
Un par de cortafuegos entre dos capas de TR7 solo sirve si un flujo y su retorno pasan por el mismo cortafuegos; de lo contrario este ve media conversación y la descarta. La selección por hash de origen en el tipo de servicio agnóstico al protocolo da esa simetría, las comprobaciones de salud sacan de la rotación a un cortafuegos caído en segundos, y añadir capacidad es añadir un miembro y no rehacer la topología. Lo que TR7 no hace es sincronizar las tablas de sesión de los propios cortafuegos: eso sigue siendo su tarea, y un par con estado debe seguir agrupándose como su fabricante prevé.
El grupo de backends predeterminado define el conjunto de destinos principal para cada pool
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.
Los grupos de backends adicionales crean segmentos de tráfico separados bajo el mismo servicio
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 a nivel de grupo determinan dónde se aplica cada regla
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.
Las acciones HTTP, TCP y compartidas se separan por la matriz de tipos
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.
La capacidad del pool y los límites de conexión se gestionan a nivel de servicio
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.
Profundidad operacional
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.
Restricción de cambio de tipo
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.
Ubicación de ACL en grupos
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.
Generación de bloques de configuración
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.
Comportamiento de HTTP/2 ALPN
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.
Enrutamiento SNI TCP
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.
Ruta de estadísticas Layer4
En el tipo Layer4, las estadísticas provienen de mecanismos de distribución a nivel de paquete 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.
Cuándo utilizarlo
API gateway HTTP con protección WAAP
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.
Gateway de mensajería empresarial basado en TCP
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.
Clúster de servicio DNS basado en UDP
Los equipos de telecomunicaciones e infraestructura pueden distribuir el tráfico UDP a nivel de paquete 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.
Enrutamiento A/B con grupos de backends HTTP
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.
Preguntas frecuentes
¿Cuál es la diferencia fundamental entre los tipos HTTP, TCP y Layer4?
¿Puede cambiarse el tipo de servicio después de crear el pool?
¿Cómo se definen múltiples grupos de backends bajo el mismo servicio?
¿Cómo se monitorizan las estadísticas en el tipo Layer4?
¿Cómo funciona el enrutamiento basado en SNI en el tipo TCP?
¿Qué acciones pueden usarse en más de un tipo de servicio?
Descubra el modelo de funcionalidades correcto para su tipo de servicio
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.