Si tu sitio o aplicación está creciendo, un servidor eventualmente se queda sin espacio. Un balanceador de carga distribuye el tráfico entre varios servidores para que los usuarios estén contentos y nada se caiga, y también es cómo mantienes los servicios altamente disponibles cuando un único servidor falla. Hay dos tipos que debes conocer: el balanceador de carga de red (Capa 4) y el balanceador de carga de aplicación (Capa 7). Un balanceador de carga L4 se preocupa por la IP y el puerto. Un balanceador de carga L7 se preocupa por lo que hay dentro de la solicitud. Los dos no siempre son productos distintos. Algunos balanceadores de carga, incluido el próximo Contabo Load Balancer, pueden gestionar tanto L4 como L7 en el mismo servicio. Echemos un vistazo a las diferencias para que puedas elegir el modo correcto para tu carga de trabajo.
Referencia rápida al modelo OSI: Lo que significan la Capa 4 y la Capa 7
El modelo OSI divide la red en siete capas. Aquí importan dos. La Capa 4 es la capa de transporte, donde viven TCP y UDP. Un paquete en esta capa tiene una IP de origen, IP de destino, puerto de origen, puerto de destino y una carga útil que el balanceador de carga nunca abre. La Capa 7 es la capa de aplicación, donde viven HTTP, HTTPS, gRPC y WebSocket. El proxy lee la solicitud, incluyendo la ruta de la URL, encabezado del host, cookies y método. La capa OSI que elijas determina cuánto puede ver el proxy, y esa única diferencia impulsa cada otra compensación por debajo.
¿Qué es un balanceador de carga de Capa 4?
Un balanceador de carga de Capa 4, también llamado balanceador de carga de red o balanceador de carga TCP, distribuye el tráfico basado en la dirección IP y el puerto de cada conexión. No inspecciona la carga útil. Cuando un cliente abre una conexión TCP, el proxy L4 selecciona un backend usando un algoritmo de balanceo como round-robin o menor número de conexiones, y luego reenvía los paquetes entre los puntos finales. Las sesiones persistentes, donde el mismo cliente siempre llega al mismo backend, son una preocupación separada y se implementan comúnmente mediante hashing de la IP de origen, aunque existen otros métodos. Un balanceador de carga UDP funciona igual para tráfico sin conexión como DNS, QUIC o protocolos de juegos. Debido a que el balanceador de carga L4 nunca analiza la carga útil, gestiona tasas de paquetes muy altas con bajo uso de CPU y latencia predecible. Es un director de tráfico de alta velocidad que sabe a dónde enviar una conexión, no lo que se está diciendo a través de ella.
Balanceador de carga de Capa 4: Ventajas y desventajas
Ventajas de un balanceador de carga L4:
- Rendimiento muy alto y poca latencia, porque no ocurre análisis de carga útil.
- Funciona para cualquier servicio que se ejecute sobre los protocolos que soporta el balanceador de carga, típicamente TCP y UDP. No limitado a HTTP.
- Configuración más sencilla y menos partes móviles.
Desventajas de un balanceador de carga L4:
- Sin enrutamiento consciente del contenido. No puede enviar
/apia un grupo y/statica otro. - No terminación de TLS en el proxy en la mayoría de configuraciones. Los certificados viven en los backends.
- Sin chequeos de salud a nivel de aplicación. El proxy puede decir si un puerto TCP está abierto, pero no si la aplicación detrás de él está realmente saludable.
- Observabilidad limitada. Ves conexiones, no solicitudes.
¿Qué es un balanceador de carga de Capa 7?
Un balanceador de carga de Capa 7, también llamado balanceador de carga de aplicación o balanceador de carga HTTP, toma decisiones de enrutamiento usando el contenido de las solicitudes HTTP. Termina la conexión del cliente, inspecciona la línea de solicitud y los encabezados, aplica reglas y abre una nueva conexión con el backend elegido. Esa única capacidad permite el enrutamiento basado en la ruta, enrutamiento basado en el host, reglas de encabezados y cookies, reescritura de solicitudes, compresión de respuestas, y terminación de TLS en un punto central. Es bueno para lógica de enrutamiento que depende de lo que el usuario está pidiendo, no solo de a dónde van los paquetes.
Balanceador de carga de Capa 7: Ventajas y desventajas
Ventajas de un balanceador de carga L7:
- Enrutamiento basado en la ruta y basado en el host para microservicios y aplicaciones multi-tenant.
- Terminación de TLS en el proxy, con gestión central de certificados.
- Soporte nativo para HTTP/2, HTTP/3, WebSocket y gRPC.
- Sesiones persistentes a través de cookies, para que el mismo usuario llegue al mismo backend sin depender de la IP de origen.
- Integración de WAF para filtrar solicitudes maliciosas antes de que lleguen a tu aplicación.
- Observabilidad detallada por solicitud y registros de acceso.
Desventajas de un balanceador de carga L7:
- Mayor costo de CPU por solicitud, porque se analiza la carga útil.
- Más superficie de configuración y más maneras de malconfigurar.
- Las características conscientes de la aplicación solo ayudan para los protocolos que el proxy entiende.
Balanceador de carga de Capa 4 vs Capa 7: Comparación lado a lado
Aquí está la comparación de balanceador de carga L4 vs L7 en una vista. Las mismas dimensiones aparecen en casi cada conversación sobre balanceo de carga L7 vs L4, por lo que esta tabla de balanceo de carga de capa 4 vs capa 7 ancla el resto del artículo.
| Dimensión | Balanceador de carga de Capa 4 | Balanceador de carga de Capa 7 |
|---|---|---|
| Capa OSI | Transporte (TCP, UDP) | Aplicación (HTTP, HTTPS, gRPC, WebSocket) |
| Entrada de enrutamiento | IP, puerto | ruta de URL, encabezado de host, cookies, métodos, encabezados |
| Inspección de carga útil | Ninguno | Solicitud y respuesta completas |
| Terminación de TLS | Pasar a backend | Terminada en el proxy |
| Rendimiento | Mayor, a nivel de paquete | Más bajo que L4, a nivel de solicitud |
| Observabilidad | Conteos de conexión, bytes | Registros por solicitud, códigos de estado, encabezados |
| Protocolos comunes | TCP, UDP, cualquier | HTTP, HTTPS, HTTP/2, HTTP/3, WebSocket, gRPC |
| Productos típicos | Modo TCP de HAProxy, módulo de transmisión de NGINX, AWS NLB | NGINX, Envoy, Traefik, modo HTTP de HAProxy, AWS ALB |
| Nomenclatura de proveedores de nube | Balanceador de carga de red (NLB) | Balanceador de carga de aplicación (ALB) |
En la nomenclatura del balanceador de carga de aplicación vs balanceador de carga de red utilizada por los principales proveedores de nube, ALB es L7 y NLB es L4. La distinción entre balanceador de carga de red y balanceador de carga de aplicación se reduce al mismo eje de inspección de carga útil.
Rendimiento: ¿Qué tan más rápido es la Capa 4?
L4 es generalmente más rápido que L7, y la razón es mecánica. Un proxy L4 mueve paquetes sin analizarlos, por lo que el CPU por conexión es bajo y el rendimiento de paquetes escala cerca de la tasa de línea de red. Los caminos de datos L4 construidos sobre eBPF, como Cilium y Katran, llevan esto más lejos al reenviar en el núcleo de Linux en lugar de en el espacio del usuario. La brecha es más pequeña de lo que sugiere el marketing, sin embargo. Un balanceador de carga de alto rendimiento en la Capa 7, como NGINX o Envoy, gestiona decenas de miles de solicitudes HTTPS por segundo en hardware modesto. Para la mayoría de las cargas de trabajo web, el cuello de botella se desplaza primero al backend. Usa L4 cuando importan las conexiones crudas por segundo. Usa L7 cuando importan las características de la solicitud.
Cuándo usar un balanceador de carga de Capa 4
Cuándo usar un balanceador de carga en la Capa 4 se reduce a cuatro señales. Busca un proxy L4 si aplica cualquiera de estas:
- El tráfico no es HTTP. Un balanceador de carga TCP es la única opción para bases de datos, SMTP, IMAP y la mayoría de los backends de juegos. Se necesita un balanceador de carga UDP para DNS, QUIC y medios en tiempo real.
- Necesitas un máximo de rendimiento por núcleo de CPU, y la carga de trabajo es pesada en conexiones en lugar de solicitudes.
- Quieres terminación TLS en los backends, a menudo por cumplimiento o certificados por inquilino.
- Quieres una superficie de proxy mínima, porque cada función también es una posible mala configuración.
Una implementación común de L4 es un balanceador de carga de red pública frente a un nivel L7 interno.
Cuándo usar un balanceador de carga de capa 7
Las señales para L7 son sobre lo que deseas hacer con la solicitud, no cuántos paquetes puedes manejar. Utiliza un balanceador de carga HTTP si se aplica alguno de estos:
- Sirves una aplicación web o API y necesitas enrutamiento basado en rutas o en hosts. Un balanceador de carga para microservicios es casi siempre L7.
- Terminas TLS de forma central, gestionas certificados en un solo lugar o ejecutas un WAF frente al tráfico HTTP.
- Necesitas un balanceador de carga WebSocket, sesiones persistentes ligadas a cookies, o multiplexión HTTP/2 y gRPC.
- Quieres registros por solicitud para depurar o seguimiento de SLO.
Para la mayoría de los stacks web modernos, el proxy L7 es el predeterminado.
¿Puedes usar ambos? Arquitecturas de balanceo de carga en capas
La mayoría de las implementaciones grandes no eligen. Las combinan en capas. Una arquitectura típica de balanceador de carga pone un proxy L4 en el borde para escalabilidad bruta, luego un proxy L7 dentro para enrutamiento. La capa L4 gestiona el volumen de conexiones, la absorción de DDoS y el paso de protocolo. La capa L7 lee solicitudes y las enruta. Para un balanceador de carga en microservicios, la capa L7 a menudo también actúa como controlador de ingreso, con un proxy L4 o IP anycast frente a él. El resultado es rendimiento L4 con consciencia sobre solicitudes L7.
Balanceo de carga de capa 3: una rápida mención
A veces verás referencias de balanceadores de carga L3, especialmente en la red de borde de hyperscalers. Un balanceador de carga de capa 3 enruta a nivel IP, a menudo usando ECMP o anycast con BGP, y está frente a la capa L4 en el borde. Es una categoría real, pero rara vez una decisión de compra. La mayoría de los operadores consumen el balanceo de carga L3 como una propiedad del borde del proveedor de nube.
Ejemplos de balanceadores de carga de capa 4 y capa 7
Productos comunes de balanceadores de carga y opciones de balanceadores de carga software:
- HAProxy. Opera en ambas capas. El modo TCP es L4, el modo HTTP es L7.
- NGINX. L7 por defecto a través de bloques
http. Agrega soporte L4 a través del módulostreampara TCP y UDP. - Envoy. Proxy L7 utilizado en mallas de servicio como Istio y como un gateway de aplicación independiente. También soporta L4.
- Traefik. Proxy L7 popular con plataformas de contenedores, con enrutadores TCP y UDP L4 nativos.
- Cilium y Katran. Caminos de datos L4 construidos sobre eBPF, usados para direccionamiento TCP y UDP a gran escala.
- AWS NLB y ALB. NLB es L4, ALB es L7.
- Google Cloud Load Balancing. Ofrece un Balanceador de Aplicaciones para L7 y un Balanceador de Red para L4, en variantes de reenvío y proxy.
- Azure. Separa las dos capas en productos distintos: Azure Load Balancer para L4 (TCP y UDP), Azure Application Gateway para L7 (HTTP y HTTPS, con WAF).
Estos ejemplos de balanceadores de carga cubren la mayoría de los stacks de producción. La elección del balanceador de carga de software se reduce a la familiaridad operativa.
Cómo elegir entre la capa 4 y la capa 7
Utiliza esto como una lista de verificación rápida para decisiones. Métodos comunes de balanceadores de carga como round-robin, least-connections y IP-hash existen en ambas capas, así que la elección de la capa viene antes que el algoritmo.
- Protocolos: cualquier cosa fuera de HTTP, HTTPS, gRPC o WebSocket apunta a L4.
- TLS: la terminación central significa L7. El paso a través significa L4.
- Reglas de enrutamiento: el enrutamiento basado en ruta, host, encabezado o cookies es exclusivo de L7.
- Rendimiento: si un proxy necesita más de lo que tu L7 puede manejar por núcleo, añade una capa L4 en frente.
- Observabilidad: los registros por solicitud significan L7. Los conteos de conexión significan que L4 es suficiente.
- A largo plazo: L4 frente a L7 es la arquitectura más común a escala.
Balanceo de carga L4 / L7 en VPS de Contabo
Los planes VPS de Contabo pueden ejecutar cualquier balanceador de carga de software estándar, así que puedes desplegar cualquiera de las capas sin un producto gestionado. Un patrón típico es HAProxy o NGINX en un pequeño VPS frente a dos o más servidores de aplicación en planes más grandes. NGINX cubre L7 a través de su bloque http y L4 a través del módulo stream por lo que un solo binario puede ejecutar ambas capas. HAProxy funciona de la misma manera, con mode tcp para L4 y mode http para L7. Para una configuración paso a paso, consulta la guía de configuración del balanceador de carga en el blog de Contabo. Cubre el dimensionamiento del VPS, instalando el proxy y los bloques de configuración para ambas capas.
Conclusión
La decisión entre el balanceador de carga de capa 4 y de capa 7 es principalmente una cuestión de lo que el proxy necesita ver. L4 es la respuesta correcta para rendimiento bruto, protocolos no HTTP o TLS en modo paso a través. L7 es la respuesta correcta para enrutamiento basado en rutas, TLS central y visibilidad por solicitud. La mayoría de los stacks de producción terminan ejecutando ambos.
FAQ sobre balanceadores de carga de capa 4 y 7
¿Es la capa 7 mejor que la capa 4?
Ninguna es universalmente mejor, depende del caso de uso. La capa 7 es más rica en características porque lee solicitudes HTTP, por lo que gana para aplicaciones web y microservicios. La capa 4 es más rápida y agnóstica a los protocolos para los protocolos de transporte que soporta, así que gana para tráfico no HTTP, rendimiento bruto y implementaciones a escala de borde. La elección entre L7 y L4 depende de los protocolos que balancees y las reglas de enrutamiento que necesites.
¿Es NGINX un balanceador de carga de capa 4 o de capa 7?
Ambos. NGINX como balanceador de carga opera en la Capa 7 por defecto a través de su bloque de configuración httpstream que añade balanceo de carga TCP y UDP. El mismo binario de NGINX cubre ambas capas, que es una razón por la cual sigue siendo una elección predeterminada para cargas de trabajo mixtas.
¿Un balanceador de carga de capa 4 termina SSL?
Usualmente no. La terminación SSL en el balanceador de carga es una característica de la capa 7, porque el proxy tiene que leer la solicitud para tomar decisiones de enrutamiento sobre datos en texto claro. Un balanceador de carga de capa 4 típicamente pasa tráfico cifrado directamente a los backends, que luego gestionan TLS ellos mismos. Algunos proxies L4 ofrecen paso a través de TLS con enrutamiento basado en SNI, pero esa es la excepción, no la regla.
¿Un balanceador de carga de capa 7 puede gestionar tráfico no-HTTP?
Un balanceador de carga de capa 7 está diseñado para protocolos de aplicación que puede analizar, principalmente HTTP, HTTPS, gRPC y WebSocket. Para tráfico TCP o UDP arbitrario, un proxy L7 ya sea vuelve al modo L4, como NGINX stream o HAProxy mode tcp, o le pasa el tráfico a un nivel L4 separado. Las cargas de trabajo puras no-HTTP pertenecen a L4, no a L7.
¿Cuál es la diferencia entre un Balanceador de Carga de Aplicación y un Balanceador de Carga de Red?
En la mayoría de los nombres de proveedores de nube, un Balanceador de Carga de Aplicación es Capa 7 y un Balanceador de Carga de Red es Capa 4. La diferencia entre el Balanceador de Carga de Aplicación y el Balanceador de Carga de Red es la misma que L7 frente a L4. El ALB lee las solicitudes HTTP y enruta por URL, host, y encabezados. El NLB reenvía TCP y UDP según IP y puerto. ALB vs NLB es la versión en la nube de L4 vs L7.nube
