[转自SA]浅谈nginx的工作原理和使用

Posted 2020-09-21 jiguojing

nginx apache 简单对比

nginx 相对 apache 的优点：

• 轻量级，同样起web 服务，比apache 占用更少的内存及资源
• 抗并发，nginx 处理请求是异步非阻塞的，而 apache 则是阻塞型的，在高并发下 nginx 能保持低资源低消耗高性能
• 高度模块化的设计，编写模块相对简单
• 社区活跃
• 配置简洁

apache 相对nginx 的优点：

• rewrite ，比 nginx 的 rewrite 强大
• 模块超多
• 少 bug ，nginx 的 bug 相对较多
• 超稳定
• 配置复杂

一般来说，求性能，用 nginx 。求稳定，用 apache 。

初探nginx架构

nginx的高性能与其架构是分不开的。

nginx在启动后，在类unix系统中会以daemon的方式在后台运行，后台进程包含一个master进程和多个worker进程。

1、master进程主要用来管理worker进程：

1）接收来自外界的信号；

2）向各worker进程发送信号；

3）监控worker进程的运行状态；

4）当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。

2、worker进程中处理基本的网络事件：

多个worker进程之间对等，他们同等竞争来自客户端的请求，各进程之间相互独立。

一个请求，只可能在一个worker进程中处理。worker进程个数一般我们会设置与机器cpu核数一致。

3、通过信号控制 master 进程：

1）kill -HUP pid，从容地重启 nginx（不中断服务）。

master 进程在接到信号后，会先重新加载配置文件，然后再启动新的 worker 进程，并向所有老的 worker 进程发送信号，告诉他们可以光荣退休了。

新的 worker 在启动后，就开始接收新的请求，而老的 worker 在收到来自 master 的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。

2）./nginx -s reload （0.8版本后新的平滑重启命令）

3）./nginx -s stop，停止 nginx 运行。

4、worker进程工作原理：

每个worker进程都是从master进程fork过来。

在master进程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多个worker进程。所有worker进程的listenfd会在新连接到来时变得可读。

为保证只有一个进程处理该连接，所有worker进程在注册listenfd读事件前抢accept_mutex，抢到互斥锁的那个进程注册listenfd读事件，在读事件里调用accept接受该连接。

当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，一个完整的请求就是这样。

所以一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。

5、高并发原理：

nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？

非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。

异步非阻塞的事件处理机制，具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。

请求过来，要建立连接，然后再接收数据，接收数据后，再发送数据。具体到系统底层，就是读写事件。

拿epoll为例，当事件没准备好时，放到epoll里面，事件（对于一个基本的web服务器来说，事件通常有三种类型，网络事件、信号、定时器）准备好了，我们就去读写，当读写返回EAGAIN时，我们将它再次加入到epoll里面。这样，只要有事件准备好了，我们就去处理它，只有当所有事件都没准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了。

当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。

与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已。

nginx基础概念

connection

在nginx中connection就是对tcp连接的封装，其中包括连接的socket，读事件，写事件。利用nginx封装的connection，我们可以很方便的使用nginx来处理与连接相关的事情，比如，建立连接，发送与接受数据等。而nginx中的http请求的处理就是建立在connection之上的，所以nginx不仅可以作为一个web服务器，也可以作为邮件服务器。当然，利用nginx提供的connection，我们可以与任何后端服务打交道。

结合一个tcp连接的生命周期，我们看看nginx是如何处理一个连接的。首先，nginx在启动时，会解析配置文件，得到需要监听的端口与ip地址，然后在nginx的master进程里面，先初始化好这个监控的socket(创建socket，设置addrreuse等选项，绑定到指定的ip地址端口，再listen)，然后再fork出多个子进程出来，然后子进程会竞争accept新的连接。此时，客户端就可以向nginx发起连接了。当客户端与服务端通过三次握手建立好一个连接后，nginx的某一个子进程会accept成功，得到这个建立好的连接的socket，然后创建nginx对连接的封装。接着，设置读写事件处理函数并添加读写事件来与客户端进行数据的交换。最后，nginx或客户端来主动关掉连接，到此，一个连接就寿终正寝了。

request

request，在nginx中我们指的是http请求，包含请求行、请求头、请求体、响应行、响应头、响应体。

nginx的配置系统

