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

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

Para obtener información sobre la diferencia entre los balanceadores de cargas de Google Cloud, consulta los siguientes documentos:

Casos prácticos

Los balanceadores de cargas HTTP(S) externos abordan muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Balanceo de cargas con varios tipos de backend

Un caso práctico común es el balanceo de cargas del tráfico entre distintos servicios. En el siguiente ejemplo, los clientes IPv4 y, también, IPv6 externos pueden solicitar contenido de imágenes, API y video mediante la misma URL base, con las rutas /api, /video y /images.

El mapa de URL del balanceador de cargas HTTP(S) externo especifica lo siguiente:

  • Las solicitudes a la ruta /api van a un servicio de backend con un grupo de instancias de VM o un backend de NEG zonal.
  • Las solicitudes a la ruta /images van a un depósito de backend con un backend de Cloud Storage.
  • Las solicitudes a la ruta /video van a un servicio de backend que apunta a un NEG de Internet que contiene un extremo externo ubicado en las instalaciones, fuera de Google Cloud.

Cuando un cliente envía una solicitud a la dirección IPv4 o IPv6 externa del balanceador de cargas, este evalúa la solicitud según el mapa de URL y la envía al servicio correspondiente.

En el siguiente diagrama, se ilustra este caso práctico.

Diagrama del balanceo de cargas con un origen personalizado (haz clic para agrandar)
Diagrama de balanceo de cargas con un origen personalizado (haz clic para ampliar)

En cada servicio de backend, puedes habilitar opcionalmente Cloud CDN o Google Cloud Armor. Cuando Cloud CDN está habilitado, no puedes habilitar Google Cloud Armor.

En los depósitos de backend, se admite Cloud CDN, pero no Google Cloud Armor.

Servicios web de tres niveles

Puedes usar el balanceo de cargas HTTP(S) externo para servicios web tradicionales de tres niveles. En el siguiente ejemplo, se muestra cómo puedes usar tres tipos de balanceadores de cargas de Google Cloud para escalar tres niveles. En cada nivel, el tipo de balanceador de cargas depende del tipo de tráfico:

En el diagrama, se muestra cómo se mueve el tráfico por los niveles:

  1. Un balanceador de cargas HTTP(S) externo (el asunto de esta descripción general) distribuye el tráfico desde Internet hasta un conjunto de grupos de instancias de frontend web en varias regiones.
  2. Estos frontends envían el tráfico HTTP(S) a un conjunto de balanceadores de cargas HTTP(S) internos y regionales.
  3. Los balanceadores de cargas HTTP(S) internos distribuyen el tráfico a grupos de instancias de middleware.
  4. Estos grupos de instancias de middleware envían el tráfico a balanceadores de cargas TCP/UDP internos, que balancean la carga del tráfico a los clústeres de almacenamiento de datos.
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles (haz clic si deseas ampliar)
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles

Información básica

Un balanceador de cargas HTTP(S) externo consta de varios componentes. En el siguiente diagrama, se ilustra la arquitectura de un balanceador de cargas HTTP(S) externo completo.

Diagrama del balanceo de cargas basado en el contenido y entre regiones (haz clic para ampliar)
Diagrama del balanceo de cargas basado en el contenido y entre regiones (haz clic para ampliar)

En las siguientes secciones, se describe cómo estos componentes funcionan en conjunto para formar cada tipo de balanceador de cargas. Para obtener una descripción detallada de cada componente, consulta Componentes más adelante en esta sección.

Balanceo de cargas HTTP

Un balanceador de cargas HTTP completo se estructura de la siguiente manera:

  1. Una regla de reenvío dirige las solicitudes entrantes a un proxy HTTP de destino.
  2. El proxy HTTP de destino compara cada solicitud con un mapa de URL a fin de determinar el servicio de backend apropiado para la solicitud.
  3. El servicio de backend dirige cada solicitud a un backend adecuado según la capacidad de entrega, la zona y el estado de la instancia de los backends adjuntos. El estado de cada instancia de backend se comprueba mediante una verificación de estado HTTP, HTTPS o HTTP/2. Si se configura el servicio de backend para usar una verificación de estado HTTPS o HTTP/2, la solicitud se encripta de camino a la instancia de backend.
  4. Las sesiones entre el balanceador de cargas y la instancia pueden usar el protocolo HTTP, HTTPS o HTTP/2. Si usas HTTPS o HTTP/2, cada instancia de backend debe tener un certificado SSL.

