CN103686852B - 一种对交互数据进行处理的方法、设备及无线加速系统 - Google Patents

Abstract

本发明公开了一种对交互数据进行处理的方法、设备及无线加速系统，涉及通信技术领域，解决了现有技术中对移动网与互联网之间的交互数据处理能力较差，响应慢的技术问题。其中，该方法包括：核心交换机根据预设的上行数据的策略路由将无线分组网关发送而来的用户请求转发到无线加速系统；所述无线加速系统根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本；若确定本地没有缓存对应的响应数据副本，则通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据；所述无线加速系统将所述响应数据加速处理后发送到所述用户请求对应的客户端。本发明主要用于移动网络的数据访问处理。

Description

一种对交互数据进行处理的方法、设备及无线加速系统

技术领域

本发明涉及通信技术领域，特别涉及一种对交互数据的处理方法、设备及无线加速系统。

背景技术

目前，随着3G上网卡的普及，选择直接采用无线上网卡从移动网络接入互联网的用户越来越多。加上随着上网卡业务在中国运营商的推广，移动数据业务快速增长，数据量不断增长。

网络应用变得越来越丰富，不同类型的网络应用的通讯方式、对网络的需求各有不同，并且在这些应用中，基于Web的网络应用仍占据了主导地位。

为了解决现有技术中移动网络与互联网络之间交互数据量大，数据处理效率低下的问题，现有技术中主要的互联网网站都采用了部署基于Web缓存技术的内容分发网络（Content Delivery Network，CDN）节点的方式对其内容进行优化部署。但是该方案至少存在如下的技术问题：

这些节点的网络位置选择主要还是考虑固网宽带用户的使用，并不完全针对移动网络；而且由于不同的网站选择的CDN节点也会有差别，因此也会导致用户使用网络时，不同网站之间的响应速度差异大、数据交互能力差。

发明内容

为了解决现有技术中移动网络与互联网络之间的交互数据交互能力差、响应速度差异大的技术问题，本发明的提出一种对交互数据进行处理的方法、设备及无线加速系统。

一种对交互数据进行处理的方法，包括：

核心交换机根据预设的上行数据的策略路由将无线分组网关发送而来的用户请求转发到无线加速系统；

所述无线加速系统根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本；

若确定本地没有缓存对应的响应数据副本，则通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据；

所述无线加速系统将所述响应数据加速处理后发送到所述用户请求对应的客户端。

一种加速服务器，包括：

接收单元，用于接收核心交换机或负载均衡器转发而来的用户请求；

缓存确定单元，用于根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本；

获取单元，用于在缓存确定单元确定本地没有缓存对应的响应数据副本时，通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据；

执行单元，用于将所述响应数据加速处理后发送到所述用户请求对应的客户端。

一种无线加速系统，包括至少一个负载均衡器和至少一个加速服务器；

所述负载均衡器，用于接收核心交换机根据预设的上行数据的策略路由将无线分组网关发送而来的用户请求，并根据检测到的各个加速服务器的负载状况将所述用户请求发送到适合的加速服务器；

所述加速服务器，用于根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本；若确定本地没有缓存对应的响应数据副本，则通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据；再将所述响应数据加速处理后发送到所述用户请求对应的客户端。

本发明提供的上述方案中，通过在引入了无线加速系统，专门对移动网络与互联网之间的交互数据进行加速处理，提高移动网络与互联网之间的数据交互能力，保证了交互数据的响应效率。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例1中的一种对交互数据进行处理的方法的网络构架示意图；

图2为本发明实施例1中的一种对交互数据进行处理的方法流程图；

图3为本发明实施例2中的加速服务器的结构示意图；

图4为本发明实施例3中的一种无线加速系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。并且，以下各实施例均为本发明的可选方案，实施例的排列顺序及实施例的编号与其优选执行的顺序无关。

实施例1

根据本发明实施例提供了一种对交互数据进行处理的方法，如图1所示为该方法应用的网络构架图，包括无线分组网关（图1中的PDSN（Packet Data Serving Node，分组数据服务节点）或GGSN(Gateway GPRS Support Node，网关GPRS支持节点)）、核心交换机、互联网。其中由椭圆包起来部分，是本实施例主要的改进之处——无线加速系统，该无线加速系统有至少一个负载均衡器和至少一个加速服务器组成。为了便于系统的推广和扩展，在本实施例中，无线加速系统采用对用户完全透明的部署方式，即不需要用户在个人电脑上（客户端）做任何设置也不需要安装额外的客户端软件。在逻辑上，优选方案是无线加速系统旁挂在从PDSN或GGSN之后的核心交换机上，且是核心交换机与互联网之间偏向核心交换机的位置。

