Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Informazioni sui messaggi FCM

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Firebase Cloud Messaging (FCM) offre un'ampia gamma di opzioni e funzionalità di messaggistica. Le informazioni in questa pagina hanno lo scopo di aiutarti a comprendere i diversi tipi di messaggi FCM e cosa puoi fare con essi.

Tipi di messaggi

Con FCM puoi inviare due tipi di messaggi ai clienti:

  • Messaggi di notifica, a volte considerati "messaggi di visualizzazione". Questi vengono gestiti automaticamente dall'SDK FCM.
  • Messaggi di dati, che vengono gestiti dall'app client.

I messaggi di notifica contengono un insieme predefinito di chiavi visibili all'utente. I messaggi di dati, al contrario, contengono solo le coppie chiave-valore personalizzate definite dall'utente. I messaggi di notifica possono contenere un carico utile di dati opzionale. Il carico utile massimo per entrambi i tipi di messaggio è 4000 byte, tranne quando si inviano messaggi dalla console Firebase, che impone un limite di 1024 caratteri.

Usa lo scenario Come spedire
Messaggio di notifica FCM mostra automaticamente il messaggio ai dispositivi degli utenti finali per conto dell'app client. I messaggi di notifica hanno un set predefinito di chiavi visibili all'utente e un payload di dati opzionale di coppie chiave-valore personalizzate.
  1. In un ambiente affidabile come Cloud Functions o il tuo server app, utilizza l' Admin SDK o i protocolli server FCM : imposta la chiave di notification . Potrebbe avere un carico utile di dati opzionale. Sempre pieghevole.

    Guarda alcuni esempi di visualizzazione delle notifiche e invio di payload di richieste.

  2. Usa il compositore di notifiche : inserisci il testo del messaggio, il titolo, ecc. e invia. Aggiungi un carico utile di dati opzionale fornendo dati personalizzati.
Messaggio di dati L'app client è responsabile dell'elaborazione dei messaggi di dati. I messaggi di dati hanno solo coppie chiave-valore personalizzate senza nomi di chiavi riservati (vedi sotto). In un ambiente affidabile come Cloud Functions o il tuo server app, utilizza l' Admin SDK o i protocolli server FCM : imposta solo la chiave data .

Utilizza i messaggi di notifica quando desideri che FCM gestisca la visualizzazione di una notifica per conto dell'app client. Usa i messaggi di dati quando desideri elaborare i messaggi nell'app client.

FCM può inviare un messaggio di notifica che include un payload di dati opzionale. In questi casi, FCM gestisce la visualizzazione del payload delle notifiche e l'app client gestisce il payload dei dati.

Messaggi di notifica

Per i test o per il marketing e il coinvolgimento degli utenti, puoi inviare messaggi di notifica utilizzando la console Firebase . La console Firebase fornisce test A/B basati su analisi per aiutarti a perfezionare e migliorare i messaggi di marketing.

Per inviare messaggi di notifica a livello di codice utilizzando Admin SDK o i protocolli FCM, impostare la chiave di notification con il set predefinito necessario di opzioni chiave-valore per la parte visibile all'utente del messaggio di notifica. Ad esempio, ecco un messaggio di notifica in formato JSON in un'app di messaggistica istantanea. L'utente può aspettarsi di vedere un messaggio con il titolo "Portogallo vs. Danimarca" e il testo "grande partita!" sul dispositivo:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

I messaggi di notifica vengono consegnati alla barra delle notifiche quando l'app è in background. Per le app in primo piano, i messaggi vengono gestiti da una funzione di callback.

Consulta la documentazione di riferimento per l'elenco completo delle chiavi predefinite disponibili per i messaggi di notifica degli edifici:

Messaggi di dati

Imposta la chiave appropriata con le tue coppie chiave-valore personalizzate per inviare un payload di dati all'app client.

Ad esempio, ecco un messaggio in formato JSON nella stessa app di messaggistica istantanea di cui sopra, in cui le informazioni sono incapsulate nella chiave data comune e l'app client dovrebbe interpretare il contenuto:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

L'esempio precedente mostra l'utilizzo del campo data di livello superiore o comune, interpretato dai client su tutte le piattaforme che ricevono il messaggio. Su ciascuna piattaforma, l'app client riceve il carico utile dei dati in una funzione di callback.

Crittografia per messaggi di dati