Balanceo de cargas HTTPS

Un balanceador de cargas HTTPS tiene la misma estructura básica que un balanceador de cargas HTTP, pero difiere de las siguientes maneras:

  • Un balanceador de cargas HTTPS usa un proxy HTTPS de destino en lugar de un proxy HTTP de destino.
  • Un balanceador de cargas HTTPS requiere al menos un certificado SSL firmado instalado en el proxy HTTPS de destino para el balanceador de cargas. Puedes usar certificados SSL administrados por Google o autogestionados.
  • La sesión SSL del cliente finaliza en el balanceador de cargas.
  • Los balanceadores de cargas HTTPS admiten el protocolo de capa de transporte QUIC.

Direcciones IP de origen

Las direcciones IP de origen de los paquetes, vistas por cada contenedor o instancia de máquina virtual (VM) de backend, son una dirección IP de estos rangos:

  • 35.191.0.0/16
  • 130.211.0.0/22

La dirección IP de origen para el tráfico real del balanceo de cargas es la misma que la de los rangos de IP del sondeo de verificación de estado.

Las direcciones IP de origen del tráfico, vistas por los backends, no son la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos sesiones HTTP, SSL o TCP:

  • 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).
    • Dirección IP de destino: Es la dirección IP del balanceador de cargas.
  • Sesión 2, que abarca desde el balanceador de cargas (GFE) hasta el contenedor o la VM de backend:

    • Dirección IP de origen: Es una dirección IP en uno de estos rangos: 35.191.0.0/16 o 130.211.0.0/22.

      No puedes predecir la dirección real de origen.

    • Dirección IP de destino: Es la dirección IP interna del contenedor o la VM de backend en la red de nube privada virtual (VPC).

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 HTTPS.
  • No puedes inhabilitar HTTP/2 si realizas 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.
  • Los balanceadores de cargas HTTPS no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.

Puertos abiertos

Los balanceadores de cargas HTTP(S) son balanceadores de cargas de proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre nuevas conexiones entre el balanceador de cargas y los backends. Google Front End (GFE) proporciona la función de proxy inverso.

Las reglas de firewall que configuras bloquean el tráfico de los GFE a los backends, pero no bloquean el tráfico entrante a los GFE.

Los balanceadores de cargas HTTP(S) externos tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Si ejecutas un análisis de puertos o de seguridad en función de la dirección IP externa de un balanceador de cargas HTTP(S) externo de Google Cloud, parecerá que hay puertos adicionales abiertos.

Esto no afecta a los balanceadores de cargas HTTP(S) externos. Las reglas de reenvío externas, que se usan en la definición de un balanceador de cargas HTTP(S) externo, solo pueden hacer referencia a los puertos TCP 80, 8080 y 443. El tráfico con un puerto de destino TCP diferente no se reenvía al backend del balanceador de cargas.

Componentes

Los siguientes son componentes de balanceadores de cargas HTTP(S) externos.

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 en un proxy de destino, un mapa 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 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 de un balanceador de cargas 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 que se necesita para los balanceadores de cargas HTTP(S) externos depende del nivel de servicio de red en el que se encuentre el balanceador de cargas.

  • Los balanceadores de cargas HTTP(S) externos en el nivel Premium usan reglas de reenvío externas globales.
  • Los balanceadores de cargas HTTP(S) externos en el nivel Estándar usan reglas de reenvío externas regionales.

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.

