运维必会之nginx篇_nginx详解与运维

nginx防盗链的作用

在企业中，一般都需要配置防盗链，这样避免网站的内容被非法盗用，造成经济损失，也可以减少服务器带宽的使用。

nginx防盗链配置

环境说明：
系统为redhat8.2
两台主机均安装nginx

1.准备工作

// 两台主机都要做以下操作
[root@www html]# cat /etc/hosts 
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.182.137 www.bt.com
192.168.182.143 www.test.com


//在windows的C:\Windows\System32\drivers\etc目录下找到hosts文件，并添加如下内容
192.168.182.137 www.bt.com
192.168.182.143 www.test.com
1
2
3
4
5
6
7
8
9
10
11

2. 被盗主机配置

[root@www html]# pwd
/usr/local/nginx/html

[root@www html]# ls | grep source.png
source.png
1
2
3
4
5

3.盗链主机的配置

[root@www html]# pwd
/usr/local/nginx/html

[root@www html]# vim index.html
<p><em>Thank you for using nginx.</em></p>
<img src="http://www.bt.com/source.png"/>  //添加此行，盗取源主机上的图片
1
2
3
4
5
6

4. 测试盗链是否成功

// 使用www.test.com来访问，盗取成功

5.配置nginx防盗链

nginx防盗链的原理是加入location项，用正则表达式来过滤图片类型的文件，对于信任的网站可以正常使用和访问，对于不信任的网站则会返回错误的图片。在源主机也就是www.bt.com的配置文件中加入如下内容

[root@www conf]# pwd
/usr/local/nginx/conf

[root@www conf]# vim nginx.conf
        location ~* \.(png|gif|swf)$ {
               valid_referers none blocked *.bt.com bt.com;
               if ($invalid_referer) {
                  rewrite ^/ http://www.bt.com/error.jpg;
               }

        }  

// ~* \.(png|gif|swf)$，正则表达式，匹配以 .png .gif .swf等结尾并不区分大小写还有如.jpg结尾的可以自行，因为我们这里的防盗链的图是以.jpg结尾的所以这里我们不能加入

// valid_referers是设置信任的网站域名，可以正常访问图片；
// none 浏览器中的referer为空的情况，就是直接在浏览器访问图片
// blocked 浏览器中referer不为空的情况，但是值被防火墙或者代理删除了，这些值不以http://或https://开头。
后面的网址或者域名: referer中包含相关字符串的网址。

// if语句：如果链接的来源域名不在valid_referer所列出的列表中，$invalid_referer为1，则执行后面的操作，即进行重写或返回403页面。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 在源主机也就是www.bt.com的/usr/local/nginx/html目录下放一张错误图片
[root@www html]# pwd
/usr/local/nginx/html

[root@www html]# ls
50x.html  error.jpg  index.html  source.png
1
2
3
4
5
6

6.防盗测试

// 重启源主机(www.bt.com)的nginx
[root@www html]# systemctl restart nginx.service
1
2

防盗成功

// 使用域名访问

// 使用IP访问

nginx隐藏版本号

为什么要隐藏版本号呢？有的小伙伴可能会很好奇，这是因为如果某个版本出现了BUG那么一些黑客、竞争对手。会利用这个BUG对你服务器进行攻击，从而造成不必要的损失。

隐藏版本号的配置

隐藏版本号的主机的IP为192.168.182.143

[root@www conf]# pwd
/usr/local/nginx/conf

[root@www conf]# vim nginx.conf
19     default_type  application/octet-stream;
20     server_tokens off;  //添加此行内容 off表示关闭

// 重启nginx服务
[root@www conf]# systemctl restart nginx.service

// 我们在本地访问
[root@www html]# curl -I 192.168.182.143
HTTP/1.1 403 Forbidden
Server: nginx   //没有版本
1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 通过浏览器访问，发现看不见版本号了

版本深度优化

下面隐藏版本号的方式不建议大家使用，因为如果倒时需要根据nginx某个版本进行优化的话这种方式会给自己带来不必要的麻烦

// 我们使用下面的命令也还是可以看到nginx的命令
[root@www html]# nginx -v
nginx version: nginx/1.20.1

// 下面咱们让自己也看不到
[root@www core]# pwd
/usr/local/nginx-1.20.1/src/core

// 修改之后重新编译即可
[root@www core]# vim nginx.h
#define nginx_version      1020001
#define NGINX_VERSION      ""  //将版本号删除，或者随意写一个数字
#define NGINX_VER          "web/" NGINX_VERSION  //咱们将nginx改为web

[root@www nginx-1.20.1]# nginx -v
nginx version: web/
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

nginx返向代理与负载均衡

• 说到反向代理相信大家并不陌生，nginx的反向代理常常与负载均衡一起出现，反向代理就是当用户请求某个资源的时候，会通过反向代理服务器，而代理服务器会将请求转发到有用户所需要资源的服务器上，然后服务器将相应的资源找到后给到代理服务器，最后资源将通过代理服务器转交给用户。

• 既然讲到了反向代理相信大家也好奇正向代理，透明代理是什么？这里我们就来讲一下，正向代理就是代替用户去访问请求的资源，用户要访问一个网站，而正向代理就会接收用户请求，去找对应资源然后返回给客户端。

• 这里要说明一下正向代理于反向代理的区别：正向代理对客户端负责，正向代理是客户端与其他所有服务器的代理。

• 反向代理是对服务端负责，是客户端与所要代理的服务器之间的代理。

• 透明代理：又名内网代理、拦截代理、强制代理。透明代理是拦截客户端的请求，自己代表客户端去访问服务端，获取到结果后再由透明代理交给客户端，一般用于内网。

• 什么是负载均衡呢？大家都知道每一台服务器都是有自己的瓶颈的，所以当用户的访问量超过了服务器的所能承载的范围或者快达到瓶颈，这样用户访问速度就会降低影响用户体验，甚至导致服务器宕机。
  一台主机承载不了访问，那么我用多台呢？负载均衡就是通过策略将请求分发到多台主机上，从而提高访问速度，减轻服务器的负担。

nginx反向代理与负载均衡

[root@www conf]# pwd
/usr/local/nginx/conf

[root@www conf]# vim nginx.conf
 34     upstream  test {   //test为集群名称
 35       server 127.0.0.1:80;  //这里一个server代表一台主机，127.0.0.1为要负载均衡的主机80为要负载均衡服务的端口号
 36       server 127.0.0.1:80;
 37 }

 47         location / {
 48             root   html;
 49             index  index.html index.htm;
 50             proxy_pass http://test;  //反向代理发配置，test为集群名
 51          
 52         }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

nginx优化之网页压缩

配置网页压缩是为了减少资源浪费

[root@www conf]# pwd
/usr/local/nginx/conf

gzip  on;  //取消注释开启nginx的gzip压缩功能
    gzip_buffers 4 64k;  //压缩缓冲区，大小为4个64k缓冲区
    gzip_http_version 1.1;  //压缩版本
    gzip_comp_level 2;  //压缩比率，1-6等级
    gzip_min_length 1k;  //最小压缩文件的大小
    gzip_vary on;  //支持前端缓存服务器存储压缩页面
    gzip_types text/plain text/javascript application/x-javascript text/css text/xml application/xml application/xml+rss image/jpg image/jpeg image/png image/gif application/x-httpd-php application/javascript application/json;  //压缩类型，表示哪些网页文档启用压缩功能

[root@www html]# pwd
/usr/local/nginx/html

[root@www html]# ls  //上传一张图片进行测试
50x.html  index.html  test.jpg

[root@www html]# vim index.html
24 <img src="test.jpg"/>   //添加此行

// 重启nginx
[root@www html]# systemctl restart nginx.service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

nginx优化之配置网页缓存时间

// 当nginx将网页数据返回给客户端后，可以设置缓存时间，以方便日后进行相同内容请求时直接返回，避免重复请求，加快访问速度，一般只针对静态资源进行设置，对动态网页不用设置缓存时间。

// 配置网页缓存

[root@www conf]# pwd
/usr/local/nginx/conf
[root@www conf]# vim nginx.conf
        location ~\.(gif|jpg|png|jepg|bmp|ico)$ {  //这个文件类型以.png .jpg结尾等
          root html;  
          expires 1d;   //指定缓存时间为1天
}
        #error_page  404              /404.html;

1
2
3
4
5
6
7
8
9

测试

[root@www html]# pwd
/usr/local/nginx/html

[root@www html]# ls  //这里我们还是使用上面的图片
50x.html  index.html  test.jpg

[root@www html]# vim index.html  //同样的操作
<img src="test.jpg"/>

//重启nginx
[root@www html]# systemctl restart nginx.service
1
2
3
4
5
6
7
8
9
10
11

// 一天之内浏览器请求这个页面，都会使用这个缓存，而不会向nginx服务器发出请求，减少服务器的使用频率。

nginx优化之压力测试

ab接口压力测试工具，ab是apache自带的性能测试工具。主要是显示你安装的apache每秒可以处理多少个请求

[root@www html]# yum -y install httpd-tools

[root@www html]# ab -n 3000 -c 10 192.168.182.143/index.html
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.182.143 (be patient)
Completed 300 requests
Completed 600 requests
Completed 900 requests
Completed 1200 requests
Completed 1500 requests
Completed 1800 requests
Completed 2100 requests
Completed 2400 requests
Completed 2700 requests
Completed 3000 requests
Finished 3000 requests


