Ikuti semua informasi yang diumumkan di Firebase Summit, dan pelajari bagaimana Firebase dapat membantu Anda mempercepat pengembangan aplikasi dan menjalankan aplikasi dengan percaya diri. Pelajari Lebih Lanjut

Tentang pesan FCM

Firebase Cloud Messaging (FCM) menawarkan berbagai opsi dan kemampuan pengiriman pesan. Informasi di halaman ini dimaksudkan untuk membantu Anda memahami berbagai jenis pesan FCM dan apa yang dapat Anda lakukan dengannya.

Jenis pesan

Dengan FCM, Anda dapat mengirim dua jenis pesan ke klien:

  • Pesan notifikasi, terkadang dianggap sebagai "pesan tampilan". Ini ditangani oleh FCM SDK secara otomatis.
  • Pesan data, yang ditangani oleh aplikasi klien.

Pesan notifikasi berisi kumpulan kunci yang dapat dilihat pengguna yang telah ditentukan sebelumnya. Pesan data, sebaliknya, hanya berisi pasangan nilai kunci khusus yang ditentukan pengguna. Pesan notifikasi dapat berisi payload data opsional. Payload maksimum untuk kedua jenis pesan adalah 4000 byte, kecuali saat mengirim pesan dari Firebase console, yang memberlakukan batas 1024 karakter.

Gunakan skenario Bagaimana cara mengirim
Pesan pemberitahuan FCM secara otomatis menampilkan pesan ke perangkat pengguna akhir atas nama aplikasi klien. Pesan notifikasi memiliki kumpulan kunci yang dapat dilihat pengguna dan payload data opsional dari pasangan nilai kunci khusus.
  1. Di lingkungan tepercaya seperti Cloud Functions atau server aplikasi Anda, gunakan Admin SDK atau FCM Server Protocols : Setel kunci notification . Mungkin memiliki muatan data opsional. Selalu bisa dilipat.

    Lihat beberapa contoh pemberitahuan tampilan dan kirim muatan permintaan.

  2. Gunakan Notifications composer : Masukkan Teks Pesan, Judul, dll., dan kirim. Tambahkan payload data opsional dengan menyediakan data Kustom.
pesan data Aplikasi klien bertanggung jawab untuk memproses pesan data. Pesan data hanya memiliki pasangan nilai kunci khusus tanpa nama kunci yang dicadangkan (lihat di bawah). Di lingkungan tepercaya seperti Cloud Functions atau server aplikasi Anda, gunakan Admin SDK atau FCM Server Protocols : Setel kunci data saja.

Gunakan pesan notifikasi saat Anda ingin FCM menangani tampilan notifikasi atas nama aplikasi klien Anda. Gunakan pesan data saat Anda ingin memproses pesan di aplikasi klien Anda.

FCM dapat mengirim pesan notifikasi termasuk payload data opsional. Dalam kasus seperti itu, FCM menangani tampilan payload notifikasi, dan aplikasi klien menangani payload data.

Pesan pemberitahuan

Untuk pengujian atau untuk pemasaran dan interaksi kembali pengguna, Anda dapat mengirim pesan notifikasi menggunakan Firebase console . Konsol Firebase menyediakan pengujian A/B berbasis analitik untuk membantu Anda menyempurnakan dan menyempurnakan pesan pemasaran.

Untuk mengirim pesan notifikasi secara terprogram menggunakan Admin SDK atau protokol FCM, setel kunci notification dengan kumpulan opsi nilai kunci yang telah ditentukan sebelumnya yang diperlukan untuk bagian pesan notifikasi yang terlihat oleh pengguna. Misalnya, berikut adalah pesan notifikasi berformat JSON di aplikasi IM. Pengguna dapat mengharapkan untuk melihat pesan dengan judul "Portugal vs. Denmark" dan teks "cocok!" pada perangkat:

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

Pesan notifikasi dikirim ke baki notifikasi saat aplikasi berada di latar belakang. Untuk aplikasi di latar depan, pesan ditangani oleh fungsi panggilan balik.

Lihat dokumentasi referensi untuk daftar lengkap kunci standar yang tersedia untuk membuat pesan notifikasi:

