Informazioni sui messaggi FCM

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 messaggio

Con FCM, puoi inviare due tipi di messaggi ai client:

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

I messaggi di notifica contengono un set 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 payload di dati facoltativo. Il payload massimo per entrambi i tipi di messaggio è di 4000 byte, tranne quando si inviano messaggi dalla console Firebase, che applica un limite di 1024 caratteri.

	Usa lo scenario	Come spedire
Messaggio di notifica	FCM SDK mostra il messaggio ai dispositivi degli utenti finali per conto dell'app client quando è in esecuzione in background. In caso contrario, se l'app è in esecuzione in primo piano quando viene ricevuta la notifica, il codice dell'app determina il comportamento. I messaggi di notifica hanno un set predefinito di chiavi visibili all'utente e un payload di dati facoltativo di coppie chiave-valore personalizzate.	In un ambiente attendibile come Cloud Functions o il tuo server delle app, usa Admin SDK o FCM Server Protocols : imposta la chiave notification . Può avere un carico utile di dati facoltativo. Sempre pieghevole. Guarda alcuni esempi di visualizzazione delle notifiche e payload delle richieste di invio. Usa il compositore delle notifiche : inserisci il testo del messaggio, il titolo, ecc. e invia. Aggiungi payload di dati facoltativo 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 attendibile come Cloud Functions o il tuo server delle app, usa Admin SDK o FCM Server Protocols : imposta solo la chiave data .

Utilizza i messaggi di notifica quando desideri che l'SDK FCM gestisca la visualizzazione automatica di una notifica quando la tua app è in esecuzione in background. Utilizzare i messaggi di dati quando si desidera elaborare i messaggi con il proprio codice dell'app client.

FCM può inviare un messaggio di notifica che include un payload di dati facoltativo. In tali casi, FCM gestisce la visualizzazione del payload di notifica 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 programmazione utilizzando l'SDK di amministrazione o i protocolli FCM, impostare la chiave notification con il set predefinito necessario di opzioni valore-chiave 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 "Portugal vs. Denmark" e il testo "great match!" sul dispositivo:

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

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

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

• Oggetto di notifica del protocollo HTTP v1
• Payload di notifica del protocollo HTTP legacy
• Payload di notifica del protocollo XMPP

Messaggi di dati

Imposta la chiave appropriata con le 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 primo livello, o comune, che viene interpretato dai client su tutte le piattaforme che ricevono il messaggio. In ogni piattaforma, l'app client riceve il payload dei dati in una funzione di callback.

Crittografia per i messaggi di dati

L'Android Transport Layer (vedi architettura FCM ) utilizza la crittografia point-to-point. A seconda delle tue esigenze, puoi 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 Capillary o DTLS .

Messaggi di notifica con payload dati opzionale

Sia a livello di programmazione che tramite la console Firebase, puoi inviare messaggi di notifica che contengono un payload facoltativo di coppie chiave-valore personalizzate. Nel compositore Notifiche , utilizzare i Campi dati personalizzati in Opzioni avanzate .

Il comportamento dell'app quando si ricevono messaggi che includono sia notifiche che payload di dati dipende dal fatto che l'app sia in background o in primo piano, essenzialmente, se è attiva o meno al momento della ricezione.

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

Ecco un messaggio in formato JSON contenente sia la chiave 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

L'SDK Firebase Admin e il protocollo HTTP FCM v1 consentono entrambi alle richieste di messaggio 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 diverse piattaforme 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

Utilizza i campi comuni quando:

• Targeting delle 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:

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

Quando utilizzare i campi specifici della piattaforma

Utilizza i campi specifici della piattaforma quando desideri:

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

Ogni volta che vuoi inviare valori solo a piattaforme particolari, non usare campi comuni; utilizzare campi specifici della piattaforma. Ad esempio, per inviare una notifica solo alle piattaforme Apple e al web ma non ad Android, devi utilizzare due insiemi di campi separati, 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 campi specifici della piattaforma. Questo perché ogni piattaforma può interpretare il valore in modo leggermente diverso, ad esempio il time-to-live è 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 una lunga durata per le piattaforme Android e Web, mentre imposta la priorità dei messaggi APN (piattaforme Apple) su un valore basso
• imposta le chiavi appropriate per definire il risultato di un tocco dell'utente sulla notifica su Android e Apple - click_action e category , rispettivamente.

