Nginx之资源压缩，大文件传输，缓冲区，缓冲机制，IP黑白名单

作者: 上善若泪 | 来源:发表于2023-02-03 14:35 被阅读0次

1 Nginx

1.1 资源压缩

资源压缩建立在动静分离的基础之上，如果一个静态资源的Size越小，那么自然传输速度会更快，同时也会更节省带宽，因此在部署项目时，也可以通过Nginx对于静态资源实现压缩传输，一方面可以节省带宽资源，第二方面也可以加快响应速度并提升系统整体吞吐。

在Nginx也提供了三个支持资源压缩的模块ngx_http_gzip_module、ngx_http_gzip_static_module、ngx_http_gunzip_module，其中ngx_http_gzip_module属于内置模块，代表着可以直接使用该模块下的一些压缩指令，后续的资源压缩操作都基于该模块，先来看看压缩配置的一些参数/指令：

参数项	描述	参数值
gzip	开启或关闭压缩机制	on/off
gzip_types	根据文件类型选择性开启压缩机制	image/png、text/css...
gzip_comp_level	用于设置压缩级别，级别越高越耗时	1~9（越高压缩效果越好）
gzip_vary	设置是否携带Vary:Accept-Encoding头域的响应头部	on/off
gzip_buffers	设置处理压缩请求的缓冲区数量和大小	数量大小，如16 8k
gzip_disable	针对不同客户端的请求来设置是否开启压缩	如 .Chrome.，指令一般是用来排除一些明显不支持Gzip的浏览器。
gzip_http_version	指定压缩响应所需要的最低HTTP请求版本	如1.1
gzip_min_length	设置触发压缩文件最低大小	如512k
gzip_proxied	对于后端服务器的响应结果是否开启压缩	off、expired/no-cache...

了解了Nginx中的基本压缩配置后，接下来可以在Nginx中简单配置一下：

http{
    # 开启压缩机制
    gzip on;
    # 指定会被压缩的文件类型(也可自己配置其他类型)
    gzip_types text/plain application/javascript text/css application/xml text/javascript image/jpeg image/gif image/png;
    # 设置压缩级别，越高资源消耗越大，但压缩效果越好
    gzip_comp_level 5;
    # 在头部中添加Vary: Accept-Encoding（建议开启）
    gzip_vary on;
    # 处理压缩请求的缓冲区数量和大小
    gzip_buffers 16 8k;
    # 对于不支持压缩功能的客户端请求不开启压缩机制
    gzip_disable "MSIE [1-6]\."; # 低版本的IE浏览器不支持压缩
    # 设置压缩响应所支持的HTTP最低版本
    gzip_http_version 1.1;
    # 设置触发压缩的最小阈值
    gzip_min_length 2k;
    # 关闭对后端服务器的响应结果进行压缩
    gzip_proxied off;
}

在上述的压缩配置中，最后一个gzip_proxied选项，可以根据系统的实际情况决定，总共存在多种选项：

off：关闭Nginx对后台服务器的响应结果进行压缩。
expired：如果响应头中包含Expires信息，则开启压缩。
no-cache：如果响应头中包含Cache-Control:no-cache信息，则开启压缩。
no-store：如果响应头中包含Cache-Control:no-store信息，则开启压缩。
private：如果响应头中包含Cache-Control:private信息，则开启压缩。
no_last_modified：如果响应头中不包含Last-Modified信息，则开启压缩。
no_etag：如果响应头中不包含ETag信息，则开启压缩。
auth：如果响应头中包含Authorization信息，则开启压缩。
any：无条件对后端的响应结果开启压缩机制。

注意：

对于图片、视频类型的数据，会默认开启压缩机制，因此一般无需再次开启压缩
对于.js文件而言，需要指定压缩类型为application/javascript，而并非text/javascript、application/x-javascript

1.2 大文件传输配置