并且，为了保证需要进行数据加速的用户能够接受数据加速服务，在核心交换机上需要预设上行数据的策略路由，使得用户请求中包含的用户地址（即源IP）若匹配要加速的用户地址池的IP，则该源IP对应的数据包转发到负载均衡器上，负载均衡器将根据用户请求将用户的会话负载均衡到加速服务器上。加速服务器接收到用户发来的会话请求后，伪装成互联网网站的IP地址对请求进行处理，这样，从用户的角度上来看，自己是在跟互联网网站的服务器进行会话通信，因此加速系统对于无线上网用户来说完全透明。

对于加速服务器本地缓存有该用户请求所需要的响应数据副本的情况下，加速服务器可以直接将对应的响应数据副本返回给发送该用户请求的客户端；对于加速服务器本地没有保留缓存副本的用户请求来说，加速服务器需要代替用户向互联网网站服务器发送请求以获得未缓存内容，这时，加速服务器有两种方式向互联网网站发起请求。一种方式是将用户的源IP地址修改为加速服务器的地址，此时需要分配能够访问互联网的IP地址给该加速服务器。这样互联网网站返回到数据可以直接发到加速服务器上，这种方式要求为加速服务器分配可以访问互联网的IP地址，由于修改了源IP地址，从互联网网站的角度上看，请求来自于加速服务器，而不是无线上网用户，这种方式对用户透明，但对互联网网站不透明，称为单向透明模式；另一种方式是不修改用户请求中的源IP地址，直接利用用户的源IP地址将用户请求发送到互联网中请求的网站，同时在核心交换机上另外预设一条用于下行数据的策略路由，使得互联网返回的响应数据源地址为互联网IP，目的地址为源IP地址的数据成为加速服务器用户地址池的成员，并将该响应数据的数据包设置为负载均衡器的地址，这样可以保证互联网中请求网站返回给客户端的数据能够达到加速服务器，这种方式对用户和互联网网站来说，无线加速系统都是不存在的，称为双向透明模式。

下面，本实施例将具体以单向透明模式的实施方式为例，描述一种对交互数据进行处理的方法（双向透明模式的实施方式参照实施例2），如图2所示，包括：

步骤101，PDSN/GGSN接收到客户端发送的用户访问互联网中某请求网站的用户请求，并将该用户请求发送到核心交换机；

步骤102，核心交换机根据预设的上行数据的策略路由将该用户请求转发到无线加速系统；

核心交换机将该用户请求转发到无线加速系统的目的，是为了便于无线加速系统根据用户请求中的网址确定本地是否缓存有对应的响应数据副本，具体而言，该部分执行步骤包括如下103-105。

步骤103，无线加速系统中的负载均衡器接收到用户请求，并根据检测到的各个加速服务器的负载状况将用户请求发送到适合的加速服务器；

本实施例中，负载均衡器可以实时检测各个加速服务器的负载状况，并根据检测到的各个加速服务器的负载状况将用户请求发送到当前负载较轻的一个加速服务器处理；

优选方案中，为了减少一些不需要进行加速处理（即压缩）的数据，加速服务器接收到该用户请求后，还可以进行如下步骤104。

步骤104，无线加速系统中的加速服务器根据用户请求中的网址确定用户请求是否为动态请求，如搜索查询等。若为动态请求，则直接转发该请求到请求站点，并可以不再执行下述步骤；若不为动态请求，则执行步骤105。

动态请求在本实施例中指由第三方网站服务接收的动态的请求。考虑到动态请求属于第三方网站服务的内容，随机性太大，因此本实施例优选方案中对于这类请求的响应数据不缓存其副本，也不给予加速处理。可以在加速服务器上预存包含第三方网站URL的列表，通过查询该列表和用户请求中的网址，加速服务器可以确定该用户请求是否为动态请求。

步骤105，加速服务器根据用户请求中的网址URL确定本地是否缓存有该用户请求所请求的响应数据副本；若确定本地没有缓存对应的响应数据副本，则执行步骤106；若确定本地缓存有对应的响应数据副本，则将响应数据副本返回到核心交换机，并无需再执行下述步骤。