Los proxies configuran encabezados de solicitud/respuesta HTTP de la siguiente manera:

  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-Proto: [http | https] (solo invitaciones)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in Google Cloud> (solo invitaciones)

    El encabezado X-Forwarded-For (XFF) contiene una lista de direcciones IP separadas por comas que representan los proxies por los que pasó la solicitud. Cada proxy puede adjuntar la dirección IP de su cliente a la lista. Debido a esto, la cantidad de direcciones IP en el encabezado XFF puede variar. Un balanceador de cargas HTTP(S) externo de Google Cloud agrega dos direcciones IP al encabezado: la del cliente solicitante y externa de la regla de reenvío del balanceador de cargas, en ese orden.

    Por lo tanto, la dirección IP que precede inmediatamente a la dirección IP del balanceador de cargas de Google Cloud es la dirección IP del sistema que se comunica con el balanceador de cargas. El sistema puede ser un cliente o, también, podría ser otro servidor proxy fuera de Google Cloud que reenvía las solicitudes en nombre de un cliente.

    Cuando un servidor proxy fuera de Google Cloud contacta al balanceador de cargas HTTP(S) externo de Google Cloud en nombre de un cliente, es posible que el balanceador de cargas no reciba la dirección IP del sistema que contacta al proxy externo. Es posible que el proxy externo no adjunte la dirección IP de su cliente al encabezado XFF. Si todos los proxies externos agregan una dirección IP de cliente al encabezado XFF, la primera dirección IP de la lista es la del cliente original.

    Si las VM de backend de un balanceador de cargas HTTP(S) externo funcionan como proxies internos, es posible que se agreguen más direcciones IP de cliente al encabezado XFF. En este caso, es posible que la dirección IP de la regla de reenvío del balanceador de cargas HTTP(S) externo no sea la última de la lista.

  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo invitaciones)

    Contiene parámetros para Cloud Trace.

Puedes crear encabezados de solicitud personalizados si los encabezados predeterminados no satisfacen tus necesidades. Para obtener más información sobre esta función, consulta Crea encabezados de solicitud definidos por el usuario.

No dependas de que el proxy conserve 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.

Mapas de URL

Los mapas 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 entre regiones, es posible que no definas ninguna regla de URL y solo te bases en el servicio predeterminado. Para el enrutamiento de tráfico basado en el contenido, el mapa de URL te permite dividir tu tráfico mediante el análisis de los componentes de URL a fin de enviar solicitudes a diferentes conjuntos de backends.

Certificado SSL

Si usas el balanceo de cargas HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino. Puedes tener instalados hasta quince (15) certificados SSL. Los proxies HTTPS de destino los usan para autenticar las comunicaciones entre el balanceador de cargas y el cliente. Estos pueden ser certificados SSL administrados por Google o autogestionados. Cada uno de los certificados SSL administrados por Google admite (en versión Beta) hasta 100 dominios.

Si usas HTTPS o HTTP/2 entre el balanceador de cargas y los backends, debes instalar certificados SSL en cada instancia de VM. Para instalar certificados SSL en una instancia de VM, usa las instrucciones incluidas en la documentación de tu aplicación. Estos certificados pueden ser autofirmados.

Para el balanceo de cargas HTTP(S) externo, Google encripta el tráfico entre el balanceador de cargas y las instancias de backend. Los recursos del certificado SSL no son necesarios para las instancias de VM individuales. Si necesitas certificados SSL en una instancia de VM debido a los servicios que tienes en ejecución allí, instala los certificados como se describe en la documentación de tu aplicación.

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 algoritmos de cifrado 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.

Control geográfico sobre dónde se finaliza TLS

El balanceador de cargas HTTPS finaliza TLS en ubicaciones distribuidas de manera global a fin de minimizar la latencia entre los clientes y el balanceador de cargas. Si necesitas control geográfico sobre la ubicación donde se finaliza TLS, usa el balanceo de cargas de red de Google Cloud y finaliza TLS en backends ubicados en regiones adecuadas para tus necesidades.

Servicios de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Un balanceador de cargas HTTP(S) externo debe tener al menos un servicio de backend. Además, puede tener varios servicios de backend.

