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

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Firebase Cloud Messaging (FCM) menawarkan berbagai opsi dan kemampuan perpesanan. 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. Sebaliknya, pesan data hanya berisi pasangan nilai kunci khusus yang ditentukan pengguna. Pesan notifikasi dapat berisi payload data opsional. Muatan 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 yang telah ditentukan sebelumnya dan payload data opsional 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 notifikasi tampilan dan kirim payload permintaan.

  2. Gunakan penulis Notifikasi : Masukkan Teks Pesan, Judul, dll., dan kirim. Tambahkan payload data opsional dengan memberikan 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 keterlibatan kembali pengguna, Anda dapat mengirim pesan notifikasi menggunakan konsol Firebase . Firebase console 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 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 "pertandingan hebat!" 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 callback.

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

Pesan data

Tetapkan kunci yang sesuai dengan pasangan nilai kunci khusus Anda untuk mengirim muatan data ke aplikasi klien.

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

{
  "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. Di setiap platform, aplikasi klien menerima muatan data dalam fungsi callback.

Enkripsi untuk pesan data

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

Pesan notifikasi dengan payload data opsional

Baik secara terprogram atau melalui konsol Firebase, Anda dapat mengirim pesan notifikasi yang berisi muatan opsional pasangan nilai kunci khusus. Di penulis Notifikasi , gunakan kolom data Kustom 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 atau tidak pada saat penerimaan.

  • Saat berada di latar belakang , aplikasi menerima payload notifikasi di baki notifikasi, dan hanya menangani payload 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 menyetel semua kolom 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.

Pemblokiran khusus platform memberi Anda fleksibilitas untuk menyesuaikan pesan untuk platform yang berbeda guna 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 kolom umum

Gunakan kolom umum saat Anda:

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

Semua instance aplikasi, apa pun platformnya, dapat menginterpretasikan kolom umum berikut:

Kapan harus menggunakan bidang khusus platform

Gunakan bidang khusus platform saat Anda ingin:

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

Setiap kali Anda ingin mengirim nilai hanya ke platform tertentu, jangan gunakan kolom 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 lagi 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, meskipun Anda ingin menyetel nilai yang pada dasarnya sama di seluruh platform, Anda harus menggunakan bidang khusus platform. Hal 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 disetel 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 — masing-masing click_action , dan 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"
       }
     }
   }
 }

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 Pengiriman .

Pilihan pengiriman

FCM menyediakan serangkaian opsi pengiriman khusus untuk pesan yang dikirim ke perangkat Android, dan memungkinkan opsi serupa di platform Apple dan web. Misalnya, perilaku pesan "dapat dilipat" 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 dikirimkan ke perangkat. Pesan yang tidak dapat diciutkan mengirimkan beberapa konten yang bermanfaat, berlawanan 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 chat 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 runtuh. Jika batas tercapai, semua pesan yang tersimpan akan dibuang. Saat 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 dikirimkan 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 angka ini, FCM hanya menyimpan empat kunci penciutan, tanpa jaminan mana yang disimpan.

Pesan topik tanpa payload 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 performa, 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 angka ini, karena dapat menyebabkan konsekuensi yang tidak terduga.

Gunakan skenario Bagaimana cara mengirim
Tidak dapat dilipat Setiap pesan penting untuk aplikasi klien dan perlu disampaikan. Kecuali untuk pesan notifikasi, semua pesan tidak dapat diciutkan secara default.
Dapat dilipat Saat ada pesan baru yang merender pesan lama terkait yang tidak relevan dengan aplikasi klien, FCM akan mengganti pesan lama. Misalnya: pesan yang digunakan untuk memulai sinkronisasi data dari server, atau pesan notifikasi yang kedaluwarsa. 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 yang berjalan di latar belakang, pengiriman mungkin tertunda. Untuk pesan yang tidak terlalu sensitif terhadap waktu, seperti pemberitahuan email baru, menyinkronkan UI, atau menyinkronkan data aplikasi di latar belakang, pilih prioritas pengiriman normal.

  • Prioritas utama. FCM berupaya mengirimkan pesan berprioritas tinggi dengan segera meskipun perangkat dalam mode Istirahatkan. Pesan berprioritas tinggi adalah untuk konten yang dapat dilihat pengguna dan sensitif terhadap waktu.

Berikut adalah contoh pesan prioritas normal yang dikirim melalui protokol HTTP FCM 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 khusus platform lainnya tentang menyetel 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 dengan sengaja menunda pesan untuk mencegah aplikasi menggunakan sumber daya yang berlebihan dan memengaruhi masa pakai baterai secara negatif.

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

Di Android dan Web/JavaScript, Anda dapat menentukan umur maksimum pesan. 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 kolom ini default ke periode maksimum empat minggu.

Berikut beberapa kemungkinan penggunaan fitur ini:

  • Panggilan masuk obrolan video
  • Acara undangan kedaluwarsa
  • Acara kalender