Pesan data

Setel kunci yang sesuai dengan pasangan nilai kunci khusus Anda untuk mengirim payload data ke aplikasi klien.

Misalnya, berikut adalah pesan berformat JSON di aplikasi IM yang sama seperti di atas, di mana informasinya dienkapsulasi dalam kunci data umum dan aplikasi klien diharapkan untuk menginterpretasikan konten:

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

Contoh di atas menunjukkan penggunaan tingkat atas, atau bidang data umum, yang ditafsirkan oleh klien di semua platform yang menerima pesan. Pada setiap platform, aplikasi klien menerima payload data dalam fungsi callback.

Enkripsi untuk pesan data

Lapisan Transport Android (lihat arsitektur FCM ) menggunakan enkripsi titik-ke-titik. Tergantung pada kebutuhan Anda, Anda dapat memutuskan untuk menambahkan enkripsi ujung ke ujung ke pesan data. FCM tidak memberikan solusi ujung ke ujung. Namun, ada solusi eksternal yang tersedia seperti Capillary atau DTLS .

Pesan pemberitahuan dengan muatan data opsional

Baik secara terprogram atau melalui Firebase console, Anda dapat mengirim pesan notifikasi yang berisi payload opsional dari pasangan nilai kunci khusus. Di Notifications composer , gunakan bidang Data khusus di Opsi lanjutan .

Perilaku aplikasi saat menerima pesan yang menyertakan pemberitahuan dan muatan data bergantung pada apakah aplikasi berada di latar belakang atau latar depan—pada dasarnya, apakah aplikasi aktif pada saat diterima atau tidak.

  • Saat berada di latar belakang , aplikasi menerima muatan notifikasi di baki notifikasi, dan hanya menangani muatan data saat pengguna mengetuk notifikasi.
  • Saat berada di latar depan , aplikasi Anda menerima objek pesan dengan kedua muatan tersedia.

Berikut adalah pesan berformat JSON yang berisi kunci notification dan kunci data :

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

Menyesuaikan pesan di seluruh platform

Firebase Admin SDK dan protokol HTTP FCM v1 memungkinkan permintaan pesan Anda untuk menyetel semua bidang yang tersedia di objek message . Ini termasuk:

  • kumpulan bidang umum untuk ditafsirkan oleh semua instance aplikasi yang menerima pesan.
  • kumpulan bidang khusus platform, seperti AndroidConfig dan WebpushConfig , hanya ditafsirkan oleh instance aplikasi yang berjalan pada platform yang ditentukan.

Blok khusus platform memberi Anda fleksibilitas untuk menyesuaikan pesan untuk platform yang berbeda untuk memastikan bahwa pesan tersebut ditangani dengan benar saat diterima. Backend FCM akan mempertimbangkan semua parameter yang ditentukan dan menyesuaikan pesan untuk setiap platform.

Kapan harus menggunakan bidang umum

Gunakan bidang umum saat Anda:

  • Menargetkan instans aplikasi di semua platform — Apple, Android, dan web
  • Mengirim pesan ke topik

Semua instance aplikasi, apa pun platformnya, dapat menafsirkan bidang umum berikut:

Kapan menggunakan bidang khusus platform

Gunakan bidang khusus platform saat Anda ingin:

  • Kirim bidang hanya ke platform tertentu
  • Kirim bidang khusus platform selain bidang umum

Kapan pun Anda ingin mengirim nilai hanya ke platform tertentu, jangan gunakan bidang umum; gunakan bidang khusus platform. Misalnya, untuk mengirim pemberitahuan hanya ke platform dan web Apple tetapi tidak ke Android, Anda harus menggunakan dua kumpulan bidang yang terpisah, satu untuk Apple dan satu untuk web.

Saat Anda mengirim pesan dengan opsi pengiriman tertentu , gunakan bidang khusus platform untuk menyetelnya. Anda dapat menentukan nilai yang berbeda per platform jika Anda mau. Namun, bahkan ketika Anda ingin menetapkan nilai yang pada dasarnya sama di seluruh platform, Anda harus menggunakan bidang khusus platform. Ini karena setiap platform mungkin menginterpretasikan nilainya sedikit berbeda—misalnya, time-to-live disetel di Android sebagai waktu kedaluwarsa dalam hitungan detik, sedangkan di Apple ditetapkan sebagai tanggal kedaluwarsa .

