nginx使用场景面试（为什么要用nginx来做反向代理）

本文目录

• 为什么要用nginx来做反向代理
• 面试官：请问Nginx为什么比Apache性能好
• nginx是干嘛用的
• 跟我学Nginx，nginx 如何处理请求
• Nginx基础篇----虚拟主机、日志、模块、请求限制

为什么要用nginx来做反向代理

　　nginx 这个轻量级、高性能的 web server 主要可以干两件事情：
***隐藏网址***
　　〉另外一个功能就是作为反向代理服务器实现负载均衡
　　以下我们就来举例说明如何使用 nginx 实现负载均衡。因为nginx在处理并发方面的优势，现在这个应用非常常见。当然了Apache的 mod_proxy和mod_cache结合使用也可以实现对多台app server的反向代理和负载均衡，但是在并发处理方面apache还是没有 nginx擅长。
　　1)环境：
　　a. 我们本地是Windows系统，然后使用VirutalBox安装一个虚拟的Linux系统。
　　在本地的Windows系统上分别安装nginx(侦听8080端口)和apache(侦听80端口)。在虚拟的Linux系统上安装apache(侦听80端口)。
　　这样我们相当于拥有了1台nginx在前端作为反向代理服务器；后面有2台apache作为应用程序服务器(可以看作是小型的server cluster。;-) )；
　　b. nginx用来作为反向代理服务器，放置到两台apache之前，作为用户访问的入口；
　　nginx仅仅处理静态页面，动态的页面(php请求)统统都交付给后台的两台apache来处理。
　　也就是说，可以把我们网站的静态页面或者文件放置到nginx的目录下；动态的页面和数据库访问都保留到后台的apache服务器上。
　　c. 如下介绍两种方法实现server cluster的负载均衡。
　　我们假设前端nginx(为127.0.0.1:80)仅仅包含一个静态页面index.html；
　　后台的两个apache服务器(分别为localhost:80和158.37.70.143:80)，一台根目录放置phpMyAdmin文件夹和test.php(里面测试代码为print “server1“;)，另一台根目录仅仅放置一个test.php(里面测试代码为 print “server2“;)。
　　2)针对不同请求 的负载均衡：
　　a. 在最简单地构建反向代理的时候 (nginx仅仅处理静态不处理动态内容，动态内容交给后台的apache server来处理)，我们具体的设置为：在nginx.conf中修改：
　　复制代码 代码如下:
　　location ~ \.php$ {
　　proxy_pass 158.37.70.143:80 ;
　　}
　　〉 这样当客户端访问localhost:8080/index.html的时候，前端的nginx会自动进行响应；
***隐藏网址***
　　如上是最为简单的使用nginx做为反向代理服务器的例子；
　　b. 我们现在对如上例子进行扩展，使其支持如上的两台服务器。
　　我们设置nginx.conf的server模块部分，将对应部分修改为：
　　复制代码 代码如下:
　　location ^~ /phpMyAdmin/ {
　　proxy_pass 127.0.0.1:80 ;
　　}
　　location ~ \.php$ {
　　proxy_pass 158.37.70.143:80 ;
　　}
***隐藏网址***
***隐藏网址***
　　因此综上，我们实现了针对不同请求的负载均衡。
　　〉如果用户访问静态页面index.html，最前端的nginx直接进行响应；
　　〉如果用户访问test.php页面的话，158.37.70.143:80 的Apache进行响应；
　　〉如果用户访问目录phpMyAdmin下的页面的话，127.0.0.1:80 的Apache进行响应；
　　3)访问同一页面 的负载均衡：
***隐藏网址***
　　a. 现在我们的情况是在windows下nginx是localhost侦听8080端口；
　　两台apache，一台是127.0.0.1:80(包含test.php页面但是打印server1)，另一台是虚拟机的158.37.70.143:80(包含test.php页面但是打印server2)。
　　b. 因此重新配置nginx.conf为：
***隐藏网址***
　　复制代码 代码如下:
　　upstream myCluster {
　　server 127.0.0.1:80 ;
　　server 158.37.70.143:80 ;
　　}
　　表示这个server cluster包含2台服务器
　　〉然后在server模块中定义，负载均衡：
　　复制代码 代码如下:
　　location ~ \.php$ {
***隐藏网址***
　　proxy_redirect off;
　　proxy_set_header Host $host;
　　proxy_set_header X-Real-IP $remote_addr;
　　proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
　　}
***隐藏网址***
　　上面在定义upstream的时候每个server之后没有定义权重，表示两者均衡；如果希望某个更多响应的话例如：
　　复制代码 代码如下:
　　upstream myCluster {
　　server 127.0.0.1:80 weight=5;
　　server 158.37.70.143:80 ;
　　}
　　这样表示5/6的几率访问第一个server,1/6访问第二个。另外还可以定义max_fails和fail_timeout等参数。
　　综上，我们使用nginx的反向代理服务器reverse proxy server的功能，将其布置到多台apache server的前端。
　　nginx仅仅用来处理静态页面响应和动态请求的代理pass，后台的apache server作为app server来对前台pass过来的动态页面进行处理并返回给nginx。
　　通过以上的架构，我们可以实现nginx和多台apache构成的机群cluster的负载均衡。
　　两种均衡：
　　1)可以在nginx中定义访问不同的内容，代理到不同的后台server； 如上例子中的访问phpMyAdmin目录代理到第一台server上；访问test.php代理到第二台server上；
　　2)可以在nginx中定义访问同一页面，均衡 (当然如果服务器性能不同可以定义权重来均衡)地代理到不同的后台server上。 如上的例子访问test.php页面，会均衡地代理到server1或者server2上。
　　实际应用中，server1和server2上分别保留相同的app程序和数据，需要考虑两者的数据同步。

