CN103581130A - 数据压缩处理方法、系统及装置 - Google Patents

Abstract

本发明公开了一种数据压缩处理方法、系统及装置，在上述方法中，中间服务器接收来自于目标服务器的响应于客户端发出的请求消息的响应消息，并从响应消息中获取客户端待接收的响应数据，其中，请求消息中携带有客户端指定的中间服务器待使用的压缩流的标识信息；中间服务器在采用与标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中，并将封装处理后的响应消息发送至客户端。根据本发明提供的技术方案，提高了网络数据的压缩率、降低了网络数据的压缩时间、加快了客户端的访问速度、节省了网络流量。

Description

数据压缩处理方法、系统及装置

技术领域

本发明涉及移动通信领域，具体而言，涉及一种数据压缩处理方法、系统及装置。

背景技术

目前，客户端需要访问的网页内容通常是经过特定压缩算法进行压缩处理得到的，例如采用字典压缩算法，即字典里的每一个键都会对应于同一个值，如果被压缩的数据中有部分数据相同，则会被同一个键所替代。由此可见，在可以重复利用压缩字典且用户多次浏览的页面内容相似率较高的情况下，可以获得更高的压缩率。

GZIP是一种典型的字典压缩算法，最早由Jean-loup Gailly和MarkAdler创建，用于UNIX系统的文件压缩。在Linux中经常会用到后缀为.gz的文件，这些文件所采用的格式即为GZIP格式。如今，GZIP格式已经成为因特网(Internet)上使用非常广泛的一种数据压缩格式或者一种文件格式。目前，超文本传输协议(Hypertext Transfer Protocol，简称为HTTP)上的GZIP压缩是一项用来改进WEB应用程序性能的技术。大流量的WEB站点常常使用GZIP压缩技术以使用户感受更快的页面显示速度，通过在WWW服务器中安装此项功能，当用户访问该服务器中的网站时，服务器中的此项功能就会将网页内容压缩后传输至访问的移动终端浏览器上进行显示。通常情况下，对纯文本内容可压缩到原大小的40％，传输速度明显加快，其效果在于用户点击网址后，目标页面会很快的显示出来，当然这也会增加服务器的负载。在客户端/服务器(C/S架构)的网络传输中，一般由客户端发起请求，通知服务器客户端可以接收GZIP压缩编码的数据。如果服务器支持GZIP编码，就会创建GZIP压缩流，将数据采用GZIP编码处理后返回客户端，当服务器编码完成后就会释放已经创建的GZIP压缩流。当客户端接收到编码处理的数据时，发现数据采用了GZIP编码，客户端就会创建GZIP解压流，当解压完成后即释放GZIP解压流。

然而，相关技术中，通常会出现客户端与同一个目标服务器在一段时间内进行多次数据交互。此时GZIP压缩/解压流将会处于不断被创建、又不断被释放的状态，因此压缩效率仍有待提高。

发明内容

本发明提供了一种数据压缩处理方法、系统及装置，以至少解决相关技术中在客户端连续访问同一目标服务器的页面内容时，页面网络数据压缩效率较低的问题。

根据本发明的一个方面，提供了一种数据压缩处理方法。

根据本发明的数据压缩处理方法包括：中间服务器接收来自于目标服务器的响应于客户端发出的请求消息的响应消息，并从响应消息中获取客户端待接收的响应数据，其中，请求消息中携带有客户端指定的中间服务器待使用的压缩流的标识信息；中间服务器在采用与标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中，并将封装处理后的响应消息发送至客户端。

优选地，在中间服务器接收来自于目标服务器的响应消息之前，还包括：客户端获取压缩流的标识信息以及压缩流已经传输的响应数据的长度信息并将获取到的信息添加在请求消息中。

优选地，客户端获取压缩流的标识信息以及压缩流已经传输的响应数据的长度信息并将获取到的信息添加在请求消息中包括：客户端判断当前是否存在与目标服务器对应的已经使用过的压缩流；如果存在，则客户端获取已经使用过的压缩流的标识信息以及该压缩流已经传输的响应数据的长度信息，并将获取到的信息添加在请求消息中；如果不存在，则客户端创建压缩流，设置创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在请求消息中。

优选地，在客户端创建压缩流，设置创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在请求消息之后，还包括：中间服务器在对请求消息进行解析后，为创建的压缩流分配标识信息。

优选地，在中间服务器将封装处理后的响应消息发送至客户端之后，还包括：中间服务器更新当前保存的已经接收到的响应数据的长度信息；中间服务器更新响应消息中的长度字节，其中，长度字节用于记录经过中间服务器压缩处理后的响应数据的长度。

根据本发明的另一方面，提供了一种数据压缩处理系统。

根据本发明的数据压缩处理系统包括：中间服务器；中间服务器包括：接收模块，用于接收来自于目标服务器的响应于客户端发出的请求消息的响应消息，并从响应消息中获取客户端待接收的响应数据，其中，请求消息中携带有客户端指定的中间服务器待使用的压缩流的标识信息；第一处理模块，用于在采用与标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中，并将封装处理后的响应消息发送至客户端。

优选地，上述系统还包括：客户端；客户端包括：添加模块，用于获取压缩流的标识信息以及压缩流已经传输的响应数据的长度信息并将获取到的信息添加在请求消息中。

优选地，添加模块包括：判断单元，用于判断当前是否存在与目标服务器对应的已经使用过的压缩流；添加单元，用于在判断单元输出为是时，获取已经使用过的压缩流的标识信息以及该压缩流已经传输的响应数据的长度信息，并将获取到的信息添加在请求消息中；创建单元，用于在判断单元输出为否时，创建压缩流，设置创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在请求消息中。

优选地，中间服务器还包括：分配模块，用于在对请求消息进行解析后，为创建的压缩流分配标识信息。

根据本发明的再一方面，提供了一种数据压缩处理装置。

根据本发明的数据压缩处理装置包括：发送模块，用于经由中间服务器向目标服务器发送请求消息，其中，请求消息中携带有客户端指定的中间服务器待使用的压缩流的标识信息；接收模块，用于经由中间服务器接收来自于目标服务器的响应于请求消息的响应消息，并从响应消息中获取响应数据，其中，所述响应数据是由中间服务器在采用与标识信息对应的由客户端指定的压缩流进行压缩处理后，封装在响应消息中。

通过本发明，客户端在访问目标服务器时，首先获取已经使用过的访问该目标服务器的压缩流，并将获取到的压缩流的标识信息添加在请求消息中；其次中间服务器将请求消息转发至目标服务器，之后接收来自于目标服务器的响应消息，并从响应消息中获取客户端待接收的响应数据；然后中间服务器在采用客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中，并将封装处理后的响应消息发送至客户端，解决了相关技术中在客户端连续访问同一目标服务器的页面内容时，页面网络数据压缩效率较低的问题，进而提高了网络数据的压缩率、降低了网络数据的压缩时间、加快了客户端的访问速度、节省了网络流量。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的数据压缩处理方法的中间服务器处理的流程图；

图2是根据本发明优选实施例的客户端、中间服务器以及目标服务器的时序交互流程图；

图3是根据本发明优选实施例的数据压缩处理方法的中间服务器处理的流程图；

图4是根据本发明实施例的数据压缩处理方法的客户端处理的流程图；

图5是根据本发明优选实施例的客户端、中间服务器以及目标服务器使用数据压缩处理方法进行交互的系统示意图；

图6是根据本发明实施例的数据压缩处理系统的结构框图；

图7是根据本发明优选实施例的数据压缩处理系统的结构框图；以及

图8是根据本发明实施例的数据压缩处理装置的结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

图1是根据本发明实施例的数据压缩处理方法的中间服务器处理的流程图。如图1所示，该方法可以包括以下处理步骤：

步骤S102：中间服务器接收来自于目标服务器的响应于客户端发出的请求消息的响应消息，并从响应消息中获取客户端待接收的响应数据，其中，请求消息中携带有客户端指定的中间服务器待使用的压缩流的标识信息；

其中，所述标识信息可以为复用压缩流标识信息，表明该压缩流是可以复用的。

步骤S104：中间服务器在采用与标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中，并将封装处理后的响应消息发送至客户端。

相关技术中，在客户端连续访问同一目标服务器的页面内容时，页面网络数据压缩效率较低。采用如图1所示的方法，客户端在访问目标服务器时，获取已经使用过的所要访问的目标服务器的压缩流，并将获取到的压缩流的标识信息添加在请求消息(例如：超文本传输协议HTTP请求)中；中间服务器将接收到的客户端的请求消息转发至目标服务器，之后接收来自于目标服务器的响应消息，并从响应消息中获取客户端待接收的响应数据；中间服务器在采用与所述标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中，并将封装处理后的响应消息发送至客户端，从而解决了相关技术中无法实现对协议中的压缩流进行重复利用的问题，进而提高了网络数据的压缩率、降低了网络数据的压缩时间、加快了客户端的访问速度、节省了网络流量。

在优选实施例中，相关技术中的应用服务器仅能支持标准的普通HTTP请求，因此，引入了一个中间服务器(例如：WEB加速器)。WEB加速器相当于一个增强版的代理，不但能够处理普通的HTTP请求，同样也可以自动识别客户端发过来的重复利用压缩流的HTTP请求，并且对服务器的响应数据进行压缩再转发给客户端。鉴于用户可能会重复刷新某一个页面，并且对于大量文本页面会有一定的数据重合，WEB加速器在进行数据压缩时会根据客户端发过来的请求标识进行压缩流的复用，以达到提高压缩率和降低压缩时间的目的。

在优选实施例中，如图2所示，中间服务器(图2以WEB加速器为例)在接收到客户端发送的HTTP请求消息后，还要对HTTP请求消息进行解析，通过解析处理可以获知客户端是否支持复用压缩流。

在优选实施例中，中间服务器在接收到目标服务器(图2中指服务端)的应答时，发现满足以下条件时判断为能重复使用压缩流：

条件一、客户端启用加速功能(请求头中有X-Z-Ticket和Accept-Encoding：gzip)；

条件二、中间服务器开启加速功能(配置项已经开启)；

在优选实施例中，若中间服务器成功开启了WEB加速功能，则目标服务器在HTTP应答中携带以下应答头：X-Z-Ticket：流标识已传输的数据长度，其中，流标识可以由WEB加速器生成，具有标识意义的base64字符串，其长度小于32字节。已传输的数据长度是指目标服务器已经在应答中发送的网络数据大小。

条件三、目标服务器的应答数据的类型符合要求，即属于非图片类型数据；

条件四、响应数据为文本(text)、js和层叠样式表单(css)且不为chunked(分块编码)；

条件五、请求头IP地址未存在于黑名单中。

需说明的是，上述5个条件是本发明的最优实施例，在满足前面3个条件时也是可以实现。

优选地，在步骤S102，中间服务器接收来自于目标服务器的响应消息之前，还可以包括以下处理：客户端获取压缩流的标识信息以及压缩流已经传输的响应数据的长度信息并将获取到的信息添加在请求消息中。

优选地，上述客户端获取压缩流的标识信息以及压缩流已经传输的响应数据的长度信息并将获取到的信息添加在请求消息中可以包括以下操作：

步骤S1：客户端判断当前是否存在与目标服务器对应的已经使用过的压缩流；

在优选实施例中，客户端发送HTTP请求消息时，先判断当前已有压缩流的状态，若压缩流正在被使用，则该压缩流不会再被重复使用，即当前被使用的压缩流处于锁定状态，那么将继续判断是否应该新建压缩流，即通过判断是否存在已经使用过的压缩流来确定是否新建压缩流。需要说明的是，此时并不需要真正创建压缩流对象。

步骤S2：如果不存在，则客户端创建压缩流，设置创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在HTTP请求消息中。

例如：如图2所示，客户端没有获取到一个已经使用过的压缩流，可以在HTTP请求消息中添加X-Z-Ticket的值为0，且Accept-Encoding带有GZIP。

在优选实施例中，若客户端启用WEB加速功能，则可以在HTTP请求中携带以下请求头：X-Z-Ticket：流标识已传输的数据长度，其中，流标识可以是从之前由WEB加速器在X-Z-Ticket应答头中返回的字符串中取位于之前的部分或者设置为空；流标识可以让客户端标识出来自不同WEB加速器的压缩流。例如：当前有加速器A和加速器B，加速器A发送的压缩流的标识与加速器B发送的压缩流标识不同，即每个压缩流各有一个唯一的标识。因此，在客户端接收到压缩流之后，可以明确区分压缩流的来源(来自于加速器A或者来自于加速器B)。如果从加速器A和加速器B向客户端发送的压缩流的标识相同，则客户端将无法区分所接收到的压缩流来自于哪个加速器，由此可能会导致客户端错用压缩流进行解压，从而导致无法获取正确的结果。已传输的数据长度是指客户端已经从HTTP响应消息中读取的网络数据大小。

