本文目录导航：
Nginx限度并发衔接数
关于一些主机流量意外、负载过大，甚至是大流量的恶意攻打访问等，启动并发数的限度（共享内存和并发限度需联合系统定制） limit_conn_zone 设置共享内存区域参数
limit_conn设置共享内存区域和给定键值的最大准许衔接数
limit_conn_log_level日志可以调整级别，自动 error
limit_conn_status前往形态码照应拒绝恳求，自动 503
示例
限度来自单个IP地址的恳求处置频率，每秒固定处置恳求数，推延过多恳求。以此来防止运行层的 DDOS 攻打（共享内存和恳求频率需联合系统定制） limit_req_zone设置共享内存区域参数
limit_req设置共享内存区域、突发大小、延时
limit_req_log_level日志可以调整级别，自动 error
limit_req_status前往形态码照应拒绝恳求，自动 503
示例
面试官：请问Nginx为什么比Apache性能好
Nginx才短短几年，就拿下了web主机大笔江山，妇孺皆知，Nginx在处置大并发静态恳求方面，效率显著高于httpd，甚至能轻松处置C10K疑问。
上方咱们就来聊聊Web主机面前的一些原理。
进程是具备肯定独罪恶能的，在计算机中曾经运转的程序的实体。
在早期系统中（如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版宿管大妈会先记下每位同窗的房间号，你的好友来时，只要通知你的好友你住在哪个房间即可，不用亲身带着你的好友满大楼找人。
假设来了团体，都要找自己住这栋楼的同窗时，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支持并发，是有依据的。
传统上基于进程或线程模型架构的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倍。
Nginx的代码是由一个外围和一系列的模块组成, 外围重要用于提供Web Server的基本色能，以及Web和Mail反向代理的性能；还用于启用网络协定，创立必要的运转时环境以及确保不同的模块之间平滑地启动交互。
不过，大多跟协定相关的性能和某运行特有的性能都是由nginx的模块成功的。
这些性能模块大抵可以分为事情模块、阶段性处置器、输入过滤器、变量处置器、协定、upstream和负载平衡几个类别，这些独特组成了nginx的http性能。
事情模块重要用于提供OS独立的(不同操作系统的事情机制有所不同)事情通知机制如kqueue或epoll等。
协定模块则担任成功nginx经过http、tls/ssl、smtp、pop3以及imap与对应的客户端建设会话。
在Nginx外部，进程间的通讯是经过模块的pipeline或chain成功的；换句话说，每一特性能或操作都由一个模块来成功。
例如，紧缩、经过FastCGI或uwsgi协定与upstream主机通讯，以及与memcached建设会话等。
处置静态文件，索引文件以及智能索引；反向代理减速(无缓存)，便捷的负载平衡和容错；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 同时也是一个十分低劣的邮件代理主机（最早开发这个产品的目标之一也是作为邮件代理主机）, 形容了成功并且美妙的经常使用阅历 装置十分的便捷 , 性能文件十分繁复（还能够支持perl语法）,Bugs 十分少的主机: Nginx 启动特意容易, 并且简直可以做到7*24不连续运转，即使运转数个月也不须要从新启动. 你还能够 不连续服务的状况下启动软件版本的更新 。
Nginx 的降生重要处置C10K疑问
nginx能扛得住5万并发，那更大呢，怎样办
在高并发衔接的状况下，Nginx是Apache主机不错的代替品。
Nginx同时也可以作为7层负载平衡主机来经常使用。
测试结果，Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 可以接受3万以上的并发衔接数，相当于等同环境下Apache的10倍。
依据阅历，4GB内存的主机+Apache（prefork形式）普通只能处置3000个并发衔接，由于它们将占用3GB以上的内存，还得为系统预留1GB的内存。
我曾经就有两台Apache主机，由于在性能文件中设置的MaxClients为4000，当Apache并发衔接数到达3800时，造成主机内存和Swap空间用满而解体。
而这台 Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 主机在3万并发衔接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存（20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。
假设主机内存较小，齐全可以只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。
在3万并发衔接下，访问Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 主机的PHP程序，依然速度飞快。
你说的5万可以成功最高能到达10万并发 然而有一个疑问你的主机性能要跟得上才可以玩要不然弄到那个并发数也没啥意义
