Catch up on everthing we announced at this year's Firebase Summit. Learn more

Sunucu ortamınız ve FCM

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

  • Google tarafından sağlanan FCM arka uç.
  • Uygulamanız sunucusu veya örneğin sunucu mantığı çalışır, diğer güvenilir sunucu ortamı Firebase için Bulut Fonksiyonlar veya diğer bulut ortamlarında Google tarafından başardı.

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.
  • İsteklerini işlemek ve kullanarak bunları yeniden göndermek için Able üstel geri-off.
  • 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

Sen FCM sunucularıyla etkileşim için bir yol üzerinde karar vermek gerekir: kullanarak ya Firebase Admin SDK veya ham protokolleri. 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:
  • İçin desteği vardır Firebase Yönetici SDK Düğüm , Java , Python , C # ve Go .
  • FCM HTTP v1 API daha güvenli yetkilendirme ve esnek ile protokol seçeneklerinin en güncel olan, çapraz platform mesajlaşma yetenekleri (Firebase Yönetici SDK bu protokole dayanan ve doğal tüm avantajlarını sağlayan edilir).
  • Eski HTTP protokolü.
  • XMPP sunucusu protokolü. İstemci uygulamalarınızdan yukarı akış mesajlaşmasını kullanmak istiyorsanız, XMPP kullanmanız gerektiğini unutmayın.

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 kurmak için, bkz Sunucunuza Firebase Yönetici SDK'yı ekleyin . Zaten bir Firebase projeniz varsa, başlamak SDK ekleyin . Firebase Yönetici SDK yüklendikten sonra, daha size yazma mantığını başlayabilirsiniz inşa gönderme istekleri .

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çenekleri hakkında ayrıntılı bilgi için bkz Yapı Uygulama Sunucusu Gönder İstekleri

XMPP sunucu protokolünü uygulama

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

  • Birden fazla alıcı için destek yoktur.
  • FCM alan ekler message_id gereklidir. Bu kimlik, mesajı bir XMPP bağlantısında benzersiz olarak tanımlar. FCM gelen ACK ya da NACK kullanan message_id FCM için uygulama sunucularından gönderilen bir mesajın belirlenmesi. Bu nedenle, bu önemlidir message_id sadece (başına benzersiz olması gönderici kimliği ), ama her zaman mevcut.
  • XMPP, FCM'ye kalıcı bir bağlantıya yetki vermek için sunucu anahtarını kullanır. Bkz Yetkilendirme İstekleri gönder Daha fazla bilgi için.

Normal FCM mesajlarına ek olarak, kontrol mesajları ile gösterilen gönderilir message_type JSON nesne alanda. Değer, 'ack' veya 'nack' veya 'kontrol' olabilir (aşağıdaki biçimlere bakın). Bilinmeyen bir ile herhangi bir FCM mesajı message_type Sunucunuz tarafından göz ardı edilebilir.

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. Bkz Akış Kontrolü Detaylar için.

Bkz Protokolü Başvurusu tüm mesaj parametrelerinin listesi için.

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ı

İşte 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ı

Bir NACK hatası olduğu bir düzenli XMPP mesajdır message_type durum mesajı "nack" dir. 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>

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

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ı koparır önce, FCM gönderir CONNECTION_DRAINING bağlantısı tahliye ediliyor ve yakında kapalı olacağını belirten mesajı. "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 aldığınızda CONNECTION_DRAINING mesajı, hemen yeni bir bağlantı gerekirse açarak, başka FCM bağlantısına mesaj gönderme başlamalıdır. 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ı aşağıdaki gibidir:

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

CONNECTION_DRAINING şu anda sadece control_type destekledi.

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 / bildirim akar.

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 göndermeden ö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.