1. HTTP長連接和短連接的定義

• HTTP長連接
• 瀏覽器向服務器進行一次HTTP會話訪問后，并不會直接關(guān)閉這個連接，而是會默認保持一段時間，那么下一次瀏覽器繼續(xù)訪問的時候就會再次利用到這個連接。
• 在HTTP/1.1版本中，默認的連接都是長連接，我們可以通過Connection: keep-alive字段進行指定。
• HTTP短連接
• 瀏覽器向服務器每進行一次HTTP操作都要建立一個新的連接。
• 在HTTP/1.0版本中默認是短鏈接

2.  HTTP長連接本質(zhì)

HTTP協(xié)議本質(zhì)是OSI七層參考模型中的應用層協(xié)議，而網(wǎng)絡進行通信的時候都是通過上層協(xié)議封裝頭部后作為下層協(xié)議的數(shù)據(jù)部分進行封裝的，而實際中我們經(jīng)常接觸的是TCP/IP協(xié)議簇，也就是傳輸層利用TCP協(xié)議和網(wǎng)絡層利用IP協(xié)議。因此HTTP協(xié)議的長連接本質(zhì)上就是TCP的長連接。

2.1 TCP建立連接回顧

上面我們提到了TCP，那么回顧一下，通信雙方在進行通信的時候就是要通過“三次握手“來建立連接的，握手的過程大致如圖1所示：

那么通過上圖我們就可以清楚的看到，服務器和客戶端都建立了一個TCB傳輸控制塊，這里就是我們進行socket編程的時候管理連接的地方，在這里我們先標記這個TCB,在后續(xù)的文章，我們會詳細介紹在Linux中TCB是怎么樣管理連接的。

2.2  TCP釋放連接回顧

在回顧了TCP連接建立之后，我們不妨再來看看TCP四次揮手，如圖2所示：

TCP連接的釋放是看通信雙方誰是主動關(guān)閉的一方，誰是被動關(guān)閉的一方來決定各自狀態(tài)的，具體的內(nèi)容大家依然可以參考《TCP/IP詳解》，這里就不再贅述了。

2.3 TCP長連接

在建立了TCP連接之后，這也就到了這篇文章中比較核心的問題，就是說TCP連接建立之后，并不會在完成一次數(shù)據(jù)通信后就關(guān)閉連接，而是要保持一段時間，那么這個時間是怎么樣保證，又是誰保證的呢？

2.3.1 TCP?；顧C制

• 為什么要有?；顧C制？
• 第一點自然是我們這篇文章的主題，通過保活機制，我們可以保證通訊雙方的連接不被釋放掉
• 第二點就是在另一些情況下，如果客戶端或者服務器發(fā)生了錯誤或者宕機，那么就可以依靠這種?；顧C制探測出網(wǎng)絡通信出現(xiàn)了問題，進而可以釋放掉這種錯誤連接。
• ?；顧C制

首先?；顧C制的工作原理就是，通過在服務器端設置一個保活定時器，當定時器開始工作后就定時的向網(wǎng)絡通信的另一端發(fā)出保活探測的TCP報文，如果接收到了ACK報文，那么就證明對方存活，可以繼續(xù)保有連接；否則就證明網(wǎng)絡存在故障。

上面只是在原理層面簡單的介紹，根據(jù)文獻[1]，我們可以了解到詳細的內(nèi)容：

如果一個給定的連接在兩個小時之內(nèi)沒有任何動作，則服務器就向客戶發(fā)送一個探查報文段?？蛻糁鳈C必須處于以下 4個狀態(tài)之一。

狀態(tài)1：客戶主機依然正常運行，并從服務器可達。客戶的TCP響應正常，而服務器也知道對方是正常工作的。服務器在兩小時以后將?；疃〞r器復位。如果在兩個小時定時器到時間之前有應用程序的通信量通過此連接，則定時器在交換數(shù)據(jù)后的未來2小時再復位。

狀態(tài)2：客戶主機已經(jīng)崩潰，并且關(guān)閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務器將不能夠收到對探查的響應，并在75秒后超時。服務器總共發(fā)送10個這樣的探查，每個間隔75秒。如果服務器沒有收到一個響應，它就認為客戶主機已經(jīng)關(guān)閉并終止連接。

狀態(tài)3：客戶主機崩潰并已經(jīng)重新啟動。這時服務器將收到一個對其?；钐讲榈捻憫?，但是這個響應是一個復位，使得服務器終止這個連接。

狀態(tài)4：客戶主機正常運行，但是從服務器不可達。這與狀態(tài)2相同，因為TCP不能夠區(qū)分狀態(tài)4與狀態(tài)2之間的區(qū)別，它所能發(fā)現(xiàn)的就是沒有收到探查的響應。

• 實際應用

那么我們在了解了理論上TCP長連接是通過?；顧C制來實現(xiàn)的，但是保活機制并不是RFC規(guī)定的TCP協(xié)議的內(nèi)容，因此有時候在不支持?；顧C制的機器上，往往我們也需要先看一下內(nèi)核層面是否支持，如果不支持需要在應用層自己去實現(xiàn)這個功能。

在這里我們就來看一下Linux相關(guān)的TCP?；顓?shù)

tcp_keepalive_time，單位：秒，表示發(fā)送的探測報文之前的連接空閑時間，默認是7200s。

tcp_keepalive_intvl，單位：秒，表示兩次探測報文之間的間隔時間，默認是75s

tcp_keepalive_probes，單位，秒，表示探測的次數(shù)，默認是9

接下來如果我們需要在應用層寫自己的心跳機制，那么就需要其他方面的一些內(nèi)容了。

2.3.2 TCP長連接和短鏈接比較

• TCP短鏈接
• 優(yōu)點
• 短鏈接不占服務器的內(nèi)存，服務器能處理的連接數(shù)量會比較多
• 缺點
• 在有實際的資源要進行數(shù)據(jù)通信的時候才建立連接，那么在客戶端發(fā)送完數(shù)據(jù)釋放連接之后當服務器有向客戶端發(fā)送數(shù)據(jù)時就不能做到發(fā)送消息的實時性。
• 頻繁地建立連接、釋放連接會耗費大量的CPU和網(wǎng)絡帶寬資源。
• TCP長連接[2]
• 優(yōu)點
• 通信雙方因為在?；顧C制的保證下可以保證數(shù)據(jù)收發(fā)的實時性
• 缺點
• 因為服務器需要一直保存和客戶端的這條鏈接，因為是有狀態(tài)的，那么在大量并發(fā)連接請求過來時，系統(tǒng)資源可能就不夠了。
• 什么時候需要長連接
• 服務器需要主動發(fā)送資源給客戶端時
• 客戶端和服務器通信很頻繁時
• 客戶端宕機或者掉線時需要服務器做一些處理時
• TCP長連接設計時需要考慮的問題
• 默認的keep-alive時間比較長，一般的業(yè)務可能不需要這么久的時間
• socket proxy會讓TCP的保活失效：多有的proxy應用只能轉(zhuǎn)發(fā)TCP的應用數(shù)據(jù)，不能轉(zhuǎn)發(fā)TCP協(xié)議內(nèi)部的包