Check out what’s new from Firebase@ Google I/O 2021, and join our alpha program for early access to the new Remote Config personalization feature. Learn more

À propos des messages FCM

Firebase Cloud Messaging (FCM) offre une large gamme d'options et de capacité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 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 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 000 octets, sauf lors de l'envoi de messages depuis la console Firebase, qui impose une limite de 1024 caractères.

Scénario d'utilisation Comment envoyer
Message de notification FCM affiche automatiquement le message sur les appareils des utilisateurs finaux au nom de l'application cliente. Les messages de notification ont 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.
  1. Dans un environnement de confiance tel que Cloud Functions ou votre serveur d'applications, utilisez le SDK Admin ou le FCM Server Protocols : définissez la clé de notification . Peut avoir une charge utile de données facultative. Toujours pliable.

    Voir quelques exemples d'affichage de notifications et d'envoi de charges utiles de demande.

  2. Utilisez le composeur de notifications : saisissez le texte du message, le titre, etc., et envoyez-le. Ajoutez une charge utile de données facultative en fournissant des données personnalisées.
Message de données L'application cliente est responsable du traitement des messages de données. Les messages de données n'ont que des paires clé-valeur personnalisées sans nom de clé réservé (voir ci-dessous). Dans un environnement de confiance tel que Cloud Functions ou votre serveur d'applications, utilisez le SDK Admin ou les protocoles du serveur FCM : définissez uniquement la clé de data .

Utilisez des messages de notification lorsque vous souhaitez que FCM gère l'affichage d'une notification au nom de votre application cliente. Utilisez des messages de données lorsque vous souhaitez traiter les messages sur votre application cliente.

Le 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 cliente gère la charge utile de données.

Messages de notification

À des fins de test ou 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 par programmation des messages de notification à l'aide du SDK Admin ou des protocoles FCM, définissez la clé de 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 « grand 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 pour obtenir la liste complète des clés prédéfinies disponibles pour les messages de notification de création :

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é de data commune et 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 de data niveau supérieur 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 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. Selon 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. Cependant, il existe des solutions externes telles que Capillary ou DTLS .

Messages de notification avec charge utile de données facultative

Que ce soit par programmation 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 qui incluent à la fois des notifications et des charges utiles de données dépend du fait que l'application est en arrière-plan ou au premier plan, essentiellement, qu'elle soit active ou non au moment de la réception.

  • Lorsqu'elles sont en arrière-plan , les applications reçoivent la charge utile de la notification dans la barre de notification et ne gèrent la charge utile des données que lorsque l'utilisateur appuie sur la notification.
  • Lorsqu'elle est 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é de notification et la clé de 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 de message . Ceci comprend:

  • 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 à la plate-forme vous offrent la possibilité de personnaliser les messages pour différentes plates-formes afin de garantir qu'ils sont correctement traités lors de leur réception. 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 des champs communs lorsque vous êtes :

  • Cibler les instances d'application sur toutes les plateformes — iOS, Android et Web
  • Envoi de 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 à la plate-forme

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

  • Envoyer des champs uniquement à des plates-formes 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 ; utiliser des champs spécifiques à la plate-forme. Par exemple, pour envoyer une notification uniquement à iOS et au Web mais pas à Android, vous devez utiliser deux ensembles de champs distincts, un pour iOS et un pour le Web.

Lorsque vous envoyez des messages avec des options de livraison spécifiques , utilisez des champs spécifiques à la plate-forme pour les définir. Vous pouvez spécifier différentes valeurs par plate-forme si vous le souhaitez. Cependant, même lorsque vous souhaitez définir essentiellement la même valeur sur toutes les plates-formes, vous devez utiliser des champs spécifiques à la plate-forme. En effet, chaque plate-forme peut interpréter la valeur légèrement différemment. Par exemple, la durée de vie est définie sur Android comme un délai d'expiration en secondes, tandis que sur iOS, elle est définie comme une date d' expiration .

Exemple : message de notification avec des options de livraison spécifiques à la plate-forme

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 (iOS) 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 iOS - 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 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 iOS et sur le Web. Par exemple, le comportement de message « réductible » est pris en charge sur Android via la collapse_key de FCM, sur iOS via apns-collapse-id et sur JavaScript/Web via Topic . Pour plus de détails, voir les descriptions dans cette section et la documentation de référence associée.

Messages non pliables et pliables

Un message non réductible indique que chaque message individuel est remis à l'appareil. Un message non réductible fournit un contenu utile, par opposition à un message réductible comme un « ping » sans contenu à 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 voudriez transmettre chaque message, car chaque message a un contenu différent.

Pour Android, il y a une limite de 100 messages qui peuvent ê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 correctement la situation, généralement en demandant une synchronisation complète au serveur d'applications.

Un message rétractable est un message qui peut être remplacé par un nouveau message s'il n'a pas encore été remis à l'appareil.

Les cas d'utilisation courants des messages réductibles sont les 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 repli 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 repli différente. Si vous dépassez ce nombre, FCM ne conserve que quatre clés de réduction, sans aucune garantie quant à celles qui sont conservées.

Les messages de sujet sans charge utile sont réductibles par défaut.

Lequel dois-je utiliser ?

Les messages pliables sont un meilleur choix du point de vue des performances, à condition que votre application n'ait pas besoin d'utiliser des messages non pliables. Cependant, si vous utilisez des messages réductibles, n'oubliez pas que FCM n'autorise l'utilisation d'un maximum de quatre clés de réduction différentes par le serveur de connexion FCM par jeton d'enregistrement à un moment donné. Vous ne devez pas dépasser ce nombre, ou cela pourrait entraîner des conséquences imprévisibles.

Scénario d'utilisation Comment envoyer
Non pliable Chaque message est important pour l'application cliente et doit être transmis. À l'exception des messages de notification, tous les messages ne sont pas réductibles par défaut.
Pliant Lorsqu'un message plus récent rend un message plus ancien et connexe non pertinent pour l'application cliente, 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 :
  • collapseKey sur Android
  • apns-collapse-id sur iOS
  • Topic sur le Web
  • collapse_key dans les protocoles hérités (toutes les plateformes)

Définir la priorité d'un message

Vous avez deux options pour attribuer une priorité de livraison aux messages en aval sur Android : priorité normale et haute. La livraison des messages normaux et prioritaires fonctionne comme ceci :

  • Priorité normale. Il s'agit de la priorité par défaut pour les messages de données . Les messages prioritaires normaux sont livrés immédiatement lorsque l'application est au premier plan. Lorsque l'appareil est en mode Doze, la livraison peut être retardée pour économiser la batterie. Pour les messages moins urgents, tels que les notifications de nouvel e-mail, la synchronisation de votre interface utilisateur ou la synchronisation des données de l'application en arrière-plan, choisissez la priorité de livraison normale.

    Lorsque vous recevez un message prioritaire normal sur Android qui demande une synchronisation des données en arrière-plan pour votre application, vous pouvez planifier une tâche avec WorkManager pour la gérer lorsque le réseau est disponible.

  • Haute priorité. Le FCM tente de livrer immédiatement des messages de haute priorité, permettant au service FCM de réveiller un périphérique en veille si nécessaire et d'exécuter un traitement limité (y compris un accès réseau très limité). Les messages à haute priorité devraient généralement entraîner une interaction de l'utilisateur avec votre application ou ses notifications. Si FCM détecte un modèle dans lequel ils ne le font pas, vos messages peuvent être dépriorisés. Android P a introduit des buckets de veille d'application qui limitent le nombre de messages FCM hautement prioritaires que vous pouvez envoyer à votre application sans que l'utilisateur utilise votre application ou affiche une notification. Si, en réponse à un message de haute priorité, une notification s'affiche d'une manière visible pour l'utilisateur, votre quota de buckets de veille d'application ne sera pas consommé par ce message.

    Étant donné qu'une petite partie de la population mobile Android utilise des réseaux à latence élevée, évitez d'ouvrir une connexion à vos serveurs avant d'afficher une notification. Rappeler le serveur avant la fin du temps de traitement autorisé peut être risqué pour les utilisateurs sur les réseaux à haute latence. Au lieu de cela, incluez le contenu de la notification dans le message FCM et affichez-le immédiatement. Si vous avez besoin de synchroniser pour du contenu supplémentaire dans l'application sur Android, vous pouvez planifier une tâche avec WorkManager pour gérer cela en arrière-plan.

Voici un exemple de message prioritaire normal envoyé via le protocole FCM HTTP v1 pour informer un abonné d'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 :

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 peut-être pas toujours possible. Par exemple, si la plate-forme est Android, l'appareil peut être éteint, hors ligne ou indisponible. Ou 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 en retard pourrait aussi bien ne jamais être livré. 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 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) et elle correspond à la période maximale pendant laquelle FCM stocke et tente de remettre le message. Les demandes qui ne contiennent pas ce champ par défaut à la période maximale de quatre semaines.

