Google is committed to advancing racial equity for Black communities. See how.
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

สภาพแวดล้อมเซิร์ฟเวอร์ของคุณและ FCM

ฝั่งเซิร์ฟเวอร์ของ Firebase Cloud Messaging ประกอบด้วยสององค์ประกอบ:

  • แบ็กเอนด์ FCM ที่ Google จัดหาให้
  • เซิร์ฟเวอร์แอป ของคุณหรือ สภาพแวดล้อมเซิร์ฟเวอร์ที่เชื่อถือได้ อื่น ๆ ที่ตรรกะของเซิร์ฟเวอร์ทำงานเช่น Cloud Functions for Firebase หรือสภาพแวดล้อมระบบคลาวด์อื่น ๆ ที่ Google จัดการ

เซิร์ฟเวอร์แอปของคุณหรือสภาพแวดล้อมเซิร์ฟเวอร์ที่เชื่อถือได้ส่งคำขอข้อความไปยังแบ็กเอนด์ FCM ซึ่งจะกำหนดเส้นทางข้อความไปยังแอปไคลเอ็นต์ที่ทำงานบนอุปกรณ์ของผู้ใช้

ข้อกำหนดสำหรับสภาพแวดล้อมเซิร์ฟเวอร์ที่เชื่อถือได้

สภาพแวดล้อมเซิร์ฟเวอร์แอปของคุณต้องเป็นไปตามเกณฑ์ต่อไปนี้:

  • สามารถส่งคำขอข้อความที่จัดรูปแบบอย่างถูกต้องไปยังแบ็กเอนด์ FCM
  • สามารถจัดการคำขอและส่งใหม่โดยใช้การ ย้อนกลับแบบเอ็กซ์โปเนนเชียล
  • สามารถจัดเก็บข้อมูลรับรองการอนุญาตเซิร์ฟเวอร์และโทเค็นการลงทะเบียนไคลเอนต์ได้อย่างปลอดภัย
  • สำหรับโปรโตคอล XMPP (ถ้าใช้) เซิร์ฟเวอร์ต้องสามารถสร้าง ID ข้อความเพื่อระบุแต่ละข้อความที่ส่งโดยไม่ซ้ำกัน (แบ็กเอนด์ FCM HTTP จะสร้าง ID ข้อความและส่งกลับในการตอบกลับ) รหัสข้อความ XMPP ควรไม่ซ้ำกันต่อ ID ผู้ส่ง

การเลือกตัวเลือกเซิร์ฟเวอร์

คุณจะต้องตัดสินใจเกี่ยวกับวิธีโต้ตอบกับเซิร์ฟเวอร์ FCM โดยใช้ Firebase Admin SDK หรือโปรโตคอลดิบ เนื่องจากการสนับสนุนภาษาโปรแกรมยอดนิยมและวิธีการที่สะดวกในการจัดการการตรวจสอบสิทธิ์และการอนุญาตจึงขอแนะนำให้ใช้ Firebase Admin SDK

ตัวเลือกสำหรับการโต้ตอบกับเซิร์ฟเวอร์ FCM มีดังต่อไปนี้:
  • Firebase Admin SDK ซึ่งรองรับ Node , Java , Python , C # และ Go
  • FCM HTTP v1 API ซึ่งเป็นตัวเลือกโปรโตคอลที่ทันสมัยที่สุดพร้อมการอนุญาตที่ปลอดภัยยิ่งขึ้นและความ สามารถในการส่งข้อความข้ามแพลตฟอร์มที่ ยืดหยุ่น (Firebase Admin SDK ใช้โปรโตคอลนี้และให้ข้อดีทั้งหมดโดยธรรมชาติ)
  • โปรโตคอล HTTP เดิม
  • โปรโตคอลเซิร์ฟเวอร์ XMPP โปรดทราบว่าหากคุณต้องการใช้การส่งข้อความอัพสตรีมจากแอปพลิเคชันไคลเอนต์ของคุณคุณต้องใช้ XMPP

Firebase Admin SDK สำหรับ FCM

