Nginx的相关介绍

前言

说到服务器，一定会想到apache的httpd和Nginx

Apache的发展时期很长，而且是毫无争议的世界第一大服务器。它有着很多优点：稳定、开源、跨平台等等。它出现的时间太长了，它兴起的年代，互联网产业远远比不上现在。所以它被设计为一个重量级的。它不支持高并发的服务器。在Apache上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源，导致HTTP请求的平均响应速度降低。

这些都决定了Apache不可能成为高性能WEB服务器，轻量级高并发服务器Nginx就应运而生了。

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：Рамблер）开发的，第一个公开版本0.1.0发布于2004年10月4日。

由于：

• Nginx使用基于事件驱动架构，使得其可以支持数以百万级别的TCP连接
• 高度的模块化和自由软件许可证使得第三方模块层出不穷（这是个开源的时代啊~）
• Nginx是一个跨平台服务器，可以运行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等操作系统上
• 这些优秀的设计带来的是极大的稳定性

所以，Nginx火了！

Nginx用武之地

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

关于代理

说到代理，首先我们要明确一个概念，所谓代理就是一个代表、一个渠道；

此时就涉及到两个角色，一个是被代理角色，一个是目标角色，被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程；

举个栗子：如同生活中的专卖店~客人到adidas专卖店买了一双鞋，这个专卖店就是代理，被代理角色就是adidas厂家，目标角色就是用户。

透明代理

透明代理看名字就知道这个代理服务器是透明的，透明代理其实也叫做内网代理(inline proxy)、拦截代理(intercepting proxy)以及强制代理(force proxy)。透明代理和正向代理的行为很相似，但细节上有所不同。透明代理将拦截客户端发送的请求，拦截后自己代为访问服务端，获取响应结果后再由透明代理交给客户端。一般公司内的上网行为管理软件就是透明代理。

正向代理

说反向代理之前，我们先看看正向代理，正向代理也是大家最常接触的到的代理模式，我们会从两个方面来说关于正向代理的处理模式，分别从软件方面和生活方面来解释一下什么叫正向代理。

在如今的网络环境下，我们如果由于技术需要要去访问国外的某些网站，此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的，此时大家可能都会用一个操作FQ进行访问，FQ的方式主要是找到一个可以访问国外网站的代理服务器，我们将请求发送给代理服务器，代理服务器去访问国外的网站，然后将访问到的数据传递给我们！

上述这样的代理模式称为正向代理，正向代理最大的特点是客户端非常明确要访问的服务器地址；服务器只清楚请求来自哪个代理服务器，而不清楚来自哪个具体的客户端；正向代理模式屏蔽或者隐藏了真实客户端信息。来看个示意图（我把客户端和正向代理框在一块，同属于一个环境，后面我有介绍）：

客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。

总结来说：

正向代理，"它代理的是客户端，代客户端发出请求"，是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。

正向代理的用途：
（1）访问原来无法访问的资源，如Google
（2） 可以做缓存，加速访问资源
（3）对客户端访问授权，上网进行认证
（4）代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

反向代理

明白了什么是正向代理，我们继续看关于反向代理的处理方式，举例如我大天朝的某宝网站，每天同时连接到网站的访问人数已经爆表，单个服务器远远不能满足人民日益增长的购买欲望了，此时就出现了一个大家耳熟能详的名词：分布式部署；也就是通过部署多台服务器来解决访问人数限制的问题；某宝网站中大部分功能也是直接使用Nginx进行反向代理实现的，并且通过封装Nginx和其他的组件之后起了个高大上的名字：Tengine，有兴趣的童鞋可以访问Tengine的官网查看具体的信息：http://tengine.taobao.org/。那么反向代理具体是通过什么样的方式实现的分布式的集群操作呢，我们先看一个示意图（我把服务器和反向代理框在一块，同属于一个环境，后面我有介绍）：

通过上述的图解大家就可以看清楚了，多个客户端给服务器发送的请求，Nginx服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，Nginx扮演的就是一个反向代理角色。

客户端是无感知代理的存在的，反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。

反向代理，"它代理的是服务端，代服务端接收请求"，主要用于服务器集群分布式部署的情况下，反向代理隐藏了服务器的信息。

反向代理的作用：
（1）保证内网的安全，通常将反向代理作为公网访问地址，Web服务器是内网
（2）负载均衡，通过反向代理服务器来优化网站的负载

项目场景

通常情况下，我们在实际项目操作时，正向代理和反向代理很有可能会存在在一个应用场景中，正向代理代理客户端的请求去访问目标服务器，目标服务器是一个反向单利服务器，反向代理了多台真实的业务处理服务器。具体的拓扑图如下：

二者区别

截了一张图来说明正向代理和反向代理二者之间的区别，如图。

图解：

正反向代理，主要是从代理服务器来看

正向代理：代理服务器代理的是客户端，逻辑服务器只会收到代理服务器的请求，客户端对于逻辑服务器来说是透明的

反向代理：代理服务器的是逻辑服务器，客户端只会请求代理服务器，逻辑服务器对于客户端来说是透明的

