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) externo es un balanceador de cargas de capa 7 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.

Modos de operación

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

• Balanceador de cargas de HTTP(S) externo global. Este es un balanceador de cargas global que se implementa como un servicio administrado en Google Front End (GFE). Usa el proxy de Envoy de código abierto para admitir capacidades de administración de tráfico avanzadas, como la duplicación de tráfico, la división de tráfico basada en el peso, las transformaciones de encabezados de solicitud o respuesta y mucho más.
• Balanceador de cargas de HTTP(S) global externo (clásico). Este es el balanceador de cargas de HTTP(S) externo clásico que es global en el nivel Premium, pero se puede configurar para que sea regional en el nivel Estándar. Este balanceador de cargas 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 HTTP(S) regional externo. 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 de HTTP(S) externo global	Usa este balanceador de cargas para cargas de trabajo de HTTP(S) externas con usuarios de todo el mundo o servicios de backend en varias regiones.	Admite la administración avanzada de tráfico Direcciones IP externas Anycast globales a través del nivel Premium Puede acceder a backends en varias regiones Admite Cloud CDN Admite Google Cloud Armor (no incluye la administración de bots) Compatible con GKE mediante NEG independientes (organización manual).
Balanceador de cargas de HTTP(S) global externo (clásico)	Este balanceador de cargas es global en el nivel Premium, pero se puede configurar para que sea regional de forma eficaz en el nivel Estándar. En el nivel de servicio de red Premium, este balanceador de cargas 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.	Compatible con GKE mediante Ingress o Gateway (completamente organizado). Admite Google Cloud Armor (incluye la administración de bots). Menos funciones de enrutamiento de tráfico Consulta la página Funciones del balanceo de cargas para ver la lista completa de funciones.
Balanceador de cargas HTTP(S) regional externo	Este balanceador de cargas contiene muchas de las características del balanceador de cargas de HTTP(S) externo global existente, junto con capacidades de administración avanzada del tráfico. Usa este balanceador de cargas si deseas entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las reglamentaciones de cumplimiento) o si deseas usar el nivel de servicio de red Estándar.	Compatible con GKE mediante NEG independientes (organización manual). Admite funciones avanzadas de administración del tráfico VIP regionales que usan el nivel de red Estándar Finaliza TLS en una sola región que configures Entrega contenido solo desde la región configurada Para obtener una lista completa, consulta Funciones de balanceo de cargas.

Identifica el modo

Consola de Cloud

1. En la consola de Google Cloud, ve a la página Balanceo de cargas.
   Ir a Balanceo de cargas
2. En la pestaña Balanceadores de cargas, se muestran el tipo, el protocolo y la región del balanceador de cargas. Si la región está en blanco, entonces el balanceador de cargas es global. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.

   Modo de balanceador de cargas	Tipo de balanceo de cargas	Región	Nivel de red
   Balanceador de cargas de HTTP(S) externo global	HTTP(S)		PREMIUM
   Balanceador de cargas de HTTP(S) global externo (clásico)	HTTP(S)(Clásico)		ESTÁNDAR O PREMIUM
   Balanceador de cargas HTTP(S) regional externo	HTTP(S)	Especifica una región	ESTÁNDAR

gcloud

1. Para determinar el modo de un balanceador de cargas, ejecuta el siguiente comando:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

   En el resultado del comando, verifica el esquema de balanceo de cargas, la región y el nivel de red. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.

   Modo de balanceador de cargas	Esquema de balanceo de cargas	Regla de reenvío	Nivel de red
   Balanceador de cargas de HTTP(S) externo global	EXTERNAL_MANAGED	Global	PREMIUM
   Balanceador de cargas de HTTP(S) global externo (clásico)	EXTERNAL	Global	ESTÁNDAR O PREMIUM
   Balanceador de cargas HTTP(S) regional externo	EXTERNAL_MANAGED	Especifica una región	ESTÁNDAR

Importante: Después de crear un balanceador de cargas, no puedes editar su modo. En su lugar, debes borrar el balanceador de cargas y crear uno nuevo.

Arquitectura

Los siguientes recursos son necesarios para implementar el balanceo de cargas de HTTP(S):

• 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. Los balanceadores de cargas de HTTP(S) externos globales también admiten 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.

