nginx图片压缩-怎样使用 nginx 压缩html

nginx是个多进程web容器,不同的配置下它的启动方式也是不同的,这里我只说说最典型的启动方式。

它有1个master进程,和多个worker进程(最优配置的数量与CPU核数相关)。那么,首先我们要找到main函数,它在src/core/nginx.c文件中。谈到源码了,这时我们先简单看下源码的目录结构吧。

nginx主要有下列目录:

src/core,这个目录存放了基础的数据结构像LIST、红黑树、nginx字符串,贯穿始终的一些逻辑结构如ngx_cycle_s、ngx_connection_s等,还有对一些底层操作的封装如log、文件操作、共享内存、内存池等,最后还有个nginx.c这个main启动函数了。

src/event,这个目录下存放与抽象事件相关的结构和钩子函数。nginx是以事件驱动处理流程的,事件自然是整个体系的核心了,这里定义了最核心的ngx_event_s结构。

src/event/modules目录存放了具体的种种事件驱动方式,例如epoll、kqueue、poll、aio、select等,它们通过ngx_event_actions_t结构体中的钩子挂在nginx中。nginx启动时会根据配置来决定使用哪种实现方式。

src/os/unix中存放了unix系统下许多函数调用的UNIX实现。

src/http目录存放到http module的相关实现,这个module负责处理http请求,包括协议的解析以及访问backend server的代码。

src/http/module目录存放http module类型的一些特定用途的module,比如gzip处理加密,图片压缩等。

有个初步了解后,回到main函数中,顺序看看我们感兴趣的事情。它先执行了ngx_time_init,为什么要初始化时间呢?nginx考虑的还是很周到的,取系统时间gettimeofday是系统调用,这意味着,需要发送中断给linux内核,内核需要做进程间切换来处理这个调用。这是一个不能忽视成本的函数。nginx封装了时间函数,这样,每次我们需要处理时间时,并不是调用gettimeofday,而是nginx自己缓存的时间,这样大量减少了系统调用,取当前时间这事可是谁都爱干的。

那么,nginx是怎么维护自己的这个时钟呢?如何保证用户取到的当前时间是有意义的?nginx设计者的出发点是,nginx是事件驱动机制,当一批事件发生时,也就是epoll_wait返回时,会取一次gettimeofday来更新自己的时间,然后调用各个事件对应的处理函数。这些函数都会保证自己是无阻塞的,也就是毫秒级的处理能力,所以,在任何一个事件处理函数中,取到的时间都是之前epoll_wait刚返回时取到的时间,这样,即使拿到的时间慢了几毫秒也无所谓。关键是,每个函数都是无阻塞的,都要迅速的把控制权交还给nginx,这是基本设计原则哈。

gzip 是在 Linux 系统中经常使用的一个对文件进行压缩和解压缩的命令,既方便又好用。

在Nginx安装完成之后,我们可以开启Gzip压缩功能,这里Nginx默认只能对text/html类型的文件进行压缩。

下面的指令为开启Gzip的指令:

   # 启用 gzip 压缩功能

   gzip  on;

   # 默认值是1.1,就是说对HTTP/1.1协议的请求才会进行gzip压缩

   gzip_http_version 1.1;

   gzip_vary on;

   # 压缩级别,1压缩比最小处理速度最快,9压缩比最大但处理最慢,同时也最消耗CPU,一般设置为3就可以了

   gzip_comp_level 6;

   # nginx 做前端代理时启用该选项,表示无论后端服务器的headers头返回什么信息,都无条件启用压缩

   gzip_proxied any;

   # 什么类型的页面或文档启用压缩

   gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript image/jpeg image/gif image/png;

   # 最小压缩的页面,如果页面过于小,可能会越压越大,这里规定大于1K的页面才启用压缩

   gzip_min_length  1024;

   # 设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流

   gzip_buffers 16 8k;

   # 禁用IE6的gzip压缩

   gzip_disable "MSIE [1-6].(?!.*SV1)";

相关配置说明:

1、在gzip_http_version的默认值是1.1,就是说对HTTP/1.1协议的请求才会进行gzip压缩。

如果使用了proxy_pass进行反向代理,那么nginx和后端的upstream server之间是用HTTP/1.0协议通信的,如果使用nginx通过反向代理做Cache Server,前端的nginx没有开启gzip,且后端的nginx上未设置gzip_http_version为1.0,那么Cache的url将不会被gzip压缩。

2、gzip_disable的设置是禁用IE6的gzip压缩

IE6的某些版本对gzip的压缩支持不是很好,会造成页面的假死。对img进行gzip后会造成IE6的假死,把对img的gzip压缩去掉后就正常了。为了确保其它的IE6版本不出问题,所以加上了gzip_disable配置项。

3、gzip_min_length设置允许压缩的页面最小字节数,页面字节数从header头中的Content-Length中进行获取。

默认值是0,不管页面多大都压缩。建议设置成大于1k的字节数,小于1k可能会越压越大。 即: gzip_min_length 1024。

项目用到spring cloud,前端项目使用nginx进行代理,在上传大图片时时间过长,在页面的F1中查看接口状态,发现报500的错误,这是在后台服务中的网关服务的日志中发现报连接后台上传服务超时没有返回,这时去查看网关zuul的配置文件,修改一下相关的时间超时配置。修改后如下,将超时时间适当的配置大一些。

hystrix:

command:

default:

execution:

isolation:

thread:

timeoutInMilliseconds: 300000

ribbon:

ConnectTimeout: 300000

ReadTimeout: 300000

修改了如上配置后,在zuul中不报超时的错误了,但是上传大文件的时候还是失败,但是错误变成了504超时,这时发现是nginx配置的超时时间过小导致的,对nginx的配置文件添加相应的超时配置。

#该指令设置与upstream server的连接超时时间

proxy_connect_timeout 750;

#该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间,而是两次reading操作的时间

proxy_read_timeout 6000;

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

这两个选项.

fastcgi_read_timeout是指fastcgi进程向nginx进程发送response的整个过程的超时时间

fastcgi_send_timeout是指nginx进程向fastcgi进程发送request的整个过程的超时时间

这两个选项默认都是秒(s),可以手动指定为分钟(m),小时(h)等

通过上面的配置之后图片可以正常上传上去,虽然花费的时间较长,但总算是传上去了。