面试官：请问Nginx为什么比Apache性能好

***隐藏网址***

进程是具有一定独立功能的，在计算机中已经运行的程序的实体。在早期系统中（如linux 2.4以前），进程是基本运作单位，在支持线程的系统中（如windows，linux2.6）中，线程才是基本的运作单位，而进程只是线程的容器。程序本身只是指令、数据及其组织形式的描述，进程才是程序（那些指令和数据）的真正运行实例。若干进程有可能与同一个程序相关系，且每个进程皆可以同步（循序）或异步（平行）的方式独立运行。现代计算机系统可在同一段时间内以进程的形式将多个程序加载到存储器中，并借由时间共享（或称时分复用），以在一个处理器上表现出同时（平行性）运行的感觉。同样的，使用多线程技术（多线程即每一个线程都代表一个进程内的一个独立执行上下文）的操作系统或计算机架构，同样程序的平行线程，可在多 CPU 主机或网络上真正同时运行（在不同的CPU上）。

Web服务器要为用户提供服务，必须以某种方式，工作在某个套接字上。一般Web服务器在处理用户请求是，一般有如下三种方式可选择：多进程方式、多线程方式、异步方式。Web服务器要为用户提供服务，必须以某种方式，工作在某个套接字上。一般Web服务器在处理用户请求是，一般有如下三种方式可选择：多进程方式、多线程方式、异步方式。多进程方式：为每个请求启动一个进程来处理。由于在操作系统中，生成进程、销毁进程、进程间切换都很消耗CPU和内存，当负载高是，性能会明显降低。优点： 稳定性！由于采用独立进程处理独立请求，而进程之间是独立的，单个进程问题不会影响其他进程，因此稳定性最好。缺点： 资源占用！当请求过大时，需要大量的进程处理请求，进程生成、切换开销很大，而且进程间资源是独立的，造成内存重复利用。多线程方式：一个进程中用多个线程处理用户请求。由于线程开销明显小于进程，而且部分资源还可以共享，因此效率较高。优点：开销较小！线程间部分数据是共享的，且线程生成与线程间的切换所需资源开销比进程间切换小得多。缺点：稳定性！线程切换过快可能造成线程抖动，且线程过多会造成服务器不稳定。异步方式：使用非阻塞方式处理请求，是三种方式中开销最小的。但异步方式虽然效率高，但要求也高，因为多任务之间的调度如果出现问题，就可能出现整体故障，因此使用异步工作的，一般是一些功能相对简单，但却符合服务器任务调度、且代码中没有影响调度的错误代码存在的程序。优点：性能最好！一个进程或线程处理多个请求，不需要额外开销，性能最好，资源占用最低。缺点：稳定性！某个进程或线程出错，可能导致大量请求无法处理，甚至导致整个服务宕机。

