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

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. También puedes cambiar el número de solicitudes simultáneas que puede gestionar una instancia definiendo el elemento max_concurrent_requests en el archivo app.yaml.

El servidor determina qué secuencia de comandos del controlador de PHP debe ejecutar comparando la URL de la solicitud con los patrones de URL del archivo de configuración app.yaml de la aplicación. A continuación, ejecuta la secuencia de comandos rellenada con los datos de la solicitud. El servidor coloca los datos de la solicitud en variables de entorno y en el flujo de entrada estándar. La secuencia de comandos realiza las acciones adecuadas para la solicitud, prepara una respuesta y la coloca en el flujo de salida estándar.

El siguiente ejemplo es una secuencia de comandos PHP que responde a cualquier solicitud HTTP con el mensaje "Hello World!".

<?php

echo 'Hello, World!';

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ímite Cantidad
Tamaño de la solicitud 32 megabytes
Tamaño de la respuesta 32 megabytes
Tiempo de espera de solicitud Depende del tipo de escalado que use tu aplicación
Número total máximo de archivos (archivos de aplicaciones y archivos estáticos) 10.000 en total
1000 por directorio
Tamaño máximo de un archivo de aplicación 32 megabytes
Tamaño máximo de un archivo estático 32 megabytes
Tamaño total máximo de todos los archivos estáticos y de la aplicación El primer gigabyte es gratuito
0,026 USD por gigabyte al mes después del primer gigabyte
Tiempo de espera de las solicitudes pendientes 10 segundos
Tamaño máximo de un único campo de encabezado de solicitud 8 kilobytes para los runtimes de segunda generación en el entorno estándar. Las solicitudes a estos tiempos de ejecución con campos de encabezado que superen los 8 kilobytes devolverán errores HTTP 400.

Límites de solicitudes

Todas las solicitudes HTTP/2 se traducirán a solicitudes HTTP/1.1 cuando se reenvíen al servidor de aplicaciones.

Límites de respuesta

  • Las respuestas dinámicas tienen un límite de 32 MB. Si un controlador de secuencias de comandos genera una respuesta que supera este límite, el servidor devuelve una respuesta vacía con el código de estado 500 Internal Server Error. Esta limitación no se aplica a las respuestas que sirven datos de Cloud Storage.

  • El límite de encabezados de respuesta es de 8 KB para los runtimes de segunda generación. 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.

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.

Gestionar los tiempos de espera de las solicitudes

App Engine está optimizado para aplicaciones con solicitudes de corta duración, normalmente las que tardan unos cientos de milisegundos. Una aplicación eficiente responde rápidamente a la mayoría de las solicitudes. Una aplicación que no lo haga no se escalará bien con la infraestructura de App Engine. Para asegurar este nivel de rendimiento, el sistema impone un tiempo de espera máximo de las solicitudes al que deben responder todas las aplicaciones.

Si una secuencia de comandos PHP supera este plazo, se define el bit TIMEOUT en el campo de bits connection status. Tu secuencia de comandos tendrá un breve plazo de un segundo para limpiar las tareas de larga duración y devolver una respuesta al usuario.

Si tu secuencia de comandos no ha devuelto una respuesta antes de la segunda fecha límite, el controlador se detiene y se devuelve una respuesta de error predeterminada.

Respuestas

App Engine llama a la secuencia de comandos con la matriz $_REQUEST rellenada, almacena en búfer cualquier salida de la secuencia de comandos y, cuando la secuencia de comandos completa la ejecución, envía la salida almacenada en búfer al usuario final.

Hay límites de tamaño que se aplican a la respuesta que generas, y la respuesta se puede modificar antes de devolverse al cliente.

Para obtener más información, consulta la referencia de respuestas de solicitudes.

Respuestas de streaming

App Engine no admite respuestas de streaming en las que los datos se envían en fragmentos incrementales al cliente mientras se procesa una solicitud. Todos los datos de tu código se recogen tal como se ha descrito anteriormente y se envían como una única respuesta HTTP.

