Nginx

独幽鎏煌

于 2024-08-26 22:06:36 发布

阅读量373

点赞数 6

文章标签： nginx 运维

本文链接：https://blog.csdn.net/L234412/article/details/141221469

版权

一.Web服务器介绍

1.1 Apache 经典的 Web 服务端

1.1.1 Apache prefork 模型

预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024
每个子进程有一个独立的线程响应用户请求
相对比较占用内存，但是比较稳定，可以设置最大和最小进程数
是最古老的一种模式,也是最稳定的模式，适用于访问量不是很大的场景

优点：稳定

缺点：每个用户请求需要对应开启一个进程,占用资源较多，并发性差,不适用于高并发场景

1.1.2 Apache worker 模型

一种多进程和多线程混合的模型
有一个控制进程，启动多个子进程
每个子进程里面包含固定的线程
使用线程程来处理请求
当线程不够使用的时候会再启动一个新的子进程,然后在进程里面再启动线程处理请求
由于其使用了线程处理请求，因此可以承受更高的并发

优点：相比prefork 占用的内存较少，可以同时处理更多的请求

缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用（该问题在 prefork模式下，同样会发生）

1.1.3 Apache event模型

Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型,属于事件驱动模型(epoll) 每个进程响应多个请求，在现在版本里的已经是稳定可用的模式它和worker模式很像，最大的区别在于，它解决了keepalive场景下长期被占用的线程的资源浪费问题（某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）event MPM中，会有一个专门的线程来管理这些keepalive类型的线程当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力

优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keepalive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放

缺点：没有线程安全控制

1.2.Nginx

Nginx 是由 1994 年毕业于俄罗斯国立莫斯科鲍曼科技大学的同学为俄罗斯 rambler.ru 公司开发的，开发工作最早从2002 年开始，第一次公开发布时间是 2004 年 10 月 4 日，版本号是 0.1.0

Nginx 历经十几年的迭代更新（ https://nginx.org/en/CHANGES ），目前功能已经非常完善且运行稳定，另外Nginx 的版本分为开发版、稳定版和过期版， nginx 以功能丰富著称，它即可以作为 http 服务器，也可以作为反向代理服务器或者邮件服务器能够快速的响应静态网页的请求

支持 FastCGI/SSL/Virtual Host/URL Rwrite /Gzip / HTTP Basic Auth/http 或者 TCP的

负载均衡 (1.9 版本以上且开启stream 模块 ) 等功能，并且支持第三方的功能扩展。天猫淘宝京东小米 163 新浪等一线互联网公司都在用 Nginx 或者进行二次开发

基于 Nginx 的工作场景：

1.3用户访问体验和性能

1.3.1影响用户体验的因素

1.客户端

客户端硬件配置
客户端网络速率
客户端与服务端距离

2.服务器

服务端网络速率
服务端硬件配置
服务端架构设计
服务端应用程序工作模式
服务端并发数量服务端响应文件大小及数量 buffer cache
服务端I/O压力1.2.4 服务端 I/O 流程

1.4.服务端I/O流程

I/O 在计算机中指 Input/Output ， IOPS (Input/Output Per Second) 即每秒的输入输出量 ( 或读写次数 ) ，是衡量磁盘性能的主要指标之一。IOPS 是指单位时间内系统能处理的 I/O 请求数量，一般以每秒处理的 I/O请求数量为单位， I/O 请求通常为读或写数据操作请求。

一次完整的 I/O 是用户空间的进程数据与内核空间的内核数据的报文的完整交换，但是由于内核空间与用户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说 I/O 就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中。

服务器的I/O：

磁盘I/O
网络I/O : 一切皆文件,本质为对socket文件的读写

1.4.1磁盘I/O

磁盘 I/O 是进程向内核发起系统调用，请求磁盘上的某个资源比如是 html 文件或者图片，然后内核通过相应的驱动程序将目标文件加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存，如果是比较大的数据也需要等待时间

机械磁盘的寻道时间、旋转延迟和数据传输时间：

