當面試官問你：TCP 通信過程中的長連接與短連接是什么？

你應該如何回答？你會嗎？

當網絡通信采用tcp協議時，在真正的讀寫操作之前，sever與client之間必須建立一個連接，當讀寫操作完成之后，對方不再需要這個連接時他們可以釋放這個鏈接，連接的連接需要三次握手：

釋放需要四次握手：

也就是說每個連接的建立都是需要消耗資源和時間的。

tcp 連接

短連接

模擬一種TCP短連接的情況:

client 向 server 發起連接請求

server 接到請求，雙方建立連接

client 向 server 發送消息

server 回應 client

一次讀寫完成，此時雙方任何一個都可以發起 close 操作

一般都是 client 先發起 close 操作。當然也不排除有特殊的情況。

從上面的描述看，短連接一般只會在 client/server 間傳遞一次讀寫操作！

短連接的操作步驟是：

建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接

優缺點

短連接對于服務器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。

應用場景

而像WEB網站的http服務一般都用短鏈接，因為長連接對于服務端來說會耗費一定的資源，而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發量大，但每個用戶無需頻繁操作情況下需用短連好。

TCP長連接

模擬一種長連接的情況:

client 向 server 發起連接

server 接到請求，雙方建立連接

client 向 server 發送消息

server 回應 client

一次讀寫完成，連接不關閉

后續讀寫操作…

長時間操作之后client發起關閉請求

長連接的操作步驟是：

建立連接——數據傳輸…（保持連接）…數據傳輸——關閉連接

保持連接用到了TCP保活功能

優缺點：

長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對于頻繁請求資源的客戶來說，適合長連接

client與server之間的連接如果一直不關閉的話，會存在一個問題，隨著客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累后端服務。

應用場景：

長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多情況。每個TCP連接都需要三次握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，再次處理時直接發送數據包就OK了，不用建立TCP連接。

例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。

對比

短連接環境下，數據交互完畢后，會主動釋放連接；如果使用的是長連接的情況下，如果雙方已經建立起了連接，但是很長一段時間內沒有數據交換，而客戶端可能意外斷電、死機、崩潰、重啟，還是中間路由網絡無故斷開，這些TCP連接沒來得及正常釋放，那么，因為服務端不知道客戶端的情況，他就會一直維護這個連接，長時間的積累會導致非常多的半打開連接，造成服務端系統資源的消耗和浪費。

所以服務端要做到快速感知失敗，減少無效連接操作，這就有了TCP的Keepalive（保活探測）機制。

長連接斷開的原因

在長連接的情況下，雙方的所有通信 都建立在1條長連接上（1次TCP連接）；所以，長連接 需要 持續保持雙方連接 才可使得雙方持續通信。

可是，長連接會存在斷開的情況，而斷開原因主要是：

長連接所在進程被殺死

NAT超時

網絡狀態發生變化

其他不可抗因素（網絡狀態差、DHCP的租期等等 ）

原因1：進程被殺死

當進程被殺死后，長連接也會隨之斷開。

原因2：NAT 超時（重點關注）

NAT超時現象如下

各運營商 & 地區的 NAT超時時間如下

特別注意：排除其他外因（網絡切換、NAT超時、人為原因），TCP長連接在雙方都不斷開連接的情況上，本質上是不會自動中斷的

即，不需要心跳包來維持。

驗證：讓2臺電腦連上同1個Wifi（其中1臺做服務器, 另1臺做客戶端連接服務器（無設置KeepAlive）；只要電腦、路由器不斷網斷電，那么，2臺電腦的長連接是不會自動中斷的。

原因3：網絡狀態發生變化

當移動客戶端網絡狀態發生變化時（如移動網絡 & Wifi切換、斷開、重連），也會使長連接斷開。

原因4：其他不可抗因素

如網絡狀態差、DHCP的租期到期等等，都會使得長連接發生偶然的斷開。

DHCP的租期到期：對于Android系統，DHCP到了租期后不會主動續約 & 繼續使用過期IP,，從而導致長連接斷開。

高效維持長連接的解決方案

在了解長連接斷開原因后，針對對應原因，此處給出 高效維持長連接的解決方案。

為此，若需有效維持長連接，則需要做到。

其實，說得簡單點：高效維持長連接的關鍵在于。

保活：處于連接狀態時盡量不要斷

斷線重連：斷了之后繼續重連回來

解決方案1：進程保活

解決方案2：心跳保活機制

解決方案3：斷線重連機制

心跳保活機制簡介

心跳保活機制的整體介紹如下

注：很多人容易混淆心跳機制 & 輪詢機制，此處給出二者區別。

主流心跳機制分析 & 對比

對國、內外主流的移動IM產品（WhatsApp、Line、微信）進行了心跳機制的簡單分析 & 對比，具體請看下圖 。

心跳機制方案 總體設計

下面，將根據市面上主流的心跳機制，設計一套心跳機制方案。

基本流程

設計要點

對于心跳機制方案設計的主要考慮因素 = 保證消息的實時性 & 耗費設備的資源（網絡流量、電量、CPU等等）

從上圖可以看出，對于心跳機制方案設計的要點在于

心跳包的規格（內容 & 大小）

心跳發送的間隔時間

斷線重連機制 （核心 = 如何 判斷長連接的有效性）

在下面的方案設計中，將針對這3個問題給出詳細的解決方案。

心跳機制方案詳細設計

心跳包的規格

為了減少流量 & 提高發送效率，需要精簡心跳包的設計。

設計原則

主要從心跳包的內容 & 大小入手，設計原則具體如下：

設計方案

心跳包 = 1個攜帶少量信息 & 大小在10字節內的信息包。

心跳發送的間隔時間

為了防止NAT超時 & 減少設備資源的消耗（網絡流量、電量、CPU等等），心跳發送的間隔時間是整個心跳機制方案設計的重點。

設計原則

設計方案

最直接 & 常用方案

一般，最直接 & 常用的心跳發送間隔時間設置方案 ：每隔估計 x 分鐘發送心跳包1次。

其中，x ＜5分鐘即可。（綜合主流移動IM產品，此處建議 x= 4分鐘）。

但是，這種方案存在一些問題：