大家好，我是前端dog君，一名95后前端小兵。2019年毕业于北京化工大学，天津人，不知道有校友和老乡嘛？对前端的热爱，让我们在此相聚，希望这篇文章，能帮助到您，也同时希望能交到志同道合的小伙伴，共同发展，一起进步。我的微信号dm120225，备注简书，期待您的光临。

上一篇我们聊了聊docker的基本操作，链接：写给前端的docker简明教程。那么这一篇，我们就用docker安装nginx，聊一聊nginx的基本操作。

我们将会从以下几部分展开：nginx介绍、nginx原理、nginx安装、nginx配置、nginx应用，一步步的和大家一起学习nginx。

nginx介绍

定义

我们先来看下nginx的基本定义吧：

nginx是一个高性能的http和反向代理的web服务器，同时也提供了IMAP POP3 SMTP服务。

不过我们一般不使用nginx作为邮件服务器，最多的用途，是利用nginx高性能的http部署应用和反向代理做转发。说到这，我们看一下两个基本概念，正向代理和反向代理有什么区别。

正向代理和反向打理

实践中客户端无法直接跟服务端发起请求的时候，我们就需要代理服务。代理可以实现客户端与服务端之间的通信,我们的Nginx也可以实现相应的代理服务。

正向代理

客户端 <一> 代理 一>服务端

我们简单地打个租房的比方:

A(客户端)想租C(服务端)的房子,但是A(客户端)并不认识C(服务端)租不到。
B(代理)认识C(服务端)能租这个房子所以你找了B(代理)帮忙租到了这个房子。

这个过程中C(服务端)不认识A(客户端)只认识B(代理)
C(服务端)并不知道A(客户端)租了房子，只知道房子租给了B(代理)。

反向代理

客户端 一>代理 <一> 服务端

我们也用一个租房的例子:

A(客户端)想租一个房子,B(代理)就把这个房子租给了他。
这时候实际上C(服务端)才是房东。
B(代理)是中介把这个房子租给了A(客户端)。

这个过程中A(客户端)并不知道这个房子到底谁才是房东
他都有可能认为这个房子就是B(代理)的

由上的例子和图我们可以知道，正向代理和反向代理的区别在于代理的对象不一样,正向代理的代理对象是客户端,反向代理的代理对象是服务端。

优缺点

了解了正向代理和反向代理的区别后，我们来看下nginx的优缺点。

优点

高并发量

nginx采用了异步非阻塞的方式来处理请求，能够支持高达5w个并发连接数的响应。

内存消耗小

nginx采用的事件处理方式，与多线程相比，不需要创建线程，每个请求占用的内存很少，也没有上下文切换，事件处理非常轻量级。

简单稳定

配置简单（在conf文件中配置） 性能稳定（nginx采用了分阶段资源分配技术，使cpu内存占有率非常低，具有很高的稳定性）。

模块化程度高

nginx是高度模块化设计。

低成本

nginx是开源免费的。

内置的健康检查功能

如果 nginx代理后端的某台web服务宕机了，不会影响前端访问
节省带宽，会直接剔除掉。

支持热部署

启动特别容易，并且几乎可以做到724小时不间断运行*，即使运行数月也不需要重新启动。还能够在不间断服务的情况下，对软件版本进行升级。

缺点

适用范围小

nginx仅能支持http，https和Email协议，这样就在适用范围上面小些。

nginx不支持url来检测

对后端服务的健康检查，只支持通过端口来检测，不支持通过url来检测。

不支持session的直接保持

可通过ip_hash来解决。

nginx原理

现在我们对nginx已经有了一些初步认识了。下面我们一起来看下nginx的原理。

工作过程：
nginx在启动后，会有一个master进程和多个worker进程，master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后（异常情况下），会自动重新启动新的worker进程。而基本的网络事件，则是放在了worker进程中来处理。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其他进程的请求。worker进程的个数是可以设置的，一般我们会设置与机器的cpu核数一致（这里面的原因与nginx的进程模型以及事件处理模型分不开的）

nginx安装

我们了解完nginx是什么，有什么特点，基本原理后，下面就一起来使用docker来安装nginx，体验一下nginx。

我们编写的docker-compose.yml文件内容如下:

# docker-compose.yml

version: '3.1'
services:
  nginx:
    restart: always
    image: daocloud.io/library/nginx:1.7.8
    container_name: nginx
    ports:
      - 80:80
    volumes:
      - volumes:/etc/nginx
volumes:
  volumes: {}

我们在服务器上新建一个nginx目录将docker-compose.yml放进去。这里要给大家解释下数据卷为什么这么写。docker-compose根据这个配置文件去执行，执行到volumes时，会自动根据映射一个数据卷，数据卷名称为当前目录名+volumes，如下：

可以看到，我们在nginx目录下使用docker-compose启动nginx，自动创建了一个叫nginx_volumes的数据卷。默认nginx的安装目录在/etc/nginx，我们来看下nginx数据卷nginx_volumes都有什么内容。

可以看到nginx数据卷中有如上的文件。说明我们的数据卷也映射成功，接下来我们访问下nginx。

出现了如上界面，说明我们的nginx安装并启动成功。

nginx配置

安装好了nginx后，我们来看下nginx都可能会有什么配置。nginx的配置文件是nginx.conf，我们已经在数据卷中映射出来了，我们来看下都有什么内容。

我们可以看到，这里在最后又 include 了 /etc/nginx/conf.d目录下所有以conf结尾的文件，我们来看下都有什么内容。

我们打开default.conf

这里我们截取了部分内容。关于nginx的使用，核心可以说是去修改这个配置文件。我们来整理一下，针对这些配置文件做些介绍，来看下都是干什么用的。

整体介绍

nginx共分为三块：main（全局块）、events（块）、http块

main（全局块）

从配置文件开始到events块之间的内容，主要控制nginx子进程所属的用户和用户组，派生子进程数，错误日志位置和级别，pid位置等。

events块

events块主要影响nginx服务器与用户的网络连接，常用的设置包括是否开启对多work_process下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个work_process可以同时支持的最大连接数等。

http块

http块包括http-全局块、http-server块、upstream 块。可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。这是我们最重要的配置，以后我们的大部分配置工作是在http块下完成的。

http-server块

nginx中主机的配置块，可用于配置多个虚拟主机，每个server块就相当于一个虚拟主机。

upstream 块

配置负载均衡。

http-server-location 块

一个server块可以配置多个location块，这块的主要作用是基于nginx服务器接收到的请求路径，对虚拟主机名称之外的字符串进行匹配，对待定的请求进行处理。

配置详解

