系统运维——Web 服务器配置详解

最新推荐文章于 2024-09-18 19:02:21 发布

。

最新推荐文章于 2024-09-18 19:02:21 发布

阅读量920

点赞数 21

文章标签：前端服务器运维

本文链接：https://blog.csdn.net/2302_77547907/article/details/141393413

版权

一.Web 服务基础介绍

首先我们在浏览器输入一个域名进行DNS解析，一单按下回车之后，这时候客户端就会发起一个httpd request请求，这个request请求就会经过互联网然后经过域名到公网IP上，这个域名是对应的公网IP会进行DNS解析，这个DNS解析会涉及到一个递归和迭代，这个递归和迭代的过程是面试的时候百分之80的时候会问到，我们在浏览器输完一个域名之后都发生了什么。最终我们为什么能够看见这个网站里面的内容，这个是面试会问的。一旦请求到了web服务器之后就到了里面的web server这个web server有可能是nginx有可能是apache，这个web server本身能够处理一些静态请求。静态请求通常是一些index.html的文件。就是index.html文件里面写什么就会显示什么，如果这时候web server有一些内容处理不了，这些内容是有php和java写的，web server就会往后端的application（应用服务器）上转，这些application（应用服务器）就会按照微服的一些功能将他划分开，这个就看用户是需要查看图片还是需要上传资料，如果是需要上传资源就存放到后端的数据库服务中，如果是要查看图片我们就直接响应给用户，如果是要生成订单我们还要将这些订单信息写到数据库中，数据库写完之后后端服务器再把这个请求返回给web server（nginx或者apache ），这时候web server会把请求在返回给用户，这样的话用户就拿到了类似于网站的源代码一样，这个源代码我们在浏览器中可以通过右键去看见，这个源代码就是我们在当前网页中看到的源代码一样，浏览器拿到这个源代码之后会进行渲染成我们用户能看见的界面，这是一个对浏览器访问的时候简单的流程。

Apache 经典的 Web 服务端

Apache起初由美国的伊利诺伊大学香槟分校的国家超级计算机应用中心开发

目前经历了两大版本分别是1.X和2.X

其可以通过编译安装实现特定的功能

Apache prefork 模型
预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024

每个子进程有一个独立的线程响应用户请求

相对比较占用内存，但是比较稳定，可以设置最大和最小进程数

是最古老的一种模式,也是最稳定的模式，适用于访问量不是很大的场景

优点：稳定

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

Apache worker 模型
一种多进程和多线程混合的模型

有一个控制进程，启动多个子进程

每个子进程里面包含固定的线程

使用线程程来处理请求

当线程不够使用的时候会再启动一个新的子进程,然后在进程里面再启动线程处理请求

由于其使用了线程处理请求，因此可以承受更高的并发

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

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

Apache event模型
Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型,属于事件驱动模型(epoll)

每个进程响应多个请求，在现在版本里的已经是稳定可用的模式

它和worker模式很像，最大的区别在于，它解决了keepalive场景下长期被占用的线程的资源浪费问题（某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）

event MPM中，会有一个专门的线程来管理这些keepalive类型的线程

当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力

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

缺点：没有线程安全控制

Nginx-高性能的 Web 服务端

Nginx是由1994年毕业于俄罗斯国立莫斯科鲍曼科技大学的同学为俄罗斯rambler.ru公司开发的，开发工作最早从2002年开始，第一次公开发布时间是2004年10月4日，版本号是0.1.0
2019年3月11日F5 与 NGINX达成协议,F5 将收购 NGINX 的所有已发行股票，总价值约为 6.7 亿元。6.7亿美金约合44.97亿人民币,nginx核心模块代码长度198430（包括空格、注释），所以一行代码约为2.2万人民币官网地址 www.nginx.org
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或者进行二次开发

服务端 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文件的读写

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

网络I/O 处理过程

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

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

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

不论磁盘和网络I/O

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

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

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

I/O 模型相关概念

同步/异步：关注的是消息通信机制，即调用者在等待一件事情的处理结果时，被调用者是否提供完成状态的通知。

同步：synchronous，被调用者并不提供事件的处理结果相关的通知消息，需要调用者主动询问事情是否处理完成

异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态

用户空间一直询问等待内核为同步

用户空间等内核通知再去拷贝数据为异步

阻塞/非阻塞：关注调用者在等待结果返回之前所处的状态

阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起，干不了别的事情。

非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，而无需等到IO操作彻底完成，在最终的调用结果返回之前，调用者不会被挂起，可以去做别的事情。

网络 I/O 模型
阻塞型、非阻塞型、复用型、信号驱动型、异步

阻塞型 I/O 模型（blocking IO）

阻塞IO模型是最简单的I/O模型，用户线程在内核进行IO操作时被阻塞

用户线程通过系统调用read发起I/O读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作

用户需要等待read将数据读取到buffer后，才继续处理接收的数据。整个I/O请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够

优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源

缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较apache 的preforck使用的是这种模式。

同步阻塞：程序向内核发送I/O请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进程将一直等待并不再接受新的请求，并由进程轮询查看I/O是否完成，完成后进程将I/O结果返回给 Client，在IO没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看I/O是否完成，这种方式简单，但是比较慢，用的比较少。

二：Nginx的源码安装

Nginx版本
Mainline version 主要开发版本,一般为奇数版本号,比如1.19
Stable version 当前最新稳定版,一般为偶数版本,如:1.20
Legacy versions 旧的稳定版,一般为偶数版本,如:1.18
Nginx安装可以使用yum或源码安装，但是推荐使用源码编译安装
yum的版本比较旧
编译安装可以更方便自定义相关路径
使用源码编译可以自定义相关功能，更方便业务的上的使用

Nginx 编译安装

编译器：

源码安装需要提前准备标准的编译器，GCC的全称是（GNU Compiler collection），其有GNU开发，并以 GPL即LGPL许可，是自由的类UNIX即苹果电脑Mac OS X操作系统的标准编译器，因为GCC原本只能处理C语言，所以原名为GNU C语言编译器，后来得到快速发展，可以处理C++,Fortran，pascal，objective C， java以及Ada等其他语言，此外还需要Automake工具，以完成自动创建Makefile的工作，Nginx的一些模块需要依赖第三方库，比如: pcre（支持rewrite），zlib（支持gzip模块）和openssl（支持ssl模块）等。

官方源码包下载地址：

https://nginx.org/en/download.html

这里用的压缩包安装

[root@Nginx ~]# dnf install gcc pcre-devel zlib-devel openssl-devel -y #下载依赖项
[root@Nginx nginx-1.24.0]# useradd -s /sbin/nologin -M nginx
[root@Nginx nginx]# tar zxf nginx-1.24.0.tar.gz
[root@Nginx nginx-1.24.0]# useradd -s /sbin/nologin -M nginx
[root@Nginx nginx]# cd nginx-1.24.0/
[root@Nginx nginx-1.24.0]# ls
auto CHANGES.ru configure html Makefile objs src
CHANGES conf contrib LICENSE man README
[root@Nginx nginx-1.24.0]# ./configure --prefix=/usr/local/nginx \
--user=nginx \ # 指定nginx运行用户
--group=nginx \ # 指定nginx运行组
--with-http_ssl_module \ # 支持https://
--with-http_v2_module \ # 支持http版本2
--with-http_realip_module \ # 支持ip透传
--with-http_stub_status_module \ # 支持状态页面
--with-http_gzip_static_module \ # 支持压缩
--with-pcre \ # 支持正则
--with-stream \ # 支持tcp反向代理
--with-stream_ssl_module \ # 支持tcp的ssl加密
--with-stream_realip_module # 支持tcp的透传ip
[root@Nginx nginx-1.24.0]# make && make install

nginx完成安装以后，有四个主要的目录：

[root@Nginx nginx-1.24.0]# ls /usr/local/nginx/
conf html logs sbin
conf：保存nginx所有的配置文件，其中nginx.conf是nginx服务器的最核心最主要的配置文件，其他
的.conf则是用来配置nginx相关的功能的，例如fastcgi功能使用的是fastcgi.conf和fastcgi_params
两个文件，配置文件一般都有一个样板配置文件，是以.default为后缀，使用时可将其复制并将default后缀
去掉即可。
html目录中保存了nginx服务器的web文件，但是可以更改为其他目录保存web文件,另外还有一个50x的web
文件是默认的错误页面提示页面。
logs：用来保存nginx服务器的访问日志错误日志等日志，logs目录可以放在其他路径，比
如/var/logs/nginx里面。
sbin：保存nginx二进制启动脚本，可以接受不同的参数以实现不同的功能。

验证版本及编译参数

[root@Nginx ~]# vim ~/.bash_profile
export PATH=$PATH:/usr/local/nginx/sbin #写了过后可以直接用nginx启动nginx
[root@Nginx ~]# source ~/.bash_profile
[root@Nginx ~]# nginx -V
nginx version: nginx/1.24.0
built by gcc 11.4.1 20231218 (Red Hat 11.4.1-3) (GCC)
built with OpenSSL 3.0.7 1 Nov 2022
TLS SNI support enabled
configure arguments: --group=nginx --with-http_ssl_module --with-http_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

使用安装完成的二进制文件nginx

[root@Nginx ~]# nginx -v
nginx version: nginx/1.18.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:

-?,-h : this help

-v : show version and exit

-V : show version and configure options then exit #显示版本和编译参数

-t : test configuration and exit #测试配置文件是否异

-T : test configuration, dump it and exit #测试并打印

-q : suppress non-error messages during configuration testing #静默
模式

-s signal : send signal to a master process: stop, quit, reopen, reload #
发送信号,reload信号会生成新的worker,但master不会重新生成

-p prefix : set prefix path (default: /etc/nginx/) #指定Nginx 目录

-c filename : set configuration file (default: /etc/nginx/nginx.conf) #
配置文件路径

-g directives : set global directives out of configuration file #设置全局指令,注意和
配置文件不要同时配置,否则冲突

2.2平滑升级和回滚

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

将旧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

平滑升级和回滚案例

