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 le possibili modalità di utilizzo.
Tipi di messaggi
Con FCM, puoi inviare due tipi di messaggi ai client:
- Messaggi di notifica, a volte chiamati "messaggi di visualizzazione". che 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 coppie chiave-valore personalizzate definite dall'utente. I messaggi di notifica possono contenere un payload dei dati facoltativo. Il payload massimo per entrambi i tipi di messaggi è di 4096 byte, tranne quando si inviano messaggi dalla console Firebase, che applica un limite di 1000 caratteri.
| Utilizza scenario | Modalità di invio | |
|---|---|---|
| Messaggio di notifica | L'SDK FCM mostra il messaggio ai dispositivi degli utenti finali per conto dell'app client quando è in esecuzione in background. Altrimenti, se l'app è in esecuzione in primo piano quando viene ricevuta la notifica, il comportamento dell'app dipende dal codice. I messaggi di notifica hanno un insieme predefinito di chiavi visibili all'utente e un payload facoltativo di coppie chiave-valore personalizzate. |
|
| Messaggio di dati | L'app client è responsabile del trattamento dei messaggi di dati. I messaggi di dati hanno solo coppie chiave-valore personalizzate senza nomi di chiave riservati (vedi di seguito). | In un ambiente attendibile come
Cloud Functions o il tuo server delle app, utilizza SDK Admin o i protocolli FCM Server. Nella richiesta di invio, imposta la chiave data.
|
Utilizza i messaggi di notifica quando vuoi che l'SDK FCM gestisca la visualizzazione automatica di una notifica quando la tua app è in esecuzione in background. Utilizza i messaggi di dati quando vuoi elaborare i messaggi con il tuo codice dell'app client.
FCM può inviare un messaggio di notifica che includa un payload dei dati facoltativo. In questi casi, FCM gestisce la visualizzazione del payload di notifica e l'app client gestisce il payload dei dati.
Messaggi di notifica
A scopo di test o per il marketing e il ricoinvolgimento 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 in modo programmatico utilizzando l'SDK Admin o i protocolli FCM, imposta la chiave 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 immediata. L'utente può aspettarsi di visualizzare un messaggio con il titolo "Portogallo - Danimarca" e il testo "Grande corrispondenza!" sul dispositivo:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
}
}
}
I messaggi di notifica vengono recapitati nella barra delle notifiche quando l'app è in background. Per le app in primo piano, i messaggi sono gestiti da una funzione di callback.
Consulta la documentazione di riferimento sull'oggetto di notifica del protocollo HTTP v1 per l'elenco completo delle chiavi predefinite disponibili per la creazione di messaggi di notifica.
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 IM dell'esempio precedente,
in cui le informazioni sono incapsulate nella chiave data comune e
l'app client deve interpretare i contenuti:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"data":{
"Nick" : "Mario",
"body" : "great match!",
"Room" : "PortugalVSDenmark"
}
}
}
L'esempio riportato sopra mostra l'utilizzo del campo data di primo livello, o comune, che viene interpretato dai client su tutte le piattaforme che ricevono il messaggio.
Su ogni piattaforma, l'app client riceve il payload dei dati in una funzione di callback.
Crittografia dei messaggi di dati
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 offre una soluzione end-to-end. Tuttavia, sono disponibili soluzioni esterne, come Capillary o DTLS.
Messaggi di notifica con payload facoltativo per i dati
Sia in modo programmatico che tramite la console Firebase, puoi inviare messaggi di notifica contenenti un payload facoltativo di coppie chiave-valore personalizzate. Nel Composer delle notifiche, utilizza i campi Dati personalizzati in Opzioni avanzate.
Il comportamento delle app durante la ricezione di messaggi che includono payload sia di notifica sia di dati dipende dal fatto che l'app sia in background o in primo piano, ovvero se è 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 notification sia la chiave data:
{
"message":{
"token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
"notification":{
"title":"Portugal vs. Denmark",
"body":"great match!"
},
"data" : {
"Nick" : "Mario",
"Room" : "PortugalVSDenmark"
}
}
}
Personalizzare un messaggio su più piattaforme
L'SDK Firebase Admin e il protocollo HTTP FCM v1 consentono alle richieste di messaggi di impostare tutti i campi disponibili nell'oggetto message. Include:
- un insieme comune di campi che deve essere interpretato da tutte le istanze dell'app che ricevono il messaggio.
- insiemi di campi specifici per piattaforma, come
AndroidConfigeWebpushConfig, interpretati solo dalle istanze dell'app in esecuzione sulla piattaforma specificata.
I blocchi specifici per piattaforma ti offrono la flessibilità di personalizzare i messaggi per piattaforme diverse per assicurarti che vengano gestiti correttamente al momento della ricezione. Il backend FCM prende in considerazione tutti i parametri specificati e personalizza il messaggio per ogni piattaforma.
Quando utilizzare i campi comuni
Utilizza i campi comuni quando:
- Targeting di istanze di 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
Utilizza i campi specifici per piattaforma quando vuoi:
- Invia i campi solo a determinate piattaforme
- Invia campi specifici per la piattaforma oltre ai campi comuni
Ogni volta che vuoi inviare valori solo a piattaforme specifiche, non utilizzare campi comuni, ma 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 recapito specifiche, utilizza campi specifici della piattaforma per impostarle. Se vuoi, puoi specificare valori diversi per piattaforma. Tuttavia, anche se vuoi impostare sostanzialmente lo stesso valore su più piattaforme, devi utilizzare campi specifici per piattaforma. Questo perché ogni piattaforma potrebbe interpretare il valore in modo leggermente diverso: ad esempio, la durata è impostata su Android come una scadenza in secondi, mentre su Apple 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 anche alcuni override specifici della piattaforma. Nello specifico, la richiesta:
- imposta una durata prolungata per le piattaforme Android e web, impostando al contempo la priorità dei messaggi per gli APN (piattaforme Apple) su un'impostazione bassa
- imposta i tasti appropriati per definire il risultato del tocco dell'utente sulla notifica su Android e Apple: rispettivamente
click_actionecategory.
{
"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 maggiori informazioni sulla creazione di richieste di invio che contengono il corpo del messaggio, consulta Creare richieste di invio.
Opzioni di consegna
FCM offre un insieme specifico di opzioni di recapito 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 maggiori dettagli, consulta 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 contenuti all'app mobile per contattare il server e 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 immediata vorresti recapitare ogni messaggio, perché ogni messaggio ha contenuti diversi.
Per Android esiste un limite di 100 messaggi che possono essere archiviati senza comprimere. Se viene raggiunto il limite, tutti i messaggi archiviati 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 al server delle app.
Un messaggio comprimibile è un messaggio che può essere sostituito da un nuovo messaggio se non è ancora stato recapitato 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 di sport che aggiorna gli utenti con l'ultimo risultato. È pertinente solo il messaggio più recente.
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, ognuno con una chiave di compressione diversa. Se superi questo numero, FCM conserva solo quattro chiavi di compressione, senza alcuna garanzia su quali vengono conservate.
I messaggi degli argomenti senza payload sono comprimibili per impostazione predefinita. I messaggi di notifica
sono sempre comprimibili e il parametro collapse_key viene ignorato.
Quale devo utilizzare?
I messaggi comprimibili sono una scelta migliore dal punto di vista delle prestazioni, a condizione che la tua app non abbia bisogno di utilizzare messaggi non comprimibili. Tuttavia, se utilizzi messaggi comprimibili, tieni presente che FCM consente l'utilizzo di un massimo di quattro chiavi di compressione diverse per token di registrazione in un determinato momento. Non devi superare questo numero per evitare conseguenze imprevedibili.
| Utilizza scenario | Modalità di invio | |
|---|---|---|
| Non comprimibili | Ogni messaggio è importante per l'app client e deve essere consegnato. | Per impostazione predefinita, tutti i messaggi, fatta eccezione per i messaggi di notifica, non sono comprimibili. |
| Ripiegabili | Quando è presente un messaggio più recente che esegue il rendering di un messaggio correlato meno recente non pertinente all'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 richiesta di messaggio:
|
Impostare la priorità di un messaggio
Sono disponibili due opzioni per assegnare la priorità di consegna ai messaggi downstream: normale e alta. Anche se il comportamento varia leggermente da una piattaforma all'altra, la consegna di messaggi normali e ad alta priorità funziona come segue:
Priorità normale. I messaggi con priorità normale vengono recapitati immediatamente quando l'app è in primo piano. Per le app in background, il caricamento potrebbe subire ritardi. Per i messaggi meno urgenti, ad esempio le notifiche di nuove email, il mantenimento della sincronizzazione dell'interfaccia utente o la sincronizzazione dei dati dell'app in background, scegli la normale priorità di consegna.
Priorità alta. FCM tenta di recapitare immediatamente i messaggi ad alta priorità anche se il dispositivo è in modalità Sospensione. I messaggi ad alta priorità sono per contenuti sensibili al momento e visibili agli utenti.
Ecco un esempio di un normale messaggio con priorità inviato tramite il protocollo FCM HTTP v1 per informare 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 relativa agli APN
- Impostare e gestire la priorità dei messaggi (Android)
- Urgenza dei messaggi push web
Impostare la durata di un messaggio
In genere, FCM 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.
In questi casi, FCM archivia il messaggio e lo consegna non appena è possibile. Anche se nella maggior parte dei casi questo non va bene, esistono alcune app per le quali un messaggio tardivo potrebbe non essere mai recapitato. Ad esempio, se il messaggio è una notifica di chiamata in arrivo o di una chat video, sarà 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 viene ricevuto al termine dell'evento.
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 cui FCM archivia e tenta di recapitare il messaggio. Per impostazione predefinita, le richieste che non contengono questo campo vengono impostate sul periodo massimo di quattro settimane.
Ecco alcuni possibili utilizzi di questa funzionalità:
- Chiamate in arrivo della chat video
- Eventi di invito in scadenza
- Eventi nel calendario
Un altro vantaggio della specifica della durata di un messaggio è che FCM non applica la limitazione dei messaggi comprimibili ai messaggi con un valore di durata pari a 0 secondi.
FCM offre la migliore gestione possibile per i messaggi che devono essere recapitati "ora o mai". Tieni presente che un valore time_to_live pari a 0 significa che i messaggi che non possono essere recapitati immediatamente vengono eliminati. Tuttavia, poiché questi messaggi non vengono mai archiviati, offre la migliore latenza per l'invio dei messaggi di notifica.
Ecco un esempio di richiesta che include il 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 app server pubblica un messaggio in 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 l'accettazione dipende da molti fattori.
Nel migliore dei casi, se il dispositivo è connesso a FCM, lo schermo è attivo e non sono presenti limitazioni di limitazione, il messaggio viene recapitato immediatamente.
Se il dispositivo è connesso ma in modalità Sospensione, FCM archivia un messaggio con priorità bassa finché il dispositivo non disattiva questa modalità. Ed è qui che gioca il flag collapse_key: se esiste già un messaggio con la stessa chiave di compressione (e token di registrazione) archiviato e in attesa di consegna, il messaggio precedente viene ignorato e quello nuovo sostituisce quello nuovo (ossia, quello nuovo viene compresso da quello nuovo). Tuttavia, se la chiave di compressione non è impostata, i messaggi nuovi e precedenti vengono archiviati per il recapito futuro.
Se il dispositivo non è connesso a FCM, il messaggio viene archiviato finché non viene stabilita una connessione (rispettando sempre le regole relative alle chiavi di compressione). Quando viene stabilita una connessione, FCM recapita tutti i messaggi in attesa al dispositivo. Se il dispositivo non si riconnette mai
(ad esempio in caso di ripristino dei dati di fabbrica), il messaggio scade e
viene eliminato dallo spazio di archiviazione FCM. Il timeout predefinito è di quattro settimane, a meno che non sia impostato il flag time_to_live.
Per avere maggiori informazioni sulla consegna di un messaggio:
Per ottenere maggiori informazioni sul recapito dei messaggi sulle piattaforme Android o Apple, consulta la dashboard dei report FCM, che registra il numero di messaggi inviati e aperti sui dispositivi Apple e Android, insieme ai dati relativi alle "impressioni" (notifiche visualizzate dagli utenti) per le app per Android.
Per i dispositivi Android in cui è abilitata la messaggistica diretta sul canale, se il dispositivo non si connette a FCM da 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 client riceve il callback onDeletedMessages(). L'app può quindi gestire correttamente la situazione, in genere richiedendo una sincronizzazione completa al server delle app.
Infine, quando FCM tenta di recapitare un messaggio al dispositivo e l'app è stata disinstallata, FCM elimina immediatamente il messaggio e annulla la validità del token di registrazione. Tentativi futuri di inviare un messaggio a quel
dispositivo comportano un errore NotRegistered.
Limitazione e scalabilità
Il nostro obiettivo è recapitare sempre ogni messaggio inviato tramite FCM. Tuttavia, recapitare ogni messaggio a volte comporta un'esperienza utente complessiva scadente. In altri casi, è necessario specificare dei limiti per garantire che FCM fornisca un servizio scalabile per tutti i mittenti.
Limitazione dei messaggi comprimibili
Come spiegato in precedenza, i messaggi comprimibili sono notifiche senza contenuto progettate per comprimersi una sull'altra. Se uno sviluppatore ripete troppo spesso lo stesso messaggio a un'app, ritardiamo (limitare) i messaggi per ridurre l'impatto sulla batteria dell'utente.
Ad esempio, se invii un numero elevato di nuove richieste di sincronizzazione dell'email a un singolo dispositivo, potremmo ritardare di alcuni minuti la richiesta di sincronizzazione dell'email successiva, in modo che il dispositivo possa sincronizzarsi a una velocità media inferiore. Questa limitazione viene eseguita rigorosamente per limitare l'impatto sulla batteria sperimentato dall'utente.
Se il tuo caso d'uso richiede pattern di invio a raffica elevati, i messaggi non comprimibili potrebbero essere la scelta giusta. Per questi messaggi, assicurati di includere i contenuti al loro interno per ridurre il costo della batteria.
Limitiamo i messaggi comprimibili a una serie di 20 messaggi per app per dispositivo, con una ricarica ogni 3 minuti.
Limitazione del server XMPP
La frequenza di connessione ai server FCM XMPP è limitata 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 sistema. Per ogni progetto, FCM consente 2500 connessioni in parallelo.
Per la messaggistica upstream con XMPP, FCM limita i messaggi upstream a 1.500.000 al minuto per progetto per evitare il sovraccarico dei server di destinazione upstream.
Limitiamo i messaggi upstream per dispositivo a 1000 al minuto per evitare che la batteria si scarichi a causa di comportamenti dannosi dell'app.
Frequenza massima di messaggi per un singolo dispositivo
Per Android puoi inviare fino a 240 messaggi al minuto e 5000 messaggi all'ora a un singolo dispositivo. Questa soglia alta è pensata per consentire picchi di traffico a breve termine, ad esempio quando gli utenti interagiscono rapidamente in chat. Questo limite impedisce che gli errori nella logica di invio consumino inavvertitamente la batteria di un dispositivo.
Per iOS, viene restituito un errore quando la frequenza supera i limiti previsti per gli APN.
Limite messaggi argomento
La percentuale di aggiunta/rimozione della sottoscrizione all'argomento è limitata a 3000 QPS per progetto.
Per le percentuali di invio dei messaggi, consulta la pagina relativa alla limitazione dei fan.
Limitazione del fanout
Il fanout dei messaggi è il processo di invio di un messaggio a più dispositivi, ad esempio quando scegli come target argomenti e gruppi o quando utilizzi lo strumento di scrittura delle notifiche per scegliere come target segmenti di pubblico o segmenti di utenti.
Il fanout dei messaggi non è istantaneo, pertanto a volte potresti avere più fanout in corso contemporaneamente. Limitiamo il numero di fanout di messaggi simultanei per progetto a 1000. Successivamente, potremmo rifiutare ulteriori richieste di fanout o rinviare il fan-out delle richieste fino al completamento di alcuni di quelli già in corso.
Il tasso di fanout effettivo raggiungibile è influenzato dal numero di progetti che richiedono contemporaneamente i fanout. Una velocità di fanout pari a 10.000 QPS per un singolo progetto non è rara, ma questo numero non è una garanzia ed è il risultato del carico totale sul sistema. È importante notare che la capacità di fanout disponibile viene suddivisa tra progetti e non tra richieste di fanout. Quindi, se il progetto ha due fanout in corso, ogni fanout vedrà solo la metà della percentuale di fanout disponibile. Il metodo consigliato per massimizzare la velocità dei fanout è quello di avere un solo fanout attivo alla volta.
Porte FCM e firewall
Se la tua organizzazione dispone di un firewall per limitare il traffico da o verso internet, devi configurarlo in modo che consenta ai dispositivi mobili di connettersi a FCM affinché i dispositivi sulla rete ricevano messaggi. In genere FCM utilizza la porta 5228, ma a volte utilizza le porte 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 spesso e le regole firewall potrebbero diventare obsolete, influenzando l'esperienza dei tuoi utenti. Idealmente, aggiungi alla lista consentita le porte 5228-5230 e 443 senza restrizioni IP. Tuttavia, se devi disporre di una restrizione IP, devi autorizzare tutti gli indirizzi IP elencati in goog.json. Questo lungo elenco viene aggiornato regolarmente e ti consigliamo di aggiornare le regole su base mensile. I problemi causati dalle restrizioni IP del firewall sono spesso intermittenti e difficili da diagnosticare.
Offriamo un insieme 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 altri nomi host, aggiorneremo l'elenco qui. L'utilizzo di nomi di dominio per la regola firewall potrebbe funzionare o meno 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 Inspectorion (SPI), implementa un timeout di almeno 30 minuti per le nostre connessioni sulle porte 5228-5230. Questo ci consente di offrire una connettività affidabile riducendo al contempo il consumo della batteria dei dispositivi mobili dei tuoi utenti.
Interazioni con la VPN e possibilità di bypass
Firebase Cloud Messaging prevede varie misure per garantire che la connessione per i messaggi push dal telefono al server sia affidabile e disponibile il più spesso possibile. L'utilizzo di una VPN complica questo sforzo.
Le VPN mascherano le informazioni sottostanti di cui FCM ha bisogno per ottimizzare la propria connessione per massimizzare l'affidabilità e la durata della batteria. In alcuni casi le VPN interrompono attivamente le connessioni di lunga durata, il che genera un'esperienza utente negativa a causa di messaggi persi o in ritardo o a un costo elevato della batteria. Se la VPN è configurata in modo da consentirne l'utilizzo, aggiriamo la VPN utilizzando una connessione criptata (tramite la rete Wi-Fi o LTE di base) in modo da garantire un'esperienza affidabile e rispettosa della batteria. L'utilizzo da parte di FCM di VPN ignorabili è specifico del canale di notifiche push di FCM. Altro traffico FCM, ad esempio il traffico di registrazione, utilizza la VPN se è attiva. Quando la connessione FCM ignora la VPN, perde gli ulteriori vantaggi offerti dalla VPN, come il mascheramento degli indirizzi IP.
VPN diverse avranno metodi diversi per controllare se può essere bypassata o meno. Per istruzioni, consulta la documentazione della tua VPN specifica.
Se la VPN non è configurata per essere ignorabile, Firebase Cloud Messaging utilizzerà la rete VPN per connettersi al server. Ciò potrebbe comportare periodi di ritardo dei messaggi, con un conseguente aumento dell'utilizzo della batteria mentre Cloud Messaging mantiene la connessione attraverso la connessione VPN.
Credenziali
A seconda delle funzionalità FCM implementate, potrebbero essere necessarie le seguenti credenziali del 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 token univoca che identifica ogni istanza dell'app client. Il token di registrazione è necessario per la messaggistica di singoli dispositivi e gruppi di dispositivi. Tieni presente che i token di registrazione devono essere tenuti segreti. |
| ID mittente | Un valore numerico univoco creato durante la creazione del progetto Firebase, disponibile nella scheda Cloud Messaging 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 le richieste di invio. |
| Chiave server (per protocolli precedenti **deprecati**) | Una chiave server che autorizza il server dell'app ad accedere ai servizi Google, incluso l'invio di messaggi tramite i protocolli legacy Firebase Cloud Messaging deprecati. Importante: non includere la chiave server in nessun punto del codice client. Inoltre, assicurati di utilizzare solo chiavi server per autorizzare il server delle app. Le chiavi del browser, di Android e della piattaforma Apple vengono rifiutate da FCM. |