CN103907327B - 电信网络中的不显眼内容压缩 - Google Patents

Abstract

一种电信网络策略实施点，其能操作成路由IP数据报并且压缩支持压缩的层7协议的请求响应的IP数据报，其中每个响应数据报包括数据和限定数据的第一字节的序列号的报头。该实施点进一步包括数据报检查模块，用于根据压缩策略确定数据可压缩性。它进一步包括：数据压缩模块，用于响应于可压缩性确定来压缩数据；和报头修改模块，用于修改压缩IP数据报中的报头来考虑之前的IP数据报中的字节计数减少以确保响应中相邻压缩IP数据报之间的序列号连续性。实施点进一步包括通信模块，其能操作成将压缩IP数据报传送到第一请求端点、从第一端点接收它们的接收的确认以及响应于所述确认的接收而生成对应未压缩IP数据报的接收的确认用于由通信模块传送到第二端点。

Description

电信网络中的不显眼内容压缩

技术领域

本发明涉及在电信网络中的端点之间的双向通信中路由的IP数据报的压缩，这些IP数据报输送支持压缩的层7协议（例如HTTP/1.1）的响应（层级在开放系统互连（OSI）参考模型的意义上理解）。

背景技术

近年来移动数据计划和移动宽带（MBB）的日益流行结合例如智能电话等具有像计算机的能力的廉价终端（也泛称为“用户设备”或“UE”）的可用性已经使对电信网络的需求增加，特别从带宽容量和服务质量（QoS）方面来看。提供移动接入的电信网络的网络运营商和移动设备制造商是在力求找到满足这些日益增加的需求的技术方案那些人之中。

图1是电信网络的简化图示，该电信网络包括移动数据网络10，其可以使UE 20（例如，智能电话）经由代理服务器40连接到互联网30，使得UE 20能够下载内容并且用别的方式与连接到互联网30的web服务器50通信。

为了提高电信网络（例如在图1中示出的那个）中的带宽可用性，跨越网络的业务可以通过采用支持压缩的通信协议而减少。然而，压缩业务的决定由通信中牵涉的端点（例如，在客户端-服务器架构中充当客户端的UE 20和充当服务器的web服务器50，或在对等架构中的对等物）做出，而没有在通信中调解来影响该决定的电信数据网络的余地。

在下面的境况下，在端点之间提供数据通信以能够迫使在应用级（即层7，如在OSI参考模型的意义上理解的）处的压缩（即不必压缩完整的数据流/内容（或者，也就是说，没有隧道传输）），这对于电信网络将是可取的：

－对于已经内置对压缩的支持的协议的有效载荷业务（内容）；以及

－对于在支持压缩内容的选项时已决定不这样做的客户端和服务器（或通信对等物，视情况而定）。

遵循这些指导，可以考虑能经受有力压缩的协议。“超文本传输协议”HTTP可能是最有名的情况并且将因此在下面论述。使用HTTP作为基础的其他应用层协议（例如SOAP或XML-RPC）或基于web的服务（例如“Dropbox”或“Twitter”）在用于迫使压缩的方案中也可视为候选。

根据现今的移动业务报告，基于HTTP的业务在移动数据网络中传送的数据占据相当大比例。HTTP是在万维网中用作数据通信的基础的应用级协议。根据UE 20（或在可以使用UE 20连接到移动网络的任何其他装置中）中的哪个HTTP客户端（典型地，web浏览器）可以联系HTTP服务器（例如，web服务器50）并且请求HTTP服务器50所存储的信息中的一些或备选地对HTTP服务器50发送信息用于稍后处理，HTTP起到请求-响应协议的作用（使用客户端-服务器模型）。除其他外，对于来自web服务器50的信息的请求典型地利用HTTP GET方法，而到web服务器50的上传可使用HTTP POST或GET方法。

HTTP支持内容压缩，其理解为使端点通信来发送并且接收压缩内容以优化底层带宽资源的使用并且稍后向采用未压缩（并且等于原始）格式的互联网协议族中的上层呈现该信息的能力。更具体地，例如支持内容压缩的HTTP等协议通过限定允许端点指示它从另一个端点接收规定压缩格式的压缩内容的意愿（或偏好）所需要的控制信令以及允许端点提供它发送到另一个端点的内容是否被压缩的指示并且如果这样的话则使用压缩格式所需要的控制信令而这样做。

从而，UE 20起到HTTP客户端的作用，其实现当前版本的HTTP（即HTTP/1.1）并且愿意接受采用包含压缩、封装数据的IP数据报形式的压缩内容，在发送到web服务器50的请求中在“接受-编码（Accept-Encoding）”报头中包括命名它所支持的压缩方案的列表。例如，下面的由HTTP客户端发送的HTTP请求的“接受-编码”报头示出客户端支持“gzip”和“deflate”方案两者：

接受-编码：gzip、deflate

质量值（所谓的“q值”）可以用于表达偏好。例如，在下面示例中，客户端对“gzip”表达优于“deflate”的偏好。

接受-编码：gzip；q=1.0，deflate；q=0.5，*；q=0

如果web服务器50（或充当服务器并且接收请求的任何HTTP实体）支持HTTP客户端20所提出的压缩方案中的任一个，它可根据该方案决定压缩答复中的内容。web服务器50绝没有义务对内容进行任何压缩，并且基于它的内部配置、内部能力、网络或处理负载和/或其他因素而这样做。

如果web服务器50选择压缩内容，它将在它的响应的“内容-编码（Content-Encoding）”报头中包括使用的方案。例如，下面的示例可以用于通知HTTP客户端20内容已经使用“gzip”方案而压缩：

内容-编码：gzip

当客户端20支持压缩并且服务器50选择发送压缩内容时，HTTP内容压缩在减少HTTP的带宽使用方面很好地起作用。在该方面中，大部分的现代web浏览器（无论是在传统的个人计算机中还是在现代移动终端中实现）支持HTTP内容压缩。在RFC 2616（1999年6月，“超文本传输协议－HTTP/1.1”）中提供HTTP内容压缩的进一步的细节。

在图1的示例中，宣告支持的压缩方案取决于HTTP客户端20，并且发送压缩或未压缩的内容取决于HTTP服务器50。如上文指出的，由HTTP服务器50做出的关于是否压缩它向HTTP客户端20发送的数据的决定可取决于服务器的配置或其他内部因素（例如，处理器负载，因为压缩数据内容消耗处理资源）或可能外部因素（例如，本地网络段）。从而，一般，压缩数据内容可被HTTP客户端20接受的指示（例如，包括在由客户端20发送的HTTP请求中的“接受-编码”报头）不一定迫使HTTP服务器50用压缩数据内容答复客户端20，当客户端接收HTTP响应中的未压缩数据内容时也不在客户端20中引起错误。相反，HTTP服务器50可以根据本地策略/状态和/或通过它当前的数据（例如，数据内容的压缩在服务器50中可不被允许，或请求的数据内容可未由服务器50采用压缩格式存储并且它的处理资源可在它答复客户端的请求时过载，等）的格式来作用。

