TCP/IP協(xié)議是計算機通信網絡中目前使用最多的協(xié)議，同時也融入了生活的方方面面，不管是瀏覽網頁使用的http/https協(xié)議、物聯(lián)網設備使用的MQTT/MQTTS協(xié)議與下載文件使用的ftp協(xié)議、工業(yè)以太網中使用的Modbus TCP協(xié)議等很多應用層協(xié)議，都是基于TCP/IP協(xié)議簇。
前文我們介紹了TCP流控機制的詳解，本文我們將介紹TCP keep-alive(?；?機制詳解。
?TCP Keepalive機制?是一種用于檢測TCP連接是否仍然活躍的機制。當TCP連接在一段時間內沒有數(shù)據(jù)傳輸時，Keepalive機制會發(fā)送探測報文來檢測對方是否仍然在線。如果對方正常響應，連接將被重置，等待下一個探測周期；如果對方沒有響應，連接將被認為是死連接，并最終被關閉。
當TCP連接在一段時間內沒有數(shù)據(jù)傳輸時，Keepalive機制會發(fā)送探測報文。如果對方正常工作并響應這個探測報文，連接將被重置，等待下一個探測周期。如果對方沒有響應，連續(xù)幾次探測后，TCP會認為連接已經死亡，并關閉該連接。
TCP Keepalive機制涉及幾個關鍵參數(shù)：
??keepidle?：無數(shù)據(jù)傳輸時開始發(fā)送探測報文的時間間隔。
??keepinterval?：發(fā)送探測報文的間隔時間。
??keepcount?：發(fā)送探測報文的次數(shù)，如果對方沒有響應，連接將被關閉。
一般的，TCP的客戶端與服務器的連接類型可以分為：
1、短鏈接：客戶端連接到服務器后，即開始與服務器交互，請求資源，上報數(shù)據(jù)等，交互完畢后即斷開與服務器的連接，如Http協(xié)議等。
2、長連接：客戶端連接到服務器后，不一定會立即進行數(shù)據(jù)的傳遞，而是一直保持連接狀態(tài)，且雙方一般不會主動斷開連接，如MQTT協(xié)議等。
需要注意的是，不管是長連接還是短連接都不是TCP協(xié)議本身所規(guī)定的，TCP只是給應用層提供了建立與斷開連接的方法與資源管理。
可以想到，當客戶端與服務器處于長連接狀態(tài)下，如果服務器突然斷電了，服務器也無法通知客戶端異常狀況，客戶端就無法察覺服務器異常。只有當客戶端向服務器發(fā)送數(shù)據(jù)時，由于超時機制，客戶端才能知道服務器異常。并且數(shù)據(jù)也自然丟棄了。而且如果異常連接無法釋放，也會導致系統(tǒng)資源的消耗與浪費。所以在長連接下，就可以啟用TCP 的Keep-alive機制，避免一方可能意外斷電、死機、崩潰、重啟，還是中間路由網絡無故斷開，從而導致的異常連接。
相關參數(shù)如下所示：
SO_KEEPALIVE：是否開啟?；?/span>
TCP_KEEPIDLE：Start keeplives after this period
TCP_KEEPINTVL：Interval between keepalives
TCP_KEEPCNT：Number of keepalives before death
SO_KEEPALIVE：Keep-alive可以是雙向的，即客戶端可以主動給服務器發(fā)，或服務器主動給客戶端發(fā)送。在使能了SO_KEEPALIVE后，即啟用了?；顧C制
TCP_KEEPIDLE：當客戶端與服務器沒有交互數(shù)據(jù)達到TCP_KEEPIDLE的空閑時間后，TCP將會給對方發(fā)送探測包。
TCP_KEEPINTVL：如果上一次的探測包沒有得到響應，那么將用TCP_KEEPINTVL作為下一次的探測包間隔
TCP_KEEPCNT：當連續(xù)發(fā)送了TCP_KEEPCNT次數(shù)的探測包都未收到響應后，本地將會釋放當前連接資源，并且通知應用層連接斷開
正常探測包
掉線過程
接下來測試KeepAlive斷開：正常TCP建立連接 后，拔掉網線：重新抓包如下圖所示：
今天的分享就到這里啦，EBYTE每一天都致力于更好的助力物聯(lián)化、智能化、自動化的發(fā)展，提升資源利用率，更多無線通信技術資料信息，感興趣的小伙伴可以登錄我們的億佰特官網進行了解，也可以直接撥打400電話咨詢技術專員！
相關閱讀：
1、無線模塊通過TCP/IP協(xié)議向PC端數(shù)據(jù)傳輸解析
2、基礎通信協(xié)議棧：TCP協(xié)議、IP協(xié)議詳解
3、UDP協(xié)議與TCP協(xié)議區(qū)別對比及應用場景方案
