nginx工作原理及配置

本文详细介绍了nginx的工作原理,包括模块分类、nginx的处理请求流程和多进程模型。同时,文章还涵盖了nginx的部署、配置文件详解,如错误页面、平滑升级、location配置、访问控制、HTTPS配置等内容,旨在帮助读者全面了解和掌握nginx的使用和优化。
摘要由CSDN通过智能技术生成

模块与工作原理

nginx由内核和模块组成。其中,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端请求映射到一个location block(location是nginx配置中的一个指令,用于URL匹配),而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。

模块分类

nginx的模块从结构上分为核心模块、基础模块和第三方模块

  • HTTP模块、EVENT模块和MAIL模块等属于核心模块
  • HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块属于基本模块
  • HTTP Upstream模块、Request Hash模块、Notice模块和HTTP Access Key模块属于第三方模块

用户根据自己的需要开发的模块都属于第三方模块。
nginx模块从功能上分为三类,分别是:

  • Handlers(处理器模块)。此类模块直接处理请求,并进行输出内容和修改headers信息等操作。handlers处理器模块一般只能有一个
  • Filters(过滤器模块)。此类模块主要对其他处理器模块输出的内容进行修改操作,最后由nginx输出
  • Proxies(代理器模块)。就是nginx的HTTP Upstream之类的模块,这些模块主要与后端一些服务比如fastcgi等操作交互,实现服务代理和负载均衡等功能

nginx模块分为:核心模块、事件模块、标准Http模块、可选Http模块、邮件模块、第三方模块和补丁等

nginx基本模块:所谓基本模块,指的是nginx默认的功能模块,它们提供的指令,允许你使用定义nginx基本功能的变量,在编译时不能被禁用,包括:

  • 核心模块:基本功能和指令,如进程管理和安全。常见的核心模块指令,大部分是放置在配置文件的顶部
  • 事件模块:在Nginx内配置网络使用的能力。常见的events(事件)模块指令,大部分是放置在配置文件的顶部
  • 配置模块:提供包含机制

更多的指令,请参考nginx官方文档

nginx的工作原理

nginx的模块直接被编译进nginx,因此属于静态编译方式。

启动nginx后,nginx的模块被自动加载,与Apache不一样,首先将模块编译为一个so文件,然后在配置文件中指定是否进行加载。

在解析配置文件时,nginx的每个模块都有可能去处理某个请求,但是同一个处理请求只能由一个模块来完成。

nginx的进程架构:
启动nginx时,会启动一个Master进程,这个进程不处理任何客户端的请求,主要用来产生worker线程,一个worker线程用来处理n个request。

worker 进程中,ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中,一个请求的简单处理流程如下:

  1. 操作系统提供的机制(例如 epoll, kqueue 等)产生相关的事件。
  2. 接收和处理这些事件,如是接收到数据,则产生更高层的 request 对象。
  3. 处理 request 的 header 和 body。
  4. 产生响应,并发送回客户端。
  5. 完成 request 的处理。
  6. 重新初始化定时器及其他事件。
    在这里插入图片描述
    多进程模型的处理方式:
  • 首先,master进程一开始就会根据我们的配置,来建立需要listen的网络socket fd,然后fork出多个worker进程。
  • 其次,根据进程的特性,新建立的worker进程,也会和master进程一样,具有相同的设置。因此,其也会去监听相同ip端口的套接字socket fd。
    然后,这个时候有多个worker进程都在监听同样设置的socket fd,意味着当有一个请求进来的时候,所有的worker都会感知到。这样就会产生所谓的“惊群现象”。为了保证只会有一个进程成功注册到listenfd的读事件,nginx中实现了一个“accept_mutex”类似互斥锁,只有获取到这个锁的进程,才可以去注册读事件。其他进程全部accept 失败。
  • 最后,监听成功的worker进程,读取请求,解析处理,响应数据返回给客户端,断开连接,结束。因此,一个request请求,只需要worker进程就可以完成。

