Remarque: Au cours des prochains mois, nous allons réorganiser le site de documentation App Engine afin de faciliter la recherche de contenu et de mieux s'aligner avec les autres produits Google Cloud. Le même contenu sera disponible, mais la navigation correspondra désormais au reste des produits Cloud.

Créer des connexions persistantes avec WebSockets

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

Python|Java|Node.js|Go|Ruby|PHP|.NET

Vous pouvez utiliser WebSockets pour créer une connexion persistante à partir d'un client (tel qu'un appareil mobile ou un ordinateur) vers une instance App Engine. La connexion établie permet un échange de données bidirectionnel entre le client et le serveur à tout moment, ce qui réduit le temps de latence et optimise l'utilisation des ressources.

WebSockets

Le protocole WebSockets, défini dans le document RFC 6455, fournit un canal de communication en duplex intégral entre un client et un serveur. Le canal est mis en place à partir d'une requête HTTP(S) avec un en-tête "Upgrade".

Cas d'utilisation types de WebSockets :

Mises à jour d'événements en temps réel, telles que les flux sur les médias sociaux, les résultats sportifs, les actualités ou les cours boursiers
Notifications utilisateur, telles que les mises à jour de logiciels ou de contenus
Applications de chat
Outils d'édition collaboratifs
Jeux multijoueurs

Les WebSockets sont toujours disponibles pour votre application sans qu'aucune configuration supplémentaire ne soit nécessaire. Une fois la connexion WebSockets établie, elle expire au bout d'une heure.

Exécuter un exemple d'application avec WebSockets

Tout d'abord, suivez les instructions de la section "Hello, World!" pour Go sur App Engine pour configurer votre environnement et votre projet et comprendre la structure des applications Go dans App Engine.

Cloner l'exemple d'application

Copiez les exemples d'applications sur votre ordinateur local, puis accédez au répertoire websockets :

git clone https://github.com/GoogleCloudPlatform/golang-samples
cd golang-samples/appengine_flexible/websockets/

Exécuter l'exemple en local

Pour exécuter l'exemple d'application sur votre ordinateur local :

Démarrez un serveur Web local :
```
go run *.go
```
Dans votre navigateur Web, saisissez l'adresse suivante :
```
http://localhost:8080
```

Déployer et exécuter l'exemple d'application sur App Engine

Affinité de session

Certains clients ne sont pas compatibles avec WebSockets. Pour contourner ce problème, de nombreuses applications utilisent des bibliothèques telles que Socket.io qui s'appuient sur un long polling HTTP avec des clients qui ne sont pas compatibles avec WebSockets.

En règle générale, App Engine répartit les requêtes uniformément entre les instances disponibles. Cependant, en cas de long polling HTTP, plusieurs requêtes séquentielles d'un utilisateur donné doivent atteindre la même instance.

Pour permettre à App Engine d'envoyer des requêtes du même utilisateur vers la même instance, vous pouvez activer l'affinité de session. App Engine identifie ensuite les requêtes envoyées par les mêmes utilisateurs en inspectant un cookie et achemine celles-ci vers la même instance.

L'affinité de session dans App Engine est mise en œuvre de la manière la plus optimale possible. Lors du développement de votre application, vous devez toujours partir du principe que l'affinité de session n'est pas garantie. Un client peut perdre son affinité avec l'instance cible dans les scénarios suivants :

L'autoscaler App Engine peut ajouter ou supprimer des instances qui diffusent votre application. L'application peut réaffecter la charge, et l'instance cible peut être déplacée. Pour réduire ce risque, assurez-vous que vous avez défini le nombre minimal d'instances permettant de gérer la charge attendue.
Si l'instance cible échoue lors des vérifications d'état, App Engine déplace la session vers une instance opérationnelle. Pour en savoir plus sur les vérifications d'état et les options de personnalisation, consultez la section Vérifications d'état fractionnées.
L'affinité de session est perdue lorsqu'une instance est redémarrée à des fins de maintenance ou de mise à jour logicielle. Les instances de VM de l'environnement flexible App Engine sont redémarrées toutes les semaines.

L'affinité de session n'étant pas garantie, vous ne devez l'utiliser que pour tirer parti de la capacité de socket.io et des autres bibliothèques à se rabattre sur les interrogations longues HTTP en cas d'interruption de connexion. Vous ne devez jamais utiliser l'affinité de session pour créer des applications avec état.

Activer et désactiver l'affinité de session

Par défaut, l'affinité de session est désactivée pour toutes les applications App Engine. Elle est définie au niveau de la version de votre application et peut être activée ou désactivée lors du déploiement.

Pour activer l'affinité de session pour votre version App Engine, ajoutez l'entrée suivante à votre fichier app.yaml :

network:
  session_affinity: true

Une fois que la version est déployée avec le fichier "app.yaml" mis à jour, la diffusion des nouvelles requêtes commence à partir de la même instance, tant que cette instance est disponible.

Pour désactiver l'affinité de session, supprimez l'entrée de votre fichier app.yaml ou définissez la valeur sur "false" :

network:
  session_affinity: false