關於網路那些事...

網路行銷,SEO,網路趨勢,教學文章,網頁設計,生活時事

即時通訊架構-心跳檢測原理說明

| Comments

這裡針對即時通訊架構,即時連線心跳檢測原理是什麼?各種配置機制的好與壞?以及如何提供穩定的連線品質,針對過去一些經驗進行分享~

一、正常情況下 斷開連結

在實作 TCP, Websocket 即時通訊架構時,在一般情況下,客戶端的連結中斷時,會向伺服器發送一個關閉連線的封包(fin)。

伺服端收到封包後,會觸發 Close 事件,並且在連結關閉後,連結就終止。

二、異常狀況斷開連結

在一些非正常狀態,例如,網路不穩定、訊號中斷、裝置故障或瀏覽器故障等情況,讓客戶端無法正常發送關閉連線的封包。

當這種異常狀況發生時,伺服端會持續保有這段連線。

三、透過心跳檢測機制解決異常斷開問題

【配置心跳機制】

要解決這種異常斷開網路,導致伺服端仍以為客戶端還在連線狀態,

做法有以下幾種:

  1. 客戶端定時發送心跳訊息,伺服端監聽心跳訊息

(推薦做法)

由客戶端每 30~50 秒,定時發送心跳訊息,伺服器端會進行監聽,

伺服端會判斷,當超過一定時間沒有收到心跳訊息,就會自動關閉該連線。

  1. 由伺服端主動定時發送心跳訊息,與監聽心跳訊息

(無用途,不推薦)

由伺服端主動發送心跳訊息給客戶端,但客戶端不回應也不會定時發送心跳訊息。

這樣的方式,伺服端還是無法知道客戶端是否正常在連線狀態。

  1. 由伺服端主動發送心跳訊息與監聽狀態,客戶端同時也回應心跳

(較不推薦)

由客戶端定時發送心跳訊息,

同時,伺服器端也會主動向客戶端發送心跳檢測,

客戶端收到心跳訊息時,就主動向伺服端發送訊息。

【指定客戶端需發送心跳數據,並監督】

在上面配置心跳訊息,重點在於,客戶端必須要向伺服端發送心跳訊息,監督機制才能有效進行。

在伺服端,會強制客戶端必須要在心跳間隔時間內,客戶端要向伺服端發送訊息,不然就會認為客戶端已離線。

通常,心跳間隔不會固定,當一段時間客戶端都正常發送訊息後,就會延長心跳間隔。

四、異常狀態發生後,客戶端自動重新建立連結機制

最後,針對異常狀態造成客戶端連線中斷 來做一個討論。

正常情況,只要連線中斷,服務就無法再使用。

在實際用戶操作時,只要在捷運、屋內等4G訊號不穩的地方,隨時都可能有連線中斷的情況發生。

因此,為了提供穩定的連線品質體驗,在客戶端搭建斷線後,自動監測重建連線,

可以在異常狀況後,恢復服務。


最後,如果你喜歡這篇文章,請幫忙點個讚



最新文章推薦

討論

comments powered by Disqus