通过这样的一个复杂过程，一次请求就完成了。简单来说就是：用户请求--》送达到用户空间--》系统调用--》内核空间--》内核到磁盘上读取网页资源-》返回到用户空间-》响应给用户。上述简单的说明了一下，客户端向Web服务请求过程，在这个过程中，有两个I/O过程，一个就是客户端请求的网络I/O，另一个就是Web服务器请求页面的磁盘I/O。 下面我们就来说说Linux的I/O模型。

通过上面的对连接的处理分析，我们知道工作在用户空间的web服务器进程是无法直接操作IO的，需要通过系统调用进行，其关系如下：

即进程向内核进行系统调用申请IO，内核将资源从IO调度到内核的buffer中（wait阶段），内核还需将数据从内核buffer中复制（copy阶段）到web服务器进程所在的用户空间，才算完成一次IO调度。这几个阶段都是需要时间的。根据wait和copy阶段的处理等待的机制不同，可将I/O动作分为如下五种模式：

这里有必要先解释一下阻塞、非阻塞，同步、异步、I/O的概念。

阻塞和非阻塞指的是执行一个操作是等操作结束再返回，还是马上返回。比如餐馆的服务员为用户点菜，当有用户点完菜后，服务员将菜单给后台厨师，此时有两种方式：第一种：就在出菜窗口等待，直到厨师炒完菜后将菜送到窗口，然后服务员再将菜送到用户手中；第二种：等一会再到窗口来问厨师，某个菜好了没？如果没有先处理其他事情，等会再去问一次；第一种就是阻塞方式，第二种则是非阻塞的。

同步和异步又是另外一个概念，它是事件本身的一个属性。还拿前面点菜为例，服务员直接跟厨师打交道，菜出来没出来，服务员直接指导，但只有当厨师将菜送到服务员手上，这个过程才算正常完成，这就是同步的事件。同样是点菜，有些餐馆有专门的传菜人员，当厨师炒好菜后，传菜员将菜送到传菜窗口，并通知服务员，这就变成异步的了。其实异步还可以分为两种：带通知的和不带通知的。前面说的那种属于带通知的。有些传菜员干活可能主动性不是很够，不会主动通知你，你就需要时不时的去关注一下状态。这种就是不带通知的异步。对于同步的事件，你只能以阻塞的方式去做。而对于异步的事件，阻塞和非阻塞都是可以的。非阻塞又有两种方式：主动查询和被动接收消息。被动不意味着一定不好，在这里它恰恰是效率更高的，因为在主动查询里绝大部分的查询是在做无用功。对于带通知的异步事件，两者皆可。而对于不带通知的，则只能用主动查询。

回到I/O，不管是I还是O，对外设(磁盘)的访问都可以分成请求和执行两个阶段。请求就是看外设的状态信息（比如是否准备好了），执行才是真正的I/O操作。在Linux 2.6之前，只有“请求”是异步事件，2.6之后才引入AIO（asynchronous I/O ）把“执行”异步化。别看Linux/Unix是用来做服务器的，这点上比Windows落后了好多，IOCP（Windows上的AIO，效率极高）在Win2000上就有了。所以学linux的别老觉得Windows这里不好那里不好（Windows的多线程机制也由于linux）。

根据以上分析，I/O可分为五种模型：

Linux上的前四种I/O模型的“执行”阶段都是同步的，只有最后一种才做到了真正的全异步。第一种阻塞式是最原始的方法，也是最累的办法。当然累与不累要看针对谁。应用程序是和内核打交道的。对应用程序来说，这种方式是最累的，但对内核来说这种方式恰恰是最省事的。还拿点菜这事为例，你就是应用程序，厨师就是内核，如果你去了一直等着，厨师就省事了（不用同时处理其他服务员的菜）。当然现在计算机的设计，包括操作系统，越来越为终端用户考虑了，为了让用户满意，内核慢慢的承担起越来越多的工作，IO模型的演化也是如此。非阻塞I/O ，I/O复用，信号驱动式I/O其实都是非阻塞的，当然是针对“请求”这个阶段。非阻塞式是主动查询外设状态。I/O复用里的select，poll也是主动查询，不同的是select和poll可以同时查询多个fd（文件句柄）的状态，另外select有fd个数的限制。epoll是基于回调函数的。信号驱动式I/O则是基于信号消息的。这两个应该可以归到“被动接收消息”那一类中。最后就是伟大的AIO的出现，内核把什么事都干了，对上层应用实现了全异步，性能最好，当然复杂度也最高。

