连接建立：Nginx反向代理实现支持长连接详解

前言

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

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的长连接。由于Nginx作者之前没有考虑upstream的长连接，所以在设计上要把http upstream keepalive模块化可能比较难，只能通过手动修改代码来做到。

一个完整的让upstream支持长连接的配置示例如下：

#user nobody; 
worker_processes 1; 
 
#error_log logs/error.log; 
#error_log logs/error.log notice; 
#error_log logs/error.log info; 
 
#pid logs/nginx.pid; 
 
 
events { 
 worker_connections 1024; 
} 
 
 
http { 
 include mime.types; 
 default_type application/octet-stream; 
 
 #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 
 #   '$status $body_bytes_sent "$http_referer" ' 
 #   '"$http_user_age

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，谢谢大家对本站的支持。

参考：

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive