美文网首页
写给前端的nginx简明教程

写给前端的nginx简明教程

作者: 前端dog君 | 来源:发表于2021-02-02 17:03 被阅读0次

    大家好,我是前端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,备注简书,期待您的光临。

    相关文章

      网友评论

          本文标题:写给前端的nginx简明教程

          本文链接:https://www.haomeiwen.com/subject/ujmwgktx.html