寻道时间：是指磁头移动到正确的磁道上所花费的时间，寻道时间越短则 I/O 处理就越快，目前磁盘的寻道时

间一般在 3-15 毫秒左右。

旋转延迟：是指将磁盘片旋转到数据所在的扇区到磁头下面所花费的时间，旋转延迟取决于磁盘的转速，通常

使用磁盘旋转一周所需要时间的 1/2 之一表示，比如 7200 转的磁盘平均训传延迟大约为

60*1000/7200/2=4.17 毫秒，公式的意思为（每分钟 60 秒 *1000 毫秒每秒 /7200 转每分 /2 ），如果是

15000 转的则为 60*1000/15000/2=2 毫秒。 1.2.4.2 网络 I/O

网络通信就是网络协议栈到用户空间进程的 IO 就是网络 IO

网络 I/O 处理过程

获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（ 1-3 ）

构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（ 4 ）

返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（ 5-7 ）

不论磁盘和网络 I/O

每次 I/O ，都要经由两个阶段：

第一步：将数据从文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长

第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短

数据传输时间：指的是读取到数据后传输数据的时间，主要取决于传输速率，这个值等于数据大小除以传输速

率，目前的磁盘接口每秒的传输速度可以达到 600MB ，因此可以忽略不计。

常见的机械磁盘平均寻道时间值：

7200 转 / 分的磁盘平均物理寻道时间： 9 毫秒

10000 转 / 分的磁盘平均物理寻道时间： 6 毫秒

15000 转 / 分的磁盘平均物理寻道时间： 4 毫秒

常见磁盘的平均延迟时间：

7200 转的机械盘平均延迟： 60*1000/7200/2 = 4.17ms

10000 转的机械盘平均延迟： 60*1000/10000/2 = 3ms

15000 转的机械盘平均延迟： 60*1000/15000/2 = 2ms

每秒最大 IOPS 的计算方法：

7200 转的磁盘 IOPS 计算方式： 1000 毫秒 /(9 毫秒的寻道时间 +4.17 毫秒的平均旋转延迟时

间 )=1000/13.13=75.9 IOPS

10000 转的磁盘的 IOPS 计算方式： 1000 毫秒 /(6 毫秒的寻道时间 +3 毫秒的平均旋转延迟时

间 )=1000/9=111IOPS

15000 转的磁盘的 IOPS 计算方式： 15000 毫秒 /(4 毫秒的寻道时间 +2 毫秒的平均旋转延迟时

间 )=1000/6=166.6 IOPS

1.4.2 网络I/O

网络 I/O 处理过程

获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）
构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）
返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）

不论磁盘和网络 I/O 每次I/O ，都要经由两个阶段：

第一步：将数据从文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长
第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短

二.NGINX架构和安装

2.1 NGINX介绍

2.1.1NGINX功能介绍

静态的web资源服务器html，图片，js，css，txt等静态资源
http/https协议的反向代理
结合FastCGI/uWSGI/SCGI等协议反向代理动态资源请求
tcp/udp协议的请求转发（反向代理）
imap4/pop3协议的反向代理

2.1.2 基础特性

模块化设计，较好的扩展性
高可靠性
支持热部署：不停机更新配置文件，升级版本，更换日志文件
低内存消耗：10000个keep-alive连接模式下的非活动连接，仅需2.5M内存
event-driven,aio,mmap，sendfile

2.1.3 Web服务相关功能

虚拟主机（server）
支持 keep-alive 和管道连接(利用一个连接做多次请求)
访问日志（支持基于日志缓冲提高其性能）url rewirte
路径别名
基于IP及用户的访问控制
支持速率限制及并发数限制
重新配置和在线升级而无须中断客户的工作进程

2.2 Nginx架构和进程

2.2.1Njinx进程结构

主进程 (master process) 的功能：

