WO2016146009A1

WO2016146009A1 - Html page compression method and device

Info

Publication number: WO2016146009A1
Application number: PCT/CN2016/075942
Authority: WO
Inventors: 张荣华
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2015-03-17
Filing date: 2016-03-09
Publication date: 2016-09-22
Also published as: CN106033448A

Abstract

An Html page compression method and device. The method comprises: acquiring a static data compressed section of a corresponding Html page in a cache according to an http header in a browser request, and compressing dynamic data corresponding to the Html page into a dynamic data compressed section; and merging the static data compressed section and the dynamic data compressed section into Html page compressed data, and sending the Html page compressed data to a browser. The static content on an Html page can be pre-compressed and cached, and when a browser request is received, it is possible that only dynamic data in the Html page is compressed and merged with the static content and then returned. Therefore, conducting a large amount of compression when requesting a server each time is avoided, thereby greatly reducing the calculation pressure of the server.

Description

Html page compression method and device

The present application claims the priority of the Chinese Patent Application No. 201510115508.0, the entire disclosure of which is hereby incorporated by reference.

Technical field

The present invention relates to the field of the Internet, and in particular, to a Html page compression method and apparatus.

Background technique

The current Html page compression process is: receiving a browser request, the server returns the Html page corresponding to the request, and dot the Html page, and performs page compression after the dot. Therefore, the current Html page compression, in any request, you need to compress the data of the entire page, resulting in greater server pressure.

Summary of the invention

It is an object of the present invention to provide a Html page compression method and apparatus.

To achieve one of the above objects, an embodiment of the present invention provides a Html page compression method, the method comprising:

Obtaining a static data compression segment of the corresponding Html page in the cache according to the http header in the browser request, and compressing the dynamic data corresponding to the Html page into a dynamic data compression segment;

Combining the static data compression segment and the dynamic data compression segment into Html page compression data, and transmitting the Html page compression data to a browser.

As a further improvement of an embodiment of the present invention, the static data compression segment and the dynamic data compression segment are combined into Html page compression data, which specifically includes:

And compressing the static data compression segment and the dynamic data compression segment into Html page compression data according to an original sequence of the Html page.

As a further improvement of an embodiment of the present invention, in the Html page compressed data, the static data compressed segment and the dynamic data compressed segment are encapsulated by a compressed header information and a compressed tail information.

As a further improvement of an embodiment of the present invention, before acquiring the static data compression segment and compressing the dynamic data, the method includes:

Receiving a browser request;

Generating a corresponding Html page according to the http header in the browser request;

Stripping static data and dynamic data of the Html page;

The static data is compressed into a static data compression segment and cached.

As a further improvement of an embodiment of the present invention, the static data is compressed into a static data compression segment and cached, and specifically includes:

The static data is compressed in a compression request to generate at least one static data compression segment, and the at least one static data compression segment is stored.

As a further improvement of an embodiment of the present invention, the method specifically includes: when compressing static data and compressing dynamic data:

If the static data or the dynamic data is the header data or the middle data of the Html page, then

Call the z_full_flush function to compress;

If the static data or the dynamic data is the tail data of the Html page, the z_sync_flush function is called to perform compression.

As a further improvement of an embodiment of the present invention, invoking the z_full_flush function to compress the central data of the Html page includes:

Compressing after adding an empty string to the string header of the data in the middle of the Html page;

The compression header information formed on the empty string is deleted.

As a further improvement of an embodiment of the present invention, each static data compression segment includes dictionary data to be decompressible separately.

As a further improvement of an embodiment of the present invention, the merging into the Html page compression data according to the original order of the Html page specifically includes:

The static data compression segment and the dynamic data compression segment are assembled into Html page compression data in the order of a character string.

As a further improvement of an embodiment of the present invention, the method further includes:

Configure the Http response header to inform the browser of the compression format of the Html page compressed data it receives.

To achieve one of the above objects, an embodiment of the present invention provides an Html page compression apparatus, the apparatus comprising:

The calling module is configured to obtain a static data compression segment of the corresponding Html page in the cache according to the http header in the browser request;

