Descripción general del balanceo de cargas de HTTP(S) externo

En este documento, se presentan los conceptos que debes comprender para configurar el balanceo de cargas de HTTP(S) externo de Google Cloud.

El balanceo de cargas HTTP(S) es un balanceador de cargas de capa 7 global basado en proxy que te permite ejecutar y escalar tus servicios detrás de una sola dirección IP externa. El balanceo de cargas de HTTP(S) externo distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad de plataformas de Google Cloud (como Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, etcétera), así como backends externos conectados a través de Internet o a través de la conectividad híbrida. Para obtener detalles, consulta Casos de uso.

En esta página, se describe la arquitectura de un balanceador de cargas de HTTP(S) externo independiente. Si deseas exponer tus aplicaciones de GKE a Internet, te recomendamos que uses el Ingress de GKE para el balanceo de cargas de HTTP(S) externo.

Modos de balanceadores de cargas HTTP(S) externos

Puedes configurar el balanceo de cargas de HTTP(S) externo en los siguientes modos:

  • Balanceador de cargas HTTP/S externo Este es el balanceador de cargas de HTTP(S) externo que es regional en el nivel Estándar y global en el nivel Premium. El balanceador de cargas HTTP(S) externo se implementa en Google Front End (GFE). Los GFE se distribuyen globalmente y operan juntos mediante el plano de control y la red global de Google.
  • Balanceador de cargas de HTTP(S) regional externo (Vista previa) Este es un balanceador de cargas regional se implementa como un servicio administrado en el proxy de código abierto de Envoy. Incluye capacidades avanzadas de administración de tráfico, como duplicación de tráfico, división de tráfico basada en pesos, transformaciones de encabezados basados en solicitudes y respuestas, y mucho más.
Modo de balanceador de cargas Casos de uso recomendados Funciones
Balanceador de cargas HTTP(S) externo

Este es el balanceador de cargas HTTP(S) externo que es regional en el nivel Estándar y global en el nivel Premium.

En el nivel de servicio de red Premium, el balanceador de cargas HTTP(S) externo ofrece balanceo de cargas multirregión, que dirige el tráfico al backend en buen estado más cercano que tenga capacidad y termine el tráfico HTTP(S) lo más cerca posible de tus usuarios.

En el nivel de servicio de red Estándar, el balanceo de cargas se controla a nivel regional.

Consulta la página Funciones del balanceo de cargas para ver la lista completa de funciones.
Balanceador de cargas HTTP(S) externo regional con capacidad de administración avanzada del tráfico (Vista previa)

Este balanceador de cargas contiene muchas de las características del balanceador de cargas de HTTP(S) externo existente, junto con capacidades adicionales de administración avanzada del tráfico.

Este es el balanceador de cargas HTTP(S) externo recomendado para entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las regulaciones de cumplimiento).

Usa este balanceador de cargas cuando solo se necesiten servicios de backend regionales o si deseas el Nivel de servicio de red Estándar.

Para obtener una lista completa, consulta Funciones de balanceo de cargas.

Arquitectura

Se requieren los siguientes recursos para implementar un balanceador de cargas HTTP(S) externo:

  • Solo para balanceadores de cargas HTTP(S) regionales externos, se usa una subred de solo proxy a fin de enviar conexiones desde el balanceador de cargas a los backends.

  • Una regla de reenvío externo especifica una dirección IP externa, un puerto y un proxy HTTP(S) de destino global. Los clientes usan la dirección IP y el puerto para conectarse al balanceador de cargas.

  • Un proxy HTTP(S) de destino regional recibe una solicitud del cliente. El proxy HTTP(S) evalúa la solicitud mediante el mapa de URL para tomar decisiones de enrutamiento de tráfico. El proxy también puede autenticar las comunicaciones mediante el uso de certificados SSL.

    • En el balanceo de cargas de HTTPS, el proxy HTTPS de destino usa certificados SSL para demostrar su identidad a los clientes. Un proxy HTTPS de destino admite hasta una cantidad determinada de certificados SSL.
  • El proxy HTTP(S) usa un mapa de URL regional para realizar una determinación de enrutamiento basada en atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). Según la decisión de enrutamiento, el proxy reenvía las solicitudes del cliente a servicios de backend o buckets específicos. El mapa de URL puede especificar acciones adicionales, como el envío de redireccionamientos a los clientes.

  • Un servicio de backend distribuye solicitudes a backends en buen estado. El balanceador de cargas de HTTP(S) externo también admite buckets de backend.

    • Uno o más backends deben estar conectados al servicio o al bucket de backend.
  • Una verificación de estado global supervisa de manera periódica la preparación de los backends. Esto reduce el riesgo de que las solicitudes se envíen a backends que no puedan procesar la solicitud.

  • Reglas de firewall para que tus backends acepten sondeos de verificaciones de estado. Los balanceadores de cargas de HTTP(S) regionales externos requieren una regla de firewall adicional para permitir que el tráfico de la subred de solo proxy llegue a los backends.

Modo global

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas HTTP(S) externo.

Componentes del balanceador de cargas HTTP(S) externo
Componentes del balanceador de cargas HTTP(S) externo

Modo regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas HTTP(S) regional externo.

Componentes del balanceador de cargas HTTP(S) regional externo
Componentes del balanceador de cargas HTTP(S) regional externo

Subred de solo proxy

Las subredes de solo proxy solo son necesarias para los balanceadores de cargas HTTP(S) regionales externos.

La subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de HTTP(S) regionales externos. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas de HTTP(S) regionales externos en la misma región y red de VPC comparten un grupo de proxies de Envoy de la misma subred de solo proxy. Además:

  • Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
  • Las VM de backend o los extremos de todos los balanceadores de cargas HTTP(S) regionales externos en una región y una red de VPC reciben conexiones desde la subred de solo proxy.
  • La dirección IP del balanceador de cargas HTTP(S) regional externo no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada externa, que se describe a continuación.

Direcciones y reglas de reenvío

Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino, una asignación de URL y uno o más servicios de backend.

Cada regla de reenvío proporciona una única dirección IP que se puede usar en registros DNS para tu aplicación. No se requiere el balanceo de cargas basado en DNS. Puedes especificar una dirección IP para usarla o permitir que Cloud Load Balancing te asigne una.

  • La regla de reenvío para un balanceador de cargas de HTTP solo puede hacer referencia a los puertos TCP 80 y 8080.
  • La regla de reenvío de un balanceador de cargas HTTPS solo puede hacer referencia al puerto TCP 443.

El tipo de regla de reenvío, la dirección IP y el esquema de balanceo de cargas que usan los balanceadores de cargas HTTP(S) externos dependen del modo del balanceador de cargas y del nivel de servicio de red en el que se encuentre el balanceador de cargas.