对外接口：接收外部的操作（信号）
对内转发：根据外部的操作的不同，通过信号管理 Worker
监控：监控 worker 进程的运行状态，worker 进程异常终止后，自动重启 worker 进程
读取Nginx 配置文件并验证其有效性和正确性
建立、绑定和关闭socket连接
按照配置生成、管理和结束工作进程
接受外界指令，比如重启、升级及退出服务器等指令
不中断服务，实现平滑升级，重启服务并应用新的配置
开启日志文件，获取文件描述符
不中断服务，实现平滑升级，升级失败进行回滚处理
编译和处理perl脚本

工作进程（ worker process ）的功能：

所有 Worker 进程都是平等的
实际处理：网络请求，由 Worker 进程处理
Worker进程数量：一般设置为核心数，充分利用CPU资源，同时避免进程数量过多，导致进程竞争
CPU资源，
增加上下文切换的损耗
接受处理客户的请求
将请求依次送入各个功能模块进行处理
I/O调用，获取响应数据
与后端服务器通信，接收后端服务器的处理结果
缓存数据，访问缓存索引，查询和调用缓存数据
发送请求结果，响应客户的请求
接收主程序指令，比如重启、升级和退出等

2.3. Nginx安装

2.3.1 Nginx版本和安装方式

Nginx 版本：

Mainline version 主要开发版本,一般为奇数版本号,比如1.19
Stable version 当前最新稳定版,一般为偶数版本,如:1.20
Legacy versions 旧的稳定版,一般为偶数版本,如:1.18

Nginx 安装可以使用 yum 或源码安装，但是推荐使用源码编译安装

yum的版本比较旧
编译安装可以更方便自定义相关路径
使用源码编译可以自定义相关功能，更方便业务的上的使用

2.3.2 Nginx源码编译安装

依赖包安装

[root@nginx ~]# dnf install gcc pcre-devel zlib-devel openssl-devel -y

解压缩安装包并进行检测

[root@nginx ~]# tar zxf nginx-1.24.0.tar.gz

[root@nginx ~]# cd nginx-1.24.0/

[root@nginx nginx-1.24.0]# ./configure --prefix=/usr/local/nginx \
> --user=nginx \
> --group=nginx \
> --with-http_ssl_module \
> --with-http_v2_module \
> --with-http_realip_module \
> --with-http_stub_status_module \
> --with-http_gzip_static_module \
> --with-pcre \
> --with-stream \
> --with-stream \
> --with-stream_realip_module

进行安装

[root@nginx nginx-1.24.0]# make && make install

2.3.2 验证版本及编译参数

[root@nginx ~]# vim ~/.bash_profile

[root@nginx ~]# source ~/.bash_profile

[root@nginx ~]# nginx -V

2.3.3 Nginx启动文件编写

启动nginx

[root@nginx ~]# systemctl daemon-reload
[root@nginx ~]# systemctl start nginx

查看结果

2.4 平滑升级和回滚

有时候我们需要对 Nginx 版本进行升级以满足对其功能的需求，例如添加新模块，需要新功能，而此时 Nginx又在跑着业务无法停掉，这时我们就可能选择平滑升级

2.4.1 平滑升级流程

将旧Nginx二进制文件换成新Nginx程序文件（注意先备份)
向master进程发送USR2信号
master进程修改pid文件名加上后缀.oldbin,成为nginx.pid.oldbin
master进程用新Nginx文件启动新master进程成为旧master的子进程,系统中将有新旧两个Nginx主进程共同提供Web服务,当前新的请求仍然由旧Nginx的worker进程进行处理,将新生成的master进程的PID存放至新生成的pid文件nginx.pid
向旧的Nginx服务进程发送WINCH信号，使旧的Nginx worker进程平滑停止
向旧master进程发送QUIT信号，关闭老master，并删除Nginx.pid.oldbin文件
如果发现升级有问题,可以回滚∶向老master发送HUP，向新master发送QUIT

2.4.2 实际操作

解压缩需要升级的安装包

[root@nginx ~]# tar zxf nginx-1.26.1.tar.gz

编译新版本

[root@nginx nginx-1.26.1]# ./configure --with-http_ssl_module --withhttp_v2_module --with-http_realip_module --with-http_stub_status_module --withhttp_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --
with-stream_realip_module
[root@nginx nginx-1.26.1]# make