#定义Nginx运行的用户和用户组
user www www;
#
#nginx进程数,建议设置为等于CPU总核心数.
worker_processes 8;
#
#全局错误日志定义类型,[ debug | info | notice | warn | error | crit ]
error_log /var/log/nginx/error.log info;
#
#进程文件
pid /var/run/nginx.pid;
#
#一个nginx进程打开的最多文件描述符数目,理论值应该是最多打开文件数（系统的值ulimit -n）与nginx进程数相除,但是nginx分配请求并不均匀,所以建议与ulimit -n的值保持一致.
worker_rlimit_nofile 65535;
#
#工作模式与连接数上限
events
{
    #参考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本内核中的高性能网络I/O模型,如果跑在FreeBSD上面,就用kqueue模型.
    use epoll;
    #单个进程最大连接数（最大连接数=连接数*进程数）
    worker_connections 1024;    #最大连接数，默认为512
}
#
#设定http服务器
http
{
    include mime.types; #文件扩展名与文件类型映射表
    default_type application/octet-stream; #默认文件类型，文件流形式
    #charset utf-8; #默认编码
    server_names_hash_bucket_size 128; #服务器名字的hash表大小
    client_header_buffer_size 32k; #上传文件大小限制
    large_client_header_buffers 4 64k; #设定请求缓
    client_max_body_size 8m; #设定请求缓
      keepalive_timeout 65;  #连接超时时间，默认为75s，可以在http，server，location块。
    # 开启目录列表访问,合适下载服务器,默认关闭.
    autoindex on; # 显示目录
    autoindex_exact_size on; # 显示文件大小 默认为on,显示出文件的确切大小,单位是bytes 改为off后,显示出文件的大概大小,单位是kB或者MB或者GB
    autoindex_localtime on; # 显示文件时间 默认为off,显示的文件时间为GMT时间 改为on后,显示的文件时间为文件的服务器时间
    
    sendfile on; # 开启高效文件传输模式,sendfile指令指定nginx是否调用sendfile函数来输出文件,对于普通应用设为 on,如果用来进行下载等应用磁盘IO重负载应用,可设置为off,以平衡磁盘与网络I/O处理速度,降低系统的负载.注意：如果图片显示不正常把这个改成off.
    tcp_nopush on; # 防止网络阻塞
    tcp_nodelay on; # 防止网络阻塞
    
    
    # FastCGI相关参数是为了改善网站的性能：减少资源占用,提高访问速度.下面参数看字面意思都能理解.
    fastcgi_connect_timeout 300; ## 链接
    fastcgi_send_timeout 300;  ##读取 是指nginx进程向fastcgi进程发送request的整个过程的超时时间
    fastcgi_read_timeout 300;  ##发请求 是指fastcgi进程向nginx进程发送response的整个过程的超时时间
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
    
    # gzip模块设置
    gzip on; #开启gzip压缩输出
    gzip_min_length 1k; #允许压缩的页面的最小字节数,页面字节数从header偷得content-length中获取.默认是0,不管页面多大都进行压缩.建议设置成大于1k的字节数,小于1k可能会越压越大
    gzip_buffers 4 16k; #表示申请4个单位为16k的内存作为压缩结果流缓存,默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果
    gzip_http_version 1.1; #压缩版本（默认1.1,目前大部分浏览器已经支持gzip解压.前端如果是squid2.5请使用1.0）
    gzip_comp_level 2; #压缩等级.1压缩比最小,处理速度快.9压缩比最大,比较消耗cpu资源,处理速度最慢,但是因为压缩比最大,所以包最小,传输速度快
    gzip_types text/plain application/x-javascript text/css application/xml;
    #压缩类型,默认就已经包含text/html,所以下面就不用再写了,写上去也不会有问题,但是会有一个warn.
    gzip_vary on;#选项可以让前端的缓存服务器缓存经过gzip压缩的页面.例如:用squid缓存经过nginx压缩的数据
    
    #开启限制IP连接数的时候需要使用
    #limit_zone crawler $binary_remote_addr 10m;
    
    #虚拟主机的配置
    server
    {
        # 监听端口
        listen 80;
        # 域名可以有多个,用空格隔开
        server_name 127.0.0.1;
        # HTTP 自动跳转 HTTPS
        rewrite ^(.*) https://www.baidu.com;
        deny 127.0.0.1;  #拒绝的ip
        allow 172.18.5.54; #允许的ip 
    }
    upstream myserver {   
      server 127.0.0.1:8080;
      server 192.168.24.189:8080 backup;  #热备
    }
    server
    {
        # 监听端口 HTTPS
        listen 443 ssl;
        server_name https://www.baidu.com;
        root /data/www/;
        # 配置域名证书
        ssl_certificate      C:\WebServer\Certs\certificate.crt;
        ssl_certificate_key  C:\WebServer\Certs\private.key;
        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;
        ssl_protocols SSLv2 SSLv3 TLSv1;
        ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers  on;
    
        index index.html index.htm index.php;
        
        location ~ .*\.(php|php5)?$
        {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
            include fastcgi.conf;
        }
        
        # 配置地址拦截转发，解决跨域验证问题
        location /oauth/{
            proxy_pass https://localhost:13580/oauth/;
            proxy_set_header HOST $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        
        # 图片缓存时间设置
        location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
            expires 10d;
        }
        
        # JS和CSS缓存时间设置
        location ~ .*\.(js|css)?$ {
            expires 1h;
        }

        # 日志格式设定
        log_format access '$server_name $remote_addr -$remote_user [$time_local] "$request"'
                  '$status $uptream_status $body_bytes_sent "$http_referer"'
                  '"$http_user_agent" "$http_x_forwarded_for" '
                  '$ssl_protocol $ssl_cipher $upstream_addr $request_time $upstream_response_time';
       # 定义本虚拟主机的访问日志
        access_log /var/log/nginx/access.log access;
        
        # 设定查看Nginx状态的地址.StubStatus模块能够获取Nginx自上次启动以来的工作状态，此模块非核心模块，需要在Nginx编译安装时手工指定才能使用
        location /NginxStatus {
            stub_status on;
            access_log on;
            auth_basic "NginxStatus";
            auth_basic_user_file conf/htpasswd;
            #htpasswd文件的内容可以用apache提供的htpasswd工具来产生.
        }
    }
}