Modo de balanceador de cargas Nivel de servicio de red Regla de reenvío, dirección IP y esquema de balanceo de cargas Enrutamiento de Internet al frontend del balanceador de cargas
Balanceador de cargas HTTP(S) externo Nivel Premium

Regla de reenvío externa global

Dirección IP externa global

Esquema de balanceo de cargas:
EXTERNAL

Solicitudes enrutadas al GFE más cercano al cliente en Internet.
Nivel Estándar

Regla de reenvío regional externa

Dirección IP regional externa

Esquema de balanceo de cargas:
EXTERNAL

Solicitudes enrutadas a un GFE en la región del balanceador de cargas.
Balanceador de cargas HTTP(S) regional externo Nivel Estándar

Regla de reenvío regional externa

Dirección IP regional externa

Esquema de balanceo de cargas:
EXTERNAL_MANAGED

Solicitudes enrutadas a los proxies de Envoy en la misma región que el balanceador de cargas.

Para obtener una lista completa de los protocolos que admiten las reglas de reenvío de balanceo de cargas HTTP(S) en cada modo, consulta Funciones del balanceador de cargas.

Proxies de destino

Los proxies de destino finalizan las conexiones HTTP(S) de los clientes. Una o más reglas de reenvío dirigen el tráfico al proxy de destino y este consulta el mapa de URL para determinar cómo dirigir el tráfico a los backends.

No dependas del proxy para conservar las mayúsculas de los nombres de encabezado de solicitud o respuesta. Por ejemplo, es posible que un encabezado de respuesta Server: Apache/1.0 aparezca en el cliente como server: Apache/1.0.

En la siguiente tabla, se especifica el tipo de proxy de destino que requieren los balanceadores de cargas HTTP(S) externos en cada modo.

Modo de balanceador de cargas Tipos de proxy de destino Encabezados agregados por proxy Los Encabezados personalizados son compatibles Compatible con Cloud Trace
Balanceador de cargas HTTP(S) externo HTTP global,
HTTPS global
Los proxies configuran encabezados de solicitud o respuesta HTTP de la siguiente manera:
  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-Proto: [http | https] (solo solicitudes)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo solicitudes)
    Contiene parámetros de Cloud Trace.
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta encabezado X-Forwarded-For) (solo solicitudes)
Configurado en el servicio o bucket de backend
Balanceador de cargas HTTP(S) regional externo HTTP regional,
HTTPS regional
  • X-Forwarded-Proto: [http | https] (solo solicitudes)
  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulta encabezado X-Forwarded-For) (solo solicitudes)

Encabezado del host

Cuando el balanceador de cargas realiza la solicitud HTTP, el balanceador de cargas conserva el encabezado del host de la solicitud original.

Encabezado X-Forwarded-For

El balanceador de cargas agrega dos direcciones IP separadas por una sola coma al encabezado X-Forwarded-For en el siguiente orden:

  • La dirección IP del cliente que se conecta al balanceador de cargas
  • La dirección IP de la regla de reenvío del balanceador de cargas

Si no hay un encabezado X-Forwarded-For en la solicitud entrante, estas dos direcciones IP son el valor completo del encabezado.

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Si la solicitud incluye un encabezado X-Forwarded-For, el balanceador de cargas conserva el valor proporcionado antes de <client-ip>,<load-balancer-ip>:

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

Cuando ejecutas el software del proxy HTTP inverso en los backends del balanceador de cargas, el software puede adjuntar una o las siguientes dos direcciones IP al final del encabezado X-Forwarded-For:

  • La dirección IP del Google Front End (GFE) que se conectó al backend. Estas direcciones IP se encuentran en los rangos 130.211.0.0/22 y 35.191.0.0/16.

  • La dirección IP del sistema de backend en sí.

Por lo tanto, un proceso ascendente después del backend de tu balanceador de cargas podría recibir un encabezado X-Forwarded-For con el siguiente formato:

<existing-values>,<client-ip>,<load-balancer-ip><GFE-IP><backend-IP>

Compatibilidad con los protocolos HTTP/3 y QUIC

HTTP/3 es un protocolo de Internet de última generación. Se basa en QUIC, un protocolo desarrollado a partir del protocolo Google QUIC original (gQUIC). HTTP/3 es compatible entre el balanceador de cargas HTTP(S) externo, Cloud CDN y los clientes.

En particular, haz lo siguiente:

  • QUIC es un protocolo de capa de transporte que proporciona control de congestión similar a TCP. También proporciona seguridad equivalente a SSL/TLS para HTTP/2 con un rendimiento mejorado.
  • HTTP/3 es una capa de aplicación basada en IETF QUIC y utiliza QUIC para manejar la multiplexación, el control de la congestión y los reintentos.
  • HTTP/3 permite un inicio más rápido de la conexión del cliente, resuelve el bloqueo de línea en las transmisiones multiplexadas y admite la migración de conexión cuando cambia la dirección IP de un cliente.
  • Afecta las conexiones entre los clientes y el balanceador de cargas, no aquellas conexiones entre el balanceador de cargas y sus backends.
  • Las conexiones HTTP/3 usan el protocolo de control de congestión BBR.

Habilitar HTTP/3 en el balanceador de cargas de HTTP(S) externo puede mejorar los tiempos de carga de las páginas web, reducir el realmacenamiento en búfer de video y mejorar la capacidad de procesamiento en las conexiones de latencia más alta.

Configura HTTP/3

Puedes habilitar de forma explícita la compatibilidad con HTTP/3 para tu balanceador de cargas de HTTP(S) externo si configuras quicOverride como ENABLE. En el futuro, HTTP/3 se habilitará de forma predeterminada para todos los clientes externos de balanceador de cargas HTTP(S).

Los clientes que no admiten HTTP/3 ni gQUIC no negocian una conexión HTTP/3. No es necesario que inhabilites HTTP/3 de forma explícita, a menos que hayas identificado implementaciones cliente dañadas o antiguas.

El balanceador de cargas HTTP(S) externo proporciona tres modos para configurar HTTP/3 como se muestra en la siguiente tabla.

Valor quicOverride Comportamiento
NONE

HTTP/3 y Google QUIC no se anuncian a los clientes.

Nota: Esto podría cambiar en el futuro, y HTTP/3 se anunciará a los clientes de forma predeterminada.

ENABLE

La compatibilidad con HTTP/3 y Google QUIC se anuncia a los clientes. HTTP/3 se anuncia con mayor prioridad. Los clientes que admiten ambos protocolos deben preferir HTTP/3 sobre Google QUIC.

Nota: TLS 0-RTT (también conocido como datos anticipados de TLS) es compatible de manera implícita cuando el cliente negocia Google QUIC, pero no lo es actualmente cuando se usa HTTP/3.

