Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More
Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

Sunucu ortamınız ve FCM

Firebase Cloud Messaging'in sunucu tarafı iki bileşenden oluşur:

  • Google tarafından sağlanan FCM arka ucu .
  • Uygulama sunucunuz veya Firebase için Cloud Functions veya Google tarafından yönetilen diğer bulut ortamları gibi sunucu mantığınızın çalıştığı diğer güvenilir sunucu ortamı .

Uygulama sunucunuz veya güvenilir sunucu ortamınız, FCM arka ucuna mesaj istekleri gönderir ve bu da mesajları, kullanıcıların cihazlarında çalışan istemci uygulamalarına yönlendirir.

Güvenilir sunucu ortamı için gereksinimler

Uygulama sunucusu ortamınız aşağıdaki ölçütleri karşılamalıdır:

  • FCM arka ucuna düzgün biçimlendirilmiş mesaj istekleri gönderebilme.
  • İstekleri işleyebilir ve üstel geri çekme kullanarak yeniden gönderebilir.
  • Sunucu yetkilendirme bilgilerini ve istemci kayıt belirteçlerini güvenli bir şekilde saklayabilir.
  • XMPP protokolü için (kullanılıyorsa), sunucu, gönderdiği her mesajı benzersiz bir şekilde tanımlamak için mesaj kimlikleri üretebilmelidir (FCM HTTP arka ucu, mesaj kimliklerini oluşturur ve bunları yanıtta döndürür). XMPP mesaj kimlikleri, gönderen kimliği başına benzersiz olmalıdır.

Bir sunucu seçeneği seçme

FCM sunucularıyla etkileşim kurmanın bir yoluna karar vermeniz gerekecek: ya Firebase Admin SDK'sını ya da ham protokolleri kullanarak. Popüler programlama dillerindeki desteği ve kimlik doğrulama ve yetkilendirmeyi işlemeye yönelik kolaylık yöntemleri nedeniyle, Firebase Admin SDK önerilen yöntemdir.

FCM sunucularıyla etkileşim kurma seçenekleri aşağıdakileri içerir:

  • Node , Java , Python , C# ve Go desteğine sahip Firebase Admin SDK.
  • Protokol seçeneklerinin en günceli olan, daha güvenli yetkilendirme ve esnek platformlar arası mesajlaşma özelliklerine sahip olan FCM HTTP v1 API'si (Firebase Admin SDK'sı bu protokolü temel alır ve tüm doğal avantajlarını sağlar). Yeni özellikler genellikle yalnızca HTTP v1 API'sine eklendiğinden, çoğu kullanım durumu için bu API'yi kullanmanızı öneririz.
  • Eski HTTP protokolü. Yeni projelerin eski protokol yerine FCM v1 HTTP API'sini benimsemesi şiddetle tavsiye edilir.
  • Eski XMPP sunucu protokolü. Yeni projelerin eski protokol yerine FCM v1 HTTP API'sini benimsemesi şiddetle tavsiye edilir.

FCM için Firebase Yönetici SDK'sı

Admin FCM API, arka uçla kimlik doğrulamayı yönetir ve mesaj göndermeyi ve konu aboneliklerini yönetmeyi kolaylaştırır. Firebase Admin SDK ile şunları yapabilirsiniz:

  • Tek tek cihazlara mesaj gönderin
  • Bir veya daha fazla konuyla eşleşen konulara ve koşul ifadelerine mesajlar gönderin.
  • Konulara ve konulara abone olun ve cihazlara abone olun
  • Farklı hedef platformlara göre uyarlanmış mesaj yükleri oluşturun

Admin Node.js SDK, cihaz gruplarına mesaj göndermek için yöntemler sağlar.

