今天發表幾點個人看法，關於心跳包的
最近實現基於websocket的通信，app客戶端和服務端的websocket服務
考慮到惡劣的網絡環境和其它各種意想不到的情況，爲了充分檢查websocket的連接狀態，額外採用心跳包的方式，每隔一段時間發送訊息，檢測websocket的連接狀態
在客戶端做心跳還是在服務端做心跳？心跳包的時間間隔多久合適？
經過再三分析，決定還是在客戶端做心跳比較合理，因爲客戶端做心跳發送的數據不會很集中，服務端可以承受的住，如果在服務端做心跳，單次發送的數量會很大，服務端很佔資源
客戶端多久做一次心跳，這個根據服務器的性能和服務的是否健壯來決定，如果服務器很一般建議大於一分鐘，如果服務器很強大，10秒20秒也是很輕鬆的事情
服務端如何清理一些死連接？
通常服務端會緩存websocket，但是由於各種意想不到的情況，總有連接已經死掉了，在正常的處理中無法清理，但是還放在容器中，所以要定時清理。間隔時間就可以設置的時間長一點了，比如一小時
服務端可以做一個心跳處理，僅僅用於處理清理，不做心跳發送，因爲服務端做心跳發送，在連接很多的情況下太佔資源。
如何做清理？可以在收到客戶端心跳響應的時候，做個更新時間，然後服務端根據這個時間來清理間隔時間很久的連接。
插播一個和心跳包關係可能不是很大的問題，消息發送如何確定消息發送成功？
譬如A和B聊天，A發送了幾條信息，A如何知道發送成功了？
我似乎沒有想到很好的辦法，首先要知道什麼叫發送成功，只要A和服務端的通信是成功的，我們就可以認爲就是發送成功，
因此服務端收到A發送的消息要給A做個響應，A纔可以知道消息發送成功了，至於有沒有發送到B，那是B和服務端之間的事情，A管不到也不需要管
那麼A如何管理這些消息呢
客戶端生成唯一消息ID,譬如A發送了一個消息id爲ASFT23的消息，此時默認狀態是未知的，客戶端由於緩存的了消息，所以狀態管理不是問題，這個時候客戶端收到了ASFT23的響應消息，已經確定是成功的了，更新狀態爲成功，那麼如何知道哪些不成功呢？因此客戶端還是少不了心跳檢測，如何檢測呢？只要客戶端每隔30秒或者20秒檢測一次，狀態是未知的並且時間超過20秒就認爲是一個失敗信息
是否有更好的方案？歡迎評論