报文的压缩方法和装置与流程

本申请涉及通信技术领域，尤其涉及一种报文的压缩方法和装置。

背景技术：

随着互联网的高速发展，通过互联网传输的业务数据越来越多，也越来越复杂。通常，在业务数据的传输过程中，会采用HTTP(Hyper Text Transfer Protocol，超文本传输协议)压缩技术对业务数据进行压缩后传输，这样可以减少网络中的数据传输量，并优化网络带宽。然而，传统的HTTP压缩技术只能压缩大小有限的业务数据，并且对相关设备的硬件性能要求较高。当业务数据的大小超过一定限制时，传统的HTTP压缩技术将无法实现压缩功能。

技术实现要素：

有鉴于此，本申请提供一种报文的压缩方法，以解决相关技术中可压缩的业务数据的大小有限的问题。

具体地，本申请是通过如下技术方案实现的：

第一方面，本申请提供一种报文的压缩方法，所述方法包括：

在接收到待压缩的会话报文后，将所述会话报文携带的业务数据存储在内存中；

判断内存中已存储的业务数据的大小是否大于第一阈值；

如果所述大小大于所述第一阈值，则压缩所述业务数据，基于压缩后的业务数据构造会话报文并发送。

第二方面，本申请提供一种报文的压缩装置，所述装置包括：

存储单元，用于在接收到待压缩的会话报文后，将所述会话报文携带的业务数据存储在内存中；

第一判断单元，用于判断内存中已存储的业务数据的大小是否大于第一阈值；

第一执行单元，用于当所述大小大于所述第一阈值时，压缩所述业务数据，基于压缩后的业务数据构造会话报文并发送。

分析上述技术方案可知，在实现HTTP压缩功能时，如果在内存中已存储的业务数据的大小大于第一阈值，则可以对这一组业务数据进行压缩，而无需等待接收到所有待压缩的业务数据后再进行压缩，即可以实现对待压缩的业务数据的分组压缩。与相关技术相比，可以占用较小的内存，实现对较大业务数据的压缩，不限制业务数据的压缩上限。

附图说明

图1是本申请一示例性实施例示出的一种报文的压缩方法的组网图；

图2是本申请一示例性实施例示出的一种报文的压缩方法的流程图；

图3是本申请一示例性实施例示出的另一种报文的压缩方法的流程图；

图4是本申请一示例性实施例示出的另一种报文的压缩方法的流程图；

图5是本申请一示例性实施例示出的一种报文的压缩装置所在设备的硬件结构图；

图6是本申请一示例性实施例示出的一种报文的压缩装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中，为了确保不影响设备的其他业务功能，通常会预先设置用于存储待压缩的业务数据的内存空间大小，在接收到待压缩的会话报文后，可以从所述会话报文中提取待压缩的业务数据，并将提取出的业务数据存储在内存中，在接收到本次会话的全部业务数据后，再对内存中已存储的业务数据进行压缩。然而，采用这样的实现方式，当本次会话的业务数据总大小超过预先设置的内存大小时，将无法压缩这些业务数据。

参考图1，为本申请一示例性实施例示出的一种报文的压缩方法的组网图，用户在通过终端设备实现浏览网页、网上交易等互联网业务时，终端设备可以与服务器建立HTTP连接，并基于所述HTTP连接向服务器发送业务数据获取请求，服务器在接收到该请求后，可以基于终端设备的请求构造携带有业务数据的一个或多个会话报文，并将这些会话报文发送给终端设备。

结合组网图1，参考图2，为本申请一示例性实施例示出的一种报文的压缩方法的流程图，该方法可以应用于图1所示的服务器中，也可以应用于图1所示的负载均衡设备中，以负载均衡设备为例，该方法包括以下步骤：

步骤201：在接收到待压缩的会话报文后，将所述会话报文携带的业务数据存储在内存中。

本实施例中，在终端设备与服务器建立HTTP连接后，终端设备可以向服务器发送业务数据获取请求，服务器在接收到该请求后，可以向终端设备发送携带业务数据的会话报文。负载均衡设备在接收到服务器发送的会话报文后，可以提取其携带的业务数据，并将这些业务数据存储在内存中以等待压缩。

步骤202：判断内存中已存储的业务数据的大小是否大于第一阈值。若是，执行步骤203。

本实施例中，负载均衡设备在将提取出的业务数据存储在内存中后，可以先判断内存中已存储的业务数据的大小是否大于第一阈值，所述第一阈值可以是默认的缺省值，也可以是用户预设的数值，本申请对此不作特殊限制。如果内存中已存储的业务数据的大小大于第一阈值，则可以执行步骤203；如果内存中已存储的业务数据的大小小于等于第一阈值，则可以继续执行步骤201。