a compression module, configured to compress dynamic data corresponding to the Html page into a dynamic data compression segment;

And a processing module, configured to merge the static data compression segment and the dynamic data compression segment into Html page compression data, and send the Html page compression data to a browser.

As a further improvement of an embodiment of the present invention, the processing module is configured to:

The static data compression segment and the dynamic data segment are merged into Html page compressed data according to the original order of the Html page.

As a further improvement of an embodiment of the present invention, the processing module is further configured to:

Receiving a browser request;

Separating static data and dynamic data of the Html page; the compression module is further configured to:

As a further improvement of an embodiment of the present invention, the compression module is configured to compress the static data in a compression request to generate at least one static data compression segment, and the device further includes a storage module, the storage module Used for:

Storing the at least one static data compression segment.

As a further improvement of an embodiment of the present invention, the compression module is used to:

Call the z_full_flush function to compress;

Adding an empty string to the string header of the data in the middle of the Html page for compression by the compression module;

The compression header information formed on the empty string is deleted.

As a further improvement of an embodiment of the present invention, the device further includes a configuration module, configured to:

Compared with the prior art, the technical effect of the present invention is that the Html page compression method and device of the present invention can be The static content on the Html page is pre-compressed and cached. When receiving the browser request, only the dynamic data in the Html page can be compressed and merged with the static content, so that each request is avoided. A lot of compression is needed, which greatly reduces the computing pressure on the server.

DRAWINGS

1 is a flowchart of a Html page compression method according to an embodiment of the present invention;

2 is a complete working flow chart of feedback of a request by a server after receiving a browser request according to an embodiment of the present invention;

3 is a schematic diagram of a Html page compression method according to an embodiment of the present invention;

4 is a block diagram of an Html page compression device in accordance with an embodiment of the present invention.

detailed description

The invention will be described in detail below in conjunction with the specific embodiments shown in the drawings. However, the embodiments are not intended to limit the invention, and the structural, method, or functional changes made by those skilled in the art in accordance with the embodiments are included in the scope of the present invention.

As shown in FIG. 1 , in an embodiment of the present invention, the Html page compression method includes:

Through the above process corresponding to FIG. 1, the static content on the Html page can be pre-compressed and cached. When receiving the browser request, only the dynamic data in the Html page can be compressed and merged with the static content and returned. In this way, compared with the prior art, a large amount of compression is required for each requesting server, thereby greatly reducing the computing pressure of the server.

As shown in FIG. 2, in a specific example, typically, after receiving a browser request, the server first passes some common code, such as a cookie decision. Next, it is determined whether the browser accepts the compressed data. If not, the Html page is directly generated and returned to the browser. If the browser accepts the compressed data, the Html page compression method according to an embodiment of the present invention may be used to form the Html page compressed data and then return to the browser.

Specifically, the server receives the browser request, and retrieves corresponding static data compression segments in the cache according to key fields included in the http header in the browser request, such as key data or locale in the user-agent. At this point, there are two possibilities:

1) There is a corresponding static data compression segment in the cache.

At this time, the static data compression segment in the cache may be obtained, and the dynamic data corresponding to the Html page is compressed into a dynamic data compression segment.

The Html page data includes header data, middle data, and tail data. The head data, the middle data, and the tail data may correspond to static data or dynamic data, respectively.

Further, when compressing static data and compressing dynamic data, the method specifically includes:

Call the z_full_flush function to compress;

Here, for the sake of simplicity of the description, the compression of the dynamic data is described in detail by taking the header data and the tail data corresponding to the static data and the central data corresponding to the dynamic data as an example:

