一、什么是長(zhǎng)連接

? ? ?HTTP1.1規(guī)定了默認(rèn)保持長(zhǎng)連接（HTTP persistent connection ，也有翻譯為持久連接），數(shù)據(jù)傳輸完成了保持TCP連接不斷開(kāi)（不發(fā)RST包、不四次握手），等待在同域名下繼續(xù)用這個(gè)通道傳輸數(shù)據(jù)；相反的就是短連接。

　HTTP首部的Connection: Keep-alive是HTTP1.0瀏覽器和服務(wù)器的實(shí)驗(yàn)性擴(kuò)展，當(dāng)前的HTTP1.1 RFC2616文檔沒(méi)有對(duì)它做說(shuō)明，因?yàn)樗枰墓δ芤呀?jīng)默認(rèn)開(kāi)啟，無(wú)須帶著它，但是實(shí)踐中可以發(fā)現(xiàn)，瀏覽器的報(bào)文請(qǐng)求都會(huì)帶上它。如果HTTP1.1版本的HTTP請(qǐng)求報(bào)文不希望使用長(zhǎng)連接，則要在HTTP請(qǐng)求報(bào)文首部加上Connection: close?！禜TTP權(quán)威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而導(dǎo)致長(zhǎng)連接失效：客戶端-->代理-->服務(wù)端，客戶端帶有Keep-alive，而代理不認(rèn)識(shí)，于是將報(bào)文原封不動(dòng)轉(zhuǎn)給了服務(wù)端，服務(wù)端響應(yīng)了Keep-alive，也被代理轉(zhuǎn)發(fā)給了客戶端，于是保持了“客戶端-->代理”連接和“代理-->服務(wù)端”連接不關(guān)閉，但是，當(dāng)客戶端第發(fā)送第二次請(qǐng)求時(shí)，代理會(huì)認(rèn)為當(dāng)前連接不會(huì)有請(qǐng)求了，于是忽略了它，長(zhǎng)連接失效。書(shū)上也介紹了解決方案：當(dāng)發(fā)現(xiàn)HTTP版本為1.0時(shí)，就忽略Keep-alive，客戶端就知道當(dāng)前不該使用長(zhǎng)連接。其實(shí)，在實(shí)際使用中不需要考慮這么多，很多時(shí)候代理是我們自己控制的，如Nginx代理，代理服務(wù)器有長(zhǎng)連接處理邏輯，服務(wù)端無(wú)需做patch處理，常見(jiàn)的是客戶端跟Nginx代理服務(wù)器使用HTTP1.1協(xié)議&長(zhǎng)連接，而Nginx代理服務(wù)器跟后端服務(wù)器使用HTTP1.0協(xié)議&短連接。

? ? 在實(shí)際使用中，HTTP頭部有了Keep-Alive這個(gè)值并不代表一定會(huì)使用長(zhǎng)連接，客戶端和服務(wù)器端都可以無(wú)視這個(gè)值，也就是不按標(biāo)準(zhǔn)來(lái)，譬如我自己寫(xiě)的HTTP客戶端多線程去下載文件，就可以不遵循這個(gè)標(biāo)準(zhǔn)，并發(fā)的或者連續(xù)的多次GET請(qǐng)求，都分開(kāi)在多個(gè)TCP通道中，每一條TCP通道，只有一次GET，GET完之后，立即有TCP關(guān)閉的四次握手，這樣寫(xiě)代碼更簡(jiǎn)單，這時(shí)候雖然HTTP頭有Connection: Keep-alive，但不能說(shuō)是長(zhǎng)連接。正常情況下客戶端瀏覽器、web服務(wù)端都有實(shí)現(xiàn)這個(gè)標(biāo)準(zhǔn)，因?yàn)樗鼈兊奈募中∮侄?#xff0c;保持長(zhǎng)連接減少重新開(kāi)TCP連接的開(kāi)銷(xiāo)很有價(jià)值。

? ? ?以前使用libcurl做的上傳/下載，就是短連接，抓包可以看到：1、每一條TCP通道只有一個(gè)POST；2、在數(shù)據(jù)傳輸完畢可以看到四次握手包。只要不調(diào)用curl_easy_cleanup，curl的handle就可能一直有效，可復(fù)用。這里說(shuō)可能，因?yàn)檫B接是雙方的，如果服務(wù)器那邊關(guān)掉了，那么我客戶端這邊保留著也不能實(shí)現(xiàn)長(zhǎng)連接。 ? ? ? ? 如果是使用windows的WinHTTP庫(kù)，則在POST/GET數(shù)據(jù)的時(shí)候，雖然我關(guān)閉了句柄，但這時(shí)候TCP連接并不會(huì)立即關(guān)閉，而是等一小會(huì)兒，這時(shí)候是WinHTTP庫(kù)底層支持了跟Keep-alive所需要的功能：即便沒(méi)有Keep-alive，WinHTTP庫(kù)也可能會(huì)加上這種TCP通道復(fù)用的功能，而其它的網(wǎng)絡(luò)庫(kù)像libcurl則不會(huì)這么做。以前觀察過(guò)WinHTTP庫(kù)不會(huì)及時(shí)斷開(kāi)TCP連接。

