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 sur les en-têtes de requêtes et les réponses.

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. Vous pouvez également modifier le nombre de requêtes simultanées qu'une instance peut traiter en définissant l'élément max_concurrent_requests dans votre fichier app.yaml.

Le serveur détermine le script de gestionnaire PHP à exécuter en comparant l'URL de la requête et les formats d'URL du fichier de configuration app.yaml de l'application. Il exécute ensuite le script contenant les données de la requête. Le serveur place les données de la requête dans les variables d'environnement et dans le flux d'entrée standard. Le script exécute les actions adaptées à la requête, puis prépare une réponse et la place dans le flux de résultat standard.

L'exemple suivant est un script PHP qui répond aux requêtes HTTP avec le message "Hello, World!".

<?php

echo "hello world!";

Dans l'exemple suivant, nous nous servons du framework Slim pour répondre à une requête HTTP.

$app = new Slim\App();
$app->get('/', function ($request, $response) {
    // Use the Null Coalesce Operator in PHP7
    // http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.coalesce
    $name = $request->getQueryParams()['name'] ?? 'World';
    return $response->getBody()->write("Hello, $name!");
});
$app->run();

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 ci-dessous s'appliquent spécifiquement à l'utilisation de gestionnaires de requêtes :

Limite Volume
Taille d'une requête 32 Mo
Taille d'une réponse 32 Mo
Délai avant expiration de la requête Dépend du type de scaling utilisé par votre application
Nombre total de fichiers, au maximum (fichiers d'application et fichiers statiques) 10 000 au total,
1 000 par répertoire
Taille maximale d'un fichier d'application 32 Mo
Taille maximale d'un fichier statique 32 Mo
Taille maximale du total des fichiers d'application et des fichiers statiques Le premier Go est gratuit
Le tarif est ensuite de 0,026 $ par Go et par mois

Limites de réponse

Les réponses dynamiques sont limitées à 32 Mo. Si un gestionnaire de scripts génère une réponse supérieure à cette limite, le serveur renvoie une réponse vide avec un code d'état 500 indiquant une erreur interne du serveur. Cette limite ne s'applique pas aux réponses qui diffusent des données provenant de Cloud Storage.

En-têtes de requêtes

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.

Spécifier un délai de requête

App Engine est optimisé pour les applications dont les requêtes sont de courte durée (quelques centaines de millisecondes en général). Pour être efficace, une application doit répondre rapidement à la majorité des requêtes. Si tel n'est pas le cas, elle n'est pas adaptée à l'infrastructure App Engine.

Un script PHP dispose d'une durée limitée pour générer et renvoyer une réponse à une requête. Une fois ce dernier dépassé, le bit TIMEOUT du champ de bits associé à l'état de la connexion est défini. Le script dispose alors d'un deuxième délai court pour nettoyer toutes les tâches de longue durée et renvoyer une réponse à l'utilisateur.

Si le script n'a pas renvoyé de réponse à l'expiration du deuxième délai, le gestionnaire est arrêté et un message d'erreur par défaut est alors renvoyé.

Réponses

App Engine appelle le script avec le tableau $_REQUEST renseigné et met en mémoire tampon tout résultat du script. Une fois l'exécution du script terminée, le service envoie le résultat mis en mémoire tampon à l'utilisateur final.

Certaines limites de taille s'appliquent à la réponse que vous générez et celle-ci peut être modifiée avant d'être renvoyée au client.

Pour en savoir plus, consultez la documentation de référence sur les réponses aux requêtes.

Réponses en flux continu

App Engine n'accepte pas les réponses en flux continu dans lesquelles les données sont envoyées au client par blocs incrémentiels pendant le traitement d'une requête. Toutes les données de votre code sont collectées comme indiqué ci-dessus et envoyées sous la forme d'une réponse HTTP unique.

Compression de la réponse

Pour les réponses renvoyées par votre code, App Engine compresse les données dans la réponse si les deux conditions suivantes sont remplies :

  • La requête contient l'en-tête Accept-Encoding qui inclut gzip comme valeur.
  • La réponse contient des données textuelles telles que HTML, CSS ou JavaScript.

Pour les réponses renvoyées par un gestionnaire de répertoires ou de fichiers statiques App Engine, les données de réponse sont compressées si toutes les conditions suivantes sont remplies :

  • La requête inclut l'en-tête Accept-Encoding, dont une des valeurs est gzip.
  • Le client peut recevoir les données de réponse dans un format compressé. L'interface Google gère une liste de clients qui sont connus pour avoir des problèmes liés aux réponses compressées. Ces clients ne recevront pas les données compressées provenant de gestionnaires statiques de votre application, même si les en-têtes de requête contiennent Accept-Encoding: gzip.
  • La réponse contient des données textuelles telles que HTML, CSS ou JavaScript.

Veuillez noter les points suivants :

  • Un client peut forcer la compression des types de contenu textuel en définissant à la fois les en-têtes de requête Accept-Encoding et User-Agent sur gzip.

  • Si une requête ne spécifie pas gzip dans l'en-tête Accept-Encoding, App Engine ne compresse pas les données de réponse.

  • L'interface Google met en cache les réponses des gestionnaires de répertoires et de fichiers statiques App Engine. En fonction de divers facteurs, tels que le type des données de réponse mises en cache en premier, les en-têtes Vary que vous avez spécifiés dans la réponse ou les en-têtes inclus dans la requête, un client peut avoir demandé des données compressées, mais recevoir des données non compressées, et inversement. Pour en savoir plus, consultez la section Mettre en cache les réponses.

Mettre en cache les réponses

L'interface Google et éventuellement le navigateur de l'utilisateur ainsi que d'autres serveurs proxy de mise en cache intermédiaires mettent en cache les réponses de votre application, comme indiqué par les en-têtes de mise en cache standards que vous spécifiez dans la réponse. Vous pouvez spécifier ces en-têtes de réponse soit via votre framework, directement dans votre code, soit via les gestionnaires de répertoires et de fichiers statiques d'App Engine.

Dans l'interface Google, la clé du cache correspond à l'URL complète de la requête.

Mettre en cache du contenu statique

Pour vous assurer que les clients reçoivent toujours le contenu statique mis à jour dès sa publication, nous vous recommandons de diffuser le contenu statique à partir de répertoires avec versions gérées, tels que css/v1/styles.css. L'interface Google ne valide pas le cache (vous devez rechercher le contenu mis à jour) avant l'expiration du cache. Même après son expiration, le cache n'est pas mis à jour tant que le contenu de l'URL de la requête n'a pas été modifié.

Les en-têtes de réponse suivants, que vous pouvez définir dans app.yaml, ont un impact sur le moment où l'interface Google met en cache le contenu et sur la manière dont le contenu est mis en cache.

  • Cache-Control doit être défini sur public pour que l'interface Google mette en cache le contenu. Si vous ne définissez pas cet en-tête dans app.yaml, App Engine l'ajoute automatiquement pour toutes les réponses traitées par un gestionnaire de répertoires ou de fichiers statiques. Pour en savoir plus, consultez la section En-têtes ajoutés ou remplacés.

  • Vary : pour permettre au cache de renvoyer différentes réponses pour une URL en fonction des en-têtes envoyés dans la requête, définissez une ou plusieurs des valeurs suivantes dans l'en-tête de réponse Vary : Accept, Accept-Encoding, Origin, ou X-Origin.

    En raison du potentiel de cardinalité élevée, les données ne seront pas mises en cache pour d'autres valeurs Vary.

    Exemple :

    1. Vous spécifiez l'en-tête de réponse suivant :

      Vary: Accept-Encoding

    2. Votre application reçoit une requête contenant l'en-tête Accept-Encoding: gzip. App Engine renvoie une réponse compressée, et l'interface Google met en cache la version des données de réponse compressée avec gzip. Toutes les requêtes ultérieures pour cette URL contenant l'en-tête Accept-Encoding: gzip recevront les données du cache compressées avec gzip jusqu'à l'invalidation de celui-ci (en raison du changement de contenu après l'expiration du cache).

    3. Votre application reçoit une requête qui ne contient pas l'en-tête Accept-Encoding. App Engine renvoie une réponse non compressée, et l'interface Google met en cache la version non compressée des données de réponse. Toutes les requêtes ultérieures pour cette URL ne contenant pas l'en-tête Accept-Encoding recevront les données compressées du cache jusqu'à ce que le cache soit invalidé.

    Si vous ne spécifiez pas d'en-tête de réponse Vary, l'interface Google crée une seule entrée de cache pour l'URL et l'utilise pour toutes les requêtes, quels que soient les en-têtes de la requête. Exemple :

    1. Vous ne spécifiez pas l'en-tête de réponse Vary: Accept-Encoding.
    2. Une requête contient l'en-tête Accept-Encoding: gzip, et la version compressée avec gzip des données de réponse est mise en cache.
    3. Une deuxième requête ne contient pas l'en-tête Accept-Encoding: gzip. Toutefois, comme le cache contient une version compressée avec gzip des données de réponse, la réponse sera compressée avec gzip même si le client a demandé des données non compressées.