已知的内容压缩方案（例如，HTTP数据业务的压缩）具有不能被电信网络（例如，在图1中示出的移动电信网络10）以不显眼的方式实施的缺点；例如，在不使用通常称为代理（例如web代理，其是设置成在HTTP客户端与HTTP服务器之间运行的基于HTTP的数据业务中调解的服务器）的应用级中介的情况下，如将在下文论述的。

例如，因为在图1中示出的HTTP服务器50大体上将定位在拥有被HTTP客户端20使用来访问信息的电信网络10的网络运营商的网络域外部（大体上定位在互联网的另一个域中），电信网络10将不具有影响可以由HTTP服务器50做出的决定的工具，并且更准确地，由HTTP服务器50做出的关于某些数据内容是否要交付给HTTP客户端20的决定要被压缩。

在图1的示例中，可出现下面的情形：

－HTTP客户端20支持内容压缩（例如，HTTP内容压缩）；并且

－HTTP服务器50由于例如静态配置（正确或不正确的）、基于局部知识的动态决定、防止服务器使本地资源专用于压缩内容的局部过载等因素而决定不发送压缩的内容。

因此，只要终止和/或起始于附连到电信网络10的用户终端（UE）的数据流的数据包未被压缩，充当客户端来访问数据内容的UE 20所使用的电信网络10的节点（例如，在图1中图示的电信网络10的核心网络节点和无线电接入节点）的传送资源上的负载将增加。在移动数据网络10上游的电信网络部件（在图1中由“互联网30”指示）中将出现相似的问题。

可以在网络中引入Web代理（例如在图1中示出的代理服务器40）来迫使压缩。然而，标准代理服务器和透明代理两者在它们需要对客户端配置的改变（在标准web代理的情况下，其中每个客户端必须配置成使用给定代理以便有力地压缩业务）或可扰乱HTTP协议的功能性的意义上是侵入性技术。

Web代理（标准和透明两者）实现TCP连接建立的转移（拦截）。当web代理不应访问传输层（即，层4）信息时，这因为目的地IP地址和端口与目标URL之间的映射（如由客户端实现的）可不匹配代理所选择的那个而引入问题。此外，因为客户端浏览器认为它正与服务器而不是代理谈话，TCP连接建立的拦截造成面向连接的验证方案（例如NTLM）问题。与web代理的使用关联的众所周知的问题在RFC 3143（2001年6月，“已知的HTTP代理/高速缓存问题”）中阐述。

总的来说，在电信网络上交付未压缩数据内容可以使网络节点中的至少一些（例如被移动终端所利用的无线电接入资源、分组核心资源和/或电信网络的其他部件）的传送容量过载，由此减少网络容量。网络的不同段将不同地受到影响，但一般，未压缩数据的传送将总是对网络的传送资源具有负面影响。数据压缩可以帮助减轻该问题。然而，用于迫使数据压缩的已知方案（特别地牵涉代理（例如，web代理和高速缓存服务器）的使用的那些）具有许多缺点，如上文解释的。

发明内容

本发明的发明者已经设想采用不需要对通信端点（无论是客户端-服务器架构中的客户端和服务器，还使对等网络中的对等物）的配置的任何改变的优雅、不显眼方式压缩电信系统中的业务的方法，其允许在对现有的通信没有影响并且没有来自端点的任何协作的情况下压缩业务。如将在下面解释的，方法允许以动态且自动的方式提高电信网络的资源的使用，其不具有上文标识的代理服务器的使用所固有的缺点中的至少一些。

更具体地，本发明在一个方面中提供在电信网络中的第一端点与电信网络中的第二端点之间的双向通信中由策略实施点路由IP数据报并且根据数据压缩策略压缩由该第二端点传送到第一端点的响应的IP数据报的方法。每个IP数据报包括数据的字节序列和限定IP数据报中的数据的第一字节的序列号的报头。响应是层7协议的，其支持压缩，其中层级在开放系统互连OSI参考模型的意义上理解。方法包括确定由第二端点发送的IP数据报是否未被压缩但可以通过在接收的IP数据报中的至少一个中检查层7协议的控制信息（其超出IP数据报中的IP5元组而定位）而根据数据压缩策略来压缩。接收的IP数据报中的至少一些中的数据响应于确定接收的IP数据报未被压缩但可以被压缩而压缩，由此生成压缩IP数据报用于传送到第一端点。修改压缩的IP数据报中的报头来考虑由其中的数据压缩引起的一个或多个之前的IP数据报中的字节的数量中的减少以便确保在由第二端点传送到第一端点的响应中相邻压缩IP数据报之间的所述序列号的连续性。压缩的IP数据报传送到第一端点并且从第一端点接收压缩IP数据报的接收的确认。响应于所述确认的接收，生成对应未压缩IP数据报的接收的确认用于传送到第二端点。对应的未压缩IP数据报的接收的确认然后传送到第二端点。

从而，在本发明的实施例中，在所谓的用于确定由第二端点发送的IP数据报是否未被压缩但可以被压缩的“深度包检查”（DPI）之后，由策略实施点（在适当的情况下，根据压缩策略）向从第二端点路由到第一端点的IP数据报应用压缩，使得压缩内容通过端点之间的单个TCP连接而传送，其的完整性被保留。因此与在上文提到的迫使内容压缩的基于代理的方案（其中需要代理与每个端点之间的独立连接的建立并且促发了上文论述的问题）不同，没有出现端点之间TCP连接的拦截。

数据压缩过程对于端点的透明度通过i）修改压缩IP数据报中的报头来解释由其中的数据压缩引起的一个或多个之前的IP数据报中的字节数量中的减少以便确保响应中相邻压缩IP数据报之间的序列号的连续性；以及ii）将由第一端点的压缩IP数据报的接收确认转换成用于传送到第二端点的对应未压缩IP数据报的接收确认而实现。从而，来自第二端点的TCP流（其因为压缩过程而出现）内的数据的字节数量中的减少对两个端点可以隐藏。这样，数据通过端点之间的TCP连接的传递如从每个端点的角度所预期的那样行进，其中第一端点接收并且正确地确认压缩内容的字节的接收，并且第二端点传送并且接收未压缩内容的字节的接收的正确确认。TCP连接的完整性连同重传、复制和分段从而可以保留。

除上文提到的迫使压缩的基于代理的方案的缺点外，一旦获得与客户端的请求有关的总（完整）数据内容，将代理服务器（例如，web代理或高速缓存服务器）或任何其他种类的应用级中介置于端点之间的通信的数据路径中趋于在该中介必须进行数据内容高速缓存用于执行后续压缩的情况下引入额外的传送延迟。

为了减小这样的传送延迟，在本发明的实施例（其中由第二端点传送的响应包括响应报头和内容，该响应报头包括指示响应中的内容的长度的内容长度指示符）中，在接收的IP数据报中的数据可通过以下来压缩：从响应去除内容长度指示符；在接收响应的最后IP数据报之前压缩响应的接收IP数据报中的数据；以及使压缩数据编码成数据块来生成编码的压缩响应用于传送到第一端点，该编码的压缩响应包括已经应用编码的指示。压缩接收数据报中的数据的该过程避免在可以开始压缩之前等待接收完整（未被压缩）的响应或其相当大的部分的需要，由此允许响应的流压缩由路由在端点中起始和/或终止的IP数据报的流的策略实施点进行，并且被指派来对这些流实施QoS策略（如由QoS参数确定的）。这样，数据可以“在运行中（on the fly）”被压缩，其中第一端点接收块中的压缩数据。