Il livello di trasporto Android (vedi architettura FCM ) utilizza la crittografia point-to-point. A seconda delle tue esigenze, potresti decidere di aggiungere la crittografia end-to-end ai messaggi di dati. FCM non fornisce una soluzione end-to-end. Tuttavia, sono disponibili soluzioni esterne come Capillare o DTLS .

Messaggi di notifica con payload di dati opzionale

Sia a livello di codice che tramite la console Firebase, puoi inviare messaggi di notifica che contengono un payload opzionale di coppie chiave-valore personalizzate. Nel compositore di notifiche , utilizza i campi dati personalizzati nelle opzioni avanzate .

Il comportamento dell'app durante la ricezione di messaggi che includono sia notifiche che payload di dati dipende dal fatto che l'app sia in background o in primo piano, in sostanza, dal fatto che sia attiva o meno al momento della ricezione.

  • Quando sono in background , le app ricevono il payload delle notifiche nella barra delle notifiche e gestiscono il payload dei dati solo quando l'utente tocca la notifica.
  • Quando è in primo piano , l'app riceve un oggetto messaggio con entrambi i payload disponibili.

Ecco un messaggio in formato JSON contenente sia la chiave di notification che la chiave data :

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Personalizzazione di un messaggio su più piattaforme

Firebase Admin SDK e il protocollo HTTP FCM v1 consentono entrambi alle richieste di messaggi di impostare tutti i campi disponibili nell'oggetto message . Ciò comprende:

  • un insieme comune di campi che devono essere interpretati da tutte le istanze dell'app che ricevono il messaggio.
  • set di campi specifici della piattaforma, come AndroidConfig e WebpushConfig , interpretati solo dalle istanze dell'app in esecuzione sulla piattaforma specificata.

I blocchi specifici della piattaforma offrono la flessibilità di personalizzare i messaggi per piattaforme diverse per garantire che vengano gestiti correttamente una volta ricevuti. Il backend FCM terrà conto di tutti i parametri specificati e personalizzerà il messaggio per ciascuna piattaforma.

Quando utilizzare i campi comuni

Usa i campi comuni quando sei:

  • Targeting di istanze dell'app su tutte le piattaforme: Apple, Android e Web
  • Invio di messaggi agli argomenti

Tutte le istanze dell'app, indipendentemente dalla piattaforma, possono interpretare i seguenti campi comuni:

Quando utilizzare i campi specifici della piattaforma

Usa i campi specifici della piattaforma quando vuoi:

  • Invia campi solo a piattaforme particolari
  • Invia campi specifici della piattaforma oltre ai campi comuni

Ogni volta che vuoi inviare valori solo a piattaforme particolari, non utilizzare campi comuni; utilizzare i campi specifici della piattaforma. Ad esempio, per inviare una notifica solo alle piattaforme Apple e al Web ma non ad Android, è necessario utilizzare due insiemi separati di campi, uno per Apple e uno per il Web.

Quando invii messaggi con opzioni di consegna specifiche , utilizza i campi specifici della piattaforma per impostarli. Se lo desideri, puoi specificare valori diversi per piattaforma. Tuttavia, anche quando si desidera impostare essenzialmente lo stesso valore su più piattaforme, è necessario utilizzare i campi specifici della piattaforma. Questo perché ciascuna piattaforma può interpretare il valore in modo leggermente diverso: ad esempio, il tempo di vita è impostato su Android come tempo di scadenza in secondi, mentre su Apple è impostato come data di scadenza .

Esempio: messaggio di notifica con opzioni di consegna specifiche della piattaforma

La seguente richiesta di invio v1 invia un titolo e un contenuto di notifica comuni a tutte le piattaforme, ma invia anche alcune sostituzioni specifiche della piattaforma. Nello specifico la richiesta:

  • imposta un tempo di vita lungo per le piattaforme Android e Web, mentre imposta la priorità dei messaggi APNs (piattaforme Apple) su un'impostazione bassa
  • imposta le chiavi appropriate per definire il risultato del tocco di un utente sulla notifica su Android e Apple, rispettivamente click_action e category .
{
  "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"
       }
     }
   }
 }

Consulta la documentazione di riferimento HTTP v1 per i dettagli completi sulle chiavi disponibili nei blocchi specifici della piattaforma nel corpo del messaggio. Per ulteriori informazioni sulla creazione di richieste di invio che contengono il corpo del messaggio, vedere Compilazione di richieste di invio .

Opzioni di consegna

FCM fornisce un insieme specifico di opzioni di consegna per i messaggi inviati a dispositivi Android e consente opzioni simili su piattaforme Apple e Web. Ad esempio, il comportamento del messaggio "comprimibile" è supportato su Android tramite il folder_key di FCM, su Apple tramite apns-collapse-id collapse_key su JavaScript/Web tramite Topic . Per i dettagli, vedere le descrizioni in questa sezione e la relativa documentazione di riferimento.

Messaggi non comprimibili e comprimibili

Un messaggio non comprimibile indica che ogni singolo messaggio viene consegnato al dispositivo. Un messaggio non comprimibile fornisce alcuni contenuti utili, al contrario di un messaggio comprimibile come un "ping" senza contenuto all'app mobile per contattare il server per recuperare i dati.

Alcuni casi d'uso tipici dei messaggi non comprimibili sono messaggi di chat o messaggi critici. Ad esempio, in un'app di messaggistica istantanea, vorresti consegnare ogni messaggio, perché ogni messaggio ha un contenuto diverso.

Per Android esiste un limite di 100 messaggi che possono essere archiviati senza collassare. Se viene raggiunto il limite, tutti i messaggi memorizzati vengono eliminati. Quando il dispositivo è di nuovo online, riceve un messaggio speciale che indica che il limite è stato raggiunto. L'app può quindi gestire la situazione correttamente, in genere richiedendo una sincronizzazione completa dal server dell'app.

Un messaggio comprimibile è un messaggio che può essere sostituito da un nuovo messaggio se deve ancora essere consegnato al dispositivo.

Un caso d'uso comune dei messaggi comprimibili sono i messaggi utilizzati per indicare a un'app mobile di sincronizzare i dati dal server. Un esempio potrebbe essere un'app sportiva che aggiorna gli utenti con l'ultimo punteggio. Solo il messaggio più recente è rilevante.

Per contrassegnare un messaggio come comprimibile su Android, includi il parametro collapse_key nel payload del messaggio. Per impostazione predefinita, la chiave di compressione è il nome del pacchetto dell'app registrato nella console Firebase. Il server FCM può memorizzare contemporaneamente quattro diversi messaggi comprimibili per dispositivo, ciascuno con una chiave di compressione diversa. Se si supera questo numero, FCM conserva solo quattro chiavi di compressione, senza garanzie su quali vengano conservate.

I messaggi degli argomenti senza payload sono comprimibili per impostazione predefinita. I messaggi di notifica sono sempre comprimibili e ignoreranno il parametro collapse_key .

Quale dovrei usare?

I messaggi comprimibili sono una scelta migliore dal punto di vista delle prestazioni, a condizione che la tua app non debba usare messaggi non comprimibili. Tuttavia, se utilizzi messaggi comprimibili, ricorda che FCM consente a FCM di utilizzare solo un massimo di quattro chiavi di compressione diverse per token di registrazione in un dato momento. Non devi superare questo numero, altrimenti potrebbe causare conseguenze imprevedibili.

Usa lo scenario Come spedire
Non pieghevole Ogni messaggio è importante per l'app client e deve essere consegnato. Fatta eccezione per i messaggi di notifica, tutti i messaggi non sono comprimibili per impostazione predefinita.
Collassabile Quando è presente un messaggio più recente che rende un messaggio correlato precedente irrilevante per l'app client, FCM sostituisce il messaggio precedente. Ad esempio: messaggi utilizzati per avviare una sincronizzazione dati dal server o messaggi di notifica obsoleti. Imposta il parametro appropriato nella tua richiesta di messaggio:
  • collapseKey su Android
  • apns-collapse-id su Apple
  • Topic sul Web
  • collapse_key nei protocolli legacy (tutte le piattaforme)

Impostazione della priorità di un messaggio

Sono disponibili due opzioni per assegnare la priorità di consegna ai messaggi downstream: normale e priorità alta. Sebbene il comportamento differisca leggermente tra le piattaforme, la consegna di messaggi normali e ad alta priorità funziona in questo modo:

  • Priorità normale. I messaggi con priorità normale vengono consegnati immediatamente quando l'app è in primo piano. Per le app in background, la consegna potrebbe subire dei ritardi. Per i messaggi meno urgenti, come le notifiche di nuove e-mail, la sincronizzazione dell'interfaccia utente o la sincronizzazione dei dati dell'app in background, scegli la normale priorità di consegna.

  • Priorità alta. FCM tenta di consegnare immediatamente messaggi ad alta priorità anche se il dispositivo è in modalità Doze. I messaggi ad alta priorità sono per contenuti sensibili al tempo e visibili dall'utente.

