Nginx入门笔记

目录

• 什么是反向代理

  • 正向代理
  • 反向代理

• Nginx进程模型

  • Worker抢占机制
  • Nginx事件处理

• 配置文件

  • 配置结构
  • 主要配置
• 常用命令

• 日志分割

  • 定时任务
  • 分割日志
• 配置一个静态文件
• 使用GZIP压缩
• Location匹配规则

• 跨域的方式

  • 同源策略
  • 跨域资源共享
  • 反向代理
  • 两者比较
• 配置防盗链

• 负载均衡

  • 负载均衡算法
  • 负载均衡实例
  • 长连接优化

• nginx缓存

  • 控制浏览器缓存
  • 反向代理缓存

• 配置SSL证书

  • 证书安装(腾讯云)
  • HTTP 自动跳转 HTTPS 的安全配置（可选）
• 参考

Nginx

Nginx是高性能的http和反向代理web服务器，同时也提供IMAP/POP3/SMTP服务

主要功能有

• 反向代理
• 通过配置文件实现集群和负载均衡
• 静态资源虚拟化

什么是反向代理

正向代理

正向代理→代理客户端：客户端无法直接从将请求送达目标服务器，可以通过能够请求到目标服务器的代理服务器转发请求到目标服务器，并将从目标服务器获取的内容返回给客户端，这就是正向代理。

正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径，就比如说我们再居家办公的时候需要通过vpn访问内网环境，vpn起到的作用就是正向代理。

正向代理可以使用缓存特性减少网络使用率。

反向代理

反向代理→代理服务端：客户端不知道服务器的实际地址，通过访问代理服务器由其将请求转发到相应的服务器上。

反向代理的作用

1. 保护和隐匿原始服务器

   反向代理可以不让客户端直接访问到原始资源服务器

   

2. 负载均衡

   反向代理服务器可以将多个客户端请求通过负载均衡算法将这些请求分发到不同的服务器上以减轻单个服务器的压力，当然，反向代理服务器也可以有多个组成代理服务器集群。

   

3. 缓存

   反向代理服务器可以像正向代理服务器那样拥有缓存的作用，可以将原始资源服务器返回的静态资源等数据进行缓存，提高请求效率，这也是CDN技术的核心。

4. 路由

   可以通过域名中的路由等信息将请求进行分发到不同的服务器上，这点与负载均衡有点像，但是负载均衡主要目的是为了平衡各个服务器的压力，路由是将需求不同的请求分发到不同的服务器。

   

Nginx进程模型

nginx中可分为主进程(master)和工作进程(worker),master进程主要是用来管理woker进行，工作进程可以有多个，但是默认只有1个。

[root@VM-24-13-centos nginx-1.22.0]# ps aux|grep nginx
root      2868  0.0  0.0  22292  1456 ?        Ss   Jul25   0:00 nginx: master process ./nginx
nobody   18991  0.0  0.0  24376  1768 ?        S    20:24   0:00 nginx: worker process

可以通过worker_processes配置来指定工作进行的数量

#user  nobody;
worker_processes  2;

[root@VM-24-13-centos nginx-1.22.0]# ps aux|grep nginx
root      2868  0.0  0.0  22292  1456 ?        Ss   Jul25   0:00 nginx: master process ./nginx
nobody   23812  0.0  0.0  24376  1492 ?        S    20:49   0:00 nginx: worker process
nobody   23813  0.0  0.0  24376  1492 ?        S    20:49   0:00 nginx: worker process

master进程主要是发送以下命令给worker进程使其停止、重启等

Worker抢占

nginx是多进程单线程，这样不仅能够提高nginx的并发效率，也能使进程之间相互不会影响，即使一个worker进程挂掉了不至于影响其它进程。

Worker抢占机制

由主进程创建的 listen socket，要被 fork 出来的子进程共享，但是为了避免多个子进程同时争抢共享资源，nginx 采用一种策略：使得多个子进程，同一时段，只有一个子进程能获取资源，就不存在共享资源的争抢问题。

成功获取锁的，能获取一定数量的资源，而其它没有成功获取锁的子进程，不能获取资源，只能等待成功获取锁的进程释放锁后，nginx 多进程再重新进入锁竞争环节。

Nginx事件处理

