CN114189562A

CN114189562A - 数据处理方法、装置、终端和存储介质

Info

Publication number: CN114189562A
Application number: CN202111441319.4A
Authority: CN
Inventors: 任安顺
Original assignee: Huizhou TCL Mobile Communication Co Ltd
Current assignee: Huizhou TCL Mobile Communication Co Ltd
Priority date: 2021-11-30
Filing date: 2021-11-30
Publication date: 2022-03-15
Anticipated expiration: 2041-11-30
Also published as: CN114189562B

Abstract

本申请实施例公开了一种数据处理方法、装置、终端和存储介质，应用于使用HTTP或HTTPS的终端，该方法包括：获取请求数据；对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据；将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文；其中，所述目标报文的长度小于使用HTTP和HTTPS传输所述请求数据的报文，所述目标头部数据的长度小于所述头部数据的长度，所述目标主体数据的长度小于所述主体数据的长度；发送所述目标报文，以便于接收端解析所述目标报文。本申请实施例能够将数据以较小的报文进行传输，从而缓解了数据传输的压力、提升了数据传输的效率。

Description

数据处理方法、装置、终端和存储介质

技术领域

本申请涉及计算机领域，具体涉及一种数据处理方法、装置、终端和存储介质。

背景技术

HTTP是应用较为广泛的文本传输协议，实现在服务器与客户端之间进行数据传输。然而，使用HTTP进行数据传输时，其数据报文是明文形式的文本数据，容易被窃取。若使用HTTP的加密协议HTTPS进行数据传输，需要对本就不轻量的HTTP数据报文进行非对称或者对称加密，将极大地占用网络功耗和资源，会增大数据传输的压力、降低数据传输的效率，甚至因网络波动、卡顿导致数据传输失败。

因此，现有技术存在缺陷，有待改进与发展。

发明内容

本申请实施例提供一种数据处理方法、装置、终端和存储介质，在传输数据时，本申请实施例能够将数据以较小数据报文的形式进行传输，从而有效地缓解了数据传输的压力、提升了数据传输的效率和任务并发量。

本申请实施例提供一种数据处理方法，应用于使用HTTP或HTTPS的终端，包括：

获取请求数据；

对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据；

将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文；其中，所述目标报文的长度小于使用HTTP和HTTPS传输所述请求数据的报文，所述目标头部数据的长度小于所述头部数据的长度，所述目标主体数据的长度小于所述主体数据的长度；

发送所述目标报文，以便于接收端解析所述目标报文。

可选的，所述将所述头部数据和所述主体数据分别按照目标协议进行封装，包括：按照所述目标协议的规范格式，将所述头部数据封装进所述目标协议的选项部分，将所述主体数据封装进所述目标协议的载荷部分。

可选的，该方法进一步包括：对所述头部数据进行网络地址转换和更新循环冗余校验。

可选的，该方法进一步包括：对所述主体数据进行压缩。

可选的，所述发送所述目标报文，包括：

解析所述目标协议，得到所述目标协议的传输层协议，所述传输层协议为UDP；

将所述目标报文基于所述传输层协议发送至所述接收端。

可选的，将所述目标报文基于所述传输层协议发送至所述接收端，包括：对所述目标报文使用加密协议进行传输，所述加密协议为DTLS。

可选的，所述目标协议包括CoAP协议。

本申请实施例还提供一种数据处理装置，包括：

数据获取模块，用于获取请求数据；

数据解析模块，用于对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据；

数据封装模块，用于将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文；其中，所述目标报文的长度小于使用HTTP和HTTPS传输所述请求数据的报文，所述目标头部数据的长度小于所述头部数据的长度，所述目标主体数据的长度小于所述主体数据的长度；

数据发送模块，用于发送所述目标报文，以便于接收端解析所述目标报文。

可选的，所述数据封装模块进一步用于：按照所述目标协议的规范格式，将所述头部数据封装进所述目标协议的选项部分，将所述主体数据封装进所述目标协议的载荷部分。

可选的，所述数据封装模块进一步用于：对所述头部数据进行网络地址转换和更新循环冗余校验。

可选的，所述数据封装模块进一步用于：对所述主体数据进行压缩。

可选的，所述数据发送模块进一步用于：

将所述目标报文基于所述传输层协议发送至所述接收端。

可选的，所述数据发送模块进一步用于：对所述目标报文使用加密协议进行传输，所述加密协议为DTLS。

可选的，所述目标协议包括CoAP协议。

本申请实施例还提供一种终端，所述终端能够执行上述任一项所述的数据处理方法中的操作。