Voici quelques utilisations possibles de cette fonctionnalité :

  • Appels entrants de chat vidéo
  • Événements d'invitation expirant
  • Événements du calendrier

Un autre avantage de spécifier la durée de vie d'un message est que FCM ne limite jamais les messages avec une valeur de durée de vie de 0 seconde. En d'autres termes, FCM garantit le meilleur effort pour les 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 supprimé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 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"
      }
    }
  }
}

Réception de messages de plusieurs expéditeurs

FCM permet à plusieurs parties d'envoyer des messages à la même application cliente. Par exemple, supposons que l'application cliente soit un agrégateur d'articles avec plusieurs contributeurs, et chacun d'eux devrait pouvoir envoyer un message lorsqu'il publie un nouvel article. Ce message peut contenir une URL afin que l'application cliente puisse télécharger l'article. Au lieu d'avoir à centraliser toutes les activités d'envoi en un seul endroit, FCM vous donne la possibilité de laisser chacun de ces contributeurs envoyer ses propres messages.

Pour activer cette fonctionnalité, assurez-vous d'avoir l' ID d'expéditeur de chaque expéditeur . Lors de la demande d'inscription, l'application cliente récupère le jeton plusieurs fois, à chaque fois avec un ID d'expéditeur différent dans le champ d'audience, en utilisant la méthode de récupération de jeton pour la plate-forme donnée :

Assurez-vous de ne pas ajouter plusieurs ID d'expéditeur à une seule demande de jeton, car cela peut avoir des résultats imprévisibles. Passez chaque appel séparément, une fois par ID d'expéditeur.

Enfin, partagez le jeton d'enregistrement avec les expéditeurs correspondants, et ils pourront envoyer des messages à l'application cliente à l'aide de leurs propres clés d'authentification.

Notez qu'il y a une limite de 100 expéditeurs multiples.

Durée de vie d'un message

Lorsqu'un serveur d'applications envoie un message à FCM et reçoit en retour un ID de message, cela ne signifie pas que le message a déjà été remis à l'appareil. Cela signifie plutôt qu'il a été accepté pour livraison. Ce qu'il advient du message une fois qu'il est accepté dépend de nombreux facteurs.

Dans le meilleur des cas, si l'appareil est connecté au FCM, l'écran est allumé et il n'y a pas de restrictions de limitation, le message est livré immédiatement.

Si l'appareil est connecté mais dans Doze, un message de faible priorité est stocké par le 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 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 livraison future.

Si l'appareil n'est pas connecté au FCM, le message est stocké jusqu'à ce qu'une connexion soit établie (en respectant à nouveau les règles de la clé de repli). Lorsqu'une connexion est établie, FCM transmet tous les messages en attente à l'appareil. Si l'appareil ne se reconnecte plus (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 obtenir plus d'informations sur la livraison d'un message :

    Pour obtenir plus d'informations sur la livraison des messages sur Android ou iOS, consultez le tableau de bord des rapports FCM , qui enregistre le nombre de messages envoyés et ouverts sur les appareils iOS et Android, ainsi que les données pour les "impressions" (notifications vues par les utilisateurs) pour Android applications.

Pour les appareils Android avec messagerie directe activée, si l'appareil ne s'est pas connecté à FCM pendant 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 correctement la situation, généralement en demandant une synchronisation complète au serveur d'applications.

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 futures d'envoyer un message à cet appareil entraînent une erreur NotRegistered .

Limitation et mise à l'échelle

Notre objectif est de toujours livrer chaque message envoyé via FCM. Cependant, la livraison de chaque message entraîne parfois une mauvaise expérience utilisateur globale. Dans d'autres cas, nous devons fournir des limites pour garantir que FCM fournit un service évolutif pour tous les expéditeurs.

Limitation des messages pliable

Comme décrit ci-dessus, les messages réductibles sont des notifications sans contenu conçues pour s'effondrer les unes sur les autres. Dans le cas où un développeur répète trop souvent le même message à une application, nous retardons (régulons) 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 taux moyen inférieur. Cet étranglement est fait 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ée, les messages non réductibles 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 rétractables à 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 être un problème pour la livraison des messages, mais c'est important pour assurer la stabilité de notre système.