master进程管理多个worker进程，然后每个进程对消息的处理使用Linux的epoll模型来仅从io多路复用

events {
    #不写 默认也是epoll
    use  epoll;
    #一个worker进程最大的连接数
    worker_connections  1024;
}

配置文件

配置结构

主要配置

📌全局配置

• user worker 进程的执行用户

  [root@VM-24-13-centos ~]# ps aux|grep nginx
  root      2868  0.0  0.0  22292  1456 ?        Ss   Jul25   0:00 nginx: master process ./nginx
  nobody   23812  0.0  0.0  24376  1492 ?        S    20:49   0:00 nginx: worker process
  nobody   23813  0.0  0.0  24376  1676 ?        S    20:49   0:00 nginx: worker process
  

• woker_processes worker进程数

• error_log 错误日志及日志级别

  日志级别：debug→info→notice-warn→error→crit

  默认日志级别为error

  error_log  logs/error.log;
  error_log  logs/error.log  notice;
  error_log  logs/error.log  info;

• pid日志的进程号

  #默认会配置到以下路径 - 我们打开对应的nginx.pid文件，里面是对应的pid = 2868
  pid        logs/nginx.pid;

http网络模块

• include导入外部配置文件 → 一般用于简化配置
• defalut_type 默认类型
• log_format 日志格式
• access_log请求日志
• senfile on 开启文件高效传输
• tcp_nopush on 数据包累积到一定数量再发送，它开启的前提是需要sendfile开启
• keepalive_timeout http连接的存活时间，单位是秒，默认值是65秒
• gzip on 传输过程中是否对文件进行压缩，压缩后会提高传输效率，但是也会对cpu造成一定的压力。

虚拟主机配置

虚拟主机可以配置成多块

• listen代表监听的端口
• server_name代表域名

• location路由

  • root是代表文件路径
  • index代表默认访问文件

server {
    listen       80;
    server_name  eacape.top;

    location / {
        root   html;
        index  index.html index.htm;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }
}
server {
    listen  80;
    server_name error.eacape.top;

    location / {
        root    html;
        index 50x.html;
    }
}

如上配置，我们设置多个虚拟主机，监听的端口相同，我们通过域名的匹配进行默认页面的路由匹配，即通过eacape.top域名访问服务我们路由的默认页面是index.html,通过error.eacape.top域名访问服务我们将默认页面路由到50x.html,然后在我们的计算机上hosts中配置域名-ip

82.156.2.77 error.eacape.top
82.156.2.77 eacape.top

然后重启nginx，通过访问两个域名的结果如下

常用命令

-v 可查看nginx的版本。
-V 可查看nginx的详细信息，包括编译的参数。
-t 可用来测试nginx的配置文件的语法错误。
-T 可用来测试nginx的配置文件语法错误，同时还可以通过重定向备份nginx的配置文件。
-q 如果配置文件没有错误信息时，不会有任何提示，如果有错误，则提示错误信息，与-t配合使用。
-s 发送信号给master处理：
  stop 立刻停止nginx服务，不管请求是否处理完
  quit 优雅的退出服务，处理完当前的请求退出
  reopen 重新打开日志文件，原日志文件要提前备份改名。
  reload 重载配置文件
-p 设置nginx家目录路径，默认是编译时的安装路径
-c 设置nginx的配置文件，默认是家目录下的配置文件
-g 设置nginx的全局变量，这个变量会覆盖配置文件中的变量。

日志分割

定时任务

Linux crontab 是用来定期执行程序的命令。

当安装完成操作系统之后，默认便会启动此任务调度命令。

crond 命令每分钟会定期检查是否有要执行的工作，如果有要执行的工作便会自动执行该工作。

注意： 新创建的 cron 任务，不会马上执行，至少要过 2 分钟后才可以，当然你可以重启 cron 来马上执行。

而 linux 任务调度的工作主要分为以下两类：

• 1.系统执行的工作：系统周期性所要执行的工作，如备份系统数据、清理缓存
• 2.个人执行的工作：某个用户定期要做的工作，例如每隔 10 分钟检查邮件服务器是否有新信，这些工作可由每个用户自行设置

语法

crontab [ -u user ] { -l | -r | -e }

说明：

crontab 是用来让使用者在固定时间或固定间隔执行程序之用，换句话说，也就是类似使用者的时程表。

