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

Posted jiguojing

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[转自SA]浅谈nginx的工作原理和使用相关的知识,希望对你有一定的参考价值。

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

以上是关于[转自SA]浅谈nginx的工作原理和使用的主要内容,如果未能解决你的问题,请参考以下文章

keepalived——keepalived工作原理(转)

路由器工作原理浅谈

TODO:浅谈pm2基本工作原理

浅谈Google蜘蛛抓取的工作原理(待更新)

浅谈Google蜘蛛抓取的工作原理(待更新)

浅谈k8s:k8s部署架构以及工作原理