How to Use http compression to optimize servers

Given the limited bandwidth on the internet, any effort by network administrators to speed up access is valuable. One of the methods is to accelerate the access speed through HTTP compression technology. It reduces the amount of data transmitted between the server and the client, significantly improving the website performance. Data Compression is not new. However, this method features real-time data compression between the server and the client. Few users know this method.

HTTP compression technology does not require client configuration. It is the easiest way to increase the network speed. This article aims to discuss how this technology works? What are its advantages and how to implement data compression on Apache and IIS?

　　Why compression?

Most users know about the compression technology from the experience of compressing, extracting, and opening a large group of downloaded files. This compression technology can also be used to compress data transmitted to the client, because this is an active processing process, the server can reduce the size of webpage sending, thus reducing the user download time and maximizing the efficiency of using broadband.

With compression technology, you can compress HTML files to half the original size. In this way, more time is left for the client to download more bandwidth. This compression is achieved without affecting the actual website workflow, webpage design, and internal services. The only change is the information transmission mode.

However, this method also has its limitations.

　　Suitable for compressed file types

Of course, not all files need to be compressed. For example, compressed files such as JPEG, GIF, PNG, movie, and packaged content do not require HTTP compression and filtering technology. Compressing them again will not significantly reduce the file size.

At the same time, the website also has a large amount of text content such as HTML, XML, CSS and RSS, all of which need to be compressed. The compressed program depends on the file type. The compression ratio of most HTML text files is 50%. A webpage in a very format (for example, a large number of tables are used to plan the page) can be further compressed, and the maximum size can be compressed to 1/3 of the original size.

Fortunately, most HTTP servers provide the ability to select which type of files to be compressed, and the server can select the file type for compression. files that are not suitable for compression will be excluded.

　　Implement HTTP Compression

HTTP compression is a server function, and the browser automatically supports HTTP compression without configuring the client. To enable server compression, you only need to make some simple settings for the server.

To enable HTTP compression settings, the earlier versions of Apache, IIS6, and IIS have different settings.

　　Apache

Apache 2.0 contains the mod_deflate module, which dynamically compresses the server content using gzip. This compression can be of no difference to all content-for IE browsers, all content is compressed or optional, only the specified MIME type is compressed, the MIME type is determined by the HTTP Response Header, which can be automatically generated by Apache or output by dynamic programs (such as CGI.

To achieve non-differential content compression, you can add setoutputfilter to the entire site or directory to which compression needs to be enabled in the Apache configuration file. The instructions are as follows:

Setoutputfilter deflate

To enable compression for specific mime-type content, you can use addoutputfilterbytype in the configuration file, as shown below:

Addoutputfilterbytype deflate text/html

Note that all output of the specified MIME type will be compressed, whether it is from a static disk file or a dynamic program (such as CGI or mod_perl) output.

Some old browsers cannot correctly process compressed content. In this case, browsermatch can be used to indicate that a specific browser type has been filtered out. You can view mod_deflate to help the manual obtain more detailed information.

　　IIS 6

IIS 6 includes an easy-to-use built-in compression component. Because it is built-in, it does not use the iisapi interface, and Its compression speed is extremely fast. It is the best alternative to the third-party HTTP compression components of IIS 5 and earlier versions. The compression system can be used to compress dynamic content (such as the Script output Xianhe) and static content. It can also buffer the compressed information in the directory so that when accessing previously accessed content again, no further compression is required to improve the access performance of dynamic and static content.

To implement HTTP compression technology in IIS 6, you can open the website properties page, edit global properties, switch to the "service" tab, and configure and select items in the HTTP compression option.

Cached files are stored in temporary directories. The default setting is the subdirectory of the metadata directory in IIS. The directory must be located in an NTFS-format partition. You can set the buffer size or an unlimited number, we recommend that you set up to double the partition size (the data also includes the output content of dynamic scripts ).

　　Iis5 and earlier IIS versions

Older versions of iis5 and IIS do not have built-in compression functions, but they support ISAPI filters. We recommend that you use

Zipenable. Although there are other products with similar features, it is one of the few products that Microsoft specifically recommends, and it is compatible with IIS 6, by configuring the settings of IIS 6, it can further control IIS6's HTTP compression function at the directory level.

　　Server performance

Obviously, it takes a certain amount of CPU time to compress the transmitted data. This compression process may have a negative impact on the website, because each target must be compressed before sending. Here IIS6 is a small step ahead of Apache. It creates a buffer area and stores compressed files in it, which greatly reduces the CPU compression processing time for frequently accessed content. However, this cannot completely avoid the need for real-time online compression. A large amount of dynamic content must be compressed online, and the cache space required for these dynamic content may be extremely large.

If you can save 50% of the bandwidth and only sacrifice less than 10% of the CPU time of the website. This is completely worthwhile, especially for those enterprises that pay by network traffic.

　　Browser support and Dynamic Content

Today, most modern browsers support compression technology, but the specific compression method depends on the browser. However, you don't need to worry about this because the Web server only sends compressed content when the browser instructs you to support a compression method. Although it makes sense to understand the processing mechanism and the compression types supported by different browsers.

When the browser requests a URL, it submits the supported compression formats to the server through the HTTP header of accept-encoding. Apache or other Web servers read this information from the http_accept_encoding environment variable, this process requires no human intervention. Apache will automatically encode the sent content when the browser supports compression.

The following table lists common browsers and Their supported encoding types.

Browser	Supported Encoding
Firefox 1.0, Mozilla 1.x, Camino	Gzip, deflate
Omniweb 5.x	Bzip2, Gzip, deflate
Safari	Gzip, deflate
Internet Explorer	Gzip, deflate

The word "Identity" sometimes appears in the encoding list supported by the browser, which means that non-compressed content is supported. All browsers provide support for it by default, but some are not particularly listed.

As shown above, modern browsers support compression technology. When a URL request is sent, the browser automatically provides the supported encoding. If you need to use HTTP compression technology, you only need to set the server side.

　　Summary

HTTP compression is a simple way to improve server performance and reduce bandwidth consumption. It also has potential shortcomings, that is, it increases the CPU overhead. However, compared with the benefits it brings, this overhead is worth the money.

In addition, if you find that it does not improve the server performance, it is very easy to disable it. It has not changed the content of your site, but only the data transmission method.

Note:
On Windows Server 6.0 running Microsoft Internet Information Services (IIS) 2003, use GNU zip (gzip) compressed static files may be unavailable or contain content from other files on the web server. In this case, an error is generated when a page is returned to the client, which may also cause access conflicts.
These problems may affect the "Outlook Network Access (OWA)" user and may cause code errors to be returned to the OWA page.

Microsoft has released a patch for the above problems. Its version number is 831464, And the size is 430 kb. This patch corresponds to the article in the Microsoft 831,464th knowledge base.

Click here to download the Simplified Chinese version of the patch.

Http://www.cnblogs.com/shanyou/archive/2005/08/20/218927.html
Http://www.cnblogs.com/dudu/archive/2004/12/12/76085.html
Http://blog.joycode.com/moslem/archive/2005/08/19/62173.aspx