DISABLE Inhabilita de manera explícita publicidad de HTTP/3 y Google QUIC para los clientes.

Si deseas habilitar (o inhabilitar) HTTP/3 explícitamente, sigue estos pasos.

Console: HTTPS

  1. En Google Cloud Console, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. Selecciona el balanceador de cargas HTTP(S) externo que deseas editar.

  3. Haga clic en Configuración de frontend.

  4. Selecciona la dirección IP y el puerto de frontend que deseas editar. Para editar la configuración de HTTP/3, la dirección IP y el puerto deben ser HTTPS (puerto 443).

Habilita HTTP/3

  1. Selecciona el menú desplegable Negociación de QUIC.
  2. Si quieres habilitar HTTP/3 para este frontend de forma explícita, selecciona Habilitado.
  3. Si tienes varias reglas de frontend que representan IPv4 y, también, IPv6, asegúrate de habilitar HTTP/3 en cada regla.

Inhabilita HTTP/3.

  1. Selecciona el menú desplegable Negociación de QUIC.
  2. Si quieres inhabilitar HTTP/3 para este frontend de forma explícita, selecciona Inhabilitado.
  3. Si tienes varias reglas de frontend que representan IPv4 y, también, IPv6, asegúrate de inhabilitar HTTP/3 para cada regla.

gcloud: HTTPS

Antes de que ejecutes este comando, debes crear un recurso de certificado SSL para cada certificado.

 gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
     --global \
     --quic-override=QUIC_SETTING

Reemplaza QUIC_SETTING por uno de los siguientes valores:

  • NONE (predeterminado) le permite a Google controlar cuándo se negocia QUIC.

    En este momento, cuando seleccionas NONE, QUIC está inhabilitado. Si seleccionas esta opción, permitirás que Google habilite de forma automática las negociaciones de QUIC y HTTP/3 en el futuro para este balanceador de cargas. En Cloud Console, esta opción se llama Automática (predeterminado).

  • ENABLE: Anuncia HTTP/3 y Google QUIC a los clientes

  • DISABLE: No anuncia HTTP/3 ni Google QUIC a los clientes.

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Reemplaza QUIC_SETTING por uno de los siguientes valores:

  • NONE (predeterminado) le permite a Google controlar cuándo se negocia QUIC.

    En este momento, cuando seleccionas NONE, QUIC está inhabilitado. Si seleccionas esta opción, permitirás que Google habilite de forma automática las negociaciones de QUIC y HTTP/3 en el futuro para este balanceador de cargas. En Cloud Console, esta opción se llama Automática (predeterminado).

  • ENABLE: Anuncia HTTP/3 y Google QUIC a los clientes

  • DISABLE: No anuncia HTTP/3 ni Google QUIC a los clientes.

Cómo se negocia HTTP/3

Cuando HTTP/3 está habilitado, el balanceador de cargas anuncia esta compatibilidad a los clientes, de manera que los clientes que admiten HTTP/3 intenten establecer conexiones HTTP/3 con el balanceador de cargas HTTPS.

  • Los clientes implementados de forma correcta siempre recurren a HTTPS o HTTP/2 cuando no pueden establecer una conexión QUIC.
  • Los clientes que admiten HTTP/3 usan su conocimiento previo almacenado en caché de la compatibilidad con HTTP/3 para ahorrar idas y vueltas innecesarias en el futuro.
  • Debido a esta solución alternativa, habilitar o inhabilitar QUIC en el balanceador de cargas no interrumpe la capacidad de este para conectarse con los clientes.

La compatibilidad se anuncia en el encabezado de respuesta HTTP Alt-Svc. Cuando HTTP/3 se configura como ENABLE en el recurso targetHttpsProxy del balanceador de cargas HTTP(S) externo, las respuestas del balanceador de cargas HTTP(S) externo incluyen el siguiente valor de encabezado alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

Si HTTP/3 se configuró de forma explícita como DISABLE, las respuestas no incluyen un encabezado de respuesta alt-svc.

Cuando tienes QUIC habilitado en el balanceador de cargas de HTTPS, algunas circunstancias pueden hacer que tu cliente recurra a HTTPS o HTTP/2 en lugar de negociar QUIC. Esto incluye los siguientes casos:

  • Cuando un cliente admite versiones de HTTP/3 que no son compatibles con las versiones de HTTP/3 compatibles con el balanceador de cargas HTTPS
  • Cuando el balanceador de cargas detecta que el tráfico de UDP está bloqueado o sometido a un límite de frecuencia tal que impediría el funcionamiento de HTTP/3 QUIC
  • Si el cliente no admite HTTP/3 en absoluto y, por lo tanto, no intenta negociar una conexión HTTP/3

Cuando una conexión recurre a HTTPS o HTTP/2 debido a estas circunstancias, no consideramos esto como una falla del balanceador de cargas.

Antes de habilitar HTTP/3, asegúrate de que los comportamientos descritos anteriormente sean aceptables para tus cargas de trabajo.

Mapas de URL

Las asignaciones de URL definen los patrones de coincidencia para el enrutamiento basado en URL de las solicitudes a los servicios de backend apropiados. Se define un servicio predeterminado para manejar cualquier solicitud que no coincida con una regla de coincidencia de ruta o una regla de host especificadas. En algunas situaciones, como en el ejemplo de balanceo de cargas multirregional, es posible que no definas ninguna regla de URL y solo te bases en el servicio predeterminado. Para el enrutamiento de solicitudes, el mapa de URL te permite dividir el tráfico mediante el análisis de los componentes de URL a fin de enviar solicitudes a diferentes conjuntos de backends.

En la siguiente tabla, se especifica el tipo de mapa de URL que requieren los balanceadores de cargas HTTP(S) externos en cada modo.

Modo de balanceador de cargas Tipo de mapa de URL
Balanceador de cargas HTTP(S) externo Global (solo con un subconjunto de las funciones compatibles)
Balanceador de cargas HTTP(S) regional externo Regional

Certificado SSL

La seguridad de la capa de transporte (TLS) es un protocolo de encriptación que se usa en los certificados SSL para proteger las comunicaciones de redes.

Google Cloud usa certificados SSL para proporcionar privacidad y seguridad desde un cliente hacia un balanceador de cargas. Si usas el balanceo de cargas basado en HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino.

En la siguiente tabla, se especifica el alcance del certificado SSL que requieren los balanceadores de cargas HTTP(S) externos en cada modo:

Modo de balanceador de cargas Alcance de los certificados SSL
Balanceador de cargas HTTP(S) externo Global
Balanceador de cargas HTTP(S) regional externo Regional

Para obtener más información sobre los certificados SSL, consulta lo siguiente:

Políticas de SSL