Los balanceadores de cargas usan la información de un servicio de backend para dirigir el tráfico entrante a uno o más backends adjuntos.

Los backends de un servicio de backend pueden ser grupos de instancias o grupos de extremos de red (NEG), pero no una combinación de ambos. Cuando agregas un grupo de instancias de backend o NEG, especifica un modo de balanceo, el cual define un método para distribuir solicitudes y una capacidad de destino. Para obtener más información, consulta Algoritmo de distribución de cargas.

El balanceo de cargas HTTP(S) es compatible con el escalador automático de Cloud Load Balancing, que permite a los usuarios realizar ajustes de escala automáticos en los grupos de instancias de un servicio de backend. Para obtener más información, consulta Escala en función de la capacidad de entrega del balanceo de cargas HTTP(S).

Puedes habilitar el vaciado de conexiones en servicios de backend a fin de garantizar una interrupción mínima para tus usuarios cuando se finaliza una instancia que entrega tráfico, se quita de forma manual o la quita un escalador automático. Para obtener más información, consulta Habilita el vaciado de conexiones.

Comportamiento del balanceador de cargas en diferentes niveles de servicio de red

El balanceo de cargas HTTP(S) es un servicio global cuando se usa el nivel de servicio de red Premium. Es posible que tengas más de un servicio de backend en una región y que puedas crear servicios de backend en más de una región, todos atendidos por el mismo balanceador de cargas global. El tráfico se asigna a los servicios de backend de la siguiente manera:

  1. Cuando llega una solicitud de usuario, el servicio de balanceo de cargas determina el origen aproximado de la solicitud a partir de la dirección IP de origen.
  2. El servicio de balanceo de cargas conoce las ubicaciones de las instancias que posee el servicio de backend, su capacidad general y uso actual general.
  3. Si las instancias más cercanas al usuario tienen capacidad disponible, la solicitud se reenviará a ese conjunto de instancias.
  4. Las solicitudes entrantes a la región determinada se distribuyen de manera uniforme entre todos los servicios de backend y las instancias disponibles en esa región. Sin embargo, con cargas muy pequeñas, la distribución puede parecer desigual.
  5. Si no hay instancias en buen estado con capacidad disponible en una región determinada, el balanceador de cargas envía la solicitud a la siguiente región más cercana con capacidad disponible.

El balanceo de cargas HTTP(S) es un servicio regional cuando se usa el nivel estándar del servicio de red. Sus grupos de instancias de backend o NEG deben estar ubicados en la región que usa la dirección IP externa y la regla de reenvío del balanceador de cargas.

Verificaciones de estado

Cada servicio de backend también especifica qué verificación de estado se realiza en cada instancia disponible. Para que los sondeos de verificación de estado funcionen correctamente, debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/22 y 35.191.0.0/16 llegue a tus instancias.

Para obtener más información sobre las verificaciones de estado, consulta Crea verificaciones de estado.

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas HTTP(S) externo, configuras 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.

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.

Usa gRPC con tus aplicaciones de Google Cloud

gRPC es un marco de trabajo 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 de proxy de extremo a extremo en HTTP/2. Para hacerlo con un balanceador de cargas 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 HTTP(S) externo configurado para usar HTTP/2 entre las instancias del balanceador de cargas y el backend. 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.

Si quieres configurar un balanceador de cargas HTTP(S) externo mediante HTTP/2 con Google Kubernetes Engine Ingress 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 de HTTP/2, consulta Solución de problemas de HTTP/2 en los backends.

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

Depósitos de backend

Los depósitos de backend dirigen el tráfico entrante a los depósitos de Cloud Storage.

Como se muestra en el siguiente diagrama, puedes hacer que el balanceador de cargas envíe tráfico con una ruta de /static a un depósito de almacenamiento y todas las demás solicitudes a tus otros backends.

Distribución de tráfico a varios tipos de backends con balanceo de cargas HTTP(S) (haz clic para agrandar)
Distribución de tráfico a varios tipos de backend con balanceo de cargas HTTP(S) (haz clic para agrandar)

