ID de la région
Le REGION_ID est un code abrégé que Google attribue en fonction de la région que vous sélectionnez lors de la création de votre application. Le code ne correspond pas à un pays ou une province, même si certains ID de région peuvent ressembler aux codes de pays et de province couramment utilisés. Pour les applications créées après février 2020, REGION_ID.r est inclus dans les URL App Engine. Pour les applications existantes créées avant cette date, l'ID de région est facultatif dans l'URL.
En savoir plus sur les ID de région
Ce document décrit comment votre application App Engine reçoit des requêtes et envoie des réponses. Pour en savoir plus, consultez la documentation de référence relative aux en-têtes de requête.
Si votre application utilise des services, vous pouvez adresser des requêtes à un service spécifique ou à une version spécifique de ce service. Pour en savoir plus sur l'adressage des services, consultez la page Mode de routage des requêtes.
Traiter des requêtes
Votre application est responsable du démarrage d'un serveur Web et du traitement des requêtes. Vous pouvez utiliser n'importe quel framework Web disponible pour votre langage de développement.
App Engine exécute plusieurs instances de votre application, chacune d'elles disposant de son propre serveur Web pour le traitement des requêtes. Étant donné que chaque requête peut être acheminée vers n'importe quelle instance, les requêtes consécutives provenant d'un même utilisateur ne sont pas nécessairement envoyées à la même instance. Une instance peut traiter plusieurs requêtes simultanément. Le nombre d'instances peut être ajusté automatiquement en fonction de l'évolution du trafic.
Quotas et limites
App Engine alloue automatiquement des ressources à votre application lorsque le trafic augmente. Toutefois, les restrictions suivantes s'appliquent :
App Engine réserve une capacité de scaling automatique pour les applications à faible latence, qui répondent aux requêtes en moins d'une seconde.
En outre, le temps de latence des applications fortement dépendantes des processeurs peut augmenter de manière à permettre le partage efficace des ressources avec les autres applications hébergées sur les mêmes serveurs. Aucune limite de latence n'est appliquée aux requêtes de fichiers statiques.
Chaque requête entrante vers l'application est prise en compte dans la limite des requêtes. Les données envoyées en réponse à une requête sont comptabilisées dans la limite de bande passante sortante (facturable).
Les requêtes HTTP et HTTPS (sécurisées) sont comptabilisées dans les limites de requêtes, de bande passante entrante (facturable) et de bande passante sortante (facturable). Dans la console Google Cloud, la page Détails des quotas affiche également les valeurs de Requêtes sécurisées, la Bande passante entrante sécurisée et la Bande passante sortante sécurisée de manière distincte à titre informatif. Seules les requêtes HTTPS sont comptabilisées dans ces valeurs. Pour en savoir plus, consultez la page Quotas.
Les limites suivantes s'appliquent spécifiquement à l'utilisation de gestionnaires de requêtes :
Limites de requêtes
- Un maximum de 15 Ko est autorisé dans les en-têtes de requête.
- La taille totale de la requête est limitée à ~ 32 Mo.
- Toutes les requêtes HTTP/2 sont converties en requêtes HTTP/1.1 lors de leur transmission au serveur d'applications.
- Les connexions SSL se terminent au niveau de l'équilibreur de charge. Le trafic provenant de l'équilibreur de charge est envoyé à l'instance via un canal chiffré, puis transmis au serveur d'applications via le protocole HTTP. L'en-tête X-Forwarded-Proto vous permet de savoir si la requête d'origine était au format HTTP ou HTTPS.
Limites de réponse
- Les réponses sont mises en mémoire tampon par des blocs de 64 000 Ko.
- La taille de la réponse est illimitée.
- Le délai de réponse est d'une heure.
Requêtes HTTP non prises en charge
Les fonctionnalités suivantes ne sont pas compatibles avec l'environnement flexible App Engine :
- Trafic HTTP/2 vers le service de backend
- Requêtes HTTP qui accèdent directement aux instances
En-têtes de requête
Une requête HTTP entrante inclut des en-têtes HTTP envoyés par le client. Pour des raisons de sécurité, certains en-têtes sont nettoyés ou modifiés par des serveurs proxy intermédiaires avant d'atteindre l'application.
Pour en savoir plus, consultez la documentation de référence sur les en-têtes de requête.
Forcer les connexions HTTPS
Pour des raisons de sécurité, toutes les applications doivent encourager les clients à se connecter via le protocole https. Pour indiquer au navigateur de privilégier https à http pour une page ou un domaine donné, définissez l'en-tête Strict-Transport-Security dans vos réponses.
Exemple :
Strict-Transport-Security: max-age=31536000; includeSubDomains
Gérer les tâches asynchrones en arrière-plan
Une tâche en arrière-plan désigne toute tâche effectuée par votre application pour une requête après la transmission d'une réponse HTTP. Évitez d'effectuer des tâches en arrière-plan dans votre application et examinez votre code pour vous assurer que toutes les opérations asynchrones sont terminées avant de transmettre votre réponse.
Pour les tâches de longue durée, nous vous recommandons d'utiliser Cloud Tasks. Avec Cloud Tasks, les requêtes HTTP ont une longue durée de vie et ne renvoient une réponse qu'une fois les tâches asynchrones terminées.