说明：应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。 如果数据没有准备好，一直等待数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示。这个不用多解释吧，阻塞套接字。下图是它调用过程的图示：（注，一般网络I/O都是阻塞I/O，客户端发出请求，Web服务器进程响应，在进程没有返回页面之前，这个请求会处于一直等待状态）

我们把一个套接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间，所有一般Web服务器都不使用这种I/O模型。具体过程如下图:

I/O复用模型会用到select或poll函数或epoll函数(Linux2.6以后的内核开始支持)，这两个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。具体过程如下图:

首先，我们允许套接口进行信号驱动I/O，并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。具体过程如下图:

当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者的输入输出操作。具体过程如下图:

从上图中我们可以看出，可以看出，越往后，阻塞越少，理论上效率也是最优。其五种I/O模型中，前三种属于同步I/O，后两者属于异步I/O。

同步I/O:

异步I/O:

异步 I/O 和 信号驱动I/O的区别:

注，其中iocp是Windows实现的，select、poll、epoll是Linux实现的，kqueue是FreeBSD实现的，/dev/poll是SUN的Solaris实现的。select、poll对应第3种（I/O复用）模型，iocp对应第5种（异步I/O）模型，那么epoll、kqueue、/dev/poll呢？其实也同select属于同一种模型，只是更高级一些，可以看作有了第4种（信号驱动I/O）模型的某些特性，如callback机制。

答案是，他们无轮询。因为他们用callback取代了。想想看，当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll、kqueue、/dev/poll做的。这样子说可能不好理解，那么我说一个现实中的例子，假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select、epoll、/dev/poll的性能谁的性能更高，同样十分明了。

诚然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系统，但是由于其系统本身的局限性，大型服务器还是在UNIX下。而且正如上面所述，kqueue、epoll、/dev/poll 与 IOCP相比，就是多了一层从内核copy数据到应用层的阻塞，从而不能算作asynchronous I/O类。但是，这层小小的阻塞无足轻重，kqueue、epoll、/dev/poll 已经做得很优秀了。

只有IOCP(windows实现)是asynchronous I/O，其他机制或多或少都会有一点阻塞。select（Linux实现）低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善epoll(Linux实现)、kqueue（FreeBSD实现）、/dev/poll（Solaris实现）是Reacor模式，IOCP是Proactor模式。Apache 2.2.9之前只支持select模型，2.2.9之后支持epoll模型Nginx 支持epoll模型Java nio包是select模型

我们都知道Apache有三种工作模块，分别为prefork、worker、event。prefork：多进程，每个请求用一个进程响应，这个过程会用到select机制来通知。worker：多线程，一个进程可以生成多个线程，每个线程响应一个请求，但通知机制还是select不过可以接受更多的请求。event：基于异步I/O模型，一个进程或线程，每个进程或线程响应多个用户请求，它是基于事件驱动（也就是epoll机制）实现的。

如果不用“--with-mpm”显式指定某种MPM,prefork就是Unix平台上缺省的MPM.它所采用的预派生子进程方式也是 Apache1.3中采用的模式。prefork本身并没有使用到线程，2.0版使用它是为了与1.3版保持兼容性；另一方面，prefork用单独的子进程来处理不同的请求，进程之间是彼此独立的,这也使其成为最稳定的MPM之一。

相对于prefork，worker是2.0版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是，worker也使用了多进程,每个进程又生成多个线程，以获得基于进程服务器的稳定性，这种MPM的工作方 式将是Apache2.0的发展趋势。

