nginx杂谈

1：curl和下载则是典型的IO密集型操作，因为耗时主要发生在网络IO和磁盘IO，至于curl操作，可以建立一个监听9001端口的名为upload的php-fpm进程池，专门负责处理curl操作(通过nginx分发)，避免curl操作阻塞到监听9000端口的计算密集的www进程池。
如：nginx.conf
location = /curl.php{
include fastcgi_params;
fastcgi_pass 127.0.0.1:9001;
fastcgi_param SCRIPT_FILENAME $documen{t}_{r}oot$fastcgi_script_name;
}

php-fpm.conf：
[www]
listen = 127.0.0.1:9000
pm = static
pm.max_children = 4

[curl]
listen = 127.0.0.1:9001
pm = static
pm.max_children = 20

利用php-fpm提供的池的隔离性，分离计算密集和IO密集操作，可以减少阻塞对整个php应用的影响。

2：nginx location的语法规则
= 精确匹配，这个优先级最高
^~ 匹配url路径
~ 区分大小写的正则匹配
~* 不区分大小写的正则匹配

3：buffer的工作原理
这些buffer参数是作用到每一个请求的，每一个请求会按照参数的配置获得自己的buffer。nginx将会尽可能的读取所有后端传输的数据到buffer，直到proxy_buffers设置的所有buffer被写满或者数据读取完，此时，nginx开始向客户端传输数据，会同时传输这一整串的buffer，同时，如果响应的内容太大，nginx会把他们写入到磁盘上。

4：指定文件路径的方式：
nginx指定文件路径有两种方式：root和alias，root会根据完整的uri请求来映射，alias会把location后面配置的路径丢弃掉。
如：
location /request_path/image/ {
root /local_path/image/
}
当我们请求/request_path/image/cat.png时候，nginx会把请求映射为/local_path/image/request_path/image/cat.png

location /request_path/image/ {
root /local_path/image/
}
当我们请求/request_path/image/cat.png时候，nginx会把请求映射为：/local_path/image/cat.png

5：nginx会把Request在读取完整之前buffer住，这样交给后端的就是一个完整的http请求，而不是断断续续的传递，从而提高后端的效率。同样，nginx也可以把response给buffer住。

6：nginx -t 测试配置文件是否有语法错误。-s quit：优雅地停止服务，该命令与快速停止nginx是有区别的，当快速停止服务时，worker进程与master进程在收到信号后会立刻跳出循环，退出进程，而优雅地停止服务时，首先会关闭监听端口，然后把当前正在处理的连接处理完，再退出进程。-s reload：nginx会检查新的配置文件是否有误，如果全部正确就以优雅的方式关闭nginx，然后再重新启动nginx。

7：如何在nginx里设置环境变量，然后在php里用${}_{S}ERVER来接收？a：在fastcgi.conf里添加：fastcg{i}_{p}aramD{B}_{N}AM{E}^{\prime }21cak{e}^{\prime }，然后在php端用$_SERVER[‘DB_NAME’]就能接收到21cake了。如果nginx下有多个虚拟主机，这个环境变量会适用于所有的虚拟主机。
b：在虚拟主机的server的location里添加：
location ~ .*.(php)?${
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
fastcgi_param DB_NAME ‘21cake’;
}
这个DB_NAME环境变量只适用于这个虚拟主机。
c：在php-fpm.conf里添加：env[DB_NAME] = 21cake

8：nginx的worker进程数？
worker进程的数量会直接影响性能，每个worker进程都是单线程的进程，他们会调用各个模块以实现各种各样的功能。如果这些模块确认不会出现阻塞的调用，那么有多少cpu内核就应该配置多少个进程，反之，如果有可能出现阻塞式的调用，那么就需要配置稍多一些的进程。

9：为什么要绑定nginx的worker进程到指定的cpu内核？
假如每个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个cpu，那么就会出现同步的问题，反之，如果每一个worker进程都独享一个cpu，那么就在内核的调度策略上实现了完全的并发。

10：在开始处理一个http请求时，nginx会取出header头中的host，与每个server中的server_name进行匹配，以此来决定调用哪个server来处理请求。

11：location是有顺序的，当一个请求有可能匹配多个location时，实际上这个请求会被第一个location处理。

12：try_files的用法：try_files path1 path2 uri;try_files后面要跟若干个路径，而且最后必须要有uri参数，意义如下：尝试按照顺序访问每一个path，如果可以有效地读取到，就直接向用户返回这个path对应的文件，然后结束请求，否则继续向下访问；如果所有的path都找不到有效的文件，就重定向到最后的参数uri上。

13：keepalive超时时间：一个keepalive连接在闲置一定时间后(默认是75秒)服务器和浏览器都会去关闭这个连接。当然
keepalive_timeout是用来设置nginx服务器关闭连接的时间的。

14：当客户端发来http请求时，nginx并不会立刻转发给上游服务器，而是先把用户的请求完整地接收到nginx所在服务器的硬盘或者内存中，然后在向上游服务器发起连接，把缓冲的客户端请求转发给上游服务器。这种方式的缺点：延迟了一个请求的处理时间，并增加了用于缓冲请求内容的内存和磁盘空间；优点是降低了上游服务器的负载，尽量把压力放在nginx服务器上。那么这种方式为什么会降低上游服务器的负载呢？通常客户端与代理服务器之间的网络环境比较复杂，多半是走公网，网速平均下来可能会很慢，因此，一个请求可能要持续很多才能完成，而代理服务器与上游服务器一般是走内网，传输速度较快。而squid等反向代理服务器在于客户端建立连接且没有开始接收http包体时就已经向上游服务器建立了连接。例如：请求某个要上传1G的文件，那么每次squie在接收到一个tcp包时就会即时地向上游服务器转发，在这个漫长的过程中，上游服务器始终要维持这个连接。而nginx则会完整地接收完整个文件后才会与上游服务器建立连接，由于是内网，这个转发过程很快就会完成。

