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中，除非任意一方在请求时明确声明不支持持久连接，否则所有的连接默认都是持续连接。^[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的默认连接过期时间^[2]仅有15秒^[3] ，而更新版本的Apache 2.2仅有5秒。^[4] 通过设定较短的过期时间，一个客户端能够在最开始时快速的传输多个web页组件，而不会长期占用服务器的进程或端口资源。^[5]但是，这样也会使得客户端在需要发起新请求时，原先建立的持久连接可能已经被服务端关闭。这直接削弱了持久连接带来的优势。

持久连接仅在客户端需要发送多于一个请求时才能发挥优势。在图片存放网站等的一些客户端仅需发起一个请求的使用场景下，Keep-Alive会导致客户端在请求完成之后的较长时间仍然与服务器保持不必要的连接，故此反而会导致性能下降。

Web浏览器

使用多个连接和使用持久链接的对比

网景导航者（4.05版本以后）和Internet Explorer（4.01版本以后）支持使用持久链接链接Web服务器和代理服务器。

网景在需要打开一个连接到不同的服务器上的新持久链接时，使用最近最少使用算法终止一个空闲的持久链接。^[6]

Internet Explorer支持持久链接，IE 6和IE 7缺省使用2个持久链接，而IE 8缺省使用6个持久链接^[7]。持久链接在不活跃60秒后过时关闭。该时长可以在Windows注册表中修改^[8]。

Mozilla Firefox支持持久链接。浏览器默认在连接不活跃300秒（5分钟）后过时关闭，亦对持久连接的最大个数（每个服务器，每个代理服务器，总数）加以限制。这些限制均可于配置中修改。^[9]

Opera 4.0版本开始支持持久链接^[10]。可以配置持久连接的最大个数（每个服务器，总数）。