一个进程响应多个用户请求，利用callback机制，让套接字复用，请求过来后进程并不处理请求，而是直接交由其他机制来处理，通过epoll机制来通知请求是否完成；在这个过程中，进程本身一直处于空闲状态，可以一直接收用户请求。可以实现一个进程程响应多个用户请求。支持持海量并发连接数，消耗更少的资源。

有几个基本条件：

刚好，Nginx 支持以上所有特性。所以Nginx官网上说，Nginx支持50000并发，是有依据的。

传统上基于进程或线程模型架构的web服务通过每进程或每线程处理并发连接请求，这势必会在网络和I/O操作时产生阻塞，其另一个必然结果则是对内存或CPU的利用率低下。生成一个新的进程/线程需要事先备好其运行时环境，这包括为其分配堆内存和栈内存，以及为其创建新的执行上下文等。这些操作都需要占用CPU，而且过多的进程/线程还会带来线程抖动或频繁的上下文切换，系统性能也会由此进一步下降。另一种高性能web服务器/web服务器反向代理：Nginx（Engine X），nginx的主要着眼点就是其高性能以及对物理计算资源的高密度利用，因此其采用了不同的架构模型。受启发于多种操作系统设计中基于“事件”的高级处理机制，nginx采用了模块化、事件驱动、异步、单线程及非阻塞的架构，并大量采用了多路复用及事件通知机制。在nginx中，连接请求由为数不多的几个仅包含一个线程的进程worker以高效的回环(run-loop)机制进行处理，而每个worker可以并行处理数千个的并发连接及请求。

Nginx会按需同时运行多个进程：一个主进程(master)和几个工作进程(worker)，配置了缓存时还会有缓存加载器进程(cache loader)和缓存管理器进程(cache manager)等。所有进程均是仅含有一个线程，并主要通过“共享内存”的机制实现进程间通信。主进程以root用户身份运行，而worker、cache loader和cache manager均应以非特权用户身份运行。

主进程主要完成如下工作：

注：如果负载以CPU密集型应用为主，如SSL或压缩应用，则worker数应与CPU数相同；如果负载以IO密集型为主，如响应大量内容给客户端，则worker数应该为CPU个数的1.5或2倍。

***隐藏网址***

处理静态文件，索引文件以及自动索引；反向代理加速(无缓存)，简单的负载均衡和容错；FastCGI，简单的负载均衡和容错；模块化的结构。过滤器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI过滤器中，到同一个 proxy 或者 FastCGI 的多个子请求并发处理；SSL 和 TLS SNI 支持；

使用外部 HTTP 认证服务器重定向用户到 IMAP/POP3 后端；使用外部 HTTP 认证服务器认证用户后连接重定向到内部的 SMTP 后端；认证方法：POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;IMAP: IMAP LOGIN;SMTP: AUTH LOGIN PLAIN CRAM-MD5;SSL 支持；在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;MacOS X (10.4) PPC;Windows 编译版本支持 windows 系列操作系统

一个主进程和多个工作进程，工作进程运行于非特权用户；kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （临时禁止事件）， NOTE_LOWAT, EV_EOF, 有效数据的数目，错误代码；sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；输入过滤 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；10,000 非活动的 HTTP keep-alive 连接仅需要 2.5M 内存。最小化的数据拷贝操作；

基于IP 和名称的虚拟主机服务；Memcached 的 GET 接口；支持 keep-alive 和管道连接；灵活简单的配置；重新配置和在线升级而无须中断客户的工作进程；可定制的访问日志，日志写入缓存，以及快捷的日志回卷；4xx-5xx 错误代码重定向；基于 PCRE 的 rewrite 重写模块；基于客户端 IP 地址和 HTTP 基本认证的访问控制；PUT, DELETE, 和 MKCOL 方法；支持 FLV （Flash 视频）；带宽限制；

在高连接并发的情况下，Nginx是Apache服务器不错的替代品: Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一. 能够支持高达 50,000 个并发连接数的响应, 感谢Nginx为我们选择了 epoll and kqueue 作为开发模型。Nginx作为负载均衡服务器: Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务, 也可以支持作为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多。作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器（最早开发这个产品的目的之一也是作为邮件代理服务器）, Last.fm 描述了成功并且美妙的使用经验.Nginx 安装非常的简单 , 配置文件非常简洁（还能够支持perl语法）,Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动. 你还能够 不间断服务的情况下进行软件版本的升级 。Nginx 的诞生主要解决C10K问题