本申请实施例还提供一种存储介质，所述存储介质用于存储计算机程序，所述计算机程序被处理器加载以执行上述任一项所述的数据处理方法。

本申请实施例公开了一种数据处理方法、装置、终端和存储介质，应用于使用HTTP或HTTPS的终端，所述方法包括：获取请求数据；对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据；将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文；其中，所述目标报文的长度小于使用HTTP和HTTPS传输所述请求数据的报文，所述目标头部数据的长度小于所述头部数据的长度，所述目标主体数据的长度小于所述主体数据的长度；发送所述目标报文，以便于接收端解析所述目标报文。

由上可知，本申请实施例通过将待传输的数据按照目标协议进行封装，形成比使用HTTP传输该数据的数据报文更小的目标报文，从而有效地缓解了数据传输的压力、提升了数据传输的效率、实现更高的任务并发量。

附图说明

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

图1是本申请实施例提供的数据处理方法的流程示意图；

图2是本申请实施例提供的数据处理方法的流程示意图；

图3是本申请实施例提供的目标报文的结构示意图；

图4是本申请实施例提供的请求数据传输的示意图；

图5是本申请实施例提供的数据处理装置的结构示意图；

图6是本申请实施例提供的终端的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多所述特征。在本申请的描述中，“至少两个”的含义是两个或两个以上，除非另有明确具体的限定。

下文的公开提供了许多不同的实施方式或例子用来实现本申请的不同结构。为了简化本申请的公开，下文中对特定例子的部件和设置进行描述。当然，它们仅仅为示例，并且目的不在于限制本申请。此外，本申请可以在不同例子中重复参考数字和/或参考字母，这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施方式和/或设置之间的关系。此外，本申请提供了的各种特定的工艺和材料的例子，但是本领域普通技术人员可以意识到其他工艺的应用和/或其他材料的使用。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

本申请实施例所提供的数据处理方法可以适用于任何具有数据处理功能的终端，例如OMA DM(Open Mobile Alliance Device Management，开放移动联盟设备管理协议)终端、平板电脑、笔记本电脑、台式电脑、电视、智能手机、云服务器设备等，本申请实施例不再一一列举。以下对该数据处理方法、装置、终端和存储介质进行详细说明，需说明的是，以下实施例的描述顺序不作为对实施例优选顺序的限定。

下面结合附图和具体实施方式对本发明予以详细描述，请参阅图1至图6。

请参阅图1，图1是本申请实施例提供的数据处理方法的流程示意图。其中，本申请实施例包括：

步骤110、获取请求数据。

请求数据是指请求方发出的流量数据。在一些实施例中，可以通过系统中任何具有流量采集或数据接收功能的终端、服务器、处理器等获取请求数据。

仅作为示例，服务器可以接收用户通过用户终端发送的请求数据。例如，请求数据可以是用户输入请求查询某个文件的消息。本实施例对于请求数据的获取方式不做限制。

步骤120、对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据。

对于通信领域中的任何可识别的流量数据、消息而言，均是由头部数据和主体数据组成。以HTTP传输的数据为例，其具有以下字段：