Las políticas de SSL te permiten controlar las funciones de SSL que el balanceador de cargas HTTPS negocia con clientes HTTPS.

De forma predeterminada, el balanceo de cargas HTTPS usa un conjunto de funciones de SSL que proporciona una buena seguridad y una amplia compatibilidad. Algunas aplicaciones requieren más control sobre los cifrados y las versiones de SSL que se usan para sus conexiones HTTPS o SSL. Puedes definir políticas de SSL para controlar las características de SSL que tu balanceador de cargas negocia y asocia una política de SSL con tu proxy HTTPS de destino.

Servicios y buckets de backend

El balanceador de cargas HTTP(S) externo puede tener servicios de backend y buckets de backend. El balanceador de cargas HTTP(S) regional externo no admite buckets de backend.

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Los balanceadores de cargas usan la información en el servicio de backend para dirigir el tráfico entrante a uno o más backends conectados. Para ver un ejemplo que muestra cómo configurar un balanceador de cargas con un servicio de backend y uno de Compute Engine, consulta Configura un balanceador de cargas HTTP(S) externo con un backend de Compute Engine.

Los buckets de backend dirigen el tráfico entrante a los buckets de Cloud Storage. Para ver un ejemplo que muestra cómo agregar un bucket a un balanceador de cargas HTTP(S) externo, consulta Configura un balanceador de cargas con buckets de backend.

Si quieres configurar un balanceador de cargas HTTP(S) externo mediante HTTP/2 con Ingress de Google Kubernetes Engine o mediante gRPC y HTTP/2 con Ingress, consulta HTTP/2 para el balanceo de cargas con Ingress.

En la siguiente tabla, se especifican los atributos de backend compatibles con el balanceo de cargas de HTTP(S).


Modo de balanceador de cargas
Backends compatibles en un servicio de backend Compatible con buckets de backend Compatible con Google Cloud Armor Compatible con Cloud CDN Compatible con IAP
Grupos de instancias NEG zonales NEG de Internet NEG sin servidores NEG híbridos
Balanceador de cargas HTTP(S) externo
cuando se usa el nivel Premium

Balanceador de cargas HTTP(S) regional externo

Para obtener más información, consulta lo siguiente:

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas de HTTP(S) externo, debes configurar el protocolo que usa el servicio de backend a fin de comunicarse con otros. Puedes elegir entre HTTP, HTTPS o HTTP/2. El balanceador de cargas usa solo el protocolo que especifiques. El balanceador de cargas no recurre a uno de los otros protocolos si no logra negociar una conexión al backend con el protocolo especificado.

Si usas HTTP/2, debes usar TLS. No se admite HTTP/2 sin encriptación.

Para obtener una lista completa de los protocolos admitidos, consulta Características del balanceo de cargas: protocolos del balanceador de cargas a los backends.

Compatible con WebSocket

Los balanceadores de cargas basados en HTTP(S) de Google Cloud tienen compatibilidad nativa con el protocolo WebSocket cuando se usa HTTP o HTTPS como el protocolo para el backend. El balanceador de cargas no necesita ninguna configuración para usar un proxy en las conexiones de WebSocket.

El protocolo WebSocket proporciona un canal de comunicación dúplex completo entre clientes y servidores. Una solicitud HTTP(S) inicia el canal. Para obtener información detallada sobre el protocolo, consulta RFC 6455.

Cuando el balanceador de cargas reconoce una solicitud Upgrade de WebSocket de un cliente HTTP(S) seguida de una respuesta Upgrade correcta de la instancia de backend, el balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual. Si la instancia de backend no muestra una respuesta Upgrade correcta, el balanceador de cargas cierra la conexión.

El tiempo de espera para una conexión de WebSocket depende del tiempo de espera del servicio de backend configurable del balanceador de cargas, que es de 30 segundos según la configuración predeterminada. Este tiempo de espera se aplica a las conexiones de WebSocket sin importar si están en uso.

La afinidad de sesión para WebSockets funciona de la misma manera que en cualquier otra solicitud. Para obtener información, consulta Afinidad de sesión.

Usa gRPC con tus aplicaciones de Google Cloud

gRPC es un framework de código abierto para llamadas de procedimiento remoto. Se basa en el estándar HTTP/2. Los casos prácticos para gRPC incluyen lo siguiente:

  • Sistemas distribuidos altamente escalables y de baja latencia
  • Desarrollo de clientes móviles que se comuniquen con un servidor en la nube
  • Diseño de protocolos nuevos que deben ser precisos, independientes del lenguaje y eficientes
  • Diseño en capas para habilitar extensiones, autenticación y registros

Para usar gRPC con tus aplicaciones de Google Cloud, debes usar las solicitudes del proxy de extremo a extremo en HTTP/2. Para hacerlo con un balanceador de cargas de HTTP(S) externo, sigue estos pasos:

  1. Configura un balanceador de cargas HTTPS.
  2. Habilita HTTP/2 como protocolo desde el balanceador de cargas hasta los backends.

El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL mediante la extensión ALPN TLS.

Es posible que el balanceador de cargas aún negocie HTTPS con algunos clientes o acepte solicitudes HTTP no seguras en un balanceador de cargas de HTTP(S) externo configurado para usar HTTP/2 entre las instancias del backend y el balanceador de cargas. El balanceador de cargas transforma esas solicitudes HTTP o HTTPS para representar las solicitudes a través de HTTP/2 en las instancias de backend.

Debes habilitar TLS en tus backends. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Si quieres configurar un balanceador de cargas de HTTP(S) externo mediante HTTP/2 con Ingress de Google Kubernetes Engine o mediante gRPC y HTTP/2 con Ingress, consulta HTTP/2 para el balanceo de cargas con Ingress.

Para obtener información sobre cómo solucionar problemas con HTTP/2, consulta Soluciona problemas de los backends con HTTP/2.

Para obtener información sobre las limitaciones de HTTP/2, consulta Limitaciones de HTTP/2.

Verificaciones de estado

Cada servicio de backend especifica una verificación de estado para las instancias de backend.

Para los sondeos de verificación de estado, debes crear una regla de firewall de permiso de entrada que permita que el tráfico llegue a tus instancias de backend. La regla de firewall debe permitir los siguientes rangos de origen:

  • 130.211.0.0/22
  • 35.191.0.0/16

Aunque no es obligatorio, se recomienda usar una verificación de estado cuyo protocolo coincida con el protocolo del servicio de backend. Por ejemplo, una verificación de estado HTTP/2 comprueba de forma más precisa la conectividad HTTP/2 con los backends. Para obtener la lista de protocolos de verificación de estado compatibles, consulta Funciones del balanceo de cargas.

En la siguiente tabla, se especifica el alcance de la verificación de estado que admiten los balanceadores de cargas HTTP(S) externos en cada modo.