例如，在HTTP/1.1响应的IP数据报被路由和压缩并且响应包括内容-长度报头的情况下，接收的IP数据报中的数据可通过以下来压缩：从响应去除内容-长度（Content-Length）报头；执行HTTP兼容压缩算法以在接收响应的最后IP数据报之前压缩接收IP数据报中的数据；以及对压缩数据应用成块传递编码来生成传递编码响应，其包括传递-编码（Transfer-Encoding）报头用于传送到第一端点。因为HTTP业务占据在移动网络中存在的总数据业务的相当大的百分比，HTTP/1.1业务以实现HTTP所使用的带宽中的减少这样的方式的处理可以在没有额外投入的情况下增加网络的容量，从而允许改进移动网络中的资源分配。

根据另一个方面，本发明提供电信网络策略实施点，其能操作成在电信网络中的第一端点与该电信网络中的第二端点之间采用双向通信来路由IP数据报并且能操作成根据数据压缩策略来压缩由该第二端点传送到该第一端点的响应的IP数据报。响应中的每个IP数据报包括数据的字节序列和限定IP数据报中的数据的第一字节的序列号的报头。响应是支持压缩的层7协议的，其中层级在开放系统互连OSI参考模型的意义上理解。电信网络策略实施点包括数据报检查模块，其能操作成确定从第二端点发送并且被策略实施点接收的IP数据报是否未被压缩但可以通过在接收的IP数据报中的至少一个中检查层7协议的控制信息（其超出IP数据报中的IP5元组而定位）而根据数据压缩策略来压缩。电信网络策略实施点进一步包括数据压缩模块，其能操作成响应于数据报检查模块确定接收的IP数据报未被压缩但可以压缩而压缩接收的IP数据报中的至少一些中的数据，由此生成压缩IP数据报用于传送到第一端点。电信网络策略实施点还包括：报头修改模块，其能操作成修改压缩IP数据报中的报头来考虑由数据压缩模块在其中的数据压缩所引起的一个或多个之前的IP数据报中字节数量中的减少以便确保由第二端点传送到第一端点的响应中相邻压缩IP数据报之间的所述序列号的连续性；和通信模块，其能操作成将压缩IP数据报传送到第一端点并且从其处接收压缩IP数据报的接收的确认。报头修改模块进一步能操作成响应于由通信模块接收所述确认而生成对应的未压缩IP数据报的接收的确认以由通信模块传送到第二端点。

附图说明

现在将仅通过示例的方式参考附图详细解释本发明的实施例，其中：

图1示出使移动终端连接到web服务器的常规电信网络；

图2示出根据本发明的第一实施例的电信系统，其包括策略决定点（PDP）和策略实施点（PEP）；

图3图示能够起到在图2中示出的PEP和/或PDP作用的可编程计算机硬件的示例；

图4和5是图示由在图2中示出的设备进行来进行网络业务的不显眼流压缩的处理操作的流程图；

图6总结由根据本发明的第一实施例的PEP进行的关键处理操作；

图7图示可由根据第一实施例的PEP进行的HTTP响应的流压缩；

图8示出根据本发明的第二实施例的电信系统，其包括PDP和PEP；以及

图9图示可在本发明的实施例中采用的通信协议P的某些特征。

具体实施方式

[实施例1]

图2示出根据本发明的第一实施例的电信系统100，该电信系统100包括电信网络策略实施点（PEP）100，其设置成采用在采用运行web浏览器HTTP的客户终端300（例如，智能电话）的形式的第一端点与第二端点（其采取web服务器400的形式）之间路由TCP/IP业务。该web服务器400大体上将属于远程网络域，其可以经由互联网通过电信网络的通信资源而达到。接入网络和电信网络的核心网络节点的细节以及所述电信网络与web服务器400之间的另外的网络（一个或多个）互配的细节为了简单起见而未在图2中图示。

在图2中示出的策略实施点PEP 200是网络节点，其起到路由在通信端点中起始和/或终止的数据包流的作用并且设置成为那些流实施接纳策略并且基于策略信息和QoS参数（其通常从策略决定点（PDP）500接收）对接纳的流实施QoS策略，尽管这些数据中的一些可以在PEP 200内本地配置也如此。QoS参数可以包括：例如QoS类标识符（QCI），其可以是用作PEP中的控制包转发处理的参考的标量（例如，调度权重、接纳阈值、队列管理阈值、QoS信令，等）；或分配和保留优先级（ARP），其可以包括关于包流的优先级和抢占（pre-emption）的信息（并且其可以确定例如在拥挤的情形下用于丢弃或维持包流的优先级）。PEP 200的特定示例（其将在下面描述）是在如由3GPP规范TS 23.203中描述的“PCC架构”中实现所谓的“PCEF”功能性的电信节点。

在图2中示出的PEP 200根据优选实施例是网络节点，其进一步设置成对在客户终端300中终止（或，在UE 300充当服务器的情况下，起始于客户端300）的数据流的数据包实施至少一个数据压缩策略，该策略可选地存储在PDP 500中。PEP 200和PDP 500操作地连接在一起使得存储在PDP 500中的至少一个数据压缩策略可以被PEP 200检索并且在它的操作期间被实施来压缩来自web服务器400的内容。

PEP 200的部件和它们的功能关系也在图2中示出。PEP 200包括数据报检查模块210、数据压缩模块220、通信模块230和报头修改模块240。设置成根据已知技术进行QoS实施功能性（并且可以包括例如用于包队列管理过滤和归类的模块）的PEP 200的其他部件为了简单起见而未在图2中图示。

在本实施例中，数据报检查模块210、数据压缩模块220和报头修改模块240包括可编程信号处理硬件，其实现可形成计算机程序、模块、对象或由此可执行的指令序列的至少一部分的规程。这些规则在被信号处理硬件执行时压缩并且用别的方式处理客户终端300与web服务器400之间传递的过程业务（经由通信模块210）以便提供由web服务器400在客户终端300的请求时发送到客户终端300的内容的不显眼和透明压缩，如将在下面解释的。

其中可实现PEP 200的通用种类的可编程信号处理设备的示例在图3中示出。示出的信号处理设备600除通信模块230外还包括处理器610、工作存储器620和存储计算机可读指令的指令存储630，该计算机可读指令在被处理器610执行时促使处理器610在进行下文描述的处理操作来处理客户终端300与web服务器400之间的通信中的包并且以便以高效且不显眼的方式进行由web服务器400提供的内容的流压缩方面起到PEP 200的作用。

指令存储630是数据存储装置，该数据存储装置可包括例如采用ROM、磁性计算机存储装置（例如，硬盘）或光盘形式的非易失性存储器，其可预先加载有计算机可读指令。备选地，指令存储630可包括易失性存储器（例如，DRAM或SRAM），并且计算机可读指令可以例如计算机可读存储介质640（例如光盘，例如CD-ROM、DVD-ROM，等）或携带计算机可读指令的计算机可读信号650等计算机程序产品输入到此。

