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) de Google Cloud es un balanceador de cargas de capa 7 global basado en proxy que te permite ejecutar y escalar tus servicios en todo el mundo detrás de una sola dirección IP externa. El balanceo de cargas HTTP(S) externo distribuye el tráfico HTTP y HTTPS a los backends alojados en Compute Engine y Google Kubernetes Engine (GKE).

El balanceo 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. En el nivel Premium, los GFE ofrecen balanceo de cargas multirregional, lo que dirige el tráfico al backend en buen estado más cercano y termina el tráfico HTTP(S) lo más cerca posible de tus usuarios. En el nivel Estándar, el balanceo de cargas se maneja a nivel regional.

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 integrado para el balanceo de cargas de HTTP(S) externo.

Arquitectura

Los siguientes recursos definen un balanceador de cargas de HTTP(S) externo:

  • 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 la 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 depósitos específicos. El mapa de URL puede especificar acciones adicionales, como el envío de redireccionamientos a los clientes.

  • Un servicio de backend o un bucket de backend distribuye solicitudes a backends en buen estado.

  • Uno o más backends deben estar conectados al servicio o al bucket de backend.

  • Una verificación de estado 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.

  • Un firewall para que los backends acepten sondeos de verificaciones de estado.

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 y la dirección IP que requieren los balanceadores de cargas de HTTP(S) externos depende del niveles de servicio de red en el que se encuentra el balanceador de cargas.

Para obtener una lista completa de los protocolos compatibles con las reglas de reenvío del balanceo de cargas HTTP(S), 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.

Tipos de proxy de destino Encabezados agregados por proxy Los Encabezados personalizados son compatibles Compatible con Cloud Trace
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)

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.

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.

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

Un balanceador de cargas de HTTP(S) externo puede tener servicios de backend y 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 existente, consulta Configura un balanceador de cargas con buckets de backend.

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.

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

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

cuando se usa el nivel Premium

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

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 que permita que el tráfico llegue a las instancias. La regla de firewall debe permitir los siguientes rangos de origen:

  • 130.211.0.0/22
  • 35.191.0.0/16

Los balanceadores de cargas de HTTP(S) externos usan verificaciones de estado globales.

Para obtener más información sobre las verificaciones de estado, 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.

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

Reglas de firewall

Las instancias de backend deben permitir conexiones desde las siguientes fuentes:

  • El Google Front End (GFE) del balanceador de cargas para todas las solicitudes que se envían a tus backends
  • Sondeos de verificación de estado

Para permitir este tráfico, debes crear reglas de firewall de entrada. Los puertos de estas reglas de firewall deben permitir el tráfico de la siguiente manera:

  • El puerto de destino para la verificación de estado de cada servicio de backend.

  • Para los backends de grupos de instancias: Determinados por 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 backends de NEG GCE_VM_IP_PORT: 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 lograrlo, puedes usar Google Cloud Armor.

Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico procedente de ellos, consulta Rangos de IP del sondeo y reglas del firewall.

Para los balanceadores de cargas de HTTP(S) externos, en la siguiente tabla, se especifican los rangos de origen de solicitud y verificación de estado:

Rangos de origen de la verificación de estado Rangos de origen de solicitudes de GFE
  • 130.211.0.0/22
  • 35.191.0.0/16
La fuente de tráfico de 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.

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:

  • 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: Es la dirección IP interna del contenedor o la VM de backend en la red de nube privada virtual (VPC).

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 Rutas de acceso de retorno del balanceador de cargas.

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

El balanceo 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 el tráfico se dirige 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. 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. 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. Para obtener más información, consulta Tiempos de espera y reintentos.

Los keepalives de HTTP intentan usar la misma sesión de TCP de forma eficiente; sin embargo, no hay garantía. Aunque están muy relacionados, un tiempo de espera de keepalive de HTTP y uno de inactividad de TCP no son lo mismo.

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.

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 compatibles con las reglas de reenvío del balanceo de cargas HTTP(S), consulta Funciones del balanceador de cargas.

Puertos abiertos

Los balanceadores de cargas de HTTP(S) externos son balanceadores de cargas de proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre conexiones nuevas del balanceador de cargas a los backends. Estos balanceadores de cargas se implementan mediante proxies de Google Front End (GFE) en todo el mundo.

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 los balanceadores de cargas de HTTP(S) externos que usan 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

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

Tiempos de espera y reintentos

El balanceo de cargas 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.

    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.

Para el tráfico 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 WebSocket puede permanecer abierta, ya sea que esté activa o no. Para obtener más información, consulta Configuración del servicio de backend.

  • Un tiempo de espera de sesión TCP, cuyo valor se fija en 10 minutos (600 segundos). Este tiempo de espera de la sesión a veces 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 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;

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. No se reintentan las solicitudes POST que fallaron. Solo se puede reintentar dos veces. Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.

Un GFE no vuelve a intentarlo si más del 80% de las instancias de backend están en mal 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. Para obtener más información, consulta Registro y supervisión del balanceo de cargas de HTTP(S).

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.

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.

Para obtener más información sobre los modos de balanceo, consulta Modos de balanceo.

Cómo se distribuyen las solicitudes

La distribución del tráfico a nivel regional o global depende de qué nivel de servicio de red se esté utilizando.

Para el nivel Premium:

  • 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 será uniforme 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.

El balanceo de cargas de 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 desde la misma dirección IP de cliente al mismo backend.
  • La afinidad de cookie generada establece una cookie de 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).

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.

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 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 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?