TCP在真正開始進行數(shù)據(jù)傳輸之前，Server 和 Client 之間必須建立一個連接。當數(shù)據(jù)傳輸完成后，雙方不再需要這個連接時，就可以釋放這個連接。

TCP連接的建立是通過三次握手，而連接的釋放是通過四次揮手。所以說，每個TCP連接的建立和釋放都是需要消耗資源和時間成本的。

二 TCP短連接

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

1. client 向 server 發(fā)起連接請求
2. server 收到連接請求，雙方建立TCP連接
3. client 向 server 發(fā)送消息
4. server 回應 client 消息
5. 一次讀寫完成，此時雙方任何一方都可以發(fā)起關閉連接請求，即close操作。

在步驟5中，一般都是 client 先發(fā)起close操作。從上面的描述來看，短連接一般只會在 client 和 server 之間傳遞一次讀寫操作。

短連接的操作過程：建立連接 ——> 傳輸數(shù)據(jù) ——> 關閉連接。

三 TCP長連接

模擬一種長連接的情況：

1. client 向 server 發(fā)起連接請求
2. server 收到連接請求，雙方建立TCP連接
3. client 向 server 發(fā)送消息
4. server 回應 client 消息
5. 一次讀寫完成，TCP連接不關閉
6. 后續(xù)讀寫操作...
7. 長時間操作之后，client 發(fā)起關閉連接請求

TCP長連接是指在連接成功建立之后，即使通信雙方?jīng)]有數(shù)據(jù)傳輸也要保持連接，使其不斷開。

長連接的操作步驟：建立連接 ——> 傳輸數(shù)據(jù) ——> ... (保持連接) ... ——> 傳輸數(shù)據(jù) ——> 關閉連接

四 長連接和短連接的優(yōu)缺點

4.1 短連接的優(yōu)缺點

優(yōu)點：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。

缺點：由于TCP的建立和關閉操作需要一定的系統(tǒng)開銷，如果客戶端連接請求頻繁，會降低服務器的處理速度、浪費系統(tǒng)資源和帶寬。

4.2 長連接的優(yōu)缺點

優(yōu)點：長連接可以省去較多的TCP連接的建立和關閉的操作，減少浪費，節(jié)約時間。

缺點：client 與 server 之間的連接如果一直不關閉的話，會存在一個問題，隨著客戶端的連接越來越多，服務器的負載壓力會增大，降低服務器的整體性能，更嚴重者，可能導致服務器崩潰；其次，如果大量處于連接狀態(tài)的TCP通信雙方長時間沒有進行數(shù)據(jù)傳輸，這也會浪費系統(tǒng)和網(wǎng)絡資源。

五 長連接/短連接的應用場景

• 長連接一般多用于需要頻繁進行讀寫操作，點對點通訊，而且連接數(shù)不太多的情況。

例如：數(shù)據(jù)庫的連接通常使用長連接，如果用短連接的話，頻繁的TCP socket創(chuàng)建和關閉，會造成socket錯誤，也是對資源的一種浪費。

• 短連接一般用于不需要頻繁進行讀寫操作，并且連接數(shù)很大的情況下。

例如：web網(wǎng)站的http服務一般都用短連接。因為長連接對于服務器來說是要耗費一定的系統(tǒng)資源的，像web網(wǎng)站服務，通常會有大量的客戶端連接請求，并發(fā)連接量大，使用短連接會更節(jié)省系統(tǒng)資源，能夠及時響應客戶請求。

總結：長連接和短連接的選擇要具體需求、實際情況而定。

六 長連接的?；顧C制

對于TCP長連接，當通信雙方在沒有數(shù)據(jù)傳輸?shù)臅r候，如何保持TCP連接一直處于“?；?KeepAlive)”狀態(tài)，這是一個必須要解決的問題。

在Linux系統(tǒng)中，我們可以使用 netstat、lsof等命令可以查看TCP連接是否處于“ESTABLISHED”狀態(tài)。

6.1 TCP?；畹谋匾?/h1>

（1）很多防火墻會主動關閉空閑的socket。

（2）可能出現(xiàn)的非正常斷連，服務器并不能檢測到，為了回收已斷連的socket資源，必須提供一種檢測機制。

導致TCP非正常斷連的可能原因：
（1）網(wǎng)絡故障
（2）客戶端/服務端一側突然斷電或者進程崩潰

6.2 ?；顧C制的方式

6.2.1 應用層的心跳機制

