关于Nginxupstreamkeepalive的说明
模块是 HttpUpstreamModule，配置的一个例子：
[shell]upstream http_backend {
erver 127.0.0.1:8080
keepalive 16
}
erver {
…
location /http/ {
roxy_pass http://http_backend
roxy_http_version 1.1
roxy_set_header Connection ""
…
}
}[/shell]
有几点要说明：
1. 默认情况下 Nginx 访问后端都是用的短连接(HTTP1.0)，一个请求来了，Nginx 新开一个端口和后端建立连接，请求结束连接回收。如果像上面的配置一样设置了长连接，Nginx 会接受客户端的请求，处理完成之后 Nginx 会「继续保持和后端的长连接」，如果并发请求超过了 keepalive 指定的最大连接数，Nginx 会启动新的连接 来转发请求，新连接在请求完毕后关闭，而且新建立的连接是长连接，这可能会造成额外的问题，最后再说。
2. keepalive 指定的 数值 是 Nginx 每个 worker 连接后端的最大长连接数，而不是整个 Nginx 的。 而且这里的后端指的是「所有的后端」，而不是每一个后端(已验证)。
3. 在官网上 可以看到 还有一个 single 参数，说实话我没懂什么意思，但是它已经被废弃了，看这里
4. HttpUpstreamModule 模块里面还有一共指令：least_conn，解释如下：
Specifies that a group should use a load balancing method where a request is passed to the server with the least number of active connections, taking into account weights of servers. If there are several such servers, they are tried in turn using a weighted round-robin balancing method.
翻译：
指定服务器组的负载均衡方法，根据其权重值，将请求发送到「活跃连接数最少」的那台服务器。 如果这样的服务器有多台，那就采取有权重的轮转法进行尝试。
使用这个指令的时候后端服务器的连接数好像会变的非常少，很奇怪，我还没亲自测过，待确认。
最后再说一下第 1 点，先说一个现象，我发现当 keepalive 设置小的时候，比如1，那么并发请求上去之后 Nginx 会出现大量的 TIME_WAIT，而如果把 keepalive 关掉(proxy_http_version 1.1 和 proxy_set_header Connection “” 指令也去掉)，那么 TIME_WAIT 就会出现在后端服务器了，后端用的是 tornado，相信 jetty 和 tomcat 也是一样。
这个现象是怎么产生的呢，做一个测试。
命令：ab -n 100 -c 5 http://pxe1.hy01/
xe1.hy01 (Nginx，上面配置了长连接，ip: 10.0.31.84) ，它会转到 pxe0.hy01 的 8888 端口(tornado，ip: 10.0.11.12)
测试的时候在 pxe1.hy01 执行抓包命令：
# tcpdump -i em2 -A host 10.0.11.12 -
看到：
00:22:53.252039 IP 10.0.31.84.53915 > 10.0.11.12.ddi-tcp-1: Flags [P.], seq 81:161, ack 275, win 123, length 80
@.@.].
..T
…..”…p%8|..P..{>…GET / HTTP/1.1
Host: http_backend
User-Agent: ApacheBench/2.3
Accept: */*
但是如果把 pxe1.hy01 的长连接设置都去掉的话，抓包如下：
00:23:58.111974 IP 10.0.31.84.54051 > 10.0.11.12.ddi-tcp-1: Flags [P.], seq 1:100, ack 1, win 115, length 99
E…..@.@.Z=
..T
….#”…O…SUP..s>…GET / HTTP/1.0
Host: http_backend
Connection: close
User-Agent: ApacheBench/2.3
Accept: */*
那么上面出现的现象就好解释了，是这样：
Nginx 和后端的长连接不够用时 Nginx 会新建连接来处理新的请求，而我们的配置已经配置死了 HTTP1.1，建立连接后，后端认为是「长连接」而不会主动关闭连接(一般有个空闲超时)，关闭连接由 Nginx 来做了，所以 Nginx 会出现大量的 TIME_WAIT。
而默认情况下，Nginx 用 HTTP1.0 请求后端，后端处理完成后就主动关闭连接，所以 TIME_WAIT 在后端。
那么现在有新的问题了，如果开启了长连接，而长连接又大量不够用，此时 Nginx 存在的 TIME_WAIT 可能会大量占用端口，导致端口用尽，如果用尽，后果很严重。
所以，「慎用 Nginx 的 长连接」。