Introduction to the principle
HTTP compression can greatly improve the speed of browsing websites. Its principle is that after the client requests the corresponding resources from the server, the resource files are compressed from the server and then output to the client. The client's browser is responsible for decompression and browsing. Compared with the ordinary browsing process of HTML, CSS, Javascript, and Text, it can save about 40% of traffic. More importantly, it can also compress dynamically generated web pages including CGI, PHP, JSP, ASP, Servlet, SHTML, etc., and the compression efficiency is also very high.
Configuration method
Tomcat 5.0 and later versions support compression of output content, using the gzip compression format.
Modify %TOMCAT_HOME%/conf/server.xml and revise the nodes as follows:
<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" executor="tomcatThreadPool" URIEncoding="utf-8" compression="on" compressionMinSize="50" noCompressionUserAgents="gozilla , traviata" compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" />
As can be seen from the properties of the above node, to use the gzip compression function, you need to add the following properties to the Connector node
•compression="on" turns on the compression function
•compressionMinSize="50" Enable compression output content size, default is 2KB
•noCompressionUserAgents="gozilla, traviata" Disable compression for the following browsers
•compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" Which resource types need to be compressed
Test method
After enabling the TOMCAT compression function, how do we test whether the compression is effective?
First of all, Tomcat determines whether the browser supports compression function based on the accept-encoding in the browser request header. If this value contains gzip, it means that the browser supports browsing of gzip compressed content. We can use two methods to verify whether the compression function is Take effect.
Direct request via browser
Everyone directly accesses the server with compression configuration enabled through the browser, and then uses the packet capture tool to view the captured data packets. If there is a lot of content that you cannot understand, it means that the compression function has been enabled.
By simulating requests through the program, we use httpclient to write a simple test program. The code is as follows:
@Test public void testGzip() { HttpClient httpClient = new HttpClient(); GetMethod getMethod = new GetMethod("http://localhost/admin.jsp"); try { getMethod.addRequestHeader("accept-encoding", "gzip, deflate"); getMethod.addRequestHeader("user-agent","Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0)"); int result = httpClient.executeMethod(getMethod); if (result == 200) { System.out.println(getMethod.getResponseContentLength()); String html = getMethod.getResponseBodyAsString(); System.out.println(html); System.out.println(html.getBytes().length); } } catch ( HttpException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } finally { getMethod.releaseConnection(); } } Execute this junit program and see what content it outputs. If the output is some garbled characters and the length of the printed content is much smaller than the actual length, it means that our configuration has taken effect. Through some other verification tools, we will find that the website Browsing speed will be significantly improved.
Note: If you find that the content is not compressed, you can consider adjusting the compressionMinSize size. If the requested resource is smaller than this value, compression will not be enabled.