15：所谓事件驱动架构，简单来说，就是由一些事件发生源产生事件，由一个或多个事件收集器来收集分发事件，然后一些事件处理器会注册自己感兴趣的事件，同时消费这些事件。传统的web服务器与nginx服务器之间的差别：前者是每个事件消费者独占一个进程资源，后者的事件消费者只是短期调用而已。比如，一个下载静态资源的请求可能会由于请求数据过大、网速不稳定等因素被分解成成千上百个阶段。请求的多阶段异步处理只能基于事件驱动架构来实现，就是说把一个请求的处理过程按照事件的触发方式划分为多个阶段，每个阶段都可以由事件收集、分发器来触发。异步处理和多阶段是相辅相成的，只有把请求分为多个阶段，才有所谓的异步处理。也就是说当一个事件被分发到事件消费者手中进行处理时，事件消费者处理完这个事件只相等于处理完1个请求的某个阶段。那么什么时候可以处理下一个阶段呢？这只能等待内核的通知。这样，每个阶段中的时间消费者本次完整的操作究竟什么时候能完成，只能异步、被动的等待下一次事件的通知。那么请求的多阶段异步处理的优势在哪里呢？这种设计配合事件驱动架构，将会极大地提高网络性能，同时使得每个进程都全力运转，不会或者尽量少的出现进程休眠的状况。

16：nginx location的语法规则：location =|_||^~ /uri/
等号：表示精确匹配，优先级最高。
^~：匹配uri路径
~：区分大小写的正则匹配
~：不区分大小写的正则匹配
!~：区分大小写的正则不匹配
!~*:不区分大小写的正则不匹配
/：通用匹配

17：nginx buffer的工作原理：
这些proxy buffer参数是作用到每一个请求的，每一个请求会按照参数的配置获得自己的buffer，在proxy开启的情况下，nginx将会尽可能的读取后端传输的所有数据到buffer，直到proxy buffer设置的所有buffer被写满或者数据读取完，此时nginx开始向客户端传输数据，会同时传输这一整串的buffer。也就是说nginx会接收完后端传输的数据，然后才开始向客户端返回数据。

18：nginx采用异步非阻塞的方式处理请求：worker进程采用异步非阻塞的方式对外提供服务，具体来说，worker进程在处理客户端请求时会进行io调用，如果调用不能立即得到响应，worker进程也不会一直等待，而是转去处理其他客户端的请求，当io调用有结果时会主动通知worker进程，worker进程得到通知便会暂停手上的工作，来处理io调用的返回结果。

19：nginx是由内核和模块组成的，它的工作流程是通过查找配置文件将客户端请求映射到一个location中，而这个location中所配置的每一个指令将会启动不同的模块去完成相应的工作。

20：nginx运行php的工作流程：
a：fastcgi进程管理器php-fpm自身初始化，然后启动一个主进程和若干个子进程。
b：当客户端请求到达nginx时，nginx通过location指令，将所有以php为后缀的文件都交给php-fpm来处理。
c：php-fpm会选择一个fastcgi子进程让它来处理请求，并把处理后的信息从同一连接返回给nginx服务器。
d：nginx接收到数据后就可以把数据返回给客户端了。

21：fastcgi是cgi的升级版，它是一个常驻内存的cgi，它会先启动一个主进程，解析配置文件，初始化执行环境，然后在启动多个子进程，当请求过来时，主进程会把请求传递给一个子进程，这样主进程就可以立即接受下一个请求，从而避免向cgi那样每次都要读取并解析配置文件、初始化执行环境等工作。

22：从原理上来说，unix socket要比tcp的方式要快，而且消耗的资源更少。因为socket是在nginx和php-fpm的进程之间直接通信的。而tcp则需要申请临时端口和tcp的相关资源。当然，unix socket没有tcp那么稳定，当并发连接时会产生大量的缓存。

23：高并发访问的核心原则其实就是把所有用户的访问请求都尽量往前推。如：能缓存在用户电脑本地的就不要让它去访问cdn，能缓存在cdn的就不要让它去访问静态服务器，能访问静态服务器的就不要去访问动态服务器。以此类推。

24：进程数与并发数并不存在很直接的关系，这取决于server采用的工作方式，如果server采用一个进程负责一个request的方式，那么进程数就是并发数，那么就会有很多进程出于等待的状态，一般是等待网络传输。而nginx异步非阻塞的工作方式正是利用了这点等待的时间。每进来一个request，会有一个worker进程去处理，但不是全程处理，处理到可能发生阻塞的地方，比如向上游服务器转发request并等待请求返回，那么此时，这个worker并不会一直处于等待的状态，它会在发送完请求后注册一个事件，然后他转去其他的request，当上一个请求有返回后触发一下刚才worker注册的事件，这个worker就会回过头来处理这个请求了。

25：apache的工作模型分类：
a：perfork模型：当进程收到用户的请求时，由主进程生成一个子进程，让子进程去处理用户的请求。perfork是基于select模型的，其最大并发只能支持1024个。
b：worker模型：当进程收到用户发来的请求时，首先会将其生成线程，通过线程来处理用户的请求。当第一个进程收到用户发来的请求时，进程会通知内核将请求的文件存储在进程里，当第二个请求到达时，对于第二个线程来说，文件已经存在并且放在同一个内核空间，所以速度上非常快。其缺点是会导致资源争用的情况，所以说一个进程不能生成太多的线程。
c：event模型。

26：一个http产生的tcp连接在传送完响应后还需要与服务器保持对少秒后才关闭这个连接