Firebase Cloud Messaging (FCM) offre 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 à afficher". Le SDK FCM gère automatiquement ces modifications.
- Messages de données, qui sont gérés par l'application cliente.
Les messages de notification contiennent un ensemble prédéfini de clés visibles par l'utilisateur. Les messages de données, en revanche, 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.
| Utiliser le scénario | Comment envoyer | |
|---|---|---|
| Message de notification | Le SDK FCM affiche le message sur les appareils des utilisateurs finaux au nom de l'application cliente 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 de paires clé/valeur personnalisées. |
|
| Message data | L'application cliente est responsable du traitement des messages de données. Les messages de données ne contiennent que des paires clé-valeur personnalisées sans nom de clé réservé (voir ci-dessous). | Dans un environnement approuvé tel que
Cloud Functions ou votre serveur d'applications, utilisez le SDK Admin ou les protocoles 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 le code de votre propre application cliente.
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, tandis que l'application cliente gère la charge utile des données.
Messages de notification
À des fins de test, 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 de manière programmatique à l'aide du SDK Admin ou des protocoles FCM, définissez la clé notification avec l'ensemble prédéfini d'options de clé-valeur nécessaire pour la partie du message de notification visible par l'utilisateur. Voici par exemple un message de notification au format JSON dans une application de messagerie instantanée. L'utilisateur peut s'attendre à voir un message intitulé "Portugal vs Danemark" avec le texte "Excellente correspondance !" sur l'appareil:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}
Les messages de notification sont transmis dans la barre de notification lorsque l'application est exécutée en arrière-plan. Pour les applications exécutées au premier plan, les messages sont traité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 la création 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.
Voici un exemple de 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 illustre l'utilisation du champ data commun, ou de premier niveau, 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 des données dans une fonction de rappel.
Chiffrement des messages de données
La couche de transport Android (voir l'architecture FCM) utilise le chiffrement point à point. Selon vos besoins, vous pouvez décider d'ajouter le chiffrement de bout en bout aux messages de données. FCM ne fournit pas de solution de bout en bout. Cependant, il existe des solutions externes telles que Capillary ou DTLS.
Messages de notification avec charge utile de données facultative
De manière automatisée ou via la console Firebase, vous pouvez envoyer des messages de notification contenant une charge utile facultative de paires clé/valeur personnalisées. Dans l' outil de rédaction des notifications, utilisez les champs Données personnalisées de la section Options avancées.
Le comportement de l'application lors de la réception de messages qui incluent à la fois des charges utiles de notification et de données varie selon qu'elle est exécutée en arrière-plan ou au premier plan, qu'elle soit essentiellement 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.
- 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"
}
}
}
Personnalisation d'un message sur différentes plates-formes
Le SDK Admin Firebase et le protocole HTTP FCM v1 permettent tous deux à vos requêtes de message 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 gérés correctement une fois reçus. Le backend FCM tient compte de tous les paramètres spécifiés et personnalise le message pour chaque plate-forme.
Quand utiliser des champs courants ?
Utilisez des champs courants dans les cas suivants:
- Ciblage des 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 communs suivants:
Quand utiliser des champs spécifiques à une plate-forme ?
Utilisez des champs spécifiques à la plate-forme pour:
- 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 n'envoyer des valeurs qu'à des plates-formes spécifiques, n'utilisez pas de champs communs. Utilisez plutôt 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, un pour Apple et un pour le Web.
Lorsque vous envoyez des messages comportant des options de distribution spécifiques, définissez-les à l'aide de champs spécifiques à la plate-forme. Si vous le souhaitez, vous pouvez spécifier différentes valeurs 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 à celle-ci. En effet, chaque plate-forme peut interpréter cette valeur légèrement différemment. Par exemple, la valeur TTL 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 distribution spécifiques à la plate-forme
La requête d'envoi v1 suivante envoie un titre et du contenu de notification communs à toutes les plates-formes, mais envoie également des forçages spécifiques à la plate-forme. Plus précisément, la requête:
- définit une valeur TTL longue pour les plates-formes Android et Web, tout en définissant la priorité du message APNs (plates-formes Apple) sur une valeur faible
- définit les touches appropriées pour déterminer le résultat de l'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"
}
}
}
}
Consultez la documentation de référence HTTP v1 pour en savoir plus sur les clés disponibles dans les blocs spécifiques à la plate-forme du corps du message. Pour en savoir plus sur la création de requêtes d'envoi contenant le corps d'un message, consultez la section Créer des requêtes d'envoi.
Options de livraison
FCM fournit un ensemble spécifique d'options de distribution 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 de message "réductible" est pris en charge sur Android via collapse_key de FCM, sur Apple via apns-collapse-id et sur 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 non réductibles
Un message non réductible indique que chaque message individuel est distribué à l'appareil. Un message non réductible envoie un contenu utile, par opposition à un message réductible tel qu'un "ping" sans contenu à l'application mobile pour contacter le serveur afin d'extraire les données.
Les messages non réductibles sont les messages de chat ou les messages critiques. Par exemple, dans une application de messagerie instantanée, vous souhaitez distribuer chaque message, car chaque message a un contenu différent.
Pour Android, le nombre de messages pouvant être stockés sans être réduits est limité à 100. 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 la situation correctement, généralement en demandant une synchronisation complète à partir du serveur d'applications.
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 souvent utilisés pour indiquer à une application mobile de synchroniser les données du serveur. Prenons l'exemple d'une application de sport qui fournit aux utilisateurs les derniers scores. 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 de 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, et vous ne pouvez pas garantir qu'elles seront conservées.
Les messages de sujet sans charge utile peuvent être réduits par défaut. Les messages de notification sont toujours réductibles et ignorent le paramètre collapse_key.
Lequel dois-je utiliser ?
Les messages réductibles sont un meilleur choix du 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 l'utilisation par FCM que de quatre clés de réduction différentes à la fois par jeton d'enregistrement. Vous ne devez pas dépasser ce nombre, car cela pourrait avoir des conséquences imprévisibles.
| Utiliser le scénario | Comment envoyer | |
|---|---|---|
| Non réductible | Chaque message est important pour l'application cliente et doit être distribué. | À l'exception des messages de notification, tous les messages ne sont pas réductibles par défaut. |
| Pliables | Lorsqu'un message plus récent affiche un message associé plus ancien qui n'est pas pertinent pour l'application cliente, FCM le remplace. 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 invitation à discuter :
|
Définir la priorité d'un message
Vous avez deux options pour attribuer une priorité de distribution aux messages en aval : une priorité normale et une priorité élevée. Bien que le comportement diffère légèrement selon les plates-formes, la distribution des messages de priorité normale et élevée fonctionne comme suit:
Priorité normale. Les messages à priorité normale sont distribués immédiatement lorsque l'application est exécutée au premier plan. Pour les applications en arrière-plan, la distribution peut être retardée. Pour les messages moins urgents, tels que les notifications de nouveaux e-mails, la synchronisation de votre UI ou la synchronisation des données d'application en arrière-plan, choisissez une priorité de distribution normale.
Priorité élevée FCM tente de distribuer immédiatement les messages à priorité élevée, même si l'appareil est en mode Sommeil. Les messages à priorité élevée concernent des contenus visibles par l'utilisateur et limités dans le temps.
Voici un exemple de message prioritaire normal envoyé via le protocole HTTP v1 de FCM pour avertir 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 obtenir des informations plus détaillées sur la définition de la priorité des messages selon les plates-formes:
- Documentation APNs
- 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 distribue généralement les messages immédiatement après leur envoi. Toutefois, cela 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 éviter qu'une application ne consomme trop de ressources et affecte négativement l'autonomie de la batterie.
Dans ce cas, FCM stocke le message et le distribue dès que possible. Bien que cela ne pose pas de problème dans la plupart des cas, il arrive qu'un message en retard ne soit jamais distribué pour certaines applications. 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. 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 sur le Web/JavaScript, vous pouvez spécifier la durée de vie maximale d'un message. Cette valeur doit être une durée comprise entre 0 et 2 419 200 secondes (28 jours) et 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 entrants du chat vidéo
- Événements d'invitation arrivant à expiration
- Événements d'agenda
Spécifier la durée de vie d'un message présente un autre avantage : FCM n'applique pas de limitation des messages réductibles aux messages dont la valeur TTL est de 0 seconde.
FCM permet de traiter au mieux les messages qui doivent être distribués "maintenant ou jamais". N'oubliez pas qu'une valeur time_to_live égale à 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 une latence optimale pour l'envoi des messages de notification.
Voici un exemple de requête qui inclut une valeur 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é distribué à l'appareil. Il indique plutôt qu'il a été accepté pour la livraison. Le traitement du 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 pas de limitation de bande passante, le message est immédiatement distribué.
Si l'appareil est connecté, mais qu'il est 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 l'indicateur collapse_key joue un rôle: si un message contenant la même clé de réduction (et le même jeton d'enregistrement) est déjà stocké et en attente de distribution, l'ancien message est supprimé et le nouveau remplace (c'est-à-dire que l'ancien est réduit par le nouveau). Toutefois, si la clé de réduction n'est pas définie, les nouveaux et les anciens messages sont stockés pour une distribution ultérieure.
Si l'appareil n'est pas connecté à FCM, le message est stocké jusqu'à ce qu'une connexion soit établie (en respectant les règles de clé de réduction). Lorsqu'une connexion est établie, FCM distribue tous les messages en attente à l'appareil. Si l'appareil ne se connecte plus jamais (par exemple, si la configuration d'usine a été rétablie), le message finit par expirer et est supprimé de l'espace de stockage FCM. Le délai avant expiration par défaut est de quatre semaines, sauf si l'option time_to_live est définie.
Pour obtenir plus d'informations 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 des rapports FCM, qui enregistre le nombre de messages envoyés et ouverts sur des 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 sur lesquels la messagerie par canal direct est activée, si l'appareil ne s'est pas connecté à FCM depuis plus d'un mois, FCM accepte toujours le message, mais le supprime 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 la situation correctement, généralement en demandant une synchronisation complète à partir du serveur d'applications.
Enfin, lorsque FCM tente de distribuer un message sur l'appareil et que l'application a été désinstallée, FCM supprime ce message immédiatement et invalide le jeton d'enregistrement. Les tentatives futures d'envoi d'un message à cet appareil généreront une erreur NotRegistered.
Limitation et scaling
Notre objectif est de toujours transmettre tous les messages envoyés via FCM. Cependant, la distribution de chaque message peut parfois nuire à l'expérience utilisateur globale. Dans d'autres cas, nous devons définir des limites pour nous assurer que FCM fournit un service évolutif à tous les expéditeurs.
Limitation de la diffusion des messages
Comme décrit ci-dessus, les messages réductibles sont des notifications sans contenu conçues pour se replier les unes sur les autres. Si un développeur répète trop souvent le même message dans une application, nous retardons (limitons) les messages afin de 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 des e-mails de quelques minutes afin que l'appareil puisse se synchroniser à un taux moyen inférieur. Cette limitation est strictement effectuée dans le but de limiter l'impact sur la batterie subi par l'utilisateur.
Si votre cas d'utilisation nécessite des modèles d'envoi en rafale élevée, les messages non réductibles peuvent être le bon choix. Veillez à inclure le contenu de ces messages afin de réduire l'utilisation de la batterie.
Nous limitons les messages réductibles à une rafale de 20 messages par application et par appareil, avec un nouveau remplissage d'un message toutes les trois minutes.
Limitation du serveur XMPP
Nous limitons la fréquence à laquelle vous pouvez vous connecter aux serveurs XMPP FCM à 400 connexions par minute et par projet. Cela ne devrait pas poser problème pour la distribution des messages, mais il est important pour 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/minute pour éviter la décharge de la batterie due à un comportement inapproprié des applications.
Taux maximal de messages sur un seul appareil
Pour Android, vous pouvez envoyer jusqu'à 240 messages/minute et 5 000 messages/heure à un seul appareil. Ce seuil élevé est conçu pour permettre des pics de trafic à court terme, par exemple lorsque les utilisateurs interagissent rapidement par chat. Cette limite empêche que les erreurs de logique d'envoi ne déchargent par inadvertance la batterie d'un appareil.
Pour iOS, nous renvoyons une erreur lorsque le taux dépasse les limites du service APNs.
Limite de messages par sujet
Le taux d'ajout/de suppression d'abonnement à un sujet est limité à 3 000 RPS par projet.
Pour connaître les taux d'envoi de messages, consultez Fanout Throttling.
Limitation de la distribution
La distribution ramifiée des messages consiste à envoyer un message à plusieurs appareils, par exemple lorsque vous ciblez des sujets et des groupes, ou lorsque vous utilisez le générateur de notifications pour cibler des audiences ou des segments d'utilisateurs.
La distribution ramifiée des messages n'est pas instantanée. Il peut donc arriver que plusieurs distributions soient en cours simultanément. Nous limitons le nombre de distributions simultanées de messages par projet à 1 000. Après cette date, nous pouvons rejeter d'autres demandes de distribution ramifiée ou reporter leur distribution jusqu'à ce que certaines des demandes déjà en cours soient terminées.
Le taux de distribution ramifiée réel réalisable est influencé par le nombre de projets nécessitant une distribution ramifiée en même temps. Un taux de distribution ramifiée de 10 000 RPS pour un projet individuel n'est pas rare, mais ce nombre n'est pas une garantie et résulte de la charge totale sur le système. Il est important de noter que la capacité de distribution ramifiée disponible est répartie entre les projets et non entre les requêtes de distribution ramifiée. Ainsi, si votre projet comporte deux fans en cours, chacune ne verra que la moitié du taux de distribution disponible. La méthode recommandée pour maximiser la vitesse de ramification consiste à n'avoir qu'une seule distribution active à la fois.
Ports FCM et votre pare-feu
Si votre organisation dispose d'un pare-feu pour limiter 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 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 pourraient devenir obsolètes, ce qui nuit à l'expérience utilisateur. Idéalement, ajoutez à la liste d'autorisation les ports 5228 à 5230 et 443 sans restriction d'adresse IP. Toutefois, si vous devez disposer d'une restriction d'adresse IP, vous devez ajouter à la liste d'autorisation toutes les adresses IP répertoriées dans goog.json. Cette longue liste est mise à jour régulièrement, et il est recommandé de mettre à jour vos règles chaque mois. Les problèmes causés par les restrictions d'adresse IP de pare-feu sont souvent intermittents et difficiles à diagnostiquer.
Nous proposons un ensemble de noms de domaine qui peuvent être ajoutés à la liste d'autorisation à la place des adresses IP. Ces noms d'hôte sont énumérés ci-dessous. Si nous commençons à utiliser des noms d'hôte supplémentaires, nous mettrons à jour la liste ici. L'utilisation de noms de domaine pour votre règle de pare-feu peut fonctionner ou non sur votre périphérique 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'adresses réseau et/ou d'inspection de paquets avec état:
Si votre réseau met en œuvre la traduction d'adresses réseau (NAT) ou l'inspection des paquets avec état (SPI), définissez un délai avant expiration 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 l'utilisation de la batterie des appareils mobiles de vos utilisateurs.
Interactions VPN et contournement
Firebase Cloud Messaging prend différentes étapes 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 ajuster sa connexion afin de maximiser la fiabilité et l'autonomie de la batterie. Dans certains cas, les VPN rompent activement les connexions à longue durée de vie, ce qui nuit à l'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 le contournons à l'aide d'une connexion chiffrée (via le réseau Wi-Fi ou LTE de base) afin de garantir une expérience fiable et économe en batterie. L'utilisation par FCM des VPN contournables est spécifique au canal de notification push FCM. Le reste du 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 qu'il peut offrir, tels que le masquage des adresses IP.
Les méthodes de contrôle de la capacité de contournement des VPN varient selon les VPN. Pour savoir comment procéder, consultez la documentation de votre VPN.
Si le VPN n'est pas configuré de manière à pouvoir être contourné, Firebase Cloud Messaging utilisera le réseau VPN pour se connecter au serveur. Cela peut entraîner des retards d'envoi des messages pendant des périodes et une utilisation plus importante de la batterie, car Cloud Messaging s'efforce de maintenir la connexion sur la connexion VPN.
Certificats
Selon les fonctionnalités FCM que vous implémentez, vous aurez peut-être besoin des identifiants suivants provenant de votre projet Firebase:
| ID du projet | Identifiant unique de votre projet Firebase, utilisé dans les requêtes envoyées au point de terminaison HTTP de 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 cliente. Le jeton d'enregistrement est requis pour les messages sur un seul appareil et sur un seul groupe d'appareils. Notez que les jetons d'enregistrement doivent rester secrets. |
| ID d'expéditeur | 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 permet d'identifier chaque expéditeur autorisé à envoyer des messages à l'application cliente. |
| Jeton d'accès | 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 alterner des jetons d'accès, suivez la procédure décrite dans Autoriser les requêtes 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 à envoyer des messages via les anciens protocoles obsolètes de Firebase Cloud Messaging. Important:N'incluez la clé de serveur nulle part dans le code client. Veillez également à n'utiliser que des clés de serveur pour autoriser votre serveur d'applications. Les clés Android, de plate-forme Apple et de navigateur sont refusées par FCM. |