在應用層中使用心跳(heartbeat)機制來主動檢測。具體做法：當TCP連接建立成功后，客戶端開啟一個定時任務，定時對已經(jīng)建立連接的對端發(fā)送一個心跳請求消息，服務器收到該心跳消息后，返回一個心跳應答消息。如果在超時時間內(nèi)沒有收到服務器的應答消息，則重發(fā)心跳請求消息，如果客戶端持續(xù)多次沒有響應，客戶端則可以認為該TCP連接不可用，主動斷開連接。當然，也可以是服務器端主動發(fā)送心跳請求消息給客戶端。

6.2.2 TCP協(xié)議自帶的?；顧C制

Linux內(nèi)核自帶的保活機制keep-alive。使用的時候只需要打開keep-alive功能即可。

TCP的Keepalive機制的作用是在于探測連接的對端是否存活。

工作原理：TCP keep-alive是通過在空閑時發(fā)送TCP Keep-Alive數(shù)據(jù)包，然后對方回應TCP Keep-Alive ACK來實現(xiàn)的。

在socket網(wǎng)絡編程中，需要設置一個socket選項 SO_KEEPALIVE，才能開啟keepalive機制。代碼描述如下：

keepAlive = 1;

setsockopt(listen_fd, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive));

在Linux的keepalive機制中，有3個重要的內(nèi)核參數(shù)：tcp_keepalive_time、tcp_keepalive_probes 和 tcp_keepalive_intvl。

• tcp_keepalive_time：表示TCP連接閑置多長時間后開始發(fā)送探測報文。（單位：秒）
• tcp_keepalive_probes：表示一次探測過程中最多可以重發(fā)探測報文的次數(shù)。（沒有收到確認時重發(fā)次數(shù)）
• tcp_keepalive_intvl：表示前一個探測報文和后一個探測報文之間的時間間隔。（即超時重傳的時間間隔）（單位：秒）

這些內(nèi)核參數(shù)可以在/proc/sys/net/ipv4/目錄下可以看到，也可以使用Linux命令查看其默認值：

# sysctl -a |grep keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200

可以看到，這3個內(nèi)核參數(shù)的默認值分別為：

tcp_keepalive_time = 7200秒，即2小時。也就是說，從最后一次數(shù)據(jù)傳輸結束開始計時起到發(fā)送第一個保活探測報文的時間間隔為2小時。

tcp_keepalive_probes = 9。當沒有收到對方的確認時，繼續(xù)發(fā)送?；钐綔y報文的默認次數(shù)為9次。

tcp_keepalive_intvl = 75秒。當沒有收到對方的確認時，繼續(xù)發(fā)送?；钐綔y報文的間隔時間為75秒。

TCP連接探活的過程：

開啟 keepalive后，如果2小時內(nèi)在此TCP連接的通信雙方?jīng)]有發(fā)生數(shù)據(jù)交換，TCPT就自動給對方發(fā)一個?；钐綔y報文段(keepalive probe)。這是一個對方必須響應的TCP報文段。

它會導致以下三種情況：

• 對方成功接收，連接正常：以期望的ACK報文段響應。2小時后，TCP將發(fā)出另一個探測報文。
• 對方已崩潰且已重新啟動：已RST報文段響應。socket的待處理錯誤被置為ECONNRESET，socket本身則被關閉，斷開TCP連接。
• 對方無任何響應：發(fā)送保活探測報文的一方，相隔75秒后，再次重發(fā)保活探測報文，重發(fā)8次，一共嘗試9次。若仍無響應就放棄。socket的待處理錯誤被置為ETIMEOUT，socket本身則被關閉，斷開TCP連接。

設置TCP keepalive

上面提到的 TCP keepalive使用的是其默認值。如果我們不想使用這么長的等待時間，可以修改Linux內(nèi)核關于網(wǎng)絡方面的配置參數(shù)。我們可以自定義那3個內(nèi)核參數(shù)的值，有兩種修改方式：

（1）全局設置（操作系統(tǒng)層面）

（2）針對單個TCP連接設置（應用程序層面）

1、全局設置

在Linux系統(tǒng)中，我們可以通過修改 /etc/sysctl.conf 配置文件的全局配置：

net.ipv4.tcp_keepalive_time=300 
net.ipv4.tcp_keepalive_intvl=30  
net.ipv4.tcp_keepalive_probes=5

添加上面的配置后，輸入：sysctl -p 使其生效。

這種方法設置的全局內(nèi)核參數(shù)，針對整個操作系統(tǒng)生效，對單個socket的設置不夠友好。

2、針對單個TCP連接的設置

我們可以在socket網(wǎng)絡編程中設置TCP的 TCP_KEEPCNT、TCP_KEEPIDLE、TCP_KEEPINTVL 這3個socket選項。

這三個選項的定義，可以通過man 命令查看。

man 7 tcp

