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