[root@Nginx nginx]# tar zxf nginx-1.26.1.tar.gz
[root@Nginx nginx]# cd nginx-1.26.1/
#开始编译新版本
[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 --add-module=/root/nginx-1.26.1/echo-nginx-module-0.63 #添加新模块
with-stream_realip_module
#只要make无需要make install
[root@Nginx nginx-1.26.1]# make
#查看两个版本
[root@Nginx nginx-1.26.1]# ll objs/nginx /usr/local/nginx/sbin/nginx
-rwxr-xr-x 1 root root 1239416 Jul 18 15:08 objs/nginx
-rwxr-xr-x 1 root root 5671488 Jul 18 11:41 /usr/local/nginx/sbin/nginx
#把之前的旧版的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 sbin]# nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
[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
#检测版本信息
[root@Nginx sbin]# curl -I localhost
HTTP/1.1 200 OK
Server: nginx/1.26.1 #新版本生效
Date: Thu, 18 Jul 2024 07:59:45 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
#回滚
#如果升级的版本发现问题需要回滚,可以重新拉起旧版本的worker
[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.1Nginx状态页的查看
基于nginx 模块 ngx_http_stub_status_module 实现

在编译安装nginx的时候需要添加编译参数 --with-http_stub_status_module

否则配置完成之后监测会是提示法错误

状态页显示的是整个服务器的状态，而非虚拟主机的状态

只需要在添加这行

验证

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

主配置文件：nginx.conf

子配置文件: include conf.d/*.conf

fastcgi， uwsgi，scgi 等协议相关的配置文件

mime.types：支持的mime类型，MIME(Multipurpose Internet Mail Extensions)多用途互联网邮

件扩展类型，MIME消息能包含文本、图像、音频、视频以及其他应用程序专用的数据，是设定某

种扩展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动

使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式。

Nginx 压缩功能
Nginx支持对指定类型的文件进行压缩然后再传输给客户端，而且压缩还可以设置压缩比例，压缩后的文件大小将比源文件显著变小，样有助于降低出口带宽的利用率，降低企业的IT支出，不过会占用相应的CPU资源。 Nginx对文件的压缩功能是依赖于模块 ngx_http_gzip_module,默认是内置模块

#启用或禁用gzip压缩，默认关闭
gzip on | off;
#压缩比由低到高从1到9，默认为1，值越高压缩后文件越小，但是消耗cpu比较高。基本设定未4或者5
gzip_comp_level 4;
#禁用IE6 gzip功能，早期的IE6之前的版本不支持压缩
gzip_disable "MSIE [1-6]\.";
#gzip压缩的最小文件，小于设置值的文件将不会压缩
gzip_min_length 1k;
#启用压缩功能时，协议的最小版本，默认HTTP/1.1
gzip_http_version 1.0 | 1.1;
#指定Nginx服务需要向服务器申请的缓存空间的个数和大小,平台不同,默认:32 4k或者16 8k;
gzip_buffers number size;
#指明仅对哪些类型的资源执行压缩操作;默认为gzip_types text/html，不用显示指定，否则出错
gzip_types mime-type ...;
#如果启用压缩，是否在响应报文首部插入“Vary: Accept-Encoding”,一般建议打开
gzip_vary on | off;
#预压缩，即直接从磁盘找到对应文件的gz后缀的式的压缩文件返回给用户，无需消耗服务器CPU
#注意: 来自于ngx_http_gzip_static_module模块
gzip_static on | off;

Nginx 防盗链
防盗链基于客户端携带的referer实现，referer是记录打开一个页面之前记录是从哪个页面跳转过来的标记信息，如果别人只链接了自己网站图片或某个单独的资源，而不是打开了网站的整个页面，这就是盗链，referer就是之前的那个网站域名，正常的referer信息有以下几种：

直接访问自己的网站referer的信息就是none，通过别人的网站链接到自己网站的referer就有信息

none： #请求报文首部没有referer首部，
#比如用户直接在浏览器输入域名访问web网站，就没有referer信息。

blocked： #请求报文有referer首部，但无有效值，比如为空。
server_names： #referer首部中包含本主机名及即nginx 监听的server_name。
arbitrary_string： #自定义指定字符串，但可使用*作通配符。示例: *.wang.org
www.wang.*
regular expression： #被指定的正则表达式模式匹配到的字符串,要使用~开头，例如：
~.*\.wang\.com

正常通过搜索引擎搜索web 网站并访问该网站的referer信息

[root@node1 conf.d]# tail -n 5 /usr/local/nginx/logs/access.log

实现盗链

另一台主机托入盗链：
[root@nginx-node1 ~]# dnf install httpd -y
[root@nginx-node1 ~]# cd /var/www/html/
[root@nginx-node1 html]# ls
daolian.png
[root@nginx-node1 html]# mv daolian.png /var/www/html/index.html
[root@nginx-node1 html]# ls
index.html
[root@nginx-node1 html]# cat index.html
<html>

<head>
<meta http-equiv=Content-Type content="text/html;charset=utf-8">
<title>盗链</title>
</head>

<body>
<img src="http://www.timingding.org/images/zrn.jpg" >
<h1 style="color:red">aaa</h1>
<p><a href=http://www.timingding.org>aaa</a>aaa</p>
</body>

</html>

Nginx的正反向代理功能机负载均衡

正向代理

ngx_http_proxy_module: --------- 将客户端的请求以 http 协议转发至指定服务器进行处理
ngx_http_upstream_module ---------- 用于定义为 proxy_pass,fastcgi_pass,uwsgi_pass
等指令引用的后端服务器分组
ngx_stream_proxy_module: --------- 将客户端的请求以 tcp 协议转发至指定服务器处理
ngx_http_fastcgi_module: ------ 将客户端对 php 的请求以 fastcgi 协议转发至指定服务器助理
ngx_http_uwsgi_module: ------ 将客户端对 Python 的请求以 uwsgi 协议转发至指定服务器处理

反向代理的配置参数

proxy_pass; ------ 用来设置将客户端请求转发给的后端服务器的主机
可以是主机名(将转发至后端服务做为主机头首部)、IP 地址：端口的方式
也可以代理到预先设置的主机群组，需要模块ngx_http_upstream_module支持
proxy_hide_header field; ------- 用于 nginx 作为反向代理的时候
在返回给客户端http响应时
隐藏后端服务器相应头部的信息
可以设置在http,server或location块
proxy_pass_header field; ---------- 透传
默认 nginx 在响应报文中不传递后端服务器的首部字段 Date, Server, X-Pad, X-Accel 等参数
如果要传递的话则要使用 proxy_pass_header field 声明将后端服务器返回的值传递给客户端
field 首部字段大小不敏感
proxy_pass_request_body on | off;
是否向后端服务器发送HTTP 实体部分 , 可以设置在 http,server 或 location 块，默认即为开启
proxy_pass_request_headers on | off;
是否将客户端的请求头部转发给后端服务器，可以设置在 http,server 或 location 块，默认即为开启
proxy_set_header;
可更改或添加客户端的请求头部信息内容并转发至后端服务器，比如在后端服务器想要获取客户端的真实IP 的时候，就要更改每一个报文的头部
proxy_connect_timeout time;
配置 nginx 服务器与后端服务器尝试建立连接的超时时间，默认为 60 秒
proxy_read_timeout time;
配置 nginx 服务器向后端服务器或服务器组发起 read 请求后，等待的超时时间，默认 60s
proxy_send_timeout time;
配置 nginx 项后端服务器或服务器组发起 write 请求后，等待的超时时间，默认 60s
proxy_http_version 1.0;
用于设置 nginx 提供代理服务的 HTTP 协议的版本，默认 http 1.0
proxy_ignore_client_abort off;
当客户端网络中断请求时，nginx 服务器中断其对后端服务器的请求。即如果此项设置为 on 开启，则服务器、会忽略客户端中断并一直等着代理服务执行返回，如果设置为off ，则客户端中断后 Nginx 也会中断客户端请求并立即记录499 日志，默认为 off 。

指定 location 实现反向代理

[root@nginx-node1 ~]# dnf install php -y
[root@nginx-node1 ~]# systemctl restart httpd
[root@nginx-node1 ~]# vim /var/www/html/index.php
<?php
phpinfo();
?>

[root@nginx ~]# vim /usr/local/nginx/conf.d/vhost.conf
server {
listen 80;
server_name www.timingding.org;

location ~ \.php$ {
proxy_pass http://172.25.254.10:80;
}

location /static {
proxy_pass http://172.25.254.20:8080;
}
}
[root@nginx ~]# nginx -s reload

网页访问www.timingding.org/index.php = 172.25.254.10

负载均衡
单个服务器解决不了，我们增加服务器的数量，然后将请求分发到各个服务器上，将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上，将负载均衡分发到不同的服务器，也就是我们所说的负载均衡。

负载均衡（Load Balance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。简单来说就是：现有的请求使服务器压力太大无法承受，所有我们需要搭建一个服务器集群，去分担原先一个服务器所承受的压力，那现在我们有ABCD等等多台服务器，我们需要把请求分给这些服务器，但是服务器可能大小也有自己的不同，所以怎么分？如何分配更好？

NGINX负载均衡三种方式：
(1) 轮询法（默认方法）：

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。
适合服务器配置相当，无状态且短平快的服务使用。也适用于图片服务器集群和纯静态页面服务器集群。

(2) weight 权重模式（加权轮询）：

指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。
这种方式比较灵活，当后端服务器性能存在差异的时候，通过配置权重，可以让服务器的性能得到充分发挥，有效利用资源。weight 和访问比率成正比，用于后端服务器性能不均的情况。权重越高，在被访问的概率越大

(3) ip_hash：

我们可以采用 ip_hash 指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。

动静分离
动静分离，在我们的软件开发中，有些请求是需要后台处理的，有些请求是不需要经过后台处理的（如：css、html、jpg、 js 等文件），这些不需要经过后台处理的文件称为静态文件。让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开，动态资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，以提高资源的响应速度。

Nginx的静态处理能力很强，但是动态处理能力不足，因此，在企业中常用动静分离技术。动静分离技术其实是采用代理的方式，在 server{} 段中加入带正则匹配的 location 来指定匹配项;
针对PHP的动静分离：静态页面交给 Nginx 处理，动态页面交给 PHP-FPM 模块或 Apache 处理。在Nginx的配置中，是通过 location 配置段配合正则匹配实现静态与动态页面的不同处理方式。