Para ver un ejemplo que muestra cómo agregar un depósito a un balanceador de cargas existente, consulta Agrega depósitos de backend a balanceadores de cargas.

Reglas de firewall

Debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/22 y 35.191.0.0/16 llegue a tus instancias. Estos son rangos de direcciones IP que el balanceador de cargas usa para conectarse a instancias de backend. Esta regla permite el tráfico proveniente del balanceador de cargas y del verificador de estado. La regla debe permitir el tráfico en el puerto que se usa en la configuración de tu regla de reenvío, y tu verificador de estado debe configurarse para usar el mismo puerto. Si tu verificador de estado usa otro puerto, también deberás crear una regla de firewall para ese puerto.

Las reglas de firewall bloquean y permiten el tráfico en el nivel de la instancia, no en los bordes de la red. No pueden impedir que el tráfico llegue al balanceador de cargas.

Si necesitas determinar las direcciones IP externas en un momento determinado, sigue las instrucciones que se brindan en Preguntas frecuentes de Compute Engine.

Ruta de acceso de retorno

Google Cloud usa rutas especiales no definidas en tu red de VPC para las verificaciones de estado. Para obtener más información, consulta la sección sobre rutas de acceso de retorno del balanceador de cargas.

Algoritmo de distribución de cargas

El balanceo de cargas HTTP(S) externo admite dos modos de balanceo para backends:

  • RATE para backends de grupos de instancias o NEG
  • UTILIZATION para backends de grupos de instancias

Los backends de un servicio de backend pueden ser grupos de instancias o NEG, pero no una combinación de ambos. Cuando agregas un grupo de instancias de backend o NEG, debes especificar un modo de balanceo, el cual define un método para distribuir solicitudes y una capacidad de destino. Para los backends de grupos de instancias, puedes usar el modo de balanceo UTILIZATION o RATE. Para los NEG, debes usar RATE.

Cuando utilizas el modo de balanceo RATE, debes especificar una cantidad máxima de solicitudes (consultas) por segundo (RPS, QPS). Este objetivo se utiliza para definir cuándo una instancia o extremo llegó al máximo de capacidad. La cantidad máxima de RPS/QPS puede excederse si se alcanza o supera la capacidad de todos los backends.

Cuando un balanceador de cargas HTTP(S) externo está en nivel Premium, las solicitudes enviadas al balanceador de cargas se entregan a grupos de instancias de backend o NEG en la región más cercana al usuario, si es que un backend en esa región tiene capacidad disponible. La capacidad disponible se configura mediante el modo de balanceo del balanceador de cargas.

Cuando un balanceador de cargas HTTP(S) externo está en nivel Estándar, sus grupos de instancias backend o NEG deben ubicarse en la región que usan la dirección IP externa y la regla de reenvío del balanceador de cargas.

A continuación, se describe lo que sucede después de seleccionar una región:

  • Un balanceador de cargas HTTP(S) externo intenta balancear las solicitudes de la manera más uniforme posible dentro de las zonas de una región, sujeto a la afinidad de sesión. Cuando configuras varios NEG o grupos de instancias zonales en la misma región, o uno o más grupos de instancias administrados regionales, el balanceador de cargas HTTP(S) externo se comporta de esta manera.

  • Dentro de una zona, un balanceador de cargas HTTP(S) externo intenta balancear las solicitudes mediante un algoritmo round-robin, sujeto a la afinidad de sesión.

Si quieres ver ejemplos específicos del algoritmo de distribución de cargas, consulta Cómo funciona el balanceo de cargas HTTP(S).

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.

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

  • NONE. No se configuró la afinidad de sesión para el balanceador de cargas.
  • La afinidad de IP de cliente envía solicitudes de la misma dirección IP de cliente al mismo backend.
  • La afinidad de cookie generada establece una cookie cliente cuando se realiza la primera solicitud y, luego, envía las solicitudes con esa cookie al mismo backend.

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).

Compatibilidad de proxy con WebSocket

