Nginx优化与防盗链 与apache相似

一、Nginx的概述

1.1 Nginx工作原理

Nginx由内核和模块组成。Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。
通常一个location中的指令会涉及一个handler模块和多个filter模块(当然，多个 location可以复用同一个模块)。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。

用户根据自己的需要所开发的模块都属于第三方模块。正是有了这么多模块的支撑，Nginx的功能才会如此强大。ENginx的模块从结构上分为核心模块、基础模块和第三方模块:
核心模块:HTTP模块、EVENT模块和MAIL模块;
基础模块:HTTP Access模块、HTTP FastCGl模块、HTTP Proxy模块和HTTP Rewrite模块;
]第三方模块:HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。

Nginx的模块从功能上分为如下三类:
Handlers(处理器模块)∶此类模块直接处理请求，并进行输出内容和修改header信息等操作。Handlers处理器模块一般只能有一个;
Filters(过滤器模块)∶此类模块主要对其他处理器模块输出的内容进行修改操作，最后由 Nginx输出;
Proxies(代理类模块）∶此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务比如FastCGIl等进行交互，实现服务代理和负载均衡等功能。

1.2 Nginx的进程模型

在工作方式上，Nginx分为单工作进程和多工作进程两种模式
1、在单工作进程模式下，除主进程外，还有一个工作进程，工作进程是单线程的;
2、在多工作进程模式下，每个工作进程包含多个线程。Nginx默认为单工作进程模式。

Nginx在启动后，会有一个master进程和多个worker进程。

1. master进程主要用来管理worker进程，主要包含:接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。
2. master进程充当整个进程组与用户的交互接口，同时对进程进行监护。它不需要处理网络事件，不负责业务的执行，只会通过管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。

1.3 Nginx+FastCGl运行原理

Nginx不支持对外部程序的直接调用或者解析，所有的外部程序(包括 PHP）必须通过FastCGl接口来调用。FastCGl接口在Linux 下是socket(t这个socket可以是文件socket,也可以是ip socket)。

wrapper为了调用CGI程序，还需要一个FastCGI的wrapper (wrapper可以理解为用于启动另一个程序的程序)，这个 wrapper绑定在某个固定 socket上，如端口或者文件socket。当Nginx将CGl请求发送给这个socket的时候，通过FastCGl接口，wrapper接收到请求，然后Fork(派生）出一个新的线程，这个线程调用解释器或者外部程序处理脚本并读取返回数据;接着wrapper再将返回的数据通过FastCGI接口，沿着固定的socket传递给Nginx;最后 Nginx将返回的数据(html页面或者图片）发送给客户端。

1 隐藏版本号的两种方式

curl -I http://20.0.0.30    查看Nginx的版本

第一种是修改Nginx的源码文件，指定不显示版本号

vi /usr/local/nginx/conf/nginx.conf

server_tokens off;     隐藏版本信息systemctl restart nginx.servicecurl -I http://20.0.0.30    看一下版本信息隐藏没有

第二种方式：修改Nginx的主配置文件
vi /opt/nginx-1.15.9/src/core/nginx.h

#define NGINX_VERSION      "1.1.1"                    
#define NGINX_VER          "IIS" NGINX_VERSION     不去掉这两段的#，直接改后面的参数
下面将Nginx重新编译一次
cd /opt/nginx-1.15.9/       
 ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module 
make -j3
make install
nginx -t
vi /usr/local/nginx/conf/nginx.conf 
server_tokens on;   打开版本显示信息
systemctl restart nginx.service 
curl -I http://20.0.0.30    看一下版本信息改变没有没有

2 修改用户与组

Nginx运行时进程需要有用户与组的支持，用以实现对网站文件读取时进行访问控制。主进程由root创建，子进程由指定的用户与组创建。Nginx默认使用nobody用户帐号与组帐号，一般也要进行修改。修改Nginx用户与组有两种方法，一种是在编译安装时指定用户与组，另一种是修改配置文件指定用户与组。

1.第一种就是指定用户与组参数

第二种就是进入配置文件修改参数

vi /usr/local/nginx/conf/nginx.conf
user  nginx nginx;  ###修改主和组都是nginx
systemctl restart nginx.service ##重启服务

3 配置网页缓存时间

vi /usr/local/nginx/conf/nginx.conf

在上图显示的代码下面插入下面这一段
location ~ \.(gif|jpg|jepg|png|bmp|ico)$ {
     
            root   html;
            expires 1d;         指定缓存时间一天
        }
systemctl restart nginx.service 
选着一张图片放在虚拟机 /usr/local/nginx/html/ 目录下面
然后通过wireshark抓包
打开wireshark开启vm8网卡
在打开谷歌输入20.0.0.12/2.jpg      ###也就是IP地址加图片名字
打开200 ok 的

显示这个就代表图片缓存时间是一天

二、日志切割

随着Nginx运行时间的增加，产生的日志也会逐渐增加，为了方便掌握 Nginx的运行状态，需要时刻关注Nginx日志文件。太大的日志文件对监控是一个大灾难，不便于分析排查，需要定期的进行日志文件的切割。

2.1 写脚本/opt/fenge.sh

把Nginx的日志文件/usr/local/nginx/logs/access.log移动到,目录/var/log/nginx下面，以当前时间做为日志文件的名称，然后用kill-uSR1创建新的日志文件/usr/local/nginx/logs/access.log,最后删除30天之前的日志文件。

编写脚本进行日志切割的思路

1.设置时间变量
2.设置保存日志路径
3·将目前的日志文件进行重命名
4.重建新日志文件
5.删除时间过长的日志文件
6.设置cron任务，定期执行脚本自动进行日志分割
cd /opt/
vi fenge.sh
#!/bin/bash
#Filename: fenge.sh
d=$(date -d "-1 day" "+%Y%m%d")
logs_path="/var/log/nginx"
pid_path="/usr/local/nginx/logs/nginx.pid"
[ -d $logs_path ] || mkdir -p $logs_path
mv /usr/local/nginx/logs/access.log ${logs_path}/51xit.top-access.log-$d
kill -USR1 $(cat $pid_path)
find $logs_path -mtime +30 |xargs rm -rf
chmod +x fenge.sh    添加权限
./fenge.sh 
cd /var/log/nginx/
ll   查看是不是有文件
cat /usr/local/nginx/logs/access.log    没有信息，原来的日志文件重新创建了
crontab -e
30 1 * * * /opt/fenge.sh     设置每天1.30自动执行上面的脚本

#mtime参数的理解如下
-mtime n按照文件的更改时间来找文件，n为整数。

n表示文件更改时间距离为n天，-n表示文件更改时间距离在n天以内，+n表示文件更改时间距离在n天以前。
例如:
-mtime 0表示文件修改时间距离当前为0天的文件，即距离当前时间不到1天(24小时)以内的文件。

-mtime 1表示文件修改时间距离当前为1天的文件，即距离当前时间1天(24小时-48小时）的文件。

-mtime +1表示文件修改时间为大于1天的文件，即距离当前时间2天(48小时）之外的文件

-mtime -1表示文件修改时间为小于1天的文件，即距离当前时间1天(24小时)）之内的文件


xargs是给命令传递参数的一个过滤器，也是组合多个命令的一个工具.

xargs可以将管道或标准输入(stdin）数据转换成命令行参数，也能够从文件的输出中读取数据。

xargs也可以将单行或多行文本输入转换为其他格式，例如多行变单行，单行变多行。

xargs默认的命令是echo，这意味着通过管道传递给xargs的输入将会包含换行和空白，

不过通过xargs的处理，换行和空白将被空格取代。
xargs是一个强有力的命令，它能够捕获一个命令的输出，然后传递给另外一个命令。

之所以能用到这个命令，关键是由于很多命令不支持|管道来传递参数，而日常工作中有有这个必要，所以就有了xargs命令，例.
find /sbin -perm +700 | ls-l   #这个命令是错误的
find /sbin -perm +700 | xargs ls -l   #这样才是正确的

2.2 设置连接超时

vi /usr/local/nginx/conf/nginx.conf
keepalive_timeout  65 180;     默认是65秒，设置超时的180秒
client_header_timeout 80;      
client_body_timeout 80;
systemctl restart nginx.service

keepalive_timeout第一个参数指定了与client的keep-alive连接超时时间，服务器将会在这个时间后关闭连接。可选的第二个参数指定了在响应头Keep-Alive: timeout=time中的time值。这个头能够让一些浏览器主动关闭连接，这样服务器就不必要去关闭连接了。没有这个参数，nginx不会发送Keep-Alive晌应头。
访问网址抓取数据报文，响应头中显示了超时时间是180秒。一般只设置Keepalive_timeout参数即可。
同时在优化后可能还会增加其它超时参数，比如Client_header_timeout参数，指定等待客户端发送请求头的超时时间，Client body _timeout指定请求体读超时时间

2.3 更改进程数

修改 Nginx的配置文件的worker_processes参数，一般设为CPU的个数或者核数，在高并发的情况下可设置为CPU个数或者核数的2倍，可以查看CPU的核数以确定参数。

cat /proc/cpuinfo |grep -c "physical"       查看cpu的核数4

参数设置为4，和CPU的核数相同。运行进程数多一些，响应客户端访问请求时，Nginx就不会临时启动新的进程提供服务，减少了系统的开销，提升了服务速度
vi /usr/local/nginx/conf/nginx.conf
将worker_processes 4; 将里面的数字改成4就可以了
systemctl restart nginx.service ps aux |gerp nginx 查看运行进程数的变化情况

3. 网页压缩

gzip on 开启gzip压缩输出
gzip_min_length 1k 设置允许压缩的页面最小字节
gzip_buffers 4 16k 申请4个单位为16k内存作为压缩流缓存，默认为申请与原始数据大小相同的空间来储存gzip压缩结果
gzip_http_version 1.0 设置识别http协议版本默认是目前大部分已经支持gzip解压，但处理较慢，耗资源
gzip_conp_level 2 指定gzip压缩比，1压缩最小处理快9压缩最大处理慢
gzip_types text/plain 压缩类型，对哪些网页文档启用压缩功能
gzip_vary on 让前端缓存经过gzip压缩页面

进入vi /usr/local/nginx/conf/nginx.conf
在gzip on下插入
gzip  on;
    gzip_buffers 4 64k;
    gzip_http_version 1.1;
    gzip_comp_level 2;
    gzip_min_length 1k;
    gzip_vary on;
    gzip_types text/plain text/javascript application/x-javascript text/css text/mxl application/xml application/xml+rss;
然后在nginx工作目录下建立一个大于1k的文件抓取文件数据报文

4. 配置防盗链

在企业网站服务中，一般都要配置防盗链功能，以避免网站内容被非法盗用，造成经济损失，也避免了不必要的带宽浪费。Nginx的防盗链功能也非常强大，在默认情况下，只需要进行很简单的配置，即可实现防盗链处理。

4.1 实验

1.防盗链需要准备两台主机模防盗链
进入Windows中 C:\Windows\System32\drivers\etc 设置一下hosts，加入两个映射
防盗的虚拟机 20.0.0.30 www.51xit.top
盗窃的虚拟机 20.0.0.31 www.52xit.top

先设置防盗的虚拟机

vi /usr/local/nginx/html/index.html 
<html>
<head>
<title>-压缩测试页-</title>
</head>
<body><h1>防盗的! ! This is test Page!! </h1>
<img src= "./2.jpg" />
</body>
</html>
20.0.0

然后设置盗窃的虚拟机，这里用的apache的

vi /usr/local/httpd/htdocs/index.html
<html>
<head>
<title>-压缩测试页-</title>
</head>
<body><h1>这是一个测试网页内容压缩的页面! ! This is test Page!! </h1>
<img src=http://www.51xit.top/2.jpg />
</body>
</html>

然后登录谷歌测试一下http://20.0.0.31/

最后最一下防盗链，进入防盗虚拟机中

vi /usr/local/nginx/conf/nginx.conf
 location ~* \.(gif|jpg|jepg|png|bmp|ico)$ {
     
            root   html;
            expires 1d;
#           valid_referers none blocked *.51xit.top 51xit.top;
#            if ($invalid_referer) {
     
#            rewrite ^/ https://ss0.bdstatic.com/70cFvHSh_Q1YnxGkpoWK1HF6hhy/it/u=250679977,3979511213&fm=26&gp=0.jpg;
#            }
插入前面带#的
systemctl restart nginx.service 

下面分析一下这段代码:
~* \.(jpg|gif|swf)$:这段正则表达式表示匹配不区分大小写，以.jpg或.gif或.swf结尾的
文件
Valid_referers:设置信任的网站，今以正常使用图片。
None :浏览器中referer为空的情况，就是直接在浏览器访问图片。
Blocked :referer不为空的情况，但是值被代理或防火墙删除了，这些值不以http://或
https://开头。
后面的网址或者域名:referer中包含相关字符串的网址。
If语句:如果链接的来源域名不在valid_referers所列出的列表中，$invalid_referer为
1，则执行后面的操作，即进行重写或返回403页面。
这时重启服务器，重新访问http://20.0.0.31/index.html，显示的是被重写的图片，
说明防盗链配置成功。