nginx 长连接

问题：nginx与后端upstream下面的服务器建立的都是短链接。这样nginx往upstream后端发请求时，也会消耗很多的时间与带宽，如果让nginx与upstream后端建立起长链接，从nginx发起的请求就可以挑选一个合适的长链接发往upstream后端服务器，这样即可以节省带宽，也可以提高响应速度。

 

1、关于nginx upstream长链接的介绍及具体的实现方式

http://bollaxu.iteye.com/blog/900424

Nginx upstream目前只有短连接，通过HTTP/1.0向后端发起连接，并把请求的"Connection" header设为"close"。Nginx与前端的连接默认为长连接，一个用户跟Nginx建立连接之后，通过这个长连接发送多个请求。如果Nginx只是作为reverse proxy的话，可能一个用户连接就需要多个向后端的短连接。如果后端的服务器（源站或是缓存服务器）处理并发连接能力不强的话（比如单进程的squid），就可能导致瓶颈的出现。

 

 

Nginx目前的upstream连接建立和获取的机制如下图。Nginx会在一开始创建connection pool（进程间不共享，可以避免锁），提供给所有向前/后的连接。

 

如果要实现upstream长连接，则每个进程需要另外一个connection pool，里面都是长连接。一旦与后端服务器建立连接，则在当前请求连接结束之后不会立即关闭连接，而是把用完的连接保存在一个keepalive connection pool里面，以后每次需要建立向后连接的时候，只需要从这个连接池里面找，如果找到合适的连接的话，就可以直接来用这个连接，不需要重新创建socket或者发起connect()。这样既省下建立连接时在握手的时间消耗，又可以避免TCP连接的slow start。如果在keepalive连接池找不到合适的连接，那就按照原来的步骤重新建立连接。假设连接查找时间可以忽略不计，那么这种方法肯定是有益而无害的（当然，需要少量额外的内存）。

 

具体如何来设计这个keepalive connection pool，不同人有不同的选择。比如Nginx目前的第三方模块upstream keepalive（作者Maxim Dounin）使用了一个queue来做。因为upstream的服务器很可能是多个，所以可能当保持的连接数多的时候，查找的时间可能会较长。可以给每个upstream服务器都分配一个pool（queue），缩短查找时间。但是总体来说内存操作很快，影响不会很大。upstream keepalive模块目前只支持memcached，但是可以重用其代码来达到对http upstream的长连接。在upstream模块和反向代理（二）里面highlight了一些改动的地方。由于Nginx作者之前没有考虑upstream的长连接，所以在设计上要把http upstream keepalive模块化可能比较难，只能通过手动修改代码来做到。

 

2、使用nginx keepalive，网站TPS性能提升对比

http://sohulinux.blog.sohu.com/180744817.html

编者按：本月初 Maxim Dounin，Nginx 最活跃的开发者之一，提交了 upstream keepalive patch，支持 http/fastcgi/memcached，除了减少和 upstream 的网络开销外，也意味着能反向代理 http chunked 响应了！搜狐技术部CMS组的同学进行了一个简单的测试：

---------- 已转发邮件 ----------
发件人： 韩孝冰
日期： 2011年8月8日 下午3:51
主题： HttpUpstreamKeepalive效果瞠目结舌

HttpUpstreamKeepalive真的很牛X啊。

siege -c200 -b -t10M -lsiege.log -H"Accept-Encoding: gzip,deflate" -i -f urls.txt
siege的结果：
Lifting the server siege...      done.
Transactions:               11125884 hits
Availability:                  100.00 %
Elapsed time:                 599.53 secs
Data transferred:            8139.93 MB
Response time:                  0.01 secs
Transaction rate:            18557.68 trans/sec
Throughput:                    13.58 MB/sec
Concurrency:                   199.11
Successful transactions:    11125884
Failed transactions:               0
Longest transaction:            9.01
Shortest transaction:           0.00

对比之前的压测结果，tps提升了7倍，100%成功响应。并发达到参数设置的上限，预示可能还有提升空间。

链接占用也很稳定，部了nginx+memcached的那台机器，time_wait在60000左右，总链接数不找过64000。
netstat -at | awk '/^tcp/{a[$6]++}END{for(i in a ){printf("%s\t%d\n",i,a[i])}}'
TIME_WAIT       59830
FIN_WAIT1       59
FIN_WAIT2       1
ESTABLISHED     3255
SYN_RECV        35
LISTEN  10