Firebase Admin SDK'sını kurmak için Firebase Admin SDK'sını Sunucunuza Ekleme bölümüne bakın. Zaten bir Firebase projeniz varsa Add the SDK ile başlayın. Ayrıca, projeniz için Cloud Messaging ayarları sayfasındaki Cloud Messagin API'sini etkinleştirdiğinizden emin olun. Ardından, Firebase Admin SDK yüklendikten sonra, gönderme istekleri oluşturmak için mantık yazmaya başlayabilirsiniz.

FCM Sunucu Protokolleri

Şu anda FCM şu ham sunucu protokollerini sağlamaktadır:

Uygulama sunucunuz bu protokolleri ayrı ayrı veya birlikte kullanabilir. Birden çok platforma mesaj göndermek için en güncel ve en esnek olduğu için, mümkün olan her yerde FCM HTTP v1 API'si önerilir. Gereksinimleriniz cihazlardan sunucuya yukarı akış mesajlaşmasını içeriyorsa, XMPP protokolünü uygulamanız gerekir.

XMPP mesajlaşması, HTTP mesajlaşmasından aşağıdaki şekillerde farklıdır:

  • Yukarı/Aşağı Akış mesajları
    • HTTP: Yalnızca aşağı akış, buluttan cihaza.
    • XMPP: Yukarı ve aşağı akış (cihazdan buluta, buluttan cihaza).
  • Mesajlaşma (senkron veya asenkron)
    • HTTP: Eşzamanlı. Uygulama sunucuları mesajları HTTP POST istekleri olarak gönderir ve yanıt bekler. Bu mekanizma senkronizedir ve gönderenin yanıt alınana kadar başka bir mesaj göndermesini engeller.
    • XMPP: Eşzamansız. Uygulama sunucuları, kalıcı XMPP bağlantıları üzerinden tüm cihazlarına tam hat hızında mesaj gönderir/alır. XMPP bağlantı sunucusu, onay veya hata bildirimlerini (özel ACK ve NACK JSON kodlu XMPP mesajları biçiminde) eşzamansız olarak gönderir.
  • JSON
    • HTTP: HTTP POST olarak gönderilen JSON mesajları.
    • XMPP: XMPP mesajlarında kapsüllenmiş JSON mesajları.
  • Düz Metin
    • HTTP: HTTP POST olarak gönderilen Düz Metin mesajları.
    • XMPP: Desteklenmiyor.
  • Çok noktaya yayın aşağı akış, birden çok kayıt belirtecine gönderir.
    • HTTP: JSON mesaj formatında desteklenir.
    • XMPP: Desteklenmiyor.

HTTP sunucu protokolünün uygulanması

Bir mesaj göndermek için uygulama sunucusu, bir HTTP başlığı ve JSON anahtar değer çiftlerinden oluşan bir HTTP gövdesi içeren bir POST isteği gönderir. Başlık ve gövde seçenekleriyle ilgili ayrıntılar için bkz. Uygulama Sunucusu Oluşturma İstekleri Gönderme

XMPP sunucu protokolünü uygulama

FCM mesajları için JSON yükü, şu istisnalar dışında HTTP protokolüne benzer:

  • Birden çok alıcı için destek yoktur.
  • FCM, gerekli olan message_id alanını ekler. Bu kimlik, mesajı bir XMPP bağlantısında benzersiz olarak tanımlar. FCM'den gelen ACK veya NACK, uygulama sunucularından FCM'ye gönderilen bir mesajı tanımlamak için message_id kullanır. Bu nedenle, bu message_id yalnızca benzersiz ( gönderen kimliği başına) değil, her zaman mevcut olması önemlidir.
  • XMPP, FCM'ye kalıcı bir bağlantıya yetki vermek için sunucu anahtarını kullanır. Daha fazla bilgi için Gönderme İsteklerini Yetkilendirme konusuna bakın.

Normal FCM mesajlarına ek olarak, JSON nesnesindeki message_type alanıyla gösterilen kontrol mesajları gönderilir. Değer, 'ack' veya 'nack' veya 'kontrol' olabilir (aşağıdaki biçimlere bakın). Bilinmeyen bir mesaj message_type sahip herhangi bir FCM mesajı, sunucunuz tarafından yoksayılabilir.