查看两个版本

备份旧版的nginx

[root@Nginx ~]# cd /usr/local/nginx/sbin/

[root@Nginx sbin]# cp nginx nginx.24

把新版本的 nginx 命令复制过去

[root@Nginx sbin]# \cp -f /root/nginx/nginx-1.26.1/objs/nginx

/usr/local/nginx/sbin

检查有无问题

[root@nginx nginx-1.26.1]# nginx -t

[root@Nginx sbin]# kill -USR2 48732 #nginx worker ID

#USR2 平滑升级可执行程序 , 将存储有旧版本主进程 PID 的文件重命名为 nginx.pid.oldbin ，并启动新的

nginx

# 此时两个 master 的进程都在运行 , 只是旧的 master 不在监听 , 由新的 master 监听 80

# 此时 Nginx 开启一个新的 master 进程，这个 master 进程会生成新的 worker 进程，这就是升级后的 Nginx 进

程，此时老的进程不会自动退出，但是当接收到新的请求不作处理而是交给新的进程处理。

[root@Nginx sbin]# ps aux | grep nginx

root 48732 0.0 0.1 9868 2436 ? Ss 14:17 0:00 nginx: master

process /usr/local/nginx/sbin/nginx

nobody 48733 0.0 0.2 14200 4868 ? S 14:17 0:00 nginx: worker

process

root 52075 0.0 0.3 9876 6528 ? S 15:41 0:00 nginx: master

process /usr/local/nginx/sbin/nginx

nobody 52076 0.0 0.2 14208 4868 ? S 15:41 0:00 nginx: worker

process

[root@Nginx sbin]# curl -I localhost

HTTP/1.1 200 OK

Server: nginx/1.24.0 ## 依旧是旧版本生生效

Date: Thu, 18 Jul 2024 07:45:58 GMT

Content-Type: text/html

Content-Length: 615

Last-Modified: Thu, 18 Jul 2024 03:41:13 GMT

Connection: keep-alive

ETag: "66988ed9-267"

Accept-Ranges: bytes

# 回收旧版本

[root@Nginx sbin]# kill -WINCH 48732

[root@Nginx sbin]# ps aux | grep nginx

root 48732 0.0 0.1 9868 2436 ? Ss 14:17 0:00 nginx: master

process /usr/local/nginx/sbin/nginx

root 52075 0.0 0.3 9876 6528 ? S 15:41 0:00 nginx: master

process /usr/local/nginx/sbin/nginx nobody 52076 0.0 0.2 14208 4868 ? S 15:41 0:00 nginx: worker

process

检测当前版本信息

2.4.3 回滚

如果发现升级的版本有问题需要回滚，可以重新拉起旧版本的nginx

[root@Nginx sbin]# cp nginx nginx.26
[root@Nginx sbin]# ls
nginx nginx.24 nginx.26
[root@Nginx sbin]# mv nginx.24 nginx
mv: overwrite 'nginx'? y

[root@Nginx sbin]# kill -HUP 48732
[root@Nginx sbin]# ps aux | grep nginx
root 48732 0.0 0.1 9868 2436 ? Ss 14:17 0:00 nginx: master
process /usr/local/nginx/sbin/nginx
root 52075 0.0 0.3 9876 6528 ? S 15:41 0:00 nginx: master
process /usr/local/nginx/sbin/nginx
nobody 52076 0.0 0.2 14208 5124 ? S 15:41 0:00 nginx: worker
process
nobody 52130 0.0 0.2 14200 4868 ? S 16:30 0:00 nginx: worker
process

[root@Nginx sbin]# kill -WINCH 52075
[root@Nginx sbin]# ps aux | grep nginx
root 48732 0.0 0.1 9868 2436 ? Ss 14:17 0:00 nginx: master
process /usr/local/nginx/sbin/nginx
root 52075 0.0 0.3 9876 6528 ? S 15:41 0:00 nginx: master
process /usr/local/nginx/sbin/nginx
nobody 52130 0.0 0.2 14200 4868 ? S 16:30 0:00 nginx: worker
process
root 52137 0.0 0.1 221664 2176 pts/0 S+ 16:31 0:00 grep --
color=auto nginx