Admin FCM API จะจัดการการตรวจสอบสิทธิ์กับแบ็กเอนด์และอำนวยความสะดวกในการส่งข้อความและจัดการการสมัครรับข้อมูลหัวข้อ ด้วย Firebase Admin SDK คุณสามารถ:

  • ส่งข้อความไปยังอุปกรณ์แต่ละเครื่อง
  • ส่งข้อความไปยังหัวข้อและเงื่อนไขเงื่อนไขที่ตรงกับหัวข้ออย่างน้อยหนึ่งหัวข้อ
  • สมัครและยกเลิกการสมัครอุปกรณ์เข้าและออกจากหัวข้อ
  • สร้างเพย์โหลดข้อความที่ปรับให้เหมาะกับแพลตฟอร์มเป้าหมายที่แตกต่างกัน

Admin Node.js SDK มีวิธีการส่งข้อความไปยังกลุ่มอุปกรณ์

ในการตั้งค่า Firebase Admin SDK โปรดดู เพิ่ม Firebase Admin SDK ไปยังเซิร์ฟเวอร์ของคุณ หากคุณมีโปรเจ็กต์ Firebase อยู่แล้วให้เริ่มด้วย เพิ่ม SDK จากนั้นเมื่อติดตั้ง Firebase Admin SDK แล้วคุณจะเริ่มเขียนตรรกะเพื่อ สร้างคำขอส่ง ได้

FCM เซิร์ฟเวอร์โปรโตคอล

ปัจจุบัน FCM มีโปรโตคอลเซิร์ฟเวอร์ดิบเหล่านี้:

เซิร์ฟเวอร์แอปของคุณสามารถใช้โปรโตคอลเหล่านี้แยกกันหรือควบคู่กันได้ เนื่องจากเป็นเวอร์ชันล่าสุดและยืดหยุ่นที่สุดสำหรับการส่งข้อความไปยังหลายแพลตฟอร์มจึงขอแนะนำ FCM HTTP v1 API ทุกที่ที่เป็นไปได้ หากข้อกำหนดของคุณรวมถึงการส่งข้อความต้นน้ำจากอุปกรณ์ไปยังเซิร์ฟเวอร์คุณจะต้องใช้โปรโตคอล XMPP

การส่งข้อความ XMPP แตกต่างจากการส่งข้อความ HTTP ด้วยวิธีต่อไปนี้:

  • ข้อความต้นน้ำ / ปลายน้ำ
    • HTTP: ดาวน์สตรีมเท่านั้น cloud-to-device
    • XMPP: ต้นน้ำและปลายน้ำ (อุปกรณ์สู่ระบบคลาวด์ระบบคลาวด์สู่อุปกรณ์)
  • การส่งข้อความ (ซิงโครนัสหรืออะซิงโครนัส)
    • HTTP: ซิงโครนัส เซิร์ฟเวอร์แอปส่งข้อความเป็นคำขอ HTTP POST และรอการตอบกลับ กลไกนี้ซิงโครนัสและบล็อกผู้ส่งไม่ให้ส่งข้อความอื่นจนกว่าจะได้รับการตอบกลับ
    • XMPP: อะซิงโครนัส เซิร์ฟเวอร์แอปส่ง / รับข้อความไปยัง / จากอุปกรณ์ทั้งหมดด้วยความเร็วเต็มสายผ่านการเชื่อมต่อ XMPP แบบต่อเนื่อง เซิร์ฟเวอร์การเชื่อมต่อ XMPP ส่งการแจ้งเตือนการรับทราบหรือความล้มเหลว (ในรูปแบบของข้อความ XMPP ที่เข้ารหัส ACK และ NACK JSON แบบพิเศษ) แบบอะซิงโครนัส
  • JSON
    • HTTP: ข้อความ JSON ที่ส่งเป็น HTTP POST
    • XMPP: ข้อความ JSON ที่อยู่ในข้อความ XMPP
  • ข้อความธรรมดา
    • HTTP: ข้อความธรรมดาที่ส่งเป็น HTTP POST
    • XMPP: ไม่รองรับ
  • ปลายทางแบบหลายผู้รับส่งไปยังโทเค็นการลงทะเบียนหลายรายการ
    • HTTP: รองรับในรูปแบบข้อความ JSON
    • XMPP: ไม่รองรับ

การใช้งานโปรโตคอลเซิร์ฟเวอร์ HTTP

ในการส่งข้อความเซิร์ฟเวอร์แอปจะส่งคำขอ POST ที่มีส่วนหัว HTTP และเนื้อหา HTTP ที่ประกอบด้วยคู่ค่าคีย์ JSON สำหรับรายละเอียดเกี่ยวกับตัวเลือกส่วนหัวและเนื้อหาโปรดดูที่ สร้างเซิร์ฟเวอร์แอปส่งคำขอ

