Nginx static compression is similar to apache gzip compression, and the principle is similar. This article describes how to use nginx static compression module ngx_http_gzip_static_module.
When constructing squid web page acceleration, compress large css or js files and then cache them. This increases the page response speed by reducing the download volume. If you are using a version earlier than squid 3.0 and use an ngnix server, you may encounter the following problems: if you do not need squid to open the page directly, the client returns the compressed state, if squid acceleration is enabled, the downloaded page is not in the compressed state. This is mainly because the ngnix static cache module (ngx_http_gzip_static_module) is not started.
Solve the static cache problem.
Nginx compilation options
./Configure -- with-http_gzip_static_module
Configure nginx
Gzip_static on;
Gzip_http_version 1.1;
Gzip_proxied expired no-cache no-store private auth;
Gzip_disable "MSIE [1-6].";
Gzip_vary on;
# Pre-compressed files cannot be found for dynamic compression
Gzip on;
Gzip_min_length 1000;
Gzip_buffers 4 16 k;
Gzip_comp_level 5;
Gzip_types text/plain application/x-javascript text/css application/xml;
# Gzip public configuration
Gzip_http_version 1.1
Gzip_proxied expired no-cache no-store private auth;
Gzip_vary on description
For requests that support gzip, the reverse proxy cache server will return gzip content. Clients that do not support gzip will return the original content.
Other instructions
Gzip_static configuration has a higher priority than gzip
After nginx_static is enabled, any file will first find whether the corresponding gz file exists.
Gzip_types settings are invalid for gzip_static
HttpGzipStaticModule Nginx compressed transmission
When a file is provided from a disk to a client that supports gzip, this module searches for files with the same file name in the same directory (or location) and ". gz "file ended in the format. This file is called the" pre-compression format "of the file. It is called the" pre-compression format "because Nginx does not compress the file, this file is not generated even after it is accessed ". files in gz format, so we need to compress them ourselves. So what is the role of this mechanism? The reason for doing so is to avoid compressing the same file for each request.
Ngx_http_gzip_static_module is provided from nginx 0.6.24, but it is not compiled and installed by default, so you need to specify the -- with-http_gzip_static_module option during compilation.
Configuration Example
Gzip_static on;
Gzip_http_version 1.1;
Gzip_proxied expired no-cache no-store private auth;
Gzip_disable "MSIE [1-6] \.";
Gzip_vary on;
Orders
Command name: gzip_static
Function: enable this module. Note that the timestamp of the compressed and non-compressed versions must match to provide the latest content.
Syntax: gzip_static on | off
Default value: gzip_static off
Environment: http, server, location
For the following commands, refer to the NginxHttpGzipModule module:
Command name: gzip_http_version
Command name: gzip_proxied
Command name: gzip_disable
Command name: gzip_vary
Use instance
In the following example, we first generate a ". gz" format file for the current webpage index.html, that is, index.html.gz. then we will test that the plugin is modifying the index.html file and then accessing the test.
Add configuration
Gzip on;
Gzip_types text/plain application/xml;
Gzip_static on;
Access test
Create another format index.html.gz for the index.html file:
[Root @ mfsmaster html] # ls
Index.html
[Root @ mfsmaster html] # cat index.html
<Html>
<Head>
<Title> Welcome to nginx! </Title>
</Head>
<Body bgcolor = "white" text = "black">
<Center>
</Body>
</Html>
[Root @ mfsmaster html] # gzip-c index.html> index.html.gz
[Root @ mfsmaster html] # ls
Index.html index.html.gz
Determine the file access time:
[Root @ mfsmaster html] # stat index .*
File: 'index.html'
Size: 167 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394667 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 16:45:20. 339995192 + 0800
Modify: 16:44:16. 746662848 + 0800
Change: 16:44:16. 746662848 + 0800
File: 'index.html.gz'
Size: 151 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394635 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 16:45:20. 338995344 + 0800
Modify: 16:45:20. 339995192 + 0800
Change: 16:45:20. 339995192 + 0800
Access this file:
View the object access time
[Root @ mfsmaster html] # stat index .*
File: 'index.html'
Size: 167 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394667 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 16:45:20. 339995192 + 0800
Modify: 16:44:16. 746662848 + 0800
Change: 16:44:16. 746662848 + 0800
File: 'index.html.gz'
Size: 151 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394635 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 16:59:01. 040229792 + 0800
Modify: 16:45:20. 339995192 + 0800
Change: 16:45:20. 339995192 + 0800
By comparing the timestamps of these two files, we can say that our website is provided by the 'index.html.gz 'file.
Next, modify the index.html file:
[Root @ mfsmaster html] # vi index.html
<Html>
<Head>
<Title> Welcome to nginx! </Title>
</Head>
<Body bgcolor = "white" text = "black">
<Center>
</Body>
</Html>
View the object access time
[Root @ mfsmaster html] # stat index .*
File: 'index.html'
Size: 183 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394671 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 18:02:40. 022656216 + 0800
Modify: 18:02:40. 022656216 + 0800
Change: 18:02:40. 023656064 + 0800
File: 'index.html.gz'
Size: 151 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394635 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 16:59:01. 040229792 + 0800
Modify: 16:45:20. 339995192 + 0800
Change: 16:45:20. 339995192 + 0800
Visit this webpage again:
The obtained page is the same as the original one. We can view the file access timestamp again (if you are also doing a test, you need to clear the IE browser cache ):
[Root @ mfsmaster html] # stat index .*
File: 'index.html'
Size: 183 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394671 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 18:02:40. 022656216 + 0800
Modify: 18:02:40. 022656216 + 0800
Change: 18:02:40. 023656064 + 0800
File: 'index.html.gz'
Size: 151 Blocks: 8 IO Block: 4096 general files
Device: fd00h/64768d Inode: 5394635 Links: 1
Access: (0644/-rw-r --) Uid: (0/root) Gid: (0/root)
Access: 18:09:11. 569132104 + 0800
Modify: 16:45:20. 339995192 + 0800
Change: 16:45:20. 339995192 + 0800
Comment 'file. If you do not believe it, delete the 'index.html.gz 'file and access the webpage. The webpage is definitely the latest version.
Let's take a look at the following access conditions:
[Root @ mfsmaster html] # ll
Total usage 52
-Rw-r -- 1 root 152 August 18 19:07 index.html
-Rw-r -- 1 root 151 August 18 16:45 index.html.gz. old
-Rw-r -- 1 root 12376 August 19 08:22 xx.html
-Rw-r -- 1 root 4032 August 19 12:12 xx.html.gz
To illustrate the access situation, visit http://www.xx.com/xx.html. The page will not be intercepted again. Check the status of the captured packets:
Bytes: 1260*3 + 252 bytes: Bytes. The xx.html.gz page is displayed!
After talking about this, what we need to understand is the benefits of compressed transmission, which definitely saves bandwidth. Let's take a look at the formula below:
(12376-4032)/12376 = 67.42%
(12376-4324)/12376 = 65.06%
We can see from the above that our compressed webpage directly reduces the bandwidth by about 60%, which can also save a lot of cost for the server.