Global

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas HTTP(S) global externo. Esta arquitectura se aplica al balanceador de cargas de HTTP(S) externo global con capacidad de administración avanzada del tráfico y al balanceador de cargas de HTTP(S) externo global (clásico) en el nivel Premium.

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

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

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 basados en Envoy 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.

Si creaste una subred de solo proxy con --purpose=INTERNAL_HTTPS_LOAD_BALANCER, deberás migrar el propósito de la subred a REGIONAL_MANAGED_PROXY antes de poder crear otro balanceador de cargas basado en Envoy en la misma región de la red de VPC.

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 de HTTP(S) externo global	Nivel Premium	Regla de reenvío externa global Dirección IP externa global Esquema de balanceo de cargas: EXTERNAL_MANAGED	Solicitudes enrutadas al GFE más cercano al cliente en Internet.
Balanceador de cargas de HTTP(S) global externo (clásico)	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.

Nota: En el caso de los NEG de Internet, las solicitudes del balanceador de cargas provienen de diferentes rangos de IP. Para obtener más información, consulta Autentica solicitudes.

En la siguiente tabla, se especifica el tipo de proxy de destino que requiere el balanceo de cargas de HTTP(S) 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 de HTTP(S) externo global	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 No compatible con Cloud CDN
Balanceador de cargas de HTTP(S) global externo (clásico)	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)

Nota: De acuerdo con RFC 2616, el siguiente proxy de destino no propaga los siguientes encabezados de salto a salto: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding y Upgrade.

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>

Precaución: El balanceador de cargas no verifica ninguna dirección IP que precede a <client-ip>,<load-balancer-ip> en este encabezado. Las direcciones IP anteriores pueden contener otros caracteres, incluidos los espacios.

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>

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.

Los mapas de URL que se usan con balanceadores de cargas de HTTP(S) externos y globales son compatibles con varias funciones avanzadas de administración de tráfico, como la dirección de tráfico basada en encabezados, la división de tráfico según el peso y la duplicación de solicitudes. Para obtener más información, consulta lo siguiente:

• Descripción general de la administración del tráfico en el balanceador de cargas HTTP(S) externo global
• Descripción general de la administración del tráfico en el balanceador de cargas HTTP(S) regional externo.

En la siguiente tabla, se especifica el tipo de mapa de URL que requiere el balanceo de cargas de HTTP(S) en cada modo.

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

Certificados SSL

Los balanceadores de cargas de HTTP(S) externos que usan proxies HTTPS de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de cargas:

• Google Cloud proporciona dos métodos de configuración para asignar claves privadas y certificados SSL a los proxies HTTPS de destino: el certificado SSL de Compute Engine y el Administrador de certificados. Para obtener una descripción de cada configuración, consulta Métodos de configuración de certificados en la descripción general de certificados SSL.

• Google Cloud proporciona dos tipos de certificado: autoadministrados y administrados por Google. Para obtener una descripción de cada tipo, consulta Tipos de certificados en la descripción general de certificados SSL.

• El modo de balanceador de cargas de HTTP(S) externo determina qué métodos de configuración y tipos de certificados son compatibles. Para obtener más información, consulta Certificados y balanceadores de cargas de Google Cloud en la descripción general de certificados SSL.

Políticas de SSL

Las políticas de SSL especifican el conjunto de características de SSL que los balanceadores de cargas de Google Cloud usan cuando negocian SSL con los clientes.

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 una política de SSL para especificar el conjunto de características de SSL que usará tu balanceador de cargas cuando negocies SSL con los clientes. Además, puedes aplicar esa política de SSL a tu proxy HTTPS de destino.

En la siguiente tabla, se especifica la compatibilidad de las políticas de SSL con los balanceadores de cargas en cada modo.

Modo de balanceador de cargas	Políticas de SSL compatibles
Balanceador de cargas de HTTP(S) externo global
Balanceador de cargas de HTTP(S) global externo (clásico)
Balanceador de cargas HTTP(S) regional externo

Servicios 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 HTTP(S) externo, consulta Configura un balanceador de cargas con buckets de backend.

En la siguiente tabla, se especifican las características de backend compatibles con el balanceo de cargas de HTTP(S) en cada modo.

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	NEG de Private Service Connect
Balanceador de cargas de HTTP(S) externo global
Balanceador de cargas de HTTP(S) global externo (clásico)									cuando se usa el nivel Premium
Balanceador de cargas HTTP(S) regional externo

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