Uygulama sunucunuzun FCM'den aldığı her cihaz mesajı için bir ACK mesajı göndermesi gerekir. Asla bir NACK mesajı göndermesi gerekmez. Bir mesaj için ACK göndermezseniz, mesajın süresi ilk olarak sona ermedikçe, FCM yeni bir XMPP bağlantısı kurulduğunda bunu yeniden gönderir.

FCM ayrıca sunucudan cihaza her mesaj için bir ACK veya NACK gönderir. Her ikisini de almazsanız, işlemin ortasında TCP bağlantısının kapatıldığı ve sunucunuzun mesajları yeniden göndermesi gerektiği anlamına gelir. Ayrıntılar için Akış Kontrolü'ne bakın.

Tüm mesaj parametrelerinin listesi için Protokol Referansına bakın.

Talep formatı

Yüklü mesaj — bildirim mesajı

İşte bir bildirim mesajı için bir XMPP kıtası:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
     "to":"REGISTRATION_ID",  // "to" replaces "registration_ids"
     "notification": {
        "title": "Portugal vs. Denmark”,
        "body”: "5 to 1”
      },
      "time_to_live":"600"
  }
  </gcm>
</message>

Yüklü mesaj — veri mesajı

Bir uygulama sunucusundan FCM'ye gönderilen JSON mesajını içeren bir XMPP kıtası:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
      "to":"REGISTRATION_ID",  // "to" replaces "registration_ids"
      "message_id":"m-1366082849205" // new required field
      "data":
      {
          "hello":"world",
      }
      "time_to_live":"600",
  }
  </gcm>
</message>

Yanıt biçimi

Bir FCM yanıtının üç olası biçimi olabilir. İlki normal bir 'onay' mesajıdır. Ancak yanıt bir hata içerdiğinde, aşağıda açıklanan mesajın alabileceği 2 farklı biçim vardır.

ACK mesajı

FCM'den uygulama sunucusuna gönderilen ACK/NACK mesajını içeren bir XMPP kıtası:

<message id="">
  <gcm xmlns="google:mobile:data">
  {
      "from":"REGID",
      "message_id":"m-1366082849205"
      "message_type":"ack"
  }
  </gcm>
</message>

NACK mesajı

NACK hatası, message_type durum mesajının "nack" olduğu normal bir XMPP mesajıdır. Bir NACK mesajı şunları içerir:

  • Bir NACK hata kodu.
  • Bir NACK hata açıklaması.

Aşağıda bazı örnekler verilmiştir.

Kötü kayıt:

<message>
  <gcm xmlns="google:mobile:data">
  {
    "message_type":"nack",
    "message_id":"msgId1",
    "from":"SomeInvalidRegistrationToken",
    "error":"BAD_REGISTRATION",
    "error_description":"Invalid token on 'to' field: SomeInvalidRegistrationId"
  }
  </gcm>
</message>

Geçersiz JSON:

<message>
 <gcm xmlns="google:mobile:data">
 {
   "message_type":"nack",
   "message_id":"msgId1",
   "from":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
   "error":"INVALID_JSON",
   "error_description":"InvalidJson: JSON_TYPE_ERROR : Field \"time_to_live\" must be a JSON java.lang.Number: abc"
 }
 </gcm>
</message>

Cihaz Mesaj Oranı Aşıldı:

<message id="...">
  <gcm xmlns="google:mobile:data">
  {
    "message_type":"nack",
    "message_id":"msgId1",
    "from":"REGID",
    "error":"DEVICE_MESSAGE_RATE_EXCEEDED",
    "error_description":"Downstream message rate exceeded for this registration id"
  }
  </gcm>
</message>

