Descripción general del balanceador de cargas de aplicaciones externo

En este documento, se presentan los conceptos que necesitas para configurar un balanceador de cargas de aplicaciones externo.

Un balanceador de cargas de aplicaciones externo es un balanceador de cargas de capa 7 basado en proxies que te permite ejecutar y escalar tus servicios detrás de una sola dirección IP externa. El balanceador de cargas de aplicaciones externo distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad deGoogle Cloud plataformas (como Compute Engine, Google Kubernetes Engine (GKE) y Cloud Storage), así como backends externos conectados a través de Internet o mediante la conectividad híbrida. Para obtener más detalles, consulta Descripción general del balanceador de cargas de aplicaciones: casos de uso.

Modos de operación

Puedes configurar un balanceador de cargas de aplicaciones externo en los siguientes modos:

• Balanceador de cargas de aplicaciones 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 y las transformaciones de encabezados basadas en solicitudes o respuestas.
• Balanceador de cargas de aplicaciones clásico Este es el balanceador de cargas de aplicaciones externo clásico que es global en el nivel Premium, pero se puede configurar para que sea regional en el nivel Standard. Este balanceador de cargas se implementa en Google Front End (GFE). Los GFEs se distribuyen globalmente y operan juntos mediante el plano de control y la red global de Google.
• Balanceador de cargas de aplicaciones externo regional Este es un balanceador de cargas regional se implementa como un servicio administrado en el proxy de código abierto de Envoy. Incluye capacidades de administración de tráfico avanzadas, como duplicación de tráfico, división de tráfico basada en pesos y transformaciones de encabezados basadas en solicitudes o respuestas.

Identifica el modo

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

Arquitectura

Los siguientes recursos son necesarios para implementar el balanceador de cargas de aplicaciones externo:

• Solo para balanceadores de cargas de aplicaciones regionales externos, se usa una subred de solo proxy para 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 a través del 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 aplicaciones 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 pueden procesar la solicitud.

• Reglas de firewall para que tus backends acepten sondeos de verificaciones de estado. Los balanceadores de cargas de aplicaciones 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 de aplicaciones externo global. Esta arquitectura se aplica al balanceador de cargas de aplicaciones externo global y al balanceador de cargas de aplicaciones clásico en el nivel Premium.

Regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones externo regional.

Subred de solo proxy

Las subredes de solo proxy solo son necesarias para los balanceadores de cargas de aplicaciones externos regionales.

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 aplicaciones externos regionales. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas regionales 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 de aplicaciones externos regionales 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 de aplicaciones externo regional 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, migra 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.

Reglas de reenvío y direcciones IP

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.

Especificación de la dirección IP 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.

Especificación de puerto Cada regla de reenvío para un balanceador de cargas de aplicaciones puede hacer referencia a un puerto único del 1 al 65535. Para admitir varios puertos, debes configurar varias reglas de reenvío. Puedes configurar varias reglas de reenvío para usar la misma dirección IP externa (VIP) y hacer referencia al mismo proxy HTTP(S) de destino siempre que la combinación general de la dirección IP, el puerto y el protocolo son únicos para cada regla de reenvío. De esta manera, puedes usar un solo balanceador de cargas con un mapa de URL compartido como proxy para varias aplicaciones.

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

Para obtener una lista completa de los protocolos que admiten las reglas de reenvío del balanceador de cargas de aplicaciones externo en cada modo, consulta Funciones del balanceador de cargas.

Reglas de reenvío y redes de VPC

En esta sección, se describe cómo las reglas de reenvío que usan los balanceadores de cargas de aplicaciones externos se asocian con las redes de VPC.

Proxies de destino

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

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

En la siguiente tabla, se especifica el tipo de proxy de destino que requieren los balanceadores de cargas de aplicaciones externos.

Además de los encabezados que agrega el proxy de destino, el balanceador de cargas ajusta otros encabezados HTTP de las siguientes maneras:

• Para el balanceador de cargas de aplicaciones externo global, los encabezados de solicitud y respuesta se pueden convertir en minúsculas.

  La única excepción es cuando usas backends de NEG de Internet globales con HTTP/1.1. Para obtener detalles sobre cómo se procesan los encabezados HTTP/1.1 con los NEG de Internet globales, consulta la descripción general de los NEG de Internet.

• Para el balanceador de cargas de aplicaciones clásico, los encabezados de respuesta y solicitud se convierten en minúsculas, excepto cuando usas HTTP/1.1. Con HTTP/1.1, los encabezados están en mayúsculas y minúsculas. La primera letra de la clave del encabezado y todas las letras que siguen a un guion (-) se escriben en mayúsculas para preservar la compatibilidad con clientes HTTP/1.1. Por ejemplo, user-agent se cambia a User-Agent, y content-encoding se cambia a Content-Encoding.