• Descripción general de los servicios de backend
• ¿Qué es Cloud Storage?

Backends y redes de VPC

Las restricciones sobre dónde se pueden ubicar los backends dependen del tipo de balanceador de cargas.

• Para el balanceador de cargas de HTTP(S) externo global y el balanceador de cargas de HTTP(S) externo global (clásico), todos los backends deben estar ubicados en el mismo proyecto, pero se pueden ubicar en redes de VPC diferentes. No es necesario que las diferentes redes de VPC estén conectadas mediante el intercambio de tráfico entre redes de VPC, ya que los sistemas proxy de GFE se comunican directamente con los backends en sus respectivas redes de VPC.
• Para el balanceador de cargas de HTTP(S) regional externo, todos los backends deben estar ubicados en la misma región y red de VPC.

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas, configuras el protocolo que usa el servicio de backend a fin de comunicarse con estos. 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.

Nota: HTTP/2 no es compatible.

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 ello, haz lo siguiente:

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.

El balanceador de cargas aún puede negociar HTTPS con algunos clientes o aceptar solicitudes HTTP no seguras en un balanceador de cargas configurado para usar HTTP/2 entre las instancias de 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 que supervisa de manera periódica la preparación de los backends para recibir una conexión del balanceador de cargas. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud. Las verificaciones de estado no verifican si la aplicación en sí funciona.

Para los sondeos de verificación de estado, debes crear una regla de firewall de permiso de entrada que permita que los sondeos lleguen a tus instancias de backend. Por lo general, los sondeos de verificación de estado se originan en el mecanismo centralizado de verificación de estado de Google.

Los balanceadores de cargas de HTTP(S) externos regionales que usan backends de NEG híbridos son una excepción a esta regla, ya que sus verificaciones de estado se originan en la subred de solo proxy. Para obtener más información, consulta la descripción general de los NEG híbridos.

Protocolo de verificación de estado

Aunque no es obligatorio y no siempre es posible, 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. Por el contrario, los balanceadores de cargas de HTTP(S) regionales externos que usan backends de NEG híbridos no admiten verificaciones de estado de gRPC. 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 admite el balanceo de cargas de HTTP(S) en cada modo.

Modo de balanceador de cargas	Tipo de verificación de estado
Balanceador de cargas de HTTP(S) externo global	Global
Balanceador de cargas de HTTP(S) global externo (clásico)	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:

• Descripción general de las verificaciones de estado
• Crea verificaciones de estado

Reglas de firewall

El balanceo de cargas de HTTP(S) requiere las siguientes reglas de firewall:

• Para los balanceadores de cargas de HTTP(S) externos globales, 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 de HTTP(S) regional externo, una regla de permiso de entrada que permite que el tráfico de la subred de solo proxy llegue a tus backends.
• 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.

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 lograr el balanceador de cargas de HTTP(S) externo global y el balanceador de cargas de HTTP(S) externo global (clásico), puedes usar Google Cloud Armor a fin de lograrlo.

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.

En la siguiente tabla, se resumen los rangos de direcciones IP de origen 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 de HTTP(S) externo global	35.191.0.0/16 130.211.0.0/22	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 SERVERLESS y buckets de backend: la red de producción de Google controla el enrutamiento de paquetes.
Balanceador de cargas de HTTP(S) global externo (clásico)	35.191.0.0/16 130.211.0.0/22	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): 35.191.0.0/16 130.211.0.0/22 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	35.191.0.0/16 130.211.0.0/22 Por el momento, los sondeos de verificación de estado de los NEG híbridos se originan en el mecanismo de verificación de estado centralizado de Google. Si no puedes permitir que el tráfico que se origina en los rangos de verificación de estado de Google llegue a tus extremos híbridos y prefieres que los sondeos de verificación de estado se originen en direcciones IP privadas, comunícate con tu representante de cuenta de Google a fin de obtener la lista de entidades permitidas de tu proyecto para las verificaciones de estado distribuidas de Envoy.	La subred de solo proxy que configuras.

Importante: Asegúrate de permitir los paquetes de los rangos de verificación de estado completos. Si la regla de firewall permite paquetes de solo un subconjunto de los rangos, es posible que veas fallas de verificación de estado porque el balanceador de cargas no puede comunicarse con los backends. Esto genera respuestas HTTP 502.

