一、Nginx的产生
没有听过Nginx?那么一定听过它的"同行"Apache吧!Nginx同Apache一样都是一种WEB服务器。基于REST架构风格,以统一资源描述符(Uniform Resources Identifier)URI或者统一资源定位符(Uniform Resources Locator)URL作为沟通依据,通过HTTP协议提供各种网络服务。
然而,这些服务器在设计之初受到当时环境的局限,例如当时的用户规模,网络带宽,产品特点等局限并且各自的定位和发展都不尽相同。这也使得各个WEB服务器有着各自鲜明的特点。
Apache的发展时期很长,而且是毫无争议的世界第一大服务器。它有着很多优点:稳定、开源、跨平台等等。它出现的时间太长了,它兴起的年代,互联网产业远远比不上现在。所以它被设计为一个重量级的。它不支持高并发的服务器。在Apache上运行数以万计的并发访问,会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源,导致HTTP请求的平均响应速度降低。
这些都决定了Apache不可能成为高性能WEB服务器,轻量级高并发服务器Nginx就应运而生了。
俄罗斯的工程师Igor Sysoev,他在为Rambler Media工作期间,使用C语言开发了Nginx。Nginx作为WEB服务器一直为Rambler Media提供出色而又稳定的服务。
然后呢,Igor Sysoev将Nginx代码开源,并且赋予自由软件许可证。
由于:
Nginx使用基于事件驱动架构,使得其可以支持数以百万级别的TCP连接
高度的模块化和自由软件许可证使得第三方模块层出不穷(这是个开源的时代啊~)
Nginx是一个跨平台服务器,可以运行在Linux,Windows,FreeBSD,Solaris, AIX,Mac OS等操作系统上
这些优秀的设计带来的极大的稳定性
所以,Nginx火了!
二、Nginx的用武之地
Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器;同时也是一个IMAP、POP3、SMTP代理服务器;Nginx可以作为一个HTTP服务器进行网站的发布处理,另外Nginx可以作为反向代理进行负载均衡的实现。
三、关于代理
说到代理,首先我们要明确一个概念,所谓代理就是一个代表、一个渠道;
此时就涉及到两个角色,一个是被代理角色,一个是目标角色,被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程;如同生活中的专卖店~客人到adidas专卖店买了一双鞋,这个专卖店就是代理,被代理角色就是adidas厂家,目标角色就是用户。
正向代理
说反向代理之前,我们先看看正向代理,正向代理也是大家最常接触的到的代理模式,我们会从两个方面来说关于正向代理的处理模式,分别从软件方面和生活方面来解释一下什么叫正向代理。
在如今的网络环境下,我们如果由于技术需要要去访问国外的某些网站,此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的,此时大家可能都会用一个操作FQ进行访问,FQ的方式主要是找到一个可以访问国外网站的代理服务器,我们将请求发送给代理服务器,代理服务器去访问国外的网站,然后将访问到的数据传递给我们!
上述这样的代理模式称为正向代理,正向代理最大的特点是客户端非常明确要访问的服务器地址;服务器只清楚请求来自哪个代理服务器,而不清楚来自哪个具体的客户端;正向代理模式屏蔽或者隐藏了真实客户端信息。来看个示意图(我把客户端和正向代理框在一块,同属于一个环境,后面我有介绍):
总结来说:正向代理,“它代理的是客户端,代客户端发出请求”,是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。
正向代理的用途:
(1)访问原来无法访问的资源,如Google
(2) 可以做缓存,加速访问资源
(3)对客户端访问授权,上网进行认证
(4)代理可以记录用户访问记录(上网行为管理),对外隐藏用户信息
反向代理
明白了什么是正向代理,我们继续看关于反向代理的处理方式,举例如我大天朝的某宝网站,每天同时连接到网站的访问人数已经爆表,单个服务器远远不能满足人民日益增长的购买欲望了,此时就出现了一个大家耳熟能详的名词:分布式部署;也就是通过部署多台服务器来解决访问人数限制的问题;某宝网站中大部分功能也是直接使用Nginx进行反向代理实现的,并且通过封装Nginx和其他的组件之后起了个高大上的名字:Tengine,有兴趣的童鞋可以访问Tengine的官网查看具体的信息:http://tengine.taobao.org 。那么反向代理具体是通过什么样的方式实现的分布式的集群操作呢,我们先看一个示意图(我把服务器和反向代理框在一块,同属于一个环境,后面我有介绍):
通过上述的图解大家就可以看清楚了,多个客户端给服务器发送的请求,Nginx服务器接收到之后,按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的,但是请求具体由哪台服务器处理的并不明确了,Nginx扮演的就是一个反向代理角色。
客户端是无感知代理的存在的,反向代理对外都是透明的,访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。
反向代理,“它代理的是服务端,代服务端接收请求”,主要用于服务器集群分布式部署的情况下,反向代理隐藏了服务器的信息。
反向代理的作用:
(1)保证内网的安全,通常将反向代理作为公网访问地址,Web服务器是内网
(2)负载均衡,通过反向代理服务器来优化网站的负载
项目场景
通常情况下,我们在实际项目操作时,正向代理和反向代理很有可能会存在在一个应用场景中,正向代理代理客户端的请求去访问目标服务器,目标服务器是一个反向单利服务器,反向代理了多台真实的业务处理服务器。具体的拓扑图如下:
四、正向代理和反向代理的区别
正向代理和反向代理的区别我在知乎上找到两张图可以帮助我们很好的理解:
正向代理:客户端 <一> 代理 一>服务端
正向代理简单地打个租房的比方:
A(客户端)想租C(服务端)的房子,但是A(客户端)并不认识C(服务端)租不到。
B(代理)认识C(服务端)能租这个房子所以你找了B(代理)帮忙租到了这个房子。
这个过程中C(服务端)不认识A(客户端)只认识B(代理)
C(服务端)并不知道A(客户端)租了房子,只知道房子租给了B(代理)。
反向代理:客户端 一>代理 <一> 服务端
反向代理也用一个租房的例子:
A(客户端)想租一个房子,B(代理)就把这个房子租给了他。
这时候实际上C(服务端)才是房东。
B(代理)是中介把这个房子租给了A(客户端)。
这个过程中A(客户端)并不知道这个房子到底谁才是房东
他都有可能认为这个房子就是B(代理)的
由上的例子和图我们可以知道正向代理和反向代理的区别在于代理的对象不一样,正向代理的代理对象是客户端,反向代理的代理对象是服务端。
五、负载均衡
我们已经明确了所谓代理服务器的概念,那么接下来,Nginx扮演了反向代理服务器的角色,它是以依据什么样的规则进行请求分发的呢?不用的项目应用场景,分发的规则是否可以控制呢?
这里提到的客户端发送的、Nginx反向代理服务器接收到的请求数量,就是我们说的负载量。
请求数量按照一定的规则进行分发到不同的服务器处理的规则,就是一种均衡规则。
所以,将服务器接收到的请求按照规则分发的过程,称为负载均衡。
负载均衡在实际项目操作过程中,有硬件负载均衡和软件负载均衡两种,硬件负载均衡也称为硬负载,如F5负载均衡,相对造价昂贵成本较高,但是数据的稳定性安全性等等有非常好的保障,如中国移动中国联通这样的公司才会选择硬负载进行操作;更多的公司考虑到成本原因,会选择使用软件负载均衡,软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制。
Nginx支持的负载均衡调度算法方式如下:
weight轮询(默认,常用):接收到的请求按照权重分配到不同的后端服务器,即使在使用过程中,某一台后端服务器宕机,Nginx会自动将该服务器剔除出队列,请求受理情况不会受到任何影响。 这种方式下,可以给不同的后端服务器设置一个权重值(weight),用于调整不同的服务器上请求的分配率;权重数据越大,被分配到请求的几率越大;该权重值,主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
ip_hash(常用):每个请求按照发起客户端的ip的hash结果进行匹配,这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器,这也在一定程度上解决了集群部署环境下session共享的问题。
fair:智能调整调度算法,动态的根据后端服务器的请求处理到响应的时间进行均衡分配,响应时间短处理效率高的服务器分配到请求的概率高,响应时间长处理效率低的服务器分配到的请求少;结合了前两者的优点的一种调度算法。但是需要注意的是Nginx默认不支持fair算法,如果要使用这种调度算法,请安装upstream_fair模块。
url_hash:按照访问的url的hash结果分配请求,每个请求的url会指向后端固定的某个服务器,可以在Nginx作为静态服务器的情况下提高缓存效率。同样要注意Nginx默认不支持这种调度算法,要使用的话需要安装Nginx的hash软件包。
六、几种常用web服务器对比
对比项/服务器 | Apache | Nginx | Lighttpd |
---|---|---|---|
Proxy代理 | 非常好 | 非常好 | 一般 |
Rewriter | 好 | 非常好 | 一般 |
Fcgi | 不好 | 好 | 非常好 |
热部署 | 不支持 | 支持 | 不支持 |
系统压力 | 很大 | 很小 | 比较小 |
稳定性 | 好 | 非常好 | 不好 |
安全性 | 好 | 一般 | 一般 |
静态文件处理 | 一般 | 非常好 | 好 |
反向代理 | 一般 | 非常好 | 一般 |
七、Nginx代理的配置演示
1、正向代理配置场景演示
正向代理很常见,我们的科学上网就是一种正向代理。
我们接下来演示正向代理的这么一个场景。
首先我在我的A服务器的nginx设置访问控制
访问控制之前我访问A下的test.html是这样的:
我们打开/etc/nginx/conf.d/default.conf
我们加入这么一个判断语句
如果访问A的IP不是118.126.106.11(我的B服务器)则返回403.
location / {
if ( $remote_addr !~* "^118\.126\.106\.11") {
return 403;
}
root /opt/app/demo/html;
index index.html index.htm;
}
添加后reload一下nginx再访问test.html:
此时本地我的浏览器就是被限制了,访问不了该资源。
现在我登录上我的B服务器,打开/etc/nginx/conf.d/default.conf
添加resolver和proxy_pass,设置如下:
server {
listen 80;
server_name localhost nginx.tangll.cn;
resolver 8.8.8.8;
location / {
proxy_pass http://$http_host$request_uri;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
resolver为DNS解析,这里填写的IP为Google提供的免费DNS服务器的IP地址
proxy_pass配置代理转发
至此便是配置了B服务器所有访问根一级的请求全部都代理转发对应到request_uri去了,request_uri就是我们后面所加的参数。
简单的说至此就是相当于配置好了我们请求了B服务器,B服务器再去请求我们所请求的地址。
那么接下来我们来看一下结果,我们在本地配置好代理,我这里是mac系统,可以从网络设置中选择高级,然后选择代理
填入我们B服务器的IP,然后我们来看一下代理是否成功。
我们登录http://www.ip138.com/ 可以看到此时我们的IP地址已经为B服务器的IP,说明代理成功。
然后我们再来访问一下test.html:
结果证明,此时的客户端已经可以成功访问A服务器的资源。
以上就是正向代理的一个场景演示,这个过程中可以知道,我们客户端是想要A的资源,但是A的资源只有B能拿到,便让B代理去帮助我们访问A的资源。整个过程A只知道B拿了他的资源,并不知道客户端拿到。
2、反向代理配置场景演示
反向代理的演示更为简单一些。
首先在/etc/nginx/conf.d/下新建一个test.conf:
server {
listen 8080;
server_name localhost nginx.tangll.cn;
location / {
root /opt/app/demo/html;
index index.html index.htm;
}
error_page 500 502 503 504 404 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
可以看到我server里listen的是8080端口,但是我的服务器本身不对外开放8080端口,只开放了80端口。
所以我们此时访问test.html结果是访问不到的:
然后我们打开我们的/etc/nginx/conf.d/default.conf
添加proxy_pass设置如下:
server {
listen 80;
server_name localhost nginx.tangll.cn;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
#设置代理
location ~ /test.html$ {
proxy_pass http://127.0.0.1:8080;
}
error_page 500 502 503 504 404 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
我们设置当匹配test.html结尾的URL时就去代理访问本机的8080端口
为了对比我们先注释掉,然后直接80端口访问一下test.html:
可以看到此时返回的404。
这时候取消注释我们reload一下nginx然后用80端口访问test.html
此时便可访问8080端口配置的资源。
以上便是完成了一个反向代理的演示,这个过程中我们可以知道,客户端想要访问的是test.html,但是test.html实际上是8080端口下配置的,中间经过了代理才能拿到。也就是说客户端并不知道中间经历了什么代理过程,只有服务端知道。客户端只知道他拿到了test.html也就是8080端口下配置的资源内容。
八、总结
由上的打比方和演示例子可以体会到正向代理与反向代理的区别和Nginx正向代理和反向代理的简单配置。正向代理和反向代理的区别上边也说过在于代理的对象不一样,正向代理的代理对象是客户端,反向代理的代理对象是服务端。
最后一句话总结此文就是
代理服务器站在客户端那边就是正向代理,
代理服务器站在原始服务器那边就是反向代理,
Nginx通过proxy_pass可以设置代理服务。
九、 negix转发常用配置
server {
listen 80;
server_name *.yourdomain.com;
....
}
代理转发是在server下面的location进行配置
server {
// 服务器配置
location / {
// ...... 代理配置
}
}
常见的Nginx代理配置
upstream my_server {
server 10.0.0.2:8080;
keepalive 2000;
}
server {
listen 80;
server_name 10.0.0.1;
client_max_body_size 1024M;
location /my/ {
proxy_pass http://my_server/;
proxy_set_header Host $host:$server_port;
}
}
通过该配置,访问nginx地址http://10.0.0.1:80/my的请求会被转发到my_server服务地址http://10.0.0.2:8080/
需要注意的是,如果按照如下配置:
upstream my_server {
server 10.0.0.2:8080;
keepalive 2000;
}
server {
listen 80;
server_name 10.0.0.1;
client_max_body_size 1024M;
location /my/ {
proxy_pass http://my_server;
proxy_set_header Host $host:$server_port;
}
}
那么,访问nginx地址http://10.0.0.1:80/my的请求会被转发到my_server服务地址http://10.0.0.2:8080/my。这是因为proxy_pass参数中如果不包含url的路径,则会将location的pattern识别的路径作为绝对路径。
评论区