• Algunos encabezados se combinan. Cuando hay varias instancias de la misma clave de encabezado (por ejemplo, Via), el balanceador de cargas combina sus valores en una lista separada por comas para una sola clave de encabezado. Solo se agrupan los encabezados cuyos valores se pueden representar como una lista separada por comas. Otros encabezados, como Set-Cookie, nunca se combinan.

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 al encabezado X-Forwarded-For, separadas por una sola coma, en el siguiente orden:

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

Si la solicitud entrante no incluye un encabezado X-Forwarded-For, el encabezado resultante es el siguiente:

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

Si la solicitud entrante ya incluye un encabezado X-Forwarded-For, el balanceador de cargas agrega sus valores al encabezado existente:

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

Cómo quitar valores de encabezado existentes con un encabezado de solicitud personalizado

Es posible quitar los valores de encabezado existentes con encabezados de solicitud personalizados en el servicio de backend. En el siguiente ejemplo, se usa la marca --custom-request-header para volver a crear el encabezado X-Forwarded-For con las variables client_ip_address y server_ip_address. Esta configuración reemplaza el encabezado X-Forwarded-For entrante solo con la dirección IP del cliente y del balanceador de cargas.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Cómo el software de proxy inverso de backend podría modificar el encabezado X-Forwarded-For

Si los backends de tu balanceador de cargas ejecutan software de proxy HTTP inverso, es posible que el software adjunte una o las siguientes dos direcciones IP al final del encabezado X-Forwarded-For:

1. Es la dirección IP del GFE que se conectó al backend. Las direcciones IP de GFE se encuentran en los rangos 130.211.0.0/22 y 35.191.0.0/16.

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

Como resultado, un sistema upstream podría ver un encabezado X-Forwarded-For estructurado de la siguiente manera:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Compatibilidad con Cloud Trace

Trace no es compatible con los balanceadores de cargas de aplicaciones. Los balanceadores de cargas de aplicaciones globales y clásicos agregan el encabezado X-Cloud-Trace-Context si no está presente. El balanceador de cargas de aplicaciones externo regional no agrega este encabezado. Si el encabezado X-Cloud-Trace-Context ya está presente, pasa por los balanceadores de cargas sin modificaciones. Sin embargo, el balanceador de cargas no exporta ningún registro ni intervalo.

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. El mapa de URL te permite dividir el tráfico a través del análisis de los componentes de URL para enviar solicitudes a diferentes conjuntos de backends. 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.

Los mapas de URL admiten varias funciones avanzadas de administración de tráfico, como el direccionamiento de tráfico basado 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 de aplicaciones externo global.

• Descripción general de la administración del tráfico en el balanceador de cargas de aplicaciones externo regional.

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

Certificados SSL

Los balanceadores de cargas de aplicaciones 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: los certificados 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 certificados: 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 tipo de balanceador de cargas de aplicaciones externo (global, regional o clásico) 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 en la descripción general de certificados SSL. Google Cloud

Políticas de SSL

Las políticas de SSL especifican el conjunto de características de SSL que los balanceadores de cargas 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.

Servicios de backend

Un servicio de backend proporciona información de configuración al balanceador de cargas para que pueda dirigir las solicitudes a sus backends, por ejemplo, grupos de instancias de Compute Engine o grupos de extremos de red (NEG). Para obtener más información sobre los servicios de backend, consulta la Descripción general de los servicios de backend.

Para ver un ejemplo que muestra cómo configurar un balanceador de cargas con un servicio de backend y un backend de Compute Engine, consulta Configura un balanceador de cargas de aplicaciones externo con un backend de Compute Engine.

Permiso del servicio de backend

En la siguiente tabla, se indica qué recurso y alcance del servicio de backend usan los balanceadores de cargas de aplicaciones externos:

Protocolo para los backends

Los servicios de backend para los balanceadores de cargas de aplicaciones deben usar uno de los siguientes protocolos para enviar solicitudes a los backends:

• HTTP, que usa HTTP/1.1 y no usa TLS
• HTTPS, que usa HTTP/1.1 y TLS
• HTTP/2, que usa HTTP/2 y TLS (no se admite HTTP/2 sin encriptación)
• H2C, que usa HTTP/2 a través de TCP No se requiere TLS. H2C no es compatible con los balanceadores de cargas de aplicaciones clásicos.

El balanceador de cargas solo usa el protocolo del servicio de backend que especifiques para comunicarse con sus backends. El balanceador de cargas no recurre a un protocolo diferente si no puede comunicarse con los backends usando el protocolo de servicio de backend especificado.