步骤106，加速服务器通过将用户请求发送到互联网中的请求站点进而获取到请求站点返回的响应数据。

具有而言，由于本实施例描述的是单向透明模式的实施例，所以属于核心交换机上未预设下行数据的策略路由的情况，那么通过将用户请求发送到互联网中的请求站点进而获取到请求站点返回的响应数据具体包括：

加速服务器更改用户请求中的用户地址为加速服务器的地址，再将更改后的用户请求发送到互联网中的请求站点；

请求站点接收到用户请求后按照加速服务器的地址将响应数据发送出去，进而使加速服务器接收到请求站点根据加速服务器的地址返回的响应数据。

步骤107，无线加速系统将响应数据加速处理后发送到用户请求对应的客户端。

具体而言，步骤107可通过如下方式实现：

加速服务器根据响应数据的协议格式以及当前的负载状况确定是否压缩响应数据；例如：在本实施例中对于HTTP协议格式的响应数据默认为需要压缩。此时，如果当前网络的负载状况属于预设的空闲值范围内，则无需压缩；否则在该响应数据的协议格式是HTTP的情况下，则确定需要进行压缩。

若确定压缩响应数据，则按照响应数据的格式对其进行压缩，并在压缩后，根据响应数据的格式确定是否在本地缓存响应数据的副本，并将压缩后的响应数据发送到用户请求对应的客户端；例如：在本实施例中可默认媒体流格式的响应数据需要本地缓存，则根据响应数据的格式（如文本文件，图片文件，媒体文件）选择适当的格式进行压缩后，若该响应数据是媒体文件，则本地缓存后发送到发送该用户请求的客户端；若该响应数据是文本文件，则直接发送到对应的客户端。

若确定不压缩响应数据，则根据响应数据的格式确定是否在本地缓存响应数据的副本后，将响应数据发送到核心交换机。

当然，本实施例中上述是以响应数据的协议格式是HTTP类型的为例，确定是否需要压缩的，根据实际需要也可以设置成其他或更多的协议格式；同理，上述也是以媒体流格式文件为例，确定是否需要缓存的（因为媒体流的文件大，缓存起来便于后继有同样请求时快速响应用户），根据实际需要也可以设置成其他或更多的文件格式。

本实施例中采用了对响应数据进行缓存的手段，通过在加速服务器中存储目标文件的响应数据副本，实现提供http请求访问目标的功能。一般来说，采用该技术手段有2方面的好处：一方面，从网络资源的角度来说，由于缓存过多数据不需要再从互联网网站服务器传输，因此可以节约网络出口的流量；另一方面，把缓存服务器部署在靠近用户的网络边缘节点处，可以减小网络中的延时和瓶颈点拥堵造成的传输速率下降，加快用户请求响应速度，从而提高用户的使用体验。

进一步地，本实施例中采用了对移动网络与互联网之间的交换数据进行加速/压缩的技术手段，是因为考虑到与固网宽带的充裕的网络接入资源不同，移动上网接入的无线空口处的网络资源相对紧张，因此如果能够利用数据压缩/加速将传输给用户的数据缩减，则相当于提高了空口侧的网络资源利用效率。另一方面，对于无线上网用户来说，在有限的传输速率下，要传输的数据量越小，则传输时间越短，因此，将数据进行压缩后传输给用户，可以进一步提高用户访问速度，从而提升用户体验。

在本实施例中，考虑到在绝大部分Web应用中，基本都通过http协议进行，因此主要的传输文件可以划分为3大类：文本类文件、图片类文件、媒体和应用类文件。文本类文件一般包括html、xml、txt、css、javascript等，以文字内容或者页面脚本为主；图片类文件一般包括jpg、png、gif等格式的文件，主要是一些图像和页面构图等；媒体和其他应用类是以flash、mp3为主体的媒体广告类文件。结合这3类的文件格式，本实施例步骤107里对响应据进行缩减的过程中将分析响应数据的格式（即文件格式），从而采用对应的压缩方式。