Contoh: pesan notifikasi dengan opsi pengiriman khusus platform

Permintaan pengiriman v1 berikut mengirimkan judul dan konten pemberitahuan umum ke semua platform, tetapi juga mengirimkan beberapa penggantian khusus platform. Secara khusus, permintaan:

  • menyetel waktu aktif yang lama untuk platform Android dan Web, sementara menyetel prioritas pesan APN (platform Apple) ke setelan rendah
  • menyetel tombol yang sesuai untuk menentukan hasil ketukan pengguna pada notifikasi di Android dan Apple — click_action , dan category , masing-masing.
{
  "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"
       }
     }
   }
 }

Lihat dokumentasi referensi HTTP v1 untuk detail lengkap tentang kunci yang tersedia di blok khusus platform di badan pesan. Untuk informasi selengkapnya tentang membuat permintaan pengiriman yang berisi isi pesan, lihat Membuat Permintaan Kirim .

Pilihan pengiriman

FCM menyediakan serangkaian opsi pengiriman khusus untuk pesan yang dikirim ke perangkat Android, dan memungkinkan opsi serupa di platform dan web Apple. Misalnya, perilaku pesan "dapat diciutkan" didukung di Android melalui collapse_key FCM, di Apple melalui apns-collapse-id , dan di JavaScript/Web melalui Topic . Untuk detailnya, lihat deskripsi di bagian ini dan dokumentasi referensi terkait.

Pesan yang tidak dapat diciutkan dan diciutkan

Pesan yang tidak dapat diciutkan menunjukkan bahwa setiap pesan individual dikirim ke perangkat. Pesan yang tidak dapat diciutkan memberikan beberapa konten yang berguna, berbeda dengan pesan yang dapat diciutkan seperti "ping" bebas konten ke aplikasi seluler untuk menghubungi server guna mengambil data.

Beberapa kasus penggunaan umum dari pesan yang tidak dapat diciutkan adalah pesan obrolan atau pesan penting. Misalnya, dalam aplikasi IM, Anda ingin mengirimkan setiap pesan, karena setiap pesan memiliki konten yang berbeda.

Untuk Android ada batas 100 pesan yang dapat disimpan tanpa diciutkan. Jika batas tercapai, semua pesan yang disimpan akan dibuang. Ketika perangkat kembali online, ia menerima pesan khusus yang menunjukkan bahwa batas telah tercapai. Aplikasi kemudian dapat menangani situasi dengan benar, biasanya dengan meminta sinkronisasi penuh dari server aplikasi.

Pesan yang dapat diciutkan adalah pesan yang dapat diganti dengan pesan baru jika belum dikirim ke perangkat.

Kasus penggunaan umum dari pesan yang dapat diciutkan adalah pesan yang digunakan untuk memberi tahu aplikasi seluler agar menyinkronkan data dari server. Contohnya adalah aplikasi olahraga yang memperbarui pengguna dengan skor terbaru. Hanya pesan terbaru yang relevan.

Untuk menandai pesan sebagai dapat diciutkan di Android, sertakan parameter collapse_key di payload pesan. Secara default, kunci penciutan adalah nama paket aplikasi yang terdaftar di konsol Firebase. Server FCM dapat secara bersamaan menyimpan empat pesan berbeda yang dapat diciutkan per perangkat, masing-masing dengan kunci penciutan yang berbeda. Jika Anda melebihi jumlah ini, FCM hanya menyimpan empat kunci penciutan, tanpa jaminan tentang kunci mana yang disimpan.

Pesan topik tanpa muatan dapat diciutkan secara default. Pesan notifikasi selalu dapat diciutkan dan akan mengabaikan parameter collapse_key .

Yang mana yang harus saya gunakan?