nginx模块一次常规的HTTP请求和响应的过程
在这里插入图片描述
一个典型的HTTP处理周期:
7. 客户端发送HTTP请求
8. Nginx基于配置文件中的位置选择一个合适的处理模块
9. (如果有)负载均衡模块选择一台后端服务器
10. 处理模块进行处理并把输出缓冲放到第一个过滤模块上
11. 第一个过滤模块处理后输出给第二个过滤模块
12. 然后第二个过滤模块又到第三个
13. 依此类推 –> 最后把响应发给客户端。

Nginx本身做的工作实际很少,当它接到一个HTTP请求时,它仅仅是通过查找配置文件将此次请求映射到一个location block,而此location中所配置的各个指令则会启动不同的模块去完成工作,因此模块可以看做Nginx真正的劳动工作者。

基本的WEB服务请求步骤
在这里插入图片描述

  1. 建立连接 — 接受一个客户端连接,或者如果不希望与这个客户端建立连接,就将其关闭。
  2. 接收请求 — 从网络中读取一条 HTTP 请求报文。
  3. 处理请求 — 对请求报文进行解释,并采取行动。
  4. 访问资源 — 访问报文中指定的资源。
  5. 构建响应 — 创建带有正确首部的 HTTP 响应报文。
  6. 发送响应 — 将响应回送给客户端。
  7. 记录事务处理过程 — 将与已完成事务有关的内容记录在一个日志文件中。

nginx部署

nginx的安装

# 关闭防火墙和selinux
[root@localhost ~]# systemctl disable --now firewalld
Removed /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
[root@localhost ~]# sed -ri 's/^(SELINUX=).*/\1disabled/g' /etc/selinux/config
[root@localhost ~]# reboot 
[root@localhost ~]# getenforce 0
Disabled
# 创建系统用户nginx
[root@localhost ~]# useradd -r -M -s /sbin/nologin nginx
# 安装依赖环境
[root@localhost ~]# yum -y install pcre-devel openssl openssl-devel gd-devel gcc gcc-c++ vim wget make
[root@localhost ~]# yum -y groups mark install 'Development Tools'
# 创建日志存放目录
[root@localhost ~]# mkdir -p /var/log/nginx
[root@localhost ~]# chown -R nginx.nginx /var/log/nginx
# 下载nginx
[root@localhost ~]# cd /usr/src/
[root@localhost src]# wget http://nginx.org/download/nginx-1.12.0.tar.gz
# 编译安装
[root@localhost src]# ls
debug  kernels  nginx-1.12.0.tar.gz
[root@localhost src]# tar xf nginx-1.12.0.tar.gz
[root@localhost src]# cd nginx-1.12.0
[root@localhost nginx-1.12.0]# ./configure \
--prefix=/usr/local/nginx \
--user=nginx \
--group=nginx \
--with-debug \
--with-http_ssl_module \
--with-http_realip_module \
--with-http_image_filter_module \
--with-http_gunzip_module \
--with-http_gzip_static_module \
--with-http_stub_status_module \
--http-log-path=/var/log/nginx/access.log \
--error-log-path=/var/log/nginx/error.log
[root@localhost nginx-1.12.0]# make -j $(grep 'processor' /proc/cpuinfo | wc -l) && make install
# 配置环境变量
[root@localhost ~]# echo 'export PATH=/usr/local/nginx/sbin:$PATH' > /etc/profile.d/nginx.sh
[root@localhost ~]# . /etc/profile.d/nginx.sh

# 启动nginx
[root@localhost ~]# nginx
[root@localhost ~]# ss -anlt
State    Recv-Q   Send-Q     Local Address:Port     Peer Address:Port   
LISTEN   0        128              0.0.0.0:80            0.0.0.0:*      
LISTEN   0        128              0.0.0.0:22            0.0.0.0:*      
LISTEN   0        128                 [::]:22               [::]:*      
# 写service文件让nginx开机自启
[root@localhost ~]# cat > /usr/lib/systemd/system/nginx.service <<EOF
[Unit]
Description=nginx
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s quit
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF
[root@localhost ~]# systemctl daemon-reload
[root@localhost ~]# systemctl enable --now  nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.

在这里插入图片描述

nginx的配置文件详解