在上述3类文件中，文本文件由于采用了大量的文本数据，进行无损压缩（即不损害文件内容的前提下缩减文件的数据量）的技术相对成熟，而且得到了http协议的支持，多数浏览器可以在http协议标准内，对无损压缩过的文本文件进行解压缩操作，不影响该文件的打开，因此对文本文件可以按照现有压缩方式进行压缩；图片类文件难以进行无损压缩，而且也没有相关的http标准协议支持类似的操作，然而，对于图片文件的有损压缩技术相对成熟，在适当的牺牲一小部分图片质量的情况下，进行适度的有损压缩可以大幅度的缩减图片文件的数据量，同时对图片观感的影响很小，因此对于图片类文件采用有损压缩的方式缩减图片的数据大小；对于第三类文件的压缩则比较困难，但是可以通过url分析的方式，屏蔽掉部分广告类的文件，以减小不必要的数据传输，例如加速服务器上预设一些广告类的URL，加速服务器分析响应数据的URL，若其中包含广告类的URL，则删除该广告进而减小数据大小；或者考虑到某些广告类的媒体流都有特定的格式，因此可以将包含有该特定格式的数据包屏蔽掉，进而减少数据大小。

实施例2

本实施例将具体以双向透明模式的实施方式为例，描述一种对交互数据进行处理的方法，该方法与上述实施例1的各步骤基本相同，不同之处在于：

在步骤106中，加速服务器通过将用户请求发送到互联网中的请求站点进而获取到请求站点返回的响应数据。

具有而言，由于本实施例描述的是双向透明模式的实施例，所以属于核心交换机上预设有下行数据的策略路由的情况，那么通过将用户请求发送到互联网中的请求站点进而获取到请求站点返回的响应数据具体为：

加速服务器直接将用户请求发送到互联网中的请求站点；请求站点将响应数据发送到核心交换机；

核心交换机接收到请求站点根据用户请求中的用户地址将返回的响应数据，并根据预设的下行数据的策略路由将请求的内容发送到负载均衡器；

负载均衡器根据检测到的各个加速服务器的负载状况将用户请求发送到适合的加速服务器，即将响应数据发送到负载较轻的加速服务器上。

本实施例中用表1来表示单向透明模式和双向透明模式的异同

表1

使用双向透明模式的好处是互联网网站和用户对无线加速系统的存在完全不可知。因此，在实现这一效果时，需要在核心交换机上新增一条从互联网到客户端的用于下行数据的策略路由，此时在负载均衡器上，则表现为同时处理用户的上行和下行数据。由于多数http会话中，用户的上行数据远远小于下行数据，因此使用双向透明模式对核心交换机和负载均衡器处理能力有一定的要求。在实际部署的过程中，可以根据实际需求进行取舍。

在现行的移动网络构架体系中，所有移动上网的通讯数据，都要由GGSN或者PDSN处理，因此在GGSN或PDSN附近就近部署针对所有互联网网站的缓存服务，则可以最大限度地利用Web缓存技术的优势，进一步提高移动上网用户的访问效率。

实施例3

本实施例提供一种加速服务器，可以用于执行实施例1和实施例2中加速服务器的步骤，以帮助实现实施例1和2的方法实施。如图3所示，包括：接收单元31，缓存确定单元32，获取单元33，执行单元34。

接收单元31，用于接收核心交换机或负载均衡器转发而来的用户请求；缓存确定单元32，用于根据用户请求中的网址确定本地是否缓存有对应的响应数据副本；获取单元33，用于在缓存确定单元32确定本地没有缓存对应的响应数据副本时，通过将用户请求发送到互联网中的请求站点进而获取到请求站点返回的响应数据；执行单元34，用于将响应数据加速处理后发送到用户请求对应的客户端。

进一步地，执行单元34，还用于在缓存确定单元32确定本地缓存有对应的响应数据副本后，将响应数据副本返回到核心交换机。

优选地，获取单元33包括：

单项获取模块，用于当核心交换机上未预设下行数据的策略路由时，加速服务器更改用户请求中的用户地址为加速服务器的地址，再将更改后的用户请求发送到互联网中的请求站点，并接收到请求站点根据加速服务器的地址返回的响应数据；

双向获取单元，用于当核心交换机上预设有下行数据的策略路由时，加速服务器直接将用户请求发送到互联网中的请求站点，并接收到核心交换机或负载均衡器发送而来的响应数据。

优选地，执行单元34包括：

确定模块，用于根据响应数据的协议格式以及当前的负载状况确定是否压缩响应数据；

