原文地址:https://program-park.github.io/2022/04/15/nginx_4/
在使用 Nginx 之前,我们先对安装好的 Nginx 目录文件进行一个分析,在这块给大家介绍一个工具 tree,通过 tree 我们可以很方面的去查看 centos 系统上的文件目录结构,当然,如果想使用 tree 工具,就得先通过yum install -y tree
来进行安装,安装成功后,可以通过执行tree /usr/local/nginx
(tree 后面跟的是 Nginx 的安装目录),获取的结果如下:
前面已经说过,Nginx 的核心配置文件默认是放在/usr/local/nginx/conf/nginx.conf
,下面我们就来说一下nginx.conf的内容和基本配置方法。
读取 Nginx 自带的 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服务器整体运行的配置指令
# events块,主要设置,Nginx服务器与用户的网络连接,这一部分对Nginx服务器的性能影响较大
events {
指令名 指令值;
}
# http块,是Nginx服务器配置中的重要部分,代理、缓存、日志记录、第三方模块配置...
http {
指令名 指令值;
server { # server块,是Nginx配置和虚拟主机相关的内容
指令名 指令值;
location / {
# location块,基于Nginx服务器接收请求字符串与location后面的值进行匹配,对特定请求进行处理
指令名 指令值;
}
}
...
}
nginx.conf 配置文件中默认有三大块:全局块
、events块
、http块
。
http 块中可以配置多个 server 块,每个 server 块又可以配置多个 location 块。
user: 用于配置运行 Nginx 服务器的 worker 进程的用户和用户组。
语法 | user user [group] |
---|---|
默认值 | nobody |
位置 | 全局块 |
该属性也可以在编译的时候指定,语法如下./configure --user=user--group=group
,如果两个地方都进行了设置,最终生效的是配置文件中的配置。
使用 user 指令可以指定启动运行工作进程的用户及用户组,这样对于系统的权限访问控制的更加精细,也更加安全。
master_process: 用来指定是否开启工作进程。
语法 | master_process on|off |
---|---|
默认值 | master_process on |
位置 | 全局块 |
worker_processes: 用于配置 Nginx 生成工作进程的数量,这个是 Nginx 服务器实现并发处理服务的关键所在。理论上来说 workder process 的值越大,可以支持的并发处理量也越多,但事实上这个值的设定是需要受到来自服务器自身的限制,建议将该值和服务器 CPU 的内核数保存一致。
语法 | worker_processes num/auto |
---|---|
默认值 | 1 |
位置 | 全局块 |
如果将 worker_processes 设置成 2,则会看到如下内容:
daemon: 设定 Nginx 是否以守护进程的方式启动。
守护式进程是 linux 后台执行的一种服务进程,特点是独立于控制终端,不会随着终端关闭而停止。
语法 | daemon on|off |
---|---|
默认值 | daemon on |
位置 | 全局块 |
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 的性能。
include: 用来引入其他配置文件,使 Nginx 的配置更加灵活。
语法 | include file |
---|---|
默认值 | 无 |
位置 | any |
accept_mutex: 用来设置 Nginx 网络连接序列化。
语法 | accept_mutex on|off |
---|---|
默认值 | accept_mutex on |
位置 | events |
这个配置主要可以用来解决常说的 “惊群” 问题。大致意思是在某一个时刻,客户端发来一个请求连接,Nginx 后台是以多进程的工作模式,也就是说有多个 worker 进程会被同时唤醒,但是最终只会有一个进程可以获取到连接,如果每次唤醒的进程数目太多,就会影响 Nginx 的整体性能。如果将上述值设置为 on(开启状态),将会对多个 Nginx 进程接收连接进行序列号,一个个来唤醒接收,就防止了多个进程对连接的争抢。
multi_accept: 用来设置是否允许同时接收多个网络连接。
语法 | multi_accept on|off |
---|---|
默认值 | multi_accept off |
位置 | events |
如果 multi_accept 被禁止了,Nginx 一个工作进程只能同时接受一个新的连接。否则,一个工作进程可以同时接受所有的新连接。 | |
worker_connections: 用来配置单个 worker 进程最大的连接数。 | |
语法 | worker_connections number |
— | — |
默认值 | worker_commections 512 |
位置 | events |
这里的连接数不仅仅包括和前端用户建立的连接数,而是包括所有可能的连接数。另外,number 值不能大于操作系统支持打开的最大文件句柄数量。 | |
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 的内核。 |
打开 Nginx 的配置文件 nginx.conf,添加如下配置:
events{
accept_mutex on;
multi_accept on;
worker_commections 1024;
use epoll;
}
启动测试:
./nginx -t
./nginx -s reload
我们都知道浏览器中可以显示的内容有 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}';
}
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 |
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 |
server 块和 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;
}
}
Nginx 在决定请求由哪个 server 块执行时,主要关注的是 server 块中的listen
和server_name
两个字段。
listen 字段定义 server 响应的 ip 和端口,如果没有明确配置 listen 字段,默认监听0.0.0.0:80
(root 用户运行)或者0.0.0.0:8080
(非 root 用户运行)。
listen 可以被配置为:
其中最后一项通常只用于在不同的 server 之间传递请求。
选择要使用的 server 的规则如下:
listen 0.0.0.0:80
,listen 1.1.1.1
转换为listen 1.1.1.1:80
等;listen 0.0.0.0
的这种 server 块,但是无论是哪种情况,端口必须是完全匹配的;server_name
指令;重要的是要理解,Nginx 仅 server_name 在需要区分与 listen 指令中特定级别的匹配的 server 块时才评估指令。比如下面的例子,如果 example.com 托管在 192.168.1.10 的端口 80 上,example.com 则在本示例中,尽管 server_name 第二个块中有指令,但对第一个块的请求始终会得到满足。
server {
listen 192.168.1.10;
. . .
}
server {
listen 80;
server_name example.com;
. . .
}
如果多个 server 块以相同的特异性匹配,则下一步是检查 server_name 指令。
如果根据 listen 指令无法得到最佳匹配,将会开始解析 server_name 指令。Nginx 会检查请求中的 “Host” 头,这个值包含了客户端实际试图请求的域名或者 ip 地址,Nginx 会根据这个值去匹配 server_name 指令,匹配规则如下:
*
开头的 server 块,如果找到多个,则选择最长匹配的 server 块;*
开头的 server 块,则会寻找以*
结尾的 server 块,同样,如果有多个匹配,选择最长匹配;*
匹配的 server 块,则会寻找使用正则表达式(以~开头)定义 server_name 的 server 块,如果找到多个匹配,会使用第一个匹配;示例如下:
server {
listen 80;
server_name www.domain.com;
. . .
}
*
通配符开始的字符串:server {
listen 80;
server_name *.domain.com;
. . .
}
*
通配符结束的字符串:server {
listen 80;
server_name www.*;
. . .
}
server {
listen 80;
server_name ~^(?.+).domain.com$;
. . .
}
server {
listen 80 default_server;
server_name _;
return 444;
}
通过返回 444 这个 Nginx 的非标准错误码让 Nginx 断开与浏览器的连接。 如果存在 server_name 与 “Host” 头值完全匹配的定义,则选择该服务器块来处理请求。
在此示例中,如果请求的 “Host” 头设置为host1.example.com
,则将选择第二台服务器:
server {
listen 80;
server_name *.example.com;
. . .
}
server {
listen 80;
server_name host1.example.com;
. . .
}
如果找不到完全匹配的内容,则 Nginx 然后检查是否存在 server_name 带有合适的起始通配符。以通配符开头的最长匹配将被选择来满足请求。
在此示例中,如果请求的 “Host” 头为www.example.org
,则将选择第二个服务器块:
server {
listen 80;
server_name www.example.*;
. . .
}
server {
listen 80;
server_name *.example.org;
. . .
}
server {
listen 80;
server_name *.org;
. . .
}
如果找不到与起始通配符匹配的内容,则 Nginx 将在表达式末尾使用通配符查看是否存在匹配项。此时,将选择以通配符结尾的最长匹配来满足请求。
例如,如果请求的 “Host” 标头设置为www.example.com
,则将选择第三个服务器块:
server {
listen 80;
server_name host1.example.com;
. . .
}
server {
listen 80;
server_name example.com;
. . .
}
server {
listen 80;
server_name www.example.*;
. . .
}
如果找不到通配符匹配项,则 Nginx 将继续尝试匹配 server_name 使用正则表达式的指令。所述第一匹配正则表达式将被选择,以响应该请求。
例如,如果请求的 “Host” 标头设置为www.example.com
,则将选择第二个服务器块以满足请求:
server {
listen 80;
server_name example.com;
. . .
}
server {
listen 80;
server_name ~^(www|host1).*.example.com$;
. . .
}
server {
listen 80;
server_name ~^(subdomain|set|www|host1).*.example.com$;
. . .
}
如果以上步骤均不能满足请求,则该请求将被传递到默认服务器以获取匹配的 IP 地址和端口。
location 块位于server 块(或其他 location 块)中,用于决定如何处理请求 URI(请求的一部分,位于域名或 IP 地址/端口之后)。
位置块通常采用以下形式:
location optional_modifier location_match {
. . .
}
在上面的 location_match 定义了 Nginx 应该针对什么样的请求 URI 检查。上例中修饰符的存在或不存在会影响 Nginx 尝试匹配 location 块的方式。
不同修饰符对 location 块的影响解释如下:
无
:如果不存在修饰符,则该位置将解释为前缀匹配。这意味着给定的 location 将与请求 URI 的开头进行匹配以确定匹配;=
:精确匹配,如果使用等号,则如果请求 URI 完全匹配给定的位置,则此块将被视为匹配;~
:如果存在波浪号修饰符,则此位置将被解释为区分大小写的正则表达式匹配(大小写敏感正则匹配);~*
:如果使用波浪号和星号修饰符,则位置块将被解释为不区分大小写的正则表达式匹配;^~
:如果存在 carat 和 tilde 修饰符,并且如果此块被选为最佳非正则表达式匹配,则不继续匹配后面的(前缀匹配)。 作为前缀匹配的一个例子,以下 location 块可以被选择为响应于请求的 URI 的样子/site
,/site/page1/index.html
或/site/index.html
:
location /site {
. . .
}
为了演示精确的请求 URI 匹配,此块将始终用于响应类似于/page1
。它不会用于响应/page1/index.html
请求 URI。请记住,如果选择此块并使用索引页完成请求,则内部重定向将发生到另一个位置,该位置将成为请求的实际处理程序:
location = /page1 {
. . .
}
作为应区分大小写的正则表达式的 location 示例,此块可用于处理对/tortoise.jpg
的请求,但不能用于处理/FLOWER.PNG
:
location ~ .(jpe?g|png|gif|ico)$ {
. . .
}
下面是一个类似于上面的不区分大小写的匹配块。在这里,无论是/tortoise.jpg
和/FLOWER.PNG
都可以通过此块处理:
location ~* .(jpe?g|png|gif|ico)$ {
. . .
}
最后,如果确定为最佳非正则表达式匹配,则此块将防止正则表达式匹配发生。它可以处理以下请求/costumes/ninja.html
:
location ^~ /costumes {
. . .
}
如上所述,修饰符对 location 块的不同影响。但是,这并没有告诉我们 Nginx 用于确定将请求发送到哪个 location 块的算法。
类似于 Nginx 用来选择处理请求的服务器块的过程,Nginx 也有一个既定的算法来决定服务器中的哪个 location 块用于处理请求。
Nginx 选择将用于为请求提供 server 的 location,其方式与它选择 server 块的方式类似。它通过一个过程来确定任何给定请求的最佳 location 块。了解这个过程是能够可靠、准确地配置 Nginx 的关键要求。
考虑到我们上面描述的 location 声明的类型,Nginx 通过将请求 URI 与每个 location 进行比较来评估可能的 location 上下文。它使用以下算法执行此操作:
=
修饰符的 location 块与请求 URI 完全匹配,则立即选择该位置块来处理请求;=
修饰符)位置块匹配,Nginx 然后继续评估非精确前缀。它发现给定请求 URI 的最长匹配前缀位置,然后按如下方式评估:
^~
修饰符,则 Nginx 将立即结束其搜索并选择此 location 来满足请求;^~
修饰符,则该匹配项暂时由 Nginx 存储,以便可以移动搜索的焦点; 这里要理解的是,默认情况下,Nginx 将优先于前缀匹配提供正则表达式匹配。但是,它首先评估前缀位置,允许管理员通过使用=
和^~
修饰符指定位置来覆盖这种趋势。
同样要注意的是,尽管前缀 location 通常是根据最长,最具体的匹配选择的,但是当找到第一个匹配的 location 时,正则表达式评估就会停止。这意味着配置中的定位对于正则表达式 location 具有广泛的意义。
最后,重要的是要理解,当 Nginx 评估正则表达式 location 时,最长前缀匹配内的正则表达式匹配将 “插队”。在考虑其他任何正则表达式匹配项之前,将按顺序评估这些值。
location /test {
...
}
location /test/ {
...
}
/
:当访问 ip 地址 /test 时, Nginx 先找是否有 test 目录,如果有则找 test 目录下的 index.html;如果没有 test 目录, nginx 则会找是否有 test 文件;/
:当访问 ip 地址 /test 时, Nginx 先找是否有 test 目录,如果有则找 test 目录下的 index.html,如果没有它也不会去找是否存在 test 文件。root: 设置请求的根目录。
语法 | root path |
---|---|
默认值 | root html |
位置 | http、server、location |
path 为 Nginx 服务器接收到请求以后查找资源的根目录路径。 | |
alias: 用来更改 location 的 URI。 | |
语法 | alias path |
— | — |
默认值 | - |
位置 | location |
path 为修改后的根路径。 | |
以上两个指令都可以来指定访问资源的路径,那么这两者之间的区别是什么? | |
举例说明: |
/usr/local/nginx/html
目录下创建一个images
目录,并在目录下放入一张图片mv.png
图片:location /images {
root /usr/local/nginx/html;
}
访问图片的路径为:http://localhost/images/mv.png
location /images {
alias /usr/local/nginx/html;
}
再次访问上述地址,页面会出现 404 的错误,查看错误日志会发现是因为地址不对,所以验证了:root的处理结果是: root路径+location路径
/usr/local/nginx/html/images/mv.png
alias的处理结果是:使用alias路径替换location路径
/usr/local/nginx/html/images
需要在 alias 后面路径改为:location /images {
alias /usr/local/nginx/html/images;
}
/
结尾,则 alias 也必须是以/
结尾,root 没有要求,将上述配置修改为:location /images/ {
alias /usr/local/nginx/html/images;
}
访问就会出问题,查看错误日志还是路径不对,所以需要把 alias 后面加上/
。总结:
root的处理结果是: root路径+location路径
alias的处理结果是:使用alias路径替换location路径
alias是一个目录别名的定义,root则是最上层目录的含义。
如果location路径是以/结尾,则alias也必须是以/结尾,root没有要求
index: 设置网站的默认首页。
语法 | index file … |
---|---|
默认值 | index index.html |
位置 | http、server、location |
index 后面可以跟多个设置,如果访问的时候没有指定具体访问的资源,则会依次进行查找,找到第一个为止。 | |
举例说明: |
location / {
root /usr/local/nginx/html;
index index.html index.htm;
}
访问该 location 的时候,可以通过http://ip:port/
,地址后面如果不添加任何内容,则默认依次访问index.html
和index.htm
,找到第一个来进行返回。
error_page: 设置网站的错误页面。
语法 | error_page code … [=[response]] uri |
---|---|
默认值 | - |
位置 | http、server、location… |
当出现对应的响应code后,如何来处理。 | |
举例说明: |
server {
error_page 404 http://www.itcast.cn;
}
server{
error_page 404 /50x.html;
error_page 500 502 503 504 /50x.html;
location =/50x.html{
root html;
}
}
server{
error_page 404 @jump_to_error;
location @jump_to_error {
default_type text/plain;
return 404 'Not Found Page...';
}
}
可选项=[response]
的作用是用来将相应代码更改为另外一个server{
error_page 404 =200 /50x.html;
location =/50x.html{
root html;
}
}
这样的话,当返回 404 找不到对应的资源的时候,在浏览器上可以看到,最终返回的状态码是 200,这块需要注意下,编写 error_page 后面的内容,404 后面需要加空格,200 前面不能加空格。 【1】https://www.bilibili.com/video/BV1yS4y1N76R?spm_id_from=333.337.search-card.all.click
【2】https://www.bilibili.com/video/BV1ov41187bq?spm_id_from=333.337.search-card.all.click
【3】https://www.bnskd.com/2813.html
【4】http://www.lmonkey.com/t/2zLAPYMyW
【5】https://my.oschina.net/python8/blog/5373448
【6】https://blog.csdn.net/qq_22783587/article/details/118891858
【7】https://blog.csdn.net/cr7258/article/details/117486459