关于nginx-module: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;}
   }

两者比拟

配置防盗链

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;}
}

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 证书装置部署

慕课实战课程