-u user 是指设定指定 user 的时程表，这个前提是你必须要有其权限(比如说是 root)才能够指定他人的时程表。如果不使用 -u user 的话，就是表示设定自己的时程表。

参数说明：

• -e : 执行文字编辑器来设定时程表，内定的文字编辑器是 VI，如果你想用别的文字编辑器，则请先设定 VISUAL 环境变数来指定使用那个文字编辑器(比如说 setenv VISUAL joe)
• -r : 删除目前的时程表
• -l : 列出目前的时程表

f1 f2 f3 f4 f5 program

• 其中 f1 是表示分钟，f2 表示小时，f3 表示一个月份中的第几日，f4 表示月份，f5 表示一个星期中的第几天。program 表示要执行的程序。
• 当 f1 为 * 时表示每分钟都要执行 program，f2 为 * 时表示每小时都要执行程序，其馀类推
• 当 f1 为 a-b 时表示从第 a 分钟到第 b 分钟这段时间内要执行，f2 为 a-b 时表示从第 a 到第 b 小时都要执行，其馀类推
• 当 f1 为 */n 时表示每 n 分钟个时间间隔执行一次，f2 为 */n 表示每 n 小时个时间间隔执行一次，其馀类推
• 当 f1 为 a, b, c,... 时表示第 a, b, c,... 分钟要执行，f2 为 a, b, c,... 时表示第 a, b, c...个小时要执行，其馀类推

*    *    *    *    *
-    -    -    -    -
|    |    |    |    |
|    |    |    |    +----- 星期中星期几 (0 - 6) (星期天 为0)
|    |    |    +---------- 月份 (1 - 12) 
|    |    +--------------- 一个月中的第几天 (1 - 31)
|    +-------------------- 小时 (0 - 23)
+------------------------- 分钟 (0 - 59)

使用者也可以将所有的设定先存放在文件中，用 crontab file 的方式来设定执行时间。

实例

每一分钟执行一次 /bin/ls

* * * * /bin/ls

在 12 月内, 每天的早上 6 点到 12 点，每隔 3 个小时 0 分钟执行一次 /usr/bin/backup

0 6-12/3 * 12 * /usr/bin/backup

周一到周五每天下午 5:00 寄一封信给 alex@domain.name：

0 17 * * 1-5 mail -s "hi" alex@domain.name < /tmp/maildata

每月每天的午夜 0 点 20 分, 2 点 20 分, 4 点 20 分....执行 echo "haha"：

20 0-23/2 * * * echo "haha"

分割日志

下面是一段用于按分钟分割日志文件的bash脚本

#!/bin/bash
#日志路径
LOG_PATH="/usr/local/nginx-1.22.0/logs"
#时间格式
RECORD_TIME=$(date -d "today" '+%Y-%m-%d')
#进程id
PID="/usr/local/nginx-1.22.0/logs/nginx.pid"
mv $LOG_PATH/access.log $LOG_PATH/access-$RECORD_TIME.log
mv $LOG_PATH/error.log $LOG_PATH/error-$RECORD_TIME.log
kill -USR1 `cat $PID`

然后可以使用linux的定时任务crontab每天定时定时切割日志文件

使用crontab -e对定时任务进行编辑，然后在其中添加如下内容，其含义为每天的23:59切割日志文件

59 23 * * * /usr/local/nginx-1.22.0/sbin/cut_nginx_log.sh

然后将定时任务重启日志分割就会生效

systemctl restart crond

配置一个静态文件

1. 在主配置文件中增加一个包含文件，在子文件中配置相关的server

2. 配置最简单的路由,将90端口默认首页路由到/app/static/ecape.html

   server {
           listen          90;
           server_name     localhost;
   
           location / {
                   root    /app/static/html;
                   index   eacape.html;
           }
   }

3. 使用别名配置，将/pic路由配置对应的img文件，也就是给/app/static/img的别名置为pic

   location /pic {
           alias   /app/static/img;
   }

4. 效果

   

   

使用GZIP压缩

• 开 启 gzip压 缩 功 能 ， 目 的 ： 提 高 传 输 效 率 ， 节 约 带 宽 - 但 是 会 增 加 服 务 器 io压 力

  gzip on;