在某些业务场景中需要传输一些大文件，但大文件传输时往往都会会出现一些Bug，比如文件超出限制、文件传输过程中请求超时等，那么此时就可以在Nginx稍微做一些配置，先来了解一些关于大文件传输时可能会用的配置项：

配置项	描述
client_max_body_size	设置请求允许的最大体积
client_header_timeout	等待客户端发送一个请求头的超时时间
client_body_timeout	设置读取请求体的超时时间
proxy_read_timeout	设置请求被后端服务器读取时，Nginx等待的最长时间
proxy_send_timeout	设置后端向Nginx返回响应时的超时时间

在传输大文件时，client_max_body_size、client_header_timeout、proxy_read_timeout、proxy_send_timeout这四个参数值都可以根据自己项目的实际情况来配置。

上述配置仅是作为代理层需要配置的，因为最终客户端传输文件还是直接与后端进行交互，这里只是把作为网关层的Nginx配置调高一点，调到能够容纳大文件传输的程度。当然，Nginx中也可以作为文件服务器使用，但需要用到一个专门的第三方模块nginx-upload-module，如果项目中文件上传的作用处不多，那么建议可以通过Nginx搭建，毕竟可以节省一台文件服务器资源。但如若文件上传/下载较为频繁，那么还是建议额外搭建文件服务器，并将上传/下载功能交由后端处理

1.3 Nginx缓冲

1.3.1 Nginx缓冲区

先来思考一个问题，接入Nginx的项目一般请求流程为：客户端→Nginx→服务端，在这个过程中存在两个连接：客户端→Nginx、Nginx→服务端，那么两个不同的连接速度不一致，就会影响用户的体验（比如浏览器的加载速度跟不上服务端的响应速度）

其实也就类似电脑的内存跟不上CPU速度，所以对于用户造成的体验感极差，因此在CPU设计时都会加入三级高速缓冲区，用于缓解CPU和内存速率不一致的矛盾。在Nginx也同样存在缓冲区的机制，主要目的就在于：用来解决两个连接之间速度不匹配造成的问题 ，有了缓冲后，Nginx代理可暂存后端的响应，然后按需供给数据给客户端。使用缓冲可以减少即时传输带来的带宽消耗。

先来看看一些关于缓冲区的配置项：

proxy_buffering：是否启用缓冲机制，默认为on关闭状态。
client_body_buffer_size：设置缓冲客户端请求数据的内存大小。
proxy_buffers：为每个请求/连接设置缓冲区的数量和大小，默认4 4k/8k。
proxy_buffer_size：设置用于存储响应头的缓冲区大小。
proxy_busy_buffers_size：在后端数据没有完全接收完成时，Nginx可以将busy状态的缓冲返回给客户端，该参数用来设置busy状态的buffer具体有多大，默认为proxy_buffer_size*2。
proxy_temp_path：当内存缓冲区存满时，可以将数据临时存放到磁盘，该参数是设置存储缓冲数据的目录。
语法：proxy_temp_path path;，其中path是临时目录的路径
proxy_temp_file_write_size：设置每次写数据到临时文件的大小限制。
proxy_max_temp_file_size：设置临时的缓冲目录中允许存储的最大容量。
非缓冲参数项：
- proxy_connect_timeout：设置与后端服务器建立连接时的超时时间。
- proxy_read_timeout：设置从后端服务器读取响应数据的超时时间。
- proxy_send_timeout：设置向后端服务器传输请求数据的超时时间。

具体的nginx.conf配置如下：

http{  
    proxy_connect_timeout 10;  
    proxy_read_timeout 120;  
    proxy_send_timeout 10;  
    proxy_buffering on;  
    client_body_buffer_size 512k;  
    proxy_buffers 4 64k;  
    proxy_buffer_size 16k;  
    proxy_busy_buffers_size 128k;  
    proxy_temp_file_write_size 128k;  
    proxy_temp_path /soft/nginx/temp_buffer;  
}