步骤203：压缩所述业务数据，基于压缩后的业务数据构造会话报文并发送。

基于前述步骤202的判断结果，如果内存中已存储的业务数据的大小大于第一阈值，则负载均衡设备可以压缩所述业务数据，基于压缩后的业务数据构造会话报文并发送。

本实施例中，负载均衡设备在接收到会话首报文时，可以将会话首报文的特征存储在内存中，所述特征通常为会话的五元组，包括源IP地址、源端口、目的IP地址、目的端口和传输层协议。负载均衡设备在对内存中已存储的本次会话的业务数据进行压缩后，可以利用存储的这些特征构造携带压缩后的业务数据的会话报文，并将所述会话报文发送给终端设备。

由上述实施例可见，在实现HTTP压缩功能时，如果在内存中已存储的业务数据的大小大于第一阈值，则负载均衡设备可以对这一组业务数据进行压缩，而无需等待接收到所有待压缩的业务数据后再进行压缩，即负载均衡设备可以实现对待压缩的业务数据的分组压缩。与相关技术相比，负载均衡设备可以占用较小的内存，实现对较大业务数据的压缩，不限制业务数据的压缩上限。另外，当负载均衡设备配置有多核CPU时，在处理并行的待压缩业务数据时，由于每个CPU占用的内存都比较小，因此多个CPU进行业务数据压缩所占用的内存总大小也比较小，不会影响其他业务的处理。

结合组网图1，参考图3，为本申请一示例性实施例示出的另一种报文的压缩方法的流程图，该方法可以应用于图1所示的服务器中，也可以应用于图1所示的负载均衡设备中，以负载均衡设备为例，该方法包括以下步骤：

步骤301：接收待压缩的会话报文。

本实施例中，在终端设备与服务器建立HTTP连接后，终端设备可以向服务器发送业务数据获取请求，服务器在接收到该请求后，可以向终端设备发送携带业务数据的会话报文，负载均衡设备可以接收到所述会话报文。

步骤302：判断所述会话报文是否为会话首报文。若是，执行步骤303；否则，执行步骤306。

本实施例中，负载均衡设备可以先判断接收到的会话报文是否为本次会话中服务器发送的会话首报文。当负载均衡设备确认接收到的会话报文是会话首报文时，可以执行步骤303；当负载均衡设备确认接收到的会话报文不是会话首报文时，则可以执行步骤306。

步骤303：获取本次会话报文的业务数据总大小。

基于前述步骤302的判断结果，如果所述会话报文是会话首报文，则负载均衡设备可以获取本次会话报文的业务数据总大小。

本实施例中，负载均衡设备在接收到本次会话中服务器发送的会话首报文时，可以从所述会话首报文的content length字段中获取本次会话报文的业务数据总大小。

步骤304：判断所述业务数据总大小是否大于第二阈值。若是，执行步骤306；否则，执行步骤305。

本实施例中，负载均衡设备在获取到本次会话报文的业务数据总大小后，可以将其与第二阈值进行比较，判断所述业务数据总大小是否大于第二阈值。当所述业务数据总大小小于等于第二阈值时，说明本次会话报文的业务数据总量不大，可以执行步骤305；当所述业务数据总大小大于第二阈值时，则说明本次会话报文的业务数据总量较大，可以执行步骤306。其中，所述第二阈值可以是默认的缺省值，也可以是用户预先设置的数值，本申请对此不作特殊限制。

步骤305：转发所述会话首报文。

基于前述步骤304的判断结果，如果所述业务数据总大小小于等于第二阈值，则负载均衡设备可以转发所述会话首报文。

本实施例中，如果本次会话报文的业务数据总大小小于等于第二阈值，则说明本次会话中需要传输的业务数据量不大，对其进行压缩的意义不大，负载均衡设备可以不对这些业务数据进行压缩，而是将接收到的会话首报文转发给终端设备，此后再接收到本次会话的会话报文时，也可以将这些会话报文转发给终端设备，无需对其携带的业务数据进行压缩。

步骤306：将所述会话报文携带的业务数据存储在内存中。

基于前述步骤304的判断结果，如果所述业务数据总大小大于第二阈值，则负载均衡设备可以将所述会话首报文携带的业务数据存储在内存中；或者，基于前述步骤302的判断结果，如果所述会话报文不是会话首报文，则负载均衡设备也可以将所述会话报文携带的业务数据存储在内存中。

