La distinción de capas OSI que sigue importando
El concepto de balanceo de carga es simple: distribuir las solicitudes entrantes entre varias instancias de servicio para que ningún servidor se sature y la aplicación permanezca disponible. Lo interesante es cómo se toma esa decisión de distribución. La división más consecuente está entre Layer 4 y Layer 7.
Layer 4 Load Balancing opera en la capa de transporte del modelo OSI — TCP y UDP. El balanceador ve la IP de origen, la IP de destino y los puertos de una conexión; nada más. Toma su decisión de distribución basada en esos campos de encabezado y luego pasa los bytes sin inspeccionar la carga útil. El protocolo de aplicación puede ser HTTP, MySQL, Kafka o un protocolo binario personalizado — el balanceador no lo sabe y no le importa.
Layer 7 Load Balancing opera en la capa de aplicación — HTTP, HTTPS, gRPC, WebSocket. El balanceador analiza cada solicitud, lee la ruta URL, los encabezados, las cookies y el método, y toma decisiones de enrutamiento basadas en ese contenido. También puede transformar solicitudes al vuelo: compresión, reescritura de encabezados, terminación TLS, caché.
Layer 7 es más potente que Layer 4 y más caro que Layer 4. La elección entre ambos depende de si el protocolo de aplicación tiene forma HTTP y si las capacidades adicionales valen el coste por conexión.
Cuándo Layer 4 es la elección correcta
Los escenarios donde L4 es la respuesta correcta comparten una propiedad: analizar el contenido de la aplicación es innecesario o no cabe en el presupuesto.
Los protocolos no HTTP son el ejemplo más claro de la categoría. Para bases de datos (MySQL, PostgreSQL), colas de mensajes (Kafka, RabbitMQ), correo electrónico (SMTP) y servicios TCP personalizados, el balanceador no necesita entender el contenido de la aplicación — la distribución por puerto y tasa de conexión funciona bien.
Los requisitos de rendimiento puro también apuntan a L4. La sobrecarga por conexión de L4 es la más baja porque no hay análisis de aplicación. Para servicios TCP de alto volumen donde cada microsegundo importa — plataformas de trading sensibles a la latencia, backends de juegos en tiempo real, cargas de trabajo similares — L4 es la herramienta correcta.
El cifrado de extremo a extremo es otro caso L4. Cuando TLS debe terminar en la aplicación en lugar del balanceador — mandato regulatorio, aislamiento multi-tenant, claves controladas por el cliente — L4 pasa TLS de forma transparente. El balanceador nunca ve el texto plano.
Por último, si una lógica de distribución simple es suficiente, L4 funciona con menos sobrecarga operativa. Si bastan round-robin, hash de IP de origen o least-connections y no se necesita enrutamiento basado en URL, L4 es más ligero y más fácil de razonar.
Cuándo Layer 7 es la elección correcta
Lo que distingue a L7 es su capacidad de tomar decisiones de enrutamiento y transformación basadas en el contenido de la aplicación. Sin esa capacidad, la mayoría de las aplicaciones web modernas no funcionarían.
El enrutamiento basado en URL es el caso más común. Enviar rutas diferentes a diferentes clusters de servicio — /api/v1/users a un cluster, /api/v1/orders a otro, /static/* a una CDN — no es posible con L4 porque L4 no ve las rutas.
El enrutamiento basado en encabezado o cookie también requiere L7. Pruebas A/B, fijación de versión (X-Service-Version: 2.5 enruta a una implementación específica), afinidad de sesión por ID de sesión de aplicación y enrutamiento por cliente mediante encabezado — todos requieren leer el contenido de la aplicación.
La terminación TLS también es un trabajo L7. SSL offload termina TLS en el balanceador, liberando a los servicios del trabajo criptográfico; permite gestión centralizada de certificados; permite inspección WAF. La WAF necesita texto plano para ver ataques; eso no ocurre sin L7.
Las funciones conscientes de la aplicación — compresión, caché, reescritura de solicitudes, health checks basados en contenido (el servicio devuelve 200 en /health, no solo acepta una conexión) y degradar HTTP/2 a HTTP/1.1 para servicios heredados — también requieren L7.
La observabilidad a nivel de aplicación sigue la misma lógica. Latencia por endpoint, tasa de error por URL, detección de consultas lentas — estos requieren ver solicitudes, no conexiones. L7 expone estos datos; L4 solo ve el nivel de conexión.
El punto clave es: si está decidiendo basado en el contenido de la aplicación, L7 es obligatorio. Si solo decide a nivel de conexión, L4 es suficiente.
Comparación directa
| Dimensión | Layer 4 | Layer 7 |
|---|---|---|
| Capa OSI | Transporte (TCP/UDP) | Aplicación (HTTP, HTTPS, gRPC, WebSocket) |
| Entradas de enrutamiento | IP de origen, IP de destino, puertos | URL, encabezados, cookies, método, cuerpo |
| Manejo TLS | Pass-through | Terminar o pass-through |
| Sobrecarga por conexión | Más baja | Mayor (análisis requerido) |
| Algoritmos de distribución | Round-robin, hash IP origen, least-connections | Todos los algoritmos L4 más enrutamiento por contenido, peso por URL |
| Integración WAF | No posible (sin visibilidad de contenido) | Nativa |
| Observabilidad | Nivel de conexión | Nivel de solicitud |
| Caso de uso típico | Proxy de base de datos, juegos, RTMP, SMTP | Aplicaciones web, APIs, microservicios |
Las implementaciones modernas usan ambos
La decisión rara vez es "L4 o L7" para toda una infraestructura. Se toma por aplicación — a veces por listener.
Un patrón empresarial típico combina ambos modos. L7 en el borde para tráfico HTTPS de usuarios; L4 para tráfico interno este-oeste donde el protocolo es nativo TCP y el presupuesto de latencia es ajustado; L7 nuevamente donde el tráfico este-oeste corre sobre RPC en HTTP, como gRPC.
La pregunta arquitectónica es si una única implementación de balanceador puede manejar ambos modos, o si la organización debe operar productos L4 y L7 separados. El enfoque de productos separados era históricamente común porque L4 y L7 tenían requisitos de implementación diferentes — L4 quería red kernel-bypass, L7 quería análisis HTTP rico. Los ADCs modernos han cerrado esa brecha; el mismo dispositivo maneja ambos modos mediante configuración por listener.
El beneficio operativo de combinarlos es el mismo que cualquier consolidación: un producto para implementar, una superficie de observabilidad, un conjunto de runbooks operativos, una ruta de actualización. Para organizaciones que antes operaban productos L4 y L7 de proveedores separados, consolidar en un solo ADC es a menudo la mayor simplificación operativa disponible.
Cómo el balanceador TR7 maneja ambos modos
El Load Balancer (LB) de TR7 lleva los modos L4 y L7 en el mismo dispositivo mediante configuración por listener. Una sola implementación puede alojar estos listeners en paralelo: un listener L7 en 443 manejando tráfico web HTTPS con WAF y aceleración SSL; un listener L4 en 5432 manejando conexiones PostgreSQL con afinidad por IP origen; otro listener L7 en 8080 manejando servicios gRPC internos con mTLS. Todos configurados juntos, compartiendo observabilidad y un único ciclo de vida de actualizaciones.
La aceleración por hardware se aplica a ambos modos. Las conexiones L4 se benefician del procesamiento de paquetes kernel-bypass; las conexiones L7 se benefician de la terminación TLS descargada y el análisis HTTP/2 / HTTP/3. El mismo dispositivo físico puede llevar miles de servicios TCP L4 concurrentemente con miles de sesiones HTTPS L7; el límite es el envolvente de hardware, no una licencia o feature gate por modo.
Para organizaciones que eligen entre proveedores en 2026, la pregunta "¿este LB admite tanto L4 como L7?" ya no es un diferenciador; la mayoría lo hacen. Los diferenciadores son la historia operativa (un producto o dos), la historia de observabilidad (unificada o dividida) y la historia de modernización (HTTP/3, TLS 1.3, soporte de criptografía post-cuántica). TR7 se posiciona alrededor de esos tres ejes; la capacidad L4 y L7 es la entrada.
L4 + L7 en una sola plataforma
TR7 Load Balancer lleva los modos L4 y L7 en el mismo dispositivo, con aceleración por hardware para ambos. Una superficie de observabilidad, una ruta de actualización, ambos modos disponibles por listener.
Descubre TR7 Load Balancer