Les en-têtes de la requête influent également sur la mise en cache :

  • Si la requête contient un en-tête Authorization, le contenu ne sera pas mis en cache par l'interface Google.

Expiration du cache

Par défaut, les en-têtes de mise en cache que les gestionnaires de répertoires et de fichiers statiques App Engine ajoutent aux réponses indiquent aux clients et aux proxys Web, tels que l'interface Google, que le cache doit expirer au bout de 10 minutes.

Une fois un fichier transmis avec un délai d'expiration donné, il n'existe généralement aucun moyen de le supprimer des caches intermédiaires, même si l'utilisateur efface le cache de son propre navigateur. Le fait de déployer une nouvelle version de l'application ne permet pas de réinitialiser les caches. Par conséquent, si vous avez l'intention de modifier un fichier statique, il doit posséder un délai d'expiration court (moins d'une heure). Le délai d'expiration par défaut de 10 minutes convient dans la plupart des cas.

Vous pouvez modifier le délai d'expiration par défaut pour tous les gestionnaires de répertoires et de fichiers statiques en spécifiant l'élément default_expiration dans votre fichier app.yaml. Pour définir des délais d'expiration spécifiques pour des gestionnaires particuliers, spécifiez l'élément expiration dans l'élément gestionnaire de votre fichier app.yaml.

La valeur spécifiée dans le délai d'expiration des éléments sera utilisée pour définir les en-têtes de réponse HTTP Cache-Control et Expires.

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
Pour définir cet en-tête pour tout contenu statique diffusé par votre application, ajoutez-le aux gestionnaires de répertoires et de fichiers statiques de votre application.

Pour en savoir plus sur la configuration des en-têtes dans une réponse générée à partir de votre script, consultez les instructions fournies par le framework Web que vous utilisez pour votre application. Si vous n'utilisez pas de framework Web, utilisez la fonction header PHP.