À propos des messages FCM

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 d'affichage". Elles sont gérées automatiquement par le SDK FCM.
• 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 les paires clé-valeur personnalisées que vous avez définies. 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 lorsque vous envoyez des messages depuis la console Firebase, qui impose une limite de 1 000 caractères.

Utilisez des messages de notification lorsque vous souhaitez que le SDK FCM gère l'affichage d'une notification automatiquement 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 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, et l'application cliente gère la charge utile de données.

Messages de notification

Pour les tests, le marketing ou le 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 des 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. 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 vs. 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 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 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 messagerie instantanée que ci-dessus, où les informations sont encapsulées dans la clé data courante 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 premier niveau ou 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 de transport Android (voir l'architecture FCM) utilise le chiffrement de bout en bout. 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, il existe des solutions externes telles que Capillary ou DTLS.

Messages de notification avec charge utile de données facultative

Que ce soit de manière programmatique 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 compositeur de notifications, utilisez les champs Données personnalisées dans Options avancées.

Le comportement de l'application lorsqu'elle reçoit des messages incluant 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 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 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 v1 de Firebase Admin SDK et FCM vous permet tous deux de définir tous les champs disponibles dans l'objet message pour vos requêtes de messages. Par exemple :

• un ensemble commun de champs à interpréter par toutes les instances d'application qui reçoivent le message.
• des ensembles de champs spécifiques à la plate-forme, tels que AndroidConfig et WebpushConfig, interprétés uniquement par les instances d'application s'exécutant sur la plate-forme spécifiée.

Les blocs spécifiques à une plate-forme vous permettent de personnaliser les messages pour différentes plates-formes afin de vous assurer qu'ils sont traités correctement lorsqu'ils sont reçus. Le backend FCM prendra en compte tous les paramètres spécifiés et personnalisera le message pour chaque plate-forme.

Quand utiliser les champs communs

Utilisez les champs courants lorsque vous :

• Cibler les instances d'application sur toutes les plates-formes (Apple, Android et Web)
• Envoyer des messages à des thèmes

Toutes les instances d'application, quelle que soit la plate-forme, peuvent interpréter les champs communs suivants :

• message.notification.title
• message.notification.body
• message.data

Quand utiliser des champs spécifiques à une plate-forme

Utilisez les champs spécifiques à la plate-forme lorsque vous souhaitez :

• Envoyer des champs uniquement à certaines plates-formes
• Envoyer des champs spécifiques à la plate-forme en plus des champs communs

Si vous souhaitez envoyer des valeurs uniquement à des plates-formes spécifiques, n'utilisez pas les champs communs, mais les 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 une valeur pratiquement identique sur toutes les plates-formes, vous devez utiliser des champs spécifiques à chaque plate-forme. En effet, chaque plate-forme peut interpréter la valeur légèrement différemment. Par exemple, le délai avant expiration est défini sur Android comme une heure d'expiration en secondes, tandis que sur Apple, il est défini 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 un contenu de notification communs à toutes les plates-formes, mais envoie également des remplacements spécifiques à certaines plates-formes. Plus précisément, 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 APNs (plates-formes Apple) sur un paramètre 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_action et category, 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 informations détaillées sur les clés disponibles dans les blocs spécifiques à la plate-forme dans le corps du message. Pour en savoir plus sur la création de requêtes d'envoi contenant le corps du message, consultez Créer des requêtes d'envoi.

Options de livraison

FCM fournit un ensemble spécifique d'options de remise pour les messages envoyés aux appareils Android, et permet d'utiliser 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 individuel 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 contacter le serveur et récupérer des données.

Les messages non réductibles sont généralement des messages de chat ou des messages critiques. Par exemple, dans une application de messagerie instantanée, vous souhaitez distribuer chaque message, car chacun d'eux contient un contenu différent.

Pour Android, vous pouvez stocker jusqu'à 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 alors gérer la situation de manière appropriée, généralement en demandant une synchronisation complète au 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é remis à l'appareil.

Les messages réductibles sont souvent utilisés pour indiquer à une application mobile de synchroniser les données du serveur. Par exemple, une application sportive qui informe les utilisateurs des 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 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 à celles qui seront 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 du point de vue des performances, à condition que votre application n'ait pas besoin d'utiliser des 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 à tout moment. Vous ne devez pas dépasser ce nombre, car cela pourrait avoir des conséquences imprévisibles.

Définir la priorité d'un message

Vous avez deux options pour attribuer une priorité de diffusion aux messages en aval : normale et élevée. Bien que le comportement diffère légèrement selon les plates-formes, la diffusion 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 au premier plan. Pour les applications mises en arrière-plan, la diffusion peut être retardée. Pour les messages moins urgents, comme 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 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 sont destinés au contenu urgent et visible par l'utilisateur.

Voici un exemple de message à priorité normale envoyé via le protocole HTTP v1 FCM pour informer un abonné à un magazine que de nouveaux contenus sont disponibles 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 en savoir plus sur la définition de la priorité des messages sur des plates-formes spécifiques :

• Documentation APNs
• Définir et gérer la priorité des messages (Android)
• Urgence des messages push Web

Cas d'utilisation critiques pour la vie

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 pourrait entraîner la perte de vies humaines, des préjudices corporels ou des dommages à l'environnement (comme l'exploitation d'installations nucléaires, le contrôle du trafic aérien ou l'utilisation d'équipements de survie). 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 gestion de la conformité de votre application avec les Conditions d'utilisation et de tout dommage résultant de votre non-respect. Google fournit les API "telles quelles" et se réserve le droit d'interrompre les API ou toute partie ou fonctionnalité de celles-ci, ou encore de suspendre votre accès à celles-ci, pour quelque raison que ce soit et à tout moment, sans responsabilité ni autre 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. Toutefois, cela n'est pas toujours possible. Par exemple, si la plate-forme est Android, l'appareil peut être éteint, hors connexion ou indisponible. Ou FCM peut intentionnellement retarder 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 ne pose pas de problème dans la plupart des cas, il existe des applications pour lesquelles un message tardif peut tout aussi bien ne jamais être distribué. Par exemple, si le message est une notification d'appel entrant ou de chat vidéo, il n'est pertinent que pendant une courte période avant la fin de l'appel. De même, 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 le message et tente de le distribuer. Les demandes 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

Un autre avantage de la spécification de la durée de vie d'un message est que FCM n'applique pas la limitation des messages réductibles aux messages dont la durée de vie est de 0 seconde. FCM fournit la meilleure gestion possible des messages qui doivent être distribués "tout de suite 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 qui inclut 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'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. Le sort 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 aucune restriction de limitation du débit, le message est envoyé immédiatement.

Si l'appareil est connecté, mais en mode Sommeil, un message de faible priorité est stocké par FCM jusqu'à ce que l'appareil quitte le mode Sommeil. C'est là que l'indicateur collapse_key entre en jeu : 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 distribution, l'ancien message est supprimé et le nouveau le remplace (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 messages ancien et nouveau 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 envoie tous les messages en attente à l'appareil. Si l'appareil ne se reconnecte jamais (par exemple, s'il a été réinitialisé), le message finit par expirer et est supprimé du 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 diffusion des messages sur les plates-formes Android ou Apple, consultez le tableau de bord des rapports FCM. Il 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 sur lesquels la messagerie directe des chaînes 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 alors gérer la situation de manière appropriée, généralement en demandant une synchronisation complète au serveur d'applications.

Enfin, lorsque FCM tente de distribuer 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. Toute tentative ultérieure d'envoi d'un message à cet appareil générera une erreur NotRegistered.

Limitation et quotas

Notre objectif est de toujours distribuer tous les messages envoyés via FCM. Toutefois, l'envoi de chaque message peut parfois entraîner 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 à tous les expéditeurs. Les types de limites et de quotas décrits dans cette section nous aident à équilibrer ces facteurs importants.

Limitation du nombre de 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 avec des pics d'utilisation.

Les pics de trafic peuvent entraîner des erreurs de dépassement de 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 rechargé la minute suivante. Des réponses 429 peuvent également être renvoyées en cas de surcharge. Nous vous encourageons donc vivement à 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 erreurs 429).
• Les quotas sont définis à la minute, mais ces minutes ne sont pas alignées sur l'heure.

Quota de surveillance

Vous pouvez consulter les quotas, l'utilisation et les erreurs dans la console Google Cloud :

1. Accéder à la console Google Cloud
2. Sélectionnez API et services.
3. Dans la liste des tables, sélectionnez API Firebase Cloud Messaging.
4. Sélectionnez QUOTAS ET LIMITES DU SYSTÈME.

REMARQUE : Ces graphiques ne sont pas précisément alignés sur les minutes de quota. Cela signifie que des erreurs 429 peuvent être générées lorsque le trafic semble être inférieur au quota.

Demander une augmentation de quota

Avant de demander une augmentation de quota, assurez-vous que :

• Votre utilisation est régulièrement supérieure ou égale à 80 % du quota pendant au moins cinq minutes consécutives par jour.
• Votre taux d'erreurs client est inférieur à 5 %, en particulier lors des pics de trafic.
• Vous respectez les bonnes pratiques pour l'envoi de messages à grande échelle.

Si vous remplissez ces critères, vous pouvez demander une augmentation de quota de 25 % maximum. FCM fera tout son possible pour répondre à votre demande (aucune augmentation ne peut être garantie).

Si vous avez besoin d'un quota de messages en aval plus important 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 votre demande. Pour les demandes importantes (> 18 millions de messages par minute), un préavis d'au moins 30 jours est requis. Les demandes de lancement et d'événements spéciaux restent soumises aux exigences concernant le taux d'erreurs côté client et les bonnes pratiques.

Consultez également les questions fréquentes sur les quotas FCM.

Limite de messages par sujet

Le taux d'ajout/de suppression d'abonnements à des thèmes est limité à 3 000 RPS par projet.

Pour connaître les taux d'envoi de messages, consultez Limitation du nombre de messages envoyés.

Limitation de la distribution ramifiée

La diffusion de messages est le processus d'envoi d'un message à plusieurs appareils, par exemple lorsque vous ciblez des thèmes et des groupes, ou lorsque vous utilisez le compositeur de notifications pour cibler des audiences ou des segments d'utilisateurs.

La diffusion des messages n'est pas instantanée. Il arrive donc que plusieurs diffusions soient en cours simultanément. Nous limitons le nombre de distributions de messages simultanées par projet à 1 000. Après cela, nous pouvons refuser les 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 distribution de 10 000 RPS pour un projet individuel n'est pas rare, mais ce nombre n'est pas garanti 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. Par conséquent, si deux fan-outs sont en cours dans votre projet, chacun d'eux ne verra que la moitié du taux de fan-out disponible. Pour maximiser la vitesse de diffusion, nous vous recommandons de n'avoir qu'une seule diffusion active à la fois.

Limitation des 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 le même message trop souvent dans une application, nous retardons (limitons) les messages pour réduire l'impact sur la batterie de l'utilisateur.

Par exemple, si vous envoyez un grand nombre de nouvelles demandes de synchronisation d'e-mails à un même appareil, nous pouvons retarder la prochaine demande de synchronisation d'e-mails de quelques minutes afin que l'appareil puisse se synchroniser à un taux moyen plus faible. Cette limitation est effectuée uniquement pour limiter l'impact sur la batterie pour 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 réapprovisionnement d'un message toutes les trois minutes.

Taux de messages maximal pour un seul appareil

Sur Android, vous pouvez envoyer jusqu'à 240 messages par minute et 5 000 messages par heure à un seul appareil. Ce seuil élevé est destiné à permettre des pics de trafic à court terme, par exemple lorsque les utilisateurs interagissent rapidement dans un chat. Cette limite permet d'éviter que des erreurs dans la logique d'envoi ne déchargent la batterie d'un appareil par inadvertance.

Pour iOS, nous renvoyons une erreur lorsque le taux dépasse les limites APNs.

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 souvent et vos règles de pare-feu pourraient devenir obsolètes, ce qui aurait un impact sur l'expérience de vos utilisateurs. Dans l'idéal, autorisez les ports 5228 à 5230 et 443 sans 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'adresse 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 d'autorisation à la place des 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 sur votre 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 avec traduction d'adresse réseau et/ou inspection dynamique des paquets :

Si votre réseau implémente la traduction d'adresse réseau (NAT) ou l'inspection approfondie des paquets (SPI), implémentez un délai d'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 la consommation de batterie des appareils mobiles de vos utilisateurs.

Interactions VPN et possibilité de contournement

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 interrompent activement les connexions de longue durée, ce qui nuit à l'expérience utilisateur en raison de messages manqués ou retardés, ou d'une consommation de batterie élevée. Lorsque le VPN est configuré pour nous le permettre, nous le contournons à 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 économe en batterie. L'utilisation de VPN contournables par FCM est spécifique au canal de notification push FCM. Les autres types de trafic FCM, comme le trafic d'enregistrement, utilisent le VPN s'il est actif. Lorsque la connexion FCM contourne le VPN, elle perd les avantages supplémentaires que le VPN peut offrir, comme le masquage de l'adresse IP.

Les méthodes de contrôle du contournement varient selon les VPN. Pour obtenir des instructions, 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 pendant lesquelles les messages sont retardés et une plus grande consommation de batterie, car Cloud Messaging s'efforce de maintenir la connexion VPN.

Identifiants

Selon les fonctionnalités FCM que vous implémentez, vous aurez peut-être besoin des identifiants suivants de votre projet Firebase :