前言

一开始接触到长连接、keepalive的概念时，可能对这些概念比较模糊，具体到协议以及开发中这些都是啥，以下几个问题展开说明，记录于此，有漏指正。

问题一：http1.1协议内容默认是长连接，即keepalive，同时在tcp协议中也有keepalive的概念，区别是什么？

问题二：http的长连接和tcp有什么关系？

问题三：长连接是为了传输效率，客户端/服务端都做了什么？

什么是keepalive

很明确的说，在http 应用层的keepalive 和 tcp 传输层的 keepalive是两个没啥关系的概念。

一、http

http 的keepalive是 http协议内容，http 是在tcp 建链完成的基础上进行的，keepalive意思我作为客服端告诉服务端，我的http消息发过去，你完事了不能把这个tcp链接给我关了，我建个tcp链接也不容易啊，下次我指不定还能用得上这个链接。

这里涉及到双端协议的大概：
第一 client端connect()后，通过send/recv完成http请求后，不会立即关闭这个链接（链接池统一管理），下次不需要重新connect()而是直接从链接池中拿出来用。
第二 server端被告知不能在send http response后立即关闭这个链接，http是无状态但是tcp必须双端都保证不关闭，所以http的keepalive 说直白点就是，在http 协议层通过头域connection:keep-alive 来确保两边都要延迟关闭tcp链接，以达到复用。

对于客服端，通常的实现是采用链接池，每次使用完的链接，统一由链接池管理，业务每次过来取一个可用的就行(如果服务端确实都关闭了，再重新再建也不迟)。

ngx_http_keepalive_handler(ngx_event_t *rev)
{
...

c = rev->data;
ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log,0,"http keepalive handler");


if (rev->timedout || c->close) {
    ngx_http_close_connection(c);
    return;
}
...
}

对于服务端，看一段nginx 源码，服务端收到keepalive请求后，没有把链接直接关掉，而是在定时器中注册超时回调函数ngx_http_keepalive_handler（注意nginx中epollo 事件c-read也被重置为ngx_http_keepalive_handler ，所以要么超时后定时器触发，要么有客服端发消息过来触发epoll读事件），如果是超时触发的rev->timedout=1（为毛说好的客服端半天没再发消息来，如果超时前客服端有消息过来，epoll read事件肯定先触发），又或者链接处于待关闭状态 c->close，这时候再关闭掉这个链接(服务端：我已经尽力了，兄弟)。说明链接并不活跃。

二、TCP

TCP建链完成后，可以想象为一根数据管道，要么正常传输，管道中有数据往来，要么处于闲置状态，等待被关闭，但是问题来了，通常在代码层面由客服端或服务端主动close(fd)(但要是代码就煞笔了没写漏掉了呢，且不懵逼，tcp协议栈在操作系统层面，操作系统自然不可能不管）。

对于这个链路有个保活机制保证，闲置状态下，每隔一段时间服务端会发送一个探测包，看客服端是否正常响应。以上面的http 的keepalive要求tcp保持一段时间这种情况为例。
第一（假如突然就是没业务往来了），代码上也并没有nginx那样的关闭动作，那tcp自己的保活机制将会自动在2小时后关闭(操作系统参数配置)。
第二 假如网路中断，服务端没收到任何客服端fin包是不可能知道网线断了的（有点夸张），那也可以通过这个机制，保证tcp正常关闭。

三、所以一句话：

http keepalive是协商如何复用tcp链接，即所谓http长连接，TCP keepalive是管道的保活机制，避免链接无业务盲等。