Arquitectura de VPC compartida

El balanceo de cargas de HTTP(S) admite redes que usan VPC compartida. Con la VPC compartida, las organizaciones pueden conectar recursos de varios proyectos a una red de VPC común, de modo que puedan comunicarse entre sí de manera segura y eficiente mediante las IP internas de esa red. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.

Hay muchas formas de configurar el balanceo de cargas de HTTP(S) externo dentro de una red de VPC compartida. Sin importar el tipo de implementación, todos los componentes del balanceador de cargas deben estar en la misma organización.

Balanceador de cargas	Componentes de frontend	Componentes de backend
Balanceador de cargas HTTP(S) externo global, Balanceador de cargas HTTP(S) externo global (clásico)	La dirección IP externa global, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto de servicio o host que los backends.	Se debe definir un servicio de backend global en el mismo proyecto de servicio o host que los backends (grupos de instancias o NEG). Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.
Balanceador de cargas HTTP(S) regional externo	Crea la red y la subred de solo proxy necesarias en el proyecto host de la VPC compartida. La dirección IP externa regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto. Este proyecto puede ser el proyecto host o un proyecto de servicio.	Puedes realizar una de las siguientes acciones: Crea servicios de backend y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en el mismo proyecto de servicio que los componentes del frontend. Crea servicios de backends y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en tantos proyectos de servicio como sea necesario. Un solo mapa de URL puede hacer referencia a servicios de backend en diferentes proyectos. Este tipo de implementación se conoce como referencia de servicio entre proyectos. Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.

Si bien puedes crear todos los componentes y backends del balanceo de cargas en el proyecto host de la VPC compartida, este modelo no separa las responsabilidades de la administración de red y el desarrollo de servicios.

Backends sin servidores en un entorno de VPC compartida

Para un balanceador de cargas que usa un backend de NEG sin servidores, el backend de Cloud Run, Cloud Functions o App Engine de respaldo debe estar en el mismo proyecto que el NEG sin servidores.

Además, para el balanceador de cargas de HTTP(S) externo regional que admite referencias de servicio entre proyectos, el servicio de backend, el NEG sin servidores y el servicio de Cloud Run siempre deben estar en el mismo proyecto de servicio.

Referencia del servicio entre proyectos

En este modelo, el frontend y el mapa de URL del balanceador de cargas se encuentran en un proyecto host o de servicio. Los servicios de backend y los backends del balanceador de cargas se pueden distribuir en todos los proyectos del entorno de VPC compartida. Se puede hacer referencia a los servicios de backend entre proyectos en un solo mapa de URL. Esto se conoce como referencia del servicio entre proyectos.

La referencia del servicio entre proyectos permite a las organizaciones configurar un balanceador de cargas central y enrutar el tráfico a cientos de servicios distribuidos en varios proyectos diferentes. Puedes administrar de forma centralizada todas las reglas y políticas de enrutamiento de tráfico en un mapa de URL. También puedes asociar el balanceador de cargas con un solo conjunto de nombres de host y certificados SSL. Por lo tanto, puedes optimizar la cantidad de balanceadores de cargas necesarios para implementar tu aplicación y reducir la administración, los costos operativos y los requisitos de cuota.

Si tienes proyectos diferentes para cada uno de los equipos funcionales, también puedes lograr la separación de los roles dentro de la organización. Los propietarios del servicio pueden enfocarse en compilar servicios en proyectos de servicio, mientras que los equipos de red pueden aprovisionar y mantener balanceadores de cargas en otro proyecto, y ambos se pueden conectar mediante referencias de servicios entre proyectos.

Los propietarios del servicio pueden mantener la autonomía sobre la exposición de sus servicios y controlar qué usuarios pueden acceder a sus servicios mediante el balanceador de cargas. Esto se logra mediante un rol especial de IAM llamado rol de usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser).

Si deseas obtener información sobre cómo configurar la VPC compartida para un balanceador de cargas de HTTP(S) regional externo (con y sin referencia a servicios entre proyectos), consulta Configura un balanceador de cargas de HTTP(S) regional externo con una VPC compartida.

La referencia del servicio entre proyectos se puede usar con grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible. Si usas NEG sin servidores, debes crear una VM en la red de VPC en la que desees crear el frontend del balanceador de cargas. Para obtener información sobre cómo crear la VM, consulta Configura un balanceador de cargas de HTTP(S) regional externo con Cloud Run.