压缩模块，用于在确定模块确定压缩响应数据后，按照响应数据的格式对其进行压缩，并在压缩后，根据响应数据的格式确定是否在本地缓存响应数据的副本；

缓存模块，用于在确定模块确定不压缩响应数据后或者在压缩模块压缩响应数据后，根据响应数据的格式确定是否在本地缓存响应数据的副本；

发送模块，用于在压缩模块压缩响应数据后，将压缩后的响应数据发送到用户请求对应的客户端；或者在确定模块确定不压缩响应数据后，将响应数据发送到用户请求对应的客户端。

其中，确定模块，还用于根据用户请求中的网址确定用户请求不为动态请求。

本实施例提供的加速服务器可以针对移动网络与互联网网站之间的数据提供缓存服务和数据压缩服务，因此可以最大限度地对移动网络与互联网网站之间的数据进行加速，提高了响应速度，增强了通过移动网络访问互联网的交互能力。

实施例4

本实施例提供一种无线加速系统，如图4所示，包括至少一个负载均衡器41和至少一个加速服务器42；

负载均衡器41，用于接收核心交换机根据预设的上行数据的策略路由将无线分组网关发送而来的用户请求，并根据检测到的各个加速服务器的负载状况将用户请求发送到适合的加速服务器42；

加速服务器42，用于根据用户请求中的网址确定本地是否缓存有对应的响应数据副本；若确定本地没有缓存对应的响应数据副本，则通过将用户请求发送到互联网中的请求站点进而获取到请求站点返回的响应数据；再将响应数据加速处理后发送到用户请求对应的客户端。

无线加速系统部署在核心交换机旁，可以是上行方向，靠近核心交换机的位置，也可以是靠近PDSN/GGSN的位置。

具体而言，由于该加速服务器42与实施例3中的加速服务器相同，故而在此不赘述。

本发明的技术方案本质上或者说对现有技术做出贡献的部分是以软件产品的形式体现出来的功能，也即是说：本发明的装置、设备或者组成系统的各个设备其所执行的方法或实现的功能主体即便为硬件，但是实际上实现本发明上述功能的部分却是计算机软件产品的模块或单元。并且该计算机软件产品可存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台设备执行本发明各个实施例所述的方法。

以上所述，仅为本发明的具体实施方式，但本发明能有多种不同形式的具体实施方式，上文结合附图对本发明做举例说明，这并不意味着本发明所应用的具体实施方式只能局限在这些特定的具体实施方式中，本领域的技术人员应当了解，上文所提供的具体实施方式只是多种优选实施方式中的一些示例，任何体现本发明权利要求的具体实施方式均应在本发明权利要求所要求保护的范围之内；本领域的技术人员能够对上文各具体实施方式中所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换或者改进等，均应包含在本发明权利要求的保护范围之内。

Claims (10)

1.一种对交互数据进行处理的方法，其特征在于，包括：

核心交换机根据预设的上行数据的策略路由将无线分组网关发送而来的用户请求转发到无线加速系统；

所述无线加速系统根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本；

若确定本地没有缓存对应的响应数据副本，则通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据；

所述无线加速系统将所述响应数据加速处理后发送到所述用户请求对应的客户端；

其中，所述通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据具体包括：

当所述核心交换机上未预设下行数据的策略路由时，加速服务器更改所述用户请求中的用户地址为所述加速服务器的地址，再将所述更改后的用户请求发送到所述互联网中的请求站点，并接收到所述请求站点根据所述加速服务器的地址返回的响应数据；

当所述核心交换机上预设有下行数据的策略路由时，所述加速服务器直接将所述用户请求发送到所述互联网中的请求站点；

所述核心交换机接收到所述请求站点根据用户请求中的用户地址返回的响应数据，并根据预设的下行数据的策略路由将所述请求的内容发送到负载均衡器；

所述负载均衡器根据检测到的各个加速服务器的负载状况将所述用户请求发送到适合的加速服务器。

2.根据权利要求1所述的方法，其特征在于，所述无线加速系统包括至少一个负载均衡器和至少一个加速服务器；

所述无线加速系统根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本具体包括：

所述负载均衡器接收到所述用户请求，并根据检测到的各个加速服务器的负载状况将所述用户请求发送到适合的加速服务器；

所述加速服务器根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本。

3.根据权利要求1所述的方法，其特征在于，所述无线加速系统包括至少一个负载均衡器和至少一个加速服务器。

