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（页面存档备份，存于互联网档案馆）