La referencia del servicio entre proyectos no es compatible con el balanceador de cargas de HTTP(S) externo global ni el balanceador de cargas de HTTP(S) externo global.

Ejemplo 1: frontend y backend del balanceador de cargas en diferentes proyectos de servicio

Este es un ejemplo de una implementación en la que se crean el frontend y el mapa de URL del balanceador de cargas en el proyecto de servicio A, y el mapa de URL hace referencia a un servicio de backend en el proyecto de servicio B.

En este caso, los administradores de red o del balanceador de cargas en el proyecto de servicio A requerirán acceso a los servicios de backend en el proyecto de servicio B. Los administradores del proyecto de servicio B otorgan el rol de IAM compute.loadBalancerServiceUser a los administradores del balanceador de cargas en el proyecto de servicio A que desean hacer referencia al servicio de backend en el proyecto de servicio B.

Frontend y backend del balanceador de cargas en diferentes proyectos de servicio

Ejemplo 2: frontend del balanceador de cargas en el proyecto host y backends en proyectos de servicio

En este tipo de implementación, el frontend y el mapa de URL del balanceador de cargas se crean en el proyecto host y los servicios de backend (y los backends) se crean en los proyectos de servicio.

En este caso, los administradores de red o del balanceador de cargas en el proyecto host requerirán acceso a los servicios de backend en el proyecto de servicio. Los administradores de proyectos de servicio otorgan el rol compute.loadBalancerServiceUser de IAM a los administradores del balanceador de cargas en el proyecto host A que desean hacer referencia al servicio de backend en el proyecto de servicio.

Frontend del balanceador de cargas y mapa de URL en el proyecto host

Todos los componentes y backends del balanceador de cargas en un proyecto de servicio

En este modelo, todos los componentes y backends del balanceador de cargas están en un proyecto de servicio. Este modelo de implementación es compatible con todos los balanceadores de cargas de HTTP(S).

Los componentes del balanceador de cargas y los backends deben usar la misma red de VPC.

Balanceador de cargas de HTTP(S) regional externo en la red de VPC compartida

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

Conexiones del balanceador de cargas de HTTP(S) externo global

Varios proxies llamados Google Front End (GFE) implementan los balanceadores de cargas de HTTP (S) externos globales. 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/16 y 130.211.0.0/22.

Nota: En el caso de los NEG de Internet, las solicitudes del balanceador de cargas provienen de diferentes rangos de IP. Para obtener más información, consulta Autentica solicitudes.

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 basados en Envoy 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 los balanceadores de cargas de HTTP(S) externos globales:

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

Nota: En el caso de los NEG de Internet, las solicitudes del balanceador de cargas provienen de diferentes rangos de IP. Para obtener más información, consulta Autentica solicitudes.

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 globales, 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 a los balanceadores de cargas de HTTP(S) externos globales que se implementan mediante GFE.