Server Software:        nginx  //http响应数据的头信息
Server Hostname:        192.168.182.143  //请求的url中的主机名称
Server Port:            80  //web服务器软件的监听端口

Document Path:          /index.html  //请求的url根的绝对路径
Document Length:        635 bytes  //http响应数据的正文长度

Concurrency Level:      10  //并发的用户数
Time taken for tests:   0.188 seconds  //处理这些请求被处理完成所花费的时间总和
Complete requests:      3000  //表示总请求数
Failed requests:        0  //失败的请求总数
Total transferred:      2583000 bytes  //请求的响应数据长度总和
HTML transferred:       1905000 bytes  //整个场景中的HTML内容传输量
Requests per second:    15952.19 [#/sec] (mean)  //服务器吞吐量，每秒处理的请求数
Time per request:       0.627 [ms] (mean)   //用户平均请求等待时间
Time per request:       0.063 [ms] (mean, across all concurrent requests)  //每个请求实际运行时间的平均值
Transfer rate:          13412.92 [Kbytes/sec] received

Connection Times (ms)  //表示网路上消耗的时间的分解
              min  mean[+/-sd] median   max
Connect:        0    0   0.4      0      20
Processing:     0    1   1.1      0      20
Waiting:        0    0   1.1      0      20
Total:          0    1   1.1      0      20

Percentage of the requests served within a certain time (ms)  //描述每个请求处理时间的分布情况
  50%      0
  66%      1
  75%      1
  80%      1
  90%      1
  95%      1
  98%      1
  99%      2
 100%     20 (longest request)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

nginx性能优化之cpu亲和性配置

cpu亲和性能够使nginx对于不同的work工作进程绑定到不同的cpu上面去。就能够减少在work间不断切换cpu，把进程通常不会在处理器之间频繁迁移，进程迁移的频率小，来减少性能损耗。

nginx运行工作进程个数一般设置cpu的核心或者核心数乘以2。如果不知道自己cpu的核心可以使用top命令，按1来进行查看。

// 查看cpu的核心数也可以使用如下命令
[root@www ~]# cat /proc/cpuinfo | grep processor  //从0开始计算的，所以我们有两核
processor	: 0
processor	: 1

[root@www ~]# cat /proc/cpuinfo | grep "cpu cores" | uniq -c  //uniq -c是统计重复的行数，这里有两核cpu
      2 cpu cores	: 2

//显示物理cpu数量
[root@www conf]# cat /proc/cpuinfo | grep "physical id" | sort 
physical id	: 0
physical id	: 0

// 查看nginx使用cpu核心和对应的nginx进程号
[root@www nginx]# ps -eo pid,args,psr | grep [n]ginx
   1076 nginx: master process /usr/   0
   1077 nginx: worker process         0
   1078 nginx: worker process         1
   1079 nginx: worker process         0
   1080 nginx: worker process         1

这里有必要解释一下ps -eo pid,args,psr的意思
-e 是显示所有进程
-o 是用户自定义参数，就是自己输入要查找的参数如pid等等
pid：显示进程的pid
args：显示进程的名字(该进程执行时传入的命令行参数)
psr：显示运行此进程的cpu
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

ps参数

具体配置操作

[root@www conf]# pwd
/usr/local/nginx/conf

[root@www conf]# vim nginx.conf
worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;

// 查看nginx是否有4个work进程
[root@www conf]# ps -ef | grep nginx | grep -v g[r]ep
root        1887       1  0 09:30 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx       1888    1887  0 09:30 ?        00:00:00 nginx: worker process
nginx       1889    1887  0 09:30 ?        00:00:00 nginx: worker process
nginx       1890    1887  0 09:30 ?        00:00:00 nginx: worker process
nginx       1891    1887  0 09:30 ?        00:00:00 nginx: worker process

// 若是8核的cpu配置如下：
work_processor 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

但是你用的nginx若是1.9版本以上的可以使用下面这种简单的配置

[root@www conf]# vim nginx.conf
worker_processes  4;  //因为nginx1.9版本之后，nginx会自动帮我们进行绑定cpu
worker_cpu_affinity auto;
1
2
3

nginx优化之事件处理模型优化

nginx的连接处理机制在于不同的操作系统会采用不同的I/O模型，linux中nginx使用的是epoll的I/O多路复用模型，在FreeBSD使用kqueue的I/O多路复用模型，在Windows使用的是icop，在solaris使用的是/dev/pool方式的IO多路复用模型等等。要根据系统类型的不同选择不同的事务处理模型，在企业中我们一般会使用的系统为linux，所以这里我们使用epoll模型

[root@www conf]# pwd
/usr/local/nginx/conf

// 说明：在不指定的情况下nginx会自动先择最佳的事务处理模型
[root@www conf]# vim nginx.conf
events {
    worker_connections  1024;
    use epoll;
}

1
2
3
4
5
6
7
8
9
10

设置work_connection连接数

[root@www conf]# vim nginx.conf 
events {
    worker_connections  10024;

1
2
3
4

keepalive timeout会话保持时间

[root@www conf]# vim nginx.conf 
33     keepalive_timeout  65;
1
2

设置nginx的字符集

[root@www conf]# vim nginx.conf 
 48         #charset utf-8;  //将koi8-r改为utf-8
1
2

设置proxy超时设置

proxy_connect_timeout 90;
proxy_send_timeout  90;
proxy_read_timeout  4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k
1
2
3
4
5

高效传输模式

[root@www conf]# vim nginx.conf
29     sendfile        on; //开启高效文件传输模式，对静态资源的处理比较有效
30     #tcp_nopush     on;  //需要在sendfile开启模式才有效，防止网路阻塞，积极的减少网络报文段的数量。将响应头和正文的开始部分一起发送，而不一个接一个的发送，如果做静态资源服务器可以打开
1
2
3

nginx深度优化之linux系统内核层面

为了使nginx到达最好的性能，除了要优化nginx服务外，还需优化nginx服务器上的内核参数
以下操作在/etc/sysctl.conf 文件中进行，使用sysctl -p使其生效

net.core.somaxconn = 262144  //调节系统同时发起的tcp连接数

net.core.somaxconn = 4096 //允许等待中的监听

// tcp连接重用
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

// 不抵御洪水攻击
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144  //该参数用于设定系统中最多允许存在多少TCP套接字不被关联到任何一个用户文件句柄上，主要目的为了防止dbos攻击
1
2
3
4
5
6
7
8
9
10
11

// 最大文件打开数
在命令行中输入如下命令，即可设置Linux最大文件打开数。
ulimit -n 30000
1
2
3

nginx优化之文件句柄的优化

linux/Unix上，一切皆文件，每一次用户发起请求就会生成一个文件句柄，文件句柄可以理解为就是一个索引，所以文件句柄就会随着请求量的增多，而进程调用的频率增加，文件句柄的产生就越多，系统对文件句柄默认的限制是1024个

//设置方式有以下几种

1. 系统全局性修改
2. 用户局部性修改
3. 进程局部性修改

// 系统全局性修改和用户局部性修改
[root@www ~]# vim /etc/security/limits.conf  //在文件最后添加如下内容
root soft nofile 65535  
root hard nofile 65535
*    soft nofile 10050
*    hard nofile 10050

soft：软控制，到达设定值后，操作系统不会采取措施，只是发提醒
hard：硬控制，到达设定值后，操作系统会采取机制对当前进程进行限制，这个时候请求就会受到影响
root：这里代表root用户（系统全局性修改）
*：代表全局，即所有用户都受此限制（用户局部性修改）
nofile：指限制的是文件数的配置项。后面的数字即设定的值，一般设置10000左右
1
2
3
4
5
6
7
8
9
10
11
12

// 进程局部性修改
[root@www conf]# pwd
/usr/local/nginx/conf

[root@www conf]# vim nginx.conf
 11 worker_rlimit_nofile 35535;  //进程限制
1
2
3
4
5
6

nginx优化之日志分割

[root@www test]# cat nginx.sh 
#!/bin/bash
log_path=/var/log/nginx/
t=`date -d "-1 day" "+%Y%m%d"`  //date -d "-1 day"的意思是显示当前时间的前一天， "+%Y%m%d"的意思是显示当前时间的年月日
pid_path=/usr/local/nginx/logs/nginx.pid
 [ -d $log_path ] || mkdir -p $log_path  //判断是否存在变量中的路径，||的意思是或当目录不存在时创建这个目录，当这个目录存在了，就不会创建了
mv /var/log/nginx/access.log ${log_path}test.com-access.log-$t  //这里根据你nginx的访问日志的位置来进行调整，这里我的日志就放在/var/log/ngin目录下然后改个名字
kill -USR1 $(cat $pid_path)  //重新建日志文件
find $log_path -mtime +30 | xargs rm -f  //删除30天之前的日志文件

可能有人对kill -USR1这个命令不解，那么这里我来解释一下。
USR1一般是用来告诉应用程序重载配置文件，就像nginx -s reload的作用类似。
USR1信号的执行步骤是：
1. 停止接受新的连接；
2. 等待当前连接停止；
3. 重新载入配置文件；
4. 重新打开日志文件；
5. 重启服务器
这样就实现了一个相对平滑的更改日志的方式

// 执行脚本之后，就会生成切割之后的日志
[root@www nginx]# ls | grep .log
access.log
error.log
test.com-access.log-20220414
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25