Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

À 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 de données facultative. La charge utile maximale pour les deux types de message est de 4 Ko, sauf lors de l'envoi de messages depuis la console Firebase, qui applique une limite de 1024 caractères.

Utiliser le scénario 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 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 les protocoles du serveur FCM : définissez la clé de notification . Peut avoir une charge de données facultative. Toujours pliable.
  2. Utilisez l' éditeur de notifications : entrez le texte du message, le titre, etc., puis envoyez. Ajoutez une charge 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 ont uniquement des paires clé-valeur personnalisées sans noms de clé réservés (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.

FCM peut envoyer un message de notification comprenant une charge 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 des données.

Messages de notification

Pour les tests ou pour le marketing et le 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 programme 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 vs 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 la création de messages de notification:

Messages de données

Définissez la clé appropriée avec vos paires clé-valeur personnalisées pour envoyer une charge 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 plateforme, l'application cliente reçoit la charge de données dans une fonction de rappel. :

Messages de notification avec données utiles en option

À la fois par programme ou via la console Firebase, vous pouvez envoyer des messages de notification contenant une charge utile facultative de paires clé-valeur personnalisées. Dans l' éditeur 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 charges utiles de notification et de données dépend du fait que l'application est en arrière-plan ou au premier plan, essentiellement, si elle est active ou non au moment de la réception.

  • En arrière-plan , les applications reçoivent la charge utile de notification dans la barre de notification et ne gèrent la charge utile de données que lorsque l'utilisateur appuie sur la notification.
  • 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"
    }
  }
}

Personnalisation d'un message sur toutes les plateformes

Le SDK Firebase Admin et le protocole HTTP FCM v1 permettent à 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.
  • ensembles de champs spécifiques à la plate-forme, tels que AndroidConfig et WebpushConfig , interprétés uniquement par des instances d'application exécutées sur la plate-forme spécifiée.

Les blocs spécifiques à la plate-forme vous permettent de personnaliser les messages pour différentes plates-formes afin de vous assurer qu'ils sont correctement 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 plateforme.

Quand utiliser les champs communs

Utilisez des champs communs lorsque vous:

  • Ciblage des instances d'application sur toutes les plates-formes - iOS, Android et Web
  • Envoi de messages à des sujets

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

Quand utiliser les champs spécifiques à la plateforme

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

  • Envoyer les 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 plateforme. 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 remise 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 si vous souhaitez définir essentiellement la même valeur sur toutes les plates-formes, vous devez utiliser des champs spécifiques à la plate-forme. En effet, chaque plate-forme peut interpréter la valeur légèrement différemment. Par exemple, la durée de vie est définie sur Android comme une heure d'expiration en secondes, tandis que sur iOS, elle est définie comme une date d' expiration.

Exemple: message de notification avec options de livraison spécifiques à la plateforme

La demande d'envoi v1 suivante envoie un titre et un contenu de notification communs à toutes les plates-formes, mais envoie également des remplacements spécifiques à la plate-forme. 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 APN (iOS) sur un paramètre bas
  • définit les clés appropriées pour définir le résultat d'un utilisateur tapant 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 Générer 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 "pliable" est pris en charge sur Android via la FCM collapse_key , sur iOS via apns-collapse-id et JavaScript / Web via Topic . Pour plus de détails, reportez-vous aux descriptions de cette section et à la documentation de référence associée.

Messages non pliables et réductibles

Un message non réductible indique que chaque message individuel est remis à l'appareil. Un message non pliable fournit un contenu utile, par opposition à un message pliable comme un "ping" sans contenu à l'application mobile pour contacter le serveur pour 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 souhaitez remettre 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 se réduire. Si la limite est atteinte, tous les messages stockés sont supprimés. Lorsque l'appareil est de nouveau en ligne, il reçoit un message spécial indiquant que la limite a été atteinte. L'application peut ensuite gérer la situation correctement, 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 cas d'utilisation courants de 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 de sport 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. FCM permet à un maximum de quatre clés de réduction différentes par appareil Android d'être utilisées par le serveur d'application à tout moment. En d'autres termes, 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 aucune garantie sur celles qui sont conservées.

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 des messages non réductibles. Toutefois, si vous utilisez des messages réductibles, n'oubliez pas que FCM autorise uniquement l'utilisation de quatre clés de réduction différentes au maximum par le serveur de connexion FCM par jeton d'enregistrement à un moment donné. Vous ne devez pas dépasser ce nombre, sinon cela pourrait entraîner des conséquences imprévisibles.

