Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.
Trang này được dịch bởi Cloud Translation API.
Switch to English

Môi trường máy chủ và FCM của bạn

Phía máy chủ của Firebase Cloud Messaging bao gồm hai thành phần:

  • Phần phụ trợ FCM do Google cung cấp.
  • Máy chủ ứng dụng của bạn hoặc môi trường máy chủ đáng tin cậy khác nơi logic máy chủ của bạn chạy, chẳng hạn như Chức năng đám mây cho Firebase hoặc các môi trường đám mây khác do Google quản lý.

Máy chủ ứng dụng hoặc môi trường máy chủ đáng tin cậy của bạn sẽ gửi các yêu cầu tin nhắn đến phần phụ trợ FCM, sau đó định tuyến thông báo đến các ứng dụng khách đang chạy trên thiết bị của người dùng.

Yêu cầu đối với môi trường máy chủ đáng tin cậy

Môi trường máy chủ ứng dụng của bạn phải đáp ứng các tiêu chí sau:

  • Có thể gửi các yêu cầu tin nhắn được định dạng đúng tới phần phụ trợ FCM.
  • Có thể xử lý các yêu cầu và gửi lại chúng bằng cách sử dụng dự phòng theo cấp số nhân.
  • Có thể lưu trữ an toàn thông tin xác thực ủy quyền máy chủ và mã thông báo đăng ký khách hàng.
  • Đối với giao thức XMPP (nếu được sử dụng), máy chủ phải có khả năng tạo ID thông báo để nhận dạng duy nhất từng thông báo mà nó gửi (chương trình phụ trợ HTTP FCM tạo ID thông báo và trả lại chúng trong phản hồi). ID tin nhắn XMPP phải là duy nhất cho mỗi ID người gửi.

Chọn một tùy chọn máy chủ

Bạn sẽ cần quyết định cách tương tác với máy chủ FCM: sử dụng SDK quản trị Firebase hoặc các giao thức thô. Do hỗ trợ trên các ngôn ngữ lập trình phổ biến và các phương pháp tiện lợi để xử lý xác thực và ủy quyền, nên SDK quản trị Firebase là phương pháp được khuyến nghị.

Các tùy chọn để tương tác với máy chủ FCM bao gồm:
  • SDK quản trị Firebase, hỗ trợ Node , Java , Python , C #Go .
  • API FCM HTTP v1 , là tùy chọn giao thức cập nhật nhất, với khả năng ủy quyền an toàn hơn và khả năng nhắn tin đa nền tảng linh hoạt (SDK quản trị Firebase dựa trên giao thức này và cung cấp tất cả các lợi thế vốn có của nó).
  • Giao thức HTTP kế thừa.
  • Giao thức máy chủ XMPP . Lưu ý rằng nếu bạn muốn sử dụng nhắn tin ngược dòng từ các ứng dụng khách của mình, bạn phải sử dụng XMPP.

SDK quản trị Firebase cho FCM

API quản trị FCM xử lý việc xác thực với phần phụ trợ và tạo điều kiện cho việc gửi tin nhắn và quản lý đăng ký chủ đề. Với SDK quản trị Firebase, bạn có thể:

  • Gửi tin nhắn đến từng thiết bị
  • Gửi tin nhắn đến các chủ đề và câu điều kiện phù hợp với một hoặc nhiều chủ đề.
  • Đăng ký và hủy đăng ký các thiết bị đến và từ các chủ đề
  • Xây dựng tải trọng tin nhắn phù hợp với các nền tảng mục tiêu khác nhau

SDK quản trị Node.js cung cấp các phương pháp gửi thông báo đến các nhóm thiết bị.

Để thiết lập SDK quản trị Firebase, hãy xem Thêm SDK quản trị Firebase vào máy chủ của bạn . Nếu bạn đã có dự án Firebase, hãy bắt đầu với Thêm SDK . Sau đó, khi SDK quản trị Firebase được cài đặt, bạn có thể bắt đầu viết logic để tạo yêu cầu gửi .

Giao thức máy chủ FCM

Hiện tại FCM cung cấp các giao thức máy chủ thô này:

Máy chủ ứng dụng của bạn có thể sử dụng các giao thức này riêng biệt hoặc song song. Bởi vì nó là cập nhật mới nhất và linh hoạt nhất để gửi tin nhắn đến nhiều nền tảng, nên API FCM HTTP v1 được khuyến nghị ở bất kỳ nơi nào khả thi. Nếu yêu cầu của bạn bao gồm nhắn tin ngược dòng từ các thiết bị tới máy chủ, bạn sẽ cần triển khai giao thức XMPP.