El protocolo del servicio de backend no necesita coincidir con el protocolo que usan los clientes para comunicarse con el balanceador de cargas. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de cargas con HTTP/2, pero el balanceador de cargas puede comunicarse con los backends con HTTP/1.1 (HTTP o HTTPS).

Buckets de backend

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 de aplicaciones externo, consulta Configura un balanceador de cargas con buckets de backend. Para obtener información general sobre Cloud Storage, consulta ¿Qué es Cloud Storage?

Backends

En la siguiente tabla, se especifican los backends y las funciones relacionadas que admiten los balanceadores de cargas de aplicaciones externos en cada modo.

Backends y redes de VPC

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

Para los backends del balanceador de cargas de aplicaciones externo global, se aplica lo siguiente:

• Las instancias de backend (para backends de grupos de instancias) y los extremos de backend (para backends de NEG) pueden ubicarse en cualquier red de VPC dentro de la misma organización. No es necesario que las diferentes redes de VPC estén conectadas a través del intercambio de tráfico entre redes de VPC, ya que los GFEs se comunican de forma directa con los backends en sus respectivas redes de VPC.

• Los buckets de Cloud Storage no están asociados a una red de VPC. Pueden ubicarse en cualquier proyecto dentro de la misma organización.

  Los balanceadores de cargas de aplicaciones externos globales también admiten entornos de VPC compartida en los que puedes compartir redes de VPC y sus recursos asociados entre proyectos. Sin embargo, para los balanceadores de cargas de aplicaciones externos globales, no es necesario que configures la VPC compartida para poder hacer referencia a los servicios de backend o los buckets de backend de otros proyectos de tu organización.

Para los backends del balanceador de cargas de aplicaciones clásico, se aplica lo siguiente:

• Todas las instancias de backend de los backends de grupos de instancias y todos los extremos de backend de los backends de NEG deben estar ubicados en el mismo proyecto. Sin embargo, un backend de grupo de instancias o un NEG pueden usar una red de VPC diferente en ese proyecto. No es necesario que las diferentes redes de VPC estén conectadas a través del intercambio de tráfico entre redes de VPC, ya que los GFEs se comunican de forma directa con los backends en sus respectivas redes de VPC.

• Los buckets de Cloud Storage no están asociados a una red de VPC. Sin embargo, deben estar ubicadas en el mismo proyecto que el balanceador de cargas.

Para los backends de balanceadores de cargas de aplicaciones externos regionales, se aplica lo siguiente:

• Para los grupos de instancias, los NEGs zonales y los NEG de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y región que el servicio de backend. Sin embargo, un balanceador de cargas puede hacer referencia a un backend que usa una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red de VPC del balanceador de cargas y la red de VPC del backend se puede configurar mediante el intercambio de tráfico entre redes de VPC, túneles de Cloud VPN, adjuntos de VLAN de Cloud Interconnect o un framework de Network Connectivity Center.

  Definición de la red de backend

  • En el caso de los NEGs zonales y los híbridos, debes especificar de forma explícita la red de VPC cuando creas el NEG.
  • En los grupos de instancias administrados, la red de VPC se define en la plantilla de instancias.
  • En los grupos de instancias no administrados, la red de VPC del grupo de instancias se configura para que coincida con la red de VPC de la interfaz nic0 de la primera VM que se agrega al grupo de instancias.

  Requisitos de red del backend

  La red de tu backend debe satisfacer uno de los siguientes requisitos de red:

  • La red de VPC del backend debe coincidir exactamente con la red de VPC de la regla de reenvío.

  • La red de VPC del backend debe estar conectada a la red de VPC de la regla de reenvío mediante el intercambio de tráfico entre redes de VPC. Debes configurar intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.

• Tanto la red de VPC del backend como la red de VPC de la regla de reenvío deben ser radios de VPC conectados al mismo concentrador de Network Connectivity Center. Los filtros de importación y exportación deben permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.

• Para todos los demás tipos de backends, todos deben estar ubicados en la misma red de VPC y región.

  Los balanceadores de cargas de aplicaciones externos regionales también admiten entornos de VPC compartida en los que puedes compartir redes de VPC y sus recursos asociados entre proyectos. Si quieres que el servicio de backend y los backends del balanceador de cargas de aplicaciones externo regional estén en un proyecto diferente al de la regla de reenvío, debes configurar el balanceador de cargas en un entorno de VPC compartida con referencias a servicios entre proyectos.

Interfaces de red y backends

Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a interfaces que no son de nic0 (ya sean vNICs o interfaces de red dinámicas), usa backends de NEG en su lugar.

