HTTP 長連線與短連線

一，什麼是長連線

http1.1規定了預設保持長連線（http persistent connection ，也有翻譯為持久連線），資料傳輸完成了保持tcp連線不斷開（不發rst包、不四次握手），等待在同網域名稱下繼續用這個通道傳輸資料；相反的就是短連線。

http首部的connection: keep-alive是http1.0瀏覽器和伺服器的實驗性擴充套件，當前的http1.1 rfc2616文件沒有對它做說明，因為它所需要的功能已經預設開啟，無須帶著它，但是實踐中可以發現，瀏覽器的報文請求都會帶上它。如果http1.1版本的http請求報文不希望使用長連線，則要在http請求報文首部加上connection: close。《http權威指南》提到，有部分古老的http1.0 **不理解keep-alive，而導致長連線失效：客戶端-->**-->服務端，客戶端帶有keep-alive，而**不認識，於是將報文原封不動轉給了服務端，服務端響應了keep-alive，也被****給了客戶端，於是保持了「客戶端-->**」連線和「**-->服務端」連線不關閉，但是，當客戶端第傳送第二次請求時，**會認為當前連線不會有請求了，於是忽略了它，長連線失效。書上也介紹了解決方案：當發現http版本為1.0時，就忽略keep-alive，客戶端就知道當前不該使用長連線。其實，在實際使用中不需要考慮這麼多，很多時候**是我們自己控制的，如nginx**，**伺服器有長連線處理邏輯，服務端無需做patch處理，常見的是客戶端跟nginx**伺服器使用http1.1協議&長連線，而nginx**伺服器跟後端伺服器使用http1.0協議&短連線。

在實際使用中，http頭部有了keep-alive這個值並不代表一定會使用長連線，客戶端和伺服器端都可以無視這個值，也就是不按標準來，譬如我自己寫的http

客戶端多執行緒去

的或者連續的多次get請求，都分開在多個tcp通道中，每一條tcp通道，只有一次get，get完之後，立即有tcp關閉的四次握手，這樣寫**更簡單，這時候雖然http頭有connection: keep-alive，但不能說是長連線

。正常情況下

客戶端瀏覽器、web服務端都有實現這個標準，因為它們的檔案又小又多，保持長連線減少重新開tcp連線的開銷很有價值。

二，長連線的過期時間

上圖中的

keep-alive: timeout=20，表示這個tcp通道可以保持20秒。另外還可能有max=***，表示這個長連線最多接收***次請求就斷開。對於客戶端來說，

如果伺服器沒有告訴客戶端超時時間也沒關係，服務端可能主動發起四次握手斷開tcp連線，客戶端能夠知道該tcp連線已經無效；另外tcp還有心跳包來檢測當前連線是否還活著，方法很多，避免浪費資源。

三，長連線資料傳輸完成識別

使用長連線之後，客戶端、服務端怎麼知道本次傳輸結束呢？兩部分：1是判斷傳輸資料是否達到了content-length指示的大小；2動態生成的檔案沒有content-length，它是分塊傳輸（chunked），這時候就要根據chunked編碼來判斷，chunked編碼的資料在最後有乙個空chunked塊，表明本次傳輸資料結束。

四，併發連線數量限制

五、容易混淆的概念——tcp的keep alive和http的keep-alive

tcp的keep alive是檢查當前tcp連線是否活著；http的keep-alive是要讓乙個tcp連線活久點。它們是不同層次的概念。

tcp keep alive的表現：

當乙個連線「一段時間」沒有資料通訊時，一方會發出乙個心跳包（keep alive包），如果對方有回包則表明當前連線有效，繼續監控。

這個「一段時間」可以設定。

curlopt_tcp_keepidle是空閒多久傳送乙個心跳包，curlopt_tcp_keepintvl是心跳包間隔多久發乙個。

開啟網頁抓包，傳送心跳包和關閉連線如下：

從上圖可以看到，大概過了44秒，客戶端發出了心跳包，伺服器及時回應，本tcp連線繼續保持。到了空閒60秒的時候，伺服器主動發起fin包，斷開連線。

HTTP 長連線與短連線

http 長連線短連線

Http 長連線短連線長輪詢短輪詢

HTTP 長連線短連線長輪詢短輪詢

HTTP 長連線 與 短連線

http 長連線 短連線

Http 長連線 短連線 長輪詢 短輪詢

HTTP 長連線 短連線 長輪詢 短輪詢

相關推薦

HTTP 長連線與短連線

http 長連線短連線

Http 長連線短連線長輪詢短輪詢

HTTP 長連線短連線長輪詢短輪詢