TCP通信過程中的長連接與短連接是什么？

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

你應(yīng)該如何回答？你會嗎？

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

釋放需要四次握手：

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

tcp 連接

短連接

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

client 向 server 發(fā)起連接請求

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

client 向 server 發(fā)送消息

server 回應(yīng) client

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

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

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

短連接的操作步驟是：

建立連接——數(shù)據(jù)傳輸——關(guān)閉連接…建立連接——數(shù)據(jù)傳輸——關(guān)閉連接

優(yōu)缺點

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

應(yīng)用場景

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

TCP長連接

模擬一種長連接的情況:

client 向 server 發(fā)起連接

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

client 向 server 發(fā)送消息

server 回應(yīng) client

一次讀寫完成，連接不關(guān)閉

后續(xù)讀寫操作…

長時間操作之后client發(fā)起關(guān)閉請求

長連接的操作步驟是：

建立連接——數(shù)據(jù)傳輸…（保持連接）…數(shù)據(jù)傳輸——關(guān)閉連接

保持連接用到了TCP?；罟δ?/p>

優(yōu)缺點：

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

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

應(yīng)用場景：

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

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

對比

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

所以服務(wù)端要做到快速感知失敗，減少無效連接操作，這就有了TCP的Keepalive（?；钐綔y）機制。

長連接斷開的原因

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

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

長連接所在進程被殺死

NAT超時

網(wǎng)絡(luò)狀態(tài)發(fā)生變化

其他不可抗因素（網(wǎng)絡(luò)狀態(tài)差、DHCP的租期等等 ）

原因1：進程被殺死

當(dāng)進程被殺死后，長連接也會隨之?dāng)嚅_。

原因2：NAT 超時（重點關(guān)注）

NAT超時現(xiàn)象如下

各運營商 & 地區(qū)的 NAT超時時間如下

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

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

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

原因3：網(wǎng)絡(luò)狀態(tài)發(fā)生變化

當(dāng)移動客戶端網(wǎng)絡(luò)狀態(tài)發(fā)生變化時（如移動網(wǎng)絡(luò) & Wifi切換、斷開、重連），也會使長連接斷開。

原因4：其他不可抗因素

如網(wǎng)絡(luò)狀態(tài)差、DHCP的租期到期等等，都會使得長連接發(fā)生偶然的斷開。

DHCP的租期到期：對于Android系統(tǒng)，DHCP到了租期后不會主動續(xù)約 & 繼續(xù)使用過期IP,，從而導(dǎo)致長連接斷開。

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

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

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

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

?；睿禾幱谶B接狀態(tài)時盡量不要斷

斷線重連：斷了之后繼續(xù)重連回來

解決方案1：進程保活

解決方案2：心跳?；顧C制

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

心跳?；顧C制簡介

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

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

主流心跳機制分析 & 對比

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

心跳機制方案 總體設(shè)計

下面，將根據(jù)市面上主流的心跳機制，設(shè)計一套心跳機制方案。

基本流程

設(shè)計要點

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

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

心跳包的規(guī)格（內(nèi)容 & 大?。?/p>

心跳發(fā)送的間隔時間

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

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

心跳機制方案詳細設(shè)計

心跳包的規(guī)格

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

設(shè)計原則

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

設(shè)計方案

心跳包 = 1個攜帶少量信息 & 大小在10字節(jié)內(nèi)的信息包。

心跳發(fā)送的間隔時間

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

設(shè)計原則

設(shè)計方案

最直接 & 常用方案

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

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

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