4.根据权利要求2或3所述的方法，其特征在于，所述无线加速系统将所述响应数据加速处理后发送到所述用户请求对应的客户端具体包括：

加速服务器根据所述响应数据的协议格式以及当前的负载状况确定是否压缩所述响应数据；

若确定压缩所述响应数据，则按照所述响应数据的格式对其进行压缩，并在压缩后，根据所述响应数据的格式确定是否在本地缓存所述响应数据的副本，并将所述压缩后的响应数据发送到所述用户请求对应的客户端；

若确定不压缩所述响应数据，则根据所述响应数据的格式确定是否在本地缓存所述响应数据的副本后，将所述响应数据发送到所述核心交换机。

5.根据权利要求1所述的方法，其特征在于，该方法还包括：若确定本地缓存有对应的响应数据副本，则将所述响应数据副本返回到所述核心交换机。

6.根据权利要求1至3中任意一项所述的方法，其特征在于，在核心交换机根据预设的上行数据的策略路由将无线分组网关发送而来的用户请求转发到无线加速系统之后，该方法还包括：

所述无线加速系统中的加速服务器根据所述用户请求中的网址确定所述用户请求不为动态请求。

7.一种加速服务器，其特征在于，包括：

接收单元，用于接收核心交换机或负载均衡器转发而来的用户请求；

缓存确定单元，用于根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本；

获取单元，用于在缓存确定单元确定本地没有缓存对应的响应数据副本时，通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据；

执行单元，用于将所述响应数据加速处理后发送到所述用户请求对应的客户端；

其中，所述获取单元包括：

单向获取模块，用于当核心交换机上未预设下行数据的策略路由时，所述加速服务器更改所述用户请求中的用户地址为所述加速服务器的地址，再将所述更改后的用户请求发送到所述互联网中的请求站点，并接收到所述请求站点根据所述加速服务器的地址返回的响应数据；

双向获取单元，用于当所述核心交换机上预设有下行数据的策略路由时，所述加速服务器直接将所述用户请求发送到所述互联网中的请求站点，并接收到所述核心交换机或负载均衡器发送而来的响应数据。

8.根据权利要求7所述的加速服务器，其特征在于，所述执行单元包括：

确定模块，用于根据所述响应数据的协议格式以及当前的负载状况确定是否压缩所述响应数据；

压缩模块，用于在确定模块确定压缩所述响应数据后，按照所述响应数据的格式对其进行压缩，并在压缩后，根据所述响应数据的格式确定是否在本地缓存所述响应数据的副本；

缓存模块，用于在确定模块确定不压缩所述响应数据后或者在压缩模块压缩所述响应数据后，根据所述响应数据的格式确定是否在本地缓存所述响应数据的副本；

发送模块，用于在压缩模块压缩所述响应数据后，将所述压缩后的响应数据发送到所述用户请求对应的客户端；或者在确定模块确定不压缩所述响应数据后，将所述响应数据发送到所述用户请求对应的客户端。

9.一种无线加速系统，其特征在于，包括至少一个负载均衡器和至少一个加速服务器；

所述负载均衡器，用于接收核心交换机根据预设的上行数据的策略路由将无线分组网关发送而来的用户请求，并根据检测到的各个加速服务器的负载状况将所述用户请求发送到适合的加速服务器；

所述加速服务器，用于根据所述用户请求中的网址确定本地是否缓存有对应的响应数据副本；若确定本地没有缓存对应的响应数据副本，则通过将所述用户请求发送到互联网中的请求站点进而获取到所述请求站点返回的响应数据；再将所述响应数据加速处理后发送到所述用户请求对应的客户端；

其中，所述加速服务器还包括：单向获取模块，用于当核心交换机上未预设下行数据的策略路由时，所述加速服务器更改所述用户请求中的用户地址为所述加速服务器的地址，再将所述更改后的用户请求发送到所述互联网中的请求站点，并接收到所述请求站点根据所述加速服务器的地址返回的响应数据；

双向获取单元，用于当所述核心交换机上预设有下行数据的策略路由时，所述加速服务器直接将所述用户请求发送到所述互联网中的请求站点，并接收到所述核心交换机或负载均衡器发送而来的响应数据。

10.根据权利要求9所述的系统，其特征在于，所述无线加速系统部署在所述核心交换机旁。