优选地，在上述步骤S3，客户端创建压缩流，设置创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在HTTP请求消息之后，还可以包括：

步骤S3：如果存在，则客户端获取已经使用过的压缩流的标识信息以及该压缩流已经传输的响应数据的长度信息，并将获取到的信息添加在HTTP请求消息中；

例如：如图2所示，客户端获取到一个已经使用过的压缩流，可以在HTTP请求消息中添加X-Z-Ticket的值为ABCDEF1024，且Accept-Encoding带有GZIP。

步骤S4：中间服务器在对HTTP请求消息进行解析后，为创建的压缩流分配标识信息。

在优选实施例中，如图2所示，WEB加速器在接收到客户端发送的HTTP请求消息之后，发现X-Z-Ticket的值为0，且Accept-Encoding带有GZIP，表明不存在已经使用过的压缩流，需要创建一个新的压缩流，则WEB加速器会为新创建的压缩流分配了一个唯一的标识：ABCDEF，以便客户端下次再访问相同的目标服务器时，可以重复利用新开启的压缩流。

优选地，上述HTTP请求消息中还可以携带有压缩流已经传输的响应数据的长度信息(例如：1024个字节)，在步骤S104中，中间服务器采用客户端指定的压缩流对响应数据进行压缩处理可以包括以下步骤：

步骤S5：中间服务器获取客户端指定的压缩流，并对客户端指定的压缩流的已经传输的响应数据的长度信息进行校验；

例如：如图2所示，客户端指定WEB加速器使用X-Z-Ticket的值为ABCDEF1024，且Accept-Encoding带有GZIP的压缩流，则WEB加速器获取这个压缩流并对响应数据的长度信息1024进行校验。

步骤S6：如果校验成功，则中间服务器采用获取到的客户端指定的压缩流对响应数据进行压缩处理。

例如：如图2所示，WEB加速器对压缩流已经传输的响应数据的长度信息(例如：1024个字节)校验成功，则使用这个获取到的压缩流对接收到的响应数据进行压缩处理。

优选地，如果上述步骤S5校验失败，则上述方法还可以包括以下步骤：

步骤S7：中间服务器记录校验失败的次数，并与预设阈值(例如：5次)进行比较；

步骤S8：如果校验失败的次数超过预设阈值，则中间服务器在预设时间段内仅对响应数据进行普通的压缩处理，并返回给客户端。

在优选实施例中，若获取压缩流失败或者校验长度信息失败，则会通过判断当前客户端的失败次数是否达到阀值决定是否进入黑名单。因此，本发明可以在步骤S4前判断客户端是否在黑名单中，若此客户端处于黑名单中，则表明受某种原因(例如：网关拦截X-Z-Ticket头)影响导致此功能异常，因此，不再或者在某段时间内不对应答数据进行二次压缩处理，只进行普通压缩处理。

优选地，在步骤S104，中间服务器将封装处理后的HTTP响应消息发送至客户端之后，还可以包括以下操作：

步骤S9：中间服务器更新当前保存的已经接收到的响应数据的长度信息，其值为旧值加上当前应答的网络数据长度(HTTP应答的Content-Length或者经过chunked解码后的数据长度)，即中间服务器累计更新经过压缩处理的响应数据长度；

例如：如果WEB加速器已经传输的响应数据的长度为1024字节，而客户端此次访问又接收到服务器返回的响应数据的长度为512字节，此时，WEB加速器将已经传输的响应数据的长度更新为1536字节。

步骤S10：中间服务器更新HTTP响应消息中的长度字节(即Content-Length)，其中，该长度字节用于记录经过中间服务器压缩处理后的响应数据的长度，即中间服务器记录当前接收到的响应消息中的响应数据在经过压缩处理后的响应数据长度。

例如：中间服务器当前接收到的响应消息中的响应数据的长度为1024字节，经过压缩处理后的响应数据长度为512字节，此时应该用当前压缩处理后的响应数据的长度去更新上一次记录的经过中间服务器压缩处理后的响应数据的长度。

需要说明的是，对于chunk类型的HTTP响应消息，WEB加速器并不等待所有分段都接收完成再进行合并转发，而是会选择直接转发已经收到的分段转发给客户端。

在优选实施例中，图3是根据本发明优选实施例的数据压缩处理的中间服务器处理的流程图。如图3所示，该流程可以包括以下步骤：

步骤S302：中间服务器接收到客户端的HTTP请求消息；

步骤S304：中间服务器对HTTP请求消息进行解析，并将请求消息转发至目标服务器；

步骤S306：中间服务器收到目标服务器的响应消息；

步骤S308：中间服务器判断与响应消息对应的请求消息中是否存在X-Z-Ticker和Accept-Encoding：gzip；如果存在，则继续执行步骤S310；如果不存在，则转到步骤S328；

需说明的是，在步骤308之前，中间服务器可以先判断客户端的IP地址是否存在于黑名单中；如果判断出客户端的IP地址存在于黑名单中，那么将使用普通压缩方法对响应数据进行压缩处理；如果判断出客户端的IP地址不在黑名单中，再进入步骤308进行处理。

步骤S310：中间服务器继续判断是否可以对接收到的响应数据进行重复压缩处理；如果可以，则继续执行步骤S312；如果不可以，则转到步骤S330；

步骤308已经判断出存在请求消息中包含X-Z-Ticker和Accept-Encoding：gzip；

该步骤S310中继续判断是否能进行重复压缩处理，若发现目标服务器的响应数据的类型符合要求(即是否属于非图片类型数据)，且响应数据为文本(text)、js和层叠样式表单(css)且不为chunked，则判断出可以对接收到的响应数据进行重复压缩处理。

步骤S312：中间服务器获取压缩流；

步骤S314：中间服务器判断是否获取成功，如果获取成功，则继续执行步骤S316；如果不成功，则转到步骤S330；

步骤S316：中间服务器对已经传输的数据长度进行校验；

步骤S318：中间服务器判断校验是否正确；如果正确，则继续执行步骤S322；如果不正确，则转到步骤S320；

步骤S320：中间服务器释放压缩流，转到步骤S330；

步骤S322：中间服务器对接收到的应答数据进行解压缩处理；

步骤S324：中间服务器使用获取到的压缩流对响应数据进行压缩处理；

步骤S326：中间服务器存储压缩流的流标识和已传输的数据长度；

步骤S328：中间服务器向客户端返回响应消息；

其中，如果从步骤S326进入步骤S328，则该响应消息中携带有经过步骤S324压缩处理后的响应数据，流程结束；如果从步骤S330进入步骤S328，则该响应消息中携带普通压缩处理的响应数据。

步骤S330：判断是否使用普通压缩方法对响应数据进行压缩处理，如果是，则转到步骤S328；如果否，则继续执行步骤S332；

步骤S332：中间服务器创建压缩流，继续执行步骤S322。

优选地，在步骤S104，中间服务器将封装处理后的HTTP响应消息发送至客户端之后，还可以包括以下操作：

步骤S11：客户端判断封装处理后的HTTP响应消息中是否存在客户端指定的中间服务器待使用的压缩流的标识信息；

在优选实施例中，客户端接收到HTTP响应消息时，判断响应消息中是否存在应答头X-Z-Ticker和Content-Encoding：gzip；如果存在，则可以进行重复压缩处理；否则，只进行普通的解压缩处理。

步骤S12：如果存在，则客户端根据客户端指定的中间服务器待使用的压缩流的标识信息获取该压缩流，并对压缩流已经传输的响应数据的长度信息进行校验；

在优选实施例中，如果响应消息中存在压缩流的流标识并且压缩流已经传输的响应数据的长度为0，则客户端将创建压缩流对象。

步骤S13：如果校验成功，则客户端采用获取到的压缩流对响应数据进行解压缩处理；如果校验不成功，则表明当前压缩流存在异常；

步骤S14：客户端更新当前保存的已经接收到的响应数据的长度信息，其值为旧值加上当前应答的网络数据长度(HTTP应答的Content-Length或解chunked后的数据长度)。

