HTTP keep-alive 和 TCP keepalive 的区别

首先，二者是完全不同的东西：

• HTTP keep-alive：是应用层（用户态）实现，称为HTTP长连接；
• TCP keepalive，是传输层TCP（内核态）实现，称为TCP保活机制

HTTP 的 keep-alive

HTTP 协议采用的是「请求-应答」的模式，也就是客户端发起请求，服务端返回响应，如下图：

用于 HTTP 是基于 TCP 传输协议实现的，客户端和服务端要进行 HTTP 通信之前，需要建立 TCP 连接。在完成通信之后，再断开连接。如果每次请求都经历：建立TCP --> 请求资源 --> 响应资源 --> 释放连接，那么此种方式称为 HTTP 短连接。这样的话，一次 TCP 请求只能请求一次资源，无疑造成资源的浪费。

HTTP 的 keep-alive 就是为了避免这种情况。它可以让同一个 TCP 连接来发送和接收多个 HTTP 连接/应答，避免了重复连接和释放的开销，此即为HTTP长连接。

HTTP1.0 中默认是关闭的，如果要开启 keep-alive，需要在请求头里添加Connection: Keep-Alive。服务器收到请求后，会在响应头里添加Connection: Keep-Alive。HTTP1.1 中默认是开启的，如果要关闭，需要在请求头里添加Connection: close。

HTTP 长连接不仅仅减少了 TCP 连接资源的开销，而且这给 HTTP 流水线技术提供了可实现的基础。
所谓的HTTP流水线，是客户端可以先一次性发送多个请求，而在发送过程中不需先等待服务器的回应，可以减少整体的响应时间。

但是如果 HTTP 开启了长连接后，服务端长时间没有收到客户端的请求，仍然会释放该连接来避免资源浪费。通过keepalive_timeout参数来指定 HTTP 长连接的超时时间。当服务端在完成一个请求后，会开启一个定时器，当定时器达到keepalive_timeout设定值后，就会释放该连接。

TCP中的keepalive

TCP 的 Keepalive 这东西其实就是 TCP 的保活机制，它的工作原理我之前的文章写过，这里就直接贴下以前的内容。

如果两端的 TCP 连接一直没有数据交互，达到了触发 TCP 保活机制的条件，那么内核里的 TCP 协议栈就会发送探测报文。

如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
如果对端主机崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
所以，TCP 保活机制可以在双方没有数据交互的情况，通过探测报文，来确定对方的 TCP 连接是否存活，这个工作是在内核完成的。

注意，应用程序若想使用 TCP 保活机制需要通过 socket 接口设置 SO_KEEPALIVE 选项才能够生效，如果没有设置，那么就无法使用 TCP 保活机制。

总结

HTTP 的 Keep-Alive 也叫 HTTP 长连接，该功能是由「应用程序」实现的，可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

TCP 的 Keepalive 也叫 TCP 保活机制，该功能是由「内核」实现的，当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接。