工作存储器620起到暂时存储数据来支持根据存储在指令存储630中存储的处理逻辑而执行的处理操作的作用。如在图3中示出的，通信模块230设置成与处理器610通信以便致使信号处理设备600能够处理接收的信号并且传达它的处理结果。

处理器610、工作存储器620和指令存储630（在适当地由本领域内技术人员所熟知的技术编程时）在一起的组合660构成在图2中示出的PEP 200的数据报检查模块210、数据压缩模块220和报头修改模块240。组合660还进行在本文描述的PEP 200的其他操作。

在本实施例中，PDP 500是有权做出关于在附连到电信网络的客户终端300中终止和/或起始于它的数据流的数据包并且要由路由数据包的PEP 200实施的策略决定的网络节点。在本实施例中，PDP 500作为独立于PEP 200的网络节点（例如设置成经由任何适合的工具（例如，LAN或互联网）而与实现PEP 200的服务器通信的独立服务器）的部分而提供。然而，PDP 500的功能可备选地或另外由PEP 200的硬件提供；例如，一个或多个数据压缩策略可存储在图3中示出的信号处理设备的指令存储640中。

由本实施例的PEP 200进行来处理流数据的操作将参考图4和5描述。

首先参考图4，在步骤S10中，客户终端300建立到web服务器400的TCP连接并且向web服务器400发送HTTP请求，从而请求web服务器400向客户终端300发送某些请求内容（例如，与存储在服务器400中的特定URL关联的内容）。PEP 200将HTTP请求路由到web服务器400。

在步骤S20中，PEP 200的数据报检查模块210进行DPI来确定客户终端的请求是否符合支持作为可选特征的内容压缩的适合通信协议。在本实施例中，HTTP/1.1被视为这样的协议的示例。如果请求在步骤S20中确定为不是HTTP/1.1请求，则PEP 200确定它将不压缩对于请求的任何响应的内容，并且在客户端300与服务器400之间流动的数据包通过未更改的PEP 200而行进，从而绕过它的压缩机构。

PEP 200进行DPI以通过在接收的IP数据报中的至少一个中检查层7协议的控制信息（其超出IP数据报中的IP 5元组而定位）来识别通信协议。在利用互联网协议作为用于数据传送的网络（间）-级协议的数据通信中，已知IP 5元组包括：源传输端口（即，关于源的OSI层4信息）、源IP地址（即，关于源的OSI层3信息）、目的地传输端口（即，关于目的地的OSI层4信息）、目的地IP地址（即，关于目的地的OSI层3信息）和通过IP协议（例如，TCP、UDP，等）的协议的标识符。这些信息元素定位在IP数据报的开始处。本质上，DPI包括检查并且分析超出那些信息元素的IP数据报的内容，即包括对应于在IP数据报内输送的上层通信层的有效载荷。

另一方面，如果数据报检查模块210在步骤S20中确定请求是HTTP/1.1请求，过程行进到步骤S40，其中数据报检查模块210确定客户终端300是否支持内容压缩。如果客户终端300已经向web服务器400指示它接受HTTP请求中的接受-编码报头中的压缩内容的意愿，有力压缩对于客户终端300确定为可接受的，否则过程行进到步骤S30并且绕过PEP 200的压缩机构。

在步骤S50中，web服务器400接收HTTP请求并且通过朝客户终端300发送包含请求内容的HTTP响应而作出响应。

然后，在步骤S60中，朝客户终端300路由HTTP响应的PEP 200对HTTP响应的一个或多个IP数据报进行DPI。更具体地，数据报检查模块210确定HTTP响应的IP数据报（其已经由web服务器400发送并且由PEP 200的通信模块230接收）未被压缩但可以根据存储在PDP500中的至少一个数据压缩策略来压缩。为了做出该确定，数据报检查模块210采用DPI技术来检查HTTP控制信息，其超出IP数据报中的IP 5元组而定位。特别地，HTTP内容-类型（Content-Type）报头的值连同内容-编码报头在响应中的缺乏可以用于识别未压缩内容。在步骤S60中，数据报检查模块210还检查IP数据报中的内容-类型报头并且做出被指示的内容类型（例如，text/html、text/javascript、text/css，等）的记录。

如果HTTP响应的内容在步骤S60中确定为不适合于压缩，过程行进到步骤S30并且绕过PEP 200的压缩机构，否则过程继续到步骤S70。

在步骤S70中，数据报检查模块210在步骤S60中识别的内容类型的基础上确定由web服务器400交付的内容是否应被PEP 200压缩。如果确定内容不应被压缩，则过程行进到步骤S30并且绕过PEP 200的压缩机构，否则数据报检查模块210在步骤S80中确定PEP 200配置成应用的压缩方法是否被客户终端300支持。如果配置的压缩方法与客户端300兼容，则web服务器的响应的流压缩在步骤S90中进行，否则过程行进到步骤S30并且绕过PEP 200的压缩机构。

在本实施例中，步骤S70和S80中的确定由数据报检查模块210根据存储在PDP 500中的一个或多个压缩策略做出，该一个或多个压缩策略可以从PDP 500传送到PEP 200，或可以在PEP 200中本地配置。数据压缩策略可基于客户终端300的记录，其已经在对web服务器400的请求中包括客户终端300能够对压缩的IP数据报解压缩来提取其中的数据的指示。

另外或备选地，数据压缩策略可基于存储的与客户终端300关联的简档数据或它的标识符中的任一个，其可以指示客户终端300是否能够对压缩的IP数据报解压缩来提取其中的数据或起初未被压缩的内容是否要对于所述终端压缩。在该情况下，可询问PDP 500来确定与客户终端300有关的简档数据（例如，基于由所述客户端提交的标识符，其由电信网络中的节点与对应的简档数据有关地存储，并且其可以确定在识别的客户端中起始或终止的数据流的某些处理）是否指示客户终端300根据所述简档中的数据而能够对压缩的IP数据报解压缩，或起初未被压缩的内容是否要被压缩。

除上文的选项中的任一个或两个外或作为其的另外备选方案，数据压缩策略可基于限定允许接收IP数据报包含的数据的类型的信息。

在本实施例中，步骤S70和S80中的确定由数据报检查模块210参考存储在PDP 500中的压缩策略表而做出，该压缩策略表形成PEP的部分（尽管PDP 500可备选地是PEP 200外部但可被PEP 200访问的外部网络节点，如上文指出的）。在做出的步骤S70和S80中的确定的基础上，表中的信息包括（除其他信息外）客户终端300是否接受压缩内容、起初由web服务器400交付的内容的类型的指示、起初由web服务器400交付的内容是否已经被压缩以及要应用于内容的压缩技术（如有的话）的指示。

例如，在本实施例中，策略表基于内容-类型、内容-编码和传递-编码报头，如在下页的表1中示出的（可由PDP 500存储的与端点有关联的其他简档数据为了清楚起见而被省略）。

表1

该压缩策略表可以在PEP 200中凭借本地配置而引入。响应中的初始内容-类型报头的定义可以包含通配符（*）来表达“任何事物”并且大体上来避免必须规定对于压缩不是必需的信息，例如字符集。这样，下面的内容-类型：

内容类型：text/html*

