Round-robin envía cada solicitud a un backend diferente — por diseño. Para servicios sin estado es perfecto. Pero en el momento en que un usuario inicia sesión, llena un carrito o inicia un escritorio remoto, la aplicación empieza a mantener estado en un backend específico. Si la solicitud #2 llega a uno diferente, el usuario ve un carrito vacío, una pantalla de cierre de sesión o una sesión RDP congelada.
La persistencia de sesión (o «afinidad») resuelve esto anclando a un usuario al backend elegido durante la duración de la sesión. La dificultad: no existe una única forma correcta de anclar. Source-IP funciona para usuarios con IP única pero falla detrás de NAT corporativo. Las cookies funcionan en navegadores pero no para TCP raw. URL-parameter hash funciona para URLs sin estado pero no para flujos con ámbito de usuario. Cada método es correcto en algún lugar.
La respuesta es incluir cada método y seleccionar por vService.
Cada vService selecciona su método de persistencia desde un desplegable — junto a su algoritmo de balanceo de carga. Ambas capas son independientes: elija Fastest+ para la selección de backend y una cookie TR7 para afinidad, o round-robin con source-IP, o la combinación que se adapte a la carga de trabajo. El cambio de método es hot-swap, sin reinicio.
Cinco algoritmos de balanceo de carga auto-persistentes (source, URI, URL-param, cabecera, RDP-cookie) más cuatro métodos de persistencia explícitos (cookie TR7, cookie del backend, dinámica, SAM). Cubren todos los casos comunes.
Session Affinity Manager le permite configurar la fuente de la cookie (generada por TR7 o por el backend), el formato de sesión (UUID, IP-timestamp-random, IP-random, personalizado) y los indicadores de seguridad (HttpOnly, Secure, SameSite=Strict/Lax) — sin tocar el código del backend.
La persistencia se ejecuta sobre el algoritmo de balanceo de carga: el algoritmo elige el backend para la primera solicitud, la persistencia ancla el resto. Fastest+ para el arranque en frío, cookie sticky para la sesión — funciona conjuntamente.
Cambie el método de persistencia en un vService activo y las nuevas sesiones adoptan el nuevo método de inmediato. Las sesiones ancladas existentes continúan sin interrupción hasta que expiran.
Elija el método que se adapta al protocolo, la población de clientes y el modelo de sesión de la aplicación. Los 9 están disponibles por vService — sin código, sin plugins.
La misma IP de cliente siempre llega al mismo backend. Simple, sin código, funciona para cualquier protocolo. Ideal cuando las IPs de cliente son diversas — falla detrás de NAT compartido o proxies corporativos.
El hash sobre la longitud de URL distribuye la carga por complejidad de URL mientras ancla las URLs idénticas al mismo backend. Útil para escenarios de afinidad de caché.
Hash sobre un parámetro de consulta específico (p. ej. ?user_id, ?session_token). Enruta la misma solicitud con ámbito de usuario al mismo backend sin necesidad de cookies.
Hash sobre una cabecera HTTP personalizada. Útil cuando el llamante upstream inyecta IDs de tenant o correlación, o para enrutamiento A/B basado en cabeceras.
Lee la cookie de sesión RDP integrada en la negociación del protocolo. Necesaria para gateways RDP y granjas de escritorio remoto — mantiene a los usuarios en el mismo host RDP tras la reconexión.
TR7 ADC genera y gestiona la cookie de afinidad por sí mismo — no se requiere código del backend. El operador establece el nombre de la cookie y un timeout de inactividad máximo; el ADC la lee en cada solicitud, el backend la ignora. La persistencia más fácil de adjuntar a una aplicación legacy.
Use la cookie de sesión propia de la aplicación para la afinidad — el operador nombra la cookie (PHPSESSID, JSESSIONID, app-id, cualquier nombre personalizado) y TR7 ADC lee el valor existente. No se añaden nuevas cookies. Correcto cuando la aplicación ya hace seguimiento de sesiones y no desea añadir una segunda capa de cookies.
Tabla de persistencia por clave hash mantenida en memoria. Cada entrada mapea una clave — cualquier combinación de cabeceras de solicitud, cookies, source IP o parámetros URL — a un backend. El operador establece el tamaño de la tabla (10K a 100M entradas, predeterminado 3M) y el tiempo de expiración de entrada. Úselo cuando las reglas de persistencia necesiten ser más flexibles que una cookie o cabecera fija única.
El motor de persistencia avanzado basado en cookies. Elija quién genera la cookie, el formato del ID de sesión y los indicadores de seguridad — todo desde la UI, sin cambios en el backend. Vea los detalles más abajo.
SAM es el método de persistencia más flexible de TR7. Donde una cookie simple ancla una sesión, SAM le permite controlar cada propiedad de esa cookie desde un desplegable — sin cambios en el backend, sin escribir código de reglas.
Elija quién genera la cookie de afinidad: generada por TR7 (predeterminado — sin participación del backend) o generada por el backend (use la cookie de sesión existente de la aplicación). Cambie entre ellas sin romper las sesiones activas.
Opciones de formato del identificador de sesión: UUID (128 bits aleatorio), IP-timestamp-random (rastreable, ordenado por tiempo), IP-random (anónimo dentro de un tenant) o Personalizado. El modo Personalizado abre la superficie completa de variables de tráfico — combine cualquier cabecera de solicitud, cookie, componente URL, información de sesión TLS, source IP (en bruto o enmascarada), claims JWT, parámetros de consulta e incluso campos del cuerpo de la solicitud con funciones de transformación definidas por el operador (enmascaramiento, hashing, extracción de subcadenas, normalización de mayúsculas/minúsculas, concatenación). El mismo motor de variable-y-transformación impulsa las claves hash de la persistencia Dinámica. Vea el spotlight más abajo para combinaciones del mundo real.
Indicadores de seguridad de cookies: HttpOnly (sin acceso JavaScript — protección XSS), Secure (solo HTTPS), SameSite=Strict (sin envío entre sitios — protección CSRF), SameSite=Lax (variante compatible). Combínelos según sea necesario.
Todo lo anterior es un desplegable por vService en el panel SAM. Sin código de reglas personalizado, sin integración con el backend, sin regla WAAP separada para el manejo de cookies. SAM es una configuración, no un script.
El Formato Personalizado SAM y las claves hash de persistencia Dinámica aceptan cada variable de tráfico que TR7 ADC ve — combínelas, transfórmelas, construya la regla de persistencia exacta que su aplicación necesita
Los usuarios añaden artículos a través de múltiples cargas de página. La cookie del backend o la cookie TR7 mantiene el estado del carrito en un backend — el checkout nunca ve un carrito vacío.
Sesiones con sesión iniciada donde la caché de permisos del usuario vive en un backend. SAM con cookie generada por TR7 + HttpOnly + Secure funciona sin cambios en el código del backend.
Las sesiones RDP deben reconectarse al mismo host. La persistencia por cookie RDP lee el ID de sesión nativo del protocolo — sin configuración adicional, sin inyección de cookies.
Aplicaciones que no hacen seguimiento de sesiones por sí mismas. La persistencia source-IP o por parámetro URL ancla a los usuarios sin requerir cambios de código en la aplicación legacy.
Vea cómo 9 métodos de persistencia cubren todos los casos comunes — desde gateways RDP hasta aplicaciones legacy y cookies controladas por SAM.