{
  "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 Creazione di richieste di invio .

Opzioni di consegna

FCM fornisce un set specifico di opzioni di consegna per i messaggi inviati ai dispositivi Android e consente opzioni simili sulle piattaforme Apple e sul Web. Ad esempio, il comportamento del messaggio "comprimibile" è supportato su Android tramite collapse_key di FCM, su Apple tramite apns-collapse-id e 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 recapitato 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 i messaggi di chat o i messaggi critici. Ad esempio, in un'app di messaggistica istantanea, vorresti recapitare 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 correttamente la situazione, 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ò archiviare contemporaneamente quattro diversi messaggi comprimibili per dispositivo, ciascuno con una chiave di compressione diversa. Se superi questo numero, FCM conserva solo quattro chiavi di compressione, senza alcuna garanzia su quali siano conservate.

I messaggi di argomento 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 l'app non debba usare messaggi non comprimibili. Tuttavia, se utilizzi messaggi comprimibili, ricorda che FCM consente l'utilizzo di un massimo di quattro diverse chiavi di compressione da parte di FCM per token di registrazione in un dato momento. Non devi superare questo numero o potrebbe causare conseguenze imprevedibili.

	Usa lo scenario	Come spedire
Non pieghevole	Ogni messaggio è importante per l'app client e deve essere recapitato.	Ad eccezione dei 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 dei 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 recapito ai messaggi downstream: priorità normale e alta. Sebbene il comportamento differisca leggermente tra le piattaforme, la consegna di messaggi con priorità normale e alta funziona in questo modo:

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

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

Ecco un esempio di un normale messaggio prioritario inviato tramite il protocollo FCM HTTP v1 per notificare a un abbonato a una rivista che sono disponibili nuovi contenuti per il download:

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

• Documentazione APN
• Imposta e gestisci la priorità dei messaggi (Android)
• Urgenza del messaggio push Web

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 memorizza 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 recapitato. 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 ad 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 essere una durata compresa tra 0 e 2.419.200 secondi (28 giorni) e corrisponde al periodo di tempo massimo durante il quale FCM archivia e tenta di recapitare il messaggio. Le richieste che non contengono questo campo hanno come impostazione predefinita il periodo massimo di quattro settimane.

Ecco alcuni possibili utilizzi di questa funzione:

• Video chat chiamate in arrivo
• Eventi di 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 time-to-live di 0 secondi. In altre parole, FCM garantisce il massimo impegno per i messaggi che devono essere consegnati "ora o mai più". Tieni presente che un valore time_to_live pari a 0 indica che i messaggi che non possono essere recapitati 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 app invia un messaggio a 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 limitazioni di limitazione, il messaggio viene recapitato immediatamente.

Se il dispositivo è connesso ma in Doze, FCM memorizza un messaggio a bassa priorità finché il dispositivo non esce da Doze. Ed è qui che gioca un ruolo il flag collapse_key : se c'è già un messaggio con la stessa chiave di collasso (e token di registrazione) memorizzato 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 il recapito futuro.

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 il valore di fabbrica), il messaggio alla fine scade e viene eliminato dall'archivio 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, consulta la dashboard dei rapporti FCM , che registra il numero di messaggi inviati e aperti su dispositivi Apple e Android, insieme ai dati relativi alle "impressioni" (notifiche visualizzate dagli utenti) per App Android.

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

Infine, quando FCM tenta di consegnare un messaggio al dispositivo e l'app è stata disinstallata, FCM scarta immediatamente quel messaggio e invalida il token di registrazione. I futuri tentativi 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 limiti per garantire che FCM fornisca un servizio scalabile per tutti i mittenti.

Limitazione dei messaggi comprimibile

Come descritto in precedenza, 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 con troppa frequenza, ritardiamo (limitiamo) i messaggi per ridurre l'impatto sulla batteria dell'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 a raffica elevata, i messaggi non comprimibili potrebbero essere la scelta giusta. Per tali messaggi, assicurarsi di includere il contenuto in tali messaggi al fine di ridurre il costo della batteria.

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

Limitazione del server XMPP

Limitiamo la velocità con cui puoi connetterti ai server FCM XMPP 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.

Tasso massimo di messaggi verso 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 picchi di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente tramite chat. Questo limite impedisce agli errori nell'invio della logica di scaricare inavvertitamente la batteria su un dispositivo.

Per iOS, restituiamo un errore quando la tariffa supera i limiti APN.

Limite del messaggio a monte

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

Limitiamo i messaggi in upstream per dispositivo a 1.000/minuto per proteggere dal consumo della batteria dovuto a un cattivo comportamento dell'app.

Limite messaggio argomento

La velocità di aggiunta/rimozione dell'abbonamento all'argomento è limitata a 3.000 QPS per progetto.

Per le velocità 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 dei messaggi non è istantaneo e quindi occasionalmente si verificano più fanout in corso contemporaneamente. Limitiamo a 1.000 il numero di fanout di messaggi simultanei per progetto. Successivamente, potremmo rifiutare ulteriori richieste di fanout o rinviare il fanout delle richieste fino al completamento di alcuni dei fanout già in corso.

Il tasso di fanout effettivo 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 è suddivisa 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à del tasso di fanout disponibile. Il modo consigliato per massimizzare la velocità di fanout è avere un solo fanout attivo in corso alla volta.

Porte FCM e 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 con FCM affinché i dispositivi sulla tua rete possano ricevere i messaggi. FCM utilizza in genere 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 IP cambia troppo frequentemente e le regole del tuo firewall potrebbero diventare obsolete, influenzando l'esperienza degli utenti. Idealmente, consenti le porte 5228-5230 e 443 senza restrizioni IP. Tuttavia, se è necessario disporre di una restrizione IP, è necessario 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 inclusi 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 può o non può essere 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
• device-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 almeno 30 minuti 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 di 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 è necessario per la messaggistica di un singolo dispositivo e di un gruppo di dispositivi. Si noti che i token di registrazione devono essere tenuti segreti.
identità del mittente	Un valore numerico univoco creato quando crei il tuo progetto Firebase, disponibile nella scheda Cloud Messaging del riquadro Impostazioni della console Firebase. L'ID mittente viene usato 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, seguire i passaggi descritti in Autorizzare le richieste di invio .
Chiave del server (per protocolli legacy)	Una chiave del server che autorizza il tuo server dell'app ad accedere ai servizi Google, incluso l'invio di messaggi tramite i protocolli precedenti di Firebase Cloud Messaging. Ottieni la chiave del server quando crei il tuo progetto Firebase. Puoi visualizzarlo nella scheda Cloud Messaging 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 tuo server delle applicazioni. Le chiavi per Android, piattaforma Apple e browser vengono rifiutate da FCM.