• 限 制 最 小 压 缩 ， 小 于 1字 节 文 件 不 会 被 压 缩

  gzip_min_length 1;

• 定 义 压 缩 级 别 （ 压 缩 比 ， 文 件 越 大 ， 压 缩 越 多 ）

  gzip_comp_level 3;

• 压 缩 的 类 型 对 图 片 压 缩

  gzip_types image/jpg image/png image/jpeg;

• 设置gzip压缩针对的HTTP协议版本

  gzip_http_version 1.1;
  

Location匹配规则

• \~ 波浪线表示执行一个正则匹配，区分大小写
• \~* 表示执行一个正则匹配，不区分大小写
• ^\~ 表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录
• \= 进行普通字符精确匹配
• @ 定义一个命名的 location，使用在内部定向时，例如 error\_page, try\_files

location  = / {
  # 只匹配"/".
  [ configuration A ] 
}
location  / {
  # 匹配任何请求，因为所有请求都是以"/"开始
  # 但是更长字符匹配或者正则表达式匹配会优先匹配
  [ configuration B ] 
}
location ^~ /images/ {
  # 匹配任何以 /images/ 开始的请求，并停止匹配 其它location
  [ configuration C ] 
}
location ~* \.(gif|jpg|jpeg)$ {
  # 匹配以 gif, jpg, or jpeg结尾的请求. 
  # 但是所有 /images/ 目录的请求将由 [Configuration C]处理.   
  [ configuration D ] 
}

error_page 404 = @fetch;
 
location @fetch(
proxy_pass http:/是完全/fetch;
)

跨域的方式

同源策略

同源策略是一个重要的安全策略，它用于限制一个origin的文档或它加载的脚本不能与另一个源的资源进行交互。能够减少恶意文档，减少可能被攻击媒介。 如果两个URL的协议、域名、端口号都相同，就称这两个URL同源，则双方可以进行资源交互，否则不行。

浏览器的同源策略目的是为了保护用户的信息安全,为了防止恶意网站窃取用户在浏览器上的数据,如果不是同源的站点,将不能进行如下操作 :

• Cookie、LocalStorage 和 IndexDB 无法读写
• DOM 和 Js对象无法获得
• AJAX请求不能发送

比如说我们前端部署在localhost:80服务器上，但是后端部署的端口是localhost:8080那么由于两个origin的端口不同，所以前后端是不同源的，即在前端的脚本中请求后端的数据由于同源策略是不被浏览器认可的。

跨域资源共享

CORS全称是跨域资源共享(Cross-Origin resource sharing),它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。

浏览器一旦返现AJAX发送的是跨域就会在请求中添加一些头信息。

添加Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

以SpringBoot举例，我们常在服务端的拦截器中加入以下代码，表示同意返回的资源对这些Origin共享。

response.setHeader("Access-Control-Allow-Origin","http://120.28.12.33:80");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Headers", "X-Requested-With,Content-Type,Authorization");
response.setHeader("Access-Control-Allow-Methods", "*");

• Access-Control-Allow-Origin（表示服务器允许的源地址列表）该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。如上配置中只接受Origin为http://120.28.12.33:80请求

• Access-Control-Allow-Credentials（表示发出响应的服务器是否允许浏览器发送cookie）该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下（没有该字段的情况下），Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为，如果服务器不要浏览器发送Cookie，删除该字段即可。

  response.setHeader("Access-Control-Allow-Origin",reqs.getHeader("Origin"));

  如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

  Access-Control-Allow-Credentials: true
  

  另一方面，开发者必须在AJAX请求中打开withCredentials属性。

  var xhr = new XMLHttpRequest();
  xhr.withCredentials = true;

  否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

  需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。所以在springboot中设置这个属性一般如下

  response.setHeader("Access-Control-Allow-Origin",request.getHeader("Origin"));

• Access-Control-Expose-Headers该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。
• Access-Control-Allow-Methods 表示支持跨域请求的方法如 GET POST OPTION等

总结

1. 发现是跨域请求，浏览器自动请求头添加Origin字段，用于后端服务器验证。
2. 服务器都会正常返回响应，状态码无法判断是否跨域请求成功，需要浏览器自动判断服务器返回的响应头信息中，是否有Access-Control-Allow字段。
3. 如果需要CORS请求中使用Cookie，需要前端和后端同时设置Credentials，前端才会正常被设置cookie和发送cookie，后端才会正常给前端设置cookie和接收cookie。
4. 如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。
5. Cookie依然遵循同源策略，只有用本服务器域名设置的Cookie才会被浏览器发送。