Pesan yang dapat diciutkan adalah pilihan yang lebih baik dari sudut pandang kinerja, asalkan aplikasi Anda tidak perlu menggunakan pesan yang tidak dapat diciutkan. Namun, jika Anda menggunakan pesan yang dapat diciutkan, ingatlah bahwa FCM hanya mengizinkan maksimal empat kunci penciutan yang berbeda untuk digunakan oleh FCM per token pendaftaran pada waktu tertentu. Anda tidak boleh melebihi jumlah ini, atau ini dapat menyebabkan konsekuensi yang tidak terduga.

Gunakan skenario Bagaimana cara mengirim
Tidak bisa dilipat Setiap pesan penting untuk aplikasi klien dan perlu disampaikan. Kecuali untuk pesan notifikasi, semua pesan tidak dapat diciutkan secara default.
Bisa dilipat Saat ada pesan baru yang membuat pesan lama dan terkait tidak relevan dengan aplikasi klien, FCM akan menggantikan pesan lama. Misalnya: pesan yang digunakan untuk memulai sinkronisasi data dari server, atau pesan pemberitahuan usang. Tetapkan parameter yang sesuai dalam permintaan pesan Anda:
  • collapseKey di Android
  • apns-collapse-id di Apple
  • Topic di Web
  • collapse_key dalam protokol lama (semua platform)

Mengatur prioritas pesan

Anda memiliki dua opsi untuk menetapkan prioritas pengiriman ke pesan downstream: normal dan prioritas tinggi. Meskipun perilakunya sedikit berbeda di seluruh platform, pengiriman pesan normal dan berprioritas tinggi berfungsi seperti ini:

  • Prioritas biasa. Pesan prioritas normal segera dikirim saat aplikasi berada di latar depan. Untuk aplikasi di latar belakang, pengiriman mungkin tertunda. Untuk pesan yang tidak terlalu sensitif terhadap waktu, seperti pemberitahuan email baru, menjaga UI tetap sinkron, atau menyinkronkan data aplikasi di latar belakang, pilih prioritas pengiriman normal.

  • Prioritas utama. FCM mencoba mengirimkan pesan prioritas tinggi dengan segera meskipun perangkat dalam mode Istirahatkan. Pesan prioritas tinggi adalah untuk konten yang sensitif terhadap waktu dan terlihat oleh pengguna.

Berikut adalah contoh pesan prioritas normal yang dikirim melalui protokol FCM HTTP v1 untuk memberi tahu pelanggan majalah bahwa konten baru tersedia untuk diunduh:

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

Untuk detail lebih spesifik platform tentang pengaturan prioritas pesan:

Mengatur umur pesan

FCM biasanya mengirimkan pesan segera setelah dikirim. Namun, ini mungkin tidak selalu memungkinkan. Misalnya, jika platformnya adalah Android, perangkat dapat dimatikan, offline, atau tidak tersedia. Atau FCM mungkin sengaja menunda pesan untuk mencegah aplikasi menghabiskan sumber daya yang berlebihan dan memengaruhi masa pakai baterai secara negatif.

Ketika ini terjadi, FCM menyimpan pesan dan mengirimkannya sesegera mungkin. Meskipun ini baik-baik saja dalam banyak kasus, ada beberapa aplikasi yang pesan terlambatnya mungkin tidak akan pernah terkirim. Misalnya, jika pesan tersebut adalah panggilan masuk atau pemberitahuan obrolan video, pesan tersebut hanya bermakna untuk waktu yang singkat sebelum panggilan dihentikan. Atau jika pesan tersebut adalah undangan suatu acara, percuma jika diterima setelah acara tersebut berakhir.

Di Android dan Web/JavaScript, Anda dapat menentukan masa aktif pesan maksimum. Nilai harus berdurasi dari 0 hingga 2.419.200 detik (28 hari), dan sesuai dengan periode waktu maksimum FCM menyimpan dan mencoba mengirimkan pesan. Permintaan yang tidak berisi bidang ini default ke periode maksimum empat minggu.

Berikut adalah beberapa kemungkinan penggunaan fitur ini:

  • Obrolan video panggilan masuk
  • Acara undangan kedaluwarsa
  • Acara kalender

