Mode de traitement des requêtes

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. L'ajout de REGION_ID.r dans les URL App Engine est facultatif pour les applications existantes. Il sera bientôt obligatoire pour toutes les applications nouvelles.

Pour assurer une transition en douceur, nous mettons lentement à jour App Engine afin d'utiliser les ID de région. Si nous n'avons pas encore mis à jour votre projet Google Cloud, vous ne verrez pas d'ID de région pour votre application. Étant donné que l'ID est facultatif pour les applications existantes, vous n'avez pas besoin de mettre à jour les URL ni d'effectuer d'autres modifications une fois l'ID de région disponible pour vos applications existantes.

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. L'exemple suivant contient le code JavaScript permettant de démarrer un serveur et de répondre à toutes les requêtes GET de clients Web envoyées au chemin racine ('/') en affichant le message "Hello, world!" via un serveur s'exécutant sur le port 8080 :

const express = require('express');

const app = express();

app.get('/', (req, res) => {
  res.status(200).send('Hello, world!').end();
});

// Start the server
const PORT = process.env.PORT || 8080;
app.listen(PORT, () => {
  console.log(`App listening on port ${PORT}`);
  console.log('Press Ctrl+C to quit.');
});

Il est important de noter que sur les dernières lignes, le code demande au serveur d'écouter le port spécifié par la variable process.env.PORT. Il s'agit d'une variable d'environnement définie par l'environnement d'exécution App Engine. Si votre serveur n'écoute pas ce port, il ne pourra pas recevoir de requêtes.

Quotas et limites

App Engine alloue automatiquement des ressources à votre application lorsque le trafic augmente. Toutefois, cela dépend des restrictions suivantes :

  • 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. Les applications à latence très élevée (par exemple, de plus d'une seconde par requête pour un grand nombre de requêtes) et à haut débit nécessitent une formule d'assistance Silver, Gold ou Platinum. Les clients bénéficiant de ce niveau d'assistance peuvent demander une augmentation de leurs limites de débit en contactant leur représentant de l'équipe d'assistance.

  • 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 Cloud Console, la page Détails des quotas affiche également les valeurs de Requêtes sécurisées, Bande passante entrante sécurisée et 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 préférer 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

Pour définir cet en-tête pour les réponses générées à partir de votre code, utilisez le package helmet.