图4是根据本发明实施例的数据压缩处理方法的客户端处理的流程图。如图4所示，该方法可以包括以下处理步骤：

步骤S402：客户端经由中间服务器向目标服务器发送请求消息，其中，该请求消息中可以携带客户端指定的中间服务器待使用的压缩流的标识信息；

步骤S404：客户端经由中间服务器接收来自于目标服务器的响应于请求消息的响应消息，并从响应消息中获取客户端待接收的响应数据，其中，中间服务器在采用与标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中。

下面结合图5对上述优选实施过程做进一步的描述。

图5是根据本发明优选实施例的客户端、中间服务器以及目标服务器使用数据压缩处理方法进行交互的系统示意图。如图5所示，在该优选实施例中，可以分为客户端未获取到一个已经使用过的压缩流和客户端已获取到一个已经使用过的压缩流两种情形。

情形一、客户端未获取到一个已经使用过的压缩流：

用户使用支持复用压缩流的浏览器(相当于上述客户端)浏览阳光农场(该阳光农场是由目标服务器提供的一种在线游戏)且提供阳光农场游戏的目标服务器的网站域名在预先设定的白名单中时，浏览器会在请求头里要求复用压缩流，即在请求头里添加x-z-ticket：0和accept-encoding：gzip这两个字段以表明需要开启一个新的压缩流。中间服务器在收到请求时会识别出此请求的发起客户端支持复用压缩流，先直接将该请求转发至目标服务器；在中间服务器收到目标服务器的响应后，分析出请求头里x-z-ticket的值为0，且accept-encoding带有gzip，这表明了客户端浏览器要求开启一个新的gzip压缩流，中间服务器开启了一个新的压缩流后，为这个压缩流分配了一个唯一的ID号00e08180fdd6：devx：10012：0并进行缓存。响应数据通过此压缩流压缩后，中间服务器在响应头部里插入x-z-ticket：00e08180fdd6：devx：10012：00和content-encoding：gzip这两个字段向客户端表明开启新流成功。x-z-ticket字段的值通过分隔为两部分，其中，前半部分为唯一的ID，后半部分表明客户端收到的经过此流压缩的数据累加长度，该数值在中间服务器和客户端都会进行保存，供检验中间服务器缓存的压缩流与客户端缓存的解压流是否同步。中间服务器将响应消息转发到浏览器，浏览器收到响应消息后先分析x-z-ticket，通过长度发现(为0)这是一个新开启的流，故对应的浏览器也开启一个的gzip解压流将响应数据解压，将此解压流跟ID号缓存下来，并维护此ID号收到的压缩数据的累加长度。

情形二、客户端已获取到一个已经使用过的压缩流：

用户使用支持复用压缩流的浏览器浏览阳光农场时，在请求头里添加x-z-ticket：00e08180fdd6：devx：10012：0512和accept-encoding：gzip这两个字段以表明复用x-z-ticket：00e08180fdd6：devx：10012这个压缩流。中间服务器同样将请求转发给目标服务器；收到响应后分析出请求头里x-z-ticket的值为00e08180fdd6：devx：10012：0512，且accept-encoding带有gzip，中间服务器获知浏览器将要复用00e08180fdd6：devx：10012对应的压缩流，校检长度正确后，使用该压缩流将响应数据进行压缩，并在头部里添加x-z-ticket：00e08180fdd6：devx：10012：0512和content-encoding：gzip这两个字段表明复用压缩流成功，最终发送响应消息给浏览器。浏览器收到响应消息后，通过分析x-z-ticket和content-encoding的值可以得知复用压缩流成功，直接使用x-z-ticket：00e08180fdd6：devx：10012对应的解压流进行解压缩处理，得到正确的响应数据。

需要说明的是，相关技术中在阳光农场游戏环境下统计到的普通gzip压缩的平均压缩率为62.90％，而在采用本发明的复用压缩流的情况下平均压缩率为79.32％，相比普通gzip压缩率节省了44.26％的网络流量。

图6是根据本发明实施例的数据压缩处理系统的结构框图。如图6所示，该系统包括：中间服务器10；中间服务器10可以包括：接收模块100，用于接收来自于目标服务器的响应于客户端发出的请求消息的响应消息，并从响应消息中获取客户端待接收的响应数据，其中，请求消息中携带有客户端指定的中间服务器待使用的压缩流的标识信息；第一处理模块102，用于在采用与标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中，并将封装处理后的响应消息发送至客户端。