上述的缓冲区参数，是基于每个请求分配的空间，而并不是所有请求的共享空间。当然，具体的参数值还需要根据业务去决定，要综合考虑机器的内存以及每个请求的平均数据大小。

1.3.2 Nginx缓存机制

对于性能优化而言，缓存是一种能够大幅度提升性能的方案，因此几乎可以在各处都能看见缓存，如客户端缓存、代理缓存、服务器缓存等等，Nginx的缓存则属于代理缓存的一种。对于整个系统而言，加入缓存带来的优势额外明显：

减少了再次向后端或文件服务器请求资源的带宽消耗
降低了下游服务器的访问压力，提升系统整体吞吐
缩短了响应时间，提升了加载速度，打开页面的速度更快

那么在Nginx中，又该如何配置代理缓存呢？先来看看缓存相关的配置项：

proxy_cache_path：代理缓存的路径。
语法：
proxy_cache_path
path [levels=levels] [use_temp_path=on|off]
keys_zone=name:size
[inactive=time] [max_size=size]
[manager_files=number] [manager_sleep=time]
[manager_threshold=time] [loader_files=number]
[loader_sleep=time] [loader_threshold=time]
[purger=on|off] [purger_files=number]
[purger_sleep=time] [purger_threshold=time];
解释一下每个参数项的含义：
- path：缓存的路径地址。
- levels：缓存存储的层次结构，最多允许三层目录。
- use_temp_path：是否使用临时目录。
- keys_zone：指定一个共享内存空间来存储热点Key(1M可存储8000个Key)
- inactive：设置缓存多长时间未被访问后删除（默认是十分钟）。
- max_size：允许缓存的最大存储空间，超出后会基于LRU算法移除缓存，Nginx会创建一个Cache manager的进程移除数据，也可以通过purge方式
- manager_files：manager进程每次移除缓存文件数量的上限。
- manager_sleep：manager进程每次移除缓存文件的时间上限。
- manager_threshold：manager进程每次移除缓存后的间隔时间。
- loader_files：重启Nginx载入缓存时，每次加载的个数，默认100。
- loader_sleep：每次载入时，允许的最大时间上限，默认200ms。
- loader_threshold：一次载入后，停顿的时间间隔，默认50ms。
- purger：是否开启purge方式移除数据。
- purger_files：每次移除缓存文件时的数量。
- purger_sleep：每次移除时，允许消耗的最大时间。
- purger_threshold：每次移除完成后，停顿的间隔时间。
proxy_cache：开启或关闭代理缓存，开启时需要指定一个共享内存区域。
语法：proxy_cache zone | off;：zone为内存区域的名称，即上面中keys_zone设置的名称。
proxy_cache_key：定义如何生成缓存的键。
语法：proxy_cache_key string;
string为生成Key的规则，如$scheme$proxy_host$request_uri
proxy_cache_valid：缓存生效的状态码与过期时间。
语法：proxy_cache_valid [code ...] time;
code为状态码，time为有效时间，可以根据状态码设置不同的缓存时间。
例如：proxy_cache_valid 200 302 30m;
proxy_cache_min_uses：设置资源被请求多少次后被缓存。
语法：proxy_cache_min_uses number;
number为次数，默认为1。
proxy_cache_use_stale：当后端出现异常时，是否允许Nginx返回缓存作为响应。
语法：proxy_cache_use_stale error;
error为错误类型，可配置timeout|invalid_header|updating|http_500...
proxy_cache_lock：对于相同的请求，是否开启锁机制，只允许一个请求发往后端。
语法：proxy_cache_lock on | off;
proxy_cache_lock_timeout：配置锁超时机制，超出规定时间后会释放请求。
proxy_cache_lock_timeout time;
proxy_cache_methods：设置对于那些HTTP方法开启缓存。
语法：proxy_cache_methods method;，method为请求方法类型，如GET、HEAD等。
proxy_no_cache：定义不存储缓存的条件，符合时不会保存。
语法：proxy_no_cache string...;
string为条件，例如$cookie_nocache $arg_nocache $arg_comment;
proxy_cache_bypass：定义不读取缓存的条件，符合时不会从缓存中读取。
语法：proxy_cache_bypass string...;和上面proxy_no_cache的配置方法类似。
add_header：往响应头中添加字段信息。
语法：add_header fieldName fieldValue;
$upstream_cache_status：记录了缓存是否命中的信息，存在多种情况：
- MISS：请求未命中缓存。
- HIT：请求命中缓存。
- EXPIRED：请求命中缓存但缓存已过期。
- STALE：请求命中了陈旧缓存。
- REVALIDDATED：Nginx验证陈旧缓存依然有效。
- UPDATING：命中的缓存内容陈旧，但正在更新缓存。
- BYPASS：响应结果是从原始服务器获取的。

