Conceptos del balanceo de cargas de HTTP(S)

En este documento, se presentan los conceptos que debes comprender para configurar el balanceo de cargas HTTP o HTTPS.

Información básica

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

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

En las siguientes secciones, se describe cómo cada componente funciona en conjunto para formar cada tipo de balanceador de cargas. Para obtener una descripción detallada de cada componente, consulta Componentes a continuación.

Balanceo de cargas HTTP

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

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

Balanceo de cargas HTTPS

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

Comunicaciones del cliente con el balanceador de cargas

  • Los clientes pueden comunicarse con el balanceador de cargas mediante el protocolo HTTP 1.1 o HTTP/2.
  • Cuando se usa HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas HTTPS.
  • No puedes inhabilitar HTTP/2 si cambias la configuración en el balanceador de cargas. Sin embargo, puedes configurar algunos clientes para usar HTTP 1.1 en lugar de HTTP/2. Por ejemplo, con curl, usa el parámetro --http1.1.
  • Los balanceadores de cargas HTTPS no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.

Puertos abiertos

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

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

Los balanceadores de cargas HTTP(S) tienen una cantidad de puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Si ejecutas un escaneo de puertos o de seguridad sobre la dirección IP externa de un balanceador de cargas HTTP(S) de GCP, parece que hay puertos adicionales abiertos.

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

Componentes

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

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 balanceo de cargas basado en DNS. Puedes especificar la dirección IP a usar o permitir que Google Cloud Load Balancing te asigne una.

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

Proxies de destino

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

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

  • Via: 1.1 google (solicitudes y respuestas)
  • X-Forwarded-Proto: [http | https] (solo solicitudes)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (solo solicitudes) Una lista de direcciones IP separadas por comas que agregan los intermediarios por los que pasó la solicitud. Si ejecutas proxies dentro de GCP que agregan datos al encabezado X-forwarded-For, entonces tu software debe tener en cuenta la existencia y la cantidad de esos proxies. El balanceador de cargas proporciona solo las entradas <immediate client IP> y <global forwarding rule external IP>. Todas las demás entradas de la lista se pasan sin verificación. La entrada <immediate client IP> es el cliente que se conectó de forma directa al balanceador de cargas. La entrada <global forwarding rule external IP> es la dirección IP externa de la regla de reenvío del balanceador de cargas. Si hay más entradas, entonces la primera en la lista es la dirección del cliente original. Otras entradas antes de la entrada <immediate client IP> representan otros servidores proxy que reenviaron la solicitud al balanceador de cargas.
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (solo solicitudes)
    Parámetros para Stackdriver Trace.

Puedes crear encabezados de solicitud personalizados si los encabezados predeterminados no satisfacen tus necesidades. Para obtener más información sobre esta característica, consulta la página sobre cómo crear encabezados de solicitud que define el usuario.

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

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

Certificados SSL

Si usas el balanceo de cargas HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino. Puedes tener instalados hasta quince (15) certificados SSL. Los proxies HTTPS de destino los usan para autenticar las comunicaciones entre el balanceador de cargas y el cliente. Estos pueden ser certificados SSL autoadministrados o que administra Google.

Si quieres obtener más información sobre la instalación de certificados SSL para un balanceador de cargas HTTPS, consulta la página sobre certificados SSL.

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

Políticas de SSL

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

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

Control geográfico sobre la ubicación en la que se finaliza TLS

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

Servicios de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Un balanceador de cargas HTTP(S) puede tener varios servicios de backend y debe tener al menos uno.

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

Cada backend está compuesto por un grupo de instancias y por metadatos de capacidad de entrega adicional. La capacidad de entrega del backend se puede basar en CPU o solicitudes por segundo (RPS).

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

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

Verificaciones de estado

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

Para obtener más información sobre las verificaciones de estado, consulta las páginas sobre los conceptos de verificación de estado y acerca de cómo crear verificaciones de estado.

Protocolo para los backends

Cuando configuras un servicio de backend para el balanceador de cargas HTTP(S), configura el protocolo que usa el servicio de backend a fin de comunicarse con los backends. 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 puede negociar una conexión al backend con el protocolo especificado.

Usa una verificación de estado de HTTP/2 si usas HTTP/2 para las VM de backend.

Usa gRPC con tus aplicaciones de Google Cloud Platform

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

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

Para usar gRPC con tus aplicaciones de Google Cloud Platform, debes enviar solicitudes proxy de extremo a extremo a través de HTTP/2. Para hacerlo con un balanceador de cargas HTTP(S), sigue estos pasos:

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

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