NACK hata kodlarının tam listesi için Sunucu Referansına bakın. Aksi belirtilmedikçe, NACK'lenmiş bir mesaj yeniden denenmemelidir. Beklenmeyen NACK hata kodları INTERNAL_SERVER_ERROR ile aynı şekilde ele alınmalıdır.

Dörtlük hatası

Bazı durumlarda dörtlük hatası da alabilirsiniz. Bir kıta hatası şunları içerir:

  • Stanza hata kodu.
  • Stanza hata açıklaması (serbest metin).

Örneğin:

<message id="3" type="error" to="123456789@fcm.googleapis.com/ABC">
  <gcm xmlns="google:mobile:data">
     {"random": "text"}
  </gcm>
  <error code="400" type="modify">
    <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
      InvalidJson: JSON_PARSING_ERROR : Missing Required Field: message_id\n
    </text>
  </error>
</message>

Kontrol mesajları

Yük dengelemeyi gerçekleştirmek için FCM'nin periyodik olarak bir bağlantıyı kapatması gerekir. Bağlantıyı kapatmadan önce FCM, bağlantının boşalmakta olduğunu ve yakında kapatılacağını belirtmek için bir CONNECTION_DRAINING mesajı gönderir. "Boşaltma", bir bağlantıya gelen mesaj akışının kapatılmasını, ancak boru hattında zaten olanın devam etmesine izin verilmesini ifade eder. Bir CONNECTION_DRAINING mesajı aldığınızda, gerekirse yeni bir bağlantı açarak hemen başka bir FCM bağlantısına mesaj göndermeye başlamalısınız. Bununla birlikte, orijinal bağlantıyı açık tutmalı ve bağlantı üzerinden gelebilecek mesajları almaya devam etmelisiniz (ve bunları ACK ile göndererek)—FCM, hazır olduğunda bir bağlantıyı başlatmayı gerçekleştirir.

CONNECTION_DRAINING mesajı şöyle görünür:

<message>
  <data:gcm xmlns:data="google:mobile:data">
  {
    "message_type":"control"
    "control_type":"CONNECTION_DRAINING"
  }
  </data:gcm>
</message>

CONNECTION_DRAINING şu anda desteklenen tek control_type .

Akış kontrolü

FCM'ye gönderilen her mesaj ya bir ACK ya da bir NACK yanıtı alır. Bu yanıtlardan birini almayan iletiler beklemede olarak kabul edilir. Bekleyen mesaj sayısı 100'e ulaşırsa, uygulama sunucusu yeni mesaj göndermeyi durdurmalı ve Şekil 1'de gösterildiği gibi FCM'nin mevcut bekleyen mesajlardan bazılarını onaylamasını beklemelidir.

FCM ve uygulama sunucusu arasındaki kontrol akışının ayrıntılı diyagramı

Şekil 1. Mesaj/onay akışı.

Tersine, uygulama sunucusunun aşırı yüklenmesini önlemek için, çok fazla onaylanmamış mesaj varsa FCM göndermeyi durdurur. Bu nedenle, uygulama sunucusu, gelen mesajların sabit akışını sağlamak için istemci uygulamasından FCM aracılığıyla alınan yukarı akış mesajlarını mümkün olan en kısa sürede "ACK" yapmalıdır. Yukarıda belirtilen bekleyen mesaj limiti bu ACK'ler için geçerli değildir. Bekleyen mesaj sayısı 100'e ulaşsa bile, uygulama sunucusu, yeni yukarı akış mesajlarının teslimini engellememek için FCM'den alınan mesajlar için ACK göndermeye devam etmelidir.

ACK'ler yalnızca bir bağlantı bağlamında geçerlidir. Bir mesajın ACK'lenmesinden önce bağlantı kapatılırsa, uygulama sunucusu FCM'nin yukarı akış mesajını tekrar ACK'lemeden önce yeniden göndermesini beklemelidir. Benzer şekilde, bağlantı kapatılmadan önce FCM'den ACK/NACK alınmamış bekleyen tüm mesajlar yeniden gönderilmelidir.