Layer 4 load balancing uses information defined at the networking transport layer (Layer 4) as the basis for deciding how to distribute client requests across a group of servers. For Internet traffic specifically, a Layer 4 load balancer bases the load-balancing decision on the source and destination IP addresses and ports recorded in the packet header, without considering the contents of the packet.
There are seven networking layers in all, defined by the Open Systems Interconnection [OSI] Reference Model. For more information, see Layers in the OSI and Internet Models below.
For more information about load balancing, see Application Load Balancing with NGINX Plus.
Actualmente, el término «equilibrio de carga de capa 4» suele hacer referencia a una implementación en la que la dirección IP del equilibrador de carga se anuncia a los clientes como la correspondiente al sitio web o servicio, generalmente mediante DNS. Esto provoca que los clientes utilicen la dirección del equilibrador de carga como destino en sus solicitudes.
Cuando un equilibrador de carga de capa 4 recibe una solicitud y decide cómo distribuirla, realiza una traducción de direcciones de red (NAT) en el paquete. Específicamente, reemplaza la dirección IP de destino registrada por la del servidor de contenidos seleccionado en la red interna. De manera similar, antes de reenviar las respuestas del servidor a los clientes, modifica la dirección de origen en el encabezado del paquete, reemplazándola por su propia dirección IP. En algunos casos, también se ajustan los números de puerto TCP de destino y origen registrados en los paquetes siguiendo un proceso similar.
Los equilibradores de carga de capa 4 toman sus decisiones de enrutamiento basándose en la información de direcciones extraída de los primeros paquetes del flujo TCP, y no inspeccionan el contenido de los paquetes. Un equilibrador de carga de capa 4 suele ser un dispositivo de hardware dedicado suministrado por un proveedor y ejecuta un software de equilibrado de carga propietario, y las operaciones NAT pueden ser realizadas por chips especializados en lugar de por software.
El equilibrio de carga de capa 4 era un enfoque arquitectónico popular para la gestión del tráfico cuando el hardware básico no era tan potente como lo es ahora, y la interacción entre los clientes y los servidores de aplicaciones era mucho menos compleja. Requiere menos computación que los métodos de equilibrio de carga más sofisticados (como la capa 7), pero la CPU y la memoria son ahora lo suficientemente rápidas y baratas como para que la ventaja de rendimiento del equilibrio de carga de capa 4 sea insignificante o irrelevante en la mayoría de las situaciones.
Layer 7 load balancers operate at the highest level in the OSI model, the application layer (on the Internet, HTTP is the dominant protocol at this layer). Layer 7 load balancers base their routing decisions on various characteristics of the HTTP header and on the actual contents of the message, such as the URL, the type of data (text, video, graphics), or information in a cookie.
Taking into consideration so many more aspects of the information being transferred can make Layer 7 load balancing more expensive than Layer 4 in terms of time and required computing power, but it can nevertheless lead to greater overall efficiency. For instance, because a Layer 7 load balancer can determine what type of data (video, text, and so on) a client is requesting, you don’t have to duplicate the same data on all of the load-balanced servers.
Modern general-purpose load balancers, such as NGINX Plus and the open source NGINX software, generally operate at Layer 7 and serve as full reverse proxies. Rather than manage traffic on a packet-by-packet basis like Layer 4 load balancers that use NAT, Layer 7 load balancing proxies can read requests and responses in their entirety. They manage and manipulate traffic based on a full understanding of the transaction between the client and the application server.
Algunos equilibradores de carga pueden configurarse para proporcionar equilibrio de carga de capa 4 o capa 7, dependiendo de la naturaleza del servicio. Como se ha mencionado anteriormente, el hardware básico moderno suele ser lo suficientemente potente como para que el ahorro en costes computacionales del equilibrio de carga de capa 4 no sea lo suficientemente grande como para compensar las ventajas de mayor flexibilidad y eficiencia del equilibrio de carga de capa 7.
NGINX Plus and NGINX are the best-in-class load balancing solutions used by high-traffic websites such as Dropbox, Netflix, and Zynga. More than 350 million websites worldwide rely on NGINX Plus and NGINX Open Source to deliver their content quickly, reliably, and securely.
Como equilibrador de carga basado en software, NGINX Plus es mucho más económico que las soluciones basadas en hardware con funciones similares. Las completas funciones de equilibrio de carga de NGINX Plus le permiten crear una red de entrega de aplicaciones altamente optimizada.
Cuando inserta NGINX Plus como equilibrador de carga delante de su granja de servidores, aumenta la eficacia, el rendimiento, la fiabilidad y la escala de todo su sitio web. NGINX Plus le ayuda a maximizar tanto la satisfacción del cliente como el rendimiento de sus inversiones en TI.
Para el tráfico de Internet, referirse al equilibrio de carga de «capa 4» y «capa 7» es una abreviatura cómoda, pero no estrictamente exacta. Si le interesa, siga leyendo.
The notion of seven networking layers comes from the Open Systems Interconnection (OSI) Reference Model. The model separates network functions into seven abstracted layers, commonly referred to by their numbers (Layer 1 through Layer 7). At each layer there are standards that define how data is packaged and transported. Among other things, the standards define how to segment the stream of bits that constitute a request or response into discrete packages called protocol data units (PDUs). The standards also define the metadata added to each PDU in the form of a header; the metadata might specify the addresses of the origin and destination hosts, for example.
Asignar diferentes aspectos de la funcionalidad de la red a diferentes capas simplifica el procesamiento en cada capa, porque un protocolo solo tiene que saber cómo tratar las PDU de su propia capa, y qué metadatos incluir en el encabezado cabecera para que los protocolos de las capas adyacentes puedan reempaquetar las PDU en su propio nivel de segmentación de datos.
The distribution of network functions among the basic protocols for traffic on the World Wide Web – which are collectively referred to as the Internet protocol (IP) suite – does not conform exactly to the OSI model. This is because the IP suite was defined and implemented before the finalized OSI model was published in 1984. Nonetheless, the various protocols in the IP suite do perform distinct functions that roughly correspond to OSI layers.
Hay múltiples protocolos definidos en cada nivel, pero los siguientes son los protocolos y niveles pertinentes para el equilibrio de carga del tráfico de sitios web:
Como queda claro en esta lista, referirse al «equilibrio de carga de capa 4» del tráfico de Internet es una abreviatura conveniente, pero el término más exacto es «equilibrio de carga de capa 3/4», porque el equilibrador de carga basa su decisión tanto en las direcciones IP de los servidores de origen y destino (capa 3) como en el número de puerto TCP de las aplicaciones (capa 4). El término más exacto para «equilibrio de carga de capa 7» podría ser «equilibrio de carga de capa 5 a 7», porque HTTP combina las funciones de las capas 5, 6 y 7 de OSI.