对于Nginx中的缓存配置项大概了解后，接着来配置一下Nginx代理缓存：

http{  
    # 设置缓存的目录，并且内存中缓存区名为hot_cache，大小为128m，  
    # 三天未被访问过的缓存自动清楚，磁盘中缓存的最大容量为2GB。
    proxy_cache_path /soft/nginx/cache levels=1:2 keys_zone=hot_cache:128m inactive=3d max_size=2g;  
      
    server{  
        location / {  
            # 使用名为nginx_cache的缓存空间  
            proxy_cache hot_cache;  
            # 对于200、206、304、301、302状态码的数据缓存1天  
            proxy_cache_valid 200 206 304 301 302 1d;  
            # 对于其他状态的数据缓存30分钟  
            proxy_cache_valid any 30m;  
            # 定义生成缓存键的规则（请求的url+参数作为key）  
            proxy_cache_key $host$uri$is_args$args;  
            # 资源至少被重复访问三次后再加入缓存  
            proxy_cache_min_uses 3;  
            # 出现重复请求时，只让一个去后端读数据，其他的从缓存中读取  
            proxy_cache_lock on;  
            # 上面的锁超时时间为3s，超过3s未获取数据，其他请求直接去后端  
            proxy_cache_lock_timeout 3s;  
            # 对于请求参数或cookie中声明了不缓存的数据，不再加入缓存  
            proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;  
            # 在响应头中添加一个缓存是否命中的状态（便于调试）  
            add_header Cache-status $upstream_cache_status;  
        }  
    }  
}

1.3.3 缓存清理

当缓存过多时，如果不及时清理会导致磁盘空间被“吃光”，因此我们需要一套完善的缓存清理机制去删除缓存，在之前的proxy_cache_path参数中有purger相关的选项，开启后可以帮我们自动清理缓存，但遗憾的是：purger系列参数只有商业版的NginxPlus才能使用，需要付费才可使用

不过可以通过强大的第三方模块ngx_cache_purge来替代，先来安装一下该插件：

首先去到Nginx的安装目录下，创建一个cache_purge目录：
mkdir cache_purge && cd cache_purge
通过wget指令从github上拉取安装包的压缩文件并解压：
拉取：wget https://github.com/FRiCKLE/ngx_cache_purge/archive/2.3.tar.gz
解压：tar -xvzf 2.3.tar.gz
再次去到之前Nginx的解压目录下：
cd /soft/nginx/nginx1.21.6
重新构建一次Nginx，通过--add-module的指令添加刚刚的第三方模块：
./configure --prefix=/soft/nginx/ --add-module=/soft/nginx/cache_purge/ngx_cache_purge-2.3/
重新根据刚刚构建的Nginx，再次编译一下，但切记不要make install：
执行编译命令：make
删除之前Nginx的启动文件，不放心的也可以移动到其他位置：
rm -rf /soft/nginx/sbin/nginx
从生成的objs目录中，重新复制一个Nginx的启动文件到原来的位置：
cp objs/nginx /soft/nginx/sbin/nginx