内置变量

$remote_addr:客户端的IP地址
$remote_user:客户端用户名，用于记录浏览者进行身份验证时提供的名称，如果没有登录，则为空
$time_local 访问的时间和时区   如21/Sep/ 2016:12:21:15 + 0800  时间信息最后的+0800表示服务器所处时区位于UTC之后的8小时
$request 请求的URI和HTTP协议  如GET/HTTP/1.1
$status 记录请求返回的HTTP状态码  如 200（成功）
$body_bytes_sent 发送给客户端的文件主体内容大小 如899
$http_referer   来路URL地址
$http_user_agent   客户端浏览器信息
$http_x_forwarded for   客户端ip地址列表（包括中间经过的代理）

以上的nginx配置是比较全的了，里面涉及到的像work_process 指令，$remote_addr等内置变量和其他配置，下面附上了大佬们的参考链接，大家可以详细的进行查看。下面我们针对location块的匹配做一个简单的介绍。

location匹配

介绍

location指令是http模块当中最核心的一项配置，根据预先定义的URL匹配规则来接收用户发送的请求，根据匹配结果，将请求转发到后台服务器、非法的请求直接拒绝并返回403、404、500错误处理等。

语法

nginx官方文档给出location语法如下：

location [=|~|~*|^~] uri { … }
其中，方括号中的四种标识符是可选项，用来改变请求字符串和uri的匹配方式。uri是待匹配的请求字符串，可以是不包含正则的字符串，这种模式被称为“标准的uri"；也可以包含正则，这种模式被称为"正则uri"，如下：

location ~ .*\.(php|php5)?$ { }

uri匹配模式

location指令分为两种匹配模式：

• 普通字符串匹配：以=开头或开头无引导字符（～）的规则

• 正则匹配：以～或～开头表示正则匹配，~表示正则不区分大小写

= 精确匹配；用于标准uri前，要求请求字符串和uri严格匹配。如果匹配成功，就停止匹配，立即执行该location里面的请求。
~ 正则匹配；用于正则uri前，表示uri里面包含正则，并且区分大小写。
~* 正则匹配；用于正则uri前，表示uri里面包含正则，不区分大小写。
^~ 非正则匹配；用于标准uri前，nginx服务器匹配到前缀最多的uri后就结束，该模式匹配成功后，不会使用正则匹配。
无 普通匹配（最长字符匹配）；与location顺序无关，是按照匹配的长短来取匹配结果。若完全匹配，就停止匹配。

uri 匹配规则

当nginx收到一个请求后，会截取请求的URI部份，去搜索所有location指令中定义的URI匹配模式。在server模块中可以定义多个location指令来匹配不同的url请求，多个不同location配置的URI匹配模式，总体的匹配原则是：先匹配普通字符串模式（普通匹配，匹配到会暂存，继续搜索正则匹配），再匹配正则模式(正则模式匹配到，即为最终匹配)。只识别URI部份，例如请求为：/test/abc/user.do?name=xxxx

一个请求过来后，Nginx匹配这个请求的流程如下：

• 先查找是否有=开头的精确匹配
  如：location = /test/abc/user.do { … }

• 再查找普通匹配
  以 最大前缀 为原则，如有以下两个location，则会匹配后一项
  location /test/ { … } location /test/abc { … }

匹配到一个普通格式后，搜索并未结束，而是暂存当前匹配的结果，并继续搜索正则匹配模式

所有正则匹配模式location中找到第一个匹配项后，就以此项为最终匹配结果

所以正则匹配项匹配规则，受定义的前后顺序影响，但普通匹配模式不会

如果未找到正则匹配项，则以普通匹配中缓存的结果为最终匹配结果

如果一个匹配都没搜索到，则返回404

综上所述：location匹配优先级为：

（精确匹配 = ）> (最长字符串匹配，但完全匹配 /xxx/yyy/zzz) >（非正则匹配 ^~）>（正则匹配 ~ ~*）>（最长字符串匹配，不完全匹配 /abc）>（location通配 / /abc）

nginx应用

下面呢，我们一起来看下，nginx在我们工作中都会有什么用途。

web服务器

我们先来看下nginx定义

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