Call the z_full_flush function to compress the middle data (dynamic data) of the Html page. Here, the reason why the central data needs to be compressed by calling the z_full_flush function is that if the central data in Html is compressed using the default compression method, the returned package is complete. For example, if you directly use the DEFLATEOutputStream in the JDK to compress the central data, each compressed package will carry the full DEFLATE header and trailer information. For some browsers, these multiple complete archives are not recognized. So in the java environment, a java implementation version of zlib is introduced: jzlib (http://www.jcraft.com/jzlib/, common knowledge of those of ordinary skill in the art, which will not be described here), jzlib In the embodiment, the flush_mode (jzlib) in the compression is supported, so in the embodiment, the z_full_flush function of jzlib can be called to compress the central data to obtain a corresponding dynamic data compression segment.

In the specific compression process: first, after adding an empty string to the string header of the middle data (dynamic data), the compressed file will contain a compressed header information formed on the empty string. And further deleting the compression header information formed on the empty string to facilitate the subsequent "merging of data compression segments", which will be explained in detail below.

2) There is no corresponding static data compression segment in the cache.

In this case, the cached data has expired, or the request for the Html page comes first after the server is started, so the cache is empty. At this time, according to an embodiment of the present invention:

First receiving a browser request and generating a corresponding Html page according to the http header in the browser request. The static data and the dynamic data of the Html page are stripped, and the static data is compressed into a static data compression segment and cached. Typically, the key data contained in the http header is used here, such as key information in the user-agent (exemplary: determining whether the browser that needs to be returned is applied to a PC or a mobile phone) to generate a corresponding Html page.

Here, the static data is compressed in one compression request. In order to improve the compression efficiency, in the present embodiment, multiple compressions of a plurality of separate static data in the same Html page data may be performed in one request. Moreover, the static data compression segment compressed at the time is synchronized, and the storage period can be set according to the update condition of the Html, so that the static data compression segment can be updated after one cycle.

Similarly, the header data and the tail data correspond to the static data, and the central data corresponds to the dynamic data as an example. The compression of the dynamic data and the static data is elaborated in this way:

Call jzlib's z_full_flush function to compress the Html page header data (static data) and the middle data (dynamic data), and call jzlib's z_sync_flush function to compress the Html page tail data (static data). Here, the reason why the z_full_flush function and the z_sync_flush function need to be called to compress the corresponding header data, the middle data, and the tail data is that if the data in the Html is compressed using the default compression method, each of the returned The zip package is complete. For example, if you directly use the DEFLATEOutputStream in the JDK to compress each part of the data, each compressed package will carry the full DEFLATE header and trailer information. For some browsers, these multiple complete archives are not recognized. So in the java environment, a java implementation version of zlib is introduced: jzlib, jzlib supports the flush_mode (jzlib) in compression, so in this embodiment, the z_full_flush function and the z_sync_flush function are respectively called to compress the above-mentioned partial data to obtain Static data compression segment and dynamic data compression segment.

Further, in the embodiment, the “combining the static data compression segment and the dynamic data compression segment into Html page compression data” specifically includes:

According to the original order of the Html page, the static data compression segment and the dynamic data compression segment are assembled into Html page compression data in the order of the string. At this time, since the static content on the Html page has been pre-compressed and cached, it avoids a large amount of repeated compression every time the request server is required, which greatly reduces the computing pressure of the server. Illustratively, the dynamic data here is dot data.

Further, in order to enable more browsers to recognize the Html page compressed data, in the Html page compressed data, the static data compressed segment and the dynamic data are compressed by a compressed header information and a compressed tail information. Shrink section package.

As shown in Figure 3, one Html page includes two static data compression segments: DEFLATE Data A (head data compression segment), DEFLATE Data C (tail data compression segment), and a dynamic data compression segment: DEFLATE Data B (middle Data compression section) as an example. DEFLATE Data A is compressed by the z_full_flush function, which contains a DEFLATE Header, which is compressed by the z_sync_flush function and contains a DEFLATE Tail. DEFLATE Data B is compressed by the z_full_flush function. In the compression process of DEFLATE Data B, an empty string is inserted in the corresponding string header, and the compression header information formed on the empty string is deleted after compression. . Thus, DEFLATE Data A, DEFLATE Data B, and DEFLATE Data C can be combined in sequence to form a complete Html page compression data.