การใช้งานโปรโตคอลเซิร์ฟเวอร์ XMPP

เพย์โหลด JSON สำหรับข้อความ FCM คล้ายกับโปรโตคอล HTTP โดยมีข้อยกเว้นเหล่านี้:

  • ไม่มีการสนับสนุนสำหรับผู้รับหลายคน
  • FCM เพิ่มฟิลด์ message_id ซึ่งจำเป็น รหัสนี้ระบุข้อความโดยไม่ซ้ำกันในการเชื่อมต่อ XMPP ACK หรือ NACK จาก FCM ใช้ message_id เพื่อระบุข้อความที่ส่งจากเซิร์ฟเวอร์แอปไปยัง FCM ดังนั้นจึงเป็นสิ่งสำคัญที่ message_id นี้ไม่เพียง แต่จะไม่ซ้ำกัน (ต่อ ID ผู้ส่ง ) แต่ต้องแสดงอยู่เสมอ
  • XMPP ใช้คีย์เซิร์ฟเวอร์เพื่ออนุญาตการเชื่อมต่อแบบถาวรกับ FCM ดู อนุญาตส่งคำขอ สำหรับข้อมูลเพิ่มเติม

นอกเหนือจากข้อความ FCM ปกติแล้วข้อความควบคุมจะถูกส่งซึ่งระบุโดยฟิลด์ message_type ในออบเจ็กต์ JSON ค่าอาจเป็น "ack" หรือ "nack" หรือ "control" ก็ได้ (ดูรูปแบบด้านล่าง) เซิร์ฟเวอร์ของคุณสามารถละเว้นข้อความ FCM ที่มี message_type ไม่รู้จักได้

สำหรับข้อความอุปกรณ์แต่ละรายการที่เซิร์ฟเวอร์แอปของคุณได้รับจาก FCM จำเป็นต้องส่งข้อความ ACK ไม่จำเป็นต้องส่งข้อความ NACK หากคุณไม่ส่ง ACK สำหรับข้อความ FCM จะส่งซ้ำอีกครั้งในครั้งถัดไปที่สร้างการเชื่อมต่อ XMPP ใหม่เว้นแต่ว่าข้อความจะหมดอายุก่อน

FCM ยังส่ง ACK หรือ NACK สำหรับแต่ละข้อความระหว่างเซิร์ฟเวอร์ถึงอุปกรณ์ หากคุณไม่ได้รับแสดงว่าการเชื่อมต่อ TCP ถูกปิดในระหว่างการดำเนินการและเซิร์ฟเวอร์ของคุณจำเป็นต้องส่งข้อความอีกครั้ง ดูรายละเอียดใน Flow Control

ดูการ อ้างอิงโปรโตคอล สำหรับรายการพารามิเตอร์ข้อความทั้งหมด

รูปแบบคำขอ

ข้อความพร้อมเพย์โหลด - ข้อความแจ้งเตือน

นี่คือ XMPP stanza สำหรับข้อความแจ้งเตือน:

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

ข้อความพร้อมเพย์โหลด - ข้อความข้อมูล

นี่คือ XMPP stanza ที่มีข้อความ JSON จากเซิร์ฟเวอร์แอปไปยัง FCM:

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

รูปแบบการตอบกลับ

การตอบสนอง FCM สามารถมีได้สามรูปแบบ ข้อความแรกคือข้อความ "ack" ปกติ แต่เมื่อการตอบกลับมีข้อผิดพลาดข้อความสามารถทำได้ 2 รูปแบบตามที่อธิบายไว้ด้านล่าง

ข้อความ ACK

นี่คือ XMPP stanza ที่มีข้อความ ACK / NACK จาก FCM ไปยังเซิร์ฟเวอร์แอป:

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

NACK ข้อความ

ข้อผิดพลาด NACK คือข้อความ XMPP ปกติซึ่งข้อความสถานะ message_type คือ "nack" ข้อความ NACK ประกอบด้วย:

  • รหัสข้อผิดพลาด NACK
  • คำอธิบายข้อผิดพลาด NACK

ด้านล่างนี้คือตัวอย่างบางส่วน

การลงทะเบียนไม่ถูกต้อง:

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

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>

อัตราข้อความอุปกรณ์เกิน:

<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 ทั้งหมด ไม่ควรลองส่งข้อความ NACKed อีกครั้งเว้นแต่จะระบุไว้เป็นอย่างอื่น รหัสข้อผิดพลาด NACK ที่ไม่คาดคิดควรได้รับการปฏิบัติเช่นเดียวกับ INTERNAL_SERVER_ERROR

ข้อผิดพลาด Stanza

คุณยังสามารถรับข้อผิดพลาดของฉันท์ได้ในบางกรณี ข้อผิดพลาดของ stanza ประกอบด้วย:

  • รหัสข้อผิดพลาด Stanza
  • คำอธิบายข้อผิดพลาด Stanza (ข้อความอิสระ)

ตัวอย่างเช่น:

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

ข้อความควบคุม

FCM จำเป็นต้องปิดการเชื่อมต่อเป็นระยะเพื่อดำเนินการโหลดบาลานซ์ ก่อนที่จะปิดการเชื่อมต่อ FCM จะส่งข้อความ CONNECTION_DRAINING เพื่อระบุว่าการเชื่อมต่อกำลังหมดและจะปิดในไม่ช้า "การระบายน้ำ" หมายถึงการปิดการไหลของข้อความที่เข้ามาในการเชื่อมต่อ แต่ปล่อยให้สิ่งที่มีอยู่แล้วในไปป์ไลน์ดำเนินต่อไปได้ เมื่อคุณได้รับข้อความ CONNECTION_DRAINING คุณควรเริ่มส่งข้อความไปยังการเชื่อมต่อ FCM อื่นทันทีโดยเปิดการเชื่อมต่อใหม่หากจำเป็น อย่างไรก็ตามคุณควรเปิดการเชื่อมต่อเดิมไว้และรับข้อความที่อาจมาจากการเชื่อมต่อ (และรับข้อความ) ต่อไป - FCM จะจัดการกับการเริ่มต้นการปิดการเชื่อมต่อเมื่อพร้อม

ข้อความ CONNECTION_DRAINING มีลักษณะดังนี้:

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

ขณะนี้ CONNECTION_DRAINING รองรับเฉพาะ control_type เท่านั้น

การควบคุมการไหล

ทุกข้อความที่ส่งถึง FCM จะได้รับการตอบกลับ ACK หรือ NACK ข้อความที่ยังไม่ได้รับการตอบกลับอย่างใดอย่างหนึ่งจะถือว่าอยู่ระหว่างดำเนินการ หากจำนวนข้อความที่รอดำเนินการถึง 100 เซิร์ฟเวอร์แอปควรหยุดส่งข้อความใหม่และรอให้ FCM รับทราบข้อความที่รอดำเนินการที่มีอยู่ดังแสดงในรูปที่ 1:

รูปที่ 1. การไหลของข้อความ / ack

ในทางกลับกันเพื่อหลีกเลี่ยงไม่ให้เซิร์ฟเวอร์แอปทำงานหนักเกินไป FCM จะหยุดส่งหากมีข้อความที่ไม่ได้รับการยอมรับมากเกินไป ดังนั้นเซิร์ฟเวอร์แอปควร "ACK" ข้อความอัปสตรีมที่ได้รับจากแอปพลิเคชันไคลเอนต์ผ่าน FCM โดยเร็วที่สุดเพื่อรักษาการส่งข้อความขาเข้าอย่างต่อเนื่อง ขีด จำกัด ของข้อความที่รอดำเนินการดังกล่าวข้างต้นใช้ไม่ได้กับ ACK เหล่านี้ แม้ว่าจำนวนข้อความที่รอดำเนินการจะถึง 100 แต่เซิร์ฟเวอร์แอปควรส่ง ACK สำหรับข้อความที่ได้รับจาก FCM ต่อไปเพื่อหลีกเลี่ยงการบล็อกการส่งข้อความต้นทางใหม่

ACK ใช้ได้เฉพาะในบริบทของการเชื่อมต่อเดียว หากการเชื่อมต่อถูกปิดก่อนที่ข้อความจะ ACKed ได้เซิร์ฟเวอร์แอปควรรอให้ FCM ส่งข้อความอัปสตรีมอีกครั้งก่อนที่จะทำการ ACKing อีกครั้ง ในทำนองเดียวกันข้อความที่รอดำเนินการทั้งหมดซึ่งไม่ได้รับ ACK / NACK จาก FCM ก่อนที่จะปิดการเชื่อมต่อควรถูกส่งอีกครั้ง