Pour chaque projet, FCM permet 2500 connexions en parallèle.

Débit maximal de messages vers un seul appareil

Vous pouvez envoyer jusqu'à 240 messages/minute et 5 000 messages/heure à un seul appareil. Ce seuil élevé est destiné à permettre des rafales de trafic à court terme, par exemple lorsque les utilisateurs interagissent rapidement sur le chat. Cette limite empêche les erreurs de logique d'envoi de vider par inadvertance la batterie d'un appareil.

Limite de messages en amont

Nous limitons 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 éviter l'épuisement de la batterie en cas de mauvais comportement des applications.

Limite de messages par sujet

Le taux d'ajout/suppression d'abonnement à un sujet est limité à 3 000 RPS par projet.

Pour les taux d'envoi de messages, voir Fanout Throttling .

Étranglement du fanout

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

La distribution des messages n'est pas instantanée et vous avez donc parfois plusieurs distributions en cours simultanément. Nous limitons le nombre de déploiements de messages simultanés par projet à 1 000. Après cela, nous pouvons rejeter des demandes de déploiement supplémentaires ou différer le déploiement des demandes jusqu'à ce que certains des déploiements déjà en cours soient terminés.

Le taux de déploiement réel atteignable est influencé par le nombre de projets demandant des déploiements en même temps. Un taux de déploiement de 10 000 QPS pour un projet individuel n'est pas rare, mais ce nombre n'est pas une garantie et est le résultat de la charge totale sur le système. Il est important de noter que la capacité de distribution disponible est répartie entre les projets et non entre les demandes de distribution. Ainsi, si votre projet a deux sortances en cours, chaque sortance ne verra que la moitié du taux de sortance disponible. La méthode recommandée pour maximiser votre vitesse de déploiement est de n'avoir qu'un seul déploiement actif 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 permettre aux appareils mobiles de 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 5229 et 5230.

Pour les connexions sortantes, 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 à la liste blanche sans restrictions IP. Cependant, si vous devez avoir une restriction IP, vous devez ajouter à la liste blanche toutes les adresses IP répertoriées dans goog.json . Cette grande liste est mise à jour régulièrement, et il est recommandé de mettre à jour vos règles tous les mois. Les problèmes causés par les restrictions IP du pare-feu sont souvent intermittents et difficiles à diagnostiquer.

Ports à ouvrir pour les messages entrants :

  • 5228
  • 5229
  • 5230
  • 443

Ports pour autoriser les connexions sortantes :

L'un d'entre eux (l'option 1 est préférée) :

  1. Aucune restriction IP
  2. Toutes les adresses IP pour les domaines par défaut.

    Pour récupérer une liste à jour de ces adresses, suivez les instructions décrites dans Adresses IP des domaines par défaut .

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 de 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 batterie des appareils mobiles de vos utilisateurs.

Crédits

Selon les fonctionnalités FCM que vous implémentez, vous aurez peut-être besoin des informations d'identification suivantes de votre projet Firebase :

Identifiant du projet Identifiant unique pour votre projet Firebase, utilisé dans les demandes adressées au point de terminaison HTTP FCM v1. Cette valeur est disponible dans le volet Paramètres de la console Firebase .
Jeton d'inscription

Une chaîne de jeton unique qui identifie chaque instance d'application cliente. Le jeton d'enregistrement est requis pour la messagerie d'un seul appareil et d'un groupe d'appareils. Notez que les jetons d'enregistrement doivent être gardés secrets.

Identifiant 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 cliente.
Jeton d'accès Un jeton OAuth 2.0 de courte durée qui autorise les requêtes à l'API HTTP v1. Ce jeton est associé à un compte de service qui appartient à votre projet Firebase. Pour créer et faire pivoter les jetons d'accès, suivez les étapes décrites dans Autoriser les demandes d'envoi .
Clé de serveur (pour les protocoles hérités)

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 Firebase Cloud Messaging. Vous obtenez la clé du serveur lorsque vous créez votre projet Firebase. Vous pouvez l'afficher dans l'onglet Cloud Messaging du volet Paramètres de la console Firebase.

Important : n'incluez la clé du serveur nulle part dans votre code client. Assurez-vous également d'utiliser uniquement des clés de serveur pour autoriser votre serveur d'applications. Les clés Android, iOS et du navigateur sont rejetées par FCM.