nginx是一个web服务器，实际上，当我们启动了nginx之后，访问80端口，我们已经可以看到一个界面，这就是nginx作为web服务器的一个应用。下面我们就一起来部署一个web应用。

• 新增nginx配置文件location模块，配置如下：

• 在数据卷目录下，新增web1项目

  
  

现在我们已经有了web1项目

• 重启nginx

• 浏览器访问 /web1

这就是nginx作为web服务器最简单的例子。客户端通过浏览器访问，nginx截取/web1字符串拿到location中按照匹配原则进行匹配，匹配到了之后返回相应的资源。

反向代理

前面我们已经讲过了什么是反向代理。但是我们为什么需要反向代理呢？实际上，在我们的前端，处理跨域请求的时候，通常情况下会直接使用webpack-dev-server为我们提供的proxy，也就是我们常说的CORS去处理跨域请求。实际上，如果我们在自己本机上搭建一台nginx作为一个代理服务器，帮助我们将请求转发出去，这也是一种选择。

反向代理实际上是 客户端访问应用，nginx作为代理服务器转发请求到真正的服务器，真正的服务器拿到数据后给到nginx，nginx返回给客户端。下面我们就使用tomcat作为后端服务器，nginx作为反向代理。一起来看下吧。

• 准备好tomcat的docker-compose.yml文件

• 启动tomcat1 docker-compose up -d

• 输入网址，能正常访问

  
  

• 配置nginx，新增location和upstream如下：

注意：upstream和server块同级

• 保存配置，重启nginx
• 浏览器访问/tomcat1

反向代理生效。

负载均衡

那么什么是负载均衡？我们为什么需要负载均衡？

传统的架构是，客户端直接访问服务端，服务端直接客户端返回数据。但是随着用户量的增大，访问量的增大，一台服务器无法承受原本的压力，于是扩充了多台服务器，就是服务器集群。那么我们的用户访问，比如说http://www.baidu.com，我们访问百度，只需要记住一个地址就可以了，而背后可能有成千上万台服务器，我们不可能去记住所有服务器的ip地址和端口号，我们只想记住一个域名就可以直接访问应用。nginx就是来帮助我们解决这个问题的。

用户发送请求，访问的是nginx。nginx对用户发送过来的请求进行转发，那么按照什么策略进行转发，能保证服务器的利用比较充分，用户能够流畅的进行访问，并且不会宕机，这就是我们说的nginx负载均衡。nginx为我们提供了多种负载均衡策略，包括但不限于 轮询、权重、ip_hash、fair、least_conn等，这里我们介绍比较常用的前三种。

为了演示负载均衡，首先我们准备两个tomcat服务，这里我们直接看下效果。

访问8081端口

访问8082端口

到此呢，我们的两个tomcat服务和nginx已经准备好，下面介绍下nginx的负载均衡策略。

轮询

将客户端发起的请求，平均的分配给每一台服务器。

这是nginx默认的负载均衡策略，我们在nginx中配置下

• 进入nginx的数据卷

  
  

• 对conf.d 的default.conf进行配置

• 配置结束后重启nginx

我们可以看到，当客户端发送请求到/tomcat1时，nginx进行转发，转发到两个服务，8081和8082的tomcat服务，nginx默认采用的是轮询策略，我们用浏览器访问测试下，可以发现，页面在tomcat1服务和tomcat2服务中跳来跳去，并且是每个服务交替访问，这就是nginx负载均衡的轮询策略。

权重

将客户端的请求，根据服务器的权重值不同，分配不同的数量。

我们的服务器，在不能保证配置相同的情况下，有的服务器配置相对较低，有的服务器配置相对较高，那么我们就让配置较高的服务器多处理请求，配置较低的服务器少处理请求，这就用到了权重策略。我们在nginx中配置感受下：

• 配置权重策略

  
  

我们只需要将upstream中的服务后添加weight参数即可。途中配置代表如果来了5个请求，81端口的tomcat服务处理4次，82端口的tomcat服务处理1次。

• 重启nginx

我们用浏览器访问测试下，可以看到,连续访问5次，有4次是被tomcat1服务处理的，有1次是被tomcat2处理的，这就是nginx负载均衡的权重策略。

ip_hash

基于发起请求的客户端的ip地址不同，始终会将请求发送到指定的服务器上。