Si usas backends de NEG zonales, los paquetes se envían a cualquier interfaz de red que represente el extremo en el NEG. Los extremos del NEG deben estar en la misma red de VPC que la red de VPC definida explícitamente en el NEG.

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 a partir del mecanismo centralizado de verificación de estado de Google.

Los balanceadores de cargas de aplicaciones 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 aplicaciones externos regionales 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 las verificaciones de estado que admiten los balanceadores de cargas de aplicaciones externos en cada modo.

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 balanceador de cargas requiere las siguientes reglas de firewall:

• Para los balanceadores de cargas de aplicaciones externos globales, una regla de permiso de entrada que permite que el tráfico de Google Front Ends (GFEs) llegue a tus backends. Para el balanceador de cargas de aplicaciones externo regional, 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 sondeo 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 Google Cloud reglas de firewall para evitar que el tráfico llegue al balanceador de cargas. Para el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones clásico, puedes usarGoogle Cloud Armor para 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 a través de 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:

Compatibilidad con GKE

GKE usa balanceadores de cargas de aplicaciones externos de las siguientes maneras:

• Las puertas de enlace externas creadas con el controlador de GKE Gateway pueden usar cualquier modo de un balanceador de cargas de aplicaciones externo. Puedes controlar el modo del balanceador de cargas eligiendo un objeto GatewayClass. El controlador de la puerta de enlace de GKE siempre usa back-ends de NEG zonales GCE_VM_IP_PORT.

• Los objetos Ingress externos creados con el controlador de Ingress de GKE siempre son balanceadores de cargas de aplicaciones clásicos. El controlador de Ingress de GKE prefiere usar backends de NEG zonales de GCE_VM_IP_PORT, aunque también se admiten backends de grupos de instancias.

• Puedes usar el NEG zonal GCE_VM_IP_PORT creado y administrado por los servicios de GKE como backends para cualquier balanceador de cargas de aplicaciones o balanceador de cargas de red de proxy. Para obtener más información, consulta Balanceo de cargas nativo del contenedor a través de NEG zonales independientes.

Arquitectura de VPC compartida

Los balanceadores de cargas de aplicaciones externos admiten redes que usan VPC compartida. Con la VPC compartida, las organizaciones pueden conectar recursos de varios proyectos a una red de VPC común para que puedan comunicarse entre ellas de forma segura y eficiente a través de 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 un balanceador de cargas de aplicaciones 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.

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

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

En el siguiente diagrama de arquitectura, se muestra una implementación de VPC compartida estándar en la que todos los componentes y backends del balanceador de cargas se encuentran en un proyecto de servicio. Este tipo de implementación es compatible con todos los balanceadores de cargas de aplicaciones.

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

Backends sin servidores en un entorno de VPC compartida

Para un balanceador de cargas que usa un backend de NEG sin servidores, el servicio de backend de Cloud Run o funciones de Cloud Run debe estar en el mismo proyecto que el NEG sin servidores.

Además, para el balanceador de cargas de aplicaciones 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

La referencia de servicio entre proyectos es un modelo de implementación en el que el frontend y el mapa de URL del balanceador de cargas se encuentran en un proyecto, y el servicio de backend y los backends del balanceador de cargas se encuentran en un proyecto diferente.

La referencia a servicios 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 las 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 a través de 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 a través de 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).

La compatibilidad con la referencia del servicio entre proyectos varía según el tipo de balanceador de cargas:

• Para los balanceadores de cargas de aplicaciones externos globales: El frontend y el mapa de URL de tu balanceador de cargas pueden hacer referencia a servicios de backend o buckets de backend de cualquier proyecto dentro de la misma organización. No se aplican restricciones a las redes de VPC. Si bien puedes usar un entorno de VPC compartida para configurar una implementación entre proyectos, como se muestra en este ejemplo, esto no es un requisito.

• Para los balanceadores de cargas de aplicaciones externos regionales: Debes crear el balanceador de cargas en un entorno de VPC compartida. El frontend y el mapa de URL del balanceador de cargas deben estar en un proyecto host o de servicio, y los servicios de backend y los backends del balanceador de cargas se pueden distribuir en proyectos host o de servicio en el mismo entorno de VPC compartida.

Si deseas obtener información para configurar la VPC compartida para un balanceador de cargas de aplicaciones externo regional, con y sin referencias de servicios entre proyectos, consulta Configura un balanceador de cargas de aplicaciones externo regional con VPC compartida.

Notas de uso para la referencia del servicio entre proyectos

