2 Nginx 目录结构及配置文件详解
2.1 Nginx 目录结构分析
在使用Nginx之前,我们先对安装好的Nginx目录文件进行一个分析,在这块给大家介绍一个工具tree,通过tree我们可以很方面的去查看centos系统上的文件目录结构,当然,如果想使用tree工具,就得先通过yum install -y tree
来进行安装,安装成功后,可以通过执行tree /usr/local/nginx
(tree后面跟的是Nginx的安装目录),获取的结果如下:
-
conf:nginx所有配置文件目录
-
CGI(Common Gateway Interface)通用网关【接口】,主要解决的问题是从客户端发送一个请求和数据,服务端获取到请求和数据后可以调用调用CGI【程序】处理及相应结果给客户端的一种标准规范。
-
-
fastcgi.conf:fastcgi相关配置文件
-
fastcgi.conf.default:fastcgi.conf的备份文件
-
fastcgi_params:fastcgi的参数文件
-
fastcgi_params.default:fastcgi的参数备份文件
-
scgi_params:scgi的参数文件
-
scgi_params.default:scgi的参数备份文件
-
uwsgi_params:uwsgi的参数文件
-
uwsgi_params.default:uwsgi的参数备份文件
-
mime.types:记录的是HTTP协议中的Content-Type的值和文件后缀名的对应关系
-
mime.types.default:mime.types的备份文件
-
nginx.conf:这个是Nginx的核心配置文件,这个文件非常重要,也是我们即将要学习的重点
-
nginx.conf.default:nginx.conf的备份文件
-
koi-utf、koi-win、win-utf这三个文件都是与编码转换映射相关的配置文件,用来将一种编码转换成另一种编码
-
html:存放nginx自带的两个静态的html页面
-
50x.html:访问失败后的失败页面
-
index.html:成功访问的默认首页
-
-
logs:记录入门的文件,当nginx服务器启动后,这里面会有 access.log error.log 和nginx.pid三个文件出现。
-
sbin:是存放执行程序文件nginx
-
nginx是用来控制Nginx的启动和停止等相关的命令。
-
2.2 Nginx 服务器启停命令
Nginx安装完成后,接下来我们要学习的是如何启动、重启和停止Nginx的服务。
对于Nginx的启停在linux系统中也有很多种方式,介绍两种方式:
-
Nginx服务的信号控制
-
Nginx的命令行控制
2.2.1 Nginx服务的信号控制
前面在提到Nginx的高性能,其实也和它的架构模式有关。Nginx默认采用的是多进程的方式来工作的,当将Nginx启动后,我们通过ps -ef | grep nginx
命令可以查看到如下内容:
从上图中可以看到,Nginx后台进程中包含一个master进程和多个worker进程,master进程主要用来管理worker进程,包含接收外界的信息,并将接收到的信号发送给各个worker进程,监控worker进程的状态,当worker进程出现异常退出后,会自动重新启动新的worker进程。
而worker进程则是专门用来处理用户请求的,各个worker进程之间是平等的并且相互独立,处理请求的机会也是一样的。nginx的进程模型,我们可以通过下图来说明下:
我们现在作为管理员,只需要通过给master进程发送信号就可以来控制Nginx,这个时候我们需要有两个前提条件,一个是要操作的master进程,一个是信号。
(1)要想操作Nginx的master进程,就需要获取到master进程的进程号ID。获取方式简单介绍两个,
-
方式一:通过
ps -ef | grep nginx
; -
方式二:在讲解nginx的
./configure
的配置参数的时候,有一个参数是--pid-path=PATH
默认是/usr/local/nginx/logs/nginx.pid
,所以可以通过查看该文件来获取nginx的master进程ID.
(2)信号
信号 | 作用 |
---|---|
TERM/INT | 立即关闭整个服务 |
QUIT | "优雅"地关闭整个服务 |
HUP | 重读配置文件并使用服务对新配置项生效 |
USR1 | 重新打开日志文件,可以用来进行日志切割 |
USR2 | 平滑升级到最新版的nginx |
WINCH | 所有子进程不在接收处理新连接,相当于给work进程发送QUIT指令 |
调用命令为kill -signal PID
signal:即为信号;PID即为获取到的master线程ID
-
发送TERM/INT信号给master进程,会将Nginx服务立即关闭。
kill -TERM PID
kill -TERM `cat /usr/local/nginx/logs/nginx.pid`
kill -INT PID
kill -INT `cat /usr/local/nginx/logs/nginx.pid`
-
发送QUIT信号给master进程,master进程会控制所有的work进程不再接收新的请求,等所有请求处理完后,在把进程都关闭掉。
kill -QUIT PID
kill -TERM `cat /usr/local/nginx/logs/nginx.pid`
-
发送HUP信号给master进程,master进程会把控制旧的work进程不再接收新的请求,等处理完请求后将旧的work进程关闭掉,然后根据nginx的配置文件重新启动新的work进程
kill -HUP PID
kill -TERM `cat /usr/local/nginx/logs/nginx.pid`
-
发送USR1信号给master进程,告诉Nginx重新开启日志文件
kill -USR1 PID
kill -TERM `cat /usr/local/nginx/logs/nginx.pid`
-
发送USR2信号给master进程,告诉master进程要平滑升级,这个时候,会重新开启对应的master进程和work进程,整个系统中将会有两个master进程,并且新的master进程的PID会被记录在
/usr/local/nginx/logs/nginx.pid
而之前的旧的master进程PID会被记录在/usr/local/nginx/logs/nginx.pid.oldbin
文件中,接着再次发送QUIT信号给旧的master进程,让其处理完请求后再进行关闭
kill -USR2 PID
kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
kill -QUIT PID
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`
-
发送WINCH信号给master进程,让master进程控制不让所有的work进程在接收新的请求了,请求处理完后关闭work进程。注意master进程不会被关闭掉
kill -WINCH PID
kill -WINCH`cat /usr/local/nginx/logs/nginx.pid`
2.2.2 Nginx的命令行控制
此方式是通过Nginx安装目录下的sbin下的可执行文件nginx来进行Nginx状态的控制,我们可以通过nginx -h
来查看都有哪些参数可以用:
-?和-h:显示帮助信息
-v:打印版本号信息并退出
-V:打印版本号信息和配置信息并退出
-t:测试nginx的配置文件语法是否正确并退出
-T:测试nginx的配置文件语法是否正确并列出用到的配置文件信息然后退出
-q:在配置测试期间禁止显示非错误消息
-s:signal信号,后面可以跟 :
stop[快速关闭,类似于TERM/INT信号的作用]
quit[优雅的关闭,类似于QUIT信号的作用]
reopen[重新打开日志文件类似于USR1信号的作用]
reload[类似于HUP信号的作用]
-p:prefix,指定Nginx的prefix路径,(默认为: /usr/local/nginx/)
-c:filename,指定Nginx的配置文件路径,(默认为: conf/nginx.conf)
-g:用来补充Nginx配置文件,向Nginx服务指定启动时应用全局的配置
2.3 Nginx 服务器版本升级和新增模块
如果想对Nginx的版本进行更新,或者要应用一些新的模块,最简单的做法就是停止当前的Nginx服务,然后开启新的Nginx服务。但是这样会导致在一段时间内,用户是无法访问服务器。为了解决这个问题,我们就需要用到Nginx服务器提供的平滑升级功能。这个也是Nginx的一大特点,使用这种方式,就可以使Nginx在7*24小时不间断的提供服务了。接下来我们分析下需求:
需求:Nginx的版本最开始使用的是Nginx-1.18.0,由于服务升级,需要将Nginx的版本升级到Nginx-1.20.1,要求Nginx不能中断提供服务。
为了应对上述的需求,这里我们给大家提供两种解决方案:
-
方案一:使用Nginx服务信号完成Nginx的升级
-
方案二:使用Nginx安装目录的make命令完成升级
2.3.1 环境准备
(1)先准备两个版本的Nginx分别是 1.18.0和1.20.1
(2)使用Nginx源码安装的方式将1.18.0版本安装成功并正确访问
cd /root/nginx-1.18.0
./configure
make && make install
(3)将Nginx1.20.1进行参数配置和编译,不需要进行安装。
cd /root/nginx-1.20.1
./configure
make
2.3.2 使用Nginx服务信号进行升级
第一步:将1.18.0版本的sbin目录下的nginx进行备份
cd /usr/local/nginx/sbin
mv nginx nginx-old
第二步:将Nginx1.16.1安装目录编译后的objs目录下的nginx文件,拷贝到原来/usr/local/nginx/sbin
目录下
cd /root/nginx-1.20.1/objs
cp nginx /usr/local/nginx/sbin
第三步:发送信号USR2给Nginx的1.18.0版本对应的master进程
kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
第四步:发送信号QUIT给Nginx的1.18.0版本对应的master进程
kill -QUIT `more /usr/local/nginx/logs/nginx.pid.oldbin`
2.3.3 使用Nginx安装目录的make命令完成升级
第一步:将1.18.0版本的sbin目录下的nginx进行备份
cd /usr/local/nginx/sbin
mv nginx nginx-old
第二步:将Nginx1.20.1安装目录编译后的objs目录下的nginx文件,拷贝到原来/usr/local/nginx/sbin
目录下
cd /root/nginx-1.20.1/objs
cp nginx /usr/local/nginx/sbin
第三步:进入到安装目录,执行make upgrade
cd /root/nginx-1.20.1/
make upgrade
第四步:查看是否更新成功
./nginx -v
在整个过程中,其实Nginx是一直对外提供服务的。并且当Nginx的服务器启动成功后,我们是可以通过浏览器进行直接访问的,同时我们可以通过更改html目录下的页面来修改我们在页面上所看到的内容
2.4 Nginx 核心配置文件结构
2.4.1 全局块
Nginx的核心配置文件默认是放在/usr/local/nginx/conf/nginx.conf
,介绍下nginx.conf的内容和基本配置方法。
读取Nginx自带的Nginx配置文件,我们将其中的注释部分删除掉后,就剩下下面内容:
cd /usr/local/nginx/conf/
# 清除所有空行和注释
cat nginx.conf | grep -v "#" | grep -v "^$" > nginx2.conf
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
简单小结下:
-
nginx.conf配置文件中默认有三大块:全局块、events块、http块
-
http块中可以配置多个server块,每个server块又可以配置多个location块。
(1)user指令
user:用于配置运行Nginx服务器的worker进程的用户和用户组。
语法 | user user [group] |
---|---|
默认值 | nobody |
位置 | 全局块 |
该属性也可以在编译的时候指定,语法如下./configure --user=user --group=group
,如果两个地方都进行了设置,最终生效的是配置文件中的配置。
该指令的使用步骤:
1)设置一个用户信息"www"
sed -i "1i user gudu;" nginx.conf
2)创建一个用户
useradd gudu
3)修改user属性
user gudu;
4)创建/root/html/index.html
页面,添加如下内容
mkdir -p /root/html/
cat <<EOF> /root/html/index.heml
5)修改nginx.conf
location / {
root /root/html;
index index.html index.htm;
}
6)测试启动访问
页面会报403拒绝访问的错误
7)分析原因
因为当前用户没有访问/root/html目录的权限
8)将文件创建到 /home/gudu/html/index.html
,修改配置
location / {
root /home/gudu/html;
index index.html index.htm;
}
9)再次测试启动访问
能正常访问。
综上所述,使用user指令可以指定启动运行工作进程的用户及用户组,这样对于系统的权限访问控制的更加精细,也更加安全。
(2)work process指令
master_process:用来指定是否开启工作进程。
语法 | master_process on|off; |
---|---|
默认值 | master_process on; |
位置 | 全局块 |
worker_processes:用于配置Nginx生成工作进程的数量,这个是Nginx服务器实现并发处理服务的关键所在。理论上来说workder process的值越大,可以支持的并发处理量也越多,但事实上这个值的设定是需要受到来自服务器自身的限制,建议将该值和服务器CPU的内核数保存一致。
语法 | worker_processes num/auto; |
---|---|
默认值 | 1 |
位置 | 全局块 |
如果将worker_processes设置成2,则会看到如下内容:
(3)其他指令
1)daemon:设定Nginx是否以守护进程的方式启动。
守护式进程是linux后台执行的一种服务进程,特点是独立于控制终端,不会随着终端关闭而停止。
语法 | daemon on|off; |
---|---|
默认值 | daemon on; |
位置 | 全局块 |
2)pid:用来配置Nginx当前master进程的进程号ID存储的文件路径。
语法 | pid file; |
---|---|
默认值 | 默认为:/usr/local/nginx/logs/nginx.pid |
位置 | 全局块 |
该属性可以通过./configure --pid-path=PATH
来指定
error_log:用来配置Nginx的错误日志存放路径
语法 | error_log file [日志级别]; |
---|---|
默认值 | error_log logs/error.log error; |
位置 | 全局块、http、server、location |
该属性可以通过./configure --error-log-path=PATH
来指定
其中日志级别的值有:debug|info|notice|warn|error|crit|alert|emerg,翻译过来为试|信息|通知|警告|错误|临界|警报|紧急,这块建议大家设置的时候不要设置成info以下的等级,因为会带来大量的磁盘I/O消耗,影响Nginx的性能。
3)include:用来引入其他配置文件,使Nginx的配置更加灵活
语法 | include file; |
---|---|
默认值 | 无 |
位置 | any |
2.4.2 events块
(1)accept_mutex:用来设置Nginx网络连接序列化
语法 | accept_mutex on|off; |
---|---|
默认值 | accept_mutex on; |
位置 | events |
这个配置主要可以用来解决常说的"惊群"问题。大致意思是在某一个时刻,客户端发来一个请求连接,Nginx后台是以多进程的工作模式,也就是说有多个worker进程会被同时唤醒,但是最终只会有一个进程可以获取到连接,如果每次唤醒的进程数目太多,就会影响Nginx的整体性能。
如果将上述值设置为on(开启状态),将会对多个Nginx进程接收连接进行序列号,一个个来唤醒接收,就防止了多个进程对连接的争抢。
(2)multi_accept:用来设置是否允许同时接收多个网络连接
语法 | multi_accept on|off; |
---|---|
默认值 | multi_accept off; |
位置 | events |
如果multi_accept被禁止了,nginx一个工作进程只能同时接受一个新的连接。否则,一个工作进程可以同时接受所有的新连接
(3)worker_connections:用来配置单个worker进程最大的连接数
语法 | worker_connections number; |
---|---|
默认值 | worker_commections 512; |
位置 | events |
这里的连接数不仅仅包括和前端用户建立的连接数,而是包括所有可能的连接数。另外,number值不能大于操作系统支持打开的最大文件句柄数量。
(4)use:用来设置Nginx服务器选择哪种事件驱动来处理网络消息。
语法 | use method; |
---|---|
默认值 | 根据操作系统定 |
位置 | events |
注意:此处所选择事件处理模型是Nginx优化部分的一个重要内容,method的可选值有select/poll/epoll/kqueue等,之前在准备centos环境的时候,我们强调过要使用linux内核在2.6以上,就是为了能使用epoll函数来优化Nginx。
另外这些值的选择,我们也可以在编译的时候使用
--with-select_module
--without-select_module
--with-poll_module
--without-poll_module
来设置是否需要将对应的事件驱动模块编译到Nginx的内核。
events指令配置实例
打开Nginx的配置文件 nginx.conf,添加如下配置
events{
accept_mutex on;
multi_accept on;
worker_commections 1024;
use epoll;
}
启动测试
./nginx -t
./nginx -s reload
2.4.3 http块
(1)定义MIME-Type
我们都知道浏览器中可以显示的内容有HTML、XML、GIF等种类繁多的文件、媒体等资源,浏览器为了区分这些资源,就需要使用MIME Type。所以说MIME Type是网络资源的媒体类型。Nginx作为web服务器,也需要能够识别前端请求的资源类型。
在Nginx的配置文件中,默认有两行配置
include mime.types;
default_type application/octet-stream;
default_type:用来配置Nginx响应前端请求默认的MIME类型。
语法 | default_type mime-type; |
---|---|
默认值 | default_type text/plain; |
位置 | http、server、location |
在default_type之前还有一句include mime.types
,include之前我们已经介绍过,相当于把mime.types文件中MIMT类型与相关类型文件的文件后缀名的对应关系加入到当前的配置文件中。
举例说明:
有些时候请求某些接口的时候需要返回指定的文本字符串或者json字符串,如果逻辑非常简单或者干脆是固定的字符串,那么可以使用nginx快速实现,这样就不用编写程序响应请求了,可以减少服务器资源占用并且响应性能非常快。
如何实现:
location /get_text {
#这里也可以设置成text/plain
default_type text/html;
return 200 "This is nginx's text";
}
location /get_json{
default_type application/json;
return 200 '{"name":"TOM","age":18}';
}
(2)自定义服务日志
Nginx中日志的类型分access.log、error.log。
-
access.log:用来记录用户所有的访问请求。
-
error.log:记录nginx本身运行时的错误信息,不会记录用户的访问请求。
Nginx服务器支持对服务日志的格式、大小、输出等进行设置,需要使用到两个指令,分别是access_log和log_format指令。
1)access_log:用来设置用户访问日志的相关属性。
语法 | access_log path[format[buffer=size]] |
---|---|
默认值 | access_log logs/access.log combined; |
位置 | http , server , location |
2)log_format:用来指定日志的输出格式。
语法 | log_format name [escape=default|json|none] string....; |
---|---|
默认值 | log_format combined "..."; |
位置 | http |
(3)其他配置指令
1)sendfile:用来设置Nginx服务器是否使用sendfile()传输文件,该属性可以大大提高Nginx处理静态资源的性能
语法 | sendfile on|off; |
---|---|
默认值 | sendfile off; |
位置 | http、server、location |
2)keepalive_timeout:用来设置长连接的超时时间。
我们都知道HTTP是一种无状态协议,客户端向服务端发送一个TCP请求,服务端响应完毕后断开连接。
如何客户端向服务端发送多个请求,每个请求都需要重新创建一次连接,效率相对来说比较多,使用keepalive模式,可以告诉服务器端在处理完一个请求后保持这个TCP连接的打开状态,若接收到来自这个客户端的其他请求,服务端就会利用这个未被关闭的连接,而不需要重新创建一个新连接,提升效率,但是这个连接也不能一直保持,这样的话,连接如果过多,也会是服务端的性能下降,这个时候就需要我们进行设置其的超时时间。
语法 | keepalive_timeout time; |
---|---|
默认值 | keepalive_timeout 75s; |
位置 | http、server、location |
3)keepalive_requests:用来设置一个keep-alive连接使用的次数。
语法 | keepalive_requests number; |
---|---|
默认值 | keepalive_requests 100; |
位置 | http、server、location |
2.4.4 server块和location块
server块和location块都是我们要重点讲解和学习的内容,因为我们后面会对Nginx的功能进行详细讲解,所以这块内容就放到静态资源部署的地方给大家详细说明。
主要来认识下Nginx默认给的nginx.conf中的相关内容,以及server块与location块在使用的时候需要注意的一些内容。
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
error_page 500 502 503 504 404 /50x.html;
location = /50x.html {
root html;
}
}