细说Http中的Keep-Alive和Java Http中的Keep-Alive机制

什么是 Keep-Alive

这个词看着有点熟，很多地方好像都见过。

TCP 的 KeepAlive，Http 的 KeepAlive，现在就连一些前端框架都有类似 KeepAlive 的东西了（比如 VUE.js，保持路由）。

本文介绍 HTTP 和 TCP 中的 KeepAlive 机制，其他方面不在本文讨论范围。

Http 中的 Keep-Alive

HTTP 持久连接（HTTP persistent connection，也称作 HTTP keep-alive 或 HTTP connection reuse，翻译过来可以是保持连接或者连接复用）是使用同一个 TCP 连接来发送和接收多个 HTTP 请求 / 应答，而不是为每一个新的请求 / 应答打开新的连接的方式。

HTTP 协议采用 “请求 - 应答” 模式，当使用普通模式，即非 KeepAlive 模式时，每个请求 / 应答客户和服务器都要新建一个连接，完成 之后立即断开连接（HTTP 协议为无连接的协议），每次请求都会经过三次握手四次挥手过程，效率较低；当使用Keep-Alive模式时，客户端到服务器端的连接不会断开，当出现对服务器的后继请求时，客户端就会复用已建立的连接。

下图是每次新建连接和连接复用在通信模型上的区别：

在 Http 1.0 中，Keep-Alive是没有官方支持的，但是也有一些 Server 端支持，这个年代比较久远就不用考虑了。

Http1.1 以后，Keep-Alive已经默认支持并开启。客户端（包括但不限于浏览器）发送请求时会在 Header 中增加一个请求头Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，也会在响应头中添加 Keep-Alive。这样一来，客户端和服务器之间的 HTTP 连接就会被保持，不会断开（断开方式下面介绍），当客户端发送另外一个请求时，就可以复用已建立的连接。

现在的 Http 协议基本都是 Http 1.1 版本了，不太需要考虑 1.0 的兼容问题

Keep-Alive 真的就这么完美吗

当然不是，Keep-Alive 也有自己的优缺点，并不是所有场景下都适用

优点

• 节省了服务端 CPU 和内存适用量
• 降低拥塞控制 （TCP 连接减少）
• 减少了后续请求的延迟（无需再进行握手）

缺点

对于某些低频访问的资源 / 服务，比如一个冷门的图片服务器，一年下不了几次，每下一次连接还保持就比较浪费了（这个场景举的不是很恰当）。Keep-Alive 可能会非常影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间，额外占用了服务端的连接数。

连接复