二、長(zhǎng)連接的過(guò)期時(shí)間

? ? 客戶端的長(zhǎng)連接不可能無(wú)限期的拿著，會(huì)有一個(gè)超時(shí)時(shí)間，服務(wù)器有時(shí)候會(huì)告訴客戶端超時(shí)時(shí)間，譬如： ? ? ?上圖中的Keep-Alive: timeout=20，表示這個(gè)TCP通道可以保持20秒。另外還可能有max=XXX，表示這個(gè)長(zhǎng)連接最多接收XXX次請(qǐng)求就斷開(kāi)。對(duì)于客戶端來(lái)說(shuō)，如果服務(wù)器沒(méi)有告訴客戶端超時(shí)時(shí)間也沒(méi)關(guān)系，服務(wù)端可能主動(dòng)發(fā)起四次握手?jǐn)嚅_(kāi)TCP連接，客戶端能夠知道該TCP連接已經(jīng)無(wú)效；另外TCP還有心跳包來(lái)檢測(cè)當(dāng)前連接是否還活著，方法很多，避免浪費(fèi)資源。

三、長(zhǎng)連接的數(shù)據(jù)傳輸完成識(shí)別

? ? 使用長(zhǎng)連接之后，客戶端、服務(wù)端怎么知道本次傳輸結(jié)束呢？兩部分：1是判斷傳輸數(shù)據(jù)是否達(dá)到了Content-Length指示的大小；2動(dòng)態(tài)生成的文件沒(méi)有Content-Length，它是分塊傳輸（chunked），這時(shí)候就要根據(jù)chunked編碼來(lái)判斷，chunked編碼的數(shù)據(jù)在最后有一個(gè)空chunked塊，表明本次傳輸數(shù)據(jù)結(jié)束。更細(xì)節(jié)的介紹可以看這篇文章。

四、并發(fā)連接數(shù)的數(shù)量限制

? ? 在web開(kāi)發(fā)中需要關(guān)注瀏覽器并發(fā)連接的數(shù)量，RFC文檔說(shuō)，客戶端與服務(wù)器最多就連上兩通道，但服務(wù)器、個(gè)人客戶端要不要這么做就隨人意了，有些服務(wù)器就限制同時(shí)只能有1個(gè)TCP連接，導(dǎo)致客戶端的多線程下載（客戶端跟服務(wù)器連上多條TCP通道同時(shí)拉取數(shù)據(jù)）發(fā)揮不了威力，有些服務(wù)器則沒(méi)有限制。瀏覽器客戶端就比較規(guī)矩，知乎這里有分析，限制了同域名下能啟動(dòng)若干個(gè)并發(fā)的TCP連接去下載資源。并發(fā)數(shù)量的限制也跟長(zhǎng)連接有關(guān)聯(lián)，打開(kāi)一個(gè)網(wǎng)頁(yè)，很多個(gè)資源的下載可能就只被放到了少數(shù)的幾條TCP連接里，這就是TCP通道復(fù)用（長(zhǎng)連接）。如果并發(fā)連接數(shù)少，意味著網(wǎng)頁(yè)上所有資源下載完需要更長(zhǎng)的時(shí)間（用戶感覺(jué)頁(yè)面打開(kāi)卡了）；并發(fā)數(shù)多了，服務(wù)器可能會(huì)產(chǎn)生更高的資源消耗峰值。瀏覽器只對(duì)同域名下的并發(fā)連接做了限制，也就意味著，web開(kāi)發(fā)者可以把資源放到不同域名下，同時(shí)也把這些資源放到不同的機(jī)器上，這樣就完美解決了。

五、容易混淆的概念——TCP的keep alive和HTTP的Keep-alive

? ??TCP的keep alive是檢查當(dāng)前TCP連接是否活著；HTTP的Keep-alive是要讓一個(gè)TCP連接活久點(diǎn)。它們是不同層次的概念。 ? ? TCP keep alive的表現(xiàn)： ? ? 當(dāng)一個(gè)連接“一段時(shí)間”沒(méi)有數(shù)據(jù)通訊時(shí)，一方會(huì)發(fā)出一個(gè)心跳包（Keep Alive包），如果對(duì)方有回包則表明當(dāng)前連接有效，繼續(xù)監(jiān)控。 這個(gè)“一段時(shí)間”可以設(shè)置。 WinHttp庫(kù)的設(shè)置：

WINHTTP_OPTION_WEB_SOCKET_KEEPALIVE_INTERVAL
Sets the interval, in milliseconds, to send a keep-alive packet over the connection. The default interval is 30000 (30 seconds). The minimum interval is 15000 (15 seconds). Using WinHttpSetOption to set a value lower than 15000 will return with ERROR_INVALID_PARAMETER.