Of course, in an exemplary alternative embodiment, DEFLATE Data B may also be compressed by the z_sync_flush function, and correspondingly, in the compression process of DEFLATE Data B, an empty string is inserted at the end of its corresponding string. And after compression, the compressed tail information formed on the empty string is deleted. In this way, DEFLATE Data A, DEFLATE Data B, and DEFLATE Data C can also be combined into one complete Html page compression data.

In the present embodiment, each static data compression segment includes dictionary data instead of the dictionary data of the first compressed segment, so that decompression can be performed separately.

Finally, the above Html page compression data is sent to the browser. In this process, first configure the Http response header to inform the browser of the compression format of the Html page compressed data it receives, and then put the Html page compressed data into the response buffer. The buffer compresses the Html page and finally returns it to the browser to complete the process of sending the entire Html page to the browser.

In an example implementation of the java version of the Html page compression method of the present invention, a_html and c_html are generated in advance, and some dynamic data is also included between the two pages. First compress a_html and c_html into the cache, then retrieve the static compressed data from the cache each time the request comes, and if not, re-generate the static compressed data dynamically; then generate dynamic data and compress, then set the HTTP response Header, and finally the compressed package is flushed into the response buffer according to the original order of the page.

It's worth noting that in the process of compressing dynamic data, you don't need to create a ZStream every time. You only need to create it once for each thread and you can reuse it. In this way, a few hundred KB of pages, a small amount of dynamic data will be compressed, most of the data will be pre-compressed, subsequent requests do not need to be compressed again, successfully avoiding a lot of double counting.

As shown in FIG. 4, in an embodiment of the present invention, the Html page compression apparatus 100 includes a retrieval module. 10. The compression module 20 and the processing module 30.

The retrieving module 10 is configured to obtain a static data compression segment of the corresponding Html page in the cache according to the http header in the browser request;

The compression module 20 is configured to compress dynamic data corresponding to the Html page into a dynamic data compression segment;

The processing module 30 is configured to merge the static data compression segment and the dynamic data compression segment into Html page compression data, and send the Html page compression data to a browser.

In a specific example, typically, after receiving a browser request, the server first passes some common code, such as a cookie decision. Next, it is determined whether the browser accepts the compressed data. If not, the Html page is directly generated and returned to the browser. If the browser accepts the compressed data, the Html page compression device according to an embodiment of the present invention may be used to form the Html page compressed data and then return to the browser.

1) There is a corresponding static data compression segment in the cache.

The compression module 20 is configured to:

Call the z_full_flush function to compress;

The compression module 20 calls the z_full_flush function to compress the middle data (dynamic data) of the Html page. Here, the reason why the central data needs to be compressed by calling the z_full_flush function is that if the central data in Html is compressed using the default compression method, the returned package is complete. For example, if you directly use the DEFLATEOutputStream in the JDK to compress the central data, each compressed package will carry the full DEFLATE header and trailer information. For some browsers, these multiple complete archives cannot be Identification. So in the java environment, a java implementation version of zlib is introduced: jzlib (http://www.jcraft.com/jzlib/, common knowledge of those of ordinary skill in the art, which will not be described here), jzlib In the embodiment, the flush_mode (jzlib) in the compression is supported, so in the embodiment, the z_full_flush function of jzlib can be called to compress the central data to obtain a corresponding dynamic data compression segment.

During the specific compression process, the processing module 30 first adds an empty string to the string header of the middle data (dynamic data) for compression by the compression module 20. At this time, the obtained compressed file will include a null character in the compressed file. The compression header information formed on the string; the processing module 30 further deletes the compression header information formed on the empty character string to facilitate the subsequent "merging of data compression segments", which will be explained in detail below. .

2) There is no corresponding static data compression segment in the cache.

The processing module 30 is configured to first receive a browser request, generate a corresponding Html page according to the http header in the browser request, and then strip the static data and the dynamic data of the Html page, and the compression module 20 is configured to: Static data is compressed into static data compression segments and cached. Typically, the key data contained in the http header is used here, such as key information in the user-agent (exemplary: determining whether the browser that needs to be returned is applied to a PC or a mobile phone) to generate a corresponding Html page.