本实施例中，如果本次会话报文的业务数据总大小大于第二阈值，则说明本次会话中需要传输的业务数据量较大，负载均衡设备可以对这些业务数据进行压缩，以减少数据传输量并优化网络带宽。具体的，负载均衡设备可以在接收到本次会话中服务器发送的会话报文后，提取其携带的业务数据，并将这些业务数据存储在内存中以等待压缩。

步骤307：判断内存中已存储的业务数据的大小是否大于第一阈值。若是，执行步骤309；否则，执行步骤308。

本实施例中，负载均衡设备在将提取出的业务数据存储在内存中后，可以先判断内存中已存储的业务数据的大小是否大于第一阈值。当内存中已存储的业务数据的大小大于第一阈值时，可以执行步骤309；当内存中已存储的业务数据的大小小于等于第一阈值时，则可以执行步骤308。

步骤308：根据所述业务数据总大小判断是否已接收到本次会话的全部业务数据。若是，执行步骤309；否则，继续执行步骤301。

基于前述步骤307的判断结果，如果内存中已存储的业务数据的大小小于等于第一阈值，则负载均衡设备可以根据所述业务数据总大小判断是否已接收到本次会话的全部业务数据。

本实施例中，负载均衡设备可以先根据在前述步骤303中获取的业务数据总大小，以及已接收到的业务数据的大小，判断是否已接收到本次会话的全部业务数据。当已接收到本次会话的全部业务数据时，可以执行步骤309；当未接收到本次会话的全部业务数据时，则可以继续执行步骤301，负载均衡设备可以继续接收会话报文，并将其携带的业务数据存储在内存中，以充分利用内存资源。

步骤309：压缩所述业务数据。

基于前述步骤307的判断结果，如果内存中已存储的业务数据的大小大于第一阈值，则负载均衡设备可以压缩所述业务数据；或者，基于前述步骤308的判断结果，如果已接收到本次会话的全部业务数据，则负载均衡设备也可以压缩所述业务数据。

本实施例中，负载均衡设备在确定要对内存中已存储的业务数据进行压缩后，可以采用gzip等HTTP压缩技术对这些业务数据进行压缩。

步骤310：清除内存中已压缩的业务数据。

本实施例中，负载均衡设备在对内存中已存储的业务数据进行压缩后，可以清除之前存储的待压缩的业务数据，仅保留压缩后的业务数据，以减小占用的内存大小。

步骤311：基于压缩后的业务数据构造会话报文并发送。

本实施例中，负载均衡设备在前述步骤302中接收到会话首报文时，可以将会话报文的特征存储在内存中，所述特征通常为会话的五元组。负载均衡设备在前述步骤309中得到压缩后的业务数据后，可以利用所述特征，构造携带压缩后的业务数据的会话报文，并将所述会话报文发送给终端设备。

需要说明的是，负载均衡设备在将某次会话的所有业务数据均压缩并发送给终端设备后，可以清除内存中缓存的与本次会话相关的所有数据，例如会话特征、构造的会话报文等。

在一个可选的实施方式中，参考图4，前述步骤311可以包括以下步骤：

步骤401：判断内存中是否存储有上一次构造会话报文时剩余的未发送压缩数据。若是，执行步骤402；否则，执行步骤403。

本实施例中，负载均衡设备在基于压缩后的业务数据构造会话报文时，可以先判断内存中是否存储有上一次构造会话报文时剩余的未发送压缩数据。当内存中存储有所述未发送压缩数据时，可以执行步骤402；当内存中未存储有所述未发送压缩数据时，则可以执行步骤403。

步骤402：将所述未发送压缩数据排列在本次压缩后的业务数据之前以构造会话报文并发送。

基于前述步骤401的判断结果，如果内存中存储有上一次构造会话报文时剩余的未发送压缩数据，则负载均衡设备可以将所述未发送压缩数据排列在前述步骤309中得到的压缩后的业务数据之前，此后负载均衡设备可以基于组合后的压缩数据，并利用内存中已存储的会话报文的特征，构造会话报文并发送。

步骤403：基于本次压缩后的业务数据构造会话报文并发送。

基于前述步骤401的判断结果，如果内存中未存储有上一次构造会话报文时剩余的未发送压缩数据，则负载均衡设备可以基于在前述步骤309中得到的压缩后的业务数据，并利用内存中已存储的会话报文的特征，构造会话报文并发送。

步骤404：如果在本次构造会话报文时有剩余的未发送压缩数据，则将内存中存储的未发送压缩数据更新为本次剩余的未发送压缩数据。