Utiliser le scénario Comment envoyer
Non pliable Chaque message est important pour l'application cliente et doit être livré. À l'exception des messages de notification, tous les messages ne sont pas réductibles par défaut.
Pliant Lorsqu'un message plus récent rend un message plus ancien et associé non pertinent pour l'application cliente, FCM remplace l'ancien message. Par exemple: les messages utilisés pour lancer une synchronisation des données à partir du serveur ou les 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 plates-formes)

Définition de la priorité d'un message

Vous avez deux options pour attribuer la priorité de livraison aux messages en aval sur Android: priorité normale et haute. La livraison de 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 de priorité normale sont envoyé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 nouveaux e-mails, la synchronisation de votre interface utilisateur ou la synchronisation des données d'application en arrière-plan, choisissez la priorité de livraison normale.

    Lorsque vous recevez un message de priorité normale 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é. FCM tente de dé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 de haute priorité doivent 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 compartiments de veille d'application qui limitent le nombre de messages FCM haute priorité que vous pouvez envoyer à votre application et qui n'incitent pas l'utilisateur à utiliser votre application ou à afficher une notification. Si, en réponse à un message de priorité élevée, une notification est affichée de manière visible pour l'utilisateur, le quota de votre compartiment de veille d'application ne sera pas consommé par ce message.

    Étant donné qu'une petite partie de la population mobile Android se trouve sur des réseaux à latence élevée, évitez d'ouvrir une connexion à vos serveurs avant d'afficher une notification. Le rappel du serveur avant la fin du temps de traitement autorisé peut être risqué pour les utilisateurs des réseaux à latence élevée. 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 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 de priorité normale envoyé via le protocole FCM HTTP v1 pour informer un abonné à un magazine qu'un nouveau contenu est disponible au téléchargement:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

Pour plus de détails spécifiques à la plate-forme sur la définition de la priorité des messages:

Définition de la durée de vie d'un message

FCM remet 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 retarder intentionnellement 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 remet dès que possible. Bien que cela convienne dans la plupart des cas, il existe certaines applications pour lesquelles un message tardif pourrait tout aussi bien ne jamais être 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 avoir 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 livrer le message. Les demandes qui ne contiennent pas ce champ utilisent par défaut la période maximale de quatre semaines.

Voici quelques utilisations possibles de cette fonctionnalité:

  • Chat vidéo appels entrants
  • Événements d'invitation expirant
  • Événements du calendrier

Un autre avantage de la spécification de la durée de vie d'un message est que FCM 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 rejetés. Cependant, comme ces messages ne sont jamais stockés, cela fournit la meilleure latence pour l'envoi des messages de notification.

Voici un exemple de requête qui inclut 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"
      }
    }
  }
}

Recevoir des 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 que chacun d'entre 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, à l'aide de 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 en utilisant 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 publie un message à FCM et reçoit un ID de message en retour, 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 après son acceptation dépend de nombreux facteurs.

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