libcurl的設(shè)置： http://curl.haxx.se/libcurl/c/curl_easy_setopt.html CURLOPT_TCP_KEEPALIVE Pass a long. If set to 1, TCP keepalive probes will be sent. The delay and frequency of these probes can be controlled by the CURLOPT_TCP_KEEPIDLE and CURLOPT_TCP_KEEPINTVL options, provided the operating system supports them. Set to 0 (default behavior) to disable keepalive probes (Added in 7.25.0). CURLOPT_TCP_KEEPIDLE Pass a long. Sets the delay, in seconds, that the operating system will wait while the connection is idle before sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0) CURLOPT_TCP_KEEPINTVL Pass a long. Sets the interval, in seconds, that the operating system will wait between sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0) ? ? ?CURLOPT_TCP_KEEPIDLE是空閑多久發(fā)送一個(gè)心跳包，CURLOPT_TCP_KEEPINTVL是心跳包間隔多久發(fā)一個(gè)。? 打開(kāi)網(wǎng)頁(yè)抓包，發(fā)送心跳包和關(guān)閉連接如下： ? ? ? 從上圖可以看到，大概過(guò)了44秒，客戶端發(fā)出了心跳包，服務(wù)器及時(shí)回應(yīng)，本TCP連接繼續(xù)保持。到了空閑60秒的時(shí)候，服務(wù)器主動(dòng)發(fā)起FIN包，斷開(kāi)連接。

六、HTTP 流水線技術(shù)

? ? 使用了HTTP長(zhǎng)連接（HTTP persistent connection ）之后的好處，包括可以使用HTTP 流水線技術(shù)（HTTP pipelining，也有翻譯為管道化連接），它是指，在一個(gè)TCP連接內(nèi)，多個(gè)HTTP請(qǐng)求可以并行，下一個(gè)HTTP請(qǐng)求在上一個(gè)HTTP請(qǐng)求的應(yīng)答完成之前就發(fā)起。從wiki上了解到這個(gè)技術(shù)目前并沒(méi)有廣泛使用，使用這個(gè)技術(shù)必須要求客戶端和服務(wù)器端都能支持，目前有部分瀏覽器完全支持，而服務(wù)端的支持僅需要：按HTTP請(qǐng)求順序正確返回Response（也就是請(qǐng)求&響應(yīng)采用FIFO模式），wiki里也特地指出，只要服務(wù)器能夠正確處理使用HTTP pipelinning的客戶端請(qǐng)求，那么服務(wù)器就算是支持了HTTP pipelining。 ? ? 由于要求服務(wù)端返回響應(yīng)數(shù)據(jù)的順序必須跟客戶端請(qǐng)求時(shí)的順序一致，這樣也就是要求FIFO，這容易導(dǎo)致Head-of-line blocking：第一個(gè)請(qǐng)求的響應(yīng)發(fā)送影響到了后邊的請(qǐng)求，因?yàn)檫@個(gè)原因?qū)е翲TTP流水線技術(shù)對(duì)性能的提升并不明顯（wiki提到，這個(gè)問(wèn)題會(huì)在HTTP2.0中解決）。另外，使用這個(gè)技術(shù)的還必須是冪等的HTTP方法，因?yàn)榭蛻舳藷o(wú)法得知當(dāng)前已經(jīng)處理到什么地步，重試后可能發(fā)生不可預(yù)測(cè)的結(jié)果。POST方法不是冪等的：同樣的報(bào)文，第一次POST跟第二次POST在服務(wù)端的表現(xiàn)可能會(huì)不一樣。 ? ? 在HTTP長(zhǎng)連接的wiki中提到了HTTP1.1的流水線技術(shù)對(duì)RFC規(guī)定一個(gè)用戶最多兩個(gè)連接的指導(dǎo)意義：流水線技術(shù)實(shí)現(xiàn)好了，那么多連接并不能提升性能。我也覺(jué)得如此，并發(fā)已經(jīng)在單個(gè)連接中實(shí)現(xiàn)了，多連接就沒(méi)啥必要，除非瓶頸在于單個(gè)連接上的資源限制迫使不得不多開(kāi)連接搶資源。 ? ? 目前瀏覽器并不太重視這個(gè)技術(shù)，畢竟性能提升有限。 ?本文所在：http://www.cnblogs.com/cswuyg/p/3653263.html ?

七、學(xué)習(xí)資料

1、HTTP Keep-Alive模式：http://www.cnblogs.com/skynet/archive/2010/12/11/1903347.html 2、瀏覽器的并發(fā)請(qǐng)求限制：http://www.zhihu.com/question/20474326 3、RFC文檔 connection部分：http://tools.ietf.org/html/rfc2616#page-44 4、C/C++網(wǎng)絡(luò)編程中的TCP?；?#xff1a;?http://blog.csdn.net/weiwangchao_/article/details/7225338 5、HTTP persistent connection：?http://en.wikipedia.org/wiki/HTTP_persistent_connection 6、HTTP pipelining：http://en.wikipedia.org/wiki/HTTP_pipelining 7、Head-of-line blocking：http://en.wikipedia.org/wiki/Head-of-line_blocking 8、《HTTP權(quán)威指南》第四章 連接管理? 超強(qiáng)干貨來(lái)襲 云風(fēng)專(zhuān)訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的http 长连接 短连接的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。