本实施例中，负载均衡设备在构造会话报文时以字节为单位，即负载均衡设备发送的会话报文携带的是整数个字节大小的压缩数据。如果在前述步骤402或403中得到的待发送的压缩数据的大小不是整数个字节，则说明本次构造会话报文时有剩余的未发送压缩数据；否则，说明本次构造会话报文时没有剩余的未发送压缩数据。如果本次构造会话报文时有剩余的未发送压缩数据，则负载均衡设备可以利用所述待发送的压缩数据尾部无法构成一个字节的压缩数据，更新内存中存储的未发送压缩数据。

例如，假设负载均衡设备得到内存中存储的上一次构造会话报文时剩余的未发送压缩数据有4位，本次压缩后的业务数据有18位，则负载均衡设备可以将4位未发送压缩数据排列在18位压缩后的业务数据之前，利用得到的22位组合后的压缩数据的前16位，即前2个字节的压缩数据构造会话报文并发送，并利用所述组合后的压缩数据的后6位，即不足1个字节的压缩数据更新内存中存储的未发送压缩数据。

由上述实施例可见，在实现HTTP压缩功能时，如果在内存中已存储的业务数据的大小大于第一阈值，则负载均衡设备可以对这一组业务数据进行压缩，而无需等待接收到所有待压缩的业务数据后再进行压缩，即负载均衡设备可以实现对待压缩的业务数据的分组压缩。与相关技术相比，负载均衡设备可以占用较小的内存，实现对较大业务数据的压缩，不限制业务数据的压缩上限。另外，当负载均衡设备配置有多核CPU时，在处理并行的待压缩业务数据时，由于每个CPU占用的内存都比较小，因此多个CPU进行业务数据压缩所占用的内存总大小也比较小，不会影响其他业务的处理。

与前述报文的压缩方法的实施例相对应，本申请还提供了报文的压缩装置的实施例。

本申请报文的压缩装置的实施例可以应用在服务器或负载均衡设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，以负载均衡设备为例，为本申请报文的压缩装置所在负载均衡设备的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中报文的压缩装置所在的负载均衡设备通常根据该报文压缩的实际功能，还可以包括其他硬件，对此不再赘述。

参考图6，为本申请一示例性实施例示出的一种报文的压缩装置的框图，该报文的压缩装置600可以应用于图5中的负载均衡设备，包括：

存储单元601，用于在接收到待压缩的会话报文后，将所述会话报文携带的业务数据存储在内存中；

第一判断单元602，用于判断内存中已存储的业务数据的大小是否大于第一阈值；

第一执行单元603，用于当所述大小大于所述第一阈值时，压缩所述业务数据，基于压缩后的业务数据构造会话报文并发送。

在一个可选的实施方式中，所述存储单元601可以包括：

第一判断子单元6011，用于在接收到待压缩的会话报文后，判断接收到的待压缩的会话报文是否为会话首报文；

获取子单元6012，用于当所述会话报文为会话首报文时，从所述会话首报文中获取本次会话报文的业务数据总大小；

第二判断子单元6013，用于判断所述业务数据总大小是否大于第二阈值；

存储子单元6014，用于当所述业务数据总大小大于所述第二阈值时，将所述会话报文携带的业务数据存储在内存中。

在另一个可选的实施方式中，所述装置600还可以包括：

第二判断单元604，用于当内存中已存储的业务数据的大小小于等于所述第一阈值时，根据所述业务数据总大小判断是否已接收到本次会话的全部业务数据；

第二执行单元605，用于当已接收到本次会话的全部业务数据时，压缩内存中已存储的业务数据，基于压缩后的业务数据构造会话报文并发送。

在另一个可选的实施方式中，所述装置600还可以包括：

清除单元606，用于在压缩所述业务数据后，清除内存中已压缩的业务数据。

在另一个可选的实施方式中，所述第一执行单元603可以包括：

判断子单元6031，用于判断内存中是否存储有上一次构造会话报文时剩余的未发送压缩数据；

第一发送子单元6032，用于当内存中存储有所述未发送压缩数据时，将所述未发送压缩数据排列在本次压缩后的业务数据之前以构造会话报文并发送；

第二发送子单元6033，用于当内存中未存储有所述未发送压缩数据时，基于本次压缩后的业务数据构造会话报文并发送；

更新子单元6034，用于当在本次构造会话报文时有剩余的未发送压缩数据时，将内存中存储的未发送压缩数据更新为本次剩余的未发送压缩数据；

其中，所述未发送压缩数据为构造会话报文时剩余的无法构成一个字节的压缩数据。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。