El balanceador de cargas aún puede negociar HTTPS con algunos clientes o aceptar solicitudes HTTP no seguras en un balanceador de cargas HTTP(S) 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 deseas configurar un balanceador de cargas HTTP(S) mediante HTTP/2 con Ingress de Google Kubernetes Engine, consulta HTTP/2 para balanceo de cargas con Ingress.

También puedes usar gRPC y HTTP/2 con Ingress. Si necesitas más información, consulta la página sobre cómo usar HTTP/2 para el balanceo de cargas con Ingress.

Para obtener información sobre cómo solucionar problemas de HTTP/2, consulta la solución de problemas de HTTP/2 en los backends. Para obtener información sobre las limitaciones de HTTP/2, consulta las limitaciones de HTTP/2.

Depósitos de backend

Los depósitos de backend dirigen tráfico de entrada a depósitos de Google Cloud Storage. Para ver un ejemplo que muestra cómo agregar un depósito a un balanceador de cargas existente, consulta la página sobre cómo agregar depósitos de Cloud Storage a los balanceadores de cargas.

Reglas de firewall

Debes crear una regla de firewall que permita que el tráfico de 130.211.0.0/22 y 35.191.0.0/16 llegue a tus instancias. Estos son rangos de direcciones IP que el balanceador de cargas usa para conectarse a instancias de backend. Esta regla permite el tráfico tanto del balanceador de cargas como del verificador de estado. La regla debe permitir el tráfico en el puerto cuya regla de reenvío global se haya configurado para usar y el verificador de estado debe configurarse a fin de usar el mismo puerto. Si tu verificador de estado usa un puerto diferente, debes crear otra regla de firewall para ese puerto.

Ten en cuenta que las reglas de firewall bloquean y permiten el tráfico al nivel de instancia, no en los extremos de la red. No pueden evitar que el tráfico llegue al balanceador de cargas.

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

Ruta de acceso de retorno

GCP usa rutas especiales no definidas en la red de VPC para las verificaciones de estado. Para obtener información completa sobre este tema, consulta las rutas de acceso de retorno del balanceador de cargas.

Algoritmo de distribución de cargas

El balanceo de cargas HTTP(S) proporciona dos métodos para determinar la carga de la instancia. En el recurso de servicio de backend, la propiedad balancingMode selecciona entre las solicitudes por segundo (RPS) y modos de uso de CPU. Ambos modos permiten especificar un valor máximo; el balanceador de cargas HTTP(S) intenta garantizar que la carga permanezca por debajo del límite, pero pueden producirse pequeños picos de actividad por encima del límite durante los eventos de conmutación por error o pico de carga.

Las solicitudes entrantes se envían a la región más cercana al usuario, si esa región tiene capacidad disponible. Si se configura más de una zona con backends en una región, el comportamiento predeterminado del algoritmo es distribuir el tráfico entre los grupos de instancias en cada zona de acuerdo con la capacidad de cada grupo. Dentro de la zona, las solicitudes se distribuyen de manera uniforme en las instancias mediante un algoritmo round-robin. Puedes anular la distribución round-robin si configuras la afinidad de sesión. Sin embargo, ten en cuenta que la afinidad de sesión funciona mejor si también configuras el modo de balanceo en solicitudes por segundo (RPS).

Consulta la página sobre cómo funciona el balanceo de cargas HTTP(S) para ver ejemplos específicos del algoritmo de distribución de cargas.

Afinidad de sesión

La afinidad de sesión envía todas las solicitudes del mismo cliente a la misma instancia de máquina virtual, siempre y cuando la instancia esté en buen estado y tenga capacidad.

El balanceo de cargas HTTP(S) de GCP ofrece dos tipos de afinidad de sesión:

Compatibilidad de proxy con WebSocket

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

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

Cuando el balanceo de cargas HTTP(S) reconoce una solicitud Upgrade de WebSocket de un cliente HTTP(S) y una respuesta Upgrade exitosa de la instancia de backend sigue a esta solicitud, el balanceador de cargas representa el tráfico bidireccional durante la conexión actual. Si el backend no muestra una respuesta Upgrade correcta, el balanceador de cargas cierra la conexión.

El tiempo de espera para una conexión de WebSocket depende del tiempo de espera de respuesta configurable del balanceador de cargas, que es de 30 segundos de forma predeterminada. Este tiempo de espera se aplica a las conexiones de WebSocket sin importar si están en uso o no. Para obtener más información sobre el tiempo de espera de respuesta y cómo configurarlo, consulta Tiempos de espera y reintentos.

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

El protocolo WebSocket es compatible con Ingress.

Compatibilidad con el protocolo QUIC para el balanceo de cargas HTTPS