El balanceo de cargas HTTP(S) tiene compatibilidad nativa con el protocolo WebSocket cuando se usa HTTP o HTTPS (no HTTP/2) como protocolo para el backend.

Los backends que usan el protocolo WebSocket para comunicarse con los clientes pueden usar el balanceador de cargas HTTP(S) externo como frontend para mejorar el escalamiento y la disponibilidad. El balanceador de cargas no necesita ninguna configuración adicional para usar un proxy en las conexiones de WebSocket.

El protocolo WebSocket, que se define en RFC 6455, proporciona un canal de comunicación dúplex completo entre clientes y servidores. El canal se inicia a partir de una solicitud HTTP(S).

Cuando el balanceo de cargas HTTP(S) reconoce una solicitud WebSocket Upgrade de un cliente HTTP(S) y la solicitud es seguida por una respuesta Upgrade exitosa de la instancia de backend, el balanceador de cargas procesa el tráfico bidireccional mientras dure la conexión actual. Si el 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 de respuesta configurable del balanceador de cargas, que es de 30 segundos de forma predeterminada. Este tiempo de espera se aplica a las conexiones WebSocket independientemente de si están en uso. Para obtener más información sobre el tiempo de espera de respuesta y cómo configurarlo, consulta Tiempos de espera y reintentos.

Si configuraste la IP de cliente o generaste afinidad de sesión de cookies para tu balanceador de cargas HTTP(S), todas las conexiones de WebSocket de un cliente se envían a la misma instancia de backend, siempre que la instancia no deje de aprobar las verificaciones de estado y tenga capacidad.

El protocolo WebSocket es compatible con Ingress.

Compatibilidad con el protocolo QUIC para el balanceo de cargas HTTPS

El balanceo de cargas HTTPS admite el protocolo QUIC en las conexiones entre el balanceador de cargas y los clientes. QUIC es un protocolo de capa de transporte que proporciona control de congestión similar a TCP y seguridad equivalente a SSL/TLS para HTTP/2, con un rendimiento mejorado. QUIC permite un inicio más rápido de la conexión del cliente, elimina 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.

QUIC afecta las conexiones entre los clientes y el balanceador de cargas, no las conexiones entre el balanceador de cargas y sus backends.

La configuración de anulación QUIC del proxy de destino te permite habilitar una de las siguientes opciones:

  • Cuando sea posible, negociar QUIC para un balanceador de cargas
  • Inhabilitar QUIC siempre para un balanceador de cargas

Si no especificas un valor para la configuración de anulación QUIC, se permite que Google administre cuándo se usa QUIC. Google habilita QUIC solo cuando la marca --quic-override en la herramienta de línea de comandos de gcloud se configura como ENABLE o cuando la marca quicOverride en la API de REST se configura como ENABLE.

Para obtener información sobre cómo inhabilitar y habilitar la compatibilidad con QUIC, consulta Proxies de destino. Puedes habilitar o inhabilitar la compatibilidad con QUIC en la sección de configuración del frontend de Google Cloud Console mediante la herramienta de línea de comandos gcloud o mediante la API de REST.

Cómo se negocia QUIC

Cuando habilitas QUIC, el balanceador de cargas puede anunciar su capacidad QUIC a los clientes, lo que permite que los clientes compatibles con QUIC intenten establecer conexiones de este tipo 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. Debido a este resguardo, habilitar o inhabilitar QUIC en el balanceador de cargas no interrumpe la capacidad de este para conectarse con los clientes.

Cuando tienes QUIC habilitado en el balanceador de cargas 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 QUIC que no son compatibles con las que admite el balanceador de cargas HTTPS
  • Cuando el balanceador de cargas detecta que el tráfico UDP está bloqueado o sometido a un límite de frecuencia tal que impediría el funcionamiento de QUIC
  • Si QUIC está inhabilitado de manera temporal para los balanceadores de cargas HTTPS en respuesta a errores, vulnerabilidades o algunas otras inquietudes

Los casos en los que una conexión recurre a HTTPS o HTTP/2 debido a estas circunstancias no se consideran una falla del balanceador de cargas.

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