Modo de balanceador de cargas Tipo de verificación de estado
Balanceador de cargas HTTP(S) externo Global
Balanceador de cargas HTTP(S) regional externo Regional

Para obtener más información sobre las verificaciones de estado, consulta los siguientes vínculos:

Reglas de firewall

Un balanceador de cargas HTTP(S) externo requiere las siguientes reglas de firewall:

  • En el balanceador de cargas HTTP(S) externo, una regla de permiso de entrada que permite que el tráfico de Google Front End (GFE) llegue a tus backends.
    Para el balanceador de cargas HTTP(S) regional externo, una regla de permiso de entrada que permite el tráfico desde la subred de solo proxy.
  • Una regla de permiso de entrada que permita el tráfico de los rangos de sondelo de verificación de estado Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico de ellos, consulta Sondea rangos de IP y reglas de firewall.

Los puertos de estas reglas de firewall deben configurarse de la siguiente manera:

  • Permite el tráfico al puerto de destino para cada verificación de estado del servicio de backend.

  • Para los backends de grupos de instancias: determina los puertos que se configurarán mediante la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados con ese puerto con nombre en cada grupo de instancias. Los números pueden variar entre grupos de instancias asignados al mismo servicio de backend.

  • Para los backends de NEG GCE_VM_IP_PORT: permite el tráfico a los números de puerto de los extremos.

Las reglas de firewall se implementan a nivel de la instancia de VM, no en los proxies de GFE. No puedes usar las reglas de firewall de Google Cloud para evitar que el tráfico llegue al balanceador de cargas. Para el balanceador de cargas HTTP(S) externo, puedes usar Google Cloud Armor a fin de lograrlo.

En los balanceadores de cargas HTTP(S) externos, la siguiente tabla resume los rangos de direcciones IP necesarios para las reglas de firewall:

Modo de balanceador de cargas Rangos de origen de la verificación de estado Rangos de origen de solicitud
Balanceador de cargas HTTP(S) externo
  • 130.211.0.0/22
  • 35.191.0.0/16
La fuente de tráfico del GFE depende del tipo de backend:
  • Grupos de instancias, NEG zonales (GCE_VM_IP_PORT) y NEG de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT):
    • 130.211.0.0/22
    • 35.191.0.0/16
  • NEG de Internet (INTERNET_FQDN_PORT y INTERNET_IP_PORT):
    • 34.96.0.0/20
    • 34.127.192.0/18
  • NEG SERVERLESS y buckets de backend: la red de producción de Google controla el enrutamiento de paquetes.
Balanceador de cargas HTTP(S) regional externo
  • 130.211.0.0/22
  • 35.191.0.0/16
La subred de solo proxy que configuras.

Cómo funcionan las conexiones en el balanceo de cargas de HTTP(S)

Conexiones del balanceador de cargas HTTP(S) externo

El balanceador de cargas de HTTP(S) externo es un servicio implementado por muchos proxies llamados Google Front End (GFE). No hay un solo proxy. En el nivel Premium, la misma dirección IP externa global se anuncia desde varios puntos de presencia y las solicitudes de los clientes se dirigen al GFE del cliente más cercano.

Según dónde se encuentren tus clientes, varios GFE pueden iniciar conexiones HTTP(S) con tus backends. Los paquetes enviados desde GFE tienen direcciones IP de origen del mismo rango que usan los verificadores de estado: 35.191.0.0/16130.211.0.0/22.

Según la configuración del servicio de backend, el protocolo que usa cada GFE para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Para las conexiones HTTP o HTTPS, la versión HTTP que se usa es HTTP 1.1.

El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. Los keepalives de HTTP intentan usar la misma sesión de TCP de forma eficiente; sin embargo, no hay garantía. GFE usa un tiempo de espera de 600 segundos para el keepalive, y no puedes configurarlo. Sin embargo, puedes configurar el tiempo de espera de la solicitud o la respuesta mediante la configuración del tiempo de espera del servicio de backend. Aunque están muy relacionados, un tiempo de espera de keepalive de HTTP y uno de inactividad de TCP no son lo mismo. Para obtener más información, consulta Tiempos de espera y reintentos.

La cantidad de conexiones HTTP y sesiones TCP varía según la cantidad de conexiones de GFE, la cantidad de clientes que se conectan a GFE, el protocolo a los backends y la ubicación de implementación de backends.

Para obtener más información, consulta Cómo funciona el balanceo de cargas de HTTP(S) en la guía de soluciones: Optimizaciones de la capacidad de las aplicaciones con el balanceo de cargas global.

Conexiones del balanceador de cargas HTTP(S) regional externo

El balanceador de cargas de HTTP(S) externo regional es un servicio administrado que se implementa en el proxy de Envoy. El balanceador de cargas de HTTP(S) externo regional usa una subred compartida llamada subred de solo proxy para aprovisionar un conjunto de direcciones IP que Google usa a fin de ejecutar proxies de Envoy en tu nombre. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas de HTTP(S) externos regionales en una red y una región en particular comparten esta subred.

Los clientes usan la dirección IP y el puerto del balanceador de cargas para conectarse al balanceador de cargas. Las solicitudes del cliente se dirigen a la subred de solo proxy en la misma región que el cliente. El balanceador de cargas finaliza las solicitudes de los clientes y abre conexiones nuevas de la subred de solo proxy a tus backends. Por lo tanto, los paquetes enviados desde el balanceador de cargas tienen direcciones IP de origen de la subred de solo proxy.

Según la configuración del servicio de backend, el protocolo que usan los proxies de Envoy para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Si es HTTP o HTTPS, la versión HTTP es HTTP 1.1. El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. El proxy de Envoy usa un tiempo de espera de keepalive de 600 segundos, y no puedes configurarlo. Sin embargo, puedes configurar el tiempo de espera de la solicitud o la respuesta mediante la configuración del tiempo de espera del servicio de backend. Para obtener más información, consulta Tiempos de espera y reintentos.

Comunicaciones del cliente con el balanceador de cargas

  • Los clientes se pueden comunicar con el balanceador de cargas mediante el protocolo HTTP 1.1 o HTTP/2.
  • Cuando se usa HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas de HTTPS.
  • No puedes inhabilitar HTTP/2 aunque realices un cambio de configuración en el balanceador de cargas. Sin embargo, puedes configurar algunos clientes para usar HTTP 1.1 en lugar de HTTP/2. Por ejemplo, con curl, usa el parámetro --http1.1.
  • El balanceo de cargas HTTP(S) admite la respuesta HTTP/1.1 100 Continue.

Para obtener una lista completa de los protocolos que admiten las reglas de reenvío de balanceo de cargas HTTP(S) en cada modo, consulta Funciones del balanceador de cargas.

