关于nginx:一怒之下我把-Nginx-核心知识点扒了个底朝天

什么是Nginx？

Nginx是一个轻量级/高性能的反向代理Web服务器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 协定。他实现十分高效的反向代理、负载平衡，他能够解决2-3万并发连接数，官网监测能反对5万并发，当初中国应用nginx网站用户有很多，例如：新浪、网易、腾讯等

Nginx 有哪些长处？

跨平台、配置简略。
非阻塞、高并发连贯：解决 2-3 万并发连接数，官网监测能反对 5 万并发。
内存耗费小：开启 10 个 Nginx 才占 150M 内存。
老本低廉，且开源。
稳定性高，宕机的概率十分小。
内置的健康检查性能：如果有一个服务器宕机，会做一个健康检查，再发送的申请就不会发送到宕机的服务器了。从新将申请提交到其余的节点上

Nginx利用场景？

http服务器。Nginx是一个http服务能够独立提供http服务。能够做网页动态服务器。
虚拟主机。能够实现在一台服务器虚构出多个网站，例如集体网站应用的虚拟机。
反向代理，负载平衡。当网站的访问量达到肯定水平后，单台服务器不能满足用户的申请时，须要用多台服务器集群能够应用nginx做反向代理。并且多台服务器能够均匀分担负载，不会应为某台服务器负载高宕机而某台服务器闲置的状况。
nginz 中也能够配置平安治理、比方能够应用Nginx搭建API接口网关,对每个接口服务进行拦挡。

Nginx怎么解决申请的？