Interfaces

Tu servicio de balanceo de cargas HTTP(S) se puede configurar y actualizar a través de las siguientes interfaces:

  • La herramienta de línea de comandos de gcloud: una herramienta de línea de comandos que se incluye en el SDK de Cloud. La documentación de balanceo de cargas HTTP(S) llama a esta herramienta con frecuencia para realizar tareas. Para obtener una descripción general completa de la herramienta, consulta la guía de la herramienta de gcloud. Puedes encontrar comandos relacionados con el balanceo de cargas en el grupo de comandos gcloud compute.

    También puedes obtener ayuda detallada para cualquier comando gcloud con la marca --help:

    gcloud compute http-health-checks create --help
        
  • Cloud Console: Las tareas de balanceo de cargas se pueden realizar con Cloud Console.

  • API de REST: Todas las tareas de balanceo de cargas pueden realizarse con la API de Google Cloud Load Balancing. En los documentos de referencia de la API, se describen los recursos y métodos disponibles.

Compatibilidad con TLS

De forma predeterminada, un proxy de destino HTTPS solo acepta TLS 1.0, 1.1 y 1.2 cuando finaliza las solicitudes SSL del cliente. Puedes usar las políticas de SSL para cambiar este comportamiento predeterminado y controlar cómo el balanceador de cargas negocia SSL con los clientes.

Cuando el balanceador de cargas usa HTTPS como protocolo de servicio de backend, puede negociar TLS 1.0, 1.1 o 1.2 con el backend.

Tiempos de espera y reintentos

El balanceo de cargas HTTP(S) tiene dos tipos de tiempos de espera diferentes:
  • Un tiempo de espera de respuesta HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera a que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera de respuesta es de 30 segundos. Considera aumentar este tiempo de espera en cualquiera de estas circunstancias:

    • Si esperas que un backend tarde más en mostrar respuestas HTTP
    • Si la conexión se actualiza a un WebSocket (solo balanceo de cargas HTTP[S])

    Para el tráfico de WebSocket enviado mediante un balanceador de cargas, el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión de WebSocket puede permanecer abierta, ya sea que esté activa o no. Para obtener más información, consulta la Configuración del servicio de backend.

  • Un tiempo de espera de sesión TCP, cuyo valor se fija en 10 minutos (600 segundos). A veces, este tiempo de espera de sesión se denomina tiempo de espera keepalive o inactivo, y su 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 y evitar que el backend cierre las conexiones antes de tiempo. 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 keepalive para el software de servidor web común:

Software de 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;

El balanceador de cargas reintenta las solicitudes GET que fallaron en ciertas circunstancias, como cuando se agota el tiempo de espera de respuesta. No se reintentan las solicitudes POST que fallaron. Solo se puede reintentar dos veces. Las solicitudes con reintentos generan solo una entrada de registro para la respuesta final.

Para obtener más información, consulta Registro y supervisión del balanceo de cargas HTTP(S).

Solicitud ilegal y manejo de respuestas

El balanceador de cargas HTTP(S) externo impide que las solicitudes de cliente 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 hacia o desde los backends. 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 trozos 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 de tamaño máximo de encabezado de respuesta del balanceo de cargas HTTP(S) externo.
  • La versión de HTTP es desconocida.

Limitaciones

Limitaciones de HTTP/2

  • En comparación con el protocolo HTTP(S), 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. La agrupación de conexiones, una optimización que reduce la cantidad de conexiones cuando se usa el protocolo HTTP(S), no está disponible actualmente con HTTP/2.
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no es compatible con lo siguiente:
    • Extracción del servidor
    • WebSockets

Restricción sobre el uso de Cloud CDN

  • No puedes habilitar Google Cloud Armor y Cloud CDN con el mismo servicio de backend. Si intentas hacerlo, el proceso de configuración fallará.

  • No puedes habilitar Identity-Aware Proxy ni Cloud CDN con el mismo servicio de backend. Si intentas hacerlo, el proceso de configuración fallará.

Qué sigue