Nhắn tin XMPP khác với nhắn tin HTTP theo những cách sau:

  • Tin nhắn ngược dòng / xuôi dòng
    • HTTP: Chỉ xuống dòng, từ đám mây đến thiết bị.
    • XMPP: Upstream và down (thiết bị lên đám mây, đám mây với thiết bị).
  • Nhắn tin (đồng bộ hoặc không đồng bộ)
    • HTTP: Đồng bộ. Máy chủ ứng dụng gửi tin nhắn dưới dạng yêu cầu HTTP POST và chờ phản hồi. Cơ chế này đồng bộ và chặn người gửi gửi tin nhắn khác cho đến khi nhận được phản hồi.
    • XMPP: Không đồng bộ. Máy chủ ứng dụng gửi / nhận tin nhắn đến / từ tất cả các thiết bị của họ ở tốc độ đường truyền tối đa qua kết nối XMPP liên tục. Máy chủ kết nối XMPP gửi thông báo xác nhận hoặc thông báo lỗi (ở dạng thông báo XMPP được mã hóa ACK và NACK JSON đặc biệt) không đồng bộ.
  • JSON
    • HTTP: Thư JSON được gửi dưới dạng HTTP POST.
    • XMPP: Thông báo JSON được gói gọn trong các thông báo XMPP.
  • Văn bản thô
    • HTTP: Tin nhắn văn bản thuần được gửi dưới dạng HTTP POST.
    • XMPP: Không được hỗ trợ.
  • Multicast xuôi dòng gửi đến nhiều mã thông báo đăng ký.
    • HTTP: Được hỗ trợ ở định dạng thông báo JSON.
    • XMPP: Không được hỗ trợ.

Triển khai giao thức máy chủ HTTP

Để gửi tin nhắn, máy chủ ứng dụng đưa ra yêu cầu ĐĂNG với tiêu đề HTTP và nội dung HTTP bao gồm các cặp giá trị khóa JSON. Để biết chi tiết về các tùy chọn tiêu đề và nội dung, hãy xem Xây dựng yêu cầu gửi máy chủ ứng dụng

Triển khai giao thức máy chủ XMPP

Tải trọng JSON cho các thông báo FCM tương tự như giao thức HTTP, với các ngoại lệ sau:

  • Không có hỗ trợ cho nhiều người nhận.
  • FCM thêm trường message_id , bắt buộc. ID này xác định duy nhất tin nhắn trong kết nối XMPP. ACK hoặc NACK từ FCM sử dụng message_id để xác định thông báo được gửi từ máy chủ ứng dụng tới FCM. Do đó, điều quan trọng là message_id này không chỉ là duy nhất (mỗi ID người gửi ) mà còn phải luôn hiện diện.
  • XMPP sử dụng khóa máy chủ để cho phép kết nối liên tục với FCM. Xem Ủy quyền Gửi Yêu cầu để biết thêm thông tin.

Ngoài các thông báo FCM thông thường, các thông báo điều khiển được gửi, được chỉ ra bởi trường message_type trong đối tượng JSON. Giá trị có thể là 'ack' hoặc 'nack' hoặc 'control' (xem các định dạng bên dưới). Máy chủ của bạn có thể bỏ qua bất kỳ thông báo FCM nào có message_type không xác định.

Đối với mỗi tin nhắn thiết bị mà máy chủ ứng dụng của bạn nhận được từ FCM, nó cần gửi một tin nhắn ACK. Nó không bao giờ cần gửi tin nhắn NACK. Nếu bạn không gửi ACK cho một tin nhắn, FCM sẽ gửi lại nó vào lần tiếp theo khi kết nối XMPP mới được thiết lập, trừ khi tin nhắn hết hạn trước.

FCM cũng gửi một ACK hoặc NACK cho mỗi tin nhắn từ máy chủ đến thiết bị. Nếu bạn cũng không nhận được, điều đó có nghĩa là kết nối TCP đã bị đóng giữa quá trình hoạt động và máy chủ của bạn cần gửi lại tin nhắn. Xem Kiểm soát dòng để biết chi tiết.

Xem Tham chiếu Giao thức để biết danh sách tất cả các tham số thông báo.

Yêu cầu định dạng

Tin nhắn có tải trọng - tin nhắn thông báo

Đây là một đoạn thơ XMPP cho một tin nhắn thông báo:

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

