Firebase Cloud Messaging (FCM) propose un large éventail d'options et de fonctionnalités de messagerie. Les informations de cette page sont destinées à vous aider à comprendre les différents types de messages FCM et ce que vous pouvez en faire.
Types de messages
Avec FCM, vous pouvez envoyer deux types de messages aux clients:
- Messages de notification, parfois appelés "messages d'affichage". Elles sont gérées automatiquement par le SDK FCM.
- Messages de données, gérés par l'application cliente.
Les messages de notification contiennent un ensemble prédéfini de clés visibles par l'utilisateur. À l'inverse, les messages de données ne contiennent que vos paires clé-valeur personnalisées définies par l'utilisateur. Les messages de notification peuvent contenir une charge utile de données facultative. La charge utile maximale pour les deux types de messages est de 4 096 octets, sauf lors de l'envoi de messages depuis la console Firebase, qui applique une limite de 1 000 caractères.
| Scénario d'utilisation | Envoyer | |
|---|---|---|
| Message de notification | Le SDK FCM affiche le message sur les appareils des utilisateurs finaux au nom de l'application cliente lorsqu'il s'exécute en arrière-plan. Sinon, si l'application s'exécute au premier plan lorsque la notification est reçue, le code de l'application détermine le comportement. Les messages de notification comportent un ensemble prédéfini de clés visibles par l'utilisateur et une charge utile de données facultative de paires clé-valeur personnalisées. |
|
| Message data | L'application cliente est chargée de traiter les messages de données. Les messages de données ne contiennent que des paires clé-valeur personnalisées sans noms de clé réservés (voir ci-dessous). | Dans un environnement sécurisé tel que
Cloud Functions ou votre serveur d'application, utilisez le SDK Admin ou les protocoles de serveur FCM. Dans la requête d'envoi, définissez la clé data.
|
Utilisez des messages de notification lorsque vous souhaitez que le SDK FCM gère l'affichage automatique d'une notification lorsque votre application s'exécute en arrière-plan. Utilisez des messages de données lorsque vous souhaitez les traiter avec votre propre code d'application client.
FCM peut envoyer un message de notification incluant une charge utile de données facultative. Dans ce cas, FCM gère l'affichage de la charge utile de notification, et l'application cliente gère la charge utile de données.
Messages de notification
Pour les tests, ou à des fins marketing et de réengagement des utilisateurs, vous pouvez envoyer des messages de notification à l'aide de la console Firebase. La console Firebase propose des tests A/B basés sur les données analytiques pour vous aider à affiner et à améliorer vos messages marketing.
Pour envoyer des messages de notification par programmation à l'aide du SDK Admin ou des protocoles FCM, définissez la clé notification avec l'ensemble prédéfini nécessaire d'options clé-valeur pour la partie visible par l'utilisateur du message de notification. Voici un exemple de message de notification au format JSON dans une application de chat. L'utilisateur peut s'attendre à voir un message intitulé "Portugal contre Danemark" et le texte "Super match !" sur l'appareil:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}
Les messages de notification sont envoyés à la barre des notifications lorsque l'application est en arrière-plan. Pour les applications au premier plan, les messages sont gérés par une fonction de rappel.
Consultez la documentation de référence sur l'objet de notification du protocole HTTP v1 pour obtenir la liste complète des clés prédéfinies disponibles pour créer des messages de notification.
Messages de données
Définissez la clé appropriée avec vos paires clé-valeur personnalisées pour envoyer une charge utile de données à l'application cliente.
Par exemple, voici un message au format JSON dans la même application de chat que ci-dessus, où les informations sont encapsulées dans la clé data commune et où l'application cliente doit interpréter le contenu:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
}
L'exemple ci-dessus montre l'utilisation du champ de premier niveau, ou data commun, qui est interprété par les clients sur toutes les plates-formes qui reçoivent le message.
Sur chaque plate-forme, l'application cliente reçoit la charge utile de données dans une fonction de rappel.
Chiffrement des messages de données
La couche transport Android (voir Architecture FCM) utilise le chiffrement point à point. Selon vos besoins, vous pouvez décider d'ajouter un chiffrement de bout en bout aux messages de données. FCM ne fournit pas de solution de bout en bout. Toutefois, des solutions externes sont disponibles, telles que Capillary ou DTLS.
Messages de notification avec charge utile de données facultative
Vous pouvez envoyer des messages de notification contenant une charge utile facultative de paires clé-valeur personnalisées, à la fois de manière programmatique et via la console Firebase. Dans l' outil de création de notifications, utilisez les champs Données personnalisées dans les options avancées.
Le comportement de l'application lors de la réception de messages incluant à la fois des charges utiles de notification et de données dépend de l'état de l'application (en arrière-plan ou au premier plan), c'est-à-dire si elle est active ou non au moment de la réception.
- En arrière-plan, les applications reçoivent la charge utile de notification dans la barre d'état des notifications et ne gèrent la charge utile de données que lorsque l'utilisateur appuie sur la notification.
- Au premier plan, votre application reçoit un objet de message avec les deux charges utiles disponibles.
Voici un message au format JSON contenant à la fois la clé notification et la clé data:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}
Personnaliser un message sur plusieurs plates-formes
Le protocole HTTP Firebase Admin SDK et le protocole HTTP FCM v1 permettent tous deux à vos requêtes de messages de définir tous les champs disponibles dans l'objet message. Par exemple :
- un ensemble commun de champs à interpréter par toutes les instances d'application qui reçoivent le message.
- Ensembles de champs spécifiques à la plate-forme, tels que
AndroidConfigetWebpushConfig, interprétés uniquement par les instances d'application exécutées sur la plate-forme spécifiée.
Les blocs spécifiques à la plate-forme vous permettent de personnaliser les messages pour différentes plates-formes afin de vous assurer qu'ils sont correctement gérés lorsqu'ils sont reçus. Le backend FCM tiendra compte de tous les paramètres spécifiés et personnalisera le message pour chaque plate-forme.
Quand utiliser des champs courants ?
Utilisez des champs courants lorsque vous:
- Cibler les instances d'application sur toutes les plates-formes (Apple, Android et Web)
- Envoyer des messages aux sujets
Toutes les instances d'application, quelle que soit la plate-forme, peuvent interpréter les champs courants suivants:
Quand utiliser des champs spécifiques à la plate-forme ?
Utilisez des champs spécifiques à la plate-forme lorsque vous souhaitez:
- Envoyer des champs uniquement à des plates-formes spécifiques
- Envoyer des champs spécifiques à la plate-forme en plus des champs communs
Lorsque vous souhaitez envoyer des valeurs uniquement à des plates-formes spécifiques, n'utilisez pas de champs communs, mais des champs spécifiques à la plate-forme. Par exemple, pour envoyer une notification uniquement aux plates-formes Apple et au Web, mais pas à Android, vous devez utiliser deux ensembles de champs distincts, l'un pour Apple et l'autre pour le Web.
Lorsque vous envoyez des messages avec des options de distribution spécifiques, utilisez des champs spécifiques à la plate-forme pour les définir. Si vous le souhaitez, vous pouvez spécifier des valeurs différentes par plate-forme. Toutefois, même si vous souhaitez définir essentiellement la même valeur sur toutes les plates-formes, vous devez utiliser des champs spécifiques à la plate-forme. En effet, chaque plate-forme peut interpréter la valeur légèrement différemment. Par exemple, la valeur de la durée de vie est définie sur Android comme une heure d'expiration en secondes, tandis qu'elle est définie sur Apple comme une date d'expiration.
Exemple: message de notification avec des options de diffusion spécifiques à la plate-forme
La requête d'envoi v1 suivante envoie un titre et un contenu de notification communs à toutes les plates-formes, mais envoie également des forçages spécifiques à la plate-forme. Plus précisément, la demande:
- définit une durée de vie longue pour les plates-formes Android et Web, tout en définissant la priorité des messages des APN (plates-formes Apple) sur une valeur faible
- définit les clés appropriées pour définir le résultat d'un appui de l'utilisateur sur la notification sur Android et Apple (
click_actionetcategory, respectivement).
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Match update",
"body":"Arsenal goal in added time, score is now 3-0"
},
"android":{
"ttl":"86400s",
"notification"{
"click_action":"OPEN_ACTIVITY_1"
}
},
"apns": {
"headers": {
"apns-priority": "5",
},
"payload": {
"aps": {
"category": "NEW_MESSAGE_CATEGORY"
}
}
},
"webpush":{
"headers":{
"TTL":"86400"
}
}
}
}
Pour en savoir plus sur les clés disponibles dans les blocs spécifiques à la plate-forme dans le corps du message, consultez la documentation de référence HTTP v1. Pour en savoir plus sur la création de requêtes d'envoi contenant le corps du message, consultez la section Créer des requêtes d'envoi.
Options de livraison
FCM fournit un ensemble spécifique d'options de diffusion pour les messages envoyés aux appareils Android, et permet des options similaires sur les plates-formes Apple et le Web. Par exemple, le comportement des messages "réductibles" est compatible avec Android via collapse_key de FCM, avec Apple via apns-collapse-id et avec JavaScript/Web via Topic. Pour en savoir plus, consultez les descriptions de cette section et la documentation de référence associée.
Messages non réductibles et réductibles
Un message non réductible indique que chaque message est envoyé à l'appareil. Un message non réductible fournit du contenu utile, contrairement à un message réductible, tel qu'un "ping" sans contenu envoyé à l'application mobile pour qu'elle contacte le serveur afin de récupérer des données.
Les messages de chat ou les messages critiques sont des cas d'utilisation courants des messages non réductibles. Par exemple, dans une application de chat, vous devez distribuer chaque message, car chaque message a un contenu différent.
Pour Android, vous ne pouvez stocker que 100 messages sans les réduire. Si la limite est atteinte, tous les messages stockés sont supprimés. Lorsque l'appareil est de nouveau en ligne, il reçoit un message spécial indiquant que la limite a été atteinte. L'application peut ensuite gérer correctement la situation, généralement en demandant une synchronisation complète au serveur de l'application.
Un message réductible est un message qui peut être remplacé par un nouveau message s'il n'a pas encore été distribué à l'appareil.
Les messages réductibles sont couramment utilisés pour indiquer à une application mobile de synchroniser les données du serveur. Par exemple, une application de sport qui informe les utilisateurs du dernier score. Seul le message le plus récent est pertinent.
Pour marquer un message comme réductible sur Android, incluez le paramètre collapse_key dans la charge utile du message. Par défaut, la clé de réduction est le nom du package de l'application enregistré dans la console Firebase. Le serveur FCM peut stocker simultanément quatre messages réductibles différents par appareil, chacun avec une clé de réduction différente. Si vous dépassez ce nombre, FCM ne conserve que quatre clés de réduction, sans garantie quant aux clés conservées.
Les messages de sujet sans charge utile sont réductibles par défaut. Les messages de notification sont toujours réductibles et ignorent le paramètre collapse_key.
Quelle solution dois-je utiliser ?
Les messages réductibles sont un meilleur choix d'un point de vue des performances, à condition que votre application n'ait pas besoin d'utiliser de messages non réductibles. Toutefois, si vous utilisez des messages réductibles, n'oubliez pas que FCM n'autorise qu'un maximum de quatre clés de réduction différentes à être utilisées par FCM par jeton d'enregistrement à un moment donné. Vous ne devez pas dépasser ce nombre, car cela pourrait avoir des conséquences imprévisibles.
| Scénario d'utilisation | Envoyer | |
|---|---|---|
| Non réductible | Chaque message est important pour l'application cliente et doit être transmis. | À l'exception des messages de notification, tous les messages ne sont pas réductibles par défaut. |
| Réductible | Lorsqu'un message plus récent rend un message plus ancien et associé non pertinent pour l'application cliente, FCM remplace le message plus ancien. Par exemple : messages utilisés pour lancer une synchronisation de données à partir du serveur ou messages de notification obsolètes. | Définissez le paramètre approprié dans votre requête de message :
|
Définir la priorité d'un message
Vous avez deux options pour attribuer une priorité de diffusion aux messages en aval : une priorité normale et une priorité élevée. Bien que le comportement diffère légèrement d'une plate-forme à l'autre, l'envoi des messages de priorité normale et élevée fonctionne comme suit:
Priorité normale : Les messages de priorité normale sont envoyés immédiatement lorsque l'application est exécutée au premier plan. Pour les applications en arrière-plan, la diffusion peut être retardée. Pour les messages moins urgents, tels que les notifications de nouveaux e-mails, la synchronisation de l'UI ou la synchronisation des données de l'application en arrière-plan, choisissez la priorité de diffusion normale.
Priorité élevée. FCM tente de distribuer immédiatement les messages à priorité élevée, même si l'appareil est en mode Doze. Les messages de priorité élevée sont destinés aux contenus visibles par l'utilisateur et à caractère urgent.
Voici un exemple de message de priorité normal envoyé via le protocole HTTP v1 FCM pour avertir un abonné à un magazine que de nouveaux contenus sont disponibles en téléchargement:
{
"message":{
"topic":"subscriber-updates",
"notification":{
"body" : "This week's edition is now available.",
"title" : "NewsMagazine.com",
},
"data" : {
"volume" : "3.21.15",
"contents" : "http://www.news-magazine.com/world-week/21659772"
},
"android":{
"priority":"normal"
},
"apns":{
"headers":{
"apns-priority":"5"
}
},
"webpush": {
"headers": {
"Urgency": "high"
}
}
}
}
Pour en savoir plus sur la configuration de la priorité des messages, en fonction de la plate-forme:
- Documentation sur les APNs
- Définir et gérer la priorité des messages (Android)
- Urgence des messages push Web
Cas d'utilisation critiques
Les API FCM ne sont pas conçues pour les alertes d'urgence ni pour d'autres activités à haut risque pour lesquelles l'utilisation ou la défaillance des API pourraient entraîner la mort, des dommages corporels ou des dommages environnementaux (comme l'exploitation d'installations nucléaires, le contrôle du trafic aérien ou les systèmes médicaux). Toute utilisation de ce type est expressément interdite en vertu de la section 4. a. 7 des conditions d'utilisation. Vous êtes seul responsable de la conformité de votre application avec les présentes conditions et de tout dommage résultant de votre non-respect. Google fournit les API "tel quel" et se réserve le droit de les abandonner, ou de supprimer une partie ou une fonctionnalité, ou de suspendre votre accès, pour quelque raison que ce soit et à tout moment, sans aucune responsabilité ni obligation envers vous ou vos utilisateurs.
Définir la durée de vie d'un message
FCM distribue généralement les messages immédiatement après leur envoi. Cependant, ce n'est pas toujours possible. Par exemple, si la plate-forme est Android, l'appareil peut être éteint, hors connexion ou indisponible. FCM peut également retarder intentionnellement les messages pour empêcher une application de consommer des ressources excessives et d'affecter négativement l'autonomie de la batterie.
Dans ce cas, FCM stocke le message et le distribue dès que possible. Bien que cela soit acceptable dans la plupart des cas, il existe certaines applications pour lesquelles un message tardif peut tout aussi bien ne jamais être envoyé. Par exemple, si le message est une notification d'appel entrant ou de chat vidéo, il n'a de sens que pendant une courte période avant la fin de l'appel. Si le message est une invitation à un événement, il est inutile s'il est reçu après la fin de l'événement.
Sur Android et Web/JavaScript, vous pouvez spécifier la durée de vie maximale d'un message. La valeur doit être une durée comprise entre 0 et 2 419 200 secondes (28 jours). Elle correspond à la période maximale pendant laquelle FCM stocke et tente de distribuer le message. Les requêtes qui ne contiennent pas ce champ sont définies par défaut sur la période maximale de quatre semaines.
Voici quelques utilisations possibles de cette fonctionnalité:
- Appels vidéo entrants
- Événements d'expiration des invitations
- Événements d'agenda
Autre avantage de spécifier la durée de vie d'un message : FCM n'applique pas la limitation des messages réductibles aux messages dont la valeur de durée de vie est de 0 seconde.
FCM gère de manière optimale les messages qui doivent être distribués "maintenant ou jamais". N'oubliez pas qu'une valeur time_to_live de 0 signifie que les messages qui ne peuvent pas être distribués immédiatement sont supprimés. Toutefois, comme ces messages ne sont jamais stockés, cela offre la meilleure latence pour l'envoi de messages de notification.
Voici un exemple de requête incluant un TTL:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
},
"apns":{
"headers":{
"apns-expiration":"1604750400"
}
},
"android":{
"ttl":"4500s"
},
"webpush":{
"headers":{
"TTL":"4500"
}
}
}
}
Durée de vie d'un message
Lorsqu'un serveur d'application publie un message sur FCM et reçoit un ID de message en retour, cela ne signifie pas que le message a déjà été distribué à l'appareil. Cela signifie qu'il a été accepté pour la diffusion. Ce qui se passe avec le message après son acceptation dépend de nombreux facteurs.
Dans le meilleur des cas, si l'appareil est connecté à FCM, que l'écran est allumé et qu'il n'y a pas de restrictions de limitation, le message est immédiatement distribué.
Si l'appareil est connecté, mais en mode Sommeil, un message de faible priorité est stocké par FCM jusqu'à ce que l'appareil ne soit plus en mode Sommeil. C'est là que le flag collapse_key joue un rôle: s'il existe déjà un message avec la même clé de réduction (et le même jeton d'enregistrement) stocké et en attente de diffusion, l'ancien message est supprimé et le nouveau prend sa place (c'est-à-dire que l'ancien message est réduit par le nouveau). Toutefois, si la clé de réduction n'est pas définie, les nouveaux et anciens messages sont stockés pour une diffusion ultérieure.
Si l'appareil n'est pas connecté à FCM, le message est stocké jusqu'à ce qu'une connexion soit établie (en respectant à nouveau les règles de clé de réduction). Lorsqu'une connexion est établie, FCM envoie tous les messages en attente à l'appareil. Si l'appareil ne se connecte plus jamais (par exemple, s'il a été rétabli à sa configuration d'usine), le message expire et est supprimé de l'espace de stockage FCM. Le délai avant expiration par défaut est de quatre semaines, sauf si l'indicateur time_to_live est défini.
Pour en savoir plus sur la distribution d'un message:
Pour en savoir plus sur la distribution des messages sur les plates-formes Android ou Apple, consultez le tableau de bord de reporting FCM, qui enregistre le nombre de messages envoyés et ouverts sur les appareils Apple et Android, ainsi que les données sur les "impressions" (notifications vues par les utilisateurs) pour les applications Android.
Pour les appareils Android avec la messagerie de canal direct activée, si l'appareil ne s'est pas connecté à FCM depuis plus d'un mois, FCM accepte toujours le message, mais l'élimine immédiatement. Si l'appareil se connecte dans les quatre semaines suivant le dernier message de données que vous lui avez envoyé, votre client reçoit le rappel onDeletedMessages(). L'application peut ensuite gérer correctement la situation, généralement en demandant une synchronisation complète au serveur de l'application.
Enfin, lorsque FCM tente de transmettre un message à l'appareil et que l'application a été désinstallée, FCM supprime immédiatement ce message et invalide le jeton d'enregistrement. Les futures tentatives d'envoi d'un message à cet appareil entraîneront une erreur NotRegistered.
Limites et quotas
Notre objectif est de toujours distribuer tous les messages envoyés via FCM. Toutefois, l'envoi de tous les messages entraîne parfois une mauvaise expérience utilisateur globale. Dans d'autres cas, nous devons définir des limites pour nous assurer que FCM fournit un service évolutif pour tous les expéditeurs. Les types de limites et de quotas décrits dans cette section nous aident à équilibrer ces facteurs importants.
Limiter les messages en aval
L'API HTTP v1 a introduit des quotas par projet et par minute pour la messagerie en aval. Le quota par défaut de 600 000 messages par minute couvre plus de 99% des développeurs FCM, tout en protégeant la stabilité du système et en minimisant l'impact des projets à pics.
Les pics de trafic peuvent entraîner des erreurs liées au dépassement du quota. En cas de dépassement du quota, le système renvoie le code d'état HTTP 429 (QUOTA_EXCEEDED) jusqu'à ce que le quota soit rempli dans la minute suivante. Des réponses 429 peuvent également être renvoyées en cas de surcharge. Nous vous recommandons donc vivement de gérer les réponses 429 conformément aux recommandations publiées.
Remarques :
- Le quota en aval mesure les messages, et non les requêtes.
- Les erreurs client (codes d'état HTTP 400 à 499) sont comptabilisées (à l'exception des codes 429).
- Les quotas sont calculés par minute, mais ces minutes ne sont pas alignées sur l'horloge.
Quota de surveillance
Vous pouvez consulter les quotas, l'utilisation et les erreurs dans la console Google Cloud:
- Accéder à la console Google Cloud
- Sélectionnez API et services.
- Dans la liste du tableau, sélectionnez API Firebase Cloud Messaging.
- Sélectionnez QUOTA ET LIMITES DU SYSTÈME.
REMARQUE: Ces graphiques ne sont pas alignés précisément sur les minutes de quota. Par conséquent, des erreurs 429 peuvent être diffusées lorsque le trafic semble être inférieur au quota.
Demander une augmentation de quota
Avant de demander une augmentation de quota, vérifiez les points suivants:
- Votre utilisation est régulièrement supérieure à 80% du quota pendant au moins cinq minutes consécutives par jour.
- Le ratio d'erreurs client est inférieur à 5 %, en particulier pendant les pics de trafic.
- Vous respectez les bonnes pratiques pour envoyer des messages à grande échelle.
Si vous remplissez ces critères, vous pouvez envoyer une demande d'augmentation de quota jusqu'à 25 %. FCM fera tout son possible pour répondre à cette demande (aucune augmentation ne peut être garantie).
Si vous avez besoin de plus de quota de messages en aval en raison d'un lancement imminent ou d'un événement temporaire, demandez votre quota au moins 15 jours à l'avance pour nous laisser suffisamment de temps pour traiter la demande. Pour les requêtes volumineuses (> 18 millions de messages par minute), un préavis d'au moins 30 jours est requis. Les lancements et les requêtes d'événements spéciaux restent soumis au ratio d'erreurs client et aux bonnes pratiques.
Consultez également les questions fréquentes sur les quotas FCM.
Limite des messages par sujet
Le débit d'ajout/suppression d'abonnements aux sujets est limité à 3 000 RPS par projet.
Pour connaître les taux d'envoi de messages, consultez Limitation du fanout.
Limitation de la distribution
Le fanage de messages consiste à envoyer un message à plusieurs appareils, par exemple lorsque vous ciblez des sujets et des groupes, ou lorsque vous utilisez l'outil de création de notifications pour cibler des audiences ou des segments d'utilisateurs.
La diffusion des messages n'est pas instantanée. Il peut donc arriver que plusieurs diffusions soient en cours simultanément. Nous limitons le nombre de fanouts de messages simultanés par projet à 1 000. Après cela, nous pouvons refuser les demandes de fanage supplémentaires ou différer le fanage des demandes jusqu'à ce que certains des fanages déjà en cours soient terminés.
Le taux de fanout réel réalisable est influencé par le nombre de projets demandant des fanouts en même temps. Un taux de fanout de 10 000 RPS pour un projet individuel n'est pas rare, mais ce nombre n'est pas garanti et dépend de la charge totale sur le système. Il est important de noter que la capacité de fanout disponible est répartie entre les projets et non entre les requêtes de fanout. Par conséquent, si votre projet comporte deux fanouts en cours, chacun d'eux ne verra que la moitié du débit de fanout disponible. Pour maximiser la vitesse de fanout, nous vous recommandons de n'avoir qu'un seul fanout actif à la fois.
Limiter les messages réductibles
Comme décrit ci-dessus, les messages réductibles sont des notifications sans contenu conçues pour se réduire les unes sur les autres. Si un développeur répète trop fréquemment le même message dans une application, nous retardons (limitons) les messages pour réduire leur impact sur la batterie de l'utilisateur.
Par exemple, si vous envoyez un grand nombre de nouvelles requêtes de synchronisation des e-mails à un seul appareil, nous pouvons retarder la prochaine requête de synchronisation des e-mails de quelques minutes afin que l'appareil puisse se synchroniser à un débit moyen inférieur. Cette limitation est effectuée uniquement pour limiter l'impact de la batterie sur l'utilisateur.
Si votre cas d'utilisation nécessite des modèles d'envoi par rafales élevés, les messages non réductibles peuvent être le bon choix. Pour ces messages, veillez à inclure le contenu afin de réduire l'impact sur la batterie.
Nous limitons les messages réductibles à une rafale de 20 messages par application et par appareil, avec un remplissage d'un message toutes les trois minutes.
Limiter le débit du serveur XMPP
Nous limitons le débit de connexion aux serveurs XMPP FCM à 400 connexions par minute et par projet. Cela ne devrait pas poser de problème pour la distribution des messages, mais il est important de garantir la stabilité du système. Pour chaque projet, FCM autorise 2 500 connexions en parallèle.
Pour la messagerie en amont avec XMPP, FCM limite les messages en amont à 1 500 000/minute par projet afin d'éviter de surcharger les serveurs de destination en amont.
Nous limitons les messages en amont par appareil à 1 000 par minute pour éviter que la batterie ne se décharge en raison d'un mauvais comportement des applications.
Fréquence de messages maximale pour un seul appareil
Sur Android, vous pouvez envoyer jusqu'à 240 messages/minute et 5 000 messages/heure à un seul appareil. Ce seuil élevé est destiné à permettre des pics de trafic à court terme, par exemple lorsque les utilisateurs interagissent rapidement par chat. Cette limite empêche les erreurs de logique d'envoi de décharger par inadvertance la batterie d'un appareil.
Pour iOS, nous renvoyons une erreur lorsque le débit dépasse les limites des APN.
Ports FCM et pare-feu
Si votre organisation dispose d'un pare-feu pour limiter le trafic entrant ou sortant d'Internet, vous devez le configurer pour autoriser les appareils mobiles à se connecter à FCM afin que les appareils de votre réseau puissent recevoir des messages. FCM utilise généralement le port 5228, mais il utilise parfois les ports 443, 5229 et 5230.
Pour les appareils qui se connectent à votre réseau, FCM ne fournit pas d'adresses IP spécifiques, car notre plage d'adresses IP change trop fréquemment et vos règles de pare-feu peuvent devenir obsolètes, ce qui affecte l'expérience de vos utilisateurs. Idéalement, ajoutez les ports 5228 à 5230 et 443 à la liste d'autorisation sans aucune restriction d'adresse IP. Toutefois, si vous devez appliquer une restriction d'adresse IP, vous devez ajouter à la liste d'autorisation toutes les adresses IP listées dans goog.json. Cette longue liste est mise à jour régulièrement. Nous vous recommandons de mettre à jour vos règles tous les mois. Les problèmes causés par les restrictions d'adresses IP du pare-feu sont souvent intermittents et difficiles à diagnostiquer.
Nous proposons un ensemble de noms de domaine pouvant être ajoutés à la liste d'autorisation au lieu d'adresses IP. Ces noms d'hôtes sont listés ci-dessous. Si nous commençons à utiliser d'autres noms d'hôte, nous mettrons à jour la liste ici. L'utilisation de noms de domaine pour votre règle de pare-feu peut ou non fonctionner dans votre appareil de pare-feu.
Ports TCP à ouvrir:
- 5228
- 5229
- 5230
- 443
Noms d'hôte à ouvrir:
- mtalk.google.com
- mtalk4.google.com
- mtalk-staging.google.com
- mtalk-dev.google.com
- alt1-mtalk.google.com
- alt2-mtalk.google.com
- alt3-mtalk.google.com
- alt4-mtalk.google.com
- alt5-mtalk.google.com
- alt6-mtalk.google.com
- alt7-mtalk.google.com
- alt8-mtalk.google.com
- android.apis.google.com
- device-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Pare-feu de traduction d'adresse réseau et/ou d'inspection des paquets avec état :
Si votre réseau implémente la traduction d'adresse réseau (NAT) ou l'inspection de paquets avec état (SPI), implémentez un délai avant expiration de 30 minutes ou plus pour nos connexions via les ports 5228 à 5230. Cela nous permet de fournir une connectivité fiable tout en réduisant la consommation de la batterie des appareils mobiles de vos utilisateurs.
Interactions et possibilité de contourner le VPN
Firebase Cloud Messaging prend diverses mesures pour s'assurer que la connexion de messagerie push du téléphone au serveur est fiable et disponible aussi souvent que possible. L'utilisation d'un VPN complique cette tâche.
Les VPN masquent les informations sous-jacentes dont FCM a besoin pour ajuster sa connexion afin de maximiser la fiabilité et l'autonomie de la batterie. Dans certains cas, les VPN rompent activement les connexions de longue durée, ce qui entraîne une mauvaise expérience utilisateur en raison de messages manqués ou retardés, ou d'une consommation élevée de la batterie. Lorsque le VPN est configuré pour nous permettre de le faire, nous contournons le VPN à l'aide d'une connexion chiffrée (sur le réseau de base Wi-Fi ou LTE) afin de garantir une expérience fiable et respectueuse de la batterie. L'utilisation de VPN contournables par FCM est spécifique au canal de notification push FCM. Le trafic FCM supplémentaire, tel que le trafic d'enregistrement, utilise le VPN s'il est actif. Lorsque la connexion FCM contourne le VPN, elle perd les avantages supplémentaires que le VPN peut fournir, tels que le masquage d'adresses IP.
Les différents VPN utilisent différentes méthodes pour contrôler s'il peut être contourné ou non. Pour savoir comment procéder, consultez la documentation de votre VPN.
Si le VPN n'est pas configuré pour être contournable, Firebase Cloud Messaging utilisera le réseau VPN pour se connecter au serveur. Cela peut entraîner des périodes de retard des messages et une utilisation plus importante de la batterie, car Cloud Messaging s'efforce de maintenir la connexion via la connexion VPN.
Identifiants
En fonction des fonctionnalités FCM que vous implémentez, vous devrez peut-être utiliser les identifiants suivants de votre projet Firebase:
| ID du projet | Identifiant unique de votre projet Firebase, utilisé dans les requêtes adressées au point de terminaison HTTP FCM v1. Cette valeur est disponible dans le volet Settings (Paramètres) de la console Firebase. |
| Jeton d'enregistrement | Chaîne de jeton unique qui identifie chaque instance d'application cliente. Le jeton d'enregistrement est obligatoire pour les messages envoyés à un seul appareil et à un groupe d'appareils. Notez que les jetons d'enregistrement doivent être tenus secrets. |
| ID de l'expéditeur | Valeur numérique unique créée lorsque vous créez votre projet Firebase, disponible dans l'onglet Cloud Messaging du volet Settings (Paramètres) de la console Firebase. L'ID d'expéditeur permet d'identifier chaque expéditeur pouvant envoyer des messages à l'application cliente. |
| Jeton d'accès | Jeton OAuth 2.0 de courte durée qui autorise les requêtes à l'API HTTP v1. Ce jeton est associé à un compte de service appartenant à votre projet Firebase. Pour créer et faire pivoter des jetons d'accès, suivez la procédure décrite dans Autoriser les demandes d'envoi. |
| Clé de serveur (pour les anciens protocoles **obsolètes**) | Clé de serveur qui autorise votre serveur d'application à accéder aux services Google, y compris à envoyer des messages via les anciens protocoles Firebase Cloud Messaging obsolètes. Important:N'incluez pas la clé du serveur dans le code client. Veillez également à n'utiliser que des clés de serveur pour autoriser votre serveur d'application. Les clés Android, de la plate-forme Apple et du navigateur sont rejetées par FCM. |