1、HTTP 協(xié)議與 TCP/IP 協(xié)議的關(guān)系

HTTP 的長(zhǎng)連接和短連接本質(zhì)上是 TCP 長(zhǎng)連接和短連接。HTTP 屬于應(yīng)用層協(xié)議，在傳輸層使用 TCP 協(xié)議，在網(wǎng)絡(luò)層使用 IP 協(xié)議。IP 協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問(wèn)題，TCP 協(xié)議主要解決如何在 IP 層之上可靠的傳遞數(shù)據(jù)包，使在網(wǎng)絡(luò)上的另一端收到發(fā)端發(fā)出的所有包，并且順序與發(fā)出順序一致。TCP 有可靠，面向連接的特點(diǎn)。

2、如何理解HTTP協(xié)議是無(wú)狀態(tài)的

HTTP 協(xié)議是無(wú)狀態(tài)的，指的是協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。也就是說(shuō)，打開(kāi)一個(gè)服務(wù)器上的網(wǎng)頁(yè)和你之前打開(kāi)這個(gè)服務(wù)器上的網(wǎng)頁(yè)之間沒(méi)有任何聯(lián)系。HTTP 是一個(gè)無(wú)狀態(tài)的面向連接的協(xié)議，無(wú)狀態(tài)不代表 HTTP 不能保持 TCP 連接，更不能代表 HTTP 使用的是 UDP 協(xié)議（無(wú)連接）。

3、什么是長(zhǎng)連接、短連接？

短連接

連接->傳輸數(shù)據(jù)->關(guān)閉連接

HTTP是無(wú)狀態(tài)的，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。

也可以這樣說(shuō)：短連接是指Socket連接后發(fā)送后接收完數(shù)據(jù)后馬上斷開(kāi)連接。

長(zhǎng)連接

連接->傳輸數(shù)據(jù)->保持連接 -> 傳輸數(shù)據(jù)-> 。。。->關(guān)閉連接。

長(zhǎng)連接指建立Socket連接后不管是否使用都保持連接。

在 HTTP/1.0 中，默認(rèn)使用的是短連接。也就是說(shuō)，瀏覽器和服務(wù)器每進(jìn)行一次 HTTP 操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。如果客戶端瀏覽器訪問(wèn)的某個(gè) HTML 或其他類型的 Web 頁(yè)中包含有其他的 Web 資源，如JavaScript 文件、圖像文件、CSS 文件等；當(dāng)瀏覽器每遇到這樣一個(gè) Web 資源，就會(huì)建立一個(gè) HTTP 會(huì)話。

但從 HTTP/1.1 起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。使用長(zhǎng)連接的 HTTP 協(xié)議，會(huì)在響應(yīng)頭有加入這行代碼：

Connection:keep-alive

在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后，客戶端和服務(wù)器之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會(huì)關(guān)閉，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive 不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如 Apache ）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接要客戶端和服務(wù)端都支持長(zhǎng)連接。

HTTP 協(xié)議的長(zhǎng)連接和短連接，實(shí)質(zhì)上是 TCP 協(xié)議的長(zhǎng)連接和短連接。

3.1 TCP 連接

當(dāng)網(wǎng)絡(luò)通信時(shí)采用 TCP 協(xié)議時(shí)，在真正的讀寫(xiě)操作之前，server 與 client 之間必須建立一個(gè)連接，當(dāng)讀寫(xiě)操作完成后，雙方不再需要這個(gè)連接 時(shí)它們可以釋放這個(gè)連接，連接的建立是需要 3 次握手的，而釋放則需要 4 次握手，所以說(shuō)每個(gè)連接的建立都是需要資源消耗和時(shí)間消耗的。

經(jīng)典的三次握手示意圖：

經(jīng)典的四次握手關(guān)閉圖：

3.2 TCP短連接

我們模擬一下 TCP 短連接的情況，client 向 server 發(fā)起連接請(qǐng)求，server 接到請(qǐng)求，然后雙方建立連接。client 向 server 發(fā)送消息，server 回應(yīng)client，然后一次讀寫(xiě)就完成了，這時(shí)候雙方任何一個(gè)都可以發(fā)起 close 操作，不過(guò)一般都是 client 先發(fā)起 close 操作。為什么呢，一般的 server 不會(huì)回復(fù)完 client 后立即關(guān)閉連接的，當(dāng)然不排除有特殊的情況。從上面的描述看，短連接一般只會(huì)在 client/server 間傳遞一次讀寫(xiě)操作

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

3.3 TCP 長(zhǎng)連接

接下來(lái)我們?cè)倌M一下長(zhǎng)連接的情況，client 向 server 發(fā)起連接，server 接受 client 連接，雙方建立連接。Client 與 server 完成一次讀寫(xiě)之后，它們之間的連接并不會(huì)主動(dòng)關(guān)閉，后續(xù)的讀寫(xiě)操作會(huì)繼續(xù)使用這個(gè)連接。

