本文主要是介绍TCP的keepalive与HTTP的keep-alive的区别，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
-
这两个完全是两样不同东西
-
实现的层面也不同：
-
HTTP 的 Keep-Alive，是由应用层（用户态） 实现的，称为 HTTP 长连接；
-
TCP 的 Keepalive，是由 TCP 层（内核态） 实现的，称为 TCP 保活机制；
-
-
HTTP的Keep-Alive
-
HTTP 协议采用的是「请求-应答」的模式，也就是客户端发起了请求，服务端才会返回响应，一来一回这样子。
-
由于 HTTP 是基于 TCP 传输协议实现的，客户端与服务端要进行 HTTP 通信前，需要先建立 TCP 连接，然后客户端发送 HTTP 请求，服务端收到后就返回响应，至此「请求-应答」的模式就完成了，随后就会释放 TCP 连接。
-
如果每次请求都要经历这样的过程：建立 TCP -> 请求资源 -> 响应资源 -> 释放连接，那么此方式就是 HTTP 短连接
-
一次连接只能请求一次资源。
-
第一个 HTTP 请求完后，先不断开 TCP 连接，让后续的 HTTP 请求继续使用此连接？
-
HTTP 的 Keep-Alive 就是实现了这个功能，可以使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，避免了连接建立和释放的开销，这个方法称为 HTTP 长连接。
-
HTTP 长连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
-
怎么才能使用 HTTP 的 Keep-Alive 功能？
-
在 HTTP 1.0 中默认是关闭的，如果浏览器要开启 Keep-Alive，它必须在请求的包头中添加：
Connection: Keep-Alive -
然后当服务器收到请求，作出回应的时候，它也添加一个头在响应中：
Connection: Keep-Alive -
这样做，连接就不会中断，而是保持连接。
-
从 HTTP 1.1 开始， 就默认是开启了 Keep-Alive，如果要关闭 Keep-Alive，需要在 HTTP 请求的包头里添加：
Connection:close -
HTTP 长连接不仅仅减少了 TCP 连接资源的开销，而且这给 HTTP 流水线技术提供了可实现的基础。
-
HTTP 流水线，是客户端可以先一次性发送多个请求，而在发送过程中不需先等待服务器的回应，可以减少整体的响应时间。
-
但是服务器还是按照顺序响应，先回应 A 请求，完成后再回应 B 请求。
-
为了避免资源浪费的情况，web 服务软件一般都会提供
keepalive_timeout参数，用来指定 HTTP 长连接的超时时间。
-
-
-
-
TCP 的 Keepalive
-
TCP 的保活机制
-
如果两端的 TCP 连接一直没有数据交互，达到了触发 TCP 保活机制的条件，那么内核里的 TCP 协议栈就会发送探测报文。
-
如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
-
如果对端主机宕机（注意不是进程崩溃，进程崩溃后操作系统在回收进程资源的时候，会发送 FIN 报文，而主机宕机则是无法感知的，所以需要 TCP 保活机制来探测对方是不是发生了主机宕机），或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
-
-
这篇关于TCP的keepalive与HTTP的keep-alive的区别的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
