乐趣区

关于前端:前端工程师不可不知的Nginx知识

观感度:????????????????????

口味:虎皮鸡蛋

烹饪工夫:10min

本文已收录在前端食堂同名仓库 Github github.com/Geekhyt,欢迎光临食堂,如果感觉酒菜还算可口,赏个 Star 对食堂老板来说是莫大的激励。

历史背景

互联网的全球化导致了互联网的数据量快速增长,加上在本世纪初摩尔定律在单核 CPU 上的生效,CPU 朝着多核方向倒退,而 Apache 显然并没有做好多核架构的筹备,它的一个过程同一时间只能解决一个连贯,解决完一个申请后能力解决下一个,这无疑不能应答现在互联网上海量的用户。况且过程间切换的老本是十分高的。在这种背景下,Nginx 应运而生,能够轻松解决数百万、上千万的连贯。

Nginx 劣势

  • 高并发高性能
  • 可扩展性好
  • 高可靠性
  • 热部署
  • 开源许可证

Nginx 次要利用场景

  • 动态资源服务,通过本地文件系统提供服务
  • 反向代理服务、负载平衡
  • API 服务、权限管制,缩小应用服务器压力

Nginx 配置文件和目录

通过 rpm -ql nginx 能够查看 Nginx 装置的配置文件和目录。

如图是我在某某云上装置的最新稳固版本的 Nginx 的配置文件及目录。

  • /etc/nginx/nginx.conf 外围配置文件
  • /etc/nginx/conf.d/default.conf 默认 http 服务器配置文件
  • /etc/nginx/fastcgi_params fastcgi 配置
  • /etc/nginx/scgi_params scgi 配置
  • /etc/nginx/uwsgi_params uwsgi 配置
  • /etc/nginx/koi-utf
  • /etc/nginx/koi-win
  • /etc/nginx/win-utf 这三个文件是编码映射文件,因为作者是俄国人
  • /etc/nginx/mime.types 设置 HTTP 协定的 Content-Type 与扩展名对应关系的文件
  • /usr/lib/systemd/system/nginx-debug.service
  • /usr/lib/systemd/system/nginx.service
  • /etc/sysconfig/nginx
  • /etc/sysconfig/nginx-debug 这四个文件是用来配置守护过程治理的
  • /etc/nginx/modules 根本共享库和内核模块
  • /usr/share/doc/nginx-1.18.0 帮忙文档
  • /usr/share/doc/nginx-1.18.0/COPYRIGHT 版权申明
  • /usr/share/man/man8/nginx.8.gz 手册
  • /var/cache/nginx Nginx 的缓存目录
  • /var/log/nginx Nginx 的日志目录
  • /usr/sbin/nginx 可执行命令
  • /usr/sbin/nginx-debug 调试执行可执行命令

对于 Nginx 的常用命令以及配置文件语法很容易就能够搜到,本文不作赘述,上面从 Nginx 的性能以及理论场景登程看一看各个场景下 Nginx 能够提供给咱们哪些配置项。在此之前,咱们先来明确两个概念:

正向代理 Forward proxy

一句话解释正向代理,正向代理的对象是客户端,服务器端看不到真正的客户端。

resolver 8.8.8.8 # 谷歌的域名解析地址
server {
    location / {
      # 当客户端申请我的时候,我会把申请转发给它
      # $http_host 要拜访的主机名 $request_uri 申请门路
      proxy_pass http://$http_host$request_uri;
    }
}

反向代理 Reverse proxy

一句话解释反向代理,反向代理的对象是服务端,客户端看不到真正的服务端。

跨域

跨域是前端工程师都会面临的场景,跨域的解决方案有很多。不过要晓得在生产中,要么应用 CORS、要么应用 Nginx 反向代理来解决跨域。在 Nginx 的配置文件中进行如下配置即可:

server {
    listen   80;
    server_name   localhost; # 用户拜访 localhost,反向代理到 http://webcanteen.com
    location / {proxy_pass http://webcanteen.com}
}

Gzip

Gzip 是互联网上十分广泛的一种数据压缩格局,对于纯文本来说能够压缩到原大小的 40%,能够节俭大量的带宽。不过须要留神的是,启用 Gzip 所需的 HTTP 最低版本是 1.1。

location ~ .*\. (jpg|png|gif)$ {
    gzip off; #敞开压缩
    root /data/www/images;
}
location ~ .*\. (html|js|css)$ {
    gzip on; #启用压缩
    gzip_min_length 1k; # 超过 1K 的文件才压缩
    gzip_http_version 1.1; # 启用 gzip 压缩所需的 HTTP 最低版本
    gzip_comp_level 9; # 压缩级别,压缩比率越高,文件被压缩的体积越小
    gzip_types text/css application/javascript; # 进行压缩的文件类型
    root /data/www/html;
}

申请限度

对于大流量歹意的拜访,会造成带宽的节约,给服务器减少压力。往往对于同一 IP 的连接数以及并发数进行限度。

对于申请限度次要有两种类型:

  • limit_conn_module 连贯频率限度
  • limit_req_module 申请频率限度
# $binary_remote_addr 近程 IP 地址 zone 区域名称 10m 内存区域大小
limit_conn_zone $binary_remote_addr zone=coon_zone:10m;
server {
    # conn_zone 设置对应的共享内存区域 1 是限度的数量
    limit_conn conn_zone 1;
}
# $binary_remote_addr 近程 IP 地址 zone 区域名称 10m 内存区域大小 rate 为申请频率 1s 一次
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;
server {
    location / {
        # 设置对应的共享内存区域 burst 最大申请数阈值 nodelay 不心愿超过的申请被提早
        limit_req zone=req_zone burst=5 nodelay;
    }
}

访问控制

对于访问控制次要有两种类型:

  • -http_access_module 基于 IP 的访问控制
  • -http_auth_basic_module 基于用户的信赖登陆

(基于用户的信赖登陆不是很平安,本文不做配置介绍)

以下是基于 IP 的访问控制:

server {
    location ~ ^/index.html {
        # 匹配 index.html 页面 除了 127.0.0.1 以外都能够拜访
        deny 127.0.0.1;
        allow all;
    }
}

ab 命令

ab 命令全称为:Apache bench,是 Apache 自带的压力测试工具,也能够测试 Nginx、IIS 等其余 Web 服务器。

  • -n 总共的申请数
  • -c 并发的申请数
ab -n 1000 -c 5000 http://127.0.0.1/

防盗链

防盗链的原理就是依据申请头中 referer 失去网页起源,从而实现访问控制。这样能够避免网站资源被非法盗用,从而保障信息安全,缩小带宽损耗,加重服务器压力。

location ~ .*\.(jpg|png|gif)$ { # 匹配防盗链资源的文件类型
    # 通过 valid_referers 定义非法的地址白名单 $invalid_referer 不非法的返回 403  
    valid_referers none blocked 127.0.0.1;
    if ($invalid_referer) {return 403;}
}

负载平衡 Load Balance

当咱们的网站须要解决高并发、海量数据问题时,就须要应用负载平衡来调度服务器。将申请正当的散发到应用服务器集群中的一台台服务器上。

Nginx 能够为咱们提供负载平衡的能力,具体配置如下:

# upstream 指定后端服务器地址
# weight 设置权重
# server 中会将 http://webcanteen 的申请转发到 upstream 池中
upstream webcanteen {
    server 127.0.0.1:66 weight=10;
    server 127.0.0.1:77 weight=1;
    server 127.0.0.1:88 weight=1;
}
server {
    location / {proxy_pass http://webcanteen}
}

后端服务器状态

后端服务器反对以下的状态配置:

  • down:以后服务器不参加负载平衡
  • backup:当其余节点都无奈应用时的备用服务器
  • max_fails:容许申请失败的次数,若达到就会休眠
  • fail_timeout:通过 max_fails 次失败后,服务器的暂停工夫,默认为 10s
  • max_conns:限度每个服务器的最大接管连接数
upstream webcanteen {
    server 127.0.0.1:66 down;
    server 127.0.0.1:77 backup;
    server 127.0.0.1:88  max_fails=3 fail_timeout=10s;
    server 127.0.0.1:99 max_conns=1000;
}

调配形式

  • 轮询 (默认),每个申请依照工夫程序轮流调配到不同的后端服务器,如果某台后端服务器宕机,Nginx 轮询列表会主动将它去除掉。
  • weight(加权轮询),轮询的加强版,weight 和拜访几率成正比,次要用于后端服务器性能不均的场景。
  • ip_hash,每个申请依照拜访 IP 的 hash 后果调配,这样每个拜访能够固定拜访一个后端服务器。
  • url_hash,依照拜访 URL 的 hash 后果来调配申请,使得每个 URL 定向到同一个后端服务器上,次要利用于后端服务器为缓存时的场景。
  • 自定义 hash,基于任意关键字作为 hash key 实现 hash 算法的负载平衡
  • fair,依照后端服务器的响应工夫来调配申请,响应工夫短则优先调配。
退出移动版