反向代理

除了使用CORS的方法还可以使用Nginx做反向代理，具体步骤如下：

1. 将AJAX访问后端的域名端口改成前端服务器的域名端口

   比如说前端的地址为a.domain.com、后端的地址为b.domain.com

   原本js中对应的后端接口地址为http://b.domain.com/api/addUser

   现在改为http://a.domain.com/api/addUser

2. 在发布前端的nginx服务中根据路由匹配做反向代理

   server {
     listen    80;
     server_name  localhost;
       #默认前端页面地址
       location / {
           root   /app/static/;
       }
       #根据匹配规则做反向代理
       location ^~ /api{
           proxy_pass http://b.domain.com;
       }
   }

两者比较

Item	CORS	Nginx反向代理
代码配置--前端	credentials=true	无
代码配置--后台	setHeader:ACA-Origin、ACA-Method、ACA-Credentials等	无
服务器配置	无	Nginx配置
移植灵活性	高、无需额外配置	低、每套环境配置可能均不相同
安全性	来源可控、直接追溯	X-Forwarded-For追溯多级来源
新项目扩展	黑白名单控制	更新配置，跨域模型会产生变化

配置防盗链

HTTP的请求头中有一个参数Referer用于描述请求来自哪一个域名

经常被用于防盗链，比如说之前gitee图床失效，就是使用referer做了防盗链，即从第三方网站请求图片资源会被拦截。

就比如说从百度点击进入某一网站

Referer：https://www.baidu.com/link?url=-aT3sJswSZKZvdnJOqj7o8Egpgn1o5AdYAKrP1hvZuWHkV1bFV_SRdWB3VVDBItyqtFukyMlS8bI6ifhUlP6aa&wd=&eqid=dd059cef000a3ef20000000462d55fcc

说明这一页面时从百度的页面跳转而来，之前访问陈皓老师的博客，如果时通过百度搜索进入他的网站，会提示你，程序员不要用百度，我想这个功能就是通过referer实现的。

防盗链是可以在在后端或者nginx中实现的，下面我们使用nginx来实现这个一个功能，我们让只有来自www.yuanyong.com的请求才能走反向代理，否则返回404，我们在自己本地配置两个host

82.156.2.77 www.xiaoming.com
82.156.2.77 www.yuanyong.com

然后在nginx下做如下配置，代表只有来自www.yuanyong.com的请求才能转发代理

server {
  listen    8081;
  server_name  localhost;

  location / {
    root   /app/static/jk;
  }

    location ^~ /api {
        #对源站点验证
        valid_referers www.yuanyong.com;
        #非法引入回返回 invalid_referer = true验证通过
        if ($invalid_referer){
            return 404;
        }
        proxy_pass http://120.48.87.20:9000;
    }
}

valid\_referers

格式： valid_referers none|blocked|server_names|string

• nginx会通过查看referer自动和valid\_referers后面的内容进行匹配；
• 如果匹配到了就将invalid\_referer 变 量 置 0 ， 如 果 没 有 匹 配 到 ，则invalid\_referer变量置为1；
• 匹配的过程中不区分大小写；

其他参数介绍：

• none：如果Header中的Referer为空，允许访问；
• blocked:在Header中的Referer不为空，但是该值被防火墙或代理进行伪装过，如不带"http\://" 、"https\://"等协议头的资源允许访问；
• server\_names:指定具体的域名或者IP；
• string: 可以支持正则表达式和*的字符串。如果是正则表达式，需要以\~ 开头表示

最终结果会如下,来自www.xiaoming.com的请求被拦截了，www.yuanyong.com没有

负载均衡

负载均衡算法

负载均衡的实现⽅法就是我们上章介绍的反向代理 。将客⼾的请求通过 nginx 分发（反向代理）到⼀组多台不同的服务器上，这⼀组服务器我们称为 服务池（upstream server），池内的每⼀个服务器称为⼀个 单元，服务池内将对每⼀个单元进⾏请求轮训，实现负载均衡

