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模块化可能比较难，只能通过手动修改代码来做到。