应匹配这两个内容-类型报头：

内容-类型：text/html；字符集=utf-8

内容-类型：text/html；字符集=iso-8859-2

从而，本实施例的PEP 200能够实现DPI技术来识别HTTP响应，其中：没有内容-编码报头；内容-类型报头匹配上文的表中的一个；以及之前（匹配）的请求包含接受-编码报头，其支持在表中包括的压缩算法。

再次参考图4，在步骤S90中，数据压缩模块220响应于数据报检查模块210确定接收的IP数据报未被压缩但可以根据PDP 500中的压缩策略来压缩而压缩接收的IP数据报中的数据，由此生成压缩的IP数据报用于由通信模块230传送到客户终端300。在本实施例中，PEP 200使用HTTP传递编码以“在运行中”压缩内容，即，在可以开始压缩之前不必等待接收整个HTTP响应的情况下。通过这样应用流压缩，内容的高速缓存和接着的内容由PEP 200的传送中的延迟可以被避免。另外，因为不需要在缓冲内容压缩之前对它分配额外的存储资源，本实施例的PEP 200对硬件资源的要求比上文提到的基于常规代理的技术方案要更低。

数据压缩如何由数据压缩模块220进行的细节现在将参考图5中的流程图来描述。

图5图示PEP 200进行成块传递编码和流压缩来压缩HTTP响应（其由web服务器300发送并且针对客户终端300）的内容所凭借的过程。使用传递编码（标准HTTP传送机制）允许PEP 200“在运行中”压缩内容，即，在不等待所有内容到达并且事先不知道内容的总长度的情况下。

成块传递编码是HTTP/1.1中的数据传递机制，其中“传递-编码”报头代替“内容-长度（Content-Length）”报头来使用并且允许内容成块交付。未使用内容-长度报头，并且因为此，web服务器400在开始交付之前不需要知道内容的总长度。成块传递编码可以用于例如在知道内容的总大小之前传送具有动态生成的内容的响应。成块HTTP传送的进一步的细节在RFC 2616（1999年6月，“超文本传输协议－HTTP/1.1”）中提供。

在图5中的步骤S100中，形成服务器的响应的部分的内容长度指示符（其在本实施例中采取HTTP服务器400的HTTP响应的内容-长度报头的形式）由数据压缩模块220从响应去除。

然后，在步骤S110中，在响应的最后IP数据报被PEP 200接收之前，数据压缩模块220采用流压缩算法以 “在运行中”压缩从web服务器的响应的接收IP数据报提取的数据。流压缩算法由它们不必访问完整内容以便压缩它这一事实来表征。这因为HTTP响应中的内容将作为流到达PEP 200而是有利的。数据压缩模块220可利用任何适合的压缩算法，其可以根据用户要求来选择。标准化“deflate”压缩方案是一个众所周知的示例。关于该算法的更多信息可以在RFC 1950（1996年5月，“ZLIB压缩的数据格式规范版本3.3”）中找到。

在步骤S120中，数据压缩模块220将压缩数据编码成数据块来生成编码的压缩响应用于由通信模块230传送到客户终端300，该编码的压缩响应包括已经应用编码的指示。更特定地，在本实施例中，数据压缩模块220对压缩数据应用成块传递编码来生成传递编码响应（其包括传递编码报头），并且将编码响应转发到通信模块230用于传送到客户终端300。

传递-编码报头由数据压缩模块220根据在上文的表1中提供（并且从本地配置建立）的指示来插入。传递-编码报头的值包含使用的流压缩算法和总是设置成“成块”的传送机制。注意规定压缩算法和传送机制所采用的顺序有关系，并且指示进行这些变换所采用的顺序。在本实施例中，压缩应指示为已经首先被进行，从而留下作为最后的变换的“成块”。因为包含传递-编码报头的HTTP响应不需要内容-长度，内容-长度报头应被去除，以便不到达客户终端400。在该方面，注意上文提到的在步骤S100中内容-长度报头的去除可备选地在步骤S110之后或在步骤S120之后进行（假定内容-长度报头在编码之前被去除），压缩的响应在步骤S130中发送到客户终端。

从而，对于包含HTTP响应的部分的每一个TCP段，PEP 200根据在传递-编码中配置的流压缩算法来压缩内容并且将它作为HTTP“块”发送到客户终端300。HTTP块以它们的大小开始、后跟编码内容并且以回车和换行（CRLF）结束。传送的结束由具有大小零的最后“块”指示。

在步骤S130中，报头修改模块240修改每个压缩IP数据报中的报头以便补偿由其中的数据压缩引起的一个或多个之前的IP数据报中的字节数量中的减少，由此确保HTTP响应中相邻压缩IP数据报之间的所述序列号的连续性。在该上下文中，“连续性”指在给定数据报中的数据的最后字节的序列号与接着的数据报中的数据的第一字节的序列号之间没有介入的整数。作为示例，如果由PEP 200接收的未压缩IP数据报在它的报头的序列号字段中具有数字“n”并且包含数据的M个字节，并且下一个要接收的未压缩IP数据报具有“n+M”作为它的报头中的序列号，并且如果这些数据报中的第一个的有效载荷由PEP 200压缩以便仅包含m个字节（其中m<n），则报头修改模块240将使在第二（接着的）数据报中指示的序列号从“n+M”减小至“n+m”，来解释由压缩处理引起的字节数量从M到m的减少。

在步骤S140中，通信模块230将压缩IP数据报（携带压缩“块”）传送到客户终端300。在接收压缩的IP数据报时，客户终端300根据TCP协议确认每个压缩数据报中的字节的接收。更具体地，客户终端300使用规定客户终端300预期接收的下一个TCP序列号的TCP“ACK”来确认接收。这些确认然后由PEP 200的通信模块230接收。

因为压缩机制在应用级（HTTP）处改变服务器答复中的数据的长度，如上文解释的，底层TCP连接中的TCP确认也应采用对应的方式对于底层TCP连接的剩余部分校正，来做出对于HTTP客户端300和HTTP服务器400透明的改变。

由于该原因，在由通信模块230从客户终端300接收确认时，报头修改模块240在步骤S150中生成对应未压缩IP数据报的接收的TCP确认用于传送到web服务器400。这通过增加在客户终端的确认中规定的确认号来补偿由PEP 200进行的内容压缩所引起的段中字节数量中的减少而实行。报头修改模块240还进行“校验和”TCP字段的相应修改，其需要在修改TCP报头和HTTP应用数据后重新计算。校正序列号、确认号和校验和TCP字段的过程持续直到关闭底层TCP连接。这在完成当前响应后可能不发生，并且其他响应可到达相同的TCP连接（如果例如启用流水线技术的话）。TCP序列号重整是已知的规程并且在其他技术中（例如在内容充实中）使用。

在步骤S160中，通信模块230将对应未压缩IP数据报的接收的确认传送到web服务器400。

然后，在步骤S170中，PEP 200检查要在步骤S110至S160中处理的最新IP数据报（一个或多个）是否是来自web服务器400的响应的最后部分。如果否的话，步骤S110至S160的执行持续直到完成服务器的响应的处理。在完成压缩过程时，PEP 200在步骤S180中通过向客户终端300发送具有大小零的最后“块”而将压缩内容的传送的结束信号传递到客户终端300。