Keuntungan lain dari menentukan umur pesan adalah bahwa FCM tidak pernah mencekik pesan dengan nilai time-to-live 0 detik. Dengan kata lain, FCM menjamin upaya terbaik untuk pesan yang harus disampaikan "sekarang atau tidak sama sekali". Perlu diingat bahwa nilai time_to_live 0 berarti pesan yang tidak dapat dikirim segera akan dibuang. Namun, karena pesan tersebut tidak pernah disimpan, ini memberikan latensi terbaik untuk mengirim pesan notifikasi.

Berikut adalah contoh permintaan yang menyertakan 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"
      }
    }
  }
}

Seumur hidup pesan

Saat server aplikasi memposting pesan ke FCM dan menerima ID pesan kembali, itu tidak berarti bahwa pesan sudah dikirim ke perangkat. Sebaliknya, itu berarti bahwa itu diterima untuk pengiriman. Apa yang terjadi pada pesan setelah diterima tergantung pada banyak faktor.

Dalam skenario kasus terbaik, jika perangkat terhubung ke FCM, layar menyala dan tidak ada batasan pembatasan, pesan akan langsung dikirim.

Jika perangkat terhubung tetapi dalam mode Istirahatkan, pesan prioritas rendah disimpan oleh FCM hingga perangkat kehabisan mode Istirahatkan. Dan di situlah flag collapse_key berperan: jika sudah ada pesan dengan kunci collapse yang sama (dan token pendaftaran) yang disimpan dan menunggu pengiriman, pesan lama akan dibuang dan pesan baru menggantikannya (yaitu, yang lama pesan diciutkan oleh yang baru). Namun, jika kunci penciutan tidak disetel, pesan baru dan lama disimpan untuk pengiriman di masa mendatang.

Jika perangkat tidak terhubung ke FCM, pesan akan disimpan hingga koneksi dibuat (sekali lagi dengan mematuhi aturan kunci penciutan). Saat koneksi dibuat, FCM mengirimkan semua pesan tertunda ke perangkat. Jika perangkat tidak pernah terhubung lagi (misalnya, jika perangkat direset ke setelan pabrik), pesan akhirnya akan habis waktu dan dibuang dari penyimpanan FCM. Batas waktu default adalah empat minggu, kecuali jika flag time_to_live disetel.

Untuk mendapatkan lebih banyak wawasan tentang pengiriman pesan:

    Untuk mendapatkan lebih banyak wawasan tentang pengiriman pesan di platform Android atau Apple, lihat dasbor pelaporan FCM , yang mencatat jumlah pesan yang dikirim dan dibuka di perangkat Apple dan Android, bersama dengan data untuk "tayangan" (pemberitahuan yang dilihat oleh pengguna) untuk aplikasi Android.

Untuk perangkat Android dengan perpesanan saluran langsung yang diaktifkan, jika perangkat tidak terhubung ke FCM selama lebih dari satu bulan, FCM masih menerima pesan tetapi segera membuangnya. Jika perangkat terhubung dalam waktu empat minggu sejak pesan data terakhir yang Anda kirimkan, klien Anda akan menerima callback onDeletedMessages() . Aplikasi kemudian dapat menangani situasi dengan benar, biasanya dengan meminta sinkronisasi penuh dari server aplikasi.

Terakhir, saat FCM mencoba mengirimkan pesan ke perangkat dan aplikasi dicopot pemasangannya, FCM langsung membuang pesan tersebut dan membuat token pendaftaran menjadi tidak valid. Upaya di masa mendatang untuk mengirim pesan ke perangkat itu menghasilkan kesalahan NotRegistered .

Pelambatan dan penskalaan

Tujuan kami adalah untuk selalu menyampaikan setiap pesan yang dikirim melalui FCM. Namun, mengirimkan setiap pesan terkadang menghasilkan pengalaman pengguna yang buruk secara keseluruhan. Dalam kasus lain, kami perlu memberikan batasan untuk memastikan bahwa FCM menyediakan layanan yang dapat diskalakan untuk semua pengirim.

Pembatasan pesan yang dapat diciutkan

