转自http://qa.blog.163.com/blog/static/19014700220134771052763/
Keep-Alive即俗称的长连接，使客户端到服务端建立的连接持续有效，当对服务器发起后续请求时，Keep-Alive功能可以复用先前使用过的连接，减少了重新建立连接所需的开销。通常使用HTTP协议采用的是请求应答模式，客户端到服务端的一次请求完成了，它们之间的连接也随之关闭。在某些应用场景下，比如后端RESTful服务，就需要保持住连接，这时就可以启用HTTP Keep-Alive。
下图就是一个比较常见的服务架构。后端服务器提供RESTful服务，需要和前端服务器保持有限的长连接。由于中间架设了代理服务器，即需要前端服务器和代理之间，代理和后端服务器之间都保持连接。另外，最终用户也可以通过浏览器方便地访问后端服务，不过这两者之间就不需要保持连接了。
图1：典型实例
下面主要介绍一个实例，其中代理服务器以nginx为例，后端服务器以tomcat为例。在这种情况下，对tomcat来说nginx是它的一个client，因此我们需要配置nginx的upstream模块
|
upstream backend { server tomcat_ip:8080; } |
但是很奇怪，我们用ss -s在服务器上观察到了很多closed或者time_wait状态的TCP连接，似乎长连接并没有生效。
在tomcat的监听端口上用tcpdump抓包确认一下
|
sudo tcpdump tcp -i eth1 -t -s 0 -c 10000 and port 8080 -w tomcat.cap |
把tomcat.cap导入到wireshark可以方便我们分析，追踪一个流看看，如下图，红色部分为请求，蓝色为应答，下同
从请求和应答都存在HTTP头Connection: Keep-Alive上判断，我们的客户端已经使用了正确的协议。但在这个TCP连接上确实只处理了一次请求，如果Keep-Alive生效，TCP连接上应该存在多次请求应答。下图断开连接后重连的过程也间接说明了这点。
类似的，通过在nginx的监听端口上抓包排除了客户端的问题，如下图，在这个TCP连接上处理了多次请求。因此，应该从nginx上去找原因。
最终找到是Nginx的upstream模块未配置keepalive的原因，摘录官方文档的说明如下。该参数开启与上游服务器之间的连接池，其数值为每个nginx worker可以保持的最大连接数，默认不设置，即nginx作为客户端时keepalive未生效。
|
Activates cache of connections to upstream servers The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are retained in the cache per one worker process. When this number is exceeded, the least recently used connections are closed |
设置该参数后
|
upstream backend { server tomcat_ip:8080; keepalive 256; } |
重新测试并验证，结果如下图所示
此时继续用ss –s观察服务器的连接状态，仍然会出现连接关闭的情况。这又是什么原因呢？求助google大神，发现还是配置问题。
|
位置 |
参数名 |
默认值 |
|
|
Tomcat |
Server.xml |
Connector标签下的maxKeepAliveRequests |
100 |
|
Nginx |
Server模块 |
keepalive_requests |
100 |
表1：keepalive requests配置
两者都是其作为server时生效的配置，即作为server当在一个keepalive的连接上请求次数超过该配置值，server会断开连接，即使它是keepalive的。当然server端判断一个keepalive连接是否需要关闭的依据还有超时时间，这里不详细说明了。
好了，就是这样，看来简单的一个Keep-Alive概念，在实际应用中要用对也是十分不易的。