TCP_KEEPCNT (since Linux 2.4)
The maximum number of keepalive probes TCP should send before dropping the connection. This option should not be
used in code intended to be portable.
關閉一個非活躍連接之前的最大重試次數(shù)。 該選項不具備可移植性。
TCP_KEEPIDLE (since Linux 2.4)
The time (in seconds) the connection needs to remain idle before TCP starts sending keepalive probes, if the
socket option SO_KEEPALIVE has been set on this socket. This option should not be used in code intended to be
portable.
設置連接上如果沒有數(shù)據(jù)發(fā)送的話，多久后發(fā)送keepalive探測報文，單位是秒。該選項不具備可移植性。
TCP_KEEPINTVL (since Linux 2.4)
The time (in seconds) between individual keepalive probes. This option should not be used in code intended to be
portable.
前后兩次探測報文之間的時間間隔，單位是秒。該選項不具備可移植性。

代碼層面的設置步驟如下：

int keepAlive = 1;    // 非0值，開啟keepalive屬性

int keepIdle = 60;    // 如該連接在60秒內(nèi)沒有任何數(shù)據(jù)往來,則進行此TCP層的探測

int keepInterval = 5; // 探測發(fā)包間隔為5秒

int keepCount = 3;    // 嘗試探測的最多次數(shù)

//開啟tcp-keepAlive探活機制
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive));

setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, &keepIdle, sizeof(keepIdle));

setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, &keepInterval, sizeof(keepInterval));

setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, &keepCount, sizeof(keepCount);

6.2.3 TCP Keepalive 常見異常

啟用TCP Keepalive 的應用程序，一般可以捕獲到下面幾種類型的錯誤：

• ETIMEOUT 超時錯誤

在發(fā)送一個探測報文段后經(jīng)過(tcpkeepaliveTime + tcpkeepaliveIntvl * tcpkeepaliveProbes)時間后仍然沒有接收到ACK確認報文段的情況下觸發(fā)的異常，套接字被關閉：Connection timedout。

• EHOSTUNREACH 主機不可達錯誤

這個是網(wǎng)絡層的ICMP匯報給上層應用的異常錯誤：No route to host。

6.2.4 TCP Keepalive 和 應用層 heartbeat 優(yōu)缺點

1、TCP協(xié)議的 Keepalive 機制

優(yōu)點：TCP協(xié)議的Keepalive機制由系統(tǒng)內(nèi)核實現(xiàn)，上層應用程序只需要處理數(shù)據(jù)的收發(fā)，連接異常通知即可，這就減少了應用層代碼的復雜度，內(nèi)核層面的計時器相比應用層，更為高效。

缺點：第一，TCP keepalive機制，位于傳輸層，由操作系統(tǒng)負責，只能檢測到連接是否存活，但不能檢測檢測連接是否可用。例如，服務器因為某種原因導致負載超高，CPU使用率達到了100%，無法繼續(xù)響應任何業(yè)務請求，但是TCP探針卻仍能確定連接狀態(tài)，這就是典型的連接活著但是服務已死的狀態(tài)。對于客戶端而言，這時最好的選擇就是斷開連接重新連接到其他服務器上，而不是一直認為當前服務器仍處于可用狀態(tài)，一直向當前服務器發(fā)送那些必然會失敗的請求。

第二，TCP keepalive機制 對于連接異常斷開的情況不能及時有效地監(jiān)測到。如果TCP連接的某一方突然異常斷開連接，這個時候發(fā)送方并不知道對端已經(jīng)掉線。而此時，如果有數(shù)據(jù)發(fā)送失敗，tcp會自動進行超時重傳，而重傳報文段的優(yōu)先級是要高于keepalive的探測報文段的，導致探測報文段總是不能發(fā)送出去，直到經(jīng)過較長時間的重傳之后，我們才會知道。

2、應用層的HeartBeat 機制

優(yōu)點：第一，具有更好的靈活可控性。可以控制心跳的監(jiān)測時機、間隔和流程，甚至可以在心跳包上附帶額外信息，最重要的是不光可以檢測連接是否存在，還可以檢測到連接是否可用，而TCP的keepalive機制只能提供簡單的檢活功能。

第二，具有通用性。應用層的心跳不依賴傳輸層協(xié)議，如果有一天不用TCP要改用UDP了，傳輸層不提供心跳機制了，但是你應用層的心跳機制依然可以使用，只需做少許改動就可以繼續(xù)使用。

缺點：第一，需要開發(fā)人員自己實現(xiàn)，增加軟件開發(fā)的工作量，由于應用特定的網(wǎng)絡框架，還可能增加代碼結構的復雜度。

第二，應用層心跳的流量消耗會更大，畢竟這本質上還是一個普通的數(shù)據(jù)包。