实际上，Proxy在两种代理中做的事情都是替服务器代为收发请求和响应，不过从结构上看正好左右互换了一下，所以把后出现的那种代理方式称为反向代理了。

负载均衡

我们已经明确了所谓代理服务器的概念，那么接下来，Nginx扮演了反向代理服务器的角色，它是以依据什么样的规则进行请求分发的呢？不用的项目应用场景，分发的规则是否可以控制呢？

这里提到的客户端发送的、Nginx反向代理服务器接收到的请求数量，就是我们说的负载量。

请求数量按照一定的规则进行分发到不同的服务器处理的规则，就是一种均衡规则。

所以~将服务器接收到的请求按照规则分发的过程，称为负载均衡。

负载均衡在实际项目操作过程中，有硬件负载均衡和软件负载均衡两种，硬件负载均衡也称为硬负载，如F5负载均衡，相对造价昂贵成本较高，但是数据的稳定性安全性等等有非常好的保障，如中国移动中国联通这样的公司才会选择硬负载进行操作；更多的公司考虑到成本原因，会选择使用软件负载均衡，软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制。

Nginx支持的负载均衡调度算法方式如下：

1. weight轮询(默认，常用)：接收到的请求按照权重分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，Nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值(weight)，用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
2. ip_hash（常用）：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。
3. fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是Nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块。
4. url_hash：按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在Nginx作为静态服务器的情况下提高缓存效率。同样要注意Nginx默认不支持这种调度算法，要使用的话需要安装Nginx的hash软件包。

几种常用web服务器对比

Nginx的反响代理配置

打开conf下的nginx.conf文件

#这个是需要转发的目标服务器地址以及端口号
#upstream:模块 不允许修改
#mynginx：名称 可修改，我使用带有“_”的符号名字，会报400，原因不知。
upstream mynginx{
    #server xxxx:x： 写监听的域名或者ip
    server 192.168.10.1:8668 down;    //down表示当前服务器不参与负载均衡
    server localhost:8080;    //负载均衡服务器逻辑服务器
    server x.x.x.x:8080 weight=5;    //weight=数字 代表的权重比例(默认)
    server x.x.x.x:8080 backup;    //backup 热备当上面监听的服务器都挂掉了，就由热备的提供服务
}
 
server {
    listen 80;
    server_name  localhost;
    index  index.html index.htm index.php;
 
    ## send request back to apache ##
    location / {
　　　　 #mynginx需要转发请求的服务器的集群
        #使用负载均衡的服务器
        proxy_pass  http://mynginx;    
 
        #Proxy Settings
        proxy_redirect     off;#是否跳转
        proxy_set_header   Host             $host; #请求要转发的host
        proxy_set_header   X-Real-IP        $remote_addr;#请求的远程地址    这些在浏览器的header都可看，不一一解释
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        proxy_max_temp_file_size 0;
        proxy_connect_timeout      90; #连接前面的服务器超时时间
        proxy_send_timeout         90;#请求转发数据报文的超时时间
        proxy_read_timeout         90;#读取超时时间
        proxy_buffer_size          4k; # 缓冲区的大小
        proxy_buffers              4 32k; #
        proxy_busy_buffers_size    64k; # #proxy_buffers缓冲区，网页平均在32k以下的
        proxy_temp_file_write_size 64k; ##高负荷下缓冲大小（proxy_buffers*2）
   }
}

upstream配置

在http配置下增加upstream配置即可：

upstream nodes {
    server 192.168.10.1:8668;
    server 192.168.10.2:8668;
}

upstream对配置的上游服务器按照默认的轮询方式进行请求。如果上游服务器挂掉，能自己主动剔除，无需手动干预。这种方式简单快捷。但是如果上游服务器在配置不均衡的情况下，是解决不了的。所以nginx有其他很多的配置项。下面就一一介绍一下。

权重配置：

weight和请求数量成正比，主要用于上游服务器配置不均衡的情况。下面的配置中，192.168.10.2机器的请求量是192.168.10.1机器请求量的2倍。

upstream nodes {
    server 192.168.10.1:8668 weight=5;
    server 192.168.10.2:8668 weight=10;
}

ip_hash配置

每一个请求按照请求的ip的hash结果分配。这样每一个请求固定落在一个上游服务器，能够解决ip会话在同一台服务器的问题。

upstream nodes {
    ip_hash;
    server 192.168.10.1:8668;
    server 192.168.10.2:8668;
}

fair配置

按上游服务器的响应时间来分配请求。响应时间短的优先分配。

upstream nodes {
    server 192.168.10.1:8668;
    server 192.168.10.2:8668;
    fair;
}

url_hash配置

按照访问的url的hash结果来分配请求，使每一个url定向到同一个上游服务器。注意：在upstream中加入hash语句。server语句中不能写入weight等其他的參数，hash_method是使用的hash算法。

upstream nodes {
    server 192.168.10.1:8668;
    server 192.168.10.2:8668;
    hash $request_uri;
    hash_method crc32;
}

---

[参考：https://www.cnblogs.com/wcwnina/p/8728391.html]

[参考：https://baijiahao.baidu.com/s?id=1612046399354825956&wfr=spider&for=pc]