Si l'appareil est connecté mais en mode Doze, un message de faible priorité est stocké par FCM jusqu'à ce que l'appareil ne soit plus en mode Doze. Et c'est là que l'indicateur collapse_key joue un rôle: s'il y a 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 rejeté et le nouveau message prend sa place (c'est-à-dire l'ancien message 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 remise future.

Si l'appareil n'est pas connecté à FCM, le message est stocké jusqu'à ce qu'une connexion soit établie (toujours en respectant les règles de la clé de réduction). Lorsqu'une connexion est établie, FCM remet tous les messages en attente à l'appareil. Si le périphérique ne se reconnecte jamais (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 sur lesquels la messagerie directe par canal est activée, si l'appareil ne s'est pas connecté à FCM pendant plus d'un mois, FCM accepte toujours le message mais le rejette immédiatement. Si l'appareil se connecte dans les quatre semaines suivant le dernier message de données que vous lui avez envoyé, votre client reçoit le rappel onDeletedMessages () . L'application peut ensuite gérer la situation correctement, généralement en demandant une synchronisation complète au serveur d'applications.

Enfin, lorsque FCM tente de remettre un message à l'appareil et que l'application a été désinstallée, FCM rejette ce message immédiatement et invalide le jeton d'enregistrement. Les futures tentatives d'envoi d'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 à tous les expéditeurs.

Limitation des messages réductibles

Comme décrit ci-dessus, les messages réductibles sont des notifications sans contenu conçues pour se replier les unes sur les autres. Dans le cas où un développeur répète trop fréquemment le même message à une application, nous retardons (limitons) les messages pour réduire l'impact sur la batterie d'un utilisateur.

Par exemple, si vous envoyez un grand nombre de nouvelles demandes de synchronisation d'e-mails à un seul appareil, nous pouvons retarder la prochaine demande de synchronisation d'e-mails de quelques minutes afin que l'appareil puisse se synchroniser à un 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 de ces messages afin de réduire le coût de la batterie.

Nous limitons les messages réductibles à 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 taux de connexion 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.

Taux de messages maximal 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 par chat. Cette limite empêche les erreurs d'envoi de la logique 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 à 1000 / minute pour éviter que la batterie ne s'épuise en cas de mauvais comportement des applications.

Limite des messages de sujet

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

Pour connaître les taux d'envoi de messages, consultez Limitation du fanout .

Throttling de fanout

La diffusion de 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 l' éditeur de notifications pour cibler des publics ou des segments d'utilisateurs.

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

Le taux de distribution réel réalisable est influencé par le nombre de projets demandant des fanouts en même temps. Un taux de distribution 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 du système. Il est important de noter que la capacité de distribution disponible est divisée entre les projets et non entre les demandes de distribution. Ainsi, si votre projet a deux fanouts en cours, chaque fanout ne verra que la moitié du taux de fanout disponible. La manière 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 peuvent devenir obsolètes et avoir un impact sur l'expérience de vos utilisateurs. Idéalement, vous allez ajouter les ports 5228-5230 à la liste blanche sans restrictions IP. Toutefois, si vous devez avoir une restriction IP, vous devez ajouter toutes les adresses IP dans les blocs IPv4 et IPv6 répertoriés dans l' ASN de Google de 15169 . Il s'agit d'une longue liste et vous devriez prévoir 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:

Un de ceux-ci (l'option n ° 1 est préférable):

  1. Aucune restriction IP
  2. Toutes les adresses IP contenues dans les blocs IP répertoriés dans l' ASN de Google de 15169 . N'oubliez pas de le mettre à jour au moins une fois par mois.

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 avec état 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.

Identifiants

En fonction des fonctionnalités FCM que vous implémentez, vous pouvez avoir besoin des informations d'identification suivantes de votre projet Firebase:

ID du projet Un identifiant unique pour votre projet Firebase, utilisé dans les requêtes adressées au point de terminaison HTTP FCM v1. Cette valeur est disponible dans le volet Paramètres de la console Firebase .
Jeton d'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 tenus secrets.

ID de l'expéditeur Valeur numérique unique créée lorsque vous créez votre projet Firebase, disponible dans l'onglet Cloud Messaging du volet Paramètres de la console Firebase. L'ID de l'expéditeur est utilisé pour identifier chaque expéditeur qui peut envoyer des messages à l'application cliente.
Jeton d'accès Jeton OAuth 2.0 de courte durée qui autorise les requêtes adressées à l'API HTTP v1. Ce jeton est associé à un compte de service qui appartient à votre projet Firebase. Pour créer et faire pivoter des jetons d'accès, suivez les étapes décrites dans Autoriser les demandes d'envoi .
Clé de serveur (pour les 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é de 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 nulle part la clé du serveur dans votre code client. Assurez-vous également de n'utiliser que des clés de serveur pour autoriser votre serveur d'applications. Les clés Android, iOS et du navigateur sont rejetées par FCM.