Ecco un esempio di un normale messaggio di priorità inviato tramite il protocollo FCM HTTP v1 per notificare a un abbonato a una rivista che è possibile scaricare nuovi contenuti:

{
  "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"
      }
    }
  }
}

Per ulteriori dettagli specifici della piattaforma sull'impostazione della priorità dei messaggi:

Impostazione della durata di un messaggio

FCM di solito consegna i messaggi immediatamente dopo che sono stati inviati. Tuttavia, questo potrebbe non essere sempre possibile. Ad esempio, se la piattaforma è Android, il dispositivo potrebbe essere spento, offline o comunque non disponibile. Oppure FCM potrebbe ritardare intenzionalmente i messaggi per impedire a un'app di consumare risorse eccessive e influire negativamente sulla durata della batteria.

Quando ciò accade, FCM archivia il messaggio e lo consegna non appena possibile. Anche se questo va bene nella maggior parte dei casi, ci sono alcune app per le quali un messaggio in ritardo potrebbe anche non essere mai consegnato. Ad esempio, se il messaggio è una chiamata in arrivo o una notifica di chat video, è significativo solo per un breve periodo di tempo prima che la chiamata venga terminata. Oppure se il messaggio è un invito a un evento, è inutile se ricevuto dopo che l'evento è terminato.

Su Android e Web/JavaScript, puoi specificare la durata massima di un messaggio. Il valore deve avere una durata compresa tra 0 e 2.419.200 secondi (28 giorni) e corrisponde al periodo di tempo massimo per il quale FCM memorizza e tenta di recapitare il messaggio. Le richieste che non contengono questo campo hanno un periodo massimo di quattro settimane.

Ecco alcuni possibili usi per questa funzione:

  • Videochat per le chiamate in arrivo
  • Eventi su invito in scadenza
  • Eventi del calendario

Un altro vantaggio di specificare la durata di un messaggio è che FCM non limita mai i messaggi con un valore di durata di 0 secondi. In altre parole, FCM garantisce il massimo sforzo per i messaggi che devono essere consegnati "ora o mai più". Tieni presente che un valore time_to_live di 0 significa che i messaggi che non possono essere consegnati immediatamente vengono eliminati. Tuttavia, poiché tali messaggi non vengono mai archiviati, ciò fornisce la migliore latenza per l'invio di messaggi di notifica.

Ecco un esempio di una richiesta che include 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"
      }
    }
  }
}

Durata di un messaggio

Quando un server dell'app pubblica un messaggio su FCM e riceve un ID messaggio, non significa che il messaggio sia già stato recapitato al dispositivo. Piuttosto, significa che è stato accettato per la consegna. Ciò che accade al messaggio dopo che è stato accettato dipende da molti fattori.

Nella migliore delle ipotesi, se il dispositivo è connesso a FCM, lo schermo è acceso e non ci sono restrizioni di limitazione, il messaggio viene consegnato immediatamente.

Se il dispositivo è connesso ma in Doze, un messaggio di priorità bassa viene memorizzato da FCM fino a quando il dispositivo non esce da Doze. Ed è qui che gioca un ruolo il flag di collapse_key : se c'è già un messaggio con la stessa chiave di compressione (e token di registrazione) archiviato e in attesa di consegna, il vecchio messaggio viene scartato e il nuovo messaggio prende il suo posto (ovvero il vecchio messaggio viene compresso da quello nuovo). Tuttavia, se la chiave di compressione non è impostata, sia il nuovo che il vecchio messaggio vengono archiviati per la consegna futura.

Se il dispositivo non è connesso a FCM, il messaggio viene memorizzato fino a quando non viene stabilita una connessione (sempre rispettando le regole della chiave di compressione). Quando viene stabilita una connessione, FCM consegna tutti i messaggi in sospeso al dispositivo. Se il dispositivo non viene mai più connesso (ad esempio, se è stato ripristinato le impostazioni di fabbrica), il messaggio alla fine va in timeout e viene eliminato dalla memoria FCM. Il timeout predefinito è di quattro settimane, a meno che non sia impostato il flag time_to_live .

Per ottenere maggiori informazioni sulla consegna di un messaggio:

    Per avere maggiori informazioni sulla consegna dei messaggi su piattaforme Android o Apple, vedere la dashboard di reportistica FCM , che registra il numero di messaggi inviati e aperti su dispositivi Apple e Android, insieme ai dati per le "impressioni" (notifiche viste dagli utenti) per App Android.

