Nginx的配置文件说明
Nginx配置文件的主要配置块可以分为三个部分：全局配置块（events和http块），events块和http块。这三个部分共同定义了Nginx服务器的整体行为和处理HTTP请求的方式。
全局配置块：
包含了影响Nginx服务器整体行为的指令，如进程数、工作目录、错误日志级别、进程ID文件路径、用户和组设置等。
全局配置块中的指令对整个Nginx服务器实例生效。
events 块：
处理Nginx服务器与客户端的连接事件。
定义了工作进程数、连接数限制等影响服务器性能和稳定性的参数。
events块通常位于全局配置块内，也可以单独作为一个块。
http 块：
处理HTTP请求，是Nginx配置的核心部分。
包括了解析请求、生成响应、日志记录等指令。
http块可以包含多个子块，如server、location、upstream等，这些子块分别用于配置服务器设置、请求处理位置和后端服务器集群
nginx.conf配置文件说明
```powershell
指令名 指令值; #全局块，主要设置Nginx服务器整体运行的配置指令 在event和http之外的都是全局块
#events块,主要设置,Nginx服务器与用户的网络连接
events {
指令名 指令值;
}
#http块，是Nginx服务器配置中的重要部分，代理、缓存、日志记录、第三方模块配置...
http {
指令名 指令值;
server { #server块，是Nginx配置和虚拟主机相关的内容
指令名 指令值;
location / {
#location块，基于Nginx服务器接收请求字符串与location后面的值进行匹配，对特定请求进行处理
指令名 指令值;
}
}
...
}
``
nginx.conf配置文件中默认有三大块：全局块、events块、http块
http块中可以配置多个server块，每个server块又可以配置多个location块。
全局块
1.user:用于配置运行Nginx服务器的worker进程的用户和用户组。
| 语法 | user user [group] |
|---|---|
| 默认值 | nobody |
| 位置 | 全局块 |
修改user配置 用户必须是存在Linux中的
如果没有用户可以通过以下命令创建一个
useradd jackwade
测试配置效果
在/root/html/下创建index.html页面，添加如下内容
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
<p><em>I am iron man</em></p>
</body>
</html>
修改nginx.conf配置文件
在对应http下的server模块下添加location配置如下：
./nginx -s reload 执行重载配置文件命令
访问也会提示403，没有权限
复制cp index.html /home/jackwade/html/
然后再次修改nginx.conf
location / {
#root html;
root /home/jackwade/html;
index index.html index.htm;
}
./nginx -s reload 重新加载配置文件
访问页面
通过ps -ef | grep nginx命令查看进程 ，可以看到工作进程是"jackwade"
通过上面的测试，使用user指令可以指定启动运行工作进程的用户及用户组。
work process
master_process:用于关闭 Nginx 的主进程模式，使其只运行一个单一的工作进程.
| 语法 | master_process [on off] |
|---|---|
| 默认值 | master_process on; |
| 位置 | 全局块 |
master_process off;
作用：master_process:用于关闭 Nginx 的主进程模式，使其只运行一个单一的工作进程
- 性能影响: 关闭主进程模式会导致 Nginx 只运行一个单一的工作进程，从而不能充分利用多核处理器的优势，影响性能。
- 稳定性: 在生产环境中使用 master_process off; 可能会影响 Nginx 的稳定性和可扩展性，因此一般不建议在生产环境中使用。
- 调试用途: master_process off; 常用于开发和调试环境，以简化调试过程和配置测试
关闭后需要重启生效，查看进程里面则没有相应的Master和worker进程
关闭后查看效果 ps -ef | grep nginx
worker_processes
用于定义 Nginx 启动多少个工作进程。通常，设置为与服务器 CPU 核心数相同，以便充分利用多核处理器。
| 语法 | worker_processes [number|auto] |
|---|---|
| 默认值 | worker_processes 1; |
| 位置 | 全局块 |
设置工作进程 worker_processes 2;
如果master_process off； 则worker processes 2 设置无效，将之前设置的master_process 注释掉。
同样的该设置需要重新启动才能生效
重启
设置后的效果
auto :设置成auto会自动适当的工作进程数，一般等于机器的 CPU 核心数。
daemon守护进程
daemon 指令用于控制 Nginx 是否以守护进程方式运行。默认情况下，Nginx 是以守护进程方式运行的。守护进程不会随着终端关闭而停止。
| 语法 | daemon [on | off] |
|---|---|
| 默认值 | daemon on; |
| 示例 | daemon off; |
| 位置 | 全局块 |
pid
用来配置Nginx当前master进程的进程号ID存储的文件路径。
| 语法 | pid [文件路径] |
|---|---|
| 默认值 | pid /usr/local/nginx/logs/nginx.pid |
| 位置 | 全局块、http、server、location |
error_log
用来配置Nginx的错误日志存放路径
| 语法 | error_log [文件路径] [级别] |
|---|---|
| 默认值 | error_log /var/log/nginx/error.log warn; |
| 示例 | error_log /var/log/nginx/error.log debug; |
| 位置 | 全局块、http、server、location |
该属性也可以通过./configure --error-log-path=[PATH]来指定
其中日志级别的值有：debug|info|notice|warn|error|crit|alert|emerg，翻译过来为调试|信息|通知|警告|错误|临界|警报|紧急，这块建议设置的时候不要设置成info以下的等级，因为会带来大量的磁盘I/O消耗，影响Nginx的性能。
include
| 语法 | include [文件路径] |
|---|---|
| 默认值 | 无 |
| 示例 | include /etc/nginx/conf.d/*.conf; |
| 位置 | 全局块 |
使用 include指令可以包含指定的配置文件中的配置内容到当前的配置文件中
例如我们include 一个 nginx_main.conf
nginx_main.conf配置内容如下
在全局块中添加include
测试配置文件
重新加载文件 nginx -s reload
查看进程,可以看到是4个jackwade进程，表明引入成功
http块配置说明
http块
定义MIME-Type
Nginx 的 mime.types 配置文件用于定义文件扩展名与 MIME 类型之间的映射。MIME 类型（Multipurpose Internet Mail Extensions）是一种标准，用于描述文件的类型和格式。通过将文件扩展名与适当的 MIME 类型关联，Nginx 能够正确地告诉浏览器如何处理和显示文件。
在Nginx的配置文件中，http块中默认有两行配置
include mime.types;
default_type application/octet-stream;
mime.types文件内容
default_type:用来配置Nginx响应前端请求默认的MIME类型。
| 语法 | default_type [MIME 类型] |
|---|---|
| 默认值 | default_type text/plain; |
| 示例 | default_type application/octet-stream; |
| 位置 | http, server, location 块 |
当请求某些接口时，需要返回指定的文本字符串或 JSON 字符串。如果逻辑非常简单，或者返回的是固定的字符串，可以使用 Nginx 来快速实现。这不仅免去了编写程序来响应请求的麻烦，还可以减少服务器资源的占用，并且提高响应性能
location /get_text {
default_type text/plain;
return 200 "This is Nginx Text Test";
}
按如上修改配置nginx.conf文件
修改完成后使用nginx -t测试文件是否正确
使用nginx -s reload重新加载配置文件
测试：
测试html
添加配置
location /get_html {
default_type text/html;
return 200 "<h2>This is Nginx html Test<h2>";
}
修改完成后执行nginx -s reload重新加载配置文件
返回json格式
```powershell
location /get_json {
default_type application/json;
return 200 '{"name":"jack","age":"18","gender":1}';
}
sendfile
sendfile 用于设置 Nginx 服务器是否使用 sendfile() 系统调用来传输文件。sendfile 是 Linux 内核中处理静态资源的一个函数，它可以显著提升从磁盘读取静态资源并返回到前端的过程。
当 Nginx 访问静态资源时，这些资源通常存储在磁盘上。通过启用 sendfile，Nginx 可以直接从磁盘读取数据并发送到网络，而无需在内核空间和用户空间之间进行多次数据复制。这种方式大大提高了静态资源处理的性能，减轻了 CPU 负载，并加快了文件传输速度。
简而言之，启用 sendfile 能显著提高 Nginx 处理静态资源的性能，使得文件传输更加高效。
如下图：
未开启sendfile的处理流程
开启sendfile的处理流程
| 语法 | sendfile [on | off] |
|---|---|
| 默认值 | sendfile off; |
| 示例 | sendfile on; |
| 位置 | http, server, location 块 |
sendfile 指令的解释
语法: sendfile [on | off]
用于启用或禁用 sendfile 功能。
默认值: sendfile off;
默认情况下，sendfile 功能是禁用的。
示例: sendfile on;
启用 sendfile 功能，允许在发送文件时直接从磁盘读取数据并发送到网络，减少数据在内核空间和用户空间之间的复制，提高文件传输效率。
keepalive_timeout
keepalive_timeout:用来设置长连接的超时时间。
为什么要用keepalive_timeout
HTTP是一种无状态协议，客户端向服务端发送一个TCP请求，服务端响应完毕后断开连接。
如果客户端向服务端发送多个请求，那么每个请求都需要重新创建一次连接，效率相对来说比较低，
使用keepalive模式，可以告诉服务器端在处理完一个请求后保持这个TCP连接的打开状态，
若接收到来自这个客户端的其他请求，服务端就会利用这个未被关闭的连接，而不需要重新创建一个新连接，
提升效率，但是这个连接也不能一直保持，这样的话，连接如果过多，也会使服务端的性能下降，这个时候就需要我们进行设置其的超时时间。
| 语法 | keepalive_timeout [timeout] [header_timeout] |
|---|---|
| 默认值 | keepalive_timeout 75s; |
| 示例 | keepalive_timeout 65s; |
| 位置 | http, server, location 块 |
keepalive_requests
keepalive_requests: 指令用于设置在一个保持活动连接（Keep-Alive）上可以执行的最大请求数。通过限制请求数，可以防止单个连接长时间占用资源，提高服务器的可用性和性能。
| 语法 | keepalive_requests [number] |
|---|---|
| 默认值 | keepalive_requests 100; |
| 示例 | keepalive_requests 200; |
| 位置 | http, server, location 块 |
events块配置说明
events 块是 Nginx 配置文件 (nginx.conf) 中的重要部分，用于配置与事件处理相关的参数。它主要定义了 Nginx 服务器如何处理客户端连接，以及控制工作进程的行为。这些配置对于优化服务器性能和稳定性至关重要。
accept_mutex 设置Nginx网络连接序列化
| 语法 | accept_mutex [on | off] |
|---|---|
| 默认值 | accept_mutex on; |
| 示例 | accept_mutex off; |
| 位置 | events 块 |
accept_mutex 这个配置主要用于解决常说的"惊群"问题。当客户端发送一个请求连接时，Nginx 作为多进程服务器，会同时唤醒多个 worker 进程，但最终只有一个进程能获取到连接。如果每次唤醒的进程数目太多，就会影响 Nginx 的整体性能。
如果将 accept_mutex 设置为 on（开启状态），Nginx 会对多个进程接收连接进行排队，一个接一个地唤醒进程接收连接，从而防止多个进程争抢连接资源，提高性能。然而，是否开启该配置需要根据实际的生产环境来决定。
例如有时候多个客户端发送了多个请求，改配置为on，这个时候这会逐一去唤醒工作进程，实际上比关闭状态下情况还差了些，浪费了询问的时间。
配置示例:
multi_accept:设置是否允许同时接收多个网络连接
| 语法 | multi_accept [on | off] |
|---|---|
| 默认值 | multi_accept off; |
| 示例 | multi_accept on; |
| 位置 | events 块 |
multi_accept 的配置决定了 Nginx 的工作进程在有新连接到达时，是一次只处理一个连接，还是一次处理多个连接。
multi_accept off: 默认情况下，每次有新连接到达时，一个工作进程只接受一个连接。这种方式适合普通的请求负载，因为它避免了过多连接堆积在单个进程上，从而导致资源竞争。
multi_accept on: 当启用这个选项时，每次有新连接到达时，一个工作进程会尽可能多地接受新连接。这对于高并发场景是有利的，因为可以一次性处理多个新连接，减少系统调用的开销，提高整体处理效率。
配置示例:
worker_connections：配置单个worker进程最大的连接数
| 语法 | worker_connections [number] |
|---|---|
| 默认值 | worker_connections 1024; |
| 位置 | events 块 |
worker_connections 指令用于设置每个 Nginx 工作进程可以同时处理的最大连接数，这里的连接数不仅仅包括和前端用户建立的连接数，而是包括所有可能的连接数，另外，number值不能大于操作系统支持打开的最大文件句柄数量。
可以通过ulimit -n 查看最大文件句柄数量。
ulimit -n
配置示例
use：设置Nginx服务器选择哪种事件驱动来处理网络消息
| 语法 | use [方法] |
|---|---|
| 默认值 | use select; |
| 示例 | use epoll; |
| 位置 | events 块 |
注意：此处所选择事件处理模型是Nginx优化部分的一个重要内容，method的可选值有select/poll/epoll/kqueue等，注意使用epoll需要linux内核在2.6以上才能够使用epoll函数来优化Nginx。
假设 Nginx 服务器是一家餐厅，而事件驱动模型就像餐厅里服务员用来管理桌子的方式：
select: 这是最传统的方式，适用于几乎所有操作系统，但在处理大量连接时效率较低。就像服务员需要逐个查看每张桌子是否有新客人，效率不高。
poll: 这是 select 的改进版本，能够更有效地处理更多的连接。服务员可以查看多个桌子，但还是需要逐个处理。
epoll: 这是 Linux 上最先进的方式，能够高效地处理大量并发连接，适用于高流量的网站。就像服务员有一个智能系统，能够快速找到需要服务的桌子，大大提高了效率。
kqueue: 这是 FreeBSD 上的高效事件驱动模型，类似于 Linux 的 epoll。服务员有一个类似的智能系统，可以快速响应需求。（FreeBSD 是一个类 UNIX 操作系统，基于 BSD (Berkeley Software Distribution) 系统。它主要用于服务器和嵌入式平台，但也可以用作桌面操作系统。）
/dev/poll: 这是 Solaris 上的事件驱动模型，也是一种高效的管理方式。
配置文件配置
events {
worker_connections 1024;
accept_mutex on;
multi_accept on;
use epoll; #使用epoll
}
另外这些值的选择，我们也可以在编译的时候使用
–with-select_module、#加入到nginx编译环境
–without-select_module、#移除nginx编译环境
–with-poll_module、
–without-poll_module
来设置是否需要将对应的事件驱动模块编译到Nginx的内核。