首先說(shuō)一下 TCP/IP 詳解上講到的 TCP ?；罟δ?，?；罟δ苤饕獮榉?wù)器應(yīng)用提供，服務(wù)器應(yīng)用希望知道客戶主機(jī)是否崩潰，從而可以代表客戶使用資源。如果客戶已經(jīng)消失，使得服務(wù)器上保留一個(gè)半開(kāi)放的連接，而服務(wù)器又在等待來(lái)自客戶端的數(shù)據(jù)，則服務(wù)器將應(yīng)遠(yuǎn)等待客戶端的數(shù)據(jù)，保活功能就是試圖在服務(wù) 器端檢測(cè)到這種半開(kāi)放的連接。

如果一個(gè)給定的連接在兩小時(shí)內(nèi)沒(méi)有任何的動(dòng)作，則服務(wù)器就向客戶發(fā)一個(gè)探測(cè)報(bào)文段，客戶主機(jī)必須處于以下 4 個(gè)狀態(tài)之一：

• 客戶主機(jī)依然正常運(yùn)行，并從服務(wù)器可達(dá)?？蛻舻腡CP響應(yīng)正常，而服務(wù)器也知道對(duì)方是正常的，服務(wù)器在兩小時(shí)后將?；?a href="http://m.xsypw.cn/tags/定時(shí)器/" target="_blank">定時(shí)器復(fù)位。
• 客戶主機(jī)已經(jīng)崩潰，并且關(guān)閉或者正在重新啟動(dòng)。在任何一種情況下，客戶的 TCP 都沒(méi)有響應(yīng)。服務(wù)端將不能收到對(duì)探測(cè)的響應(yīng)，并在75秒后超時(shí)。服務(wù)器總共發(fā)送 10 個(gè)這樣的探測(cè) ，每個(gè)間隔 75 秒。如果服務(wù)器沒(méi)有收到一個(gè)響應(yīng)，它就認(rèn)為客戶主機(jī)已經(jīng)關(guān)閉并終止連接。
• 客戶主機(jī)崩潰并已經(jīng)重新啟動(dòng)。服務(wù)器將收到一個(gè)對(duì)其?；钐綔y(cè)的響應(yīng)，這個(gè)響應(yīng)是一個(gè)復(fù)位，使得服務(wù)器終止這個(gè)連接。
• 客戶機(jī)正常運(yùn)行，但是服務(wù)器不可達(dá)，這種情況與 2 類似，TCP 能發(fā)現(xiàn)的就是沒(méi)有收到探查的響應(yīng)。

3.4 長(zhǎng)連接短連接操作過(guò)程

短連接的操作步驟是：

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

長(zhǎng)連接的操作步驟是：

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

4、長(zhǎng)連接和短連接的優(yōu)點(diǎn)和缺點(diǎn)

由上可以看出，長(zhǎng)連接可以省去較多的 TCP 建立和關(guān)閉的操作，減少浪費(fèi)，節(jié)約時(shí)間。對(duì)于頻繁請(qǐng)求資源的客戶來(lái)說(shuō)，較適用長(zhǎng)連接。

不過(guò)這里存在一個(gè)問(wèn)題，存活功能的探測(cè)周期太長(zhǎng)，還有就是它只是探測(cè) TCP 連接的存活，屬于比較斯文的做法，遇到惡意的連接時(shí)，保活功能就不夠使了。

在長(zhǎng)連接的應(yīng)用場(chǎng)景下，client 端一般不會(huì)主動(dòng)關(guān)閉它們之間的連接，client 與 server 之間的連接如果一直不關(guān)閉的話，會(huì)存在一個(gè)問(wèn)題，隨著客戶端連接越來(lái)越多，server 早晚有扛不住的時(shí)候，這時(shí)候 server 端需要采取一些策略，如關(guān)閉一些長(zhǎng)時(shí)間沒(méi)有讀寫(xiě)事件發(fā)生的連接，這樣可 以避免一些惡意連接導(dǎo)致server 端服務(wù)受損；如果條件再允許就可以以客戶端機(jī)器為顆粒度，限制每個(gè)客戶端的最大長(zhǎng)連接數(shù)，這樣可以完全避免某個(gè)蛋疼的客戶端連累后端服務(wù)。

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

長(zhǎng)連接和短連接的產(chǎn)生在于 client 和 server 采取的關(guān)閉策略，具體的應(yīng)用場(chǎng)景采用具體的策略，沒(méi)有十全十美的選擇，只有合適的選擇。

5、什么時(shí)候用長(zhǎng)連接，短連接？