Per i dispositivi Android con messaggistica diretta del canale abilitata, se il dispositivo non si è connesso a FCM per più di un mese, FCM accetta comunque il messaggio ma lo scarta immediatamente. Se il dispositivo si connette entro quattro settimane dall'ultimo messaggio di dati che gli è stato inviato, il client riceve il callback onDeletedMessages() . L'app può quindi gestire la situazione correttamente, in genere richiedendo una sincronizzazione completa dal server dell'app.

Infine, quando FCM tenta di recapitare un messaggio al dispositivo e l'app è stata disinstallata, FCM elimina immediatamente quel messaggio e invalida il token di registrazione. I tentativi futuri di inviare un messaggio a quel dispositivo generano un errore NotRegistered .

Limitazione e ridimensionamento

Il nostro obiettivo è consegnare sempre ogni messaggio inviato tramite FCM. Tuttavia, la consegna di ogni messaggio a volte si traduce in un'esperienza utente complessiva scadente. In altri casi, dobbiamo fornire dei limiti per garantire che FCM fornisca un servizio scalabile per tutti i mittenti.

Limitazione dei messaggi comprimibile

Come descritto sopra, i messaggi comprimibili sono notifiche prive di contenuto progettate per comprimersi l'una sull'altra. Nel caso in cui uno sviluppatore ripeta lo stesso messaggio a un'app troppo frequentemente, ritardiamo (valorizziamo) i messaggi per ridurre l'impatto sulla batteria di un utente.

Ad esempio, se invii un numero elevato di nuove richieste di sincronizzazione e-mail a un singolo dispositivo, potremmo ritardare di alcuni minuti la successiva richiesta di sincronizzazione e-mail in modo che il dispositivo possa sincronizzarsi a una velocità media inferiore. Questa limitazione viene eseguita rigorosamente per limitare l'impatto della batteria sperimentato dall'utente.

Se il tuo caso d'uso richiede modelli di invio burst elevati, i messaggi non comprimibili potrebbero essere la scelta giusta. Per tali messaggi, assicurati di includere il contenuto in tali messaggi al fine di ridurre il costo della batteria.

Limitiamo i messaggi comprimibili a una raffica di 20 messaggi per app per dispositivo, con una ricarica di 1 messaggio ogni 3 minuti.

Limitazione del server XMPP

Limitiamo la velocità di connessione ai server XMPP di FCM a 400 connessioni al minuto per progetto. Questo non dovrebbe essere un problema per la consegna dei messaggi, ma è importante per garantire la stabilità del nostro sistema.

Per ogni progetto, FCM consente 2500 connessioni in parallelo.

Velocità massima dei messaggi su un singolo dispositivo

Per Android, puoi inviare fino a 240 messaggi/minuto e 5.000 messaggi/ora a un singolo dispositivo. Questa soglia elevata ha lo scopo di consentire esplosioni di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente tramite chat. Questo limite impedisce agli errori di invio della logica di scaricare inavvertitamente la batteria di un dispositivo.

Per iOS, viene restituito un errore quando la frequenza supera i limiti APN.

Limite di messaggi a monte

Limitiamo i messaggi a monte a 1.500.000/minuto per progetto per evitare di sovraccaricare i server di destinazione a monte.

Limitiamo i messaggi a monte per dispositivo a 1.000/minuto per evitare che la batteria si scarichi dal cattivo comportamento delle app.

Limite dei messaggi dell'argomento

Il tasso di aggiunta/rimozione dell'abbonamento all'argomento è limitato a 3.000 QPS per progetto.

Per le tariffe di invio dei messaggi, vedere Fanout Throttling .

Limitazione del fanout

Il fanout del messaggio è il processo di invio di un messaggio a più dispositivi, ad esempio quando scegli come target argomenti e gruppi o quando utilizzi il compositore di notifiche per indirizzare il pubblico o i segmenti di utenti.

Il fanout del messaggio non è istantaneo e quindi occasionalmente hai più fanout in corso contemporaneamente. Limitiamo il numero di fanout di messaggi simultanei per progetto a 1.000. Successivamente, potremmo rifiutare ulteriori richieste di fanout o posticipare il fanout delle richieste fino al completamento di alcuni dei fanout già in corso.