Seperti dijelaskan di atas, pesan yang dapat diciutkan adalah notifikasi bebas konten yang dirancang untuk saling bertumpuk. Jika pengembang terlalu sering mengulangi pesan yang sama ke aplikasi, kami menunda (memperlambat) pesan untuk mengurangi dampak pada baterai pengguna.

Misalnya, jika Anda mengirim sejumlah besar permintaan sinkronisasi email baru ke satu perangkat, kami mungkin menunda permintaan sinkronisasi email berikutnya beberapa menit sehingga perangkat dapat menyinkronkan dengan kecepatan rata-rata yang lebih rendah. Throttling ini dilakukan secara ketat untuk membatasi dampak baterai yang dialami oleh pengguna.

Jika kasus penggunaan Anda memerlukan pola pengiriman burst tinggi, maka pesan yang tidak dapat diciutkan mungkin merupakan pilihan yang tepat. Untuk pesan seperti itu, pastikan untuk menyertakan konten dalam pesan tersebut untuk mengurangi biaya baterai.

Kami membatasi pesan yang dapat diciutkan menjadi 20 pesan per aplikasi per perangkat, dengan isi ulang 1 pesan setiap 3 menit.

Pembatasan server XMPP

Kami membatasi kecepatan yang dapat Anda sambungkan ke server FCM XMPP hingga 400 koneksi per menit per proyek. Ini seharusnya tidak menjadi masalah untuk pengiriman pesan, tetapi penting untuk memastikan stabilitas sistem kami.

Untuk setiap proyek, FCM memungkinkan 2500 koneksi secara paralel.

Tingkat pesan maksimum ke satu perangkat

Untuk Android, Anda dapat mengirim hingga 240 pesan/menit dan 5.000 pesan/jam ke satu perangkat. Ambang batas tinggi ini dimaksudkan untuk memungkinkan lonjakan lalu lintas jangka pendek, seperti saat pengguna berinteraksi dengan cepat melalui obrolan. Batas ini mencegah kesalahan dalam pengiriman logika dari menguras baterai pada perangkat secara tidak sengaja.

Untuk iOS, kami mengembalikan kesalahan saat tarif melebihi batas APN.

Batas pesan upstream

Kami membatasi pesan upstream pada 1.500.000/menit per proyek untuk menghindari kelebihan beban server tujuan upstream.

Kami membatasi pesan upstream per perangkat pada 1.000/menit untuk melindungi dari pengurasan baterai dari perilaku aplikasi yang buruk.

Batas pesan topik

Tingkat penambahan/penghapusan langganan topik dibatasi hingga 3.000 QPS per proyek.

Untuk tarif pengiriman pesan, lihat Pembatasan Fanout .

Pelambatan kipas

Fanout pesan adalah proses pengiriman pesan ke beberapa perangkat, seperti saat Anda menargetkan topik dan grup, atau saat Anda menggunakan Notifications Composer untuk menargetkan audiens atau segmen pengguna.

Fanout pesan tidak instan dan terkadang Anda memiliki beberapa fanout yang sedang berlangsung secara bersamaan. Kami membatasi jumlah fanout pesan serentak per proyek hingga 1.000. Setelah itu, kami dapat menolak permintaan fanout tambahan atau menunda fanout permintaan hingga beberapa fanout yang sedang berlangsung selesai.

Tingkat fanout aktual yang dapat dicapai dipengaruhi oleh jumlah project yang meminta fanout pada saat yang sama. Tingkat fanout 10.000 QPS untuk proyek individu bukanlah hal yang tidak biasa, tetapi jumlah tersebut bukan merupakan jaminan dan merupakan hasil dari beban total pada sistem. Penting untuk dicatat bahwa kapasitas fanout yang tersedia dibagi di antara proyek dan bukan di seluruh permintaan fanout. Jadi, jika proyek Anda memiliki dua fanout yang sedang berlangsung, maka setiap fanout hanya akan melihat setengah dari tingkat fanout yang tersedia. Cara yang disarankan untuk memaksimalkan kecepatan fanout Anda adalah dengan hanya memiliki satu fanout aktif yang sedang berlangsung dalam satu waktu.