El balanceo de cargas HTTPS admite el protocolo QUIC en las conexiones entre el balanceador de cargas y los clientes. QUIC es un protocolo de capa de transporte que proporciona control de congestión similar a TCP y seguridad equivalente a SSL/TLS para HTTP/2, con un rendimiento mejorado. QUIC permite un inicio más rápido de la conexión del cliente, elimina el bloqueo de línea en las transmisiones multiplexadas y admite la migración de conexión cuando cambia la dirección IP de un cliente.

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

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

  • Cuando sea posible, negocia QUIC para un balanceador de cargas O
  • Siempre inhabilita QUIC para un balanceador de cargas.

Si no especificas ninguna anulación QUIC, se permite que Google administre cuándo se usa QUIC. Google no habilita QUIC sin anulación especificada. Para obtener información sobre cómo inhabilitar y habilitar la compatibilidad con QUIC, consulta Proxies de destino. También puedes habilitar QUIC cuando creas un balanceador de cargas HTTPS con Google Cloud Platform Console o inhabilitarlo para editar la configuración del balanceador de cargas.

Cómo se negocia QUIC

Cuando habilitas QUIC, el balanceador de cargas puede anunciar su capacidad QUIC a los clientes, lo que permite que los clientes que admiten QUIC intenten establecer conexiones QUIC con el balanceador de cargas HTTPS. Los clientes implementados de forma correcta siempre recurren a HTTPS o HTTP/2 cuando no pueden establecer una conexión QUIC. Debido a esta solución alternativa, habilitar o inhabilitar QUIC en el balanceador de cargas no interrumpe la capacidad de este para conectarse con los clientes.

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

  • Cuando un cliente admite versiones de QUIC que no son compatibles con las versiones de QUIC que admite el balanceador de cargas HTTPS
  • Cuando el balanceador de cargas detecta que el tráfico UDP está bloqueado o la velocidad limitada de una manera que evitaría que QUIC funcione
  • Si QUIC está inhabilitado de manera temporal para los balanceadores de cargas HTTPS en respuesta a errores, vulnerabilidades o algunas otras inquietudes

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

Asegúrate de que los comportamientos descritos antes sean aceptables para tus cargas de trabajo antes de habilitar QUIC.

Interfaces

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

  • La herramienta de línea de comandos de gcloud: una herramienta de línea de comandos incluida en el SDK de Cloud que se usa a menudo en la documentación del balanceo de cargas HTTP(S) para realizar diversas tareas. Para obtener una descripción general completa de la herramienta, consulta la guía de la herramienta de gcloud. Encontrarás comandos relacionados con el balanceo de cargas en el grupo de comandos de gcloud compute.

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

    gcloud compute http-health-checks create --help
    
  • Google Cloud Platform Console: las tareas de balanceo de cargas se pueden realizar a través de Google Cloud Platform Console.

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

Compatibilidad con TLS

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

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

Tiempos de espera y reintentos

El balanceo de cargas HTTP(S) tiene dos tipos distintos de tiempos de espera:

  • Un tiempo de espera de respuesta HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera que el backend muestre una respuesta HTTP completa. Este no es un tiempo de espera HTTP inactivo (keepalive). El valor predeterminado es 30 segundos. Considera aumentar este tiempo de espera en estas circunstancias:

    • Si esperas que un backend tarde más en mostrar respuestas HTTP o
    • Si la conexión se actualiza a un WebSocket.

    Para el tráfico de WebSocket enviado a través de un balanceador de cargas HTTP(S) de GCP, el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión con WebSocket puede permanecer activa o inactiva. Para obtener más información, consulta la configuración del servicio de backend.

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

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

Software de servidor web Parámetro Configuración predeterminada Configuración recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Los reintentos de balanceo de cargas HTTP(S) fallaron las solicitudes GET en ciertas circunstancias, como cuando se agota el tiempo de espera de respuesta. No se reintentan solicitudes POST con errores. Solo se puede reintentar dos veces. Las solicitudes recuperadas solo generan una entrada de registro para la respuesta final. Para obtener más información, consulta la sección sobre registro.

Solicitud ilegal y manejo de respuestas

El balanceador de cargas HTTP(S) 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.

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

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

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

  • La combinación de la URL de solicitud y los encabezados supera los 15 KB.
  • El método de solicitud no permite un cuerpo, pero la solicitud tiene uno.
  • La solicitud contiene un encabezado Upgrade y el encabezado Upgrade no se usa para habilitar las conexiones de 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 los 128 KB.
  • La versión HTTP es desconocida.

Próximos pasos

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...