Nota: El balanceador de cargas HTTP(S) regional externo se implementa mediante proxies de Envoy, que solo admiten los puertos 80, 8080 y 443.

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 solo para los puertos en los que configuraste una regla de reenvío y en los puertos 80 y 443 si el balanceador de cargas usa una dirección IP del nivel Premium. 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 dan 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 con el puerto TCP 443, el puerto UDP 443 se usa 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 de HTTP(S) externo global	La TLS se finaliza en un GFE, que puede estar en cualquier parte del mundo.
Balanceador de cargas de HTTP(S) global externo (clásico)	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) externo tiene los siguientes 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.

  Nota: La configuración del tiempo de espera del servicio de backend no se puede configurar en los servicios de backend con backends de NEG sin servidores.

  Por ejemplo, si quieres descargar un archivo de 500 MB y el valor del tiempo de espera del servicio de backend es el valor predeterminado de 30 segundos, el balanceador de cargas espera que el backend entregue todo el archivo de 500 MB en 30 segundos. Es posible configurar el tiempo de espera del servicio de backend para que no sea lo suficientemente extenso como para que el backend envíe su respuesta HTTP completa. En esta situación, si el balanceador de cargas al menos recibió encabezados de respuesta HTTP, el balanceador de cargas muestra los encabezados de respuesta completos y todo el cuerpo de respuesta que pudo obtener dentro del tiempo de espera del servicio de backend.

  El tiempo de espera del servicio de backend debe establecerse en el máximo tiempo posible desde el primer byte de la solicitud hasta el último byte de la respuesta para la interacción entre el proxy (GFE o Envoy administrado) y tu backend. Si usas WebSockets, el tiempo de espera del servicio de backend se debe establecer en la duración máxima de un WebSocket, inactivo o activo.

  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.

  El tiempo de espera del servicio de backend que establezcas es un objetivo mejor. No garantiza que las conexiones TCP subyacentes permanezcan abiertas durante el tiempo de espera.

  Puedes establecer el tiempo de espera del servicio de backend con el valor que desees. Sin embargo, establecerlo en un valor superior a un día (86,400 segundos) no significa que el balanceador de cargas mantendrá una conexión TCP en ejecución largo. Google reinicia las tareas de software de GFE y Envoy de forma periódica para las actualizaciones de software y el mantenimiento de rutina, y el tiempo de espera del servicio de backend no anula esas opciones. Mientras más tiempo de espera tenga el servicio de backend, más probable es que Google finalice una conexión TCP para el mantenimiento. Te recomendamos que implementes la lógica de reintento para reducir el impacto de esos eventos.

  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 configurar el tiempo de espera del servicio de backend, usa uno de los siguientes métodos:

  • Consola de Google Cloud: Modifica el campo Tiempo de espera del servicio de backend del balanceador de cargas.
  • Google Cloud CLI: Usa el comando gcloud compute backend-services update para modificar el parámetro --timeout del recurso de servicio de backend.
  • API: Modifica el parámetro timeoutSec para el recurso de servicio de backend global o regional.

  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.

• Hay dos tiempos de espera aplicables cuando los buckets de backend se usan con el balanceador de cargas HTTP(S) externo global y la versión clásica del balanceador de cargas HTTP(S) externo global:
• Un tiempo de espera de inactividad fijo en 6 minutos. Esto significa que las transmisiones HTTP del bucket de backend se consideran inactivas después de 6 minutos de actividad.
• Otro tiempo de espera que incluye el tiempo de procesamiento de respuesta completo que tomó el balanceador de cargas y Cloud Storage. Este tiempo de espera se fija en 24 horas.

• 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 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;

Reintentos

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 de HTTP(S) externo global	Se puede configurar mediante una política de reintento en el mapa de URL. La cantidad predeterminada de reintentos (numRetries) es 1; la cantidad máxima de reintentos que se pueden configurar con la política de reintentos es de 25. El tiempo de espera predeterminado para cada intento (perTryTimeout) es de 30 segundos con un perTryTimeout máximo configurable de 24 horas. Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo, solicitudes GET) y dan como resultado respuestas HTTP 502, 503 o 504 (retryConditions=["gateway-error"]) se reintentan una vez. Las solicitudes HTTP POST no se reintentan. Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.
Balanceador de cargas de HTTP(S) global externo (clásico)	No se puede cambiar la política de reintento para los reintentos de conexión. 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. Los reintentos de solicitudes se limitan a 25 intentos. 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. La cantidad predeterminada de reintentos (numRetries) es 1; la cantidad máxima de reintentos que se pueden configurar con la política de reintentos es de 25. El tiempo de espera predeterminado para cada intento (perTryTimeout) es de 30 segundos con un perTryTimeout máximo configurable de 24 horas. Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo, solicitudes GET) y dan como resultado respuestas HTTP 502, 503 o 504 se reintentan una vez. Las solicitudes HTTP POST no se reintentan. Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.

El protocolo WebSocket es compatible con GKE Ingress.

Solicitud ilegal y manejo de respuestas

El balanceador de cargas 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 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 tamaño total de los encabezados y la URL de la solicitud supera el límite del tamaño máximo del encabezado de solicitud para el balanceo de cargas de HTTP(S) externo.
• El método de solicitud no permite un cuerpo, pero la solicitud tiene uno.
• La solicitud contiene un encabezado Upgrade. El encabezado Upgrade no se usa para habilitar las conexiones WebSocket.
• La versión HTTP es desconocida.

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 distribución del tráfico entre backends depende del modo del balanceador de cargas.

Balanceador de cargas de HTTP(S) externo global

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 el balanceador de cargas de HTTP(S) externo global (clásico), el modo de balanceo se usa a fin de seleccionar el backend (grupo de instancias o NEG) más favorable. Luego, el tráfico se distribuye de forma round robin entre las instancias o los extremos dentro del backend.