从而，在本实施例中，来自服务器400的HTTP响应的数据报的有效载荷被PEP 200压缩，而它们的TCP报头中的序列号以及由客户端300提供的确认号由PEP 200的报头修改模块240修改来确保由PEP 200进行的流压缩的透明度。携带HTTP响应的数据报的数量在本实施例中未被PEP 200改变。在备选实施例中，可以采用数据报argupation使得例如在两个未压缩数据报一起到达PEP 200的情况下，PEP 200仅生成一个压缩数据报用于传送到客户终端300。

总的来说，PEP 200配置成进行在图6中示出的关键处理步骤。从而，在步骤S200中，数据报检查模块210确定从第二端点（即，web服务器400）发送并且被PEP 200接收的IP数据报是否未被压缩但可以通过在接收的IP数据报中的至少一个中检查层7协议（即，在本实施例中的HTTP/1.1）的控制信息（其超出IP数据报中的IP 5元组而定位）而根据数据压缩策略来压缩。

在步骤S210中，数据压缩模块220响应于数据报检查模块210确定接收的IP数据报未被压缩但可以被压缩而压缩接收的IP数据报中的至少一些中的数据，由此生成压缩IP数据报用于传送到第一端点（即，客户终端300）。

在步骤S220中，报头修改模块240修改压缩IP数据报中的报头来考虑由其中的数据压缩引起的一个或多个之前的IP数据报中字节数量中的减少以便确保由第二端点400传送到第一端点300的响应中相邻压缩IP数据报之间的所述序列号的连续性。

在步骤S230中，通信模块230将压缩IP数据报传送到第一端点300并且从其处接收压缩IP数据报接收的确认。

然后，在步骤S240中，报头修改模块240响应于所述确认由通信模块230的接收而生成对应未压缩IP数据报的接收的确认用于由通信模块230传送到第二端点400。

最后，在步骤S250中，通信模块230将对应的未压缩IP数据报的接收的确认传送到第二端点400。

上文描述的用于进行内容的流压缩的压缩技术的应用现在将参考图7描述。

在步骤1中，HTTP客户端300使用具有至少下面的报头的HTTP GET来请求一些内容：

接受-编码：deflate

在步骤2中，服务器400用具有下面的相关报头的200 OK响应作出响应：

内容-类型：text/css

内容-长度：4729

（并且不包含内容-编码报头）。

步骤2中的响应的第一TCP段包含未压缩体中的一些，其具有小于内容-长度中的值或等于其（如果所有内容适合段的话）的长度。例如，第一TCP段中的主体可如下：

主体中的未压缩文本的示例

如果客户终端300和/或web服务器400在PEP 200中（或在PDP 500中，在该情况下PEP必须首先询问PDP）配置成具有为该流启用的HTTP有利压缩并且配置的压缩算法在步骤1中的由客户终端300发送的请求的接受-编码报头中受到支持，PEP 200对响应应用压缩。新的响应（在步骤3中）将具有下面的HTTP报头：

内容-类型：text/css

传递-编码：deflate；成块

内容-类型报头未被修改（实体不改变；PEP 200仅对消息应用变换）并且内容-长度报头被去除。

步骤2中的可用主体使用配置的算法（deflate）来压缩并且在步骤3中作为“块”而发送：

07

0A 7F 37 7A 37 58 E2，

其以“块”的长度（07）开始，后跟压缩主体（“主体中未压缩文本的示例”的压缩版本）并且以CRLF结束。

对于步骤4和6的过程在步骤5和7中重复。在步骤6中，PEP 200检测到服务器400已经发送内容中的全部。PEP 200维持记录接收的字节数量的计数器，并且当该计数器达到内容-长度的起始值时，发送具有长度零的最后的“块”来通知客户端300事务的结束（步骤7）。另外，TCP校验和在修改TCP报头和HTTP应用数据后由PEP 200重新计算。由于由PEP 200实现的压缩在插入、修改或删除所有相关HTTP报头后减少数据的长度，（3）的TCP序列号因此通过PEP 200减少。

在步骤3与5之间从HTTP客户端300到HTTP服务器400的TCP确认（未在图7中示出，因为消息没有主体）由PEP 200以朝着HTTP服务器400的正确确认号修改，该HTTP服务器400将未意识到对内容引入的变换。PEP 200（具体地，其的报头修改模块220）通过确认由HTTP服务器400传送的对应未压缩包的接收而对此补偿。

校正序列号和确认号（以及TCP校验和）的过程持续直到关闭TCP连接。这在完成当前响应后可能不发生，并且其他响应可到达相同的TCP连接（如果例如启用流水线技术的话）。

[实施例2]

根据本发明的第二实施例包括网络策略实施点的电信系统现在将参考图8描述。

在本实施例中，客户终端所附连并且对它提供朝例如定位在另一个网络域中的服务器的数据连接性服务的电信网络包括如由3GPP规范TS 23.203（2011年6月，“策略和计费控制架构”v. 11.2.0）公开的架构（称为“策略和计费控制”PCC架构）的节点，其中在图2中图示的PEP 200和PDP 500分别由在所述PCC架构电信网络内作为“策略和计费实施功能”（PCEF）2000和“策略和计费规则功能”（PCRF）5000而进行的节点实现。在图8中实现PCEF功能性的节点还通过使用例如DPI而提供所谓的“业务检测功能”（TDF）功能性。

在根据PCC架构的电信网络中，有力的压缩由PCEF 2000对通过它而路由的数据包的未压缩内容进行。例如，如果电信网络包括GPRS，则所述网络的PCC兼容架构的PCEF 2000功能性可以由网关GPRS支持节点（GGSN）实现；因此，在该实施例中，上文描述的有力压缩可以对通过GGSN的所谓的“Gi”和“Gn”接口而接收和/或发送的数据流的数据包进行。

确定是否有力压缩未压缩内容的策略信息可以本地配置或对于一些订户（或他们中的全部）或对于他们接收的业务的子集（或对于它中的全部）而经由所谓的“Gx”接口从PCRF 5000下载。

PEP 200和PDP 500采用PCC架构电信网络的PCEF 2000和PCRF 5000的相应形式的实现提供以最小影响使不显眼的内容压缩方案（这通过第一实施例的方式在上文描述）扩展到现有技术的电信网络（例如由例如3GPP规范TS 23.203 V11.2.0所公开的）的另外的优势，其中未设想web代理或高速缓存服务器或相似功能节点的存在。特别地，PCEF 2000在PCC架构中的功能性在3GPP规范TS 23.203中描述，并且更具体地，在所述文献的章节6.2.2中描述。PCEF作为策略实施点（PEP）在例如它的介入不必在端点内配置的意义上并且因为PCEF未起到隐藏端点的特性的作用但根据已知技术对它的相关数据流实施接纳和QoS策略而对于它路由它的数据包流所针对的通信端点是透明的，这从所述公开是明显的。

此外，本实施例具有允许网络运营商基于他们自身的需要和要求而迫使内容压缩的优势，而不管由web服务器发送的内容的格式如何。该技术方案允许对有力压缩的动态改变（经由例如Gx接口），从而允许运营商使HTTP所使用的带宽适应于网络条件（按需压缩）。

