HTTP持久連接

HTTP持久連接（英語：HTTP persistent connection，也稱作HTTP keep-alive或HTTP connection reuse）是使用同一個TCP連接來傳送和接收多個HTTP請求/應答的方法。使用該方法可以避免為每一個新的請求/應答打開一個新的連接。

歷史

HTTP 0.9協定不支援持久連接。每一次請求與回應完成後，客戶端與伺服器端的連接均必須被切斷。

HTTP 1.0協定中並未定義持久連接的實現方式，但是一些伺服器端和客戶端開始使用這種方式互動。如果瀏覽器支援keep-alive，它會在請求的頭欄位中添加：

Connection: Keep-Alive

然後當伺服器收到請求，作出回應的時候，它也在響應中添加如下HTTP頭：

Connection: Keep-Alive

並且在完成回應之後的一段時間保持TCP連接。此時，客戶端知道伺服器端支援持久連接，故此在客戶端傳送另一個請求時，會直接使用同一個連接傳送這個請求。這種持久連接將一直持續到在客戶端或伺服器端認為無需繼續維持時主動中斷連接，或是使用 Connection: close 欄位通知對方為止。

在HTTP 1.1中，除非任意一方在請求時明確聲明不支援持久連接，否則所有的連接預設都是持續連接。 HTTP 1.1的持久連接不需要使用獨立的keepalive資訊，但是出於相容性考慮，實作上仍然通常會如上述 HTTP 1.0一樣傳送 Connection: Keep-Alive 欄位以期盼對方不會切斷連接。

HTTP 2.0協定要求雙方必須支援復用連接。HTTP 3.0因為使用基於UDP的QUIC協定，故此不存在「連接」的概念，自然無需提供持久連接。

優勢

• 較少的CPU和主記憶體的使用（由於同時打開的連接的減少了）
• 允許請求和應答的HTTP管線化
• 降低擁塞控制 （TCP連接的數量減少了）
• 減少了後續請求的延遲（無需再進行握手）
• 無需關閉TCP連接即可報告錯誤

根據RFC 2616 （47頁），用戶客戶端與任何伺服器和代理伺服器之間不應該維持超過2個連結。代理伺服器連接到其他伺服器或代理伺服器時，應該最多使用2×N個持久連接，其中N是同時活躍的用戶數。這個指引旨在提高HTTP響應時間並避免阻塞。

劣勢

伺服器可以建立的連接數量受到埠數與檔案控制代碼數的限制。如需和客戶端保持一個開啟時間較長的連接，那麼伺服器可以同時服務的客戶端數量則會減少。

為了應對這一問題，Apache 2.0 httpd的預設連接過期時間僅有15秒 ，而更新版本的Apache 2.2僅有5秒。 通過設置較短的過期時間，一個客戶端能夠在最開始時快速的傳輸多個web頁組件，而不會長期佔用伺服器的進程或埠資源。但是，這樣也會使得客戶端在需要發起新請求時，原先建立的持久連接可能已經被伺服器端關閉。這直接削弱了持久連接帶來的優勢。

持久連接僅在客戶端需要傳送多於一個請求時才能發揮優勢。在圖片存放網站等的一些客戶端僅需發起一個請求的使用場景下，Keep-Alive會導致客戶端在請求完成之後的較長時間仍然與伺服器保持不必要的連接，故此反而會導致效能下降。

Web瀏覽器

使用多個連接和使用持久連結的對比

網景領航員（4.05版本以後）和Internet Explorer（4.01版本以後）支援使用持久連結連結Web伺服器和代理伺服器。

網景在需要打開一個連接到不同的伺服器上的新持久連結時，使用最近最少使用演算法終止一個空閒的持久連結。

Internet Explorer支援持久連結，IE 6和IE 7預設使用2個持久連結，而IE 8預設使用6個持久連結。持久連結在不活躍60秒後過時關閉。該時長可以在Windows登錄檔中修改。

Mozilla Firefox支援持久連結。瀏覽器默認在連接不活躍300秒（5分鐘）後過時關閉，亦對持久連接的最大個數（每個伺服器，每個代理伺服器，總數）加以限制。這些限制均可於組態中修改。

Opera 4.0版本開始支援持久連結。可以組態持久連接的最大個數（每個伺服器，總數）。

外部連結

• RFC 2616 (HTTP/1.1), 8.1 Persistent Connections（頁面存檔備份，存於互聯網檔案館）
• Persistent Connection Behavior of Popular Browsers (dated)（頁面存檔備份，存於互聯網檔案館）
• Apache Keep-Alive Support（頁面存檔備份，存於互聯網檔案館）