Para el balanceador de cargas de HTTP(S) externo global, el balanceo de cargas tiene dos niveles. El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG). Luego, la política de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico en las instancias o extremos dentro del grupo. Para obtener más información, consulta la política de localidad del balanceo de cargas (documentación de la API del servicio de backend).

Balanceador de cargas HTTP(S) regional externo

Para los balanceadores de cargas de HTTP(S) externos regionales, 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, consulta lo siguiente:

• Modos de balanceo
• Política de balanceo de cargas de la localidad (documentación de la API de servicio de backend regional).

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:

• 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. El proceso documentado aquí todavía es válido, pero el balanceador de cargas solo dirige las 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 un hash coherente para el balanceador de cargas de HTTP(S) externo global y se puede configurar mediante la política de localidad de balanceo de cargas para el balanceador de cargas de HTTP(S) externo global y balanceador de cargas de HTTP(S) externo regional.

Los balanceadores de cargas de HTTP(S) externos globales basados en GFE usan el siguiente proceso para distribuir las solicitudes entrantes:

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 a un sistema de balanceo de cargas de capa 3/4 (Maglev).
2. 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.

3. La segunda capa de GFE dirige las solicitudes a backends en zonas dentro de su región.
4. 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.

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.

5. 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) ofrece los siguientes tipos de afinidad de sesión:

• NONE. No se configuró la afinidad de sesión para el balanceador de cargas.
• Afinidad de IP de cliente
• Afinidad de cookie generada
• Afinidad de campo de encabezado
• Afinidad de cookie HTTP

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

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 de HTTP(S) externo global
Balanceador de cargas de HTTP(S) global externo (clásico)
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 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. Como resultado, es posible que veas latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
• 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 la consola de Google Cloud. 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.

Compatibilidad con HTTP/3 y QUIC de Google

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

Google QUIC incluye la aplicación y la capa de transporte en el modelo OSI. Es la versión anterior de la combinación de HTTP/3 y IETF QUIC.

En particular, haz lo siguiente:

• IETF 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 se utiliza QUIC para manejar la multiplexación, el control de congestión, la detección de pérdida y la retransmisión.
• 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 algoritmo de control de congestión BBR.

Habilitar HTTP/3 en el balanceador de cargas 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.

En la siguiente tabla, se especifica la compatibilidad de HTTP/3 con el balanceo de cargas de HTTP(S) en cada modo.

Modo de balanceador de cargas	Compatibilidad con HTTP/3
Balanceador de cargas de HTTP(S) externo global (siempre del nivel Premium)
Balanceador de cargas de HTTP(S) externo global (clásico) en el nivel Premium
Balanceador de cargas de HTTP(S) externo global en el nivel Estándar
Balanceador de cargas de HTTP(S) regional externo (siempre el nivel Estándar)

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 HTTP/3.
• 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 HTTP/3 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 comoENABLE en un balanceador de cargas HTTP(S) externotargetHttpsProxy recurso, las respuestas del balanceador de cargas incluyen el siguiente valor del encabezado alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":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"

Nota: El encabezado Alt-Svc anuncia varias versiones de HTTP/3 a fin de admitir los borradores anteriores que se usan en algunos clientes (p. ej., h3-29), así como las versiones de Google QUIC (h3-Q050) que también están en uso. Las versiones anteriores de ambos protocolos se quitarán del anuncio Alt-Svc.

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

Cuando tienes HTTP/3 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 HTTP/3. Se incluyen las siguientes:

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

Configura HTTP/3.

Para habilitar de forma explícita la compatibilidad con HTTP/3 en tu balanceador de cargas, configura quicOverride como ENABLE.

Cuando habilitas HTTP/3, el balanceador de cargas lo anuncia a los clientes, lo que permite que los clientes que lo admiten negocien una versión HTTP/3 con el balanceador de cargas. Los clientes que no admiten HTTP/3 no negocian una conexión HTTP/3. No es necesario que inhabilites HTTP/3 de forma explícita, a menos que hayas identificado implementaciones de cliente dañadas.

El balanceo de cargas de HTTP(S) proporciona tres formas de configurar HTTP/3, como se muestra en la siguiente tabla.

