Cómo se manejan las solicitudes

ID de región

REGION_ID es un código abreviado que Google asigna en función de la región que seleccionas cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. Incluir REGION_ID.r en las URL de App Engine es opcional en el caso de las apps existentes, y pronto será obligatorio para todas las apps nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine de forma paulatina para usar los ID de región. Si aún no actualizamos tu proyecto de Google Cloud, no verás un ID de región para la app. Dado que el ID es opcional en las apps existentes, no es necesario que actualices las URL ni realices otros cambios una vez que el ID de región esté disponible en las apps existentes.

Obtén más información acerca de los ID de región.

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

Si tu aplicación usa servicios, puedes dirigir solicitudes a un servicio específico o a una versión específica de ese servicio. Para obtener más información sobre cómo direccionar el servicio, consulta Cómo enrutar solicitudes.

Cómo controlar las solicitudes

La aplicación se encarga de iniciar un servidor web y controlar las solicitudes. Puedes usar cualquier marco de trabajo web que esté disponible para tu lenguaje de desarrollo.

La configuración del servidor de tu aplicación determina la forma en que se controlan las solicitudes simultáneas. El entorno de ejecución de Eclipse Jetty 9 ya está configurado para la simultaneidad. Sin embargo, si usas el entorno de ejecución de Java 8, la configuración de la simultaneidad dependerá de tu aplicación o framework.

Cuando App Engine recibe una solicitud web para la aplicación, invoca el servlet correspondiente a la URL, como se describe en el descriptor de implementación de la aplicación (el archivo web.xml en el directorio WEB-INF/). Usa la API del Servlet de Java, versión 3.1, para proporcionar los datos de la solicitud al servlet y aceptar los datos de la respuesta.

La siguiente clase de servlet de ejemplo muestra un mensaje simple en el navegador del usuario.

import java.io.IOException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class MyServlet extends HttpServlet {
    @Override
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}

Cuotas y límites

App Engine asigna recursos a tu aplicación de manera automática a medida que el tráfico aumenta. Sin embargo, esto se limita con las siguientes restricciones:

  • App Engine reserva la capacidad de ajuste de escala automático para aplicaciones con latencia baja a fin de que la aplicación responda a las solicitudes en menos de un segundo. Las aplicaciones con latencia muy alta, como las de más de un segundo por solicitud para varias solicitudes, y con capacidad de procesamiento alta requieren asistencia nivel Plata, Oro o Platino. Los clientes con este nivel de asistencia pueden comunicarse con su representante de asistencia para solicitar el aumento de sus límites de capacidad de procesamiento.

  • Las aplicaciones estrechamente vinculadas a la CPU también pueden incurrir en alguna latencia adicional para compartir recursos de manera eficaz con otras aplicaciones en el mismo servidor. Las solicitudes para archivos estáticos están exentas de estos límites de capacidad de latencia.

Cada solicitud que entra a la aplicación se tiene en cuenta para los límites de Solicitudes. Los datos enviados en respuesta a una solicitud se tienen en cuenta para el límite de Ancho de banda saliente (facturable).

Las solicitudes HTTP y las HTTPS (seguras) se tienen en cuenta para los límites de Solicitudes, Ancho de banda entrante (facturable) y Ancho de banda saliente (facturable). En la página Detalles de cuota de Cloud Console también se informan las Solicitudes seguras, el Ancho de banda entrante seguro y el Ancho de banda saliente seguro como valores separados. Solo se tienen en cuenta las solicitudes HTTPS para estos valores. Para obtener más información, consulta la página de Cuotas.

Los límites que se indican a continuación se aplican al uso de los controladores de solicitudes en particular.

Límites de las solicitudes

  • Se permite un máximo de ~15 KB en encabezados de solicitud.
  • El tamaño total de la solicitud se limita a ~32 MB.
  • Todas las solicitudes HTTP/2 se convertirán en solicitudes HTTP/1.1 cuando se reenvíen al servidor de la aplicación.
  • Las conexiones SSL finalizan en el balanceador de cargas. El tráfico del balanceador de cargas se envía a la instancia por un canal encriptado y, luego, se reenvía al servidor de la aplicación mediante HTTP. El encabezado X-Forwarded-Proto te permite saber si la solicitud de origen fue HTTP o HTTPS.

Límites de las respuestas

  • Las respuestas se almacenan en búfer en bloques de 64,000.
  • El tamaño de la respuesta es ilimitado.
  • El límite de tiempo de la respuesta es de una hora.

Solicitudes HTTP no compatibles

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

  • Tráfico HTTP/2 para el servicio de backend
  • Solicitudes HTTP que acceden a instancias de manera directa

Encabezados de solicitud

Una solicitud HTTP nueva incluye los encabezados HTTP que envía el cliente. Por motivos de seguridad, los proxies intermedios limpian o modifican algunos encabezados antes de que lleguen a la aplicación.

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

Fuerza conexiones HTTPS

Por motivos de seguridad, todas las aplicaciones deben incentivar al cliente a conectarse mediante https. A fin de indicarle al navegador que elija https en lugar de http para una página determinada o un dominio completo, configura el encabezado Strict-Transport-Security en tus respuestas. Por ejemplo:

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

La mayoría de los frameworks y los servidores web de las apps proporcionan asistencia para configurar este encabezado en las respuestas que se generan a partir del código. Para obtener información sobre el encabezado Strict-Transport-Security en Spring Boot, consulta HTTP con Seguridad de Transporte Estricta (HSTS).

Administra el trabajo asíncrono en segundo plano

El trabajo en segundo plano es cualquier trabajo que tu app realice para una solicitud después de que entregaste la respuesta HTTP. Evita realizar tareas en segundo plano en la app y revisa el código para asegurarte de que todas las operaciones asíncronas finalicen antes de entregar la respuesta.

Para trabajos de larga duración, recomendamos usar Cloud Tasks. Con Cloud Tasks, las solicitudes HTTP son de larga duración y muestran una respuesta solo después de que finaliza cualquier trabajo asíncrono.