nginx是干嘛用的

nginx提供了IMAP服务的功能。

Nginx (engine x)是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。Nginx作为一款轻量级的Web 服务器／反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like协议下发行。

Nginx作为负载均衡服务，Nginx既可以在内部直接支持Rails和PHP程序对外进行服务，也可以支持作为HTTP代理服务对外进行服务。Nginx采用C进行编写，不论是系统资源开销还是CPU使用效率都比Perlbal要好很多。

nginx占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

nginx使用技巧

大体上来说nginx主要用于反向加速代理而不是像squid那样作为常规代理服务。Nginx的最大优势在于高负载情况下内存和CPU的低消耗。我不认为squid能给你带来比nginx更好的性能。

依照NginxImapProxyExample开始你的配置，关于不同配置参数的具体信息，可以用运行于apache上的php脚本做后端验证，也可以使用运行于同一个服务器的nginx-embedded-perl模块作为imap/pop代理和认证后端。

跟我学Nginx，nginx 如何处理请求

基于名称（指 HTTP 请求头 Host 字段）的虚拟服务器指通过 HTTP 请求头的 Host 来决定客户端请求由哪个 server 进行处理。

让我们从一个简单的配置开始，下面配置了三个虚拟服务器，它们均侦听 80 端口 ：

上面配置中，nginx 仅测试请求的头字段“Host”以确定应将请求路由到哪个 server。如果“Host”的值与任何 server 名称都不匹配，或者请求根本不包含“Host”头字段，则 nginx 会将请求路由到此端口的默认 server。

上面的配置中，默认 server 是第一个 —— 这是 nginx 的标准默认行为。还可以使用 listen 指令中的 default_server 参数明确设置哪个 server 应该是默认 server：

如果不允许处理没有“Host”头字段的客户端请求（反过来说，只处理带有 Host 头字段的客户端请求），可以定义一个只丢弃请求的 server：

在这里，server_name 设置为一个空字符串，它将匹配没有“Host”头字段的请求，并返回一个特殊的 nginx 非标准代码 444 来关闭连接。

让我们看一个更复杂的配置，其中一些虚拟服务器侦听不同的地址：

上面配置中，nginx 首先根据 server 块的 listen 指令测试请求的 IP 地址和端口。然后，它根据与 IP 地址和端口匹配的 server 块的 server_name 条目测试请求的“Host”标头字段。如果未找到服务器名称，则请求将由默认服务器处理。例如，在 192.168.1.1:80 端口上收到的 www.example.com 请求将由 192.168.1.1:80 端口的默认服务器处理，即由第一个服务器处理，因为没有 www.example .com 为此端口定义。

如前所述，默认服务器是监听端口的一个属性，可以为不同的端口定义不同的默认服务器：

现在让我们看看 nginx 如何选择一个位置来处理一个典型的、简单的 PHP 站点的请求：

无论列出的顺序如何，nginx 首先搜索由文字字符串给出的最具体的前缀位置。在上面的配置中，唯一的前缀位置是“/”，并且由于它匹配任何请求，因此将用作最后的手段。然后 nginx 按照配置文件中列出的顺序检查正则表达式给出的位置。第一个匹配的表达式停止搜索，nginx 将使用这个位置。如果没有正则表达式匹配请求，则 nginx 使用之前找到的最具体的前缀位置。

注意： 所有类型的位置仅测试不带参数的请求行的 URI 部分。这样做是因为查询字符串中的参数可以通过多种方式给出，例如：

此外，任何人都可以在查询字符串中请求任何内容：

现在让我们看看在上面的配置中如何处理请求：

Nginx基础篇----虚拟主机、日志、模块、请求限制

在企业中，我们有很多的业务服务A，B，C等等，按照最最传统的财大气粗方式就是在一台机器上搭建一个Nginx，并且一个Nginx只为一个业务进行服务，如下图所示，我们有3个业务服务，我们就在3个机器上搭建3个Nginx，这显然是很浪费资源的一种不合理方式。

  虚拟主机的方式是指，我们在同一个Nginx上运行多套单独服务，而且这些服务是独立的，如下图所示：

  基于主机多IP的方式有两种：

