【Nginx】基础概念和核心配置块

文章目录

      • 1.Nginx基础概念
      • 2.命令和信号控制
        • 2.1信号控制
        • 2.2命令控制
      • 3.Nginx核心配置文件结构
        • 3.1全局块
          • 3.1.1权限问题
          • 3.1.2work process指令
          • 3.1.3其他指令
        • 3.2event块
        • 3.3http块
          • 3.3.1定义MIME_Type
          • 3.3.2自定义服务日志
          • 3.3.3其他配置指令
        • 3.4serve和location块

1.Nginx基础概念

Nginx一个具有高性能的【HTTP】和方向代理WEB服务器,同时也是一个POP3/SMTP/IMAP代理服务器 ,由伊戈尔·赛索耶夫(俄罗斯人)使用C语言编写的。

特点:占用内存少,并发能力强。

正向代理

在了解方向代理以前,需要先明确什么是正向代理。

正向代理:如果把局域网外的Internet资源想象成一个巨大的资源库,则局域网中的客户端想要访问Internet,则需要通过代理服务器访问。这种访问方式叫做正向代理。

【Nginx】基础概念和核心配置块_第1张图片

方向代理

​ 客户端对代理是无感知的(不需要进行配置),只需要将请求发送到方向代理服务器,由反向代理服务器去选择目标服务器,获取数据后,在返回给客户端。此时反向代理服务器和目标服务器对外就是一个服务器。对外暴露的是代理服务器的地址,隐藏了真实的服务器地址。

【Nginx】基础概念和核心配置块_第2张图片

负载均衡

当请求十分频繁时,单一服务器无法解决问题(如各大电商平台的双11活动),由于摩尔定律失效,我们只能考虑增加服务器的数量,然后将请求分发到各个服务器上。将原先请求集中到单个服务器的情况,改为将请求均匀分发到各个服务器上。

动静分离

为了加快网站的解析速度,可以把动态页面和静态页面由不同的服务器来解析,加快解析的速度,降低原来服务器的压力。

【Nginx】基础概念和核心配置块_第3张图片

2.命令和信号控制

nginx可执行程序默认路径为:

/usr/local/nginx/sbin

目录结构

【Nginx】基础概念和核心配置块_第4张图片

2.1信号控制

启动nginx

./nginx

【Nginx】基础概念和核心配置块_第5张图片

  • Nginx后台进程中包含一个master进程和多个worker进程,master进程主要用来管理worker进程。包含接收外界的信息,并将接收到的信号发送给各个worker进程,监控worker进程的状态,当worker进程出现异常退出后,会自动重新启动新的worker进程。
  • 而worker进程则是专门用来处理用户请求的,各个worker进程之间是平等的并且相互独立,处理请求的机会也是一样的。

【Nginx】基础概念和核心配置块_第6张图片

作为管理员,只需要通过给master进程发送信号就可以来控制Nginx。

这个时候我们需要有两个前提条件,一个是要操作的master进程,一个是信号。

获取master进程pid的方式

  • 方法一:ps ajx | grep nginx
  • 方法二:./configure的配置参数的时候,有一个参数是–pid-path=PATH。默认值是/usr/local/nginx/logs/nginx.pid,可以通过查看该文件来获取nginx的master进程ID.

【Nginx】基础概念和核心配置块_第7张图片

信号

信号 作用
TERM/INT 立即关闭整个服
QUIT "优雅"地关闭整个
HUP 重读配置文件并
USR1 重新打开日志文
USR2 平滑升级到最新
WINCH 所有子进程不在接收处理新连接,相当于给work进程发送QUIT指令
kill -signal PID

QUIT信号和TERM信号的区别

发送QUIT信号给master进程,master进程会控制所有的work进程不再接收新的请求,等所有请求处理完后,在把进程都关闭掉。而TERM信号是强制立马终止所有的进程。

2.2命令控制

此方式是通过Nginx安装目录下的sbin下的可执行文件nginx来进行Nginx状态的控制。

【Nginx】基础概念和核心配置块_第8张图片

  • -?和-h:显示帮助信息
  • -v:打印版本号信息并退出
  • -V:打印版本号信息和配置信息并退出
  • -t:测试nginx的配置文件语法是否正确并退出
  • -T:测试nginx的配置文件语法是否正确并列出用到的配置文件信息然后
    退出
  • -q:在配置测试期间禁止显示非错误消息
  • -s:signal信号,后面可以跟 :