{HTTP/1.0 200OK；

Content-type：text/plain；

Content-length：19；

Hi！I'm a message！}。

其中，该字段中的第1至3行为头部数据，也称为头数据、消息头或Header，用于对该数据的状态进行说明。例如字段“HTTP/1.0 200OK”代表该字段“使用1.0版本的HTTP协议进行传输”，字段“HTTP200”代表状态响应“成功处理请求”，“OK”代表“已响应”。

其中，该字段中的第4行为主体数据，也称为数据主体、载荷数据、payload，主体数据可以是想要发送或接收的目标数据。头部数据都是文本形式且都是结构化的数据，而主体数据中可以包含任意的二进制数据(比如图片、视频、音轨、软件程序)或文本数据。例如字段“Hi！I'm a message！”即为目标终端接收或发出的目标文本数据。

在一些实施例中，系统可以通过任何具有数据解析、识别或检测功能的终端、服务器、处理器等，对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据。例如，网络流量分析器、互联网数据中心(Internet Data Center，简称IDC)等。需要说明的是，现有的终端可以通过其服务器、芯片、处理器等，快捷、准确地对接收或发送的数据进行解析，本申请实施例对于请求数据的解析方式不做限制。

步骤130、将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文。

在一些实施例中，目标协议可以包括CoAP(The Constrained ApplicationProtocol，受限应用协议)协议。在一些实施例中，可以按照目标协议的规范格式，将头部数据封装进目标协议的选项部分，将主体数据封装进目标协议的载荷部分，以得到目标报文。

请一并参阅图3，图3是本申请实施例提供的目标报文的结构示意图。

如图3所示，由于请求数据按目标协议的规范进行封装后得到目标报文，以目标协议是CoAP为例，目标报文的数据格式与CoAP报文的格式对应。

目标报文可以包括目标头部数据和目标主体数据，其中，目标头部数据可以包括以下几个部分：协议版本(Ver)、报文类型(T)、标签长度(TKL)、请求/响应码(Code)、报文代号(Message ID)、标签(Token)和选项(Option)。

协议版本是指版本编号，是一个2位(bit)的无符号整数，用于指示CoAP协议的版本号，取值为0、1、B。

报文类型是指CoAP协议规定的4种不同的报文形式，包括CON报文(可靠报文)，NON报文(非可靠报文)，ACK报文(确认报文)和RST报文(重置报文)，报文类型为2位。

标签长度是指CoAP标签的长度，CoAP标签可以包括报文代号和标签，每个CoAP报文均包含报文代号，但标签是非必须的，标签长度占用4位。

请求/响应码是指，请求/响应码为在CoAP请求报文和响应报文中具有不同的表现形式，用c.dd的形式表示，例如0.XX表示CoAP请求的某种方法，而2.XX、4.XX或5.XX则表示CoAP响应的某种具体表现，请求/响应码为8位。

报文代号是指标签对应的代号、编号，报文代号为16位。

标签是指标签的具体内容，

选项是用于设定CoAP主机、CoAP URI、CoAP请求参数和负载媒体类型等的数据。

需要说明的是，上述CoAP报文的目标头部数据通过0xFF与载荷部分进行分离，其中0xFF代表二进制的11111111。

可以理解，由于一些请求数据携带的主体数据可能为空，且请求数据的主体数据被封装在目标报文的选项部分，使得目标报文数据可能不存在选项部分。因此，对于目标报文的目标头部数据，其最小长度为协议版本、报文类型、标签长度、请求/响应码、报文代号之和，即为：2+2+4+8+16＝32bit。由于8位可以换算位1字节，则目标报文的目标头部数据的最小长度仅为4字节。

在一些实施例中，目标报文的长度可以小于使用HTTP和HTTPS传输请求数据的报文，目标头部数据的长度可以小于头部数据的长度。对于使用HTTP进行数据传输的HTTP报文而言，由于HTTP报文的头部数据携带信息较多，使得HTTP报文通常具有较长的头部数据，即HTTP消息头较长、占用内存较大。仅作为示例，下面列出一个较短的HTTP消息头：

{X-Android-Selected-Protocol:http/1.1；

Connection:close；X-Android-Response-Source:NETWORK 200；

Set-Cookie:JSESSIONID＝GNNJCJ3MDYWXDGCC.ddo0_03；

Path＝/southbound-connector；

X-Android-Sent-Millis:1635123298752；

Content-Length:423；

X-Android-Received-Millis:1635123299239；

Date:Wed，13Oct 2021 07:01:27GMT；

Content-Type:application/vnd.syncml.dm+wbxml；

charset＝text/html；

charset＝UTF-8；}

可以看出，该HTTP消息头的长度为374字节，若加上TCP传输层协议的长度20字节，则共为394字节，远大于CoAP报文目标头部数据最小长度所占用的4字节。

在一些实施例中，目标主体数据的长度可以小于主体数据的长度。在一些实施例中，可以对请求数据的主体数据通过gzip的方式进行压缩，封装进目标报文的载荷部分。如此，可以进一步地减少请求数据的长度、占用内存。

在一些实施例中，可以对头部数据进行网络地址转换(Network AddressTranslation，NAT)和更新循环冗余校验(Cyclic Redundancy Check，CRC)。如此，可以更好地对头部数据按目标协议的规范进行封装，形成目标报文的目标头部数据。

由上可知，将请求数据的头部数据按目标协议进行封装，得到目标头部数据的长度不仅小于原头部数据的长度，还小于HTTP消息头的长度。因此本申请实施例通过缩小请求数据的长度，相较于通过HTTP或HTTPS进行数据传输，有效地缓解了对请求数据进行传输时的压力、提升了传输的效率。

步骤140、发送所述目标报文。

在一些实施例中，可以向接收端发送目标报文，以使接收端可以对目标报文进行解析。

请一并参阅图2，图2是本申请实施例提供的数据处理方法的流程示意图。其中，步骤140可以包括以下步骤：

步骤141、解析所述目标协议，得到所述目标协议的传输层协议。

传输层协议是指数据传输时需要用到的安全协议。传输层协议一般与通信协议相对应，例如HTTP和HTTPs对应的传输层协议为TCP。

在一些实施例中，目标协议的传输层协议可以为UDP协议。UDP传输的数据报文最小长度为8字节，TCP传输的数据报文最小长度为20字节。如此，相较于使用HTTP进行数据传输，本申请实施例可以进一步地减小请求数据的传输压力、提升传输效率。

步骤142、将所述目标报文基于所述传输层协议发送至所述接收端。

在一些实施例中，可以对目标报文使用加密协议进行传输，目标报文的加密协议可以为DTLS协议。

请一并参阅图4，图4是本申请实施例提供的请求数据传输的示意图。如图4所示，对请求数据进行封装得到目标报文后，可以在UDP传输层之前加入DTLS加密层，以对目标报文进行加密处理。其中，DTLS层的数据报文最小长度为16字节，也即CoAP层、UDP层、DTLS层总长度最小仅为28字节，而仅仅HTTPS的SSL加密层的数据报文最小长度为256字节。如此，相较于HTTPS进行可以进一步地减小请求数据的传输压力、提升传输效率。

请参阅图5，图5是本申请实施例提供的数据处理装置的一种结构示意图。

如图5所示，数据处理装置可以包括数据获取模块51、数据解析模块52、数据封装模块53和数据发送模块54。

在一些实施例中，数据获取模块51可以用于获取请求数据。

在一些实施例中，数据解析模块52可以用于对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据；

在一些实施例中，数据封装模块53可以用于将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文；其中，所述目标报文的长度小于使用HTTP和HTTPS传输所述请求数据的报文，所述目标头部数据的长度小于所述头部数据的长度，所述目标主体数据的长度小于所述主体数据的长度；

在一些实施例中，数据发送模块54可以用于发送所述目标报文，以便于接收端解析所述目标报文。

在一些实施例中，数据封装模块53可以进一步用于：按照所述目标协议的规范格式，将所述头部数据封装进所述目标协议的选项部分，将所述主体数据封装进所述目标协议的载荷部分。

在一些实施例中，数据封装模块53可以进一步用于：对所述头部数据进行网络地址转换和更新循环冗余校验。

在一些实施例中，数据封装模块53可以进一步用于：对所述主体数据进行压缩。

在一些实施例中，数据发送模块54可以进一步用于：

将所述目标报文基于所述传输层协议发送至所述接收端。

在一些实施例中，所述数据发送模块进一步用于：对所述目标报文使用加密协议进行传输，所述加密协议为DTLS。

在一些实施例中，所述目标协议包括CoAP协议。

具体实施时，以上各个单元可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现，以上各个单元的具体实施可参见前面的方法实施例，在此不再赘述。

由此，本申请实施例通过将待传输的数据按照目标协议进行封装，形成比使用HTTP传输该数据的数据报文更小的目标报文，从而有效地缓解了数据传输的压力、提升了数据传输的效率、实现更高的任务并发量。

本申请实施例还提供一种终端。如图6所示，该终端可以包括射频(RF，RadioFrequency)电路601、包括有一个或一个以上存储介质的存储器602、输入单元603、显示单元604、传感器605、音频电路606、无线保真(WiFi，Wireless Fidelity)模块607、包括有一个或者一个以上处理核心的处理器608、以及电源609等部件。本领域技术人员可以理解，图5中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

RF电路601可用于收发信息过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器608处理；另外，将涉及上行的数据发送给基站。通常，RF电路601包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM，Subscriber Identity Module)卡、收发信机、耦合器、低噪声放大器(LNA，LowNoise Amplifier)、双工器等。此外，RF电路601还可以通过无线通信与网络和其他设备通信。