Compresión de respuestas

App Engine hace todo lo posible para servir contenido comprimido (gzipeado) a los clientes que lo admiten. Para determinar si se debe comprimir el contenido, App Engine hace lo siguiente cuando recibe una solicitud:

  1. Confirma si el cliente puede recibir respuestas comprimidas de forma fiable consultando los encabezados Accept-Encoding y User-Agent de la solicitud. De esta forma, se evitan algunos errores conocidos con el contenido comprimido con gzip en navegadores populares.

  2. Confirma si es adecuado comprimir el contenido consultando el encabezado Content-Type que has configurado para el controlador de respuestas. Por lo general, la compresión es adecuada para los tipos de contenido basados en texto, pero no para los tipos de contenido binario.

Ten en cuenta lo siguiente:

  • Un cliente puede forzar la compresión de los tipos de contenido basados en texto si asigna el valor gzip a los encabezados de solicitud Accept-Encoding y User-Agent.

  • Si una solicitud no especifica gzip en el encabezado Accept-Encoding, App Engine no comprimirá los datos de la respuesta.

  • El frontend de Google almacena en caché las respuestas de los controladores de archivos estáticos y directorios de App Engine. En función de varios factores, como el tipo de datos de respuesta que se almacena en caché primero, los encabezados Vary que hayas especificado en la respuesta y los encabezados que se incluyan en la solicitud, un cliente podría solicitar datos comprimidos, pero recibir datos sin comprimir, y viceversa. Para obtener más información, consulta Almacenamiento en caché de respuestas.

Almacenamiento en caché de respuestas

El frontend de Google, y posiblemente el navegador del usuario y otros servidores proxy de almacenamiento en caché intermedios, almacenarán en caché las respuestas de tu aplicación según las instrucciones de los encabezados de almacenamiento en caché estándar que especifiques en la respuesta. Puede especificar estos encabezados de respuesta a través de su framework, directamente en su código o mediante los gestores de archivos y directorios estáticos de App Engine.

En el frontend de Google, la clave de caché es la URL completa de la solicitud.

Almacenar contenido estático en caché

Para asegurarte de que los clientes siempre reciban contenido estático actualizado en cuanto se publique, te recomendamos que sirvas contenido estático desde directorios con versiones, como css/v1/styles.css. El frontend de Google no validará la caché (comprobará si hay contenido actualizado) hasta que caduque. Aunque la caché caduque, no se actualizará hasta que cambie el contenido de la URL de la solicitud.