指令： upstream
语法： upstream name {...}
环境： http含义：定义一组 HTTP服务器，这些服务器可以监听不同的端口，以及 TCP和 UNIX套接字。
      在同一个 upstream中可以混合使用不同的端口、 TCP和 UNIX套接字。

指令： server
语法： server address [parameters];
环境： upstream
含义： 配置后端服务器，参数可以是不同的 IP地址、端口号，甚至域名。 

但是请求分发的方式不只是轮询，有以下方式

• 轮询
    即round robin 默认调度算法，静态调度算法。客户端请求顺序把客户端的请求逐一分配到不同的后端节点服务器，宕机的服务器会自动从节点服务器池中剔除，以便客户端的用户访问不受影响。新的请求会分配给正产的服务器。

  upstream  分组名称{
      server 127.0.0.1:8081;
      server 127.0.0.1:8082; 
   }
  

• 权重轮询
    即weight 权重轮循，静态调度算法。在 rr 轮循算法的基础上加上权重，即为权重轮循算法，当使用该算法时，权重和用户访问成正比，权重值越大，被转发的请求也就越多。可以根据服务器的配置和性能指定权重值大小，有效解决新旧服务器性能不均带来的请求分配问题。

  upstream  分组名称{
      server 127.0.0.1:8081 weight=1;
      server 127.0.0.1:8082 weight=2; 
   }

• IP哈希
    ip\_hash是静态调度算法，每个请求按客户端 IP 的 hash 结果分配，当新的请求到达时，先将其客户端IP通过哈希算法哈希出一个值，在随后的客户端请求中，客户 IP 的哈希值只要相同，就会被分配至同一台服务器，该调度算法可以解决动态网页的 session 共享问题，但有时会导致请求分配不均，即无法保证 1:1 的负载均衡，因为在国内大多数公司都是 NAT 上网模式，多个客户端会对应一个外部 IP，所以，这些客户端都会被分配到同一节点服务器，从而导致请求分配不均。

  upstream  分组名称{
      ip_hash;
      server 127.0.0.1:8081;
      server 127.0.0.1:8082; 
   }
  

• 最小连接数
    least\_conn是动态调度算法，会根据后端节点的连接数来决定分配情况，哪个机器连接数少就分发。

  upstream  分组名称{
      least_conn;
      server 127.0.0.1:8081;
      server 127.0.0.1:8082; 
   }
  

• 最短响应时间
    最短响应时间（fair）调度算法是动态调度算法，会根据后端节点服务器的响应时间来分配请求，响应时间端的优先分配。这是更加智能的调度算法。此种算法可以依据页面大小和加载时间长短只能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx 本身是不支持 fair 调度算法的，如果需要使用这种调度算法，必须下载 Nginx 的相关模块 upstream\_fair。

  upstream  分组名称{
      fair;
      server 127.0.0.1:8081;
      server 127.0.0.1:8082; 
   }

• url\_hash算法
    url\_hash算法是动态调度算法，按访问 URL 的 hash 结果来分配请求，使每个 URL 定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率命中率。（多用于后端服务器为缓存时的场景下）Nginx 本身是不支持 url\_hash的，如果需要使用这种调度算法，必须安装 Nginx 的hash 模块软件包。

  upstream  分组名称{
      fair;
      server 127.0.0.1:8081;
      server 127.0.0.1:8082; 
      hash $request_uri;
      hash_method crc32;
   }

负载均衡实例

下面是一个负载均衡的一个实例及参数的作用

upstream baidu_cluster {
    #可以是域名 或 ip+端口
    server x1.baidu.com;
    server x2.baidu.com;
    server x3.baidu.com;
    
    #下面的这些参数放在server地址的后面
    #如：server x3.baidu.com down;
    
    #down 不参与负载均衡
    #weight=5; 权重，越⾼分配越多 - 用于加权轮询
    #backup; 预留的备份服务器
    
    #下面这两参数配合使用
    #max_fails=number:设置允许请求代理服务器失败的次数，默认为1。
    #fail_timeout=time:设置经过max_fails失败后，服务暂停的时间，默认是10秒。

    
    #max_coons 用来设置代理服务器同时活动链接的最大数量，默认为0，表示不限制，
    #使用该配置可以根据后端服务器处理请求的并发量来进行设置，防止后端服务器被压垮。
    
    
    #根据服务器性能不同，配置适合的参数
    #server 106.xx.xx.xxx; 可以是ip
    #server 106.xx.xx.xxx:8080; 可以带端⼝号
    #server unix:/tmp/xxx; ⽀出socket⽅式
}
server {
  listen    80;
  server_name  localhost;

  location / {
        proxy_pass http://baidu_cluster;
  }
}