主配置文件:/usr/local/nginx/conf/nginx.conf

  • 默认启动nginx时,使用的配置文件是:安装路径/conf/nginx.conf文件
  • 可以在启动nginx时通过-c选项来指定要读取的配置文件
    nginx常见的配置文件及其作用
配置文件 作用
nginx.conf nginx的基本配置文件
mime.types MIME类型关联的扩展文件
fastcgi.conf 与fastcgi相关的配置
proxy.conf 与proxy相关的配置
sites.conf 配置nginx提供的网站,包括虚拟主机

nginx.conf的内容分为以下几段:

  • main配置段:全局配置段。其中main配置段中可能包含event配置段
  • event {}:定义event模型工作特性
  • http {}:定义http协议相关的配置
    配置指令:要以分号结尾,语法格式如下:
derective value1 [value2 ...];

支持使用变量:

  • 内置变量:模块会提供内建变量定义
  • 自定义变量:set var_name value
    用于调试、定位问题的配置参数
    是否以守护进程方式运行Nginx
    守护进程(daemon)是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示,这样一来,进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务,因此,默认都是以这种方式运行的。
daemon {on|off};    //是否以守护进程方式运行nginx,调试时应设置为off
master_process {on|off};    //是否以master/worker模型来运行nginx,调试时可以设置为off
error_log 位置 级别;    //配置错误日志
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
#user  nobody;
worker_processes  1;
daemon off;

[root@localhost ~]# nginx -s stop;nginx

正常运行必备的配置参数

不过Nginx还是提供了关闭守护进程的模式,之所以提供这种模式,是为了方便跟踪调试Nginx,毕竟用gdb调试进程时最烦琐的就是如何继续跟进fork出的子进程了。

# user USERNAME [GROUPNAME]		//指定允许worker进程的用户和组
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
user  nginx nginx;

# pid /path/to/pid_file			//指定nginx守护进程的pid文件
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
pid        logs/nginx.pid;
[root@localhost ~]# ls /usr/local/nginx/logs/
nginx.pid
[root@localhost ~]# systemctl stop nginx.service 
[root@localhost ~]# ls /usr/local/nginx/logs/

# worker_rlimit_nofile number	//设置所有woker进程最大可以打开的文件数,默认1024

# worker_rlimit_core size	    //指明所有worker进程所能够使用的总体的最大核心文件大小,保持默认即可

优化性能的配置参数

worker_processes n;    //启动n个worker进程,这里的n为了避免上下文切换,通常设置为cpu总核心数-1或等于总核心数
worker_cpu_affinity cpumask ...;    //将进程绑定到某cpu中,避免频繁刷新缓存
//cpumask:使用8位二进制表示cpu核心,如:
    0000 0001   //第一颗cpu核心
    0000 0010   //第二颗cpu核心
    0000 0100   //第三颗cpu核心
    0000 1000   //第四颗cpu核心
    0001 0000   //第五颗cpu核心
    0010 0000   //第六颗cpu核心
    0100 0000   //第七颗cpu核心
    1000 0000   //第八颗cpu核心

#查看cpu
[root@localhost ~]# vim /usr/local/nginx/conf/nginx.conf
worker_processes  3;
worker_cpu_affinity 0001 0010 0100;
[root@localhost ~]# systemctl restart nginx.service 
[root@localhost ~]# ps -ef | grep nginx
root        1571       1  0 23:13 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx       1572    1571  0 23:13 ?        00:00:00 nginx: worker process
nginx       1573    1571  0 23:13 ?        00:00:00 nginx: worker process
nginx       1574    1571  0 23:13 ?        00:00:00 nginx: worker process
root        1576    1485  0 23:13 pts/0    00:00:00 grep --color=auto nginx

[root@localhost ~]# top
top - 23:31:29 up 22 min,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 223 total,   1 running, 222 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3752.0 total,   3300.8 free,    216.8 used,    234.4 buff/cache
MiB Swap:   4044.0 total,   4044.0 free,      0.0 used.   3305.5 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                       
      1 root      20   0  242256  10628   8180 S   0.0   0.3   0:00.92 systemd                                                       
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kthreadd                                                      
      3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp    
                                                          
#按shi
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值