HTTP/1.1 持久鏈接 persistent connection

 

首先：HTTP的長鏈接和短鏈接本質上是TCP長鏈接和短鏈接。

 

1. 在HTTP1.0中，默認的是短鏈接，沒有正式規定 Connection:Keep-alive 操做；在HTTP1.1中全部鏈接都是Keep-alive的，也就是默認都是持續鏈接的（Persistent Connection）。

2. 兩種的鏈接方式的區別以下圖所示

3. 從上圖能夠看出，客戶端與服務器創建持續鏈接後，在鏈接期間能夠處理多個請求/響應（Request/Response）

 

HTTP權威指南：

HTTP/1.1 容許HTTP設備在事務處理結束之後將TCP鏈接保持在打開狀態，後面的HTTP Request/Response 依然能夠經過這個TCP鏈接繼續傳送。

在事務結束以後仍然保持在打開狀態的TCP鏈接成爲持久連接。非持久鏈接會在每一個事務結束後關閉，持久鏈接會在不一樣事務（Request/Response）之間保持打開狀態，知道客戶端或服務器決定將其關閉爲止。

 

能夠提升HTTP鏈接性能的方法：

並行鏈接

經過多條鏈接發起併發的HTTP請求。並行鏈接能夠提升複合頁面的傳輸速度，但其鏈接也有一些缺點

每一個事務都會打開/關閉一條新的鏈接，會耗費時間和帶寬。因爲TCP慢啓動特性存在，每條鏈接的性能都會有所下降。可打開的並行鏈接數量其實是有限的

持久化鏈接

Web客戶端常常會打開到同一個站點的鏈接。好比，一個Web頁面上的大部份內嵌圖片一般來自同一個Web站點，並且至關一部分指向其餘對象的超鏈一般都指向同一個站點。初始化了對某服務器HTTP請求的應用程序極可能會不久的未來對那臺服務器發起更多的請求，這種性質稱爲站點局部性。

 

所以，HTTP/1.1容許HTTP設備在事務處理結束以後將TCP鏈接保持在打開狀態，以便爲將來的HTTP請求重用現存的鏈接。在事務處理結束以後仍然保持在打開狀態的TCP鏈接稱之爲持久鏈接。持久鏈接會在不一樣事務之間保持打開狀態，直到客戶端或服務器決定其關閉爲之。重用已對目標服務器打開的空閒持久鏈接，就能夠避開緩慢的鏈接創建階段。並且，已經打開的鏈接還能夠避免慢啓動的擁塞適應階段，以便更快速地進行數據傳輸。因此，持久鏈接下降了時延和鏈接創建的開銷，將鏈接保持在已調諧狀態，並且減小了打開鏈接的潛在數量。

持久鏈接和並行鏈接配合使用多是最高效的方式。不少Web應用程序都會打開少許的並行鏈接，其中每一個都是持久鏈接。持久鏈接有兩種類型

1）HTTP/1.0 + keep-alive 鏈接

2) HTTP/1.1 + persistent 鏈接

 

 

HTTP/1.0  keep-alive鏈接

如今不少客戶端和服務器仍然在使用這些早期的keep-live鏈接。

實現HTTP/1.0 keep-live鏈接的客戶端能夠經過包含Connection:Keep-Alive 首部請求將一條鏈接保持在打開狀態。

若是服務器願意爲下一條請求將鏈接保持在打開狀態，就在響應中包含相同的首部，若是響應中沒有Connection:Keep-Alive 首部，客戶端就認爲服務器不支持keep-live，會在發回響應報文後關閉鏈接。

 

響應中Keep-Alive首部是可選的，但只有在提供Connection：Keep-Alive時才能使用它。

Connection:Keep-Alive

Keep-Alive:max=5,timeout=120

這個例子說明了服務器最多還會爲另外5個事務保持鏈接的打開狀態，或者將打開狀態保持到鏈接空閒了2分鐘之後。

 

注意：

1 在HTTP/1.0中，keep-alive並非默認使用的。客戶端必需發送一個Connection：Keep-Alive 請求首部來激活keep-alive鏈接。

2 若是服務器願意爲下一條請求將鏈接保持在打開狀態，就在響應中包含相同的首部，若是響應中沒有Connection:Keep-Alive 首部，客戶端就認爲服務器不支持keep-live，會在發回響應報文後關閉鏈接。

3 只有在無需檢測到鏈接的關閉就能夠肯定報文實體主體部分長度的狀況下，才能將鏈接保持在打開狀態--也就是說實體的主體部分必需有正確的Content-Length，

有多部件媒體類型（multipart/form-data ?  有boundary）或者用分塊傳輸編碼的方式進行了編碼。在一條keep-live信道中回送錯誤的Content-Length是很糟糕的事情，這樣的話，事務處理的另外一端就沒法精確地檢測出一條報文的結束和另外一條報文的開始了。

 

HTTP/1.1  持久鏈接 Persistent Connection 

HTTP/1.1逐漸中止了對keep-alive鏈接的支持，用一種名爲持久鏈接的改進型設計取代了它。持久鏈接的目的與keep-alive鏈接的目的相同，可是工做機制更優些。HTTP/1.1就吃鏈接在默認狀況下是激活的，除非特別指明，不然HTTP/1.1假定全部的鏈接都是持久的，要在事務處理結束以後將鏈接關閉，HTTP/1.1應用程序必須向報文中顯示地添加一個Connection：close首部。

HTTP1.1客戶端加載在收到響應後，除非響應中包含了Connection：close首部，否則HTTP/1.1鏈接就仍然維持在打開狀態。可是，客戶端和服務器仍然能夠隨時關閉空閒的鏈接。不發送Connection：close並不意味這服務器承諾永遠將鏈接保持在打開狀態。

注意：

1 只有當鏈接全部的報文都有正確的、自定義報文長度時，也就是說，實體主體部分的長度都和相應的Content-Length一致，或者用分塊傳輸編碼方式編碼的，鏈接誒才能持久保持。

2 若是客戶端不想在鏈接上發送其餘請求了，就應該在最後一條請求中發送一個Connection：close請求首部

 

 

管道化鏈接

HTTP/1.1容許在持久鏈接上可選的使用請求管道。是相對於keep-alive鏈接的又一性能優化。在響應到達以前，能夠將多條請求放入隊列，當第一條請求經過網絡流向服務器時，第二條和第三條請求也能夠開始發送了。在高時延網絡條件下，這樣作能夠下降網絡的環回時間，提升性能。

對管道鏈接的說明：

1）若是HTTP客戶端沒法確認鏈接是持久的，就不該該使用管道

2）必須按照與請求相同的順序回送HTTP響應。

3）HTTP客戶端必須作好鏈接會在任意時刻關閉的準備，還要準備好重發全部未完成管道化的請求。

4）出錯的時候，管道鏈接會阻礙客戶端了解服務器執行的是一些列管道化請求中的哪一些。因爲沒法安全地重試POST這樣的非冪請求，因此出錯時，就存在某些方法永遠不會被執行的風險。