這裡針對即時通訊架構，即時連線心跳檢測原理是什麼？各種配置機制的好與壞？以及如何提供穩定的連線品質，針對過去一些經驗進行分享～
一、正常情況下 斷開連結
在實作 TCP, Websocket 即時通訊架構時，在一般情況下，客戶端的連結中斷時，會向伺服器發送一個關閉連線的封包(fin)。
伺服端收到封包後，會觸發 Close 事件，並且在連結關閉後，連結就終止。
二、異常狀況斷開連結
在一些非正常狀態，例如，網路不穩定、訊號中斷、裝置故障或瀏覽器故障等情況，讓客戶端無法正常發送關閉連線的封包。
當這種異常狀況發生時，伺服端會持續保有這段連線。
三、透過心跳檢測機制解決異常斷開問題
【配置心跳機制】
要解決這種異常斷開網路，導致伺服端仍以為客戶端還在連線狀態，
做法有以下幾種：
- 客戶端定時發送心跳訊息，伺服端監聽心跳訊息
（推薦做法）
由客戶端每 30~50 秒，定時發送心跳訊息，伺服器端會進行監聽，
伺服端會判斷，當超過一定時間沒有收到心跳訊息，就會自動關閉該連線。
- 由伺服端主動定時發送心跳訊息，與監聽心跳訊息
（無用途，不推薦）
由伺服端主動發送心跳訊息給客戶端，但客戶端不回應也不會定時發送心跳訊息。
這樣的方式，伺服端還是無法知道客戶端是否正常在連線狀態。
- 由伺服端主動發送心跳訊息與監聽狀態，客戶端同時也回應心跳
（較不推薦）
由客戶端定時發送心跳訊息，
同時，伺服器端也會主動向客戶端發送心跳檢測，
客戶端收到心跳訊息時，就主動向伺服端發送訊息。
【指定客戶端需發送心跳數據，並監督】
在上面配置心跳訊息，重點在於，客戶端必須要向伺服端發送心跳訊息，監督機制才能有效進行。
在伺服端，會強制客戶端必須要在心跳間隔時間內，客戶端要向伺服端發送訊息，不然就會認為客戶端已離線。
通常，心跳間隔不會固定，當一段時間客戶端都正常發送訊息後，就會延長心跳間隔。
四、異常狀態發生後，客戶端自動重新建立連結機制
最後，針對異常狀態造成客戶端連線中斷 來做一個討論。
正常情況，只要連線中斷，服務就無法再使用。
在實際用戶操作時，只要在捷運、屋內等4G訊號不穩的地方，隨時都可能有連線中斷的情況發生。
因此，為了提供穩定的連線品質體驗，在客戶端搭建斷線後，自動監測重建連線，
可以在異常狀況後，恢復服務。