學過TCP/IP的同學應該都知道，傳輸層的兩個主要協議是UDP和TCP，其中UDP是無連接的、面向packet的，而TCP協議是有連接、面向流的協議。
所以非常容易理解，使用UDP協議的客戶端（例如早期的“OICQ”，聽說OICQ.com這兩天被搶注了來着，好古老的回憶）需要定時向服務器發送心跳包，告訴服務器自己在線。
然而，MSN和現在的QQ往往使用的是TCP連接了，儘管TCP/IP底層提供了可選的KeepAlive（ACK-ACK包）機制，但是它們也還是實現了更高層的心跳包。似乎既浪費流量又浪費CPU，有點莫名其妙。
具體查了下，TCP的KeepAlive機制是這樣的，首先它貌似默認是不打開的，要用setsockopt將SOL_SOCKET.SO_KEEPALIVE設置爲1纔是打開，並且可以設置三個參數tcp_keepalive_time/tcp_keepalive_probes/tcp_keepalive_intvl，分別表示連接閒置多久開始發keepalive的ack包、發幾個ack包不回覆才當對方死了、兩個ack包之間間隔多長，在我測試的Ubuntu Server 10.04下面默認值是7200秒（2個小時，要不要這麼蛋疼啊！）、9次、75秒。於是連接就了有一個超時時間窗口，如果連接之間沒有通信，這個時間窗口會逐漸減小，當它減小到零的時候，TCP協議會向對方發一個帶有ACK標誌的空數據包（KeepAlive探針），對方在收到ACK包以後，如果連接一切正常，應該回復一個ACK；如果連接出現錯誤了（例如對方重啓了，連接狀態丟失），則應當回覆一個RST；如果對方沒有回覆，服務器每隔intvl的時間再發ACK，如果連續probes個包都被無視了，說明連接被斷開了。
這裏有一篇非常詳細的介紹文章： http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO ，包括了KeepAlive的介紹、相關內核參數、C編程接口、如何爲現有應用（可以或者不可以修改源碼的）啓用KeepAlive機制，很值得詳讀。
這篇文章的2.4節說的是“Preventing disconnection due to network inactivity”，阻止因網絡連接不活躍（長時間沒有數據包）而導致的連接中斷，說的是，很多網絡設備，尤其是NAT路由器，由於其硬件的限制（例如內存、CPU處理能力），無法保持其上的所有連接，因此在必要的時候，會在連接池中選擇一些不活躍的連接踢掉。典型做法是LRU，把最久沒有數據的連接給T掉。通過使用TCP的KeepAlive機制（修改那個time參數），可以讓連接每隔一小段時間就產生一些ack包，以降低被T掉的風險，當然，這樣的代價是額外的網絡和CPU負擔。
前面說到，許多IM協議實現了自己的心跳機制，而不是直接依賴於底層的機制，不知道真正的原因是什麼。
就我看來，一些簡單的協議，直接使用底層機制就可以了，對上層完全透明，降低了開發難度，不用管理連接對應的狀態。而那些自己實現心跳機制的協議，應該是期望通過發送心跳包的同時來傳輸一些數據，這樣服務端可以獲知更多的狀態。例如某些客戶端很喜歡收集用戶的信息……反正是要發個包，不如再塞點數據，否則包頭又浪費了……
大概就是這樣吧，如果有大牛知道真正的原因，還望不吝賜教。
@2012-04-21
p.s. 通過諮詢某個做過IM的同事，參考答案應該是，自己實現的心跳機制通用，可以無視底層的UDP或TCP協議。如果只是用TCP協議的話，那麼直接使用KeepAlive機制就足夠了。
--
轉載請註明出自 http://www.felix021.com/blog/read.php?2076 ，如是轉載文則註明原出處，謝謝:)
RSS訂閱地址: http://www.felix021.com/blog/feed.php 。