Firebase Cloud Messaging (FCM) offre une large gamme d'options et de fonctionnalités de messagerie. Les informations contenues dans 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 considérés comme des « messages d'affichage ». Ceux-ci sont gérés automatiquement par le SDK FCM.
- Messages de données, qui sont gérés par l'application client.
Les messages de notification contiennent un ensemble prédéfini de clés visibles par l'utilisateur. En revanche, les messages de données contiennent uniquement 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 000 octets, sauf lors de l'envoi de messages à partir de la console Firebase, qui impose une limite de 1 000 caractères.
| Utiliser le scénario | Comment envoyer | |
|---|---|---|
| Message de notification | Le SDK FCM affiche le message aux appareils des utilisateurs finaux au nom de l'application client lorsqu'elle 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 composée de paires clé-valeur personnalisées. |
|
| Message de données | L'application client est responsable du traitement des messages de données. Les messages de données n'ont que des paires clé-valeur personnalisées sans noms de clé réservés (voir ci-dessous). | Dans un environnement fiable tel que Cloud Functions ou votre serveur d'applications, utilisez le SDK Admin ou les protocoles de serveur FCM . Dans la demande d'envoi, définissez la clé data . |
Utilisez des messages de notification lorsque vous souhaitez que le SDK FCM gère automatiquement l'affichage d'une notification lorsque votre application s'exécute en arrière-plan. Utilisez des messages de données lorsque vous souhaitez traiter les messages avec votre propre code d'application client.
FCM peut envoyer un message de notification comprenant une charge utile de données facultative. Dans de tels cas, FCM gère l’affichage de la charge utile de notification et l’application client gère la charge utile des données.
Messages de notification
À des fins de test ou à des fins de marketing et de réengagement des utilisateurs, vous pouvez envoyer des messages de notification à l'aide de la console Firebase . La console Firebase fournit des tests A/B basés sur des analyses pour vous aider à affiner et à améliorer les messages marketing.
Pour envoyer des messages de notification par programme à 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. Par exemple, voici un message de notification au format JSON dans une application de messagerie instantanée. L'utilisateur peut s'attendre à voir un message avec le titre « 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 dans la barre de notification 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 les objets de notification du protocole HTTP v1 pour connaître la liste complète des clés prédéfinies disponibles pour la création de 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 client.
Par exemple, voici un message au format JSON dans la même application de messagerie instantanée que ci-dessus, où les informations sont encapsulées dans la clé data commune et où l'application cliente est censée 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 data de niveau supérieur ou commun, qui est interprété par les clients sur toutes les plates-formes qui reçoivent le message. Sur chaque plateforme, l'application client reçoit la charge utile des données dans une fonction de rappel.
Cryptage des messages de données
La couche de transport Android (voir Architecture FCM ) utilise le chiffrement point à point. En fonction de vos besoins, vous pouvez décider d'ajouter un cryptage de bout en bout aux messages de données. FCM ne fournit pas de solution de bout en bout. Il existe cependant des solutions externes disponibles telles que Capillary ou DTLS .
Messages de notification avec charge utile de données facultative
Que ce soit par programme ou via la console Firebase, vous pouvez envoyer des messages de notification contenant une charge utile facultative de paires clé-valeur personnalisées. Dans le composeur de notifications , utilisez les champs de données personnalisés dans les options avancées .
Le comportement de l'application lors de la réception de messages contenant à la fois des charges utiles de notification et de données dépend du fait que l'application se trouve en arrière-plan ou au premier plan, essentiellement 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 de notification et ne gèrent la charge utile de données que lorsque l'utilisateur appuie sur la notification.
- Lorsqu'elle est au premier plan , votre application reçoit un objet 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 toutes les plateformes
Le SDK Firebase Admin et le protocole HTTP FCM v1 permettent tous deux à vos demandes de message de définir tous les champs disponibles dans l'objet message . Ceci comprend:
- 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 offrent la possibilité de personnaliser les messages pour différentes plates-formes afin de garantir qu'ils sont traités correctement une fois reçus. Le backend FCM prendra en compte tous les paramètres spécifiés et personnalisera le message pour chaque plateforme.
Quand utiliser les champs communs
Utilisez les champs communs lorsque vous :
- Ciblage des instances d'application sur toutes les plateformes : Apple, Android et Web
- Envoi de messages vers des sujets
Toutes les instances d'application, quelle que soit la plate-forme, peuvent interpréter les champs communs suivants :
Quand utiliser les champs spécifiques à la plateforme
Utilisez des champs spécifiques à la plateforme lorsque vous souhaitez :
- Envoyer des champs uniquement à des plateformes particulières
- Envoyer des champs spécifiques à la plateforme en plus des champs communs
Chaque fois que vous souhaitez envoyer des valeurs uniquement à des plates-formes particulières, n'utilisez pas de champs communs ; utilisez des champs spécifiques à la plateforme. Par exemple, pour envoyer une notification uniquement aux plateformes Apple et au Web mais pas à Android, vous devez utiliser deux ensembles de champs distincts, un pour Apple et un pour le Web.
Lorsque vous envoyez des messages avec des options de livraison spécifiques, utilisez les champs spécifiques à la plateforme pour les définir. Vous pouvez spécifier différentes valeurs par plateforme si vous le souhaitez. Cependant, même si vous souhaitez définir essentiellement la même valeur sur toutes les plateformes, vous devez utiliser des champs spécifiques à la plateforme. En effet, chaque plate-forme peut interpréter la valeur légèrement différemment : par exemple, la durée de vie est définie sur Android comme un délai d'expiration en secondes, tandis que sur Apple, elle est définie comme une date d'expiration.
Exemple : message de notification avec des options de livraison spécifiques à la plateforme
La demande d'envoi v1 suivante envoie un titre et un contenu de notification communs à toutes les plates-formes, mais envoie également des remplacements spécifiques à la plate-forme. Concrètement, la demande :
- définit une longue durée de vie pour les plates-formes Android et Web, tout en définissant la priorité des messages APN (plates-formes Apple) sur un paramètre faible
- définit les touches appropriées pour définir le résultat d'un appui utilisateur sur la notification sur Android et Apple -
click_actioncategory, 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"
}
}
}
}Consultez la documentation de référence HTTP v1 pour obtenir des détails complets sur les clés disponibles dans les blocs spécifiques à la plate-forme dans le corps du message. Pour plus d'informations sur la création de demandes d'envoi contenant le corps du message, consultez Créer des demandes d'envoi .
Options de livraison
FCM fournit un ensemble spécifique d'options de livraison pour les messages envoyés aux appareils Android et permet des options similaires sur les plates-formes Apple et sur le Web. Par exemple, le comportement des messages « réductibles » est pris en charge sur Android via collapse_key de FCM, sur Apple via apns-collapse-id et sur JavaScript/Web via Topic . Pour plus de détails, consultez les descriptions dans 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 individuel est transmis à l'appareil. Un message non réductible fournit un contenu utile, par opposition à un message réductible tel qu'un « ping » sans contenu vers l'application mobile pour contacter le serveur afin de récupérer des données.
Certains cas d'utilisation typiques de messages non réductibles sont les messages de discussion ou les messages critiques. Par exemple, dans une application de messagerie instantanée, vous souhaiteriez transmettre chaque message, car chaque message a un contenu différent.
Pour Android, il existe une limite de 100 messages pouvant être stockés sans s'effondrer. 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 alors gérer la situation correctement, généralement en demandant une synchronisation complète au serveur d'application.
Un message réductible est un message qui peut être remplacé par un nouveau message s'il n'a pas encore été remis à l'appareil.
Un cas d'utilisation courant des messages réductibles est celui des messages utilisés pour indiquer à une application mobile de synchroniser les données du serveur. Un exemple serait une application sportive qui met à jour les utilisateurs avec le 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 d'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 à celles qui sont conservées.
Les messages de sujet sans charge utile sont réductibles par défaut. Les messages de notification sont toujours réductibles et ignoreront le paramètre collapse_key .
Lequel dois-je utiliser ?
Les messages pliables constituent un meilleur choix du point de vue des performances, à condition que votre application n'ait pas besoin d'utiliser des messages non pliables. Toutefois, si vous utilisez des messages réductibles, n'oubliez pas que FCM autorise uniquement l'utilisation d'un maximum de quatre clés de réduction différentes par jeton d'enregistrement à un moment donné. Vous ne devez pas dépasser ce nombre, sinon cela pourrait entraîner des conséquences imprévisibles.
| Utiliser le scénario | Comment envoyer | |
|---|---|---|
| Non pliable | Chaque message est important pour l'application client et doit être transmis. | À l'exception des messages de notification, tous les messages ne sont pas réductibles par défaut. |
| Pliant | Lorsqu’un message plus récent rend un message plus ancien et associé sans rapport avec l’application client, FCM remplace l’ancien message. Par exemple : des messages utilisés pour lancer une synchronisation de données depuis le serveur ou des messages de notification obsolètes. | Définissez le paramètre approprié dans votre demande de message :
|
Définir la priorité d'un message
Vous disposez de deux options pour attribuer une priorité de remise aux messages en aval : priorité normale et haute. Bien que le comportement diffère légèrement selon les plates-formes, la transmission des messages normaux et hautement prioritaires fonctionne comme ceci :
Priorité normale. Les messages de priorité normale sont délivrés immédiatement lorsque l'application est au premier plan. Pour les applications en arrière-plan, la livraison peut être retardée. Pour les messages moins urgents, tels que les notifications de nouveaux e-mails, la synchronisation de votre interface utilisateur ou la synchronisation des données d'application en arrière-plan, choisissez la priorité de livraison normale.
Haute priorité. FCM tente de transmettre immédiatement des messages hautement prioritaires, même si l'appareil est en mode Doze. Les messages hautement prioritaires sont destinés au contenu sensible au temps et visible par l'utilisateur.
Voici un exemple de message de priorité normale envoyé via le protocole FCM HTTP v1 pour informer un abonné à un magazine qu'un nouveau contenu est disponible au 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 plus de détails spécifiques à la plate-forme sur la définition de la priorité des messages :
- Documentation sur les APN
- Définir et gérer la priorité des messages (Android)
- Urgence des messages push Web
Définir la durée de vie d'un message
FCM délivre généralement les messages immédiatement après leur envoi. Cependant, cela n’est pas toujours possible. Par exemple, si la plate-forme est Android, l'appareil peut être éteint, hors ligne ou indisponible. Ou encore, FCM peut intentionnellement retarder les messages pour empêcher une application de consommer des ressources excessives et d'affecter négativement la durée de vie de la batterie.
Lorsque cela se produit, FCM stocke le message et le transmet dès que possible. Bien que cela convienne dans la plupart des cas, il existe certaines applications pour lesquelles un message tardif pourrait tout aussi bien ne jamais être envoyé. Par exemple, si le message est un appel entrant ou une notification de chat vidéo, il n'a de sens que pendant une courte période avant la fin de l'appel. Ou 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 préciser 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) et elle correspond à la période maximale pendant laquelle FCM stocke et tente de transmettre le message. Les demandes qui ne contiennent pas ce champ sont par défaut limitées à une période maximale de quatre semaines.
Voici quelques utilisations possibles de cette fonctionnalité :
- Chat vidéo appels entrants
- Événements sur invitation expirant
- Événements du calendrier
Un autre avantage de la spécification de la durée de vie d'un message est que FCM n'applique pas de limitation de message réductible aux messages dont la valeur de durée de vie est de 0 seconde. FCM assure une gestion optimale des messages qui doivent être livrés « maintenant ou jamais ». Gardez à l’esprit qu’une valeur time_to_live de 0 signifie que les messages qui ne peuvent pas être livrés immédiatement sont ignorés. Cependant, 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 le 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'applications 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é transmis à l'appareil. Cela signifie plutôt qu'il a été accepté pour la livraison. Ce qui arrive au message une fois accepté 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 aucune restriction de limitation, le message est transmis immédiatement.
Si l'appareil est connecté mais en mode Doze, un message de faible priorité est stocké par FCM jusqu'à ce que l'appareil soit hors de Doze. Et c'est là que l'indicateur 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 livraison, l'ancien message est supprimé et le nouveau message prend sa place (c'est-à-dire l'ancien le message est réduit par le nouveau). Cependant, si la clé de réduction n'est pas définie, les nouveaux et les 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 la clé de réduction). Lorsqu'une connexion est établie, FCM transmet tous les messages en attente à l'appareil. Si l'appareil n'est plus jamais connecté (par exemple, s'il a été réinitialisé aux paramètres d'usine), le message finit par expirer et est supprimé du stockage FCM. Le délai d'expiration par défaut est de quatre semaines, sauf si l'indicateur time_to_live est défini.
Pour avoir plus d’informations sur la livraison d’un message :
Pour obtenir plus d'informations sur la livraison 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 Applications Android.
Pour les appareils Android avec messagerie directe activée, si l'appareil ne s'est pas connecté à FCM depuis plus d'un mois, FCM accepte toujours le message mais le rejette 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 alors gérer la situation correctement, généralement en demandant une synchronisation complète au serveur d'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 tentatives ultérieures d’envoi d’un message à cet appareil entraînent une erreur NotRegistered .
Limitation et mise à l’échelle
Notre objectif est de toujours transmettre chaque message envoyé via FCM. Cependant, transmettre chaque message entraîne parfois une mauvaise expérience utilisateur globale. Dans d'autres cas, nous devons définir des limites pour garantir que FCM fournit un service évolutif à tous les expéditeurs.
Limitation des messages pliables
Comme décrit ci-dessus, les messages pliables sont des notifications sans contenu conçues pour se superposer les unes sur les autres. Dans le cas où un développeur répète trop fréquemment le même message à une application, nous retardons (limitons) les messages pour réduire l'impact sur la batterie d'un utilisateur.
Par exemple, si vous envoyez un grand nombre de nouvelles demandes de synchronisation d'e-mails à un seul appareil, nous pouvons retarder la prochaine demande de synchronisation d'e-mails de quelques minutes afin que l'appareil puisse se synchroniser à un rythme moyen inférieur. Cette limitation est effectuée strictement pour limiter l’impact de la batterie subi par l’utilisateur.
Si votre cas d'utilisation nécessite des modèles d'envoi en rafale élevés, les messages non pliables peuvent être le bon choix. Pour de tels messages, assurez-vous d'inclure le contenu dans ces messages afin de réduire le coût de la batterie.
Nous limitons les messages pliables à une rafale de 20 messages par application et par appareil, avec une recharge de 1 message toutes les 3 minutes.
Limitation du serveur XMPP
Nous limitons le débit auquel vous pouvez vous connecter aux serveurs FCM XMPP à 400 connexions par minute et par projet. Cela ne devrait pas poser de problème pour la transmission des messages, mais c'est important pour garantir la stabilité du système. Pour chaque projet, FCM autorise 2500 connexions en parallèle.
Pour la messagerie en amont avec XMPP, FCM limite les messages en amont à 1 500 000/minute par projet pour éviter de surcharger les serveurs de destination en amont.
Nous limitons les messages en amont par appareil à 1 000/minute pour protéger contre l'épuisement de la batterie dû au mauvais comportement des applications.
Débit de messages maximum vers un seul appareil
Pour Android, vous pouvez envoyer jusqu'à 240 messages/minute et 5 000 messages/heure vers un seul appareil. Ce seuil élevé est destiné à permettre des pics de trafic à court terme, par exemple lorsque les utilisateurs interagissent rapidement via le chat. Cette limite empêche les erreurs d'envoi de la logique de vider par inadvertance la batterie d'un appareil.
Pour iOS, nous renvoyons une erreur lorsque le débit dépasse les limites des APN.
Limite de messages du sujet
Le taux d'ajout/suppression d'abonnement à un sujet est limité à 3 000 QPS par projet.
Pour connaître les tarifs d’envoi de messages, consultez Fanout Throttling .
Limitation de la diffusion
La diffusion du message est le processus d'envoi d'un message à plusieurs appareils, par exemple lorsque vous ciblez des sujets et des groupes, ou lorsque vous utilisez l' éditeur de notifications pour cibler des audiences ou des segments d'utilisateurs.
La diffusion des messages n'est pas instantanée et il arrive donc parfois que plusieurs diffusions soient en cours simultanément. Nous limitons le nombre de diffusions de messages simultanées par projet à 1 000. Après cela, nous pouvons rejeter des demandes de diffusion supplémentaires ou différer la diffusion des demandes jusqu'à ce que certaines des diffusions déjà en cours soient terminées.
Le taux de diffusion réel réalisable est influencé par le nombre de projets demandant des diffusions en même temps. Un taux de diffusion de 10 000 QPS pour un projet individuel n'est pas rare, mais ce chiffre n'est pas une garantie et résulte de la charge totale du système. Il est important de noter que la capacité de diffusion disponible est répartie entre les projets et non entre les demandes de diffusion. Ainsi, si votre projet a deux diffusions en cours, chaque diffusion ne verra que la moitié du taux de diffusion disponible. La méthode recommandée pour maximiser la vitesse de votre diffusion consiste à n’avoir qu’une seule diffusion active en cours à la fois.
Ports FCM et votre pare-feu
Si votre organisation dispose d'un pare-feu pour restreindre le trafic vers ou depuis Internet, vous devez le configurer pour autoriser les appareils mobiles à se connecter à FCM afin que les appareils de votre réseau reçoivent des messages. FCM utilise généralement le port 5228, mais il utilise parfois 443, 5229 et 5230.
Pour les appareils se connectant à 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 pourraient devenir obsolètes, ce qui aurait un impact sur l'expérience de vos utilisateurs. Idéalement, ajoutez les ports 5228 à 5230 et 443 sans aucune restriction IP. Cependant, si vous devez avoir une restriction IP, vous devez autoriser toutes les adresses IP répertoriées dans goog.json . Cette grande liste est mise à jour régulièrement et il vous est recommandé de mettre à jour vos règles sur une base mensuelle. Les problèmes causés par les restrictions IP du pare-feu sont souvent intermittents et difficiles à diagnostiquer.
Nous proposons un ensemble de noms de domaine qui peuvent être ajoutés à la liste blanche à la place des adresses IP. Ces noms d'hôtes sont répertoriés ci-dessous. Si nous commençons à utiliser des noms d'hôtes supplémentaires, nous mettrons à jour la liste ici. L'utilisation de noms de domaine pour votre règle de pare-feu peut être fonctionnelle ou non sur votre périphérique de pare-feu.
Ports TCP à ouvrir :
- 5228
- 5229
- 5230
- 443
Noms d'hôtes à 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
- appareil-provisioning.googleapis.com
- firebaseinstallations.googleapis.com
Pare-feu de traduction d’adresses réseau et/ou d’inspection de paquets avec état :
Si votre réseau implémente la traduction d'adresses réseau (NAT) ou l'inspection des paquets avec état (SPI), implémentez un délai d'attente de 30 minutes ou plus pour nos connexions sur 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 VPN et contournement
Firebase Cloud Messaging prend diverses mesures pour garantir 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 cet effort.
Les VPN masquent les informations sous-jacentes dont FCM a besoin pour régler sa connexion afin de maximiser la fiabilité et la durée de vie de la batterie. Dans certains cas, les VPN interrompent 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'un coût élevé de la batterie. Lorsque le VPN est configuré pour nous permettre de le faire, nous contournons le VPN en utilisant une connexion cryptée (sur le réseau de base wifi ou LTE) afin de garantir une expérience fiable et respectueuse de la batterie. L'utilisation par FCM de VPN contournables est spécifique au canal de notification push FCM. L'autre trafic FCM, 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 offrir, tels que le masquage IP.
Différents VPN auront différentes méthodes pour contrôler s'il peut ou non être contourné. Consultez la documentation de votre VPN spécifique pour obtenir des instructions.
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 pendant lesquelles les messages sont retardés et entraîner une utilisation accrue de la batterie, car Cloud Messaging s'efforce de maintenir la connexion via la connexion VPN.
Informations d'identification
Selon les fonctionnalités FCM que vous implémentez, vous aurez peut-être besoin des informations d'identification suivantes de votre projet Firebase :
| ID du projet | Un identifiant unique pour votre projet Firebase, utilisé dans les requêtes adressées au point de terminaison HTTP FCM v1. Cette valeur est disponible dans le volet Paramètres de la console Firebase . |
| Jeton d'enregistrement | Chaîne de jeton unique qui identifie chaque instance d'application client. Le jeton d’enregistrement est requis pour la messagerie sur un seul appareil et sur un groupe d’appareils. Notez que les jetons d’enregistrement doivent être gardés secrets. |
| ID de l'expéditeur | Une valeur numérique unique créée lorsque vous créez votre projet Firebase, disponible dans l'onglet Cloud Messaging du volet Paramètres de la console Firebase. L'ID de l'expéditeur est utilisé pour identifier chaque expéditeur pouvant envoyer des messages à l'application client. |
| Jeton d'accès | Un jeton OAuth 2.0 de courte durée qui autorise les requêtes vers 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 les étapes décrites dans Autoriser les demandes d'envoi . |
| Clé de serveur (pour les anciens protocoles **obsolètes**) | Une clé de serveur qui autorise votre serveur d'applications à accéder aux services Google, y compris l'envoi de messages via les anciens protocoles obsolètes de Firebase Cloud Messaging. Important : N'incluez la clé du serveur nulle part dans votre code client. Assurez-vous également d'utiliser uniquement les clés du serveur pour autoriser votre serveur d'applications. Les clés Android, Apple et du navigateur sont rejetées par FCM. |