长连接优化

在 Nginx中，使用 upstream进行后端访问默认用的是短连接，但这会增加网络资源的消耗。可以通过配置长连接，来减少因建立连接产生的开销、提升性能。和长连接有关的配置示例如下：

keepalive_requests 1024;
keepalive_timeout 60;

upstream baidu_cluster {
    server x1.baidu.com;
    server x2.baidu.com;
    server x3.baidu.com;
    keepalive 100;
}
server {
  listen    80;
  server_name  localhost;

  location / {
        proxy_pass http://baidu_cluster;
  }
}

指令	作用	配置环境
keepalive\_requests	设置每个连接的最大请求次数，超过这个请求次数就会关闭这个连接。	http,server,location
keepalive\_timeout	长连接的超时时间	http,server,location
keepalive	worker进程和后端服务器之间的最大空闲连接数，如果空闲连接数超过这个数就会关闭至这个值。	upstream

nginx缓存

控制浏览器缓存

location /{
  # expires 10s;  //10秒后
  # expires @22h30m;  //每天22点30分
  # expires -1h;  //当前时间的提前一个小时过期
  # expires epoch;  //不使用缓存
  # expires off;  //使用浏览器默认缓存配置，在header看不到
  
  expires max;  //设置最大的过期时间  //2037年过期

}

反向代理缓存

proxy_cache_path /usr/local/nginx-1.22.0/upstream_cache 
keys_zone=eacape_cache:32m 
max_size=1g 
inactive=1m 
use_temp_path=off;

server {
  listen    8081;
  server_name  localhost;

  location / {
    root   /app/static/jk;
  }

    location ^~ /api {
        proxy_pass http://120.48.87.20:9000;
        proxy_cache     eacape_cache;
        proxy_cache_valid   200 304 8h;
        proxy_cache_valid   any 10m;
        proxy_cache_key $host$uri$is_args$args;
    }
}

• proxy_cache_path 指定缓存区路径 配置于http模块

  参数

  • levels缓存目录级最高3层，每层1-2两个字符表示，比如：1:1:2三层
  • keys_zone缓存块名称及缓存块大小keys\_zone=eacape\_cache:32m 缓存块为32m，超出32m后最早的被清除
  • max_size缓存区占用硬盘的最大值，超出后失效的将被清除
  • inactive 失效时间
  • use_temp_path是否开启临时路径
• proxy_cache 指定缓存块(针对sever或location模块配置)对应keys_zone中设置的值
• proxy_cache_valid 针对不同状态码的缓存时间

配置SSL证书

证书安装(腾讯云)

1. 请在 SSL 证书管理控制台 中选择您需要安装的证书并单击下载。

2. 在弹出的 “证书下载” 窗口中，服务器类型选择 Nginx，单击下载并解压缩 cloud.tencent.com 证书文件包到本地目录。

   解压缩后，可获得相关类型的证书文件。其中包含 cloud.tencent.com_nginx 文件夹：

   • 文件夹名称：cloud.tencent.com_nginx

   • 文件夹内容：

     • cloud.tencent.com_bundle.crt 证书文件
     • cloud.tencent.com_bundle.pem 证书文件（可忽略该文件）
     • cloud.tencent.com.key 私钥文件
     • cloud.tencent.com.csr CSR 文件是申请证书时由您上传或系统在线生成的，提供给 CA 机构。安装时可忽略该文件。
3. 使用 “WinSCP”（即本地与远程计算机间的复制文件工具）登录 Nginx 服务器。
4. 将已获取到的 cloud.tencent.com_bundle.crt 证书文件和 cloud.tencent.com.key 私钥文件从本地目录拷贝到 Nginx 服务器的 /usr/local/nginx/conf 目录（此处为 Nginx 默认安装目录，请根据实际情况操作）下。
5. 远程登录 Nginx 服务器。例如，使用 “PuTTY” 工具 登录。