参数 作用
stop [快速关闭,类似于TERM/INT信号的作用]
quit [优雅的关闭,类似于QUIT信号的作用]
reopen [重新打开日志文件类似于USR1信号的作用]
reload [类似于HUP信号的作用]
-p 指定Nginx的prefix路径,(默认为: /usr/local/nginx/)
-c 指定Nginx的配置文件路径,(默认为: conf/nginx.conf)
-g 用来补充Nginx配置文件,向Nginx服务指定启动时应用全局的配置

3.Nginx核心配置文件结构

Nginx的核心配置文件默认是放在/usr/local/nginx/conf/nginx.conf 。

去掉其中的注释后,Nginx的代码如下:

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块。

3.1全局块

从配置文开始到events块之间的内容,主要设置一些影响nginx服务器整体允许的配置指令。

user指令

user:用于配置运行Nginx服务器的worker进程的用户和用户组。

语法 user user [group]
默认值 nobody
位置 全局块

【Nginx】基础概念和核心配置块_第9张图片

可以看到,默认条件下,worker进程属于nobody。

该指令的使用步骤:

1.首先设置一个用户信息

【Nginx】基础概念和核心配置块_第10张图片

2.创建一个用户

因为在我的Linux环境下,已经配置了一个west用户,所以不需要再添加west用户。如果没有要添加的用户,使用下面的指令配置。

useradd west

使用./nginx -t重新加载配置文件

【Nginx】基础概念和核心配置块_第11张图片

./nginx -s reload
ps -ef | grep nginx

用上面的指令查看现在nginx允许的进程。发现worker用户被修改为了west。

【Nginx】基础概念和核心配置块_第12张图片

3.1.1权限问题

在/root/html/index.html页面添加html源码,网页的效果为:

【Nginx】基础概念和核心配置块_第13张图片

修改配置文件

【Nginx】基础概念和核心配置块_第14张图片

  • 这里的root,表示浏览器搜索资源的起始目录
  • index:请求资源的首页信息
./nginx -t 
./nginx -s reload

通过上面的命令重新加载配置

【Nginx】基础概念和核心配置块_第15张图片

在访问时,就会发现报错403;403错误的原因是权限问题。这里worker进程的用户是west,而/root/html/index.html的所有者是root用户,所以无法访问。

将资源移动到west路径下

cp -f /root/html /home/west/

【Nginx】基础概念和核心配置块_第16张图片

修改配置文件,将根目录修改为/home/west/html,再重新加载配置文件。刷新浏览器请求后,得到了想要的页面。

【Nginx】基础概念和核心配置块_第17张图片

3.1.2work 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

【Nginx】基础概念和核心配置块_第18张图片

3.1.3其他指令

daemon:设定Nginx是否以守护进程的方式启动。

语法 daemon on|off;
默认值 daemon on;
位置 全局块

pid:用来配置Nginx当前master进程的进程号ID存储的文件路径

语法 pid file;
默认值 默认为:/usr/local/nginx/logs/nginx.pid
位置 全局块

error_log:用来配置Nginx的错误日志存放路径

语法 error_log file [日志级别];
默认值 error_log logs/error.log error;
位置 全局块、http、server、location

include:用来引入其他配置文件,使Nginx的配置更加灵活

语法 include file;
默认值
位置 any
3.2event块

影响Nginx服务器与用户网络的连接。常用的设置包括:是否开启对多work_process下的网络连接进行反序列化,是否允许同时接收多个网络连接。选取那种事件驱动模型来处理连接请求。每个work_process可以同时支持的最大连接数。

accept_mutex:用来设置Nginx网络连接序列化

语法 accept_mutex on|off;
默认值 accept_mutex on;
位置 events

作用:该配置主要用来解决惊群问题

惊群问题:

在某一个时刻,客户端发送一个请求。而Nginx后台是以多进程的工作模式,也就是说有多个worker进程会被同时唤醒,但是最终只会有一个进程可以获取连接。

如果每次唤醒的进程数目太多,就会影响Nginx整体性能。而序列化,将会对多个Nginx进程接收连接进行序列号,一个一个唤醒连接,可以防止多个进程对连接的争抢。

【Nginx】基础概念和核心配置块_第19张图片

multi_accept:用来设置是否允许同时接收多个网络连接