server {                                    # 第一个Server区块开始，示意一个独立的虚拟主机站点        listen       80；                          # 提供服务的端口，默认80        server_name  localhost;                    # 提供服务的域名主机名        location / {                               # 第一个location区块开始            root   html;                           # 站点的根目录，相当于Nginx的装置目录            index  index.html index.html;          # 默认的首页文件，多个用空格离开        }                                          # 第一个location区块后果

首先，Nginx 在启动时，会解析配置文件，失去须要监听的端口与 IP 地址，而后在 Nginx 的 Master 过程外面先初始化好这个监控的Socket(创立 S ocket，设置 addr、reuse 等选项，绑定到指定的 ip 地址端口，再 listen 监听)。
而后，再 fork(一个现有过程能够调用 fork 函数创立一个新过程。由 fork 创立的新过程被称为子过程 )出多个子过程进去。
之后，子过程会竞争 accept 新的连贯。此时，客户端就能够向 nginx 发动连贯了。当客户端与nginx进行三次握手，与 nginx 建设好一个连贯后。此时，某一个子过程会 accept 胜利，失去这个建设好的连贯的 Socket ，而后创立 nginx 对连贯的封装，即 ngx\_connection\_t 构造体。
接着，设置读写事件处理函数，并增加读写事件来与客户端进行数据的替换。
最初，Nginx 或客户端来被动关掉连贯，到此，一个连贯就死于非命了。

Nginx 是如何实现高并发的？

如果一个 server 采纳一个过程(或者线程)负责一个request的形式，那么过程数就是并发数。那么不言而喻的，就是会有很多过程在期待中。等什么？最多的应该是期待网络传输。

而 Nginx 的异步非阻塞工作形式正是利用了这点期待的工夫。在须要期待的时候，这些过程就闲暇进去待命了。因而体现为少数几个过程就解决了大量的并发问题。

Nginx是如何利用的呢，简略来说：同样的 4 个过程，如果采纳一个过程负责一个 request 的形式，那么，同时进来 4 个 request 之后，每个过程就负责其中一个，直至会话敞开。期间，如果有第 5 个request进来了。就无奈及时反馈了，因为 4 个过程都没干完活呢，因而，个别有个调度过程，每当新进来了一个 request ，就新开个过程来解决。

回忆下，BIO 是不是存在酱紫的问题？

Nginx 不这样，每进来一个 request ，会有一个 worker 过程去解决。但不是全程的解决，解决到什么水平呢？解决到可能产生阻塞的中央，比方向上游（后端）服务器转发 request ，并期待申请返回。那么，这个解决的 worker 不会这么傻等着，他会在发送完申请后，注册一个事件：“如果 upstream 返回了，通知我一声，我再接着干”。于是他就劳动去了。此时，如果再有 request 进来，他就能够很快再按这种形式解决。而一旦上游服务器返回了，就会触发这个事件，worker 才会来接手，这个 request 才会接着往下走。

这就是为什么说，Nginx 基于事件模型。

因为 web server 的工作性质决定了每个 request 的大部份生命都是在网络传输中，实际上破费在 server 机器上的工夫片不多。这是几个过程就解决高并发的机密所在。即：

webserver 刚好属于网络 IO 密集型利用，不算是计算密集型。

异步，非阻塞，应用 epoll ，和大量细节处的优化。也正是 Nginx 之所以然的技术基石。

什么是正向代理？

一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器获得内容，客户端向代理发送一个申请并指定指标(原始服务器)，而后代理向原始服务器转交申请并将取得的内容返回给客户端。

客户端能力应用正向代理。正向代理总结就一句话：代理端代理的是客户端。例如说：咱们应用的OpenVPN 等等。

什么是反向代理？

反向代理（Reverse Proxy）形式，是指以代理服务器来承受 Internet上的连贯申请，而后将申请，发给外部网络上的服务器并将从服务器上失去的后果返回给 Internet 上申请连贯的客户端，此时代理服务器对外就体现为一个反向代理服务器。

反向代理总结就一句话：代理端代理的是服务端。

反向代理服务器的长处是什么?

反向代理服务器能够暗藏源服务器的存在和特色。它充当互联网云和web服务器之间的中间层。这对于平安方面来说是很好的，特地是当您应用web托管服务时。

Nginx目录构造有哪些？

[root@localhost ~]# tree /usr/local/nginx/usr/local/nginx├── client_body_temp├── conf                             # Nginx所有配置文件的目录│   ├── fastcgi.conf                 # fastcgi相干参数的配置文件│   ├── fastcgi.conf.default         # fastcgi.conf的原始备份文件│   ├── fastcgi_params               # fastcgi的参数文件│   ├── fastcgi_params.default       │   ├── koi-utf│   ├── koi-win│   ├── mime.types                   # 媒体类型│   ├── mime.types.default│   ├── nginx.conf                   # Nginx主配置文件│   ├── nginx.conf.default│   ├── scgi_params                  # scgi相干参数文件│   ├── scgi_params.default  │   ├── uwsgi_params                 # uwsgi相干参数文件│   ├── uwsgi_params.default│   └── win-utf├── fastcgi_temp                     # fastcgi长期数据目录├── html                             # Nginx默认站点目录│   ├── 50x.html                     # 谬误页面优雅代替显示文件，例如当呈现502谬误时会调用此页面│   └── index.html                   # 默认的首页文件├── logs                             # Nginx日志目录│   ├── access.log                   # 拜访日志文件│   ├── error.log                    # 谬误日志文件│   └── nginx.pid                    # pid文件，Nginx过程启动后，会把所有过程的ID号写到此文件├── proxy_temp                       # 长期目录├── sbin                             # Nginx命令目录│   └── nginx                        # Nginx的启动命令├── scgi_temp                        # 长期目录└── uwsgi_temp                       # 长期目录

Nginx配置文件nginx.conf有哪些属性模块?

worker_processes  1；                                    # worker过程的数量events {                                                  # 事件区块开始    worker_connections  1024；                            # 每个worker过程反对的最大连接数}                                                        # 事件区块完结http {                                                   # HTTP区块开始    include       mime.types；                            # Nginx反对的媒体类型库文件    default_type  application/octet-stream；             # 默认的媒体类型    sendfile        on；                                   # 开启高效传输模式    keepalive_timeout  65；                               # 连贯超时    server {                                            # 第一个Server区块开始，示意一个独立的虚拟主机站点        listen       80；                                  # 提供服务的端口，默认80        server_name  localhost；                           # 提供服务的域名主机名        location / {                                    # 第一个location区块开始            root   html；                               # 站点的根目录，相当于Nginx的装置目录            index  index.html index.htm；                  # 默认的首页文件，多个用空格离开        }                                                  # 第一个location区块后果        error_page   500502503504  /50x.html；             # 呈现对应的http状态码时，应用50x.html回应客户        location = /50x.html {                          # location区块开始，拜访50x.html            root   html；                                  # 指定对应的站点目录为html        }    }      ......

cookie和session区别？

独特：

寄存用户信息。寄存的模式：key-value格局变量和变量内容键值对。

区别：

cookie
寄存在客户端浏览器
每个域名对应一个cookie，不能跨跃域名拜访其余cookie
用户能够查看或批改cookie
http响应报文外面给你浏览器设置
钥匙（用于关上浏览器上锁头）
session
寄存在服务器（文件，数据库，redis）
寄存敏感信息
锁头

为什么 Nginx 不应用多线程？

Apache: 创立多个过程或线程，而每个过程或线程都会为其调配 cpu 和内存（线程要比过程小的多，所以 worker 反对比 perfork 高的并发），并发过大会榨干服务器资源。

Nginx: 采纳单线程来异步非阻塞解决申请（管理员能够配置 Nginx 主过程的工作过程的数量）(epoll)，不会为每个申请调配 cpu 和内存资源，节俭了大量资源，同时也缩小了大量的 CPU 的上下文切换。所以才使得 Nginx 反对更高的并发。

nginx和apache的区别

轻量级，同样起web服务，比apache占用更少的内存和资源。

抗并发，nginx解决申请是异步非阻塞的，而apache则是阻塞性的，在高并发下nginx能放弃低资源，低消耗高性能。

高度模块化的设计，编写模块绝对简略。

最外围的区别在于apache是同步多过程模型，一个连贯对应一个过程，nginx是异步的，多个连贯能够对应一个过程。

什么是动静资源、动态资源拆散？

动静资源、动态资源拆散，是让动静网站里的动静网页依据肯定规定把不变的资源和常常变的资源辨别开来，动静资源做好了拆分当前咱们就能够依据动态资源的特点将其做缓存操作，这就是网站动态化解决的外围思路。

动静资源、动态资源拆散简略的概括是：动静文件与动态文件的拆散。

为什么要做动、静拆散？

在咱们的软件开发中，有些申请是须要后盾解决的（如：.jsp,.do 等等），有些申请是不须要通过后盾解决的（如：css、html、jpg、js 等等文件），这些不须要通过后盾解决的文件称为动态文件，否则动静文件。

因而咱们后盾解决疏忽动态文件。这会有人又说那我后盾疏忽动态文件不就完了吗？当然这是能够的，然而这样后盾的申请次数就显著增多了。在咱们对资源的响应速度有要求的时候，咱们应该应用这种动静拆散的策略去解决动、静拆散将网站动态资源（HTML，JavaScript，CSS，img等文件）与后盾利用离开部署，进步用户拜访动态代码的速度，升高对后盾利用拜访

这里咱们将动态资源放到 Nginx 中，动静资源转发到 Tomcat 服务器中去。

当然，因为当初七牛、阿里云等 CDN 服务曾经很成熟，支流的做法，是把动态资源缓存到 CDN 服务中，从而晋升访问速度。

相比本地的 Nginx 来说，CDN 服务器因为在国内有更多的节点，能够实现用户的就近拜访。并且，CDN 服务能够提供更大的带宽，不像咱们本人的应用服务，提供的带宽是无限的。

什么叫 CDN 服务？

CDN ，即内容散发网络。

其目标是，通过在现有的 Internet中减少一层新的网络架构，将网站的内容公布到最靠近用户的网络边缘，使用户可就近获得所需的内容，进步用户拜访网站的速度。

一般来说，因为当初 CDN 服务比拟公众，所以根本所有公司都会应用 CDN 服务。

Nginx怎么做的动静拆散？

只须要指定门路对应的目录。location/能够应用正则表达式匹配。并指定对应的硬盘中的目录。如下：（操作都是在Linux上）

location /image/ {        root   /usr/local/static/;        autoindex on;}

步骤：

# 创立目录mkdir /usr/local/static/image # 进入目录cd  /usr/local/static/image # 上传照片photo.jpg # 重启nginxsudo nginx -s reload

关上浏览器输出 server\_name/image/1.jpg 就能够拜访该动态图片了

Nginx负载平衡的算法怎么实现的?策略有哪些?

为了防止服务器解体，大家会通过负载平衡的形式来分担服务器压力。将对台服务器组成一个集群，当用户拜访时，先拜访到一个转发服务器，再由转发服务器将拜访散发到压力更小的服务器。

Nginx负载平衡实现的策略有以下五种：

1 .轮询(默认)

每个申请按工夫程序逐个调配到不同的后端服务器，如果后端某个服务器宕机，能主动剔除故障零碎。

upstream backserver {  server 192.168.0.12;  server 192.168.0.13; }

2. 权重 weight

weight的值越大，调配到的拜访概率越高，次要用于后端每台服务器性能不平衡的状况下。其次是为在主从的状况下设置不同的权值，达到正当无效的地利用主机资源。

# 权重越高，在被拜访的概率越大，如上例，别离是20%，80%。upstream backserver {  server 192.168.0.12 weight=2;  server 192.168.0.13 weight=8; }

3. ip\_hash( IP绑定)

每个申请按拜访IP的哈希后果调配，使来自同一个IP的访客固定拜访一台后端服务器，并且能够无效解决动静网页存在的session共享问题

upstream backserver {  ip_hash;  server 192.168.0.12:88;  server 192.168.0.13:80; }

4. fair(第三方插件)

必须装置upstream\_fair模块。

比照 weight、ip\_hash更加智能的负载平衡算法，fair算法能够依据页面大小和加载工夫长短智能地进行负载平衡，响应工夫短的优先调配。

# 哪个服务器的响应速度快，就将申请调配到那个服务器上。upstream backserver {  server server1;  server server2;  fair; }

5.url\_hash(第三方插件)

必须装置Nginx的hash软件包

按拜访url的hash后果来调配申请，使每个url定向到同一个后端服务器，能够进一步提高后端缓存服务器的效率。

upstream backserver {  server squid1:3128;  server squid2:3128;  hash $request_uri;  hash_method crc32; }

如何用Nginx解决前端跨域问题？

应用Nginx转发申请。把跨域的接口写成调本域的接口，而后将这些接口转发到真正的申请地址。

Nginx虚拟主机怎么配置?

1、基于域名的虚拟主机，通过域名来辨别虚拟主机——利用：内部网站
2、基于端口的虚拟主机，通过端口来辨别虚拟主机——利用：公司外部网站，内部网站的治理后盾
3、基于ip的虚拟主机。

基于虚拟主机配置域名

须要建设/data/www /data/bbs目录，windows本地hosts增加虚拟机ip地址对应的域名解析；对应域名网站目录下新增index.html文件；

# 当客户端拜访www.lijie.com,监听端口号为80,间接跳转到data/www目录下文件server {    listen       80;    server_name  www.lijie.com;    location / {        root   data/www;        index  index.html index.htm;    }} # 当客户端拜访www.lijie.com,监听端口号为80,间接跳转到data/bbs目录下文件 server {    listen       80;    server_name  bbs.lijie.com;    location / {        root   data/bbs;        index  index.html index.htm;    }}

基于端口的虚拟主机

应用端口来辨别，浏览器应用域名或ip地址:端口号拜访

# 当客户端拜访www.lijie.com,监听端口号为8080,间接跳转到data/www目录下文件 server {    listen       8080;    server_name  8080.lijie.com;    location / {        root   data/www;        index  index.html index.htm;    }}# 当客户端拜访www.lijie.com,监听端口号为80间接跳转到实在ip服务器地址 127.0.0.1:8080server {    listen       80;    server_name  www.lijie.com;    location / {         proxy_pass http://127.0.0.1:8080;        index  index.html index.htm;    }}

location的作用是什么？

location指令的作用是依据用户申请的URI来执行不同的利用，也就是依据用户申请的网站URL进行匹配，匹配胜利即进行相干的操作。location的语法能说进去吗？

留神：~ 代表本人输出的英文字母

Location正则案例

# 优先级1,准确匹配，根门路location =/ {    return 400;} # 优先级2,以某个字符串结尾,以av结尾的，优先匹配这里，辨别大小写location ^~ /av {   root /data/av/;} # 优先级3，辨别大小写的正则匹配，匹配/media*****门路location ~ /media {      alias /data/static/;} # 优先级4 ，不辨别大小写的正则匹配，所有的****.jpg|gif|png 都走这里location ~* .*\.(jpg|gif|png|js|css)$ {   root  /data/av/;} # 优先7，通用匹配location / {    return 403;}

限流怎么做的？

Nginx限流就是限度用户申请速度，避免服务器受不了

限流有3种

失常限度拜访频率（失常流量）
突发限度拜访频率（突发流量）
限度并发连接数

Nginx的限流都是基于漏桶流算法

实现三种限流算法

1、失常限度拜访频率（失常流量）：

限度一个用户发送的申请，我Nginx多久接管一个申请。

Nginx中应用ngx\_http\_limit\_req\_module模块来限度的拜访频率，限度的原理本质是基于漏桶算法原理来实现的。在nginx.conf配置文件中能够应用limit\_req\_zone命令及limit\_req命令限度单个IP的申请解决频率。

# 定义限流维度，一个用户一分钟一个申请进来，多余的全副漏掉limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m; # 绑定限流维度server{        location/seckill.html{        limit_req zone=zone;            proxy_pass http://lj_seckill;    }}

1r/s代表1秒一个申请，1r/m一分钟接管一个申请，如果Nginx这时还有他人的申请没有解决完，Nginx就会回绝解决该用户申请。

2、突发限度拜访频率（突发流量）：

限度一个用户发送的申请，我Nginx多久接管一个。

下面的配置肯定水平能够限度拜访频率，然而也存在着一个问题：如果突发流量超出申请被回绝解决，无奈解决流动时候的突发流量，这时候应该如何进一步解决呢？Nginx提供burst参数联合nodelay参数能够解决流量突发的问题，能够设置能解决的超过设置的申请数外能额定解决的申请数。咱们能够将之前的例子增加burst参数以及nodelay参数：

# 定义限流维度，一个用户一分钟一个申请进来，多余的全副漏掉limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m; # 绑定限流维度server{        location/seckill.html{        limit_req zone=zone burst=5 nodelay;        proxy_pass http://lj_seckill;    } }

为什么就多了一个 burst=5 nodelay; 呢，多了这个能够代表Nginx对于一个用户的申请会立刻解决前五个，多余的就慢慢来落，没有其余用户的申请我就解决你的，有其余的申请的话我Nginx就漏掉不承受你的申请

3、限度并发连接数

Nginx中的ngx\_http\_limit\_conn\_module模块提供了限度并发连接数的性能，能够应用limit\_conn\_zone指令以及limit\_conn执行进行配置。接下来咱们能够通过一个简略的例子来看下：

http {    limit_conn_zone $binary_remote_addr zone=myip:10m;    limit_conn_zone $server_name zone=myServerName:10m;} server {    location / {        limit_conn myip 10;        limit_conn myServerName 100;        rewrite / http://www.lijie.net permanent;    }}

下面配置了单个IP同时并发连贯数最多只能10个连贯，并且设置了整个虚构服务器同时最大并发数最多只能100个链接。当然，只有当申请的header被服务器解决后，虚构服务器的连接数才会计数。方才有提到过Nginx是基于漏桶算法原理实现的，实际上限流个别都是基于漏桶算法和令牌桶算法实现的。

漏桶算法

漏桶算法思路很简略，咱们把水比作是申请，漏桶比作是零碎解决能力极限，水先进入到漏桶里，漏桶里的水按肯定速率流出，当流出的速率小于流入的速率时，因为漏桶容量无限，后续进入的水间接溢出（拒绝请求），以此实现限流。

令牌桶算法

令牌桶算法的原理也比较简单，咱们能够了解成医院的挂号看病，只有拿到号当前才能够进行诊病。

零碎会保护一个令牌（token）桶，以一个恒定的速度往桶里放入令牌（token），这时如果有申请进来想要被解决，则须要先从桶里获取一个令牌（token），当桶里没有令牌（token）可取时，则该申请将被拒绝服务。令牌桶算法通过管制桶的容量、发放令牌的速率，来达到对申请的限度。

Nginx配置高可用性怎么配置？

当上游服务器(实在拜访服务器)，一旦呈现故障或者是没有及时相应的话，应该间接轮训到下一台服务器，保障服务器的高可用

Nginx配置代码：

server {        listen       80;        server_name  www.lijie.com;        location / {            ### 指定上游服务器负载平衡服务器            proxy_pass http://backServer;            ###nginx与上游服务器(实在拜访的服务器)超时工夫 后端服务器连贯的超时工夫_发动握手等待响应超时工夫            proxy_connect_timeout 1s;            ###nginx发送给上游服务器(实在拜访的服务器)超时工夫            proxy_send_timeout 1s;            ### nginx承受上游服务器(实在拜访的服务器)超时工夫            proxy_read_timeout 1s;            index  index.html index.htm;        }    }

Nginx怎么判断别IP不可拜访？

# 如果拜访的ip地址为192.168.9.115,则返回403if  ($remote_addr = 192.168.9.115) {       return 403;  }

在nginx中，如何应用未定义的服务器名称来阻止解决申请？

只需将申请删除的服务器就能够定义为：

服务器名被保留一个空字符串，他在没有主机头字段的状况下匹配申请，而一个非凡的nginx的非标准代码被返回，从而终止连贯。

怎么限度浏览器拜访？

## 不容许谷歌浏览器拜访 如果是谷歌浏览器返回500 if ($http_user_agent ~ Chrome) {       return 500;  }

Rewrite全局变量是什么？

$remote_addr        //获取客户端ip$binary_remote_addr //客户端ip（二进制)$remote_port        //客户端port，如：50472$remote_user        //曾经通过Auth Basic Module验证的用户名$host           //申请主机头字段，否则为服务器名称，如:blog.sakmon.com$request        //用户申请信息，如：GET ?a=1&b=2 HTTP/1.1$request_filename   //以后申请的文件的路径名，由root或alias和URI request组合而成，如：/2013/81.html$status         //申请的响应状态码,如:200$body_bytes_sent        // 响应时送出的body字节数数量。即便连贯中断，这个数据也是准确的,如：40$content_length        // 等于申请行的“Content_Length”的值$content_type          // 等于申请行的“Content_Type”的值$http_referer          // 援用地址$http_user_agent      // 客户端agent信息,如：Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36$args            //与$query_string雷同 等于当中URL的参数(GET)，如a=1&b=2$document_uri        //与$uri雷同  这个变量指以后的申请URI，不包含任何参数(见$args) 如:/2013/81.html$document_root       //针对以后申请的根门路设置值$hostname        //如：centos53.localdomain$http_cookie        //客户端cookie信息$cookie_COOKIE      //cookie COOKIE变量的值$is_args    //如果有$args参数，这个变量等于”?”，否则等于”"，空值，如?$limit_rate //这个变量能够限度连贯速率，0示意不限速$query_string       // 与$args雷同 等于当中URL的参数(GET)，如a=1&b=2$request_body      // 记录POST过去的数据信息$request_body_file  //客户端申请主体信息的长期文件名$request_method       //客户端申请的动作，通常为GET或POST,如：GET$request_uri          //蕴含申请参数的原始URI，不蕴含主机名，如：/2013/81.html?a=1&b=2$scheme            //HTTP办法（如http，https）,如：http$uri            //这个变量指以后的申请URI，不包含任何参数(见$args) 如:/2013/81.html$request_completion //如果申请完结，设置为OK. 当申请未完结或如果该申请不是申请链串的最初一个时，为空(Empty)，如：OK$server_protocol    //申请应用的协定，通常是HTTP/1.0或HTTP/1.1，如：HTTP/1.1$server_addr        //服务器IP地址，在实现一次零碎调用后能够确定这个值$server_name        //服务器名称，如：blog.sakmon.com$server_port        //申请达到服务器的端口号,如：80

Nginx 如何实现后端服务的健康检查？

形式一，利用 nginx 自带模块 ngx_http_proxy_module 和 ngx_http_upstream_module 对后端节点做健康检查。
形式二(举荐)，利用 nginx_upstream_check_module 模块对后端节点做健康检查。

Nginx 如何开启压缩？

开启nginx gzip压缩后，网页、css、js等动态资源的大小会大大的缩小，从而能够节约大量的带宽，进步传输效率，给用户快的体验。尽管会耗费cpu资源，然而为了给用户更好的体验是值得的。

开启的配置如下：

将以上配置放到nginx.conf的http{ … }节点中。

http {  # 开启gzip  gzip on;   # 启用gzip压缩的最小文件；小于设置值的文件将不会被压缩  gzip_min_length 1k;   # gzip 压缩级别 1-10   gzip_comp_level 2;   # 进行压缩的文件类型。   gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;   # 是否在http header中增加Vary: Accept-Encoding，倡议开启  gzip_vary on;}

保留并重启nginx，刷新页面（为了防止缓存，请强制刷新）就能看到成果了。以谷歌浏览器为例，通过F12看申请的响应头部：

咱们能够先来比照下，如果咱们没有开启zip压缩之前，咱们的对应的文件大小，如下所示：

当初咱们开启了gzip进行压缩后的文件的大小，能够看到如下所示：

并且咱们查看响应头会看到gzip这样的压缩，如下所示

gzip压缩前后成果比照：jquery原大小90kb，压缩后只有30kb。

gzip尽管好用，然而以下类型的资源不倡议启用。

1、图片类型

起因：图片如jpg、png自身就会有压缩，所以就算开启gzip后，压缩前和压缩后大小没有多大区别，所以开启了反而会白白的浪费资源。（Tips：能够试试将一张jpg图片压缩为zip，察看大小并没有多大的变动。尽管zip和gzip算法不一样，然而能够看出压缩图片的价值并不大）

2、大文件

起因：会耗费大量的cpu资源，且不肯定有显著的成果。

ngx\_http\_upstream\_module的作用是什么?

ngx\_http\_upstream\_module用于定义可通过fastcgi传递、proxy传递、uwsgi传递、memcached传递和scgi传递指令来援用的服务器组。

什么是C10K问题?

C10K问题是指无奈同时解决大量客户端(10,000)的网络套接字。

Nginx是否反对将申请压缩到上游?

您能够应用Nginx模块gunzip将申请压缩到上游。gunzip模块是一个过滤器，它能够对不反对“gzip”编码方法的客户机或服务器应用“内容编码:gzip”来解压缩响应。

如何在Nginx中取得以后的工夫?

要取得Nginx的以后工夫，必须应用SSI模块、$date_gmt和$date_local的变量。

Proxy_set_header THE-TIME $date_gmt;

用Nginx服务器解释-s的目标是什么?

用于运行Nginx -s参数的可执行文件。

如何在Nginx服务器上增加模块?

在编译过程中，必须抉择Nginx模块，因为Nginx不反对模块的运行工夫抉择。

生产中如何设置worker过程的数量呢？

在有多个cpu的状况下，能够设置多个worker，worker过程的数量能够设置到和cpu的外围数一样多，如果在单个cpu上起多个worker过程，那么操作系统会在多个worker之间进行调度，这种状况会升高零碎性能，如果只有一个cpu，那么只启动一个worker过程就能够了。

nginx状态码

499：服务端解决工夫过长，客户端被动敞开了连贯。

502：

(1).FastCGI过程是否曾经启动
(2).FastCGI worker过程数是否不够
(3).FastCGI执行工夫过长

fastcgi_connect_timeout 300;fastcgi_send_timeout 300;fastcgi_read_timeout 300;

(4).FastCGI Buffer不够，nginx和apache一样，有前端缓冲限度，能够调整缓冲参数

fastcgi_buffer_size 32k;fastcgi_buffers 8 32k;

(5). Proxy Buffer不够，如果你用了Proxying，调整

proxy_buffer_size 16k;proxy_buffers 4 16k;

(6).php脚本执行工夫过长

将php-fpm.conf的0s的0s改成一个工夫