Mode de traitement des requêtes

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. 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.

L'exemple suivant est une application Sinatra très basique, reposant sur un unique fichier, qui répond à toutes les requêtes GET de clients Web envoyées au chemin racine "/" en affichant le message Hello, world!  :

require "sinatra"

get "/" do
  "Hello world!"
end

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. 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). Sur la page Quotas de la console GCP, les requêtes sécurisées, la bande passante entrante sécurisée et la bande passante sortante sécurisée sont également indiquées sous forme de valeurs distinctes à des fins d'information. 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 sont terminées au niveau de l'équilibreur de charge. Le trafic provenant de l'équilibreur de charge est envoyé à l'instance par le biais d'un canal chiffré, puis transmis au serveur d'applications via HTTP. L'en-tête X-Forwarded-Proto vous permet de déterminer si la requête initiale é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.

Réponses aux requêtes

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

Désactiver la mise en mémoire tampon

Par défaut, toutes les réponses d'App Engine sont mises en mémoire tampon dans des blocs de 64 000 Ko. Dans certains cas, il peut être judicieux de désactiver la mise en mémoire tampon et de transmettre directement les octets au client. Cette méthode est généralement préférable lorsque vous utilisez des requêtes GET suspendues ou des événements envoyés par le serveur (SSE). Pour désactiver la mise en mémoire tampon, vous pouvez définir l'en-tête de réponse X-Accel-Buffering sur no.

X-Accel-Buffering: no

Forcer les connexions HTTPS

Pour des raisons de sécurité, toutes les applications doivent encourager les clients à se connecter via le protocole https. Vous pouvez utiliser l'en-tête Strict-Transport-Security pour indiquer au navigateur de préférer https à http pour une page donnée ou un domaine entier, par exemple :

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

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement flexible App Engine pour les documents Ruby