Direcciones IP de origen para paquetes de clientes

La dirección IP de origen de los paquetes, como la ven los backends, no es la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos conexiones TCP.

Para el balanceador de cargas HTTP(S) externo:
  • Sesión 1, que abarca desde el cliente original hasta el balanceador de cargas (GFE):

    • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.
  • Conexión 2, desde el balanceador de cargas (GFE) hasta el extremo o la VM de backend:

    • Dirección IP de origen: Es una dirección IP en uno de los rangos especificados en Reglas de firewall.

    • Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.

Para el balanceador de cargas HTTP(S) regional externo:

  • Conexión 1, desde el cliente original hasta el balanceador de cargas (subred de solo proxy):

    • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.
  • Conexión 2, desde el balanceador de cargas (subred de solo proxy) hasta la VM o el extremo de backend:

    • Dirección IP de origen: Una dirección IP en la subred de solo proxy que se comparte entre todos los balanceadores de cargas basados en Envoy implementados en la misma región y la red como el balanceador de cargas.

    • Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.

Ruta de acceso de retorno

En el caso de los balanceadores de cargas HTTP(S) externos, Google Cloud usa rutas especiales no definidas en tu red de VPC para las verificaciones de estado. Para obtener más información, consulta Rutas de acceso de retorno del balanceador de cargas.

Para los balanceadores de cargas de HTTP(S) regionales, Google Cloud usa proxies de Envoy de código abierto a fin de finalizar las solicitudes de los clientes al balanceador de cargas. El balanceador de cargas finaliza la sesión TCP y abre una nueva sesión TCP desde la subred de solo proxy de la región a tu backend. Las rutas definidas dentro de la red de VPC facilitan la comunicación de los proxies de Envoy a los backends y de los backends a los proxies de Envoy.

Puertos abiertos

Esta sección se aplica solo al balanceador de cargas HTTP(S) externo, que se implementa mediante GFE.

Los GFE tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Para ver una lista de algunos de los puertos que pueden estar abiertos en los GFE, consulta Regla de reenvío: especificaciones de puertos. Es posible que haya otros puertos abiertos para otros servicios de Google que se ejecutan en GFE.

Ejecutar un análisis de puerto en la dirección IP de un balanceador de cargas basado en GFE no es útil desde la perspectiva de la auditoría por los siguientes motivos:

  • Por lo general, un análisis de puerto (por ejemplo, con nmap) no espera ningún paquete de respuesta o un paquete RST de TCP cuando realiza sondeos de TCP SYN. Los GFE enviarán paquetes SYN-ACK en respuesta a los sondeos de SYN de una variedad de puertos si el balanceador de cargas usa una dirección IP del nivel Premium. Sin embargo, los GFE solo envían paquetes a tus backends en respuesta a los paquetes enviados a la dirección IP del balanceador de cargas y al puerto de destino configurado en su regla de reenvío. Los paquetes enviados a direcciones IP de balanceador de cargas diferentes o la dirección IP del balanceador de cargas en un puerto que no se configuró en la regla de reenvío no tienen como resultado que los paquetes se envíen a los backends del balanceador de cargas. Los GFE implementan funciones de seguridad como Google Cloud Armor. Incluso sin una configuración de Google Cloud Armor, la infraestructura de Google y los GFE proporcionan una defensa en profundidad para los ataques de DSD y desbordamientos SYN.

  • Cualquier GFE en la flota de Google puede responder a los paquetes enviados a la dirección IP de tu balanceador de cargas. Sin embargo, el análisis de una combinación de direcciones IP del balanceador de cargas y del puerto de destino solo intercepta un solo GFE por conexión TCP. La dirección IP de tu balanceador de cargas no se asigna a un solo dispositivo o sistema. Por lo tanto, analizar la dirección IP de un balanceador de cargas basado en GFE no analiza todos los GFE de la flota de Google.

Con esto en mente, las siguientes son algunas formas más efectivas de auditar la seguridad de tus instancias de backend:

  • Un auditor de seguridad debe inspeccionar la configuración de reglas de reenvío para la configuración del balanceador de cargas. Las reglas de reenvío definen el puerto de destino para el que tu balanceador de cargas acepta paquetes y los reenvía a los backends. Para los balanceadores de cargas basados en GFE, cada regla de reenvío externo solo puede hacer referencia a un solo puerto TCP de destino. Para un balanceador de cargas HTTP(S) externo que usa el puerto TCP 443, se usa el puerto UDP 443 cuando la conexión se actualiza a QUIC (HTTP/3).

  • Un auditor de seguridad debe inspeccionar la configuración de la regla de firewall aplicable a las VM de backend. Las reglas de firewall que configuras bloquean el tráfico desde los GFE hacia las VM de backend, pero no bloquean el tráfico entrante a los GFE. Si deseas conocer prácticas recomendadas, consulta la sección de reglas de firewall.

finalización de TLS

En la siguiente tabla, se resume cómo los balanceadores de cargas HTTP(S) externos controlan la finalización de TLS en cada modo.

Modo de balanceador de cargas finalización de TLS
Balanceador de cargas HTTP(S) externo La TLS se finaliza en un GFE, que puede estar en cualquier parte del mundo.
Balanceador de cargas HTTP(S) regional externo TLS finaliza en proxies de Envoy ubicados en una subred de solo proxy en una región elegida por el usuario. Usa este modo de balanceador de cargas si necesitas control geográfico sobre la región en la que se finaliza TLS.

Tiempos de espera y reintentos