L'effettivo tasso di fanout ottenibile è influenzato dal numero di progetti che richiedono fanout contemporaneamente. Un tasso di fanout di 10.000 QPS per un singolo progetto non è raro, ma quel numero non è una garanzia ed è il risultato del carico totale sul sistema. È importante notare che la capacità di fanout disponibile è divisa tra i progetti e non tra le richieste di fanout. Quindi, se il tuo progetto ha due fanout in corso, ogni fanout vedrà solo la metà della frequenza di fanout disponibile. Il modo consigliato per massimizzare la velocità del fanout è avere solo un fanout attivo in corso alla volta.

Porte FCM e il tuo firewall

Se la tua organizzazione dispone di un firewall per limitare il traffico da o verso Internet, devi configurarlo per consentire ai dispositivi mobili di connettersi a FCM in modo che i dispositivi sulla tua rete possano ricevere messaggi. FCM in genere utilizza la porta 5228, ma a volte utilizza 443, 5229 e 5230.

Per i dispositivi che si connettono alla tua rete, FCM non fornisce IP specifici perché il nostro intervallo di IP cambia troppo frequentemente e le regole del tuo firewall potrebbero diventare obsolete, con un impatto sull'esperienza degli utenti. Idealmente, la lista consentita porta 5228-5230 e 443 senza restrizioni IP. Tuttavia, se devi avere una restrizione IP, dovresti inserire nella lista consentita tutti gli indirizzi IP elencati in goog.json . Questo ampio elenco viene aggiornato regolarmente e si consiglia di aggiornare le regole su base mensile. I problemi causati dalle restrizioni IP del firewall sono spesso intermittenti e difficili da diagnosticare.

Offriamo una serie di nomi di dominio che possono essere inseriti nella lista consentita al posto degli indirizzi IP. Questi nomi host sono elencati di seguito. Se iniziamo a utilizzare nomi host aggiuntivi, aggiorneremo l'elenco qui. L'utilizzo dei nomi di dominio per la regola del firewall potrebbe essere o meno funzionale nel dispositivo firewall.

Porte TCP da aprire:

  • 5228
  • 5229
  • 5230
  • 443

Nomi host da aprire:

  • 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
  • dispositivo-provisioning.googleapis.com
  • firebaseinstallations.googleapis.com

Firewall Network Address Translation e/o Stateful Packet Inspection:

Se la tua rete implementa Network Address Translation (NAT) o Stateful Packet Inspection (SPI), implementa un timeout di 30 minuti o superiore per le nostre connessioni sulle porte 5228-5230. Questo ci consente di fornire una connettività affidabile riducendo il consumo della batteria dei dispositivi mobili dei tuoi utenti.

Credenziali

A seconda delle funzionalità FCM che implementi, potresti aver bisogno delle seguenti credenziali dal tuo progetto Firebase:

ID progetto Un identificatore univoco per il tuo progetto Firebase, utilizzato nelle richieste all'endpoint HTTP FCM v1. Questo valore è disponibile nel riquadro Impostazioni della console Firebase .
Token di registrazione

Una stringa di token univoca che identifica ogni istanza dell'app client. Il token di registrazione è richiesto per la messaggistica di un singolo dispositivo e di un gruppo di dispositivi. Tieni presente che i token di registrazione devono essere mantenuti segreti.

identità del mittente Un valore numerico univoco creato durante la creazione del progetto Firebase, disponibile nella scheda Messaggistica cloud del riquadro Impostazioni della console Firebase. L'ID mittente viene utilizzato per identificare ogni mittente che può inviare messaggi all'app client.
Token di accesso Un token OAuth 2.0 di breve durata che autorizza le richieste all'API HTTP v1. Questo token è associato a un account di servizio che appartiene al tuo progetto Firebase. Per creare e ruotare i token di accesso, segui i passaggi descritti in Autorizzare l'invio di richieste .
Chiave server (per protocolli legacy)

Una chiave del server che autorizza il server dell'app ad accedere ai servizi Google, incluso l'invio di messaggi tramite i protocolli legacy di Firebase Cloud Messaging. Ottieni la chiave del server quando crei il tuo progetto Firebase. Puoi visualizzarlo nella scheda Messaggistica cloud del riquadro Impostazioni della console Firebase.

Importante: non includere la chiave del server in nessun punto del codice client. Inoltre, assicurati di utilizzare solo le chiavi del server per autorizzare il server dell'app. Le chiavi Android, Apple e browser vengono rifiutate da FCM.