PCEF 2000可本地配置成限定需要（例如，根据上文的表1）的变换（压缩）。然而，HTTP服务（URL或URL集）和应用有力压缩的订户可以本地配置或从PCRF 5000（其起到PDP的作用）下载。

下面提供可如何配置变换的示例：

规则“COMPRESS-HTML”使用“deflate”压缩来压缩HTML或CSS内容。

需要的变换可以对所有HTTP业务或对HTTP服务集配置。这可以应用于所有订户或订户的子集。PREF 2000可以本地配置成以需要的粒度应用有力压缩。

备选地，实现PDP的PCRF 5000可以使用例如PCEF 2000与PCRF 5000之间的Gx接口（或其他）下载每订户会话的有力压缩策略（或对那些策略的指针）。如果Gx接口扩展来下载该信息，它应优选地优先于由PCEF 2000存储的本地配置策略。

在本实施例中，枚举且未加密类型的新的AVP（内容-压缩-简档-Id（Content-Compression-Profile-Id））用于下载对在PCEF 2000中本地配置的有力压缩策略的指针。PCRF 5000能操作成通过指向包含不同的有力压缩规则集的简档而控制应用哪些策略（如有的话）。

指示未配置的简档的简档指针可用于启用默认简档（其可包含或可不包含内容压缩规则）。

[修改和变化]

可以对上文描述的实施例做出许多修改和变化。

例如，图4和5中的流程图中的过程步骤的排序可采用任何适合且可取的方式改变。从而，在图4中，步骤S20和S40可如例如步骤S70和S80那样互换。

尽管上文描述的实施例的端点使用HTTP/1.1来共享内容，可备选地使用另一个应用协议“IP”（假定它满足将在下文解释的某些标准）。

图9示意地描绘使用具有某些特性的通用应用协议“P”在端点A与端点B之间的数据通信（在所述端到端通信中调解的节点为了简单起见而未在图9中示出）。

给出通用协议P（其遵循客户端-服务器架构），其中A是客户端并且B是服务器，上文描述的数据压缩方法可使用符合下面的标准的任何协议P来实现：

i）协议P支持作为可选特征的内容的压缩，使得内容压缩并不总是对于协议P启用；

ii）客户端A和服务器B可以通过交换消息（1’）和（2’）（其对于该特定通信不一定是在A与B之间交换的第一和第二消息）而协商内容压缩；以及

iii）如果A与B之间的协商在启用内容压缩方面是成功的，（3’）中交换的内容被压缩。

在上文描述的实施例中，在图2中示出的PEP 200的数据报检查模块210、数据压缩模块220、通信模块230和报头修改模块240每个使用可编程处理设备600来提供，该可编程处理设备600通过执行存储在指令存储640中的软件指令而提供这些部件的相应功能。然而，将意识到前面提到的部件中的一个或多个可备选地在专用于进行这些一个或多个部件（例如，ASIC或FPGA）的功能（一个或多个）的不可编程硬件中实现。

Claims (15)

1.一种电信网络策略实施点（200；2000），其能操作成在电信网络中的第一端点（300）与所述电信网络中的第二端点（400）之间的双向通信中路由IP数据报并且能操作成根据数据压缩策略来压缩由所述第二端点（400）传送到所述第一端点（300）的响应的IP数据报，每个IP数据报包括数据的字节序列和限定所述IP数据报中的数据的第一字节的序列号的报头，所述响应是支持压缩的层7协议的，其中层级在开放系统互连OSI参考模型的意义上理解，所述电信网络策略实施点（200；2000）包括：

数据报检查模块（210），其能操作成通过在接收的IP数据报中的至少一个中检查所述层7协议的控制信息来确定从所述第二端点（400）发送并且被所述策略实施点（200；2000）接收的IP数据报是否未被压缩但能根据所述数据压缩策略来压缩，所述控制信息超出IP数据报中的IP5元组而定位；

数据压缩模块（220），其能操作成响应于所述数据报检查模块（210）确定接收的IP数据报未被压缩但能压缩而压缩接收的IP数据报中的至少一些中的数据，由此生成压缩IP数据报用于传送到所述第一端点（300）；

报头修改模块（240），其能操作成修改压缩IP数据报中的报头来考虑由所述数据压缩模块（220）对在其中的数据压缩所引起的一个或多个之前的IP数据报中字节数量中的减少以便确保由所述第二端点（400）传送到所述第一端点（300）的响应中的相邻压缩IP数据报之间的所述序列号的连续性；和

通信模块（230），其能操作成将压缩IP数据报传送到所述第一端点（300）并且从其处接收所述压缩IP数据报的接收的确认，

其中所述报头修改模块（240）进一步能操作成响应于由所述通信模块（230）接收所述确认而生成对应的未压缩IP数据报的接收的确认以由所述通信模块传送到所述第二端点（400）。

2.如权利要求1所述的电信网络策略实施点，其中由所述第二端点（400）传送到所述第一端点（300）的所述响应包括响应报头和内容，并且所述响应报头包括指示所述响应中的内容的长度的内容长度指示符，并且其中所述数据压缩模块（220）进一步能操作成：

从所述响应去除所述内容长度指示符；

在由所述电信网络策略实施点（200；2000）接收所述响应的最后IP数据报之前压缩所述响应的接收IP数据报中的数据；以及

使压缩数据编码成数据块来生成编码的压缩响应用于由所述通信模块（230）传送到所述第一端点（300），所述编码的压缩响应包括已经应用编码的指示。

3.如权利要求1或2所述的电信网络策略实施点，其能操作成路由并且压缩HTTP/1.1响应的IP数据报，其中由所述第二端点（400）传送到所述第一端点（300）的所述响应包括内容-长度报头，并且其中所述数据压缩模块（220）能操作成：

从所述响应去除所述内容-长度报头；

执行HTTP兼容压缩算法以在由所述电信网络策略实施点（200；2000）接收所述响应的最后IP数据报之前压缩接收的IP数据报中的数据；以及

对压缩数据应用成块传递编码来生成传递编码响应，所述传递编码响应包括传递-编码报头用于传送到所述第一端点（300）。

4.如权利要求1或2所述的电信网络策略实施点，其中所述数据压缩策略基于以下中的至少一个：

所述第一端点（300）使所述第一端点（300）能够对压缩IP数据报解压缩以提取其中的数据的指示包括在对所述第二端点（400）的请求中的记录；

指示所述第一端点（300）能够对压缩IP数据报解压缩以提取其中的数据或指示要传送到所述第一端点（300）的起初未被压缩的IP数据能被压缩的所述第一端点的存储简档数据；以及

限定允许接收的IP数据报包含的数据的类型的信息。

5.一种策略和计费控制PCC架构电信网络的策略和计费实施功能PCEF节点（2000），其包括如上述权利要求中任一项实施的电信网络策略实施点（200），其中所述PCEF节点（2000）能操作成经由Gx接口与策略和计费规则功能PCRF节点（5000）通信来获得数据压缩策略。