El balanceo de cargas de HTTP(S) tiene dos tipos distintos de tiempos de espera:
  • Un tiempo de espera del servicio de backend HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera para que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos. El rango completo de valores de tiempo de espera permitidos es de 1 a 2,147,483,647 segundos.

    Para el tráfico HTTP, este tiempo de espera es la duración máxima de la solicitud y la respuesta HTTP.

    Para el tráfico WebSocket, este tiempo de espera es la cantidad máxima de tiempo que una conexión WebSocket puede permanecer abierta, ya sea que esté inactiva o activa.

    Considera aumentar este tiempo de espera en cualquiera de estas circunstancias:

    • Si esperas que un backend tarde más en mostrar respuestas HTTP
    • Si ves una respuesta HTTP 408 con jsonPayload.statusDetail client_timed_out.
    • La conexión se actualiza a un WebSocket.

    Por ejemplo, un valor de tiempo de espera práctico para los balanceadores de cargas HTTP(S) externos es de 1 día (86,400 segundos). Ten en cuenta que los eventos como los reinicios de GFE pueden hacer que las sesiones finalicen antes que este tiempo de espera.

    Nota: El tiempo de espera del servicio de backend no es un tiempo de espera de HTTP inactivo (keepalive). Es posible que la entrada y salida (IO) del backend se bloquee debido a un cliente lento (por ejemplo, un navegador con conexión lenta). Este tiempo de espera no se toma en cuenta en el tiempo de espera del servicio de backend.

    Para balanceadores de cargas de HTTP(S) regionales, el parámetro routeActions.timeout del mapa de URL puede anular el tiempo de espera del servicio de backend. El tiempo de espera del servicio de backend se usa como el valor predeterminado para routeActions.timeout.

  • Un tiempo de espera de keepalive de HTTP, cuyo valor se fija en 10 minutos (600 segundos). Este valor no se puede configurar mediante la modificación del servicio de backend. Debes configurar el software del servidor web que usan tus backends para que su tiempo de espera keepalive sea superior a 600 segundos a fin de evitar que el backend cierre de forma prematura las conexiones. Este tiempo de espera no se aplica a WebSockets.

    En esta tabla, se ilustran los cambios necesarios a fin de modificar los tiempos de espera de keepalive para el software del servidor web común:

    Software del servidor web Parámetro Parámetro de configuración predeterminado Configuración recomendada
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
La compatibilidad del balanceo de cargas de HTTP(S) para la lógica de reintento depende del modo del balanceador de cargas HTTP(S) externo.

Modo de balanceador de cargas Lógica de reintento
Balanceador de cargas HTTP(S) externo

No se puede cambiar la política de reintento.

Las solicitudes HTTP POST no se reintentan.

Las solicitudes HTTP GET siempre se reintentan una vez, siempre y cuando el 80% o más de los backends estén en buen estado. Si hay una sola instancia de backend en un grupo y falla la conexión, el porcentaje de instancias de backend en mal estado es del 100%, por lo que GFE no vuelve a intentar la solicitud.

El balanceador de cargas reintenta las solicitudes GET que fallaron en ciertas circunstancias, como cuando se agota el tiempo de espera del servicio de backend. Solo se puede reintentar dos veces. Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final. Para obtener más información, consulta Registro y supervisión del balanceo de cargas de HTTP(S).

Las solicitudes que no se ejecutan de forma correcta dan como resultado que el balanceador de cargas sintetiza una respuesta HTTP 502.

Balanceador de cargas HTTP(S) regional externo

Se puede configurar mediante una política de reintento en el mapa de URL.

Sin una política de reintento, las solicitudes que no tienen cuerpo HTTP (por ejemplo, solicitudes GET) se reintentan una vez.

El protocolo WebSocket es compatible con Ingress.

Solicitud ilegal y manejo de respuestas

El balanceador de cargas de HTTP(S) externo impide que las solicitudes de clientes y las respuestas de backend lleguen al backend o al cliente, respectivamente, por varios motivos. Algunas razones son solo para el cumplimiento de HTTP/1.1 y otras para evitar que se pasen datos inesperados a los backends o desde ellos. No se puede inhabilitar ninguna de las verificaciones.

El balanceador de cargas bloquea lo siguiente para el cumplimiento de HTTP/1.1:

  • No se puede analizar la primera línea de la solicitud.
  • A un encabezado le falta el delimitador :.
  • Los encabezados o la primera línea contienen caracteres no válidos.
  • La longitud del contenido no es un número válido o hay varios encabezados de longitud del contenido.
  • Hay varias claves de codificación de transferencia o hay valores de codificación de transferencia no reconocidos.
  • Hay un cuerpo no fragmentado y no se especifica la longitud del contenido.
  • Los fragmentos del cuerpo no se pueden analizar. Este es el único caso en el que algunos datos llegan al backend. El balanceador de cargas cierra las conexiones con el cliente y el backend cuando recibe un fragmento no analizable.

El balanceador de cargas bloquea la solicitud si se cumple alguna de las siguientes condiciones:

El balanceador de cargas bloquea la respuesta del backend si se cumple alguna de las siguientes condiciones:

  • El tamaño total de los encabezados de respuesta supera el límite del tamaño máximo del encabezado de respuesta del balanceo de cargas de HTTP(S) externo.
  • La versión HTTP es desconocida.

Distribución de tráfico

Cuando agregas un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo, que define un método que mide la carga de backend y una capacidad objetivo. El balanceo de cargas de HTTP(S) externo admite dos modos de balanceo:

  • RATE, para grupos de instancias o NEG, es la cantidad máxima de solicitudes (consultas) de destino por segundo (RPS, QPS). Se puede exceder la cantidad máxima de RPS/QPS si se alcanza o supera la capacidad de todos los backends.

  • UTILIZATION es el uso de backend de las VM en un grupo de instancias.

La forma en que se distribuye el tráfico entre backends depende del modo del balanceador de cargas HTTP(S) externo.

Distribución de tráfico del balanceador de cargas HTTP(S) externo

Antes de que Google Front End (GFE) envíe solicitudes a instancias de backend, GFE estima qué instancias de backend tienen capacidad para recibir solicitudes. Esta estimación de capacidad se realiza de forma proactiva, no al mismo tiempo que cuando llegan las solicitudes. Los GFE reciben información de manera periódica sobre la capacidad disponible y distribuyen las solicitudes entrantes según corresponda.

El significado de capacidad depende en parte del modo de balanceo. Para el modo RATE, es bastante simple: un GFE determina con exactitud cuántas solicitudes puede asignar por segundo. El balanceo de cargas basado en UTILIZATION es más complejo: el balanceador de cargas verifica el uso actual de las instancias y, luego, calcula una carga de consulta que cada instancia puede controlar. Esta estimación cambia a medida que cambian el uso de la instancia y los patrones de tráfico.

Ambos factores, la estimación de capacidad y la asignación proactiva, influyen en la distribución entre las instancias. Por lo tanto, Cloud Load Balancing se comporta de manera diferente a un balanceador de cargas round robin simple que distribuye las solicitudes en 50:50 exactas entre dos instancias. En cambio, el balanceo de cargas de Google Cloud intenta optimizar la selección de la instancia de backend para cada solicitud.

Para obtener más información, consulta Distribución de tráfico.

Distribución de tráfico del balanceador de cargas HTTP(S) regional externo

Para un balanceador de cargas HTTP(S) regional externo, la distribución del tráfico se basa en el modo de balanceo de cargas y la política de localidad del balanceo de cargas.

El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada grupo (grupo de instancias o NEG). La política de localidad del balanceo de cargas (LocalityLbPolicy) determina cómo se balancean las cargas del backend dentro del grupo.

Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (grupo de instancias o NEG) según el modo de balanceo del backend. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos en ese grupo de backend de acuerdo con la política de localidad del balanceo de cargas.

Para obtener más información, consulte:

Cómo se distribuyen las solicitudes