上面的两种方法可能存在一个问题，就是我们如果不在一台服务器去处理请求的话，用户第一次访问tomcat1服务，第二次访问tomcat2服务，那就造成了session丢失的问题。那么为什么会这样呢？我们简单的理解下cookie session鉴权策略
用户输入账号密码，向服务端发送请求，服务端校验通过后给服务端种cookie，cookie中存有session_id字段，服务端存储session作为唯一标识，下次用户再访问从cookie中读取session_id，和服务端存储的session进行对比，如果能找到，那么给客户端返回数据。

那么如果我们第一次访问tomcat1服务，第二次访问tomcat2服务，假设session存储在tomcat1服务中，那么自然tomcat2中拿不到用户的session，这就造成了session丢失的问题。那么怎么解决这个问题呢？

1.我们可以弄一台session服务器专门存储session，为多个服务器共享，这样问题就解决了，但是久而久之，session服务器数据越来越大，或许还需要一个session集群。

2.基于token的鉴权策略。用户登录成功后，我们给用户签发一个token，用户每次请求都带来这个token，服务端进行解析，能正确解析出来数据，给客户端返回数据。解析的过程是在程序计算出来的，也就是说，这个算法，每台服务器都存在，可以解决这个问题。

3.基于nginx的ip_hash策略。这就是我们这里来介绍的，nginx负载均衡中的ip_hash策略可以解决问题。用户来访问，nginx对其ip进行hash运算，存储起来，指定一个服务器为用户处理请求。那么下次用户再来访问时，就会一直访问这台服务器。

以上是对cookie session token的简单了解，详细解读可以看dog君的另一篇文章：一文读懂cookie session token

下面我们就对nginx的ip_hash策略进行配置，nginx配置如下：

实际上，我们只需要在upstream块中添加ip_hash即可，重启nginx，我们来测试下：可以看到，一直访问的都是tomcat1服务。那么为什么不是tomcat2服务呢？因为tomcat1服务的权重比较大，第一次访问的是tomcat1服务，又因为有ip_hash策略，所以后面访问的一直都是tomcat1服务了。

动静分离

为了加快网站的解析速度，可以把动态页面和静态页面由不同的服务器解析，加快解析速度，降低原来单个服务器的压力

比如说，我们的图片，js文件，css文件，html页面，都可以放在nginx中，nginx的高性能http来帮助我们处理这些请求。像jsp等动态页面，可以放在tomcat中来去处理。

这就是nginx的动静分离，巧妙地运用了nginx可以作为web服务器的特点。

一些计算

nginx能建立的最大连接数 worker_connections * worker_processes
HTTP请求本地资源支持最大并发数量 worker_connections * worker_processes
HTTP作为反向代理支持最大并发数 worker_connections * worker_processes / 2

接上面的动静分离，这里给出一个nginx并发能力的计算公式：
worker_connections * worker_processes / 4 | 2 = nginx最终的并发能力

动态资源除以4，静态资源除以2，因为动态资源，nginx是作为反向代理存在的，客户端发送请求给nginx，nginx发送请求给服务端，服务端返回响应给nginx，nginx返回响应给客户端，一次请求，建立了4次连接。

那么我们如果动静分离的话，静态资源交给nginx来处理，客户端发送请求给nginx，nginx直接返回给客户端，那么只建立了两次请求。所以说，动静分离，会提高nginx的并发能力。

总结

那么到此为止呢，我们的nginx已经介绍完毕了。对于nginx，以上内容只是皮毛，强大的nginx考虑到了我们多种应用场景，太多的配置供我们选择，比如说upstream 中的backup，设置备用机，作为代理服务器可以修改请求头和响应头等等，备用机可以作为我们进行版本升级发布时进行用户无感知热更新，那么作为代理服务器，大家想到他可以做什么呢？这个问题留给大家来思考啦！最后，给大家附上一个彩蛋吧，我们在vue项目中如何使用nginx进行无感知发版，也是某大神的良心之作
vue项目部署的最佳实践,实现无感知发版

参考链接：
16张图入门nginx
nginx配置文件详解
nginx配置中location匹配规则详解

我是前端dog君，一名95后前端小兵。对前端的热爱，让我们在此相聚，希望这篇文章，能帮助到您，也同时希望能交到志同道合的小伙伴，共同发展，一起进步。我的微信号dm120225，备注简书，期待您的光临。