• La referencia del servicio entre proyectos se puede usar con grupos de instancias, NEG sin servidores y la mayoría de los demás tipos de backend compatibles. Sin embargo, se aplican las siguientes limitaciones:

  • Con los balanceadores de cargas de aplicaciones externos globales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG sin servidores con App Engine.

  • Con los balanceadores de cargas de aplicaciones externos regionales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG de Internet regionales.
• La referencia del servicio entre proyectos no es compatible con el balanceador de cargas clásico de aplicaciones.
• Google Cloud no diferencia entre los recursos (por ejemplo, los servicios de backend) que usan el mismo nombre en varios proyectos. Por lo tanto, cuando usas la referencia de servicios entre proyectos, te recomendamos que uses nombres de servicio de backend únicos en todos los proyectos de tu organización.
• Si ves un error como "No se permiten las referencias entre proyectos de este recurso", asegúrate de tener permiso para usar el recurso. Un administrador del proyecto propietario del recurso debe otorgarte el rol de usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser). Este rol se puede otorgar a nivel del proyecto o del recurso. Para ver un ejemplo, consulta Otorga permisos al administrador del balanceador de cargas de Compute para usar el servicio de backend o el bucket de backend.

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

Este es un ejemplo de una implementación de VPC compartida 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 requieren acceso a los servicios de backend en el proyecto de servicio B. Los administradores del proyecto de servicio B otorgan el rol Usuario de servicios del balanceador de cargas de Compute (roles/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.

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

Este es un ejemplo de una implementación de VPC compartida en la que se crean el frontend y el mapa de URL del balanceador de cargas 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 requieren acceso a los servicios de backend en el proyecto de servicio. Los administradores de proyectos de servicio otorgan el rol Usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser) 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.

Ejemplo 3: Frontend y backends del balanceador de cargas en diferentes proyectos

Este es un ejemplo de una implementación en la que el frontend y el mapa de URL del balanceador de cargas de aplicaciones externo global se crean en un proyecto diferente del servicio de backend y los backends del balanceador de cargas. Este tipo de implementación no usa la VPC compartida y solo es compatible con los balanceadores de cargas de aplicaciones externos globales.

Para obtener más información sobre esta configuración, consulta Configura referencias de servicios entre proyectos con un servicio de backend y un bucket de backend.

Alta disponibilidad y conmutación por error

La alta disponibilidad y la conmutación por error en los balanceadores de cargas de aplicaciones externos se pueden configurar a nivel del balanceador de cargas. Esto se controla creando balanceadores de cargas de aplicaciones externos regionales de copia de seguridad en cualquier región en la que los necesites.

En la siguiente tabla, se describe el comportamiento de la conmutación por error.

Compatibilidad con HTTP/2

HTTP/2 es una revisión importante del protocolo HTTP/1. Existen 2 modos de compatibilidad con HTTP/2:

• HTTP/2 sobre TLS
• Texto simple HTTP/2 a través de TCP

HTTP/2 sobre TLS

HTTP/2 a través de TLS es compatible con las conexiones entre los clientes y el balanceador de cargas de aplicaciones externo, y con las conexiones entre el balanceador de cargas y sus backends.

El balanceador de cargas negocia automáticamente HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS. Incluso si un balanceador de cargas está configurado para usar HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas.

Si un cliente no admite HTTP/2 y el balanceador de cargas está configurado para usar HTTP/2 entre el balanceador de cargas y las instancias de backend, es posible que el balanceador de cargas aún negocie una conexión HTTPS o acepte solicitudes HTTP no seguras. Luego, el balanceador de cargas transforma esas solicitudes HTTPS o HTTP para representarlas a través de HTTP/2 en las instancias de backend.

Para usar HTTP/2 a través de TLS, debes habilitar TLS en tus backends y configurar el protocolo del servicio de backend enHTTP2. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

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 deGoogle 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 HTTP o HTTPS, 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 o HTTPS, no está disponible con HTTP/2. 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 deGoogle Cloud ni en la consola de Google Cloud . Si el extremo de gRPC devuelve un error, los registros del balanceador de cargas y los datos de supervisión informan el código de estado HTTP 200 OK.

HTTP/2 de texto simple a través de TCP (H2C)

HTTP/2 de texto no cifrado a través de TCP, también conocido como H2C, te permite usar HTTP/2 sin TLS. H2C se admite para las siguientes conexiones:

• Conexiones entre los clientes y el balanceador de cargas No se requiere ninguna configuración especial.

• Conexiones entre el balanceador de cargas y sus backends

  Para configurar H2C para las conexiones entre el balanceador de cargas y sus backends, debes establecer el protocolo del servicio de backend en H2C.

La compatibilidad con H2C también está disponible para los balanceadores de cargas creados con el controlador de Gateway de GKE y Cloud Service Mesh.