Que el tráfico se distribuya de forma regional o global depende del modo de balanceador de cargas y el nivel de servicio de red que esté en uso.

Para el nivel Premium (solo se aplica al balanceador de cargas HTTP(S) externo):

  • Google hace pública la dirección IP del balanceador de cargas desde todos los puntos de presencia y en todo el mundo. Cada dirección IP del balanceador de cargas es Anycast global.
  • Si configuras un servicio de backend con backends en varias regiones, Google Front End (GFE) intenta dirigir las solicitudes a grupos de instancias de backend o NEG en buen estado en la región más cercana al usuario. Los detalles del proceso se detallan en esta página.

Para el nivel Estándar:

  • Google hace pública la dirección IP del balanceador de cargas desde los puntos de presencia asociados con la región de la regla de reenvío. El balanceador de cargas usa una dirección IP externa regional.

  • Puedes configurar backends en la misma región que la regla de reenvío. Se sigue aplicando este proceso, pero los GFE solo dirigen solicitudes a backends en buen estado en esa región.

Proceso de distribución de solicitudes:

El modo de balanceo y la elección del destino definen la capacidad total del backend desde la perspectiva de cada NEG zonal GCE_VM_IP_PORT, grupo de instancias zonal o zona de un grupo de instancias regional. La distribución dentro de una zona se realiza con el hashing coherente.

El balanceador de cargas usa el siguiente proceso:

  1. Los routers perimetrales anuncian la dirección IP externa de la regla de reenvío en los límites de la red de Google. Cada anuncio enumera un salto siguiente al sistema de balanceo de cargas de capa 3/4 (Maglev) lo más cerca posible del usuario.
  2. Los sistemas Maglev inspeccionan la dirección IP de origen del paquete entrante. Dirigen la solicitud entrante a los sistemas Maglev que los sistemas de geo IP de Google determinan que están lo más cerca posible del usuario.
  3. Los sistemas Maglev enrutan el tráfico a Google Front End (GFE) de primera capa. El GFE de la primera capa finaliza TLS si es necesario y, luego, enruta el tráfico a los GFE de la segunda capa de acuerdo con este proceso:
    1. El mapa de URL selecciona un servicio de backend.
    2. Si un servicio de backend usa un grupo de instancias o backends de NEG GCE_VM_IP_PORT, los primeros GFE de capa prefieren los GFE de segunda capa que se encuentran en la región que contiene el grupo de instancias o NEG o cerca de ella.
    3. Para los buckets de backend y los servicios de backend con NEG híbridos, NEG sin servidores y de Internet, los GFE de la primera capa eligen GFE de segunda capa en un subconjunto de regiones, de modo que el tiempo de ida y vuelta entre los dos GFE es minimizado.

      La preferencia de GFE de segunda capa no es una garantía y puede cambiar de manera dinámica según las condiciones y el mantenimiento de la red de Google.

      Los GFE de segunda capa conocen el estado de la verificación de estado y el uso real de la capacidad del backend.

  4. La segunda capa de GFE dirige las solicitudes a backends en zonas dentro de su región.
  5. En el nivel Premium, a veces, los GFE de segunda capa envían solicitudes a backends en zonas de diferentes regiones. Este comportamiento se llama efecto secundario.
  6. El efecto secundario se rige por dos principios:

    • La propagación se puede realizar cuando todos los backends conocidos por un GFE de segunda capa están al máximo de capacidad o están en mal estado.
    • La segunda capa de GFE tiene información para los backends en buen estado y disponibles en zonas de otra región.

    Los GFE de segunda capa suelen configurarse para entregar un subconjunto de ubicaciones de backend.

    El comportamiento del efecto secundario no agota todas las zonas posibles de Google Cloud. Si necesitas dirigir el tráfico fuera de los backends en una zona en particular o en una región completa, debes configurar el escalador de capacidad en cero. Configurar backends para que fallen las verificaciones de estado no garantiza que el GFE de segunda capa se transmita a backends en zonas de otra región.

  7. Cuando se distribuyen solicitudes a backends, los GFE operan a nivel zonal.

    Con un número bajo de solicitudes por segundo, los GFE de segunda capa a veces prefieren una zona en una región sobre otras zonas. Esta preferencia es normal y esperada. La distribución entre las zonas de la región no se mantendrá incluso hasta que el balanceador de cargas reciba más solicitudes por segundo.

Afinidad de sesión

La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que el backend esté en buen estado y tenga la capacidad necesaria, según el modo de balanceo configurado.

Cuando uses la afinidad de sesión, te recomendamos el modo de balanceo RATE, en lugar de UTILIZATION. La afinidad de sesión funciona mejor si configuras el modo de balanceo en solicitudes por segundo (RPS).

El balanceo de cargas de HTTP(S) de Google Cloud ofrece los siguientes tipos de afinidad de sesión:

En la siguiente tabla, se resumen las opciones de afinidad de sesión admitidas para cada modo de balanceadores de cargas HTTP(S) externos:

Modo de balanceador de cargas Opciones de afinidad de sesión
  Ninguna IP de cliente Cookie generada Campo de encabezado Cookie HTTP
Balanceador de cargas HTTP(S) externo
Balanceador de cargas HTTP(S) regional externo

Compatibilidad con HTTP/2

Transmisiones simultáneas máximas de HTTP/2

La configuración de HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS describe el número máximo de transmisiones que acepta un extremo, que inicia el par. El valor que anuncia un cliente HTTP/2 a un balanceador de cargas de Google Cloud no tiene sentido, porque el balanceador de cargas no inicia transmisiones al cliente.

En los casos en que el balanceador de cargas usa HTTP/2 para comunicarse con un servidor que se ejecuta en una VM, el balanceador de cargas respeta el valor SETTINGS_MAX_CONCURRENT_STREAMS que anuncia el servidor. Si se anuncia un valor de cero, el balanceador de cargas no puede reenviar solicitudes al servidor y puede generar errores.

Limitaciones de HTTP/2

  • En el caso de los balanceadores de cargas HTTP(S) externos, el uso de HTTP/2 entre el balanceador de cargas y la instancia puede requerir una cantidad significativamente mayor de conexiones TCP a la instancia que HTTP(S). La agrupación de conexiones, una optimización que reduce la cantidad de conexiones con HTTP(S), no está disponible con HTTP/2 en este momento.
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la ejecución del protocolo WebSocket a través de una sola transmisión de conexión HTTP/2 (RFC 8441).
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la extracción de servidor.
  • La tasa de errores de gRPC y el volumen de solicitudes no son visibles en la API de Google Cloud ni en Cloud Console. Si el extremo de gRPC muestra un error, los registros del balanceador de cargas y los datos de supervisión informan el código de respuesta HTTP “OK 200”.

¿Qué sigue?