存储器602可用于存储软件程序以及模块，处理器608通过运行存储在存储器602的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等。此外，存储器602可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器602还可以包括存储器控制器，以提供处理器608和输入单元603对存储器602的访问。

输入单元603可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，在一个具体的实施例中，输入单元603可包括触敏表面以及其他输入设备。触敏表面，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面上或在触敏表面附近的操作)，并根据预先设定的程式驱动相应的连接装置。除了触敏表面，输入单元603还可以包括其他输入设备。具体地，其他输入设备可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元604可用于显示由用户输入的信息或提供给用户的信息以及服务器的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元604可包括显示面板，可选的，可以采用液晶显示器(LCD，Liquid CrystalDisplay)、有机发光二极管(OLED，Organic Light-Emitting Diode)等形式来配置显示面板。进一步的，触敏表面可覆盖显示面板，当触敏表面检测到在其上或附近的触摸操作后，传送给处理器608以确定触摸事件的类型，随后处理器608根据触摸事件的类型在显示面板上提供相应的视觉输出。虽然在图5中，触敏表面与显示面板是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面与显示面板集成而实现输入和输出功能。

终端还可包括至少一种传感器605，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板的亮度，接近传感器可在服务器移动到耳边时，关闭显示面板和背光。

音频电路606、扬声器，传声器可提供用户与服务器之间的音频接口。音频电路606可将接收到的音频数据转换后的电信号，传输到扬声器，由扬声器转换为声音信号输出；另一方面，传声器将收集的声音信号转换为电信号，由音频电路606接收后转换为音频数据，再将音频数据输出处理器608处理后，经RF电路601以发送给比如终端，或者将音频数据输出至存储器602以便进一步处理。音频电路606还可能包括耳塞插孔，以提供外设耳机与服务器的通信。

