【Nginx】静态资源部署（上）
文章目录
- Nginx静态资源概述
- Nginx静态资源的配置指令
-
- listen指令
- server_name指令
-
- 匹配执行顺序
- location指令
- 设置请求资源的目录root / alias
- index指令
- error_page指令
- 静态资源优化配置语法
- Nginx静态资源压缩
-
- Gzip模块配置指令
- Gzip压缩功能的实例配置
- Gzip和sendfile共存问题
-
- gzip_static指令
- 添加模块到Nginx的实现步骤
- gzip_static测试使用
Nginx静态资源概述
上网去搜索访问资源对于我们来说并不陌生，通过浏览器发送一个HTTP请求实现从客户端发送请求到服务器端获取所需要内容后并把内容回显展示在页面的一个过程。这个时候，我们所请求的内容就分为两种类型：
- 静态资源、
- 动态资源
静态资源即指在服务器端真实存在并且能直接拿来展示的一些文件，比如常见的html页面、css文件、js文件、图 片、视频等资源；
动态资源即指在服务器端真实存在但是要想获取需要经过一定的业务逻辑处理，根据不同的条件展示在页面不同这 一部分内容，比如说报表数据展示、根据当前登录用户展示相关具体数据等资源；
Nginx处理静态资源的内容，我们需要考虑下面这几个问题：
- 静态资源的配置指令
- 静态资源的配置优化
- 静态资源的压缩配置指令
- 静态资源的缓存处理
- 静态资源的访问控制，包括跨域问题和防盗链问题
Nginx静态资源的配置指令
listen指令
listen:用来配置监听端口。
| 语法 | listen address[:port] [default_server]…; listen port [default_server]…; |
|---|---|
| 默认值 | listen *:80 | *:8000 |
| 位置 | server |
listen的设置比较灵活，我们通过几个例子来把常用的设置方式熟悉下：
listen 127.0.0.1:8000; // listen localhost:8000 监听指定的IP和端口
listen 127.0.0.1; 监听指定IP的所有端口
listen 8000; 监听指定端口上的连接
listen *:8000; 监听指定端口上的连接
default_server属性是标识符，用来将此虚拟主机设置成默认主机。所谓的默认主机指的是如果没有匹配到对应的address:port，则会默认执行的。
如果不指定默认使用的是第一个server。
server{
listen 8080;
server_name 127.0.0.1;
location /{
root html;
index index.html;
}
}
server{
listen 8080 default_server;
server_name localhost;
default_type text/plain;
return 444 'This is a error request';
}
server_name指令
server_name：用来设置虚拟主机服务名称。
如果对listen和server_name理解的还不是很到位，推荐可以看看下面的文章：Nginx Server匹配原理及源码分析
127.0.0.1 、 localhost 、域名[www.baidu.com | www.jd.com]
| 语法 | server_name name …; name可以提供多个中间用空格分隔 |
|---|---|
| 默认值 | server_name “”; |
| 位置 | server |
关于server_name的配置方式有三种，分别是：
精确匹配
通配符匹配
正则表达式匹配
配置方式一：精确匹配
如：
server {
listen 80;
server_name www.itcast.cn www.itheima.cn;
...
}
补充小知识点:
hosts是一个没有扩展名的系统文件，可以用记事本等工具打开，其作用就是将一些常用的网址域名与其对应的IP地址建立一个关联“数据库”，当用户在浏览器中输入一个需要登录的网址时，系统会首先自动从hosts文件中寻找对应的IP地址，一旦找到，系统会立即打开对应网页，如果没有找到，则系统会再将网址提交DNS域名解析服务器进行IP地址的解析。
windows:C:\Windows\System32\drivers\etc
centos：/etc/hosts
因为域名是要收取一定的费用，所以我们可以使用修改hosts文件来制作一些虚拟域名来使用。需要修改 /etc/hosts文件来添加
vim /etc/hosts
127.0.0.1 www.itcast.cn
127.0.0.1 www.itheima.cn
配置方式二:使用通配符配置
server_name中支持通配符"*",但需要注意的是通配符不能出现在域名的中间，只能出现在首段或尾段，如：
server {
listen 80;
server_name *.itcast.cn www.itheima.*;
# www.itcast.cn abc.itcast.cn www.itheima.cn www.itheima.com
...
}
下面的配置就会报错
server {
listen 80;
server_name www.*.cn www.itheima.c*
...
}
配置三:使用正则表达式配置
server_name中可以使用正则表达式，并且使用~作为正则表达式字符串的开始标记。
常见的正则表达式
| 代码 | 说明 |
|---|---|
| ^ | 匹配搜索字符串开始位置 |
| $ | 匹配搜索字符串结束位置 |
| . | 匹配除换行符\n之外的任何单个字符 |
| \ | 转义字符，将下一个字符标记为特殊字符 |
| [xyz] | 字符集，与任意一个指定字符匹配 |
| [a-z] | 字符范围，匹配指定范围内的任何字符 |
| \w | 与以下任意字符匹配 A-Z a-z 0-9 和下划线,等效于[A-Za-z0-9_] |
| \d | 数字字符匹配，等效于[0-9] |
| {n} | 正好匹配n次 |
| {n,} | 至少匹配n次 |
| {n,m} | 匹配至少n次至多m次 |
| * | 零次或多次，等效于{0,} |
| + | 一次或多次，等效于{1,} |
| ? | 零次或一次，等效于{0,1} |
配置如下：
server{
listen 80;
server_name ~^www\.(\w+)\.com$;
default_type text/plain;
return 200 $1 $2 ..;
}
注意 ~后面不能加空格，括号可以取值
匹配执行顺序
由于server_name指令支持通配符和正则表达式，因此在包含多个虚拟主机的配置文件中，可能会出现一个名称被多个虚拟主机的server_name匹配成功，当遇到这种情况，当前的请求交给谁来处理呢？
server{
listen 80;
server_name ~^www\.\w+\.com$;
default_type text/plain;
return 200 'regex_success';
}
server{
listen 80;
server_name www.itheima.*;
default_type text/plain;
return 200 'wildcard_after_success';
}
server{
listen 80;
server_name *.itheima.com;
default_type text/plain;
return 200 'wildcard_before_success';
}
server{
listen 80;
server_name www.itheima.com;
default_type text/plain;
return 200 'exact_success';
}
server{
listen 80 default_server;
server_name _;
default_type text/plain;
return 444 'default_server not found server';
}
结论：
exact_success
wildcard_before_success
wildcard_after_success
regex_success
default_server not found server!!
No1:准确匹配server_name
No2:通配符在开始时匹配server_name成功
No3:通配符在结束时匹配server_name成功
No4:正则表达式匹配server_name成功
No5:被默认的default_server处理，如果没有指定默认找第一个server
location指令
server{
listen 80;
server_name localhost;
location / {
}
location /abc{
}
...
}
location:用来设置请求的URI
| 语法 | location [ = | ~ | ~* | ^~ |@ ] uri{…} |
|---|---|
| 默认值 | — |
| 位置 | server,location |
uri变量是待匹配的请求字符串，可以不包含正则表达式，也可以包含正则表达式
nginx服务器在搜索匹配location的时候，是先使用不包含正则表达式进行匹配，找到一个匹配度最高的一个，然后在通过包含正则表达式的进行匹配，如果能匹配到直接访问，匹配不到，就使用刚才匹配度最高的那个location来处理请求。
属性介绍:
不带符号，要求必须以指定模式开始
server {
listen 80;
server_name 127.0.0.1;
location /abc{
default_type text/plain;
return 200 "access success";
}
}
以下访问都是正确的
http://192.168.200.133/abc
http://192.168.200.133/abc?p1=TOM
http://192.168.200.133/abc/
http://192.168.200.133/abcdef
= : 用于不包含正则表达式的uri前，必须与指定的模式精确匹配
server {
listen 80;
server_name 127.0.0.1;
location =/abc{
default_type text/plain;
return 200 "access success";
}
}
可以匹配到
http://192.168.200.133/abc
http://192.168.200.133/abc?p1=TOM
匹配不到
http://192.168.200.133/abc/
http://192.168.200.133/abcdef
~： 用于表示当前uri中包含了正则表达式，并且区分大小写~*: 用于表示当前uri中包含了正则表达式，并且不区分大小写
换句话说，如果uri包含了正则表达式，需要用上述两个符合来标识
server {
listen 80;
server_name 127.0.0.1;
location ~^/abc\w${
default_type text/plain;
return 200 "access success";
}
}
server {
listen 80;
server_name 127.0.0.1;
location ~*^/abc\w${
default_type text/plain;
return 200 "access success";
}
}
^~: 用于不包含正则表达式的uri前，功能和不加符号的一致，唯一不同的是，如果模式匹配，那么就停止搜索其他模式了。
server {
listen 80;
server_name 127.0.0.1;
location ^~/abc{
default_type text/plain;
return 200 "access success";
}
}
设置请求资源的目录root / alias
root：设置请求的根目录
| 语法 | root path; |
|---|---|
| 默认值 | root html; |
| 位置 | http、server、location |
path为Nginx服务器接收到请求以后查找资源的根目录路径。
alias：用来更改location的URI
| 语法 | alias path; |
|---|---|
| 默认值 | — |
| 位置 | location |
path为修改后的根路径。
以上两个指令都可以来指定访问资源的路径，那么这两者之间的区别是什么?
举例说明：
（1）在/usr/local/nginx/html目录下创建一个 images目录,并在目录下放入一张图片mv.png图片
location /images {
root /usr/local/nginx/html;
}
访问图片的路径为:
http://192.168.200.133/images/mv.png
（2）如果把root改为alias
location /images {
alias /usr/local/nginx/html;
}
再次访问上述地址，页面会出现404的错误，查看错误日志会发现是因为地址不对，所以验证了：
root的处理结果是: root路径+location路径
/usr/local/nginx/html/images/mv.png
alias的处理结果是:使用alias路径替换location路径
/usr/local/nginx/html/mv.png
需要在alias后面路径改为
location /images {
alias /usr/local/nginx/html/images;
}
此时处理的结果就是：/usr/local/nginx/html/images/mv.png
（3）如果location路径是以/结尾,则alias也必须是以/结尾，root没有要求
将上述配置修改为
location /images/ {
alias /usr/local/nginx/html/images;
}
访问就会出问题，查看错误日志还是路径不对，所以需要把alias后面加上 /
小结：
root的处理结果是: root路径+location路径
alias的处理结果是:使用alias路径替换location路径
alias是一个目录别名的定义，root则是最上层目录的含义。
如果location路径是以/结尾,则alias也必须是以/结尾，root没有要求
index指令
index:设置网站的默认首页
| 语法 | index file …; |
|---|---|
| 默认值 | index index.html; |
| 位置 | http、server、location |
index后面可以跟多个值，如果访问的时候没有指定具体访问的资源，则会依次进行查找，找到第一个为止
举例说明：
location / {
root /var/www/;
index index.htm index.html;
}
访问该location的时候，可以通过 http://ip:port/，地址后面如果不添加任何内容，则默认依次访问index.html和index.htm，找到第一个来进行返回
当用户请求/ 地址时，Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和index.html 这两个文件。如果 index.htm 文件存在，则直接发起“内部跳转”到 /index.htm 这个新的地址；而如果 index.htm 文件不存在，则继续检查 index.html 是否存在。如果存在，同样发起“内部跳转”到/index.html；如果 index.html 文件仍然不存在，则放弃处理权给 content 阶段的下一个模块
error_page指令
error_page:设置网站的错误页面
| 语法 | error_page code … [=[response]] uri; |
|---|---|
| 默认值 | — |
| 位置 | http、server、location… |
当出现对应的响应code后，如何来处理。
举例说明：
（1）可以指定具体跳转的地址
server {
error_page 404 http://www.itcast.cn;
}
（2）可以指定重定向地址
server{
error_page 404 /50x.html;
error_page 500 502 503 504 /50x.html;
location =/50x.html{
root html;
}
}
也就是说发生500 502 503 504 404这些错误的时候会跳转到/50x.html这个页面，我们又使用location对其进行了匹配，其实最终的请求url是/html//50x.html
（3）使用location的@符合完成错误信息展示
server{
error_page 404 @jump_to_error;
location @jump_to_error {
default_type text/plain;
return 404 'Not Found Page...';
}
}
可选项=[response]的作用是用来将相应代码更改为另外一个
server{
error_page 404 =200 /50x.html;
location =/50x.html{
root html;
}
}
这样的话，当返回404找不到对应的资源的时候，在浏览器上可以看到，最终返回的状态码是200，这块需要注意下，编写error_page后面的内容，404后面需要加空格，200前面不能加空格
静态资源优化配置语法
Nginx对静态资源如何进行优化配置。这里从三个属性配置进行优化：
sendfile on;
tcp_nopush on;
tcp_nodeplay on;
（1）sendfile，用来开启高效的文件传输模式。
| 语法 | sendfile on |off; |
|---|---|
| 默认值 | sendfile off; |
| 位置 | http、server、location… |
我们一般是把sendfile配置在http块中
客户端请求静态资源的过程：客户端通过网络接口向服务端发送请求，操作系统将这些客户端的请求传递给服务器端应用程序，服务器端应用程序会处理这些请求，请求处理完成以后，操作系统还需要将处理得到的结果通过网络适配器传递回去。
如：
server {
listen 80;
server_name localhost；
location / {
root html;
index index.html;
}
}
在html目录下有一个welcome.html页面，访问地址
http://192.168.200.133/welcome.html
在没有使用sendfile时，客户端通过浏览器输入的地址将请求发给服务端。而服务端分为两个区域：
- 用户区：主要存放当前客户端所启动的程序
- 内核区：也就是操作系统的相关内容
我们的应用程序如果想要直接从我们的磁盘去读取文件，在我们当前一些流行的操作系统中是不会被允许的，因为这样非常的不安全。所以说应用程序想要去操作磁盘里面的内容的话，需要通过操作系统的系统调用去完成对应操作。那么具体怎么去做呢？
我们可以简单的说一下，其实这里就涉及到两个简单的操作，一个是读，一个是写。首先应用程序想要访问静态资源，他先要给操作系统(内核)发送一个指令read()去读取这个文件。我们的操作系统接收到这个指令之后就会从磁盘里去读取对应的静态资源。当读取到静态资源之后，这个静态资源会先拷贝到内核缓冲区(这里涉及到了第一次拷贝)。拷贝完之后，因为这个静态资源是应用程序所需要的，所以内核缓存区里的文件又会拷贝到应用程序的缓存区中去(这里涉及到了第二次拷贝)。应用程序拿到这个静态资源之后，他要通过网卡将这个数据发回给客户端，这里它又会发送一个write指令把资源写回到客户端中去。当这个write指令被操作完之后，我们应用缓存区里的数据就需要拷贝到socket缓冲区中去(因为都是通过http协议发送，http协议底层是通过tcp，tcp底层又是通过socket。这里又涉及到了第三次拷贝)。当我们把socket缓冲区中的数据通过网卡进行发送的时候(这里又涉及了第四次拷贝)
默认的处理流程涉及多次文件拷贝，效率相对来说比较低
而使用sendfile的情况下，我们的应用程序会直接调用sendfile函数( 操作系统的底层函数),在sendfile函数中会去指定从哪读取文件，把文件读出来之后交给哪个socket。所以在磁盘中拷贝对应的资源到内核缓存区之后，它会直接找到对应的socket进行相关的传递，然后socket再将资源拷贝网卡即可，最后网卡再去发送资源
这种方法少了两次拷贝，较少了用户态和内核态的进程切换，效率更高
（2）tcp_nopush：该指令必须在sendfile打开的状态下才会生效，主要是用来提升网络包的传输’效率’
| 语法 | tcp_nopush on|off; |
|---|---|
| 默认值 | tcp_nopush off; |
| 位置 | http、server、location |
（3）tcp_nodelay：该指令必须在keep-alive连接开启的情况下才生效，来提高网络包传输的’实时性’
| 语法 | tcp_nodelay on|off; |
|---|---|
| 默认值 | tcp_nodelay on; |
| 位置 | http、server、location |
我们可以通过上边的那张图去理解效率和实时性分别是什么。
我们先看图的上半部分。服务端把数据准备好之后，它需要把数据发送给服务端，而把数据发送到服务端分为两种方式：
- 方式一：有数据就发
- 方式二：先将数据缓存到缓存区，存满后再发
方式一的好处就是它的实时性是非常好的。但是我们知道服务端是通过tcp来建立连接发送数据的，而tcp在发送数据的时候会在你原本数据的基础上包装一些用来寻址的数据。也就是说你发送一个包过去里面可能只有1%是你的数据，99%可能都是用来寻址的其他数据。所以方式一虽然实时性高，但他的效率相对来说低一点。
而方式二的传输效率就高很多，但是实时性就很差
经过刚才的分析，“tcp_nopush"和”tcp_nodelay“看起来是"互斥的”，那么为什么要将这两个值都打开，这个大家需要知道的是在linux2.5.9以后的版本中两者是可以兼容的，三个指令都开启的好处是，sendfile可以开启高效的文件传输模式，tcp_nopush开启可以确保在发送到客户端之前数据包已经充分“填满”， 这大大减少了网络开销，并加快了文件发送的速度。 然后，当它到达最后一个可能因为没有“填满”而暂停的数据包时，Nginx会忽略tcp_nopush参数， 然后，tcp_nodelay强制套接字发送数据。由此可知，TCP_NOPUSH可以与TCP_NODELAY一起设置，它比单独配置TCP_NODELAY具有更强的性能。所以我们可以使用如下配置来优化Nginx静态资源的处理
sendfile on;
tcp_nopush on;
tcp_nodelay on;
Nginx静态资源压缩
经过上述内容的优化，我们再次思考一个问题，假如在满足上述优化的前提下，我们传送一个1M的数据和一个10M的数据那个效率高?，答案显而易见，传输内容小，速度就会快。那么问题又来了，同样的内容，如果把大小降下来，我们脑袋里面要蹦出一个词就是"压缩"，接下来，我们来学习Nginx的静态资源压缩模块。
在Nginx的配置文件中可以通过配置gzip来对静态资源进行压缩，相关的指令可以配置在http块、server块和location块中，Nginx可以通过
ngx_http_gzip_module模块
ngx_http_gzip_static_module模块
ngx_http_gunzip_module模块
对这些指令进行解析和处理。
接下来我们从以下内容进行学习
（1）Gzip各模块支持的配置指令
（2）Gzip压缩功能的配置
（3）Gzip和sendfile的冲突解决
（4）浏览器不支持Gzip的解决方案
Gzip模块配置指令
接下来所学习的指令都来自ngx_http_gzip_module模块，该模块会在nginx安装的时候内置到nginx的安装环境中，也就是说我们可以直接使用这些指令。
- gzip指令：该指令用于开启或者关闭gzip功能
| 语法 | gzip on|off; |
|---|---|
| 默认值 | gzip off; |
| 位置 | http、server、location… |
注意只有该指令为打开状态，下面的指令才有效果
http{
gzip on;
}
- gzip_types指令：该指令可以根据响应页的MIME类型选择性地开启Gzip压缩功能
| 语法 | gzip_types mime-type …; |
|---|---|
| 默认值 | gzip_types text/html; |
| 位置 | http、server、location |
所选择的值可以从mime.types文件中进行查找，也可以使用"*"代表所有。
http{
gzip_types application/javascript;
}
这里我们拿一个jquery.js文件来做一个实验：
然后我们进行gzip的相关配置：
- gzip_comp_level指令：该指令用于设置Gzip压缩程度，级别从1-9,1表示要是程度最低，要是效率最高，9刚好相反，压缩程度最高，但是效率最低最费时间。
| 语法 | gzip_comp_level level; |
|---|---|
| 默认值 | gzip_comp_level 1; |
| 位置 | http、server、location |
http{
gzip_comp_level 6;
}
同样还是上面的文件，默认的是1级压缩，大小为102kb。当我们使用6级压缩的时候文件大小是83.6kb，而当我们使用9级压缩的时候，文件大小是83.2kb。增加了三个压缩等级，但是文件只缩小了0.4kb，这说明并不是压缩等级越高越好，我们可以在效率和压缩比之间寻找到一个最优解。
- gzip_vary指令：该指令用于设置使用Gzip进行压缩发送是否携带
“Vary:Accept-Encoding”头域的响应头部。主要是告诉接收方，所发送的数据经过了Gzip压缩处理
| 语法 | gzip_vary on|off; |
|---|---|
| 默认值 | gzip_vary off; |
| 位置 | http、server、location |
- gzip_buffers指令：该指令用于处理请求压缩的缓冲区数量和大小。
| 语法 | gzip_buffers number size; |
|---|---|
| 默认值 | gzip_buffers 32 4k|16 8k; |
| 位置 | http、server、location |
其中number:指定Nginx服务器向系统申请缓存空间个数，size指的是每个缓存空间的大小。主要实现的是申请number个每个大小为size的内存空间。这个值的设定一般会和服务器的操作系统有关，所以建议此项不设置，使用默认值即可。
gzip_buffers 4 16K; #缓存空间大小
- gzip_disable指令：针对不同种类客户端发起的请求，可以选择性地开启和关闭Gzip功能。
| 语法 | gzip_disable regex …; |
|---|---|
| 默认值 | — |
| 位置 | http、server、location |
regex:根据客户端的浏览器标志(user-agent)来设置，支持使用正则表达式。指定的浏览器标志不使用Gzip.
该指令一般是用来排除一些明显不支持Gzip的浏览器。
gzip_disable "MSIE [1-6]\.";
- gzip_http_version指令：针对不同的HTTP协议版本，可以选择性地开启和关闭Gzip功能。
| 语法 | gzip_http_version 1.0|1.1; |
|---|---|
| 默认值 | gzip_http_version 1.1; |
| 位置 | http、server、location |
该指令是指定使用Gzip的HTTP最低版本，该指令一般采用默认值即可。
- gzip_min_length指令：该指令针对传输数据的大小，可以选择性地开启和关闭Gzip功能
| 语法 | gzip_min_length length; |
|---|---|
| 默认值 | gzip_min_length 20; |
| 位置 | http、server、location |
nignx计量大小的单位：bytes[字节] / kb[千字节] / M[兆]
例如: 1024 / 10k|K / 10m|M
Gzip压缩功能对大数据的压缩效果明显，但是如果要压缩的数据比较小的化，可能出现越压缩数据量越大的情况，因此我们需要根据响应内容的大小来决定是否使用Gzip功能，响应页面的大小可以通过头信息中的Content-Length来获取。但是如果使用了Chunk编码动态压缩，该指令将被忽略。建议设置为1K或以上。
- gzip_proxied指令：该指令设置是否对服务端返回的结果进行Gzip压缩。
| 语法 | gzip_proxied off|expired|no-cache| no-store|private|no_last_modified|no_etag|auth|any; |
|---|---|
| 默认值 | gzip_proxied off; |
| 位置 | http、server、location |
off - 关闭Nginx服务器对后台服务器返回结果的Gzip压缩
expired - 启用压缩，如果header头中包含 “Expires” 头信息
no-cache - 启用压缩，如果header头中包含 “Cache-Control:no-cache” 头信息
no-store - 启用压缩，如果header头中包含 “Cache-Control:no-store” 头信息
private - 启用压缩，如果header头中包含 “Cache-Control:private” 头信息
no_last_modified - 启用压缩,如果header头中不包含 “Last-Modified” 头信息
no_etag - 启用压缩 ,如果header头中不包含 “ETag” 头信息
auth - 启用压缩 , 如果header头中包含 “Authorization” 头信息
any - 无条件启用压缩
Gzip压缩功能的实例配置
gzip on; #开启gzip功能
gzip_types *; #压缩源文件类型,根据具体的访问资源类型设定
gzip_comp_level 6; #gzip压缩级别
gzip_min_length 1024; #进行压缩响应页面的最小长度,content-length
gzip_buffers 4 16K; #缓存空间大小
gzip_http_version 1.1; #指定压缩响应所需要的最低HTTP请求版本
gzip_vary on; #往头信息中添加压缩标识
gzip_disable "MSIE [1-6]\."; #对IE6以下的版本都不进行压缩
gzip_proxied off； #nginx作为反向代理压缩服务端返回数据的条件
这些配置在很多地方可能都会用到，所以我们可以将这些内容抽取到一个配置文件中，然后通过include指令把配置文件再次加载到nginx.conf配置文件中，方法使用。
nginx_gzip.conf
gzip on;
gzip_types *;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_buffers 4 16K;
gzip_http_version 1.1;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";
gzip_proxied off;
nginx.conf
include nginx_gzip.conf
Gzip和sendfile共存问题
前面在讲解sendfile的时候，提到过，开启sendfile以后，在读取磁盘上的静态资源文件的时候，可以减少拷贝的次数，可以不经过用户进程将静态文件通过网络设备发送出去，但是Gzip要想对资源压缩，是需要经过用户进程进行操作的。
所以如何解决两个设置的共存问题呢？
sendfile我们肯定是要用的，毕竟他能大幅度提高我们的效率。我们可以这么解决：既然我们没办法在访问的过程中进行压缩，那么我们能不能在访问之前就在服务器上对文件进行压缩？例如服务器提前将上图中的jquery.js压缩成jquery.js.gz，当我们再次访问jquery.js的时候，服务器在磁盘上找数据的时候就不去找jquery.js了，而是去找jquery.js.gz，将他返回到我们的浏览器之后，浏览器再去解压缩：
以上的操作可以使用ngx_http_gzip_static_module模块的gzip_static指令来实现。
gzip_static指令
gzip_static: 检查与访问资源同名的.gz文件时，response中以gzip相关的header返回.gz文件的内容。
说的直白一点就是查询与访问资源同名的gzip文件，
| 语法 | gzip_static on | off | always; |
|---|---|
| 默认值 | gzip_static off; |
| 位置 | http、server、location |
on和always的区别：
之前我们说过浏览器有不同的版本，有的版本低的是不支持Gzip的，所以如果是on，他就会去判断客户的浏览器是否支持，如果支持他才会发送这个压缩文件。如果不支持就不会发送。而always则代表 不管客户的浏览器是否支持都会以.gz文件进行发送。
添加上述命令后，会报一个错误，unknown directive "gzip_static"主要的原因是Nginx默认是没有添加ngx_http_gzip_static_module模块。如何来添加?
添加模块到Nginx的实现步骤
(1)查询当前Nginx的配置参数
nginx -V
(2)将nginx安装目录下sbin目录中的nginx二进制文件进行更名
cd /usr/local/nginx/sbin
mv nginx nginxold
(3) 进入Nginx的安装目录
cd /root/nginx/core/nginx-1.16.1
(4)执行make clean清空之前编译的内容
make clean
(5)使用configure来配置参数
./configure --with-http_gzip_static_module
(6)使用make命令进行编译
make
(7) 将objs目录下的nginx二进制执行文件移动到nginx安装目录下的sbin目录中
mv objs/nginx /usr/local/nginx/sbin
(8)执行更新命令
make upgrade
gzip_static测试使用
(1)直接访问http://192.168.200.133/jquery.js
(2)使用gzip命令进行压缩
cd /usr/local/nginx/html
gzip jquery.js
(3)再次访问http://192.168.200.133/jquery.js
