Cómo se gestionan las solicitudes

ID de región

El REGION_ID es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.

Más información sobre los IDs de región

En este documento se describe cómo recibe solicitudes y envía respuestas tu aplicación de App Engine. Para obtener más información, consulta la referencia de encabezados de solicitud.

Si tu aplicación usa servicios, puedes dirigir las solicitudes a un servicio específico o a una versión específica de ese servicio. Para obtener más información sobre la disponibilidad de las direcciones de servicio, consulta Cómo se enrutan las solicitudes.

Gestionar solicitudes

Tu aplicación se encarga de iniciar un servidor web y de gestionar las solicitudes. Puedes usar cualquier framework web que esté disponible para tu lenguaje de desarrollo.

App Engine ejecuta varias instancias de tu aplicación y cada instancia tiene su propio servidor web para gestionar las solicitudes. Cualquier solicitud se puede enrutar a cualquier instancia, por lo que no es necesario que las solicitudes consecutivas del mismo usuario se envíen a la misma instancia. Una instancia puede gestionar varias solicitudes simultáneamente. El número de instancias se puede ajustar automáticamente a medida que cambia el tráfico.

Cuotas y límites

App Engine asigna automáticamente recursos a tu aplicación a medida que aumenta el tráfico. Sin embargo, está sujeta a las siguientes restricciones:

  • App Engine reserva capacidad de escalado automático para las aplicaciones con baja latencia, en las que la aplicación responde a las solicitudes en menos de un segundo.

  • Las aplicaciones que dependen mucho de la CPU también pueden incurrir en una latencia adicional para compartir recursos de forma eficiente con otras aplicaciones en los mismos servidores. Las solicitudes de archivos estáticos están exentas de estos límites de latencia.

Cada solicitud entrante a la aplicación se incluye en el límite de solicitudes. Los datos enviados en respuesta a una solicitud se tienen en cuenta para el límite de ancho de banda saliente (facturable).

Tanto las solicitudes HTTP como las HTTPS (seguras) se contabilizan en los límites de Solicitudes, Ancho de banda de entrada (facturable) y Ancho de banda de salida (facturable). La página Detalles de la cuota de la Google Cloud consola también muestra los valores de Solicitudes seguras, Ancho de banda de entrada seguro y Ancho de banda de salida seguro por separado a modo informativo. Solo las solicitudes HTTPS se contabilizan en estos valores. Para obtener más información, consulta la página Cuotas.

Los siguientes límites se aplican específicamente al uso de controladores de solicitudes:

Límites de solicitudes

  • Se permite un máximo de unos 15 KB en los encabezados de solicitud.
  • El tamaño total de la solicitud no puede superar los 32 MB.
  • Todas las solicitudes HTTP/2 se traducirán a solicitudes HTTP/1.1 cuando se reenvíen al servidor de aplicaciones.
  • Las conexiones SSL finalizan en el balanceador de carga. El tráfico del balanceador de carga se envía a la instancia a través de un canal cifrado y, a continuación, se reenvía al servidor de aplicaciones a través de HTTP. El encabezado X-Forwarded-Proto te permite saber si la solicitud de origen era HTTP o HTTPS.

Límites de respuesta

  • Las respuestas se almacenan en búfer en bloques de 64 KB.
  • El tamaño de la respuesta es ilimitado.
  • El límite de tiempo de respuesta es de una hora.
  • El límite de encabezados de respuesta es de 64 KB. Los encabezados de respuesta que superen este límite devolverán errores HTTP 502 y los registros mostrarán upstream sent too big header while reading response header from upstream.

Solicitudes HTTP no admitidas

Las siguientes funciones no son compatibles con el entorno flexible de App Engine:

  • Tráfico HTTP/2 al servicio de backend.
  • Solicitudes HTTP que acceden directamente a las instancias.

Encabezados de solicitud

Una solicitud HTTP entrante incluye las cabeceras HTTP enviadas por el cliente. Por motivos de seguridad, los proxies intermedios anonimizan o modifican algunos encabezados antes de que lleguen a la aplicación.

Para obtener más información, consulta la referencia de encabezados de solicitud.

Inhabilitar el almacenamiento en búfer

De forma predeterminada, todas las respuestas de App Engine se almacenan en búfer en bloques de 64 KB. En algunos casos, puede ser conveniente inhabilitar el almacenamiento en búfer y transmitir bytes directamente al cliente. Esta opción suele ser la preferida cuando se usan solicitudes GET pendientes o eventos enviados por el servidor (SSEs). Para inhabilitar el almacenamiento en búfer, puedes asignar el valor no al encabezado de respuesta X-Accel-Buffering.

Forzar las conexiones HTTPS

Por motivos de seguridad, todas las aplicaciones deben animar a los clientes a conectarse a través de https. Para indicar al navegador que prefiera https en lugar de http en una página o en todo un dominio, define el encabezado Strict-Transport-Security en tus respuestas. Por ejemplo:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Gestionar el trabajo asíncrono en segundo plano

El trabajo en segundo plano es cualquier tarea que realiza tu aplicación para una solicitud después de haber enviado la respuesta HTTP. Evita realizar tareas en segundo plano en tu aplicación y revisa el código para asegurarte de que todas las operaciones asíncronas finalicen antes de enviar la respuesta.

Para los trabajos de larga duración, recomendamos usar Cloud Tasks. Con Cloud Tasks, las solicitudes HTTP son duraderas y solo devuelven una respuesta cuando finaliza el trabajo asíncrono.