WiFi属于短距离无线传输技术，终端通过WiFi模块607可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图5示出了WiFi模块607，但是可以理解的是，其并不属于终端的必须构成，完全可以根据需要在不改变申请的本质的范围内而省略。

处理器608是终端的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器602内的软件程序和模块，以及调用存储在存储器602内的数据，执行服务器的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器608可包括一个或多个处理核心；优选的，处理器608可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器608中。

终端还包括给各个部件供电的电源609(比如电池)，优选的，电源可以通过电源管理系统与处理器608逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源609还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

具体在本实施例中，终端中的处理器608会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器602中，并由处理器608来运行存储在存储器602中的应用程序，从而实现各种功能：

获取请求数据；

发送所述目标报文，以便于接收端解析所述目标报文。

本申请实施例公开了一种数据处理方法、装置、终端和存储介质。该数据处理方法包括：获取请求数据；对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据；将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文；其中，所述目标报文的长度小于使用HTTP和HTTPS传输所述请求数据的报文，所述目标头部数据的长度小于所述头部数据的长度，所述目标主体数据的长度小于所述主体数据的长度；发送所述目标报文，以便于接收端解析所述目标报文。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任一种数据处理方法中的步骤。例如，该指令可以执行如下步骤：

获取请求数据；对所述请求数据进行解析，得到所述请求数据的头部数据和主体数据；将所述头部数据和所述主体数据分别按照目标协议进行封装，得到由目标头部数据和目标主体数据组成的目标报文；其中，所述目标报文的长度小于使用HTTP和HTTPS传输所述请求数据的报文，所述目标头部数据的长度小于所述头部数据的长度，所述目标主体数据的长度小于所述主体数据的长度；发送所述目标报文，以便于接收端解析所述目标报文。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

其中，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。

由于该存储介质中所存储的指令，可以执行本申请实施例所提供的任一种数据处理方法中的步骤，因此，可以实现本申请实施例所提供的任一种数据处理方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的数据处理方法、装置、存储介质及终端进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种数据处理方法，其特征在于，应用于使用HTTP或HTTPS的终端，包括：

获取请求数据；

发送所述目标报文，以便于接收端解析所述目标报文。

2.根据权利要求1所述的方法，其特征在于，所述将所述头部数据和所述主体数据分别按照目标协议进行封装，包括：按照所述目标协议的规范格式，将所述头部数据封装进所述目标协议的选项部分，将所述主体数据封装进所述目标协议的载荷部分。

3.根据权利要求2所述的方法，其特征在于，进一步包括：对所述头部数据进行网络地址转换和更新循环冗余校验。

4.根据权利要求2所述的方法，其特征在于，进一步包括：对所述主体数据进行压缩。

5.根据权利要求1所述的方法，其特征在于，所述发送所述目标报文，包括：

将所述目标报文基于所述传输层协议发送至所述接收端。

6.根据权利要求5所述的方法，其特征在于，将所述目标报文基于所述传输层协议发送至所述接收端，包括：对所述目标报文使用加密协议进行传输，所述加密协议为DTLS。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述目标协议包括CoAP协议。

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

数据获取模块，用于获取请求数据；

9.一种终端，其特征在于，能够执行权利要求1至7任一项所述的数据处理方法中的操作。

10.一种存储介质，其特征在于，所述存储介质用于存储计算机程序，所述计算机程序被处理器加载以执行权利要求1至7任一项所述的数据处理方法。