第一步 ：在单网卡上添加多个IP--ip a add ip地址 设备名
第二步***隐藏网址***
第三步 ：找到默认配置文件，进行复制，将server中的listen进行改动，改为ip:port，在这里如果我们要为3个业务服务的话，我们就设置三个.conf的配置文件，每个配置文件中的ip不同即可。
第四步 ：nginx -s stop -c /etc/nginx/nginx.conf
nginx -s表示给nginx的主进程发送信号，停止应用。-c表示启动的时候使用哪个配置文件。

第一步***隐藏网址***
第二步 ：找到默认配置文件，进行复制，将server中的listen 端口进行改动即可，每个配置文件中的端口不同即可。
第三步 ：nginx -tc /etc/nginx/nginx.conf 对刚才修改的配置文件进行语法检查
第四步 ：nginx -c /etc/nginx/nginx.conf 启动nginx

更改server_name ：

  Nginx的日志类型有error.log和access_log两类。error.log用于记录错误类型的日志，access_log记录的是请求访问的相关的日志。Nginx使用了log_format把各种类型的变量进行组织，然后记录到access_log当中去。
***隐藏网址***

  Nginx的模块分为官方的模块和第三方的模块，我们可以通过命令行nginx -V看到很多的--with-XXXX，这些就是Nginx中的模块。

***隐藏网址***

  我们在nginx.conf中配置好后，通过IP:PORT/mystatus进行访问，会看到以下结果：

该模块使用的比较少，它表示是从目录中随机选取一个主页。语法规则 random_index on | off，默认情况下是random_index off;只能放在location的上下文中。

***隐藏网址***
***隐藏网址***
***隐藏网址***
***隐藏网址***

  Nginx中可以对连接频率和请求频率做限制。其中连接频率限制的模块是limit_conn_module，请求频率限制的模块是limit_req_module。
  请求和连接到底有什么区别呢？我们知道HTTP协议是建立在TCP协议之上的，客户端在向服务端发起请求的时候，必须先建立三次握手连接，建立完连接之后才开始发送请求，为了保持这个连接我们使用FIN和ACK，这样就可以在一个连接中多次发起请求，因此我们可以说HTTP请求建立在一次TCP连接基础上，一次TCP请求至少产生一次HTTP请求。

  连接限制的语法：
  定义空间：
***隐藏网址***
***隐藏网址***
  请求限制的语法：
  定义空间：
***隐藏网址***
***隐藏网址***

  $binary_remote_addr是限制同一客户端ip地址,binary_remote_addr和remote_addr其实是一样的，但是binary_remote_addr要更节省空间。1m 可以储存 32000 个并发会话。zone=req_zone:1m表示生成一个大小为1M，名字为req_one的内存区域，用来存储访问的频次信息;rate=1r/s表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，还可以有比如30r/m的。这里我使用abtest来演示一下各种情况：

配置每秒钟最多一次请求：

使用abtest发起请求，设置并发数20，发起20次请求。测试结果，成功1次，失败19次，符合预期：

查看nginx错误日志，图中刚好有19个error记录，而且是被限制了，符合预期：

设置一个大小为3的缓冲区，超过访问频次限制的请求将会放入到缓冲区中：

使用abtest发起请求，设置并发数20，发起20次请求。测试结果，成功4次，失败16次，符合预期，因为第一次成功后，超过了请求限制，放了3个请求到缓冲区中，所以总共成功4个：

查看nginx错误日志，图中刚好有16个error记录，而且是被限制了，符合预期：

设置最大连接数为1：

使用abtest发起请求，设置并发数20，发起20次请求。测试结果，成功20次，失败0次，符合预期：

查看nginx错误日志，无任何错误日志，符合预期。

***隐藏网址***

~表示模式匹配，这里我们表示凡是访问admin.html的请求，阻止180.158.232.219的访问，同时允许所有的IP访问。结果如下图所示：

请求成功：

***隐藏网址***
  Nginx的基础篇就讲到这里，欢迎大家指正，下一篇文章我将介绍如何使用Nginx作为静态资源Web服务。