Cómo se gestionan las solicitudes

Go Java Node.js PHP Python Ruby

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

Aceptar

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 configurando el elemento max_concurrent_requests en el archivo app.yaml o en el archivo appengine-web.xml si usas los servicios empaquetados antiguos de App Engine.

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 proporcionan datos de Cloud Storage ni a la API Blobstore antigua si está disponible en tu tiempo de ejecución.

• 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 tu aplicación supera este plazo, App Engine interrumpe el controlador de solicitudes.

Respuestas

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

En el caso de las respuestas que devuelve tu código, App Engine comprime los datos de la respuesta si se cumplen las dos condiciones siguientes:

• La solicitud contiene el encabezado Accept-Encoding, que incluye gzip como valor.
• La respuesta contiene datos basados en texto, como HTML, CSS o JavaScript.

En el caso de las respuestas devueltas por un gestor de archivos o directorios estáticos de App Engine, los datos de respuesta se comprimen si se cumplen todas las condiciones siguientes:

• La solicitud incluye Accept-Encoding con gzip como uno de sus valores.
• El cliente puede recibir los datos de la respuesta en formato comprimido. El frontend de Google mantiene una lista de clientes que se sabe que tienen problemas con las respuestas comprimidas. Estos clientes no recibirán datos comprimidos de controladores estáticos en tu aplicación, aunque los encabezados de solicitud contengan Accept-Encoding: gzip.
• La respuesta contiene datos basados en texto, como HTML, CSS o JavaScript.

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 horas de vencimiento específicas 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.

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.

Advertencia: Los clientes que hayan recibido el encabezado en el pasado no podrán conectarse si https deja de funcionar o se inhabilita por cualquier motivo. Para obtener más información, consulta esta hoja de trucos sobre la seguridad de transporte estricta mediante HTTP.

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.

Advertencia: Si realizas tareas asíncronas en segundo plano, la facturación puede ser más alta. App Engine puede escalar instancias adicionales debido a una carga de CPU alta, aunque no haya solicitudes activas. Los usuarios también pueden experimentar un aumento de la latencia debido a las solicitudes que esperan en la cola pendiente para obtener instancias disponibles.

Priorización de colas pendientes de App Engine

Durante los periodos de mucho tráfico, App Engine puede colocar solicitudes en una cola pendiente mientras espera una instancia disponible con la siguiente priorización:

• App Engine da prioridad a otras solicitudes en cola sobre las solicitudes en cola pendientes de Task queue. Las solicitudes de Cloud Tasks de App Engine también comparten este comportamiento de prioridad de cola pendiente por motivos de compatibilidad.

• En la cola pendiente, App Engine trata las solicitudes de tareas de Cloud de destino HTTP como tráfico HTTP normal. Las solicitudes de destino HTTP no tienen una prioridad más baja.

• Cuando un servicio recibe un gran volumen de tráfico HTTP estándar y, al mismo tiempo, sirve tráfico de colas de tareas o de Cloud Tasks con un volumen mucho menor, se produce un impacto desproporcionado en la latencia del tráfico de colas de tareas o de Cloud Tasks. Te recomendamos que dividas los tipos de tráfico en versiones independientes o que uses tareas de destino HTTP para evitar las colas de prioridad. También deberías plantearte atender las solicitudes sensibles a la latencia de Cloud Tasks con una versión principal o un servicio específicos.