语法 multi_accept on|off;
默认值 multi_accept off;
位置 events

如果multi_accept被禁止了,nginx一个工作进程只能同时接受一个新的连接。否则,一个工作进程可以同时接受所有的新连接。这也是提高Nginx性能的重要配置。

worker_connections:用来配置单个worker进程最大的连接数

语法 worker_connections number;
默认值 worker_commections 512;
位置 events

【Nginx】基础概念和核心配置块_第20张图片

**use:用来设置Nginx服务器选择哪种事件驱动来处理网络消息 **

语法 use method;
默认值 根据操作系统定
位置 events

此处所选择事件处理模型是Nginx优化部分的一个重要内容, 主要的模型有selcet、poll、epoll、kqueue等。我的云服务器的默认值是epoll

3.3http块

配置最频繁的部分;代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。

3.3.1定义MIME_Type

览器中可以显示的内容有HTML、XML、GIF等种类繁多的文件、媒体等资源,浏览器为了区分这些资源,就需要使用MIMEType。

所以说MIME Type是网络资源的媒体类型。Nginx作为web服务器,也需要能够识别前端请求的资源类型。

【Nginx】基础概念和核心配置块_第21张图片

default_type:用来配置Nginx响应前端请求默认的MIME类型

语法 default_type mime-type;
默认值 default_type text/plain;
位置 http、server、location

在default_type之前还有一句include mime.types ,相当于把mime.types文件中MIMT类型与相关类型文件的文件后缀名的对应关系加入到当前的配置文件中。

配置json文件格式和text文本类型

【Nginx】基础概念和核心配置块_第22张图片

接下来依次访问对应的网址。

访问/get_json网址

【Nginx】基础概念和核心配置块_第23张图片

访问/get_text网址

【Nginx】基础概念和核心配置块_第24张图片

3.3.2自定义服务日志
  • Nginx中日志的类型分access.log、error.log。
  • access.log:用来记录用户所有的访问请求。
  • error.log:记录nginx本身运行时的错误信息,不会记录用户的访问请求。
  • Nginx服务器支持对服务日志的格式、大小、输出等进行设置,需要使用到两个指令,分别是access_log和log_format指令

access_log:用来设置用户访问日志的相关属性

语法 access_log path[format[buffer=size]]
默认值 access_log logs/access.log combined;
位置 http , server , location

log_format:用来指定日志的输出格式。

语法 log_format name [escape=default|json|none] string…;
默认 值 log_format combined “…”;
位置 http

这里的combined格式就是access_log指令中的combined格式

自定义服务日志实例

【Nginx】基础概念和核心配置块_第25张图片

【Nginx】基础概念和核心配置块_第26张图片

获取日志信息,查看是否配置成功

cat /root/html/myload.log

成功获取了日志

【Nginx】基础概念和核心配置块_第27张图片

3.3.3其他配置指令

sendfile:用来设置Nginx服务器是否使用sendfile()传输文件,该属性可以大大提高Nginx处理静态资源的性能

语法 sendfile on|off;
默认值 sendfile off;
位置 http、server、location

keepalive_timeout:用来设置长连接的超时时间。

语法 keepalive_timeout time;
默认值 keepalive_timeout 75s;
位置 http、server、location

为什么要使用keepalive?

  • 我们都知道HTTP是一种无状态协议,客户端向服务端发送一个TCP请求,服务端响应完毕后断开连接。
  • 如果客户端向服务端发送多个请求,每个请求都需要重新创建一次连接,效率相对来说会下降比较多,使用keepalive模式,可以告诉服务器端在处理完一个请求后保持这个TCP连接的打开状态,若接收到来自这个客户端的其他请求,服务端就会利用这个未被关闭的连接,而不需要重新创建一个新连接,提升效率,但是这个连接也不能一直保持,这样的话,连接如果过多,也会是服务端的性能下降,这个时候就需要我们进行设置其的超时时
    间。

**keepalive_requests:用来设置一个keep-alive连接使用的次数。 **

语法 keepalive_requests number;
默认值 keepalive_requests 100;
位置 http、server、location
3.4serve和location块

serve和location块是Nginx配置的关键配置块。详细的内容将在后面讲解

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;
	}
}	
  • root: 根目录
  • index:资源请求的首页
  • error_page:匹配的错误码

你可能感兴趣的:(中间件,nginx,服务器,运维)