至此，第三方缓存清除模块ngx_cache_purge就安装完成了，接下来稍微修改一下nginx.conf配置，再添加一条location规则：

location ~ /purge(/.*) {  
  # 配置可以执行清除操作的IP（线上可以配置成内网机器）  
  # allow 127.0.0.1; # 代表本机  
  allow all; # 代表允许任意IP清除缓存  
  proxy_cache_purge $host$1$is_args$args;  
}

然后再重启Nginx，接下来即可通过http://xxx/purge/xx的方式清除缓存。

1.4 Nginx实现IP黑白名单

有时候往往有些需求，可能某些接口只能开放给对应的合作商，或者购买/接入API的合作伙伴，那么此时就需要实现类似于IP白名单的功能。而有时候有些恶意攻击者或爬虫程序，被识别后需要禁止其再次访问网站，因此也需要实现IP黑名单。那么这些功能无需交由后端实现，可直接在Nginx中处理。

Nginx做黑白名单机制，主要是通过allow、deny配置项来实现：

允许指定的IP访问，可以用于实现白名单
allow xxx.xxx.xxx.xxx;  

禁止指定的IP访问，可以用于实现黑名单
deny xxx.xxx.xxx.xxx;

要同时屏蔽/开放多个IP访问时，如果所有IP全部写在nginx.conf文件中定然是不显示的，这种方式比较冗余，那么可以新建两个文件BlocksIP.conf、WhiteIP.conf：


# --------黑名单：BlocksIP.conf---------  
deny 192.177.12.222; # 屏蔽192.177.12.222访问  
deny 192.177.44.201; # 屏蔽192.177.44.201访问  
deny 127.0.0.0/8; # 屏蔽127.0.0.1到127.255.255.254网段中的所有IP访问  
  
# --------白名单：WhiteIP.conf---------  
allow 192.177.12.222; # 允许192.177.12.222访问  
allow 192.177.44.201; # 允许192.177.44.201访问  
allow 127.45.0.0/16; # 允许127.45.0.1到127.45.255.254网段中的所有IP访问  
deny all; # 除开上述IP外，其他IP全部禁止访问

分别将要禁止/开放的IP添加到对应的文件后，可以再将这两个文件在nginx.conf中导入：

http{  
    # 屏蔽该文件中的所有IP  
    include /soft/nginx/IP/BlocksIP.conf;   
 server{  
    location xxx {  
        # 某一系列接口只开放给白名单中的IP  
        include /soft/nginx/IP/blockip.conf;   
    }  
 }  
}

对于文件具体在哪儿导入，这个也并非随意的，如果要整站屏蔽/开放就在http中导入，如果只需要一个域名下屏蔽/开放就在sever中导入，如果只需要针对于某一系列接口屏蔽/开放IP，那么就在location中导入。

当然，上述只是最简单的IP黑/白名单实现方式，同时也可以通过ngx_http_geo_module、ngx_http_geo_module第三方库去实现（这种方式可以按地区、国家进行屏蔽，并且提供了IP库）

1.5 Nginx跨域配置

跨域问题在之前的单体架构开发中，其实是比较少见的问题，除非是需要接入第三方SDK时，才需要处理此问题。但随着现在前后端分离、分布式架构的流行，跨域问题也成为了每个Java开发必须要懂得解决的一个问题。

1.5.1 跨域问题产生的原因

产生跨域问题的主要原因就在于 同源策略，为了保证用户信息安全，防止恶意网站窃取数据，同源策略是必须的，否则cookie可以共享。由于http无状态协议通常会借助cookie来实现有状态的信息记录，例如用户的身份/密码等，因此一旦cookie被共享，那么会导致用户的身份信息被盗取。

同源策略主要是指三点相同，协议+域名+端口相同的两个请求，则可以被看做是同源的，但如果其中任意一点存在不同，则代表是两个不同源的请求，同源策略会限制了不同源之间的资源交互。

1.5.2 Nginx解决跨域问题