Here, the static data is compressed for multiple statics in one compression request. In order to improve efficiency, in the present embodiment, multiple compression of a plurality of separate static data in the same Html page data may be performed in one compression request. Moreover, the storage module 40 synchronizes the static data compression segment compressed at this time, and the storage period can be set according to the update condition of the Html, so that the static data compression segment can be updated after one cycle.

Further, in this embodiment, the processing module 30 is further configured to:

According to the original order of the Html page, the processing module 30 assembles the static data compression segment and the dynamic data compression segment into Html page compression data in the order of the string. At this time, since the static content on the Html page has been pre-compressed and cached, it avoids a large amount of repeated compression every time the request server is required, which greatly reduces the computing pressure of the server. Illustratively, the dynamic data here is dot data.

Further, in order to enable more browsers to recognize the Html page compressed data, in the Html page compressed data, the static data compressed segment and the dynamic data compressed segment are encapsulated by a compressed header information and a compressed tail information.

Of course, in an exemplary alternative embodiment, the DEFLATE Data B may also be compressed by the compression module 20 by calling the z_sync_flush function. Accordingly, in the compression process of the DEFLATE Data B, the processing module 30 is in its corresponding character. An empty string is inserted at the end of the string, and the compressed tail information formed on the empty string is deleted after compression. In this way, DEFLATE Data A, DEFLATE Data B, and DEFLATE Data C can also be combined into one complete Html page compression data.

Finally, the processing module 30 sends the Html page compression data to the browser. In this process, the configuration module 50 first configures an Http response header for the Html page compression data to notify the browser of the compression format of the Html page compressed data received by the browser, and the processing module 30 then puts the Html page compressed data into the response. Punching area. The buffer will compress the Html page to compress the data and finally return to the browser to complete the process of sending the entire Html page to the browser.

It should be noted that the above-mentioned retrieving module 10, compression module 20, processing module 30, storage module 40, and configuration module 50 are all exemplary partitions according to logical functions. In actual applications, agents may be used. The server, or the application server, or the proxy server and the application server cooperate to implement the functions of the modules in the above embodiments, and the above-described modules may be correspondingly considered to constitute at least part of the proxy server and the application server.

In summary, the Html page compression method and apparatus of the present invention can pre-compress and cache the static content on the Html page, and when receiving the browser request, can only compress the dynamic data in the Html page, and Static content is returned after merging. In this way, it avoids a lot of compression every time the request server needs, which greatly reduces the computing pressure of the server.

A person skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the above-mentioned apparatus, device and module can refer to the corresponding process in the foregoing method embodiment, and details are not described herein again.

In the several embodiments provided by the present invention, it should be understood that the disclosed apparatus, apparatus, and method may be implemented in other manners. For example, the device implementations described above are merely illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be another division manner, for example, multiple modules or components may be combined or It can be integrated into another device, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or module, and may be electrical, mechanical or otherwise.

The modules described as separate components may or may not be physically separated. The components displayed as modules may or may not be physical modules, that is, may be located in one place, or may be distributed to multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.

In addition, each functional module in each embodiment of the present invention may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module. The above integrated modules can be implemented in the form of hardware or in the form of hardware plus software function modules.

The above-described integrated modules implemented in the form of software function modules can be stored in a computer readable storage medium. The software function module described above is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform the method of various embodiments of the present invention. Part of the steps. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

Finally, it should be noted that the above embodiments are only for explaining the technical solutions of the present invention, and are not intended to be limiting; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art will understand that Modifications of the technical solutions described in the foregoing embodiments, or equivalents of the technical features of the embodiments of the present invention, are not to be construed as a departure from the spirit and scope of the embodiments of the present invention.

Claims

An Html page compression method, the method comprising:

Obtaining a static data compression segment of the corresponding Html page in the cache according to the http header in the browser request, and compressing the dynamic data corresponding to the Html page into a dynamic data compression segment;

Combining the static data compression segment and the dynamic data compression segment into Html page compression data, and transmitting the Html page compression data to a browser.
The Html page compression method according to claim 1, wherein the static data compression segment and the dynamic data compression segment are combined into Html page compression data, which specifically includes:

And compressing the static data compression segment and the dynamic data compression segment into Html page compression data according to an original sequence of the Html page.
The Html page compression method according to claim 1 or 2, wherein in the Html page compression data, the static data compression segment and the dynamic data compression segment are compressed by a compression header information and a compressed tail information. Package.
The Html page compression method according to claim 1, wherein before the obtaining the static data compression segment and compressing the dynamic data, the method comprises:

Receiving a browser request;

Generating a corresponding Html page according to the http header in the browser request;

Stripping static data and dynamic data of the Html page;

The static data is compressed into a static data compression segment and cached.
The Html page compression method according to claim 4, wherein the static data is compressed into a static data compression segment and cached, and specifically includes:

The static data is compressed in a compression request to generate at least one static data compression segment, and the at least one static data compression segment is stored.
The Html page compression method according to claim 4, wherein when the method compresses the static data and compresses the dynamic data, the method specifically includes:

If the static data or the dynamic data is the header data or the middle data of the Html page, then

Call the z_full_flush function to compress;

If the static data or the dynamic data is the tail data of the Html page, the z_sync_flush function is called to perform compression.
The Html page compression method according to claim 6, wherein the z_full_flush function is called. The number of the central data of the Html page is compressed, including:

Compressing after adding an empty string to the string header of the data in the middle of the Html page;

The compression header information formed on the empty string is deleted.
The Html page compression method according to claim 1, wherein each of the static data compression segments includes dictionary data so as to be decompressible separately.
The Html page compression method according to claim 2, wherein the Html page compression data is merged according to the original order of the Html page, and specifically includes:

The static data compression segment and the dynamic data compression segment are assembled into Html page compression data in the order of a character string.
The Html page compression method according to claim 1, wherein the method further comprises:

Configure the Http response header to inform the browser of the compression format of the Html page compressed data it receives.
An Html page compression device, characterized in that the device comprises:

The calling module is configured to obtain a static data compression segment of the corresponding Html page in the cache according to the http header in the browser request;

a compression module, configured to compress dynamic data corresponding to the Html page into a dynamic data compression segment;

And a processing module, configured to merge the static data compression segment and the dynamic data compression segment into Html page compression data, and send the Html page compression data to a browser.
The Html page compression apparatus according to claim 11, wherein the processing module is configured to:

The static data compression segment and the dynamic data segment are merged into Html page compressed data according to the original order of the Html page.
The Html page compression apparatus according to claim 11 or 12, wherein in the Html page compressed data, the static data compressed segment and the dynamic data compressed segment are compressed by a compressed header information and a compressed tail information. Package.
The Html page compression device according to claim 11, wherein the processing module is further configured to:

Receiving a browser request;

Generating a corresponding Html page according to the http header in the browser request;

Separating static data and dynamic data of the Html page; the compression module is further configured to:

The static data is compressed into a static data compression segment and cached.
The Html page compression apparatus according to claim 14, wherein said compression module is used for Compressing the static data in a compression request to generate at least one static data compression segment, the device further comprising a storage module, the storage module is configured to:

Storing the at least one static data compression segment.
The Html page compression apparatus according to claim 14, wherein the compression module is configured to:

If the static data or the dynamic data is the header data or the middle data of the Html page, then

Call the z_full_flush function to compress;

If the static data or the dynamic data is the tail data of the Html page, the z_sync_flush function is called to perform compression.
The Html page compression apparatus according to claim 16, wherein the processing module is configured to:

Adding an empty string to the string header of the data in the middle of the Html page for compression by the compression module;

The compression header information formed on the empty string is deleted.
The Html page compression apparatus according to claim 11, wherein each of the static data compression sections includes dictionary data so as to be decompressible separately.
The Html page compression apparatus according to claim 12, wherein the processing module is configured to:

The static data compression segment and the dynamic data compression segment are assembled into Html page compression data in the order of a character string.
The Html page compression device according to claim 11, wherein the device further comprises a configuration module, configured to:

Configure the Http response header to inform the browser of the compression format of the Html page compressed data it receives.