[root@Nginx sbin]# curl -I localhost
HTTP/1.1 200 OK
Server: nginx/1.24.0 ##版本回滚完成
Date: Thu, 18 Jul 2024 08:31:51 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Thu, 18 Jul 2024 03:41:13 GMT
Connection: keep-alive
ETag: "66988ed9-267"
Accept-Ranges: bytes

三.Nginx的核心配置详解

3.1 配置文件说明

Nginx 的配置文件的组成部分：

主配置文件：nginx.conf
子配置文件: include conf.d/*.conf
fastcgi， uwsgi，scgi 等协议相关的配置文件
mime.types：支持的mime类型，MIME(Multipurpose Internet Mail Extensions)多用途互联网邮
件扩展类型，MIME消息能包含文本、图像、音频、视频以及其他应用程序专用的数据，是设定某
种扩展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动
使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式。

默认的 nginx.conf 配置文件格式说明

# 全局配置端，对全局生效，主要设置 nginx 的启动用户 / 组，启动的工作进程数量，工作模式， Nginx 的 PID 路

径，日志路径等。

user nginx nginx;

worker_processes 1; # 启动工作进程数数量

events { #events # 设置快，主要影响 nginx 服务器与用户的网络连接，比如是否允许同时接受多

个网络连接，使用哪种事件驱动模型 # 处理请求，每个工作进程可以同时支持的

最大连接数，是否开启对多工作进程下的网络连接进行序列化等。

worker_connections 1024; # 设置单个 nginx 工作进程可以接受的最大并发，作为 web 服务器

的时候最大并发数为 #worker_connections *

worker_processes ，作为反向代理的时候为

#(worker_connections * worker_processes)/2

}

http { #http 块是 Nginx 服务器配置中的重要部分，缓存、代理和日志格

式定义等绝大多数功能和第三方模块都 # 可以在这设置， http 块可

以包含多个 server 块，而一个 server 块中又可以包含多个 location 块，

#server 块可以配置文件引入、 MIME-Type 定义、日志自定义、是

否启用 sendfile 、连接超时时间和 # 单个链接的请求上限等。

include mime.types;

default_type application/octet-stream;

sendfile on; # 作为 web 服务器的时候打开 sendfile 加快静态文件传输，指定是

否使用

#sendfile 系统调用来传输文件

#sendfile 系统调用在两个文件描述符之间直接传递数据 ( 完全在

内核中操作 )

# 从而避免了数据在内核缓冲区和用户缓冲区之间的拷贝，操作效率

很高，被称之为零拷贝，

# 硬盘 >> kernel buffer ( 快速拷贝到 kernelsocket

buffer) >> 协议栈。

keepalive_timeout 65; # 长连接超时时间，单位是秒

server { # 设置一个虚拟机主机，可以包含自己的全局快，同时也可以包含多

个 location 模块

# 比如本虚拟机监听的端口、本虚拟机的名称和 IP 配置，多个

server 可以使用一个端口比如都使用 #80 端口提供 web 服务

listen 80; # 配置 server 监听的端口 3.2 全局配置

Main 全局配置段常见的配置指令分类

正常运行必备的配置

优化性能相关的配置

用于调试及定位问题相关的配置

事件驱动相关的配置

全局配置说明 :

server_name localhost; # 本 server 的名称，当访问此名称的时候 nginx 会调用当前 serevr

内部的配置进程匹配。

location / { #location 其实是 server 的一个指令，为 nginx 服务器提供比较

多而且灵活的指令

# 都是在 location 中体现的，主要是基于 nginx 接受到的请求字符

串

# 对用户请求的 UIL 进行匹配，并对特定的指令进行处理

# 包括地址重定向、数据缓存和应答控制等功能都是在这部分实现

# 另外很多第三方模块的配置也是在 location 模块中配置。

root html; # 相当于默认页面的目录名称，默认是安装目录的相对路径，可以使

用绝对路径配置。

index index.html index.htm; # 默认的页面文件名称

}

error_page 500 502 503 504 /50x.html; # 错误页面的文件名称

location = /50x.html { #location 处理对应的不同错误码的页面定

义到 /50x.html

# 这个跟对应其 server 中定义的目录下。

root html; # 定义默认页面所在的目录

}

}

# 和邮件相关的配置

#mail {

# ...

# } mail 协议相关配置段

#tcp 代理配置， 1.9 版本以上支持

#stream {

# ...

# } stream 服务器相关配置段

# 导入其他路径的配置文件

#include /apps/nginx/conf.d/*.conf

}

3.2 全局配置

全局配置说明 :

user nginx nginx; # 启动 Nginx 工作进程的用户和组

worker_processes [number | auto]; # 启动 Nginx 工作进程的数量 , 一般设为和 CPU 核心数相同

worker_cpu_affinity 00000001 00000010 00000100 00001000 | auto ; # 将 Nginx 工作进程绑定到指定的 CPU 核心，默认 Nginx 是不进行进程绑定的，绑定并不是意味着当前 nginx 进

程独占以一核心 CPU ，但是可以保证此进程不运行在其他核心上，这就极大减少了 nginx 的工作进程在不同的

cpu 核心上的来回跳转，减少了 CPU 对进程的资源分配与回收以及内存管理等，因此可以有效的提升 nginx 服务

器的性能。

CPU MASK: 00000001 ： 0 号 CPU

00000010 ： 1 号 CPU

10000000 ： 7 号 CPU

# 示例

worker_cpu_affinity 0001 0010 0100 1000; 第 0 号 --- 第 3 号 CPU

worker_cpu_affinity 0101 1010;

# 示例

worker_processes 4;

worker_cpu_affinity 00000010 00001000 00100000 10000000;

[root@centos8 ~]# ps axo pid,cmd,psr | grep nginx

31093 nginx: master process /apps 1

34474 nginx: worker process 1

34475 nginx: worker process 3

34476 nginx: worker process 5

34477 nginx: worker process 7

# 错误日志记录配置，语法： error_log file [debug | info | notice | warn | error | crit

| alert | emerg]

#error_log logs/error.log;

#error_log logs/error.log notice;

error_log /usr/local/nginx/logs/error.log error;

#pid 文件保存路径

pid /usr/local/nginx/logs/nginx.pid;

worker_priority 0; # 工作进程优先级， -20~20(19)

worker_rlimit_nofile 65536; # 所有 worker 进程能打开的文件数量上限 ,

# 包括 :Nginx 的所有连接（例如与代理服务器的连接等）

# 而不仅仅是与客户端的连接

# 另一个考虑因素是实际的并发连接数不能超过系统级别的最大打开文件

数的限制

# 最好与 ulimit -n 或者 limits.conf 的值保持一致 ,

# 修改 pam 限制

[root@Nginx ~]# sudo -u nginx ulimit -n

1024

[root@Nginx ~]# vim /etc/security/limits.conf

* - nofile 100000

[root@Nginx ~]# sudo -u nginx ulimit -n

100000

daemon off; # 前台运行 Nginx 服务用于测试、 docker 等环境。

master_process off|on; # 是否开启 Nginx 的 master-worker 工作模式，仅用于开发调试场景 , 默认为

on

events { worker_connections 65535; # 设置单个工作进程的最大并发连接数

use epoll; # 使用 epoll 事件驱动，

#Nginx 支持众多的事件驱动，

# 比如 :select 、 poll 、 epoll ，只能设置在 events 模块中

设置

accept_mutex on ； #on 为同一时刻一个请求轮流由 work 进程处理 ,

# 而防止被同时唤醒所有 worker

# 避免多个睡眠进程被唤醒的设置，默认为 off

# 新请求会唤醒所有 worker 进程 , 此过程也称为 " 惊群 "

# 因此 nginx 刚安装完以后要进行适当的优化。建议设置为 on

multi_accept on; #on 时 Nginx 服务器的每个工作进程可以同时接受多个新的网

络连接

# 此指令默认为 off ，

# 即默认为一个工作进程只能一次接受一个新的网络连接

# 打开后几个同接受多个。建议设置为 on

}

实现Nginx高并发配置

[root@nginx ~]# ulimit -n 102400
[root@nginx ~]# ab -c 5000 -n 10000 http://10.0.0.8/

配置并不支持高并发，会出现错误日志

修改配置：

3.3 http配置快

# 在响应报文中将指定的文件扩展名映射至 MIME 对应的类型

include /etc/nginx/mime.types;

default_type application/octet-stream; # 除 mime.types 中的类型外

# 指定其它文件的默认 MIME 类型，浏览

器一般会提示下载

types {

text/html html;

image/gif gif;

image/jpeg jpg;

}

3.4.root与alias

root ：指定 web 的家目录，在定义 location 的时候，文件的绝对路径等于 root+location

编写root文件

编写测试内容

[root@Nginx ~]# mkdir /mnt/dirtest/

[root@Nginx ~]# echo dirtest page > /mnt/dirtest/index.html

[root@Nginx ~]# nginx -s reload

重启并测试

[root@node100 ~]# curl lee.timinglee.org/dirtest/

dirtest page

alias ：定义路径别名，会把访问的路径重新定义到其指定的路径 , 文档映射的另一种机制 ; 仅能用于

location 上下文 , 此指令使用较少

3.5 location的详细使用

在一个server中location配置段可存在多个，用于实现从uri到文件系统的路径映射；
ngnix会根据用户请求的URI来检查定义的所有location，按一定的优先级找出一个最佳匹配，
而后应用其配置在没有使用正则表达式的时候，nginx会先在server中的多个location选取匹配度最
高的一个uri
uri是用户请求的字符串，即域名后面的web文件路径
然后使用该location模块中的正则url和字符串，如果匹配成功就结束搜索，并使用此location处理
此请求。

# 语法规则：

location [ = | ~ | ~* | ^~ ] uri { ... }

= # 用于标准 uri 前，需要请求字串与 uri 精确匹配，大小敏感 , 如果匹配成功就停止向下匹配并立

即处理请求

^~ # 用于标准 uri 前，表示包含正则表达式 , 并且匹配以指定的正则表达式开头

# 对 uri 的最左边部分做匹配检查，不区分字符大小写

~ # 用于标准 uri 前，表示包含正则表达式 , 并且区分大小写

~* # 用于标准 uri 前，表示包含正则表达式 , 并且不区分大写

不带符号 # 匹配起始于此 uri 的所有的 uri

\ # 用于标准 uri 前，表示包含正则表达式并且转义字符。可以将 . * ? 等转义为普通符号

# 匹配优先级从高到低：

=, ^~, ~/~*, 不带符号

3.6 Nginx账户认证功能

测试

[root@node100 ~]# curl lee.timinglee.org/login/ -u lee:lee

login

[root@node100 ~]# curl lee.timinglee.org/login/ -u admin:lee

login

3.7 自定义错误页面

重启测试

3.8 自定义错误日志

3.9 长连接配置

keepalive_timeout timeout [header_timeout]; # 设定保持连接超时时长， 0 表示禁止长连接，

默认为 75s

# 通常配置在 http 字段作为站点全局配置

keepalive_requests 数字 ; # 在一次长连接上所允许请求的资源的最大数量

# 默认为 100 次 , 建议适当调大 , 比如 :500

配置

keepalive_requests 3;

keepalive_timeout 65 60;

# 开启长连接后，返回客户端的会话保持时间为 60s ，单次长连接累计请求达到指定次数请求或 65 秒就会被断

开，第二个数字 60 为发送给客户端应答报文头部中显示的超时时间设置为 60s ：如不设置客户端将不显示超时时

间。

Keep-Alive:timeout=60 # 浏览器收到的服务器返回的报文

# 如果设置为 0 表示关闭会话保持功能，将如下显示：

#Connection:close 浏览器收到的服务器返回的报文