• <acronym id="bheaa"><strong id="bheaa"></strong></acronym>

    <pre id="bheaa"><del id="bheaa"></del></pre>

    <td id="bheaa"><ruby id="bheaa"></ruby></td>
  • <li id="bheaa"></li>

    <table id="bheaa"><ruby id="bheaa"></ruby></table>
      網頁端消息推送之推與拉
      發布時間:2019-12-13 發布者:文案編輯 來源:原創/投稿/轉載

        用戶A在網頁段登陸,系統或其他用戶的某些操作會導致在網頁顯示消息,用以提醒用戶。實現方式大致有三種。

        效率低下:發消息是一個低頻動作,如果10次輪詢才收到1條消息,請求有效性只有10%,浪費了大量服務器資源

        更要命的是,在這種方案下,實時性與效率是一對不可調和的矛盾:如果將輪詢周期設為1/10,將時延縮短到1秒,意味著100次輪詢才會收到1條消息,請求有效性則降為了1%。

        如果要兼顧實時性和效率,長連接是最佳之選,PC端聊天軟件基本都是使用長連接。網頁端常見的實現長連接的方式有兩種:

        局限性:由于websocket需要瀏覽器的支持,瀏覽器需要web-server支持,如果用戶的瀏覽器不支持websocket功能,容易導致用戶缺失某些功能。

        不像普通的“請求-響應”式HTTP請求,這個HTTP會被服務端夯住,直到有推送通知到達,或者超過約定的時間

        畫外音:對于HTTP請求,為了提高效率,一般來說browser和web-server都會有一些設置,如果一條HTTP請求長時間沒有數據(例如,150秒),會被斷開!巴ㄖB接”為了不被browser和web-server粗暴斷開,一般會設置一個約定閾值(例如,小于150秒),由系統返回一個空消息,以便“優雅返回”。

        上面三個場景的最終狀態,都是“一定,永遠,會有一條通知連接,連接在瀏覽器與服務器之間”,這樣就能夠保證消息的實時性。當然,有人會說,HTTP的返回與再次發起會有一個時間差,如果這個時間差,恰巧有新消息過來呢?

        最后這個場景,發生的概率非常小,但也確保了在“HTTP的返回與再次發起會有一個時間差”內,消息不會丟失,在通知連接發起后,消息能夠實時返回。

        最通用的方式是長輪詢,通過HTTP短連接拼裝長連接,具體是通過“夯住”“只收推送通知”的“通知連接”來實現的,能夠做到消息的實時性到達

      熱點推薦