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（頁面存檔備份，存於網際網路檔案館）