Keuntungan lain dari menentukan umur pesan adalah bahwa FCM tidak pernah membatasi 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 segera dikirim 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, bukan berarti pesan tersebut sudah dikirimkan ke perangkat. Sebaliknya, itu berarti 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 pelambatan, pesan akan segera dikirim.

Jika perangkat terhubung tetapi dalam Istirahatkan, pesan berprioritas rendah disimpan oleh FCM hingga perangkat keluar dari 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 berikutnya.

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 yang tertunda ke perangkat. Jika perangkat tidak pernah terhubung lagi (misalnya, jika disetel ulang ke setelan pabrik), pesan akan habis waktu dan dihapus dari penyimpanan FCM. Batas waktu default adalah empat minggu, kecuali 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, beserta data untuk "tayangan" (pemberitahuan yang dilihat oleh pengguna) untuk aplikasi Android.

Untuk perangkat Android dengan perpesanan saluran langsung diaktifkan, jika perangkat tidak tersambung ke FCM selama lebih dari satu bulan, FCM masih menerima pesan tersebut tetapi langsung membuangnya. Jika perangkat terhubung dalam waktu empat minggu sejak pesan data terakhir yang Anda kirim ke perangkat tersebut, 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 dihapus instalannya, FCM langsung membuang pesan tersebut dan membatalkan validasi token pendaftaran. Upaya selanjutnya untuk mengirim pesan ke perangkat itu menghasilkan kesalahan NotRegistered .

Pembatasan 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.

Pelambatan pesan yang dapat diciutkan

Seperti dijelaskan di atas, pesan yang dapat diciutkan adalah pemberitahuan bebas konten yang dirancang untuk diciutkan satu sama lain. Jika pengembang terlalu sering mengulangi pesan yang sama ke aplikasi, kami akan menunda (membatasi) pesan untuk mengurangi dampak pada baterai pengguna.

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

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

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

Pelambatan server XMPP

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

Untuk setiap project, FCM mengizinkan 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 ledakan lalu lintas jangka pendek, seperti saat pengguna berinteraksi dengan cepat melalui obrolan. Batasan ini mencegah kesalahan dalam mengirimkan logika dari menguras baterai perangkat secara tidak sengaja.

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

Batas pesan upstream

Kami membatasi pesan upstream sebesar 1.500.000/menit per project untuk menghindari kelebihan beban server tujuan upstream.

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

Batas pesan topik

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

Untuk tarif pengiriman pesan, lihat Pembatasan Fanout .

Pembatasan fanout

Penyebaran pesan adalah proses pengiriman pesan ke beberapa perangkat, seperti saat Anda menargetkan topik dan grup, atau saat Anda menggunakan penulis Notifikasi untuk menargetkan audiens atau segmen pengguna.

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

Tingkat fanout aktual yang dapat dicapai dipengaruhi oleh jumlah proyek yang meminta fanout pada waktu yang bersamaan. Tingkat fanout 10.000 QPS untuk proyek individual bukanlah hal yang tidak biasa, tetapi angka tersebut bukanlah jaminan dan merupakan hasil dari beban total pada sistem. Penting untuk diperhatikan bahwa kapasitas fanout yang tersedia dibagi di antara proyek dan bukan di seluruh permintaan fanout. Jadi, jika proyek Anda memiliki dua fanout yang sedang berjalan, maka setiap fanout hanya akan melihat setengah dari tingkat fanout yang tersedia. Cara yang disarankan untuk memaksimalkan kecepatan fanout Anda adalah dengan hanya menjalankan satu fanout aktif 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 dapat menerima pesan. FCM biasanya menggunakan port 5228, tetapi terkadang menggunakan 443, 5229, dan 5230.

Untuk perangkat yang terhubung di jaringan Anda, FCM tidak menyediakan IP khusus karena rentang IP kami terlalu sering berubah dan aturan firewall Anda bisa kedaluwarsa, sehingga memengaruhi pengalaman pengguna Anda. Idealnya, izinkan port 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 peraturan setiap bulan. Masalah yang disebabkan oleh pembatasan IP firewall seringkali terputus-putus dan sulit didiagnosis.

Kami memang menawarkan sekumpulan nama domain yang dapat diizinkan, bukan alamat IP. 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 berfungsi di perangkat firewall Anda.

Port TCP untuk dibuka:

  • 5228
  • 5229
  • 5230
  • 443

Nama host untuk 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

Terjemahan Alamat Jaringan dan/atau firewall Inspeksi Paket Stateful:

Jika jaringan Anda menerapkan Network Address Translation (NAT) atau Stateful Packet Inspection (SPI), terapkan batas waktu 30 menit atau lebih 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 mana yang Anda implementasikan, Anda mungkin memerlukan kredensial berikut dari project Firebase Anda:

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

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

ID pengirim Nilai numerik unik yang dibuat saat Anda membuat project Firebase, tersedia di tab Cloud Messaging di panel Pengaturan Firebase console. 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 merotasi token akses, ikuti langkah-langkah yang dijelaskan di Otorisasi Kirim Permintaan .
Kunci server (untuk protokol lawas)

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 di panel Pengaturan Firebase console.

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