采用如图6所示的系统，解决了相关技术中在客户端连续访问同一目标服务器的页面内容时，页面网络数据压缩效率较低的问题，进而提高了网络数据的压缩率、降低了网络数据的压缩时间、加快了客户端的访问速度、节省了网络流量。

优选地，如图7所示，上述系统还可以包括：客户端20；客户端20可以包括：添加模块200，用于获取压缩流的标识信息以及压缩流已经传输的响应数据的长度信息并将获取到的信息添加在请求消息中。

优选地，如图7所示，上述添加模块200可以包括：判断单元2000，用于判断当前是否存在与目标服务器对应的已经使用过的压缩流；添加单元2002，用于在判断单元输出为是时，获取已经使用过的压缩流的标识信息以及该压缩流已经传输的响应数据的长度信息，并将获取到的信息添加在请求消息中；创建单元2004，用于在判断单元输出为否时，创建压缩流，设置创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在请求消息中。

优选地，如图7所示，中间服务器10还可以包括：分配模块104，用于在对请求消息进行解析后，为创建的压缩流分配标识信息。

优选地，如图7所示，上述请求消息中还携带有压缩流已经传输的响应数据的长度信息，第一处理模块102可以包括：校验单元1020，用于获取客户端指定的压缩流，并对客户端指定的压缩流的已经传输的响应数据的长度信息进行校验；处理单元1022，用于在校验单元输出为校验成功时，则采用获取到的客户端指定的压缩流对响应数据进行压缩处理。

优选地，如图7所示，第一处理模块102还可以包括：比较单元1024，用于在校验单元输出为校验失败时，记录校验失败的次数，并与预设阈值进行比较；透传单元1026，用于在校验失败的次数超过预设阈值时，则在预设时间段内不对响应数据进行压缩处理，而直接将接收到的响应数据透传至客户端。

优选地，如图7所示，中间服务器10还可以包括：第一更新模块106，用于更新当前保存的已经接收到的响应数据的长度信息；第二更新模块108，用于更新响应消息中的长度字节，其中，该长度字节用于记录经过中间服务器压缩处理后的响应数据的长度。

优选地，如图7所示，客户端20还可以包括：判断模块202，用于判断封装处理后的响应消息中是否存在客户端指定的中间服务器待使用的压缩流的标识信息；校验模块204，用于在判断模块输出是时，根据客户端指定的中间服务器待使用的压缩流的标识信息获取该压缩流，并对压缩流已经传输的响应数据的长度信息进行校验；第二处理模块206，用于在校验单元输出为是时，则采用获取到的压缩流对响应数据进行解压缩处理；第三更新模块208，用于更新当前保存的已经接收到的响应数据的长度信息。

图8是根据本发明实施例的数据压缩处理装置的结构框图。如图8所示，该数据压缩处理装置可以包括：发送模块800，用于经由中间服务器向目标服务器发送请求消息，其中，请求消息中携带有客户端指定的中间服务器待使用的压缩流的标识信息；接收模块802，用于经由中间服务器接收来自于目标服务器的响应于请求消息的响应消息，并从响应消息中获取客户端待接收的响应数据，其中，所述响应数据是由中间服务器在采用与所述标识信息对应的由所述客户端指定的压缩流进行压缩处理后，封装在所述响应消息中，即中间服务器在采用与标识信息对应的由客户端指定的压缩流对响应数据进行压缩处理后，封装在响应消息中。

在优选实施例中，上述数据压缩处理装置可以设置在客户端。

需要说明的是，图6和图8中所示的各个模块以及各个单元之间相互作用的优选工作方式可以参见图1至图5所示的实施例，此处不再赘述。

从以上的描述中，可以看出，上述实施例实现了如下技术效果(需要说明的是这些效果是某些优选实施例可以达到的效果)：相关技术中的HTTP协议提供的压缩服务都是一次性的，即每次压缩都会开启一个新的压缩流，无法重复利用压缩字典。采用本发明提供的技术方案，可以在引入一个新的中间层服务的情况下，通过客户端的请求反复利用同一个压缩流对页面数据进行压缩，从而提高了网络数据的压缩率、降低了网络数据的压缩时间、加快了客户端的访问速度、节省了用户和集群的网络流量。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据压缩处理方法，其特征在于，包括：