Tin nhắn có tải trọng - tin nhắn dữ liệu

Đây là một đoạn thơ XMPP chứa thông điệp JSON từ máy chủ ứng dụng tới 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>

Định dạng phản hồi

Phản hồi FCM có thể có ba dạng. Đầu tiên là một thông báo 'ack' thông thường. Nhưng khi phản hồi có lỗi, thông báo có thể có 2 dạng khác nhau, được mô tả bên dưới.

Tin nhắn ACK

Đây là một đoạn thơ XMPP chứa thông báo ACK / NACK từ FCM đến máy chủ ứng dụng:

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

Tin nhắn NACK

Lỗi NACK là một thông báo XMPP thông thường trong đó thông báo trạng thái message_type là "nack". Thông báo NACK chứa:

  • Mã lỗi NACK.
  • Mô tả lỗi NACK.

Dưới đây là một số ví dụ.

Đăng ký không hợp lệ:

<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 không hợp lệ:

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

Tốc độ tin nhắn trên thiết bị đã vượt quá:

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

Xem Tham chiếu Máy chủ để biết danh sách đầy đủ các mã lỗi NACK. Trừ khi có chỉ định khác, không nên thử lại tin nhắn NACKed. Mã lỗi NACK không mong muốn phải được xử lý giống như INTERNAL_SERVER_ERROR .

Lỗi Stanza

Bạn cũng có thể gặp lỗi khổ thơ trong một số trường hợp nhất định. Một lỗi khổ thơ có:

  • Mã lỗi Stanza.
  • Mô tả lỗi Stanza (văn bản miễn phí).

Ví dụ:

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

Kiểm soát tin nhắn

Định kỳ, FCM cần đóng kết nối để thực hiện cân bằng tải. Trước khi đóng kết nối, FCM sẽ gửi một thông báo CONNECTION_DRAINING để cho biết rằng kết nối đang bị ngắt và sẽ sớm bị đóng. "Draining" đề cập đến việc tắt luồng thông báo đến một kết nối, nhưng vẫn cho phép bất cứ thứ gì đã có trong đường ống tiếp tục. Khi bạn nhận được tin nhắn CONNECTION_DRAINING , bạn nên bắt đầu gửi ngay tin nhắn tới một kết nối FCM khác, mở một kết nối mới nếu cần. Tuy nhiên, bạn nên giữ kết nối ban đầu mở và tiếp tục nhận các thông báo có thể đến qua kết nối (và ACKing chúng) —FCM xử lý việc bắt đầu đóng kết nối khi nó sẵn sàng.

Thông báo CONNECTION_DRAINING trông giống như sau:

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

CONNECTION_DRAINING hiện là loại control_type duy nhất được hỗ trợ.

Kiểm soát lưu lượng

Mỗi tin nhắn được gửi đến FCM đều nhận được phản hồi ACK hoặc NACK. Thư chưa nhận được một trong những phản hồi này được coi là đang chờ xử lý. Nếu số lượng tin nhắn đang chờ xử lý đạt đến 100, máy chủ ứng dụng sẽ ngừng gửi tin nhắn mới và đợi FCM xác nhận một số tin nhắn đang chờ xử lý hiện có như được minh họa trong hình 1:

Hình 1. Luồng thông điệp / ack.

Ngược lại, để tránh quá tải máy chủ ứng dụng, FCM ngừng gửi nếu có quá nhiều thư chưa được xác nhận. Do đó, máy chủ ứng dụng nên "ACK" các tin nhắn ngược dòng, nhận được từ ứng dụng khách qua FCM, càng sớm càng tốt để duy trì luồng tin nhắn đến liên tục. Giới hạn tin nhắn đang chờ xử lý nói trên không áp dụng cho các ACK này. Ngay cả khi số lượng tin nhắn đang chờ xử lý đạt đến 100, máy chủ ứng dụng phải tiếp tục gửi ACK cho các tin nhắn nhận được từ FCM để tránh chặn gửi các tin nhắn ngược dòng mới.

ACK chỉ hợp lệ trong ngữ cảnh của một kết nối. Nếu kết nối bị đóng trước khi có thể ACK một thông báo, máy chủ ứng dụng phải đợi FCM gửi lại thông báo ngược dòng trước khi ACKing lại. Tương tự, tất cả các tin nhắn đang chờ xử lý mà ACK / NACK không nhận được từ FCM trước khi kết nối bị đóng phải được gửi lại.