Los siguientes encabezados de respuesta que puedes definir en app.yaml influyen en cómo y cuándo almacena en caché el contenido el frontend de Google:

  • Cache-Control debe tener el valor public para que Google Frontend pueda almacenar contenido en caché. También puede almacenarse en caché en Google Frontend a menos que especifiques una directiva Cache-Control private o no-store. Si no defines este encabezado en app.yaml , App Engine lo añade automáticamente a todas las respuestas gestionadas por un controlador de archivos o directorios estáticos. Para obtener más información, consulta el artículo sobre encabezados añadidos o sustituidos.

  • Vary: para que la caché devuelva respuestas diferentes para una URL en función de los encabezados que se envíen en la solicitud, defina uno o varios de los siguientes valores en el encabezado de respuesta Vary: Accept, Accept-Encoding, Origin o X-Origin.

    Debido a la alta cardinalidad potencial, los datos no se almacenarán en caché para otros valores de Vary.

    Por ejemplo:

    1. Especifica el siguiente encabezado de respuesta:

      Vary: Accept-Encoding

    2. Tu aplicación recibe una solicitud que contiene el encabezado Accept-Encoding: gzip. App Engine devuelve una respuesta comprimida y el frontend de Google almacena en caché la versión comprimida con gzip de los datos de la respuesta. Todas las solicitudes posteriores de esta URL que contengan el encabezado Accept-Encoding: gzip recibirán los datos comprimidos con gzip de la caché hasta que esta se invalide (porque el contenido cambie después de que caduque la caché).

    3. Tu aplicación recibe una solicitud que no contiene el encabezado Accept-Encoding. App Engine devuelve una respuesta sin comprimir y Google Frontend almacena en caché la versión sin comprimir de los datos de la respuesta. Todas las solicitudes posteriores de esta URL que no contengan el encabezado Accept-Encoding recibirán los datos comprimidos de la caché hasta que esta se invalide.

    Si no especifica un encabezado de respuesta Vary, el frontend de Google crea una sola entrada de caché para la URL y la usará en todas las solicitudes, independientemente de los encabezados de la solicitud. Por ejemplo:

    1. No especifica el encabezado de respuesta Vary: Accept-Encoding.
    2. Una solicitud contiene la cabecera Accept-Encoding: gzip y se almacenará en caché la versión comprimida con gzip de los datos de la respuesta.
    3. Una segunda solicitud no contiene el encabezado Accept-Encoding: gzip. Sin embargo, como la caché contiene una versión comprimida con gzip de los datos de respuesta, la respuesta se comprimirá con gzip aunque el cliente haya solicitado datos sin comprimir.

Los encabezados de la solicitud también influyen en el almacenamiento en caché:

  • Si la solicitud contiene un encabezado Authorization, el contenido no se almacenará en la caché del frontend de Google.

Vencimiento de la caché

De forma predeterminada, los encabezados de almacenamiento en caché que los controladores de archivos estáticos y de directorios de App Engine añaden a las respuestas indican a los clientes y a los proxies web, como Google Frontend, que el caché caduque al cabo de 10 minutos.

Una vez que se ha transmitido un archivo con un tiempo de vencimiento determinado, por lo general, no hay forma de eliminarlo de las cachés de proxy web, aunque el usuario borre su propia caché del navegador. Al volver a implementar una nueva versión de la aplicación, no se restablecerá ninguna caché. Por lo tanto, si tienes previsto modificar un archivo estático, debe tener un tiempo de vencimiento corto (menos de una hora). En la mayoría de los casos, el tiempo de vencimiento predeterminado de 10 minutos es adecuado.

Puedes cambiar el vencimiento predeterminado de todos los controladores de archivos estáticos y directorios especificando el elemento default_expiration en el archivo app.yaml. Para definir tiempos de caducidad específicos para controladores individuales, especifica el elemento expiration en el elemento del controlador de tu archivo app.yaml.

El valor que especifiques en el tiempo de los elementos de vencimiento se usará para definir los encabezados de respuesta HTTP Cache-Control y Expires.

Almacenamiento en caché de aplicaciones

El entorno de tiempo de ejecución de PHP incluye OPcache, que puede almacenar en caché el código intermedio de PHP y mejorar significativamente el tiempo de respuesta de tu aplicación. Para inhabilitar el almacenamiento en caché de OPcache, define opcache.enabled = "0" en el archivo php.ini de la aplicación.

Almacenamiento de registros

El servidor web de App Engine registra todo lo que escribe la secuencia de comandos del controlador en el flujo de salida estándar para responder a la solicitud web. También captura todo lo que el script del controlador escribe en el flujo de errores estándar y lo almacena como datos de registro. Los datos de registro de tu aplicación se pueden consultar en la consolaGoogle Cloud mediante Cloud Logging.

El entorno de ejecución de PHP de App Engine incluye compatibilidad con el registro de mensajes arbitrarios de tu aplicación mediante la función syslog() integrada de PHP, que invoca la API Logs.

El entorno

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
Para definir este encabezado en cualquier contenido estático que sirva tu aplicación, añade el encabezado a los gestores de archivos y directorios estáticos de tu aplicación.

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.