nginx的配置系统由一个主配置文件和其他一些辅助的配置文件构成。这些配置文件均是纯文本文件，全部位于nginx安装目录下的conf目录下。

配置文件中以#开始的行，或者是前面有若干空格或者TAB，然后再跟#的行，都被认为是注释，也就是只对编辑查看文件的用户有意义，程序在读取这些注释行的时候，其实际的内容是被忽略的。

由于除主配置文件nginx.conf以外的文件都是在某些情况下才使用的，而只有主配置文件是在任何情况下都被使用的。所以在这里我们就以主配置文件为例，来解释nginx的配置系统。

在nginx.conf中，包含若干配置项。每个配置项由配置指令和指令参数2个部分构成。指令参数也就是配置指令对应的配置值。

指令上下文

nginx.conf中的配置信息，根据其逻辑上的意义，对它们进行了分类，也就是分成了多个作用域，或者称之为配置指令上下文。不同的作用域含有一个或者多个配置项。

当前nginx支持的几个指令上下文：

main:

nginx在运行时与具体业务功能（比如http服务或者email服务代理）无关的一些参数，比如工作进程数，运行的身份等。

http:

与提供http服务相关的一些配置参数。例如：是否使用keepalive啊，是否使用gzip进行压缩等。

server:

http服务上支持若干虚拟主机。每个虚拟主机一个对应的server配置项，配置项里面包含该虚拟主机相关的配置。在提供mail服务的代理时，也可以建立若干server.每个server通过监听的地址来区分。

location:

http服务中，某些特定的URL对应的一系列配置项。

mail:

实现email相关的SMTP/IMAP/POP3代理时，共享的一些配置项。

存在于main上下文中的配置指令如下:

• user
• worker_processes
• error_log
• events
• http
• mail

存在于http上下文中的指令如下:

• server

存在于mail上下文中的指令如下：

• server
• auth_http
• imap_capabilities

存在于server上下文中的配置指令如下：

• listen
• server_name
• access_log
• location
• protocol
• proxy
• smtp_auth

存在于location上下文中的指令如下：

• index
• root

请求的处理流程

NGX_HTTP_POST_READ_PHASE:读取请求内容阶段

NGX_HTTP_SERVER_REWRITE_PHASE:Server请求地址重写阶段

NGX_HTTP_FIND_CONFIG_PHASE:配置查找阶段

NGX_HTTP_REWRITE_PHASE:Location请求地址重写阶段

NGX_HTTP_POST_REWRITE_PHASE:请求地址重写提交阶段

NGX_HTTP_PREACCESS_PHASE:访问权限检查准备阶段

NGX_HTTP_ACCESS_PHASE:访问权限检查阶段

NGX_HTTP_POST_ACCESS_PHASE:访问权限检查提交阶段

NGX_HTTP_TRY_FILES_PHASE:配置项try_files处理阶段

NGX_HTTP_CONTENT_PHASE:内容产生阶段

NGX_HTTP_LOG_PHASE:日志模块处理阶段

nginx location匹配简介

= 严格匹配。如果这个查询匹配，那么将停止搜索并立即处理此请求。

~ 为区分大小写匹配(可用正则表达式)

!~为区分大小写不匹配

~* 为不区分大小写匹配(可用正则表达式)

!~*为不区分大小写不匹配

^~ 如果把这个前缀用于一个常规字符串,那么告诉nginx 如果路径匹配那么不测试正则表达式。

location  = / {

  # 精确匹配 / ，主机名后面不能带任何字符串

  [ configuration A ] 

}

location  / {

  # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求

  # 但是正则和最长字符串会优先匹配

  [ configuration B ] 

}

location /documents/ {

  # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索

  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条

  [ configuration C ] 

}

location ~ /documents/Abc {

  # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索

  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条

  [ configuration CC ] 

}

location ^~ /images/ {

  # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。

  [ configuration D ] 

}

location ~* \.(gif|jpg|jpeg)$ {

  # 匹配所有以 gif,jpg或jpeg 结尾的请求

  # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则

  [ configuration E ] 

}

location /images/ {

  # 字符匹配到 /images/，继续往下，会发现 ^~ 存在

  [ configuration F ] 

}

location /images/abc {

  # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在

  # F与G的放置顺序是没有关系的

  [ configuration G ] 

}

location ~ /images/abc/ {

  # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用

    [ configuration H ] 

}

location ~* /js/.*/\.js