Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติสำหรับชุมชนคนผิวดำ มาดูกันว่า
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

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

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

  • แบ็กเอนด์ FCM ให้บริการโดย Google
  • เซิร์ฟเวอร์แอป ของคุณหรือ สภาพแวดล้อมเซิร์ฟเวอร์ที่เชื่อถือได้ อื่น ๆ ซึ่งเซิร์ฟเวอร์ของคุณทำงานแบบลอจิกเช่น ฟังก์ชั่นคลาวด์สำหรับ 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 โปรดทราบว่าหากคุณต้องการใช้การส่งข้อความ upstream จากแอปพลิเคชันไคลเอนต์ของคุณคุณต้องใช้ XMPP

Firebase Admin SDK สำหรับ FCM

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ไม่มีการรองรับผู้รับหลายคน
  • FCM เพิ่มฟิลด์ message_id ซึ่งจำเป็นต้องมี 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

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

รูปแบบคำขอ

ข้อความที่มี payload - ข้อความแจ้งเตือน

นี่คือ 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>

ข้อความที่มี payload - ข้อความข้อมูล

นี่คือ 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
  • คำอธิบายข้อผิดพลาดของ 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 อื่นทันทีโดยเปิดการเชื่อมต่อใหม่หากจำเป็น อย่างไรก็ตามคุณควรให้เปิดการเชื่อมต่อเดิมและรับข้อความที่อาจเข้ามาเชื่อมต่อ (และ ACKing พวกเขา) - 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 เพื่อหลีกเลี่ยงการบล็อกการส่งข้อความอัปสตรีมใหม่

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