6.一种在电信网络中的第一端点（300）与所述电信网络中的第二端点（400）之间的双向通信中由策略实施点（200，2000）路由IP数据报并且根据数据压缩策略压缩由所述第二端点（400）传送到所述第一端点（300）的响应的IP数据报的方法，每个IP数据报包括数据的字节序列和限定所述IP数据报中的数据的第一字节的序列号的报头，所述响应是支持压缩的层7协议，其中层级在开放系统互连OSI参考模型的意义上理解，所述方法包括：

通过在接收的IP数据报中的至少一个中检查所述层7协议的控制信息来确定（S60；S200）由所述第二端点（400）发送的IP数据报是否未被压缩但能根据所述数据压缩策略来压缩，所述控制信息超出所述IP数据报中的IP5元组而定位；

响应于确定接收的IP数据报未被压缩但能被压缩来压缩（S110；S210）所述接收的IP数据报中的至少一些中的数据，由此生成压缩IP数据报用于传送到所述第一端点（300）；

修改（S130；S220）压缩的IP数据报中的报头来考虑其中的数据压缩所引起的一个或多个之前的IP数据报中的字节的数量中的减少以便确保在由所述第二端点（400）传送到所述第一端点（300）的响应中的相邻压缩IP数据报之间的所述序列号的连续性；

将所述压缩的IP数据报传送（S140；S230）到所述第一端点（300）并且从其处接收所述压缩IP数据报的接收的确认；

响应于所述确认的接收，生成（S150；S240）对应的未压缩IP数据报的接收的确认用于传送到所述第二端点（400）；以及

将所述对应的未压缩IP数据报的接收的确认传送（S160；S250）到所述第二端点（400）。

7.如权利要求6所述的方法，其中由所述第二端点（400）传送到所述第一端点（300）的所述响应包括响应报头和内容，并且所述响应报头包括指示所述响应中的内容的长度的内容长度指示符，并且其中接收的IP数据报中的数据通过以下来压缩：

从所述响应去除（S100）所述内容长度指示符；

在接收所述响应的最后IP数据报之前压缩（S110）所述响应的接收IP数据报中的数据；以及

使压缩数据编码（S120）成数据块来生成编码的压缩响应用于传送到所述第一端点（300），所述编码的压缩响应包括已经应用编码的指示。

8.如权利要求6或7所述的方法，其中HTTP/1.1响应的IP数据报被路由和压缩，其中由所述第二端点（400）传送到所述第一端点（300）的所述响应包括内容-长度报头，并且其中所述接收的IP数据报中的数据通过以下来压缩：

从所述响应去除（S100）所述内容-长度报头；

执行HTTP兼容压缩算法以在接收所述响应的最后IP数据报之前压缩（S110）所述接收的IP数据报中的数据；以及

对压缩数据应用成块传递编码（S120）来生成传递编码响应，所述传递编码响应包括传递-编码报头用于传送到所述第一端点（300）。

9.如权利要求6-7中任一项所述的方法，其中所述数据压缩策略基于以下中的至少一个：

所述第一端点（300）使所述第一端点（300）能够对压缩IP数据报解压缩以提取其中的数据的指示包括在对所述第二端点（400）的请求中的记录；

指示所述第一端点（300）能够对压缩IP数据报解压缩以提取其中的数据或指示要传送到所述第一端点（300）的起初未被压缩的IP数据能被压缩的所述第一端点（300）的存储简档数据；以及

限定允许接收的IP数据报包含的数据的类型的信息。

10.如权利要求6-7中任一项所述的方法，其中所述策略实施点是策略和计费控制PCC架构电信网络的策略和计费实施功能PCEF节点（2000）。

11.一种策略实施点（200，2000）中的装置，用于在电信网络中的第一端点（300）与所述电信网络中的第二端点（400）之间的双向通信中路由IP数据报，并且根据数据压缩策略压缩由所述第二端点（400）传送到所述第一端点（300）的响应的IP数据报，每个IP数据报包括数据的字节序列和限定所述IP数据报中的数据的第一字节的序列号的报头，所述响应是支持压缩的层7协议，其中层级在开放系统互连OSI参考模型的意义上理解，所述装置包括：

用于通过在接收的IP数据报中的至少一个中检查所述层7协议的控制信息来确定（S60；S200）由所述第二端点（400）发送的IP数据报是否未被压缩但能根据所述数据压缩策略来压缩的部件，所述控制信息超出所述IP数据报中的IP5元组而定位；

用于响应于确定接收的IP数据报未被压缩但能被压缩来压缩（S110；S210）所述接收的IP数据报中的至少一些中的数据，由此生成压缩IP数据报用于传送到所述第一端点（300）的部件；

用于修改（S130；S220）压缩的IP数据报中的报头来考虑其中的数据压缩所引起的一个或多个之前的IP数据报中的字节的数量中的减少以便确保在由所述第二端点（400）传送到所述第一端点（300）的响应中的相邻压缩IP数据报之间的所述序列号的连续性的部件；

用于将所述压缩的IP数据报传送（S140；S230）到所述第一端点（300）并且从其处接收所述压缩IP数据报的接收的确认的部件；

用于响应于所述确认的接收，生成（S150；S240）对应的未压缩IP数据报的接收的确认用于传送到所述第二端点（400）的部件；以及

用于将所述对应的未压缩IP数据报的接收的确认传送（S160；S250）到所述第二端点（400）的部件。

12.如权利要求11所述的装置，其中由所述第二端点（400）传送到所述第一端点（300）的所述响应包括响应报头和内容，并且所述响应报头包括指示所述响应中的内容的长度的内容长度指示符，并且其中接收的IP数据报中的数据通过以下来压缩：

从所述响应去除（S100）所述内容长度指示符；

在接收所述响应的最后IP数据报之前压缩（S110）所述响应的接收IP数据报中的数据；以及

使压缩数据编码（S120）成数据块来生成编码的压缩响应用于传送到所述第一端点（300），所述编码的压缩响应包括已经应用编码的指示。

13.如权利要求11或12所述的装置，其中HTTP/1.1响应的IP数据报被路由和压缩，其中由所述第二端点（400）传送到所述第一端点（300）的所述响应包括内容-长度报头，并且其中所述接收的IP数据报中的数据通过以下来压缩：

从所述响应去除（S100）所述内容-长度报头；

执行HTTP兼容压缩算法以在接收所述响应的最后IP数据报之前压缩（S110）所述接收的IP数据报中的数据；以及

对压缩数据应用成块传递编码（S120）来生成传递编码响应，所述传递编码响应包括传递-编码报头用于传送到所述第一端点（300）。

14.如权利要求11-12中任一项所述的装置，其中所述数据压缩策略基于以下中的至少一个：

所述第一端点（300）使所述第一端点（300）能够对压缩IP数据报解压缩以提取其中的数据的指示包括在对所述第二端点（400）的请求中的记录；

指示所述第一端点（300）能够对压缩IP数据报解压缩以提取其中的数据或指示要传送到所述第一端点（300）的起初未被压缩的IP数据能被压缩的所述第一端点（300）的存储简档数据；以及

限定允许接收的IP数据报包含的数据的类型的信息。

15.如权利要求11-12中任一项所述的装置，其中所述策略实施点是策略和计费控制PCC架构电信网络的策略和计费实施功能PCEF节点（2000）。