Valor quicOverride	Comportamiento
NONE	La compatibilidad con HTTP/3 se anuncia a los clientes.
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 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

Nota: Por el momento, la negociación de HTTP/3 no se admite en la página de proxies de destino y debe configurarse mediante la edición de la configuración del balanceador de cargas.

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

   Ir a Balanceo de cargas

2. Selecciona el balanceador de cargas 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): Permite que Google controle cuándo se anuncia HTTP/3.

  Por el momento, cuando seleccionas NONE, HTTP/3 se anuncia a los clientes, pero Google QUIC no se anuncia.

  En la consola de Google Cloud, 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): Permite que Google controle cuándo se anuncia HTTP/3.

  Por el momento, cuando seleccionas NONE, HTTP/3 se anuncia a los clientes, pero Google QUIC no se anuncia.

  En la consola de Google Cloud, 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.

Limitaciones

• Los balanceadores de cargas de HTTPS no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.
• Los balanceadores de cargas HTTPS no envían una alerta de cierre close_notify cuando finalizan conexiones SSL. Es decir, el balanceador de cargas cierra la conexión TCP en lugar de realizar un cierre SSL.
• Los balanceadores de cargas de HTTPS solo admiten caracteres en minúsculas en dominios en un atributo de nombre común (CN) o un nombre de entidad alternativo (SAN) del certificado. Los certificados con caracteres en mayúscula en los dominios solo se muestran cuando se configuran como el certificado principal en el proxy de destino.
• Los balanceadores de cargas HTTPS no usan la extensión de indicación del nombre del servidor (SNI) cuando se conectan al backend, excepto los balanceadores de cargas con backends de NEG de Internet. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.
• Cuando se usan balanceadores de cargas de HTTP(S) regionales externos con Cloud Run en un entorno de VPC compartida, las redes de VPC independientes en los proyectos de servicio pueden enviar tráfico a cualquier otro servicio de Cloud Run implementado en cualquier otro proyecto de servicio dentro del mismo entorno de VPC compartida. Este es un problema conocido, y esta forma de acceso se bloqueará en el futuro.
• reCAPTCHA Enterprise para WAF con Google Cloud Armor solo es compatible con el balanceador de cargas de HTTP(S) externo global (clásico). No es compatible con el balanceador de cargas de HTTP(S) externo global con capacidad avanzada de administración de tráfico.

¿Qué sigue?

• Si deseas obtener información sobre cómo implementar un balanceador de cargas HTTP(S) externo global, consulta Configura un balanceador de cargas HTTP(S) externo con un backend de Compute Engine.
• Si deseas obtener información sobre cómo implementar un balanceador de cargas HTTP(S) regional externo, consulta Configura un balanceador cargas de HTTP(S) regional externo con un backend de Compute Engine.
• Si eres un usuario existente del balanceador de cargas de HTTP(S) externo global (clásico), asegúrate de revisar Planifica la migración al balanceador de cargas de HTTP(S) externo global cuando planifiques una implementación nueva con el balanceador de cargas de HTTP(S) externo global.
• Si deseas obtener información sobre cómo automatizar tu configuración de balanceo de cargas de HTTP(S) externo con Terraform, consulta los ejemplos de módulos de Terraform para balanceadores de cargas HTTP(S) externos.
• Si quieres obtener información sobre cómo configurar las capacidades de administración avanzada del tráfico disponibles con el balanceador de cargas de HTTP(S) externo global, consulta Descripción general de la administración del tráfico en los balanceadores de cargas de HTTP(S) externos globales.
• Si deseas obtener información sobre cómo configurar las capacidades de administración avanzada del tráfico disponibles con el balanceador de cargas de HTTP(S) regional externo, consulta Descripción general de la administración del tráfico en los balanceadores de cargas de HTTP(S) regionales.
• Para encontrar las ubicaciones de los PoP de Google, consulta Ubicaciones de GFE.
• Para obtener más información sobre la administración de capacidad, consulta el instructivo de administración de la capacidad con balanceo de cargas y Optimización de la capacidad de las aplicaciones con balanceo de cargas global.
• Para obtener más información sobre la entrega de sitios web, consulta Entrega sitios web.
• Si quieres obtener información sobre cómo usar el Administrador de certificados para aprovisionar y administrar certificados SSL, consulta la Descripción general del Administrador de certificados.