码迷,mamicode.com
首页 > 其他好文 > 详细

nginx的proxy模块及upstream模块介绍

时间:2015-05-22 11:45:09      阅读:198      评论:0      收藏:0      [点我收藏+]

标签:nginx proxy upstream

 在互联网场景,nginx通常担任处理静态文件的web文件服务器与反向代理服务器的角色。


nginx反向代理的特性:

1、在上传文件的场景中,客户端与nginx反向代理建立连接,先把需要上传的文件上传到代理服务器,当代理接收完成文件后,再与上游的真实服务器建立连接,快速把文件上传到服务器(与squid的工作方式不同)。为什么要这样做?客户端与代理服务器的连接是互联上慢速连接,而代理与上游服务的连接是内网的高速连接,再因为http的连接是无状态的,客户端与代理的连接可开启keep-alive功能,而代理与上游服务器可关闭keep-alive功能,更能释放上游真实服务器的宝贵资源。 

2、上游服务器接收到用户请求构建好响应报文后,发往nginx反向代理服务器,代理服务器先拆开报文,再封装好响应给客户端,这个过程nginx是边接收上游服务器的响应报文,边向客户端发送响应报文,不会向客户端请求资源时的场景一样nginx反向代理先接收,接收完了再发送给上游服务器。试想这是一个视频站点就明白了,用户点播一个视频资源,如果上游服务器先发送给nginx反向代理,再由反向代理发送给客户端,那客户端的延迟会很大,用户体验就不好了。


proxy模块的常用指令

1、Syntax: proxy_pass URL;

设置代理服务器所使用的协议(http或https)、上游服务器地址(主机名或IP)和一个可选的URI被映射到一个位置。此指令一般用于location中,在使用此指令时要注意一些问题,以下用例子来说明。

例如:

location /name/ {

    proxy_pass http://192.168.0.222/remote/;

}

这里的proxy_pass指定的是一个URI(remote后有一个“/”),当用户请求中匹配到“/name/”时,被代理到后端后路径被更改成上游服务器的“/remote/”,注意这里的“/name/”和"/remote/",要么后边都要加上“/”,加么都去掉“/”,不然会有错误。

再例如:

location /some/path/ {

    proxy_pass http://127.0.0.1;

}

这里的proxy_pass指定的不是一个URI(最后没有“/”),当用户的请求匹配到“/some/path/”时,被代理到后端时会把“/some/path/”加在proxy_pass的路径后边,也就是被改写成了http://127.0.0.1/some/path/这样的URI,把“/some/path/当作了http://127.0.0.1的根”。如果"/some/path/"在本地主机上也真实存在,但这样的请求nginx依然会返回500错误,所以这样的语法是不允许的,如果proxy_pass指定的是另外的主机,只要另外主机上的网站根目录下有“/some/path/”相应的路径,那也能访问到相应的资源。

如果location中采用了正则匹配模式,那proxy_pass一定不能指定成一个URI,而location中匹配到的URI将被直接传递给上游服务器,例如:

location ~ ^/name/ {

    proxy_pass http://192.168.0.222;

}

/name/将被代理为http://192.168.0.222/name/。

2、proxy_connect_timeout TIME;

定义nginx作为代理接收到客户端的请求后,需要把这个请求转发到上游服务器的最大等待时长,默认是60秒,建议不要超过75秒。

3、proxy_cookie_domain off;

      proxy_cookie_domain domain replacement;

将upstream server通过Set-Cookie首部设定的domain属性修改为指定的值,其值可以为一个字符串、正则表达式的模式或一个引用的变量

4、proxy_cookie_path off;

      proxy_cookie_path path replacement;

将upstream server通过Set-Cookie首部设定的path属性修改为指定的值,其值可以为一个字符串、正则表达式的模式或一个引用的变量

5、proxy_hide_header FIELD;

默认情况下nginx不会将上游服务器的“Date”, “Server”, “X-Pad”, and “X-Accel-...”这些头部字段转发给客户端,使用proxy_hide_header后可以自定义哪些头部字段不被转发。

6、proxy_pass_header FIELD;

与proxy_hide_header相反,定义显式的指定上游服务器的哪些头部字段会转发给客户端。

7、proxy_set_header FILED VALUE;

把客户端发送给nginx代理的首部进行重新定义或附加一个首部,然后传递给上上游服务器,VALUE可以是文本、变量或是文本和变量的组合。例如:

server {

        listen    80;

        server_name www.a.com;

        location / {

            root /web/a.com;

            index index.html;

        }

        location /zcj/ {

            proxy_pass http://192.168.0.201/test/;

            proxy_set_header X-Real-IP $remote_addr;

        }

    }

这里定义了一个“X-Real-IP”的首部,这个首部的值是“$remote_addr”,即是客户端的IP地址,这样上游服务器就可以收到这个自定义的首部,可以利用此手段让上游服务器在访问日志中能够记录真实请求服务的IP地址,而不是记录的全是来自nginx代理的IP地址,有利于做日志分析。

8、proxy_redirect [ default|off|redirect replacement ];

重写location并刷新从upstream server收到的报文的首部,然后才发送给客户端。

9、proxy_send_timeout TIME;

在连接断开之前两次连续发送至upstream server的写操作的最大间隔时长,默认是60秒。

10、proxy_read_timeout TIME;

在连接断开之前两次从接收upstream server接收读操作的最大间隔时长,默认是60秒。

11、proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ...;

设置当上游服务器出现哪此错误时,将下一个请求转发到下一个上游服务器。


upstream模块常用指令

Syntax: upstream name { ... }

Default: —

Context: http

用于设置一个服务器组,组内的服务器可以是主机名,也可以是IP地址,服务器支持端口映射功能。只能用于http的上下文。

Syntax: server address [parameters];

Default: —

Context: upstream

定义上游的服务器的IP、端口、各种参数。

parameters参数有:

weight=NUMBER

设置服务器的权重,默认为1

max_fails=NUMBER

默认为1,与参数与fail_timeout配合使用,表示在fail_timeout指定的时间内,向上游服务器转发失败的次数达到NUMBER的次数,则认为在当前的fail_timeout设置的TIME时间内,此上游服务器不可用。

fail_timeout=TIME

默认为10秒,定义此时间周期内转发失败max_fails定义的NUMBER次后就认为上游服务器不可用。

backup

定义一个备用服务器,只有当其他所有的服务器都不可用时,这个备用的服务器才启用,

down

标记此服务器永久不可用,可作停机维护使用。

max_conns=NUMBER

在1.5.9以后,此参数可设置上游服务器的最大并发数,默认为0,表示不作限制

slow_start=time

设置一台不健康的主机变成健康主机,或者当一台主机在被认为不可用变成可用时,将其权重由零恢复到标称值的时间。默认值为零,也就是说,禁用慢启动。

这个功能仅作为商业订阅的一部分。

Syntax: health_check [parameters];

Default: —

Context: location

开启对上游服务器组的健康检测机制。

paramenters有以下这些:

interval=TIME

两个连续检测间的间隔时长,默认为5秒;

fails=NUMBER

把上游服务器标记为不可用时的连续检测失败的次数,默认为1次;

passes=NUMBER

上游服务器从不可用到可用状态时需要连续检测的次数,默认为1次;

uri=URI

指定健康状态检测的URI,默认是网站的根;

math=NAME

可以指定一个块配置来当作检测条件,默认是以响应码为2XX或3XX时代表上游服务器是可用的;

很不幸的是health_check这个指令只是在商业版中可使用的(http://stackoverflow.com/questions/30347425/nginx-unknown-directive-health-check

例如:

location / {

    proxy_pass http://backend;

    health_check;

}

这里的health_check全部采用了默认参数,即表示每5秒对backed定义的各个服务器的主页页面进行探测,如果返回的http代码为2XX或3XX,刚表示此服务器是可用的,否则认为此服务器是不健康的,客户端的请求将不会转发给此不健康的服务器。

Syntax: ip_hash;

Default: —

Context: upstream

ip_hash能实现把来自同一IP地址的客户端转发到同一台上游服务器上,它以客户端的IP取出进行hash计算,再与上游服务器的数量做取模运算,得到的结果就是需要转发到的服务器。这种以IP为粒度的算法比较粗糙,有反负载的表现。

Syntax: least_conn;

Default: —

Context: upstream

This directive appeared in versions 1.3.1 and 1.2.2.

每次将请求转发到当前活动连接数最少的上游服务器(考虑web服务器权重),如果有许多这样的服务器,将会使用带权重的round-robin算法。

对于对upstream模块的介绍,这里推荐一篇译文,http://blog.csdn.net/defonds/article/details/13003121

本文出自 “专注运维,与Linux共舞” 博客,请务必保留此出处http://zhaochj.blog.51cto.com/368705/1653723

nginx的proxy模块及upstream模块介绍

标签:nginx proxy upstream

原文地址:http://zhaochj.blog.51cto.com/368705/1653723

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!