H2C no es compatible con los balanceadores de cargas de aplicaciones clásicos.

Compatibilidad con HTTP/3

HTTP/3 es un protocolo de Internet de nueva 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 de aplicaciones externo, Cloud CDN y los clientes.

Específicamente:

• IETF QUIC es un protocolo de capa de transporte que proporciona control de congestión y confiabilidad similar a TCP. Usa TLS 1.3 para la seguridad y 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.
• HTTP/3 es compatible con conexiones entre clientes y el balanceador de cargas, no 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 balanceadores de cargas de aplicaciones externos en cada modo.

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 está habilitado, 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"

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 que admite 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 impide 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 con anterioridad sean aceptables para tus cargas de trabajo.

Configura HTTP/3

NONE (la opción predeterminada) y ENABLE habilitan la compatibilidad con HTTP/3 para tu balanceador de cargas.

Cuando el HTTP/3 está habilitado, 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.

Los balanceadores de cargas de aplicaciones externos proporcionan tres formas de configurar HTTP/3, como se muestra en la siguiente tabla.

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

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

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

{
  "quicOverride": QUIC_SETTING
}

Compatible con WebSocket

Google Cloud Los balanceadores de cargas basados en HTTP(S) admiten 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 de WebSocket proporciona un canal de comunicación dúplex completo entre los clientes y el balanceador de cargas. Para obtener más información, consulta RFC 6455.

El protocolo WebSocket funciona de la siguiente manera:

1. El balanceador de cargas reconoce una solicitud Upgrade de WebSocket de un cliente HTTP o HTTPS. La solicitud contiene los encabezados Connection: Upgrade y Upgrade: websocket, seguidos de otros encabezados de solicitud relevantes relacionados con WebSocket.
2. El backend envía una respuesta Upgrade de WebSocket. La instancia de backend envía una respuesta 101 switching protocol con encabezados Connection: Upgrade y Upgrade: websocket, y otros encabezados de respuesta relacionados con WebSocket.
3. El balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual.

Si la instancia de backend devuelve un código de estado 426 o 502, el balanceador de cargas cierra la conexión.

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

Compatibilidad con gRPC

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 Google Cloud aplicaciones, debes enviar solicitudes proxy de extremo a extremo a través de HTTP/2. Para ello, crea un balanceador de cargas de aplicaciones con una de las siguientes configuraciones:

• Para el tráfico sin encriptar de extremo a extremo (sin TLS): Crea un balanceador de cargas de HTTP (configurado con un proxy HTTP de destino). Además, puedes configurar el balanceador de cargas para que use HTTP/2 en las conexiones sin encriptar entre el balanceador de cargas y sus backends. Para ello, configura el protocolo del servicio de backend en H2C.

• Para el tráfico encriptado de extremo a extremo (con TLS): Crea un balanceador de cargas HTTPS (configurado con un proxy HTTPS de destino y un certificado SSL). El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS.

  Además, debes asegurarte de que los backends puedan controlar el tráfico de TLS y configurar el balanceador de cargas para que use HTTP/2 en las conexiones encriptadas entre el balanceador de cargas y sus backends. Para ello, configura el protocolo del servicio de backend en HTTP2.

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

Si quieres configurar un balanceador de cargas de aplicaciones a través de HTTP/2 con Ingress de Google Kubernetes Engine o a través de gRPC y HTTP/2 con Ingress, consulta HTTP/2 para el balanceo de cargas con Ingress.

Si quieres configurar un balanceador de cargas de aplicaciones externo a través de HTTP/2 con Cloud Run, consulta Usa HTTP/2 detrás de un balanceador de cargas.

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.

Compatibilidad con TLS

De forma predeterminada, un proxy HTTPS de destino solo acepta TLS 1.0, 1.1, 1.2 y 1.3 cuando finaliza las solicitudes SSL del cliente.

Cuando el balanceador de cargas de aplicaciones clásico usa HTTPS como protocolo de servicio de backend, puede negociar TLS 1.0, 1.1, 1.2 o 1.3 para el backend.

Compatibilidad con TLS mutua

La TLS mutua, o mTLS, es un protocolo estándar de la industria para la autenticación mutua entre un cliente y un servidor. La mTLS ayuda a garantizar que tanto el cliente como el servidor se autentiquen mutuamente verificando que cada uno tenga un certificado válido emitido por una autoridad certificadora (CA) de confianza. A diferencia de la TLS estándar, en la que solo se autentica el servidor, la mTLS requiere que tanto el cliente como el servidor presenten certificados, lo que confirma las identidades de ambas partes antes de que se establezca la comunicación.

Todos los balanceadores de cargas de aplicaciones admiten mTLS. Con la mTLS, el balanceador de cargas solicita que el cliente envíe un certificado para autenticarse durante el protocolo de enlace de TLS con el balanceador de cargas. Puedes configurar un almacén de confianza del Administrador de certificados que el balanceador de cargas usará para validar la cadena de confianza del certificado de cliente.

Para obtener más información sobre mTLS, consulta Autenticación TLS mutua.

Compatibilidad con datos anticipados de TLS 1.3

Los datos anticipados de TLS 1.3 se admiten en el proxy HTTPS de destino de los siguientes balanceadores de cargas de aplicaciones externos para HTTPS a través de TCP (HTTP/1.1, HTTP/2) y HTTP/3 a través de QUIC:

• Balanceadores de cargas de aplicaciones externos globales
• Balanceadores de cargas de aplicaciones clásicos

El protocolo TLS 1.3 se definió en el RFC 8446 y presenta el concepto de datos anticipados, también conocidos como datos de tiempo de ida y vuelta cero (0-RTT), que pueden mejorar el rendimiento de las aplicaciones en un 30 a un 50% para las conexiones reanudadas.

Con TLS 1.2, se requieren dos viajes de ida y vuelta antes de que los datos se puedan transmitir de forma segura. TLS 1.3 reduce esto a un viaje de ida y vuelta (1-RTT) para las conexiones nuevas, lo que permite que los clientes envíen datos de la aplicación inmediatamente después de la primera respuesta del servidor. Además, TLS 1.3 introduce el concepto de datos anticipados para las sesiones reanudadas, lo que permite a los clientes enviar datos de la aplicación con el ClientHello inicial y, de este modo, reducir el tiempo de ida y vuelta efectivo a cero (0-RTT). Los datos anticipados de TLS 1.3 permiten que el servidor de backend comience a procesar los datos del cliente antes de que se complete el proceso de protocolo de enlace con el cliente, lo que reduce la latencia. Sin embargo, se debe tener cuidado para mitigar los riesgos de reproducción.

Dado que los datos anticipados se envían antes de que se complete el protocolo de enlace, un atacante puede intentar capturar y reproducir solicitudes. Para mitigar esto, el servidor de backend debe controlar cuidadosamente el uso de datos anticipados y limitarlo a solicitudes idempotentes. Los métodos HTTP que se consideran idempotentes, pero que podrían activar cambios no idempotentes (como una solicitud GET que modifica una base de datos), no deben aceptar datos anticipados. En estos casos, el servidor de backend debe rechazar las solicitudes con el encabezado HTTP Early-Data: 1 devolviendo un código de estado HTTP 425 Too Early.

Las solicitudes con datos anticipados tienen el encabezado HTTP Early-Data establecido en un valor de 1, lo que indica al servidor de backend que la solicitud se transmitió en datos anticipados de TLS. También indica que el cliente comprende el código de estado HTTP 425 Too Early.

Modos de datos anticipados de TLS (0-RTT)

Puedes configurar los datos anticipados de TLS con uno de los siguientes modos en el recurso de proxy HTTPS de destino del balanceador de cargas.

• STRICT. Esto habilita los datos anticipados de TLS 1.3 para las solicitudes con métodos HTTP seguros (GET, HEAD, OPTIONS, TRACE) y las solicitudes HTTP que no tienen parámetros de consulta. Las solicitudes que envían datos anticipados que contienen métodos HTTP no idempotentes (como POST o PUT) o con parámetros de consulta se rechazan con un código de estado HTTP 425.

• PERMISSIVE, lo que habilita los datos anticipados de TLS 1.3 para las solicitudes con métodos HTTP seguros (GET, HEAD, OPTIONS, TRACE). Este modo no rechaza las solicitudes que incluyen parámetros de consulta. El propietario de la aplicación debe asegurarse de que los datos iniciales sean seguros para usar en cada ruta de solicitud, en especial para los extremos en los que la reproducción de solicitudes podría causar efectos secundarios no deseados, como actualizaciones de bases de datos o registros activados por solicitudes GET.

• DISABLED. No se anuncian los datos anticipados de TLS 1.3 y se rechazan todos los intentos (no válidos) de enviar datos anticipados. Si tus aplicaciones no están equipadas para controlar las solicitudes de datos anticipados de forma segura, debes inhabilitar los datos anticipados. TLS 1.3 Early Data está inhabilitado de forma predeterminada.

• UNRESTRICTED (no se recomienda para la mayoría de las cargas de trabajo). Esto habilita los datos anticipados de TLS 1.3 para solicitudes con cualquier método HTTP, incluidos los métodos no idempotentes, como POST. Este modo no aplica otras limitaciones de manera forzosa. Este modo puede ser valioso para los casos de uso de gRPC. Sin embargo, no recomendamos este método a menos que hayas evaluado tu posición de seguridad y mitigado el riesgo de ataques de reproducción con otros mecanismos.