6. 编辑 Nginx 根目录下的 conf/nginx.conf 文件。修改内容如下：

   说明：如找不到以下内容，可以手动添加。

   此操作可通过执行 vim /usr/local/nginx/conf/nginx.conf 命令行编辑该文件。由于版本问题，配置文件可能存在不同的写法。例如：Nginx 版本为 nginx/1.15.0 以上请使用 listen 443 ssl 代替 listen 443 和 ssl on。

   server {
   
     #SSL 默认访问端口号为 443
     listen 443 ssl; 
   
     #请填写绑定证书的域名
     server_name [cloud.tencent.com](http://cloud.tencent.com); 
   
     #请填写证书文件的相对路径或绝对路径
     ssl_certificate cloud.tencent.com_bundle.crt; 
   
     #请填写私钥文件的相对路径或绝对路径
     ssl_certificate_key cloud.tencent.com.key; 
     ssl_session_timeout 5m;
   
     #请按照以下协议配置
     ssl_protocols TLSv1.2 TLSv1.3; 
   
     #请按照以下套件配置，配置加密套件，写法遵循 openssl 标准。
     ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE; 
     ssl_prefer_server_ciphers on;
   
     location / {
       #网站主页路径。此路径仅供参考，具体请您按照实际目录操作。
       root html; 
       index  index.html index.htm;
     }
   }

7. 在 Nginx 根目录下，通过执行以下命令验证配置文件问题。

   ./sbin/nginx -t

   • 若存在，请您重新配置或者根据提示修改存在问题。
   • 若不存在，请执行 步骤8。

8. 在 Nginx 根目录下，通过执行以下命令重启 Nginx。

   ./sbin/nginx -s reload

9. 重启成功，即可使用 https://cloud.tencent.com 进行访问。

HTTP 自动跳转 HTTPS 的安全配置（可选）

如果您需要将 HTTP 请求自动重定向到 HTTPS。您可以通过以下操作设置：

1. 根据实际需求，选择以下配置方式：

   • 在页面中添加 JS 脚本。
   • 在后端程序中添加重定向。
   • 通过 Web 服务器实现跳转。

   • Nginx 支持 rewrite 功能。若您在编译时没有去掉 pcre，您可在 HTTP 的 server 中增加 return 301 https://$host$request_uri;，即可将默认80端口的请求重定向为 HTTPS。修改如下内容：

     说明：未添加注释的配置语句，您按照下述配置即可。由于版本问题，配置文件可能存在不同的写法。例如：Nginx 版本为 nginx/1.15.0 以上请使用 listen 443 ssl 代替 listen 443 和 ssl on。

     server {
     
       #SSL 默认访问端口号为 443
       listen 443 ssl;
     
       #请填写绑定证书的域名
       server_name [cloud.tencent.com](http://cloud.tencent.com); 
     
       #请填写证书文件的相对路径或绝对路径
       ssl_certificate  cloud.tencent.com_bundle.crt; 
     
       #请填写私钥文件的相对路径或绝对路径
       ssl_certificate_key cloud.tencent.com.key; 
       ssl_session_timeout 5m;
     
       #请按照以下套件配置，配置加密套件，写法遵循 openssl 标准。
       ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
     
       #请按照以下协议配置
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_prefer_server_ciphers on;
     
       location / {
         #网站主页路径。此路径仅供参考，具体请您按照实际目录操作。 
         root html;
         index index.html index.htm;
       }
     }
     
     server {
     
       listen 80;
     
       #请填写绑定证书的域名
       server_name [cloud.tencent.com](http://cloud.tencent.com); 
     
       #把http的域名请求转成https
       return 301 https://$host$request_uri; 
     
     }

2. 在 Nginx 根目录下，通过执行以下命令验证配置文件问题。

   ./sbin/nginx -t

   • 若存在，请您重新配置或者根据提示修改存在问题。
   • 若不存在，请执行 步骤3。

3. 在 Nginx 根目录下，通过执行以下命令重启 Nginx。

   ./sbin/nginx -s reload

4. 重启成功，即可使用 http://cloud.tencent.com 进行访问。

参考

腾讯云Nginx 服务器 SSL 证书安装部署

慕课实战课程