長(zhǎng)連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多情況。每個(gè) TCP 連接都需要三步握手，這需要時(shí)間，如果每個(gè)操作都是先連接，再操作的話那么處理速度會(huì)降低很多，所以每個(gè)操作完后都不斷開(kāi)，次處理時(shí)直接發(fā)送數(shù)據(jù)包就 OK 了，不用建立 TCP 連接。例如：數(shù)據(jù)庫(kù)的連接用長(zhǎng)連接， 如果用短連接頻繁的通信會(huì)造成 socket 錯(cuò)誤，而且頻繁的 socket 創(chuàng)建也是對(duì)資源的浪費(fèi)。

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

6、長(zhǎng)連接和短連接的生命周期有多久？

短連接在建立連接后，完成一次讀寫(xiě)就會(huì)自動(dòng)關(guān)閉了。

正常情況下，一條TCP長(zhǎng)連接建立后，只要雙不提出關(guān)閉請(qǐng)求并且不出現(xiàn)異常情況，這條連接是一直存在的，操作系統(tǒng)不會(huì)自動(dòng)去關(guān)閉它，甚至經(jīng)過(guò)物理網(wǎng)絡(luò)拓?fù)涞母淖冎笕匀豢梢允褂谩Ｋ砸粭l連接保持幾天、幾個(gè)月、幾年或者更長(zhǎng)時(shí)間都有可能，只要不出現(xiàn)異常情況或由用戶（應(yīng)用層）主動(dòng)關(guān)閉。

在編程中，往往需要建立一條TCP連接，并且長(zhǎng)時(shí)間處于連接狀態(tài)。所謂的TCP長(zhǎng)連接并沒(méi)有確切的時(shí)間限制，而是說(shuō)這條連接需要的時(shí)間比較長(zhǎng)。

7、怎樣檢測(cè)長(zhǎng)連接是否中斷？

1、在應(yīng)用層使用heartbeat來(lái)主動(dòng)檢測(cè)

對(duì)于實(shí)時(shí)性要求較高的網(wǎng)絡(luò)通信程序，往往需要更加及時(shí)的獲取已經(jīng)中斷的連接，從而進(jìn)行及時(shí)的處理。但如果對(duì)方的連接異常中斷，往往是不能及時(shí)的得到對(duì)方連接已經(jīng)中斷的信息，操作系統(tǒng)檢測(cè)連接是否中斷的時(shí)間間隔默認(rèn)是比較長(zhǎng)的，即便它能夠檢測(cè)到，但卻不符合我們的實(shí)時(shí)性需求，所以需要我們進(jìn)行手工去不斷探測(cè)。

2、改變socket的keepalive選項(xiàng)，以使socket檢測(cè)連接是否中斷的時(shí)間間隔更小，以滿足我們的及時(shí)性需求。有關(guān)的幾個(gè)選項(xiàng)使用和解析如下：

A、我們?cè)跈z測(cè)對(duì)端以一種非優(yōu)雅的方式斷開(kāi)連接的時(shí)候，可以設(shè)置SO_KEEPALIVE屬性使得我們?cè)?小時(shí)以后發(fā)現(xiàn)對(duì)方的TCP連接是否依然存在。用法如下：

keepAlive = 1；
setsockopt(listenfd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(keepAlive));

B、如果我們不想使用這么長(zhǎng)的等待時(shí)間，可以修改內(nèi)核關(guān)于網(wǎng)絡(luò)方面的配置參數(shù)，也可設(shè)置SOCKET的TCP層（SOL_TCP）選項(xiàng)TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT。

• TCP_KEEPIDLE：開(kāi)始首次KeepAlive探測(cè)前的TCP空閉時(shí)間（默認(rèn)2h）
• TCP_KEEPINTVL：兩次KeepAlive探測(cè)間的時(shí)間間隔（默認(rèn)75s）
• TCP_KEEPCNT：斷開(kāi)前的KeepAlive探測(cè)次數(shù)

如果心跳函數(shù)要維護(hù)客戶端的存活，即服務(wù)器必須每隔一段時(shí)間必須向客戶段發(fā)送一定的數(shù)據(jù)，那么使用SO_KEEPALIVE是有很大的不足的。因?yàn)镾O_KEEPALIVE選項(xiàng)指"此套接口的任一方向都沒(méi)有數(shù)據(jù)交換"。在Linux 2.6系列上，上面話的理解是只要打開(kāi)SO_KEEPALIVE選項(xiàng)的套接口端檢測(cè)到數(shù)據(jù)發(fā)送或者數(shù)據(jù)接受就認(rèn)為是數(shù)據(jù)交換。因此在這種情況下使用 SO_KEEPALIVE選項(xiàng) 檢測(cè)對(duì)方是否非正常連接是完全沒(méi)有作用的，在每隔一段時(shí)間發(fā)包的情況， keep-alive的包是不可能被發(fā)送的。上層程序在非正常斷開(kāi)的情況下是可以正常發(fā)送包到緩沖區(qū)的。非正常端開(kāi)的情況是指服務(wù)器沒(méi)有收到"FIN" 或者 "RST"包。