目录

  • 什么是反向代理

    • 正向代理
    • 反向代理

  • 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 nginxroot      2868  0.0  0.0  22292  1456 ?        Ss   Jul25   0:00 nginx: master process ./nginxnobody   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 nginxroot      2868  0.0  0.0  22292  1456 ?        Ss   Jul25   0:00 nginx: master process ./nginxnobody   23812  0.0  0.0  24376  1492 ?        S    20:49   0:00 nginx: worker processnobody   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 nginxroot      2868  0.0  0.0  22292  1456 ?        Ss   Jul25   0:00 nginx: master process ./nginxnobody   23812  0.0  0.0  24376  1492 ?        S    20:49   0:00 nginx: worker processnobody   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 = 2868pid        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.top82.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')#过程idPID="/usr/local/nginx-1.22.0/logs/nginx.pid"mv $LOG_PATH/access.log $LOG_PATH/access-$RECORD_TIME.logmv $LOG_PATH/error.log $LOG_PATH/error-$RECORD_TIME.logkill -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;    }}

两者比拟

ItemCORSNginx反向代理
代码配置--前端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.com82.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
keepaliveworker过程和后端服务器之间的最大闲暇连接数，如果闲暇连接数超过这个数就会敞开至这个值。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 证书装置部署

慕课实战课程