Port FCM dan firewall Anda

Jika organisasi Anda memiliki firewall untuk membatasi lalu lintas ke atau dari Internet, Anda perlu mengonfigurasinya untuk mengizinkan perangkat seluler terhubung dengan FCM agar perangkat di jaringan Anda menerima pesan. FCM biasanya menggunakan port 5228, tetapi terkadang menggunakan 443, 5229, dan 5230.

Untuk perangkat yang terhubung di jaringan Anda, FCM tidak memberikan IP tertentu karena rentang IP kami terlalu sering berubah dan aturan firewall Anda bisa ketinggalan zaman, sehingga memengaruhi pengalaman pengguna Anda. Idealnya, port daftar yang diizinkan 5228-5230 & 443 tanpa batasan IP. Namun, jika Anda harus memiliki batasan IP, Anda harus mengizinkan semua alamat IP yang tercantum di goog.json . Daftar besar ini diperbarui secara berkala, dan Anda disarankan untuk memperbarui aturan Anda setiap bulan. Masalah yang disebabkan oleh pembatasan IP firewall seringkali terputus-putus dan sulit didiagnosis.

Kami memang menawarkan satu set nama domain yang dapat diizinkan sebagai pengganti alamat IP. Nama-nama host tersebut tercantum di bawah ini. Jika kami mulai menggunakan nama host tambahan, kami akan memperbarui daftarnya di sini. Menggunakan nama domain untuk aturan firewall Anda mungkin berfungsi atau tidak di perangkat firewall Anda.

Port TCP untuk dibuka:

  • 5228
  • 5229
  • 5230
  • 443

Nama host yang akan dibuka:

  • 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
  • penyediaan perangkat.googleapis.com
  • firebaseinstallations.googleapis.com

Penerjemahan Alamat Jaringan dan/atau firewall Stateful Packet Inspection:

Jika jaringan Anda mengimplementasikan Network Address Translation (NAT) atau Stateful Packet Inspection (SPI), terapkan batas waktu 30 menit atau lebih besar untuk koneksi kami melalui port 5228-5230. Hal ini memungkinkan kami menyediakan konektivitas yang andal sekaligus mengurangi konsumsi baterai perangkat seluler pengguna Anda.

Kredensial

Bergantung pada fitur FCM yang Anda terapkan, Anda mungkin memerlukan kredensial berikut dari proyek Firebase Anda:

ID proyek ID unik untuk project Firebase Anda, yang digunakan dalam permintaan ke endpoint HTTP FCM v1. Nilai ini tersedia di panel Setelan konsol Firebase .
Token pendaftaran

String token unik yang mengidentifikasi setiap instance aplikasi klien. Token pendaftaran diperlukan untuk satu perangkat dan perpesanan grup perangkat. Perhatikan bahwa token pendaftaran harus dirahasiakan.

ID pengirim Nilai numerik unik yang dibuat saat Anda membuat proyek Firebase, tersedia di tab Cloud Messaging pada panel Setelan konsol Firebase. ID pengirim digunakan untuk mengidentifikasi setiap pengirim yang dapat mengirim pesan ke aplikasi klien.
Token akses Token OAuth 2.0 berumur pendek yang mengotorisasi permintaan ke HTTP v1 API. Token ini dikaitkan dengan akun layanan milik proyek Firebase Anda. Untuk membuat dan memutar token akses, ikuti langkah-langkah yang dijelaskan di Otorisasi Permintaan Kirim .
Kunci server (untuk protokol lama)

Kunci server yang mengotorisasi server aplikasi Anda untuk mengakses layanan Google, termasuk mengirim pesan melalui protokol lama Firebase Cloud Messaging. Anda mendapatkan kunci server saat membuat proyek Firebase. Anda dapat melihatnya di tab Cloud Messaging pada panel Setelan konsol Firebase.

Penting: Jangan sertakan kunci server di mana pun dalam kode klien Anda. Selain itu, pastikan untuk hanya menggunakan kunci server untuk mengotorisasi server aplikasi Anda. Android, platform Apple, dan kunci browser ditolak oleh FCM.