中间服务器接收来自于目标服务器的响应于客户端发出的请求消息的响应消息，并从所述响应消息中获取所述客户端待接收的响应数据，其中，所述请求消息中携带有所述客户端指定的所述中间服务器待使用的压缩流的标识信息；

所述中间服务器在采用与所述标识信息对应的由所述客户端指定的压缩流对所述响应数据进行压缩处理后，封装在所述响应消息中，并将封装处理后的响应消息发送至所述客户端。

2.根据权利要求1所述的方法，其特征在于，在所述中间服务器接收来自于所述目标服务器的所述响应消息之前，还包括：所述客户端获取所述压缩流的标识信息以及所述压缩流已经传输的响应数据的长度信息并将获取到的信息添加在所述请求消息中。

3.根据权利要求2所述的方法，其特征在于，所述客户端获取所述压缩流的标识信息以及所述压缩流已经传输的响应数据的长度信息并将获取到的信息添加在所述请求消息中包括：

所述客户端判断当前是否存在与所述目标服务器对应的已经使用过的压缩流；

如果存在，则所述客户端获取所述已经使用过的压缩流的标识信息以及该压缩流已经传输的响应数据的长度信息，并将获取到的信息添加在所述请求消息中；

如果不存在，则所述客户端创建压缩流，设置所述创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在所述请求消息中。

4.根据权利要求3所述的方法，其特征在于，在所述客户端创建压缩流，设置所述创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在所述请求消息之后，还包括：

所述中间服务器在对所述请求消息进行解析后，为所述创建的压缩流分配标识信息。

5.根据权利要求1所述的方法，其特征在于，在所述中间服务器将所述封装处理后的响应消息发送至所述客户端之后，还包括：

所述中间服务器更新当前保存的已经接收到的响应数据的长度信息；

所述中间服务器更新所述响应消息中的长度字节，其中，所述长度字节用于记录经过所述中间服务器压缩处理后的响应数据的长度。

6.一种数据压缩处理系统，其特征在于，所述系统包括：中间服务器；

所述中间服务器包括：

接收模块，用于接收来自于目标服务器的响应于客户端发出的请求消息的响应消息，并从所述响应消息中获取所述客户端待接收的响应数据，其中，所述请求消息中携带有所述客户端指定的所述中间服务器待使用的压缩流的标识信息；

第一处理模块，用于在采用与所述标识信息对应的由所述客户端指定的压缩流对所述响应数据进行压缩处理后，封装在所述响应消息中，并将封装处理后的响应消息发送至所述客户端。

7.根据权利要求6所述的系统，其特征在于，所述系统还包括：所述客户端；

所述客户端包括：

添加模块，用于获取所述压缩流的标识信息以及所述压缩流已经传输的响应数据的长度信息并将获取到的信息添加在所述请求消息中。

8.根据权利要求7所述的系统，其特征在于，所述添加模块包括：

判断单元，用于判断当前是否存在与所述目标服务器对应的已经使用过的压缩流；

添加单元，用于在所述判断单元输出为是时，获取所述已经使用过的压缩流的标识信息以及该压缩流已经传输的响应数据的长度信息，并将获取到的信息添加在所述请求消息中；

创建单元，用于在所述判断单元输出为否时，创建压缩流，设置所述创建的压缩流的标识信息为空以及设置该压缩流的已经传输的响应数据的长度为0，并将设置的信息添加在所述请求消息中。

9.根据权利要求8所述的系统，其特征在于，所述中间服务器还包括：

分配模块，用于在对所述请求消息进行解析后，为所述创建的压缩流分配标识信息。

10.一种数据压缩处理装置，其特征在于，包括：

发送模块，用于经由中间服务器向目标服务器发送请求消息，其中，所述请求消息中携带有客户端指定的所述中间服务器待使用的压缩流的标识信息；

接收模块，用于经由所述中间服务器接收来自于所述目标服务器的响应于所述请求消息的响应消息，并从所述响应消息中获取响应数据，其中，所述响应数据是由中间服务器在采用与所述标识信息对应的由所述客户端指定的压缩流进行压缩处理后，封装在所述响应消息中。

Images