Configura los datos anticipados de TLS

Para habilitar o inhabilitar explícitamente los datos anticipados de TLS, haz lo siguiente:

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Después de configurar los datos anticipados de TLS, puedes emitir solicitudes desde un cliente HTTP que admita datos anticipados de TLS. Puedes observar una latencia más baja en las solicitudes reanudadas.

Si un cliente que no cumple con los estándares de la RFC envía una solicitud con un método no idempotente o con parámetros de consulta, se rechaza la solicitud. Ves un código de estado HTTP 425 Early en los registros del balanceador de cargas y la siguiente respuesta HTTP:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Limitaciones

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

• Google Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.

• Cuando creas un balanceador de cargas de aplicaciones externo regional en el nivel Premium con laGoogle Cloud consola, solo las regiones que admiten el nivel Estándar están disponibles en la Google Cloud consola. Para acceder a otras regiones, usa gcloud CLI o la API.

• Los proxies de GFE que utilizan los balanceadores de cargas de aplicaciones globales y clásicos no admiten respuestas anticipadas 200 OK que se envían antes de que la carga útil de POST de la solicitud se haya enviado por proxy al backend por completo. Enviar una respuesta 200 OK anticipada hace que el GFE cierre la conexión al backend.

  Tu backend debe responder con respuestas 100 Continue después de que se reciban los encabezados de la solicitud y, luego, esperar hasta que se haya enviado por proxy por completo la carga útil de POST de la solicitud antes de responder con el código de respuesta 200 OK final.

• Cuando se usan balanceadores de cargas de aplicaciones externos regionales 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.

• Cloud CDN te permite forzar que un objeto o un conjunto de objetos sean ignorados por la caché mediante la solicitud de una invalidación de caché. De forma predeterminada, cuando usas un balanceador de cargas de aplicaciones externo global con referencia del servicio entre proyectos de VPC compartida, los administradores del proyecto de servicio no tendrán los permisos necesarios para lo siguiente: invalidaciones de caché de solicitudes. Esto se debe a que la invalidación de caché se configura en el proyecto de frontend (es decir, el proyecto que tiene la regla de reenvío, el proxy de destino y el mapa de URL del balanceador de cargas). Por lo tanto, las invalidaciones de caché solo pueden emitirse las principales que tienen los roles de IAM para configurar los recursos relacionados con el balanceador de cargas en los proyectos de frontend (por ejemplo, el rol de administrador de red de Compute). Los administradores de servicios, que controlan el aprovisionamiento de los servicios de backend en un proyecto separado, deben trabajar con el administrador del balanceador de cargas del proyecto de frontend para emitir la invalidación de caché para sus servicios entre proyectos.

¿Qué sigue?

• Para obtener información sobre cómo los balanceadores de cargas de aplicaciones externos controlan las conexiones, enrutan el tráfico y mantienen la afinidad de sesión, consulta Distribución de solicitudes para balanceadores de cargas de aplicaciones externos.

• Si deseas obtener información sobre cómo implementar un balanceador de cargas de aplicaciones externo global, consulta Configura un balanceador de cargas de aplicaciones externo con un backend de Compute Engine.

• Si deseas obtener información sobre cómo implementar un balanceador de cargas de aplicaciones externo regional, consulta Configura un balanceador de cargas de aplicaciones externo regional con un backend de Compute Engine.

• Si eres un usuario existente del balanceador de cargas de aplicaciones clásico, asegúrate de revisar la Descripción general de la migración cuando planifiques una implementación nueva con el balanceador de cargas de aplicaciones externo global.

• Si deseas obtener información sobre cómo automatizar la configuración del balanceador de cargas de aplicaciones externo con Terraform, consulta los ejemplos de módulos de Terraform para balanceadores de cargas de aplicaciones externos.

• 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 aplicaciones externo global, consulta Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones 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 aplicaciones externo regional, consulta Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos regionales.

• Para obtener más información sobre la entrega de sitios web, consulta Entrega sitios web.

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

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

• Para insertar lógica personalizada en la ruta de acceso a los datos del balanceo de cargas, configura complementos o textos destacados de extensiones de servicio.

• Solo para los balanceadores de cargas de aplicaciones externos regionales, puedes intentar usar Apigee Shadow API Discovery para encontrar APIs shadow (también conocidas como APIs sin documentar) en tu infraestructura deGoogle Cloud existente. Asegúrate de leer las limitaciones asociadas antes de habilitar Shadow API Discovery.