《Web 推送通知》系列翻譯 | 第二篇:推送是怎麼工做的?

原文地址:how-push-workshtml

譯文地址:推送是怎麼工做的?git

譯者:劉鵬github

校對者:任家樂張卓web

在咱們接觸這個 API 以前,讓咱們先從一個高層次從頭至尾來看一下推送。稍後咱們將經過逐一介紹各個主題和 API 讓你知道爲何推送是這麼重要。數據庫

下面將介紹實現推送的三個關鍵步驟:後端

  1. 添加客戶端側的邏輯來給用戶訂閱推送(也就是使用 Web App 當中的 JavaScript 和 UI,幫助用戶註冊推送消息)。
  2. 從你的後臺/應用調用 API 來觸發推送消息到用戶的設備。
  3. 當推送到達用戶的設備時,service worker 能夠接收到「推送事件」,經過使用 service worker 你將展現出一個通知。

讓咱們更加詳細的來看一下這三個步驟。瀏覽器

Step 1: 客戶端側

第一步是 「訂閱」 一個用戶來推送消息。緩存

訂閱一個用戶須要2個條件。第一,從用戶那裏獲取給他們發送消息的許可。第二,從瀏覽器那裏獲取 PushSubscription安全

PushSubscription 包含了咱們須要推送消息給目標用戶的全部信息。這個信息能夠某種程度上認爲是用戶設備的 ID。服務器

這些所有能夠經過 JavaScript 調用 Push API 來實現。

在咱們訂閱一個用戶以前,咱們須要生成一套應用服務器密鑰。這個咱們後續會解釋。

應用服務器密鑰,也被稱爲 VAPID 密鑰,對你的服務器來講是獨一無二的。有了它,推送服務知道是哪個應用服務器註冊了一個用戶,而且確保了是同一個服務器觸發了推送消息給那個用戶。

一旦你訂閱了一個用戶,而且拿到了 PushSubscription,你須要將關於這個 PushSubscription 的詳細信息發送至你的後臺/服務器。在服務器上,你須要將這個訂閱保存至數據庫當中,並使用它給用戶推送消息。

確保你發送了 `PushSubscription` 到你的後端

Step 2: 發送一個推送消息

當你想要發送一個推送消息到目標用戶,你須要執行一個 API 調用到推送服務。這個 API 包括:發送的數據、發送的對象和任何關於如何發送這條消息的標準。通常狀況下這個 API 調用是由你的服務器來完成的。

你可能會有一些疑問:

  • 推送服務是誰/是什麼?
  • 這個 API 長什麼樣?它是 JSON 格式?XML 格式?仍是其餘什麼格式?
  • 這個 API 能幹什麼?

推送服務是誰/是什麼?

推送服務接收到一個網絡請求,校驗該請求的正確性,而後發送一個推送消息到合適的瀏覽器。若是瀏覽器正好離線,這條消息會排隊直到這個瀏覽器從新在線以後發送給它。

每一個瀏覽器都能使用他們想用的任何一個推送服務,這個是開發者管控不了的。這其實並非一個問題,由於每個推送服務都接受相同的 API 調用。也就是說你沒必要擔憂這個推送服務是誰。你只須要確保你的 API 調用是正確的。

要得到合適的 URL 來觸發推送消息(也就是推送服務的 URL),你只須要查看一下前面得到的 PushSubscriptionendPoint 的值。

下面是 PushSubscription 的一個示例:

{
  "endpoint": "https://random-push-service.com/some-kind-of-unique-id-1234/v2/",
  "keys": {
    "p256dh" :
"BNcRdreALRFXTkOOUHK1EtK2wtaz5Ry4YfYCA_0QTpQtUbVlUls0VJXg7A8u-Ts1XbjhazAkj7I99e8QcYP7DkM=",
    "auth"   : "tBHItJI5svbpez7KI4CCXg=="
  }
}
複製代碼

這個示例當中的 endpointhttps://random-push-service.com/some-kind-of-unique-id-1234/v2/。 推送服務應該是 random-push-service.com,如 some-kind-of-unique-id-1234 所示,每一個 endpoint 對用戶來講都是獨一無二的。 當你開始着手於推送以後,你會注意到這個模式。

關於上述示例當中的 key 這個字段,咱們後續會講到,這裏就先不解釋了。

這個 API 是什麼樣的?

我前面提到每一個 Web 推送服務須要的是相同的 API 調用。這個 API 就是 Web 推送協議。 它是一個 IETF 標準,定義瞭如何向一個推送服務執行一個 API 調用。

這個 API 調用須要設置一些頭部,而且須要以字節流的方式發送數據。咱們將看一下如何用庫來執行這個 API,以及本身如何來實現這個 API。

這個 API 能作什麼?

這個 API 提供了發送消息到用戶的一種方法,消息能夠攜帶,也能夠不攜帶數據。同時它也提供了如何發送消息的指導方法。

你經過推送服務發送的數據必須是加密的。緣由是推送服務能夠是任何人,你必須防止他可以看到數據明文。這很重要,由於是瀏覽器決定(而不是開發者)該用哪個推送服務,而那些不安全的推送服務可能打開瀏覽器的安全大門。

當你觸發一個推送消息,推送服務接收了 API 調用,而後將消息放到隊列當中。這個消息會一直呆在隊列當中,直到用戶的設備上線,而後推送服務就能夠將消息發送過去。你能給推送服務指示來決定推送消息是如何排隊的。

這些指示包含以下:

  • 推送消息的 TTL(生存時間)。這個定義了一條消息在沒有發送並移除前,能在隊列當中排多長時間。
  • 設置消息的緊急度。這在推送服務爲了保持用戶的電量狀況下,只推送高優先級的消息時頗有用。
  • 給推送消息一個話題名,擁有相同話題的新消息將替換掉仍在排隊的老消息。

當你的服務器但願發送一個推送消息,它須要發送一個 Web 推送協議請求至推送服務

Step 3: 用戶設備上的推送事件

一旦咱們發出一個推送消息,推送服務會保留咱們的消息,直至下面的任一一種狀況發生:

  1. 設備在線,而後推送服務發送消息。
  2. 消息過時。若是消息過時,推送服務會將這條消息從它的隊列當中移除,這樣消息就永遠不會再發送了。

當推送服務確實發送了一條消息,瀏覽器會接收到這條消息,解密數據,而且會在你的 service worker 中觸發一個推送事件。

service worker 是一個特殊的 JavaScript 文件。即便瀏覽器沒有打開,瀏覽器依然能夠執行這個 JavaScript。service worker 也擁有它本身的 API,好比推送,這些 API 在 Web 頁面是不存在的(也就是說這些 API 在 service worker 腳本以外沒法被使用)。

祕密就是位於 service worker 的推送事件當中,它能讓你能執行任何後臺任務。你能夠執行分析調用、緩存離線頁面和彈出通知等。

當推送服務發送一條推送消息給用戶的設備,設備的 service worker 將收到一個推送事件

這就是整個推送消息的流程。讓咱們更詳細的來看一下其中的每一步吧。

更多分享,請關注YFE:

上一篇:《Web 推送通知》系列翻譯 | 引言&概覽

下一篇:《Web 推送通知》系列翻譯 | 第三篇:訂閱一個用戶

相關文章
相關標籤/搜索