弄明白了跨域问题的产生原因，接下来看看Nginx中又该如何解决跨域呢？其实比较简单，在nginx.conf中稍微添加一点配置即可：

location / {  
    # 允许跨域的请求，可以自定义变量$http_origin，*表示所有  
    add_header 'Access-Control-Allow-Origin' *;  
    # 允许携带cookie请求  
    add_header 'Access-Control-Allow-Credentials' 'true';  
    # 允许跨域请求的方法：GET,POST,OPTIONS,PUT  
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT';  
    # 允许请求时携带的头部信息，*表示所有  
    add_header 'Access-Control-Allow-Headers' *;  
    # 允许发送按段获取资源的请求  
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';  
    # 一定要有！！！否则Post请求无法进行跨域！
    # 在发送Post跨域请求前，会以Options方式发送预检请求，服务器接受时才会正式请求  
    if ($request_method = 'OPTIONS') {  
        add_header 'Access-Control-Max-Age' 1728000;  
        add_header 'Content-Type' 'text/plain; charset=utf-8';  
        add_header 'Content-Length' 0;  
        # 对于Options方式的请求返回204，表示接受跨域请求  
        return 204;  
    }  
}

在nginx.conf文件加上如上配置后，跨域请求即可生效了。

1.6 Nginx防盗链设计

首先了解一下何谓盗链：盗链即是指外部网站引入当前网站的资源对外展示 ，来举个简单的例子理解：

好比壁纸网站X站、Y站，X站是一点点去购买版权、签约作者的方式，从而积累了海量的壁纸素材，但Y站由于资金等各方面的原因，就直接通过<img src="X站/xxx.jpg" />这种方式照搬了X站的所有壁纸资源，继而提供给用户下载。
那么如果我们自己是这个X站的Boss，心中必然不爽，那么此时又该如何屏蔽这类问题呢？那么接下来要叙说的防盗链 登场了

Nginx的防盗链机制实现，跟一个头部字段：Referer有关，该字段主要描述了当前请求是从哪儿发出的，那么在Nginx中就可获取该值，然后判断是否为本站的资源引用请求，如果不是则不允许访问。Nginx中存在一个配置项为valid_referers，正好可以满足前面的需求，语法如下：
valid_referers none | blocked | server_names | string ...;

none：表示接受没有Referer字段的HTTP请求访问。
blocked：表示允许http://或https//以外的请求访问。
server_names：资源的白名单，这里可以指定允许访问的域名。
string：可自定义字符串，支配通配符、正则表达式写法。

简单了解语法后，接下来的实现如下：

# 在动静分离的location中开启防盗链机制  
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){  
    # 最后面的值在上线前可配置为允许的域名地址  
    valid_referers blocked 192.168.12.129;  
    if ($invalid_referer) {  
        # 可以配置成返回一张禁止盗取的图片  
        # rewrite   ^/ http://xx.xx.com/NO.jpg;  
        # 也可直接返回403  
        return   403;  
    }  
      
    root   /soft/nginx/static_resources;  
    expires 7d;  
}

根据上述中的内容配置后，就已经通过Nginx实现了最基本的防盗链机制，最后只需要额外重启一下就好啦！当然，对于防盗链机制实现这块，也有专门的第三方模块ngx_http_accesskey_module实现了更为完善的设计

注意：防盗链机制无法解决爬虫伪造referers信息的这种方式抓取数据。

Nginx之资源压缩，大文件传输，缓冲区，缓冲机制，IP黑白名单

1 Nginx

1.1 资源压缩

1.2 大文件传输配置

1.3 Nginx缓冲

1.3.1 Nginx缓冲区

1.3.2 Nginx缓存机制

1.3.3 缓存清理

1.4 Nginx实现IP黑白名单

1.5 Nginx跨域配置

1.5.1 跨域问题产生的原因

1.5.2 Nginx解决跨域问题

1.6 Nginx防盗链设计

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

k8s

Nginx