正常情况下的单次web服务访问流程：
1993年3月2日，中国科学院高能物理研究所租用AT&T公司(美国电话电报公司)的国际卫星信道建立的接入美国SLAC国家实验室的64K专线正式开通，成为我国连入Internet的第一根专线。
http://www.ihep.cas.cn/kxcb/kpcg/jsywl/201407/t20140714_4156699.html
1995年马云开始创业并推出了一个web网站<<中国黄页>>，1999年创建阿里巴巴 www.alibabagroup.com, 2003年5月10日创立淘宝网，2004年12月，马云创立第三方网上支付平台支付宝（蚂蚁金服旗下，共有蚂蚁金服支付宝、余额宝、招财宝、蚂蚁聚宝、网商银行、蚂蚁花呗、芝麻信用等子业务板块。），2009年开始举办双十一购物狂欢节，以下是历年交易成交额：
2009年双十一：5000万元；
2010年双十一：9.36亿元；
2011年双十一：33.6亿元；
2012年双十一：191亿元；
2013年双十一：350亿元；
2014年双十一：571亿元；
2015年双十一：912.17亿元；
2016年双十一：1207亿元元；
2017年双十一：1682.69亿元；
2018年双十一：2135亿元；
2019年双十一：2684亿；
。。。。。
2012年1月11日淘宝商城正式更名为“天猫”。
2014年9月19日里巴巴集团于纽约证券交易所正式挂牌上市。
2020年福布斯统计马云财富415亿美元。
Netcraft公司于1994年底在英国成立，多年来一直致力于互联网市场以及在线安全方面的咨询服务，其中在国际上最具影响力的当属其针对网站服务器，域名解析/主机提供商，以及SSL市场所做的客观严谨的分析研究。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7QnlWD6x-1610347882784)(https://news.netcraft.com/images/2020/06/wss-share.png)]](https://img-blog.csdnimg.cn/20210111145841687.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NjIzODc1NQ==,size_16,color_FFFFFF,t_70)
pache起初由美国的伊利诺伊大学香槟分校的国家超级计算机应用中心开发，目前经历了两大版本分别是1.X和2.X，其可以通过编译安装实现特定的功能，目前支持三种不同的MPM(multi-processing module,多进程处理模块，官方网站 http://www.apache.org。
1.2.1.1：Apache prefork模型：
预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024，每个子进程有一个独立的线程响应用户请求，相对比较占用内存，但是比较稳定，可以设置最大和最小进程数，是最古老的一种模式，也是最稳定的模式，适用于访问量不是很大的场景。
优点：稳定
缺点：大量用户访问慢，占用资源，1024个进程不适用于高并发场景
1.2.1.2 ：Apache woker 模型：
一种多进程和多线程混合的模型，有一个控制进程，启动多个子进程，每个子进程里面包含固定的线程，使用线程程来处理请求，当线程不够使用的时候会再启动一个新的子进程，然后在进程里面再启动线程处理请求，由于其使用了线程处理请求，因此可以承受更高的并发。
优点：相比prefork 占用的内存较少，可以同时处理更多的请求
缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在prefork模式下，同样会发生）
Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型，属于事件驱动模型(epoll)，每个进程响应多个请求，在现在版本里的已经是稳定可用的模式。它和worker模式很像，最大的区别在于，它解决了keepalive场景下，长期被占用的线程的资源浪费问题（某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）。event MPM中，会有一个专门的线程来管理这些keepalive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力。
优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放
缺点：没有线程安全控制
Nginx是由1994年毕业于俄罗斯国立莫斯科鲍曼科技大学的同学为俄罗斯rambler.ru公司开发的，开发工作最早从2002年开始，第一次公开发布时间是2004年10月4日，版本号是0.1.0，官网地址
Nginx历经十几年的迭代更新（https://nginx.org/en/CHANGES）， 目前功能已经非常完善且运行稳定，另外Nginx的版本分为开发版、稳定版和过期版，Nginx以功能丰富著称，它即可以作为http服务器，也可以作为反向代理服务器或者邮件服务器，能够快速的响应静态网页的请求，支持FastCGI/SSL/Virtual Host/URL Rwrite/Gzip/HTTP Basic Auth/http或者TCP的负载均衡(1.9版本以上且开启stream模块)等功能，并且支持第三方的功能扩展。
为什么使用Nginx：
天猫 淘宝 小米 163 京东新浪等一线互联网公司都在用Nginx或者进行二次开发
基于Nginx的访问流程如下：
说明：nginx会根据请求的类型进行动静分离，静态的请求交给存储服务器，动态请求交给MySQL
互联网存在用户速度体验的1-3-10原则，即1秒最优，1-3秒较优，3~10秒比较慢，10秒以上用户无法接受。用户放弃一个产品的代价很低，只是换一个URL而已。
http://baijiahao.baidu.com/s?id=1643187950686234006&wfr=spider&for=pc #用户体验的重要性
http://www.sohu.com/a/218426004_573333
全球最大搜索引擎 Google：慢500ms = 20% 将放弃访问。
全球最大的电商零售网站 亚马逊：慢100ms = 1% 将放弃交易
有很多研究都表明，性能对用户的行为有很大的影响：
79%的用户表示不太可能再次打开一个缓慢的网站
47%的用户期望网页能在2秒钟以内加载
40%的用户表示如果加载时间超过三秒钟，就会放弃这个网站
页面加载时间延迟一秒可能导致转换损失7%，页面浏览量减少11%
8秒定律：用户访问一个网站时，如果等待网页打开的时间超过8秒，会有超过30%的用户放弃等待
据说马云在刚开始创业在给客户演示时，打开一个网站花了两个多小时。
https://www.shuimiao.net/NjHaO/
客户端原因：
服务端原因：
httpd MPM（Multi-Processing Module，多进程处理模块）模式：
Nginx（Master+Worker）模式：
#Centos 7.x目前默认为prefork模式，ubuntu 18.04已经使用event模式
Apache线程验证方式：
[root@localhost ~]# httpd -V #Centos系统
AH00558: httpd: Could not reliably determine the server's fully qualified domain name,using localhost.localdomain. Set the 'ServerName' directive globally to suppress thismessage
Server version: Apache/2.4.6 (CentOS)
Server built: Aug 8 2019 11:41:18
Server's Module Magic Number: 20120211:24
Server loaded: APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture: 64-bit
Server MPM: prefork #MPM模式为prefork
threaded: no
# ps -ef | grep httpd
root 2757 1 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2758 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2759 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2760 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2761 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2762 2757 0 04:03 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
root 2786 2369 0 04:13 pts/0 00:00:00 grep --color=auto httpd
# cat /proc/2760/status
Name: httpd
State: S (sleeping)
..............
Threads: 1
..............
#Ubuntu 18.04.3系统：
root@mq-node1:~# apachectl -V
Server version: Apache/2.4.29 (Ubuntu)
Server built: 2019-09-16T12:58:48
Server's Module Magic Number: 20120211:68
Server loaded: APR 1.6.3, APR-UTIL 1.6.1
Compiled using: APR 1.6.3, APR-UTIL 1.6.1
Architecture: 64-bit
Server MPM: event #MPM模式为event
threaded: yes (fixed thread count)
forked: yes (variable process count)
# ps -ef | grep apache2
root 918 1 0 20:08 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 919 918 0 20:08 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 920 918 0 20:08 ? 00:00:00 /usr/sbin/apache2 -k start
root 1202 1172 0 20:12 pts/0 00:00:00 grep --color=auto apache2
# cat /proc/919/status
Name: apache2
Umask: 0022
State: S (sleeping)
..............
Threads: 27
..............
I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。IOPS是指的是在单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。
机械磁盘的寻道时间、旋转延迟和数据传输时间：
注意：web服务器千万不要用7200转的机械盘，最低用10000的
范例：
常见的机械磁盘平均寻道时间值：
7200转/分的磁盘平均物理寻道时间：9毫秒
10000转/分的磁盘平均物理寻道时间：6毫秒
15000转/分的磁盘平均物理寻道时间：4毫秒
常见磁盘的平均延迟时间：
7200转的机械盘平均延迟：60\*1000/7200/2 = 4.17ms
10000转的机械盘平均延迟：60\*1000/10000/2 = 3ms
15000转的机械盘平均延迟：60\*1000/15000/2 = 2ms
每秒最大IOPS的计算方法：
7200转的磁盘IOPS计算方式：1000毫秒/(9毫秒的寻道时间+4.17毫秒的平均旋转延迟时间)=1000/13.13=75.9 IOPS
10000转的磁盘的IOPS计算方式：1000毫秒/(6毫秒的寻道时间+3毫秒的平均旋转延迟时间)=1000/9=111 IOPS
15000转的磁盘的IOPS计算方式：15000毫秒/(4毫秒的寻道时间+2毫秒的平均旋转延迟时间)=1000/6=166.6 IOPS
一次完整的I/O是 用户空间的进程数据与内核空间的内核数据的报文的完整交换过程 ，但是由于内核空间与用户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说 一次 I/O 就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中的整个过程 。
而网络通信就是从网络协议栈到用户空间进程的IO，也就是网络IO。
磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是文件或者是图片，然后内核通过相应的驱动程序将目标图片加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存，如果是比较大的数据也需要等待时间。
每次IO，都要经由两个阶段：
关注的是事件处理的消息通信机制，即在等待一件事情的处理结果时，被调用者是否提供完成通知。
同步：synchronous，调用者等待被调用者返回消息后才能继续执行，如果被调用者不提供消息返回则为同步，同步需要调用者主动询问事情是否处理完成。
异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者，即异步会主动返回被调用者的状态给调用者。
说明：被调用者通常是内核，调用者就是web服务（Nginx、PHP）
关注调用者在等待结果返回之前所处的状态
以我去吃饭为例：我点了10个包子
同步与异步：
我点包子之后厨师是否告诉我：
阻塞与非阻塞：：
我点包子后的状态：
IO模型组合：
阻塞型、非阻塞型、复用型、信号驱动型、异步
阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞
优点：程序简单，在阻塞等待数据期间进程挂起，基本不会占用 CPU 资源
缺点：每个连接需要独立的进程单独处理，当并发请求量大时为了维护程序，内存、进程切换开销较大，apache的preforck使用的是这种模式。
同步阻塞：程序向内核发送IO请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进程将一直等待并不再接受新的请求，并由进程轮训查看IO是否完成，完成后进程将IO结果返回给Client，在IO没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看IO是否完成，这种方式简单，但是比较慢，用的比较少。
用户请求进程向内核发起IO请求时立即返回，但并未读取到任何数据，进程需要不断地发起IO请求，直到数据到达进程空间的内存后，才真正读取到数据并继续执行，即前期需要一次次 “轮询”去查看请求是否数据是否准备报，但是此机制存在两个问题：1.如果有大量文件描述符都要等，那么就得一个一个的read，这会带来大量的Context Switch（read是系统调用，每调用一次就得在用户态和核心态切换一次），2.轮询的时间不好把握，这里是要猜多久之后数据才能到，等待时间设的太长，程序响应延迟就过大，但是设的太短，就会造成过于频繁的重试，干耗CPU而已，所以是比较浪费CPU的方式，因此一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。
同步非阻塞：应用进程向内核发送请IO求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回IO结果，进程将不再等待，而且继续处理其他请求，但是仍然需要进程隔一段时间就要查看内核IO是否完成。
IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO(事件驱动IO)，select/poll/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。
当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回，这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。
Apache prefork是此模式的主进程+多进程/单线程+select，work是主进程+多进程/多线程+poll模式
信号驱动IO：signal-driven I/O
用户进程可以通过sigaction系统调用注册一个信号处理程序，然后进程可以继续向下执行，当有IO操作准备就绪时，由内核通知触发一个SIGIO信号处理程序执行，然后将用户进程所需要的数据从内核空间拷贝到用户空间，此模型的优势在于等待数据报到达期间进程不被阻塞，进程可以继续执行，只要等待来自信号处理函数的通知。
优点：进程没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此可以提高资源的利用率
缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
异步阻塞：进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核收到进程请求后进行的IO如果不能立即返回，就由内核等待结果，直到IO完成后内核再通知进程，apache event模型就是主进程+多进程/多线程+信号驱动
相对于同步IO，异步IO不是顺序执行，用户进程进行aio_read系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情，等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知，异步非阻塞IO的两个阶段，进程都是非阻塞的。
Linux提供了AIO库函数实现异步，但是用的很少，目前有很多开源的异步IO库，例如libevent、libev、libuv等，异步过程如下图所示：
异步非阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核调用的IO如果不能立即返回，内核会继续处理其他事物，直到IO完成后将结果通知给内核，内核在将IO完成的结果返回给进程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互不影响，可以实现较大的同时并实现较高的IO复用，因此异步非阻塞使用最多的一种通信方式，nginx就是是异步非阻塞模型
这五种网络 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步 I/O，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配。
Nginx支持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同，主要有以下实现方式：
select：（用的较少）
select库是在linux和windows平台都基本支持的 事件驱动模型库，并且在接口的定义也基本相同，只是部分参数的含义略有差异，最大并发限制1024，是最早期的事件驱动模型。
poll :（不推荐使用，降低性能）
在Linux 的基本驱动模型，windows不支持此驱动模型，是select的升级版，取消了最大的并发限制，在编译nginx的时候可以使用–with-poll_module和–without-poll_module这两个指定是否编译select库。
epoll：
epoll是库是Nginx服务器支持的最高性能的事件驱动库之一，是公认的非常优秀的事件驱动模型，它和select和poll有很大的区别，epoll是poll的升级版，但是与poll的效率有很大的区别.
epoll的处理方式是创建一个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮训检查这个表，以判断事件是否发生，epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大数，同时epoll库的IO效率不随描述符数目增加而线性下降，因为它只会对内核上报的“活跃”的描述符进行操作。
rtsig：
不是一个常用事件驱动，最大队列1024，不是很常用
kqueue
用于支持BSD系列平台的高效事件驱动模型，主要用在FreeBSD 4.1及以上版本、OpenBSD 2.0级以上版本，NetBSD级以上版本及Mac OS X 平台上，该模型也是poll库的变种，因此和epoll没有本质上的区别，都是通过避免轮训操作提供效率。
/dev/poll:
用于支持unix衍生平台的高效事件驱动模型，主要在Solaris 平台、HP/UX，该模型是sun公司在开发Solaris系列
平台的时候提出的用于完成事件驱动机制的方案，它使用了虚拟的/dev/poll设备，开发人员将要见识的文件描述符加入这个设备，然后通过ioctl()调用来获取事件通知，因此运行在以上系列平台的时候请使用/dev/poll事件驱动机制。
eventport：
该方案也是sun公司在开发Solaris的时候提出的事件驱动库，只是Solaris 10以上的版本，该驱动库看防止内核崩溃等情况的发生。
Iocp：
Windows系统上的实现方式，对应第5种（异步I/O）模型。
| \ | select | poll | epoll |
|---|---|---|---|
| 操作方式 | 遍历 | 遍历 | 回调 |
| 底层实现 | 数组 | 链表 | 哈希表 |
| IO效率 | 每次调用都进行线性遍历，时间复杂度为O(n) | 每次调用都进行线性遍历，时间复杂度为O(n) | 时间通知方式，每当fd就绪。系统注册的回调函数就会被调用，将就绪fd放到rdllist里面，时间复杂度为O(1) |
| 最大连接数 | 1024(x86)或2048(x64) | 无上限 | 无上限 |
| fd拷贝 | 每次调用select，都需要把fd集合从用户态拷贝到内核态 | 每次调用poll，都需要把fd集合从用户态拷贝到内核态 | 调用epoll_ctl时拷贝进内核并保存，之后每次epoll_wait不拷贝 |
说明：O(1) 表示算法的运行时间为常量，即无论是1000个还是10000个，耗费时间一样
O(n): 表示该算法是线性算法
fd表示事件描述符
水平触发-- 多次通知，需要关心数据是否取完，即数据取走之后即不再通知进程，以避免重复多次无效通知，通知效率较低。
边缘触发-- 一次通知，需要关心数据是否取走，即只通知一次怎么保证数据被进程成功取走了，以避免数据丢失，通知效率较高。
Select：
POSIX所规定，目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理
缺点
poll：
epoll：
在Linux 2.6内核中提出的select和poll的增强版本。
支持水平触发LT和边缘触发ET，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次
使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知 。
优点:
mmap(memory mapping)系统调用使得进程之间通过映射同一个普通文件实现共享内存，普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问。
Nginx：engine X ，2002年开始开发，2004年开源，2019年3月11日，Nginx公司被F5 Networks以6.7亿美元收购，Nginx官网：http://nginx.org，Nginx 商业版为Nginx Plus：https://www.nginx.com/products/nginx/
Nginx 则是免费的、开源的、高性能的HTTP和反向代理服务器、邮件代理服务器、以及TCP/UDP代理服务器，解决C10K问题（10K Connections），http://www.ideawu.net/blog/archives/740.html
nginx的其它的二次发行版：
静态的web资源服务器html，图片，js，css，txt等静态资源
结合FastCGI/uWSGI/SCGI等协议反向代理动态资源请求
http/https协议的反向代理
imap4/pop3协议的反向代理
tcp/udp协议的请求转发（反向代理）
特性：
基本功能：
web请求处理机制：
多进程方式：服务器每接收到一个客户端请求就有服务器的主进程生成一个子进程响应客户端，直到用户关闭连接，这样的优势是处理速度快，各子进程之间相互独立，但是如果访问过大会导致服务器资源耗尽而无法提供请求。
多线程方式：与多进程方式类似，但是每收到一个客户端请求会有服务进程派生出一个线程来个客户方进行交互，一个线程的开销远远小于一个进程，因此多线程方式在很大程度减轻了web服务器对系统资源的要求，但是多线程也有自己的缺点，即当多个线程位于同一个进程内工作的时候，可以相互访问同样的内存地址空间，所以他们相互影响，另外一旦主进程挂掉则所有子线程都不能工作了，IIS服务器使用了多线程的方1式，需要间隔一段时间就重启一次才能稳定。
Nginx是多进程组织模型，而且是一个由Master主进程和Worker工作进程组成。
主进程(master process)的功能：
工作进程（woker process）的功能：
工作进程是有主进程生成的，主进程使用fork()函数，在Nginx服务器启动过程中主进程根据配置文件决定启动工作进程的数量，然后建立一张全局的工作表用于存放当前未退出的所有的工作进程，主进程生成工作进程后会将新生成的工作进程加入到工作进程表中，并建立一个单向的管道并将其传递给工作进程，该管道与普通的管道不同，它是由主进程指向工作进程的单向通道，包含了主进程向工作进程发出的指令、工作进程ID、工作进程在工作进程表中的索引和必要的文件描述符等信息。
主进程与外界通过信号机制进行通信，当接收到需要处理的信号时，它通过管道向相关的工作进程发送正确的指令，每个工作进程都有能力捕获管道中的可读事件，当管道中有可读事件的时候，工作进程就会从管道中读取并解析指令，然后采取相应的执行动作，这样就完成了主进程与工作进程的交互。
说明：
核心模块：是 Nginx 服务器正常运行 必不可少 的模块，提供 错误日志记录 、 配置文件解析 、 事件驱动机制 、进程管理 等核心功能
标准HTTP模块：提供 HTTP 协议解析相关的功能，比如： 端口配置 、 网页编码设置 、 HTTP响应头设置 等等
可选HTTP模块：主要用于扩展标准的 HTTP 功能，让 Nginx 能处理一些特殊的服务，比如： Flash 多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等
邮件服务模块：主要用于支持 Nginx 的 邮件服务 ，包括对 POP3 协议、 IMAP 协议和 SMTP协议的支持 （基本用不上）
第三方模块：是为了扩展 Nginx 服务器应用，完成开发者自定义功能，比如： Json 支持、 Lua 支持等
nginx高度模块化，但其模块早期不支持DSO机制；1.9.11版本支持动态装载和卸载
模块分类：
核心模块：core module
标准模块：
HTTP 模块： ngx_http_*
HTTP Core modules 默认功能
HTTP Optional modules 需编译时指定
Mail 模块 ngx_mail_*
Stream 模块 ngx_stream_*
第三方模块
Nginx的安装版本分为Mainline version(主要开发版本，其实就是还处于开发版)、Stable version(当前最新稳定版)和Legacy versions(旧的稳定版)
Nginx安装可以使用yum或源码安装，但是推荐使用源码，一是yum的版本比较旧，二是编译安装可以更方便自定义相关路径，三是使用源码编译可以自定义相关功能，更方便业务的上的使用，源码安装需要提前准备标准的编译器
GCC的全称是（GNU Compiler collection），其有GNU开发，并以GPL即LGPL许可，是自由的类UNIX即苹果电脑Mac OS X操作系统的标准编译器，因为GCC原本只能处理C语言，所以原名为GNU C语言编译器，后来得到快速发展，可以处理C++,Fortran，pascal，objective-C，java以及Ada等其他语言，此外还需要Automake工具，以完成自动创建Makefile的工作，Nginx的一些模块需要依赖第三方库，比如pcre（支持rewrite），zlib（支持gzip模块）和openssl（支持ssl模块）等。
需要提前配置好epel源
官方提供的仓库：http://nginx.org/en/linux_packages.html#RHEL-CentOS
[root@s1 ~]# yum install epel-release -y
#或者使用官方提供的仓库，里面有新版的nginx
[root@Centos7 ~]#vim /etc/yum.repos.d/nginx.repo
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
[root@Centos7 ~]# yum install -y nginx
[root@Centos7 ~]# rpm -ql nginx
/etc/logrotate.d/nginx
/etc/nginx/fastcgi.conf
/etc/nginx/fastcgi.conf.default
/etc/nginx/fastcgi_params
/etc/nginx/fastcgi_params.default
/etc/nginx/koi-utf
/etc/nginx/koi-win
/etc/nginx/mime.types
/etc/nginx/mime.types.default
/etc/nginx/nginx.conf
/etc/nginx/nginx.conf.default
/etc/nginx/scgi_params
/etc/nginx/scgi_params.default
/etc/nginx/uwsgi_params
/etc/nginx/uwsgi_params.default
/etc/nginx/win-utf
/usr/bin/nginx-upgrade
/usr/lib/systemd/system/nginx.service
/usr/lib64/nginx/modules
/usr/sbin/nginx
/usr/share/doc/nginx-1.18.0
.................
/var/lib/nginx
/var/lib/nginx/tmp
/var/log/nginx
[root@Centos7 ~]# which nginx
/usr/sbin/nginx
查看nginx安装包信息
[root@Centos7 ~]#rpm -qi nginx
Name : nginx
Epoch : 1
Version : 1.16.1
Release : 1.el7
Architecture: x86_64
Install Date: Mon 13 Jul 2020 10:37:26 PM CST
Group : Unspecified
Size : 1689960
License : BSD
Signature : RSA/SHA256, Fri 04 Oct 2019 06:38:33 AM CST, Key ID 6a2faea2352c64e5
Source RPM : nginx-1.16.1-1.el7.src.rpm
Build Date : Thu 03 Oct 2019 01:15:40 PM CST
Build Host : buildvm-13.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://nginx.org/
Bug URL : https://bugz.fedoraproject.org/nginx
Summary : A high performance web server and reverse proxy server
Description :
Nginx is a web server and a reverse proxy server for HTTP, SMTP, POP3 and IMAP protocols, with a strong focus on high concurrency, performance and low memory usage.
使用安装完成的二进制文件nginx
[root@Centos7 ~]# nginx -h
nginx version: nginx/1.16.1
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:
-?,-h : this help
-v : show version and exit
-V : show version and configure options then exit #显示版本和编译参数
-t : test configuration and exit #测试配置文件是否异常
-T : test configuration, dump it and exit #测试并打印
-q : suppress non-error messages during configuration testing #静默模式
-s signal : send signal to a master process: stop, quit, reopen, reload #发送信号
-p prefix : set prefix path (default: /usr/share/nginx/) #指定Nginx 目录
-c filename : set configuration file (default: /etc/nginx/nginx.conf) #配置文件路径
-g directives : set global directives out of configuration file #设置全局指令
[root@Centos7 ~]#nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@Centos7 ~]#nginx -V
nginx version: nginx/1.16.1
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)
built with OpenSSL 1.0.2k-fips 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-stream_ssl_preread_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-http_auth_request_module --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'
[root@s1 ~]# cat /usr/lib/systemd/system/nginx.service
[Unit]
Description=The nginx HTTP and reverse proxy server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
# Nginx will fail to start if /run/nginx.pid already exists but has the wrong
# SELinux context. This might happen when running `nginx -t` from the cmdline.
# https://bugzilla.redhat.com/show_bug.cgi?id=1268621
ExecStartPre=/usr/bin/rm -f /run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
KillSignal=SIGQUIT
TimeoutStopSec=5
KillMode=process
PrivateTmp=true
[Install]
WantedBy=multi-user.target
默认配置文件：/etc/nginx/nginx.conf，，默认配置如下：
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
include /etc/nginx/conf.d/*.conf;
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /usr/share/nginx/html;
include /etc/nginx/default.d/*.conf;
location / {
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
}
[root@Centos7 ~]#systemctl start nginx
[root@Centos7 ~]#systemctl status nginx
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Active: active (running) since Mon 2020-07-13 22:43:52 CST; 8s ago
Process: 3141 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Process: 3138 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 3136 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 3143 (nginx)
CGroup: /system.slice/nginx.service
├─3143 nginx: master process /usr/sbin/nginx
├─3144 nginx: worker process
└─3145 nginx: worker process
Jul 13 22:43:52 Centos7.8 systemd[1]: Starting The nginx HTTP and reverse proxy server...
Jul 13 22:43:52 Centos7.8 nginx[3138]: nginx: the configuration file /etc/nginx/nginx.conf ... ok
Jul 13 22:43:52 Centos7.8 nginx[3138]: nginx: configuration file /etc/nginx/nginx.conf test...ful
Jul 13 22:43:52 Centos7.8 systemd[1]: Started The nginx HTTP and reverse proxy server.
Hint: Some lines were ellipsized, use -l to show in full.
[root&