数据传输方法及服务器与流程

本发明涉及互联网技术领域，特别是涉及一种数据传输方法及服务器。

背景技术：

随着互联网兴起，用户通常使用http(hypertexttransferprotocol,超文本传输协议)访问各种互联网站点或服务。http协议是应用层协议，纯文本协议，而且通常是明文传输，因此，基于http协议的数据很容易被劫持侦听，甚至篡改，从而导致用户隐私泄露，严重的甚至造成用户的经济损失。

为了保证互联网中数据的安全性，引入了提供认证、鉴权等功能的tls(transportlayersecurity，安全传输层)协议，用户访问互联网需要使用基于tls加密的http协议，即将互联网中传输的数据进行加密。互联网的数据加密为互联网通信自由提供了安全保障，但是，对互联网的数据内容加密后，使得基于内容感知的部分业务失效，从而在某些情况下会导致用户业务体验下降。

例如，无线网络中的流量管理场景，对不同类型的业务数据流提供不同的服务策略，保障用户的服务体验最优，数据加密导致无法识别数据的业务类型，因此不能将有限的资源用于服务用户最关心的数据。例如，固网的父子账号业务，该业务可以根据互联网的数据内容进行过滤，过滤掉不适宜儿童访问的数据，从而保证儿童上网环境健康安全，但是，如果对互联网的数据加密后，无法有效识别儿童访问的业务类型和内容，导致儿童可能会访问到非法的或不适宜儿童的内容。因此，如何在能够为用户访问互联网提供安全保障的前提下，保证基于互联网数据内容的服务系统正常运行成为亟需解决的技术问题。

技术实现要素：

本发明实施例中提供了一种数据传输方法及服务器，以解决在互联网业务数据加密的情况下无法有效识别业务信息的技术问题，本发明实施例公开了如下技术方案：

第一方面，本发明提供一种数据传输方法，应用于基于互联网通信的系统中，所述系统包括终端设备、服务器和感知节点；所述方法包括：服务器接收所述终端设备发送的应用访问请求；服务器根据所述应用访问请求获取加密后的第一业务数据及与所述第一业务数据对应的应用信息，所述应用信息用于表征所述第一业务数据的业务信息；服务器将所述应用信息及所述第一业务数据提供给感知节点；感知节点利用所述应用信息识别所述第一业务数据 的业务信息；感知节点转发所述第一业务数据，或者，所述第一业务数据和所述应用信息。

第一方面提供的数据传输方法，在服务器向终端设备发送加密业务数据的过程中，服务器将感知节点需要的应用信息传递给感知节点，从而使感知节点能够根据该应用信息获知终端设备与服务器之间传输的加密业务数据的业务信息，进而使感知业务系统完成与业务内容相关的服务。其中，应用信息以明文方式传输，不需要服务器额外增加加解密协议簇，在保证终端设备与服务器之间业务数据加密的前提下，数据传输更方便、系统成本更低。

结合第一方面，在第一方面的第一种可能的实现方式中，所述服务器将所述应用信息及所述第一业务数据提供给感知节点，包括：服务器生成第一数据包，第一数据包包括消息头和载荷，所述消息头承载所述应用信息，所述载荷承载所述第一业务数据；服务器将所述第一数据包发送给所述感知节点。

结合第一方面，在第一方面的第二种可能的实现方式中，互联网通信系统还包括用于对数据进行重封装的封包设备；服务器将所述应用信息及所述第一业务数据提供给感知节点，包括：服务器将所述应用信息及所述第一业务数据发送给所述封包设备；封包设备生成第一数据包，第一数据包括消息头和载荷，消息头承载所述应用信息，载荷承载所述第一业务数据；封包设备将第一数据包发送给所述感知节点。

结合第一方面，在第一方面的第三种可能的实现方式中，所述第一数据包基于以下协议中的任意一种构建：传输控制协议tcp、安全传输层协议tls、网络协议ip和用户数据报协议udp。

结合第一方面，在第一方面的第四种可能的实现方式中，所述服务器将所述应用信息及所述第一业务数据提供给感知节点，包括：服务器将所述第一业务数据发送给感知节点；服务器将应用信息及第一业务数据的特征信息发送给所述感知节点，以使感知节点根据特征信息建立第一业务数据与应用信息之间的关联。

结合第一方面，在第一方面的第五种可能的实现方式中，服务器将应用信息及第一业务数据的特征信息发送给感知节点，包括：服务器生成通知消息，通知消息包含应用信息和特征信息；服务器将通知消息发送给感知节点。

结合第一方面，在第一方面的第六种可能的实现方式中，所述互联网通信系统中包含用于对数据进行重封装的封包设备；服务器将应用信息及第一业务数据的特征信息发送给感知节点，包括：服务器将应用信息及特征信息发送给封包设备；封包设备生成通知消息，通知消息包含应用信息及特征信息，并将所述通知消息发送给所述感知节点。

第二方面，本发明提供了一种服务器，应用于互联网通信系统中，系统还包括终端设备 和感知节点；所述服务器包括：接收器、处理器和发送器；接收器，用于接收终端设备发送的应用访问请求；处理器，用于根据应用访问请求获取加密后的第一业务数据及与所述第一业务数据对应的应用信息，所述应用信息用于表征第一业务数据的业务信息；发送器，用于将应用信息及第一业务数据提供给感知节点，以便感知节点利用所述应用信息识别第一业务数据的业务信息。

第二方面提供的服务器，在向终端设备发送加密业务数据的过程中，将该业务数据对应的应用信息传递给感知节点，从而使感知节点能够根据该应用信息获知加密业务数据的业务信息，进而使感知业务系统完成与业务内容相关的服务。其中，应用信息以明文方式传输，不需要服务器额外增加加解密协议簇，在保证终端设备与服务器之间业务数据加密的前提下，数据传输更方便、系统成本更低。

结合第二方面，在第二方面的第一种可能的实现方式中，所述处理器还用于，生成第一数据包，所述第一数据包包括消息头和载荷，所述消息头承载所述应用信息，所述载荷承载所述第一业务数据；所述发送器，用于将所述第一数据包发送给所述感知节点。

结合第二方面，在第二方面的第二种可能的实现方式中，所述互联网通信系统还包括用于对数据进行重封装的封包设备；所述发送器将所述应用信息及所述第一业务数据提供给感知节点时，具体用于：所述发送器将所述应用信息及所述第一业务数据发送给所述封包设备，以便所述封包设备生成第一数据包并将所述第一数据包发送给所述感知节点，所述第一数据包包括消息头和载荷，所述消息头承载所述应用信息，所述载荷承载所述第一业务数据。

结合第二方面，在第二方面的第三种可能的实现方式中，所述第一数据包基于以下协议中的任意一种构建：传输控制协议tcp、安全传输层协议tls、网络协议ip和用户数据报协议udp。

结合第二方面，在第二方面的第四种可能的实现方式中，所述发送器用于将所述应用信息及所述第一业务数据提供给感知节点时，具体用于：将所述第一业务数据发送给所述感知节点；将所述应用信息及所述第一业务数据的特征信息发送给所述感知节点，以使所述感知节点根据所述特征信息建立所述第一业务数据与所述应用信息之间的关联。

结合第二方面，在第二方面的第五种可能的实现方式中，所述发送器将所述应用信息及所述第一业务数据的特征信息发送给所述感知节点时，具体包括：所述处理器器，还用于生成通知消息，所述通知消息包含所述应用信息和所述特征信息；所述发送器，用于将所述通知消息发送给所述感知节点。

结合第二方面，在第二方面的第六种可能的实现方式中，所述互联网通信系统中包含用于对数据进行重封装的封包设备；所述发送器将所述应用信息及所述第一业务数据的特征信 息发送给所述感知节点时，具体用于：所述发送器，用于将所述应用信息及所述特征信息发送给所述封包设备，以使所述封包设备生成通知消息，所述通知消息包含所述应用信息及所述特征信息，以及使所述封包设备将所述通知消息发送给所述感知节点。

第三方面，本发明提供一种封包设备，应用于互联网通信系统中，所述系统还包括服务器和感知节点；所述封包设备包括：接收器、处理器和发送器；所述接收器，用于接收所述服务器发送的第一业务数据，以及，与所述第一业务数据对应的应用信息；所述处理器，用于生成第一数据包，所述第一数据包包括消息头和载荷，所述消息头承载所述应用信息，所述载荷承载所述第一业务数据；所述发送器，用于将所述第一数据包发送给所述感知节点，以便所述感知节点根据所述应用信息识别所述第一业务数据的业务信息。

第四方面，本发明提供一种封包设备，应用于互联网通信系统中，所述系统还包括服务器和感知节点；所述封包设备包括：接收器、处理器和发送器；所述接收器，用于接收所述服务器发送的与第一业务数据对应的应用信息，以及，所述第一业务数据的特征信息；所述处理器，用于生成通知消息，所述通知消息包括所述应用信息和所述特征信息；所述发送器，用于将所述通知消息发送给所述感知节点，以便所述感知节点根据所述特征信息建立所述应用信息与所述第一业务数据之间的关联，并使所述感知节点根据所述应用信息识别所述第一业务数据的业务信息。

由以上技术方案可见，本发明实施例提供的数据传输方法，当用户访问互联网业务时，向相应的服务器发送应用访问请求。服务器响应所述应用访问请求，获取加密的第一业务数据提供给感知节点，同时，将与第一业务数据对应的应用信息提供给感知节点。感知节点通过应用信息获知第一业务数据的业务信息，进一步提供给其它需要应用感知的服务系统，从而，在业务数据加密的情况下，通过应用信息也能够识别业务数据的业务信息，例如，业务类型等，进而使得基于业务数据内容的服务系统正常运行。

附图说明

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

图1为本发明实施例一种数据传输系统的架构示意图；

图2为本发明实施例一种数据传输方法的流程图；

图3为本发明实施例一种应用信息的消息格式示意图；

图4为本发明实施例一种数据传输方法的流程图；

图5为本发明实施例另一种数据传输方法的流程图；

图6为本发明实施例另一种数据传输方法的流程图；

图7为本发明实施例一种tcp协议报文的消息格式示意图；

图8为本发明实施例一种tls协议报文的消息格式示意图；

图9为本发明实施例一种ipv4协议报文的消息格式示意图；

图10为本发明实施例一种ipv6协议报文的消息格式示意图；

图11为本发明实施例一种udp协议的消息格式示意图；

图12为本发明实施例一种icmp的协议消息格式示意图；

图13为本发明实施例一种服务器的框图；

图14为本发明实施例一种封包设备的框图。

具体实施方式

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

参见图1，为本发明实施例提供的一种数据传输系统的架构示意图，如图1所示，该系统包括终端设备110、感知节点120、封包设备130和服务器140。

终端设备110可以是电脑、手机等任何能够进行互联网访问的终端，其中，终端设备110与服务器140之间通过有线通信网络或无线通信网络进行通信。

本发明实施例中，服务器140是指非运营商提供的，用于向用户提供各种互联网业务的服务端。服务器140接收终端设备110发起的基于http的请求，并向终端设备110提供相应的应用服务。

封包设备130可以部署在服务器140上，也可以是独立于服务器的独立设备，或者，可以是服务器上的程序片段。封包设备用于对服务器指定的数据进行重封包后转发。其中，如果封包设备130部署在服务器140内部，则服务器140可以通过函数调用的方式，例如，服务器可以通过应用程序编程接口将需要封包的数据传递给封包设备130；如果封包设备130未部署在服务器140中，则服务器140通过发送消息的方式将需要封包的数据传递给封包设备130。

感知节点120用于感知终端设备110和服务器140之间传输的业务数据的业务信息。 感知节点120的输入是封包设备130输出的数据。

其中，感知节点120可以部署在从服务器140到终端设备110之间的网络路径上，可以在该网络路径上部署一个或多个感知节点，以配合在该网络路径上不同位置的其它感知业务系统150(例如，父子账号系统)完成业务内容感知。感知节点120可以是独立的装置，也可以与其它系统(例如，感知业务系统)或装置集成，或者，可以与终端设备直接集成在一起(此时，感知节点实际是终端设备内的程序片段)。

感知节点120提供对外的查询接口，其它的感知业务系统经过授权可以通过该查询接口查询到指定业务的业务信息。其中，感知业务系统即与业务内容感知相关的业务系统，例如，父子账号系统，或者，根据业务进行流量管理调度的系统等。

参见图2，为本发明实施例提供的一种数据传输方法的流程图，该方法应用于图1所示的系统中，如图2所示，该数据传输方法包括：

s110，终端设备向服务器发送应用访问请求。

例如，终端设备访问某个视频网站中具体的视频时会产生相应的访问请求并发送给该网站的服务器。

s120，服务器根据应用访问请求获取加密后的第一业务数据及与该第一业务数据相对应的应用信息。

该应用信息用于表征第一业务数据的业务信息，例如，业务类型、优先级等信息。

本发明实施例针对业务数据进行加密的应用场景，即服务器响应终端设备的访问请求时返回的所有业务数据均以密文形式传输给终端设备。服务器接收到终端设备发送的应用访问请求后，对响应该应用访问请求的业务数据进行加密，得到第一业务数据；同时，获取该第一业务数据的应用信息，该应用信息表征第一业务数据的业务内容。

参见图3，示出了本发明实施例一种应用信息的消息格式示意图，如图3所示，应用信息包括h-length(总长度)和flow-info(流信息)两个字段。

h-length：表示整个应用信息头的总长度；

flow-info：是一个可变长字段，可以包含一个或多个信息段(info)；每个信息段(info)均包含3个字段：type(类型)、t-length(长度)和sub-information(子信息)，这3个字段的具体含义参见表1；

其中，type，表示后续sub-information字段的类型；

t-length，表明本info字段的长度；

sub-information，表示本info字段携带的具体信息内容。

表1

s130，服务器将第一业务数据及应用信息提供给感知节点。

服务器将应用信息提供给感知节点，以便感知节点获取服务器传递给终端设备的业务数据的业务信息，进而使业务感知系统完成与业务信息相关的服务。

在本发明的一些实施例中，服务器内部署有封包设备，服务器通过该封包设备将第一业务数据及应用信息进行重封包，并转发给感知节点。

在本发明的另一些实施例中，封包设备独立于服务器部署，服务器将第一业务数据及应用信息发送给封包设备，封包设备将第一业务数据及应用信息进行重封包之后转发给感知节点。

在本发明的又一个实施例中，服务器可以直接将应用信息和第一业务数据提供给感知节点。

针对上述几个具体实施方式，后面将详细介绍，此处不再详述。

s140，感知节点利用所述应用信息识别所述第一业务数据的业务信息。

感知节点根据接收到的应用信息，确定所述第一业务数据的业务信息，例如，业务类型等信息。

s150，感知节点转发第一业务数据，或者，第一业务数据和应用信息。

在本发明的一些实施例中，感知节点可以只将第一业务数据转发给下一个节点，不需要转发应用信息；

在本发明的另一些实施例中，感知节点可以将第一业务数据和应用信息都转发给下一个节点。

其中，下一个节点可能是终端设备、下一个感知节点，或其它感知业务系统(例如， 父子账号系统)。本实施例提供的数据传输方法，在服务器向终端设备发送加密业务数据的过程中，服务器将感知节点需要的应用信息传递给感知节点，从而使感知节点能够根据该应用信息获知终端设备与服务器之间传输的加密业务数据的业务信息，进而使感知业务系统完成与业务内容相关的服务。其中，应用信息以明文方式传输，不需要服务器额外增加加解密协议簇，在保证终端设备与服务器之间业务数据加密的前提下，数据传输更方便、系统成本更低。

参见图4，为本发明实施例提供的一种数据传输方法的流程图，该方法应用于图1所示的系统，本实施例中，封包设备独立于服务器部署，例如，封包设备可以是任何能够对数据进行拆包、封包的设备。如图4所示，所述数据传输方法包括：

s210，终端设备向服务器发送应用访问请求。

s220，服务器根据接收到的应用访问请求，获取加密后的第一业务数据及与第一业务数据对应的应用信息，并将第一业务数据及应用信息发送给封包设备。

封包设备独立于服务器，服务器以发送消息的方式通过网络连接将应用信息发送给封包设备，通知封包设备对该应用信息和业务数据进行重封装。

s230，封包设备生成第一数据包；该第一数据包包括消息头和载荷，该消息头承载所述应用信息，所述载荷承载所述第一业务数据。

封包设备接收到服务器发送的应用信息后，缓存在本地，并向服务器返回确认信息。然后，封包设备接收服务器发送的第一业务数据，根据该第一业务数据的特征信息(例如，业务数据的特征信息可以是五元组，五元组包括源ip地址、源端口、目的ip地址、目的端口和传输层协议，用于区分不同的数据报文)查询本地是否存在与该第一业务数据匹配的应用信息，如果存在，则封包设备修改该第一业务数据，重新封装第一业务数据的报文头，将与该第一业务数据匹配的应用信息写入该第一业务数据的报文头中，从而生成第一数据包。其中，可以将应用信息写入报文头的可选字段中，或者，可以在报文头中增加新的字段用来承载该应用信息。

s240，封包设备将第一数据包发送给感知节点。

封包设备将重新封装得到的第一数据包发送给感知节点。

s250，感知节点从所述第一数据包中提取所述应用信息生成第二数据包，并根据应用信息识别所述第一业务数据的业务信息，其中，第二数据包包含第一业务数据。

感知节点解析接收到的第一数据包，判断第一数据包中是否携带应用信息，如果携带应用信息，则从第一数据包中提取应用信息，并查询本地流表(该流表用于存储接收到的各个业务数据对应的应用信息)中是否存在该应用信息；如果已经存在相应的流表 条目，则根据接收到的应用信息刷新流表条目中记录的流应用信息；如果不存在相应的流表条目，则新增流表条目并记录接收到的应用信息插入流表中。初始状态下，流表内没有应用信息的流表条目。

s260，感知节点转发所述第二数据包，或所述第一数据包。

第二数据包包含第一业务数据，第一数据包包含第一业务数据及第一业务数据对应的应用信息。

在本发明的一些应用场景中，需要保证终端设备与服务器之间收发的数据一致，因此，在此种应用场景下，感知节点需要对封包设备重新封装后的第一数据包还原成原始的第一业务数据：感知节点将应用信息从第一数据包的报文头中剥离出来，将第一数据包的报文还原成第一业务数据的报文，并转发给下一个节点。

在本发明的另一些应用场景中，不需要保证终端设备接收的数据与服务器发送的数据完全一致，因此，在此种应用场景下，感知节点可以直接将封包设备重新封装的第一数据转发给下一个节点。

图1所示的系统中可能包含多个感知节点，具体在哪个感知节点上还原业务数据报文，可以根据感知节点提供方自行确定。

本实施例提供的数据传输方法，在服务器向终端设备发送加密业务数据的过程中，服务器将感知节点需要的应用信息传递给感知节点，从而使感知节点根据应用信息获知终端设备与服务器之间传输的加密业务数据的业务信息，进而使感知业务系统完成与业务信息相关的服务。其中，应用信息以明文方式传输，不需要服务器额外增加加解密协议簇，在保证终端设备与服务器之间业务数据加密的前提下，数据传输更方便、系统成本更低。

参见图5，为本发明实施例提供的另一种数据传输方法的流程图，本实施例以父子账号系统为例，介绍父子账号系统与图1所示的系统采用图4所示的数据传输方法完成内容过滤服务。

父子账号系统用于根据互联网的数据内容进行过滤，过滤掉不适宜儿童访问的数据，从而保证儿童上网环境健康安全。

图5中的s210～s260与图4中标号相同的步骤相同，此处不再赘述，其中，s260中，感知节点将第一数据包或第二数据包转发给父子账号系统；其中，第一数据包包含第一业务数据及第一业务数据对应的应用信息；第二数据包包含第一业务数据。

s310，父子账号系统向感知节点发送业务查询消息。业务查询消息用于向感知节点查询第一业务数据的应用信息，该业务查询消息携带第一业务数据的特征信息，例如， 五元组信息。

s320，感知节点接收到业务查询消息后，根据特征信息查询本地的流表获得与该特征信息相匹配的应用信息。

感知节点接收到业务查询消息后，根据查询消息所携带的业务数据的特征信息查询本地流表中是否存在与该特征信息相匹配的流表条目，如果存在，则获取该流表条目中的应用信息；如果不存在，则结束当前流程。

s330，感知节点将获得的应用信息反馈给父子账号系统。

s340，父子账号系统根据应用信息判断第一业务数据能否被子账号访问，如果是，则执行s350；如果否，则执行s360。

s350，将接收到的第一业务数据发送给终端设备。

s360，向终端设备发送错误代码。例如，403forbidden。

其它基于业务感知的业务中数据传输业务与父子账号业务相似，此处不再一一介绍。

本实施例提供的数据传输方法，感知节点将还原得到的第一业务数据发送给感知业务系统，感知业务系统向感知节点查询该第一业务数据的应用信息，从而在业务数据加密的情况下能够识别该第一业务数据的业务信息，进而对第一业务数据进行相应的处理。

参见图6，为本发明实施例提供的另一种数据传输方法的流程图，该方法应用于图1所示的系统中。本实施例中，封包设备部署在服务器中，例如，在服务器的协议栈中实现相关功能，即服务器发出的业务数据就包含了应用层信息，该应用层信息以明文形式存储。如图6所示，该方法包括：

s410，终端设备向服务器发送应用访问请求。

s420，服务器根据接收到的应用访问请求，获取加密后的第一业务数据及与第一业务数据对应的应用信息。

s430，服务器调用封包设备生成第一数据包。第一数据包包括消息头和载荷，其中，消息头承载应用信息，载荷承载第一业务数据。

服务器可以通过调用扩展socketapi(applicationprogramminginterface，应用程序编程接口)函数调用封包设备。

s440，服务器将第一数据包发送给感知节点。

s450，感知节点从第一数据包中获得应用信息生成第二数据包，并根据所述应用信息识别所述第一业务数据的业务信息；其中，第二数据包包含第一业务数据。

s460，感知节点将第二数据包或第一数据包转发给下一个节点。

在本发明的一些实施例中，由于封包设备部署在服务器内，即服务器输出的第一数 据包中携带应用信息，为了保证终端设备和服务器之间收发的数据一致，感知节点不需要对第一数据包的报文进行修改，直接转发给下一个节点即可。

本实施例提供的数据传输方法，由部署在服务器内部的封包设备对应用信息和第一业务数据进行重新封装，得到第一数据包并发送给感知节点。感知节点从第一数据包中获取应用信息，并根据应用信息识别第一业务数据的业务信息。而且，感知节点不需要对第一数据包进行修改直接转发给下一个节点即可。该方法需要服务器侧集成封包设备的功能，但感知节点不需要修改第一数据包。

应用信息可以直接携带于业务数据流的报文中，称为带内传输方式；应用信息也可以独立于业务数据流进行传输，称为带外传输方式。其中，带内传输方式可以将应用信息写入到传输业务数据流所使用的协议报头中，例如，tcp协议、tls(transportlayersecurity，安全传输层)协议、ip(internetprotocol，网络协议)协议、udp(userdatagramprotocol，用户数据报协议)等，本发明对此并不限定。将应用信息携带到哪个协议报头中，需要根据具体应用场景确定。带外传输方式，即应用信息独立于终端设备与服务器之间的业务数据流，例如，可以通过icmp(internetcontrolmessageprotocol，网络控制报文协议)协议报文或其它协议报文单独承载应用信息，本发明对此并不限定。

下面结合图7～图10分别介绍以下几种应用场景：

在终端设备与服务器之间采用tcp(transmissioncontrolprotocol，传输控制协议)协议作为传输层协议的应用场景中，应用信息可以承载于tcp协议报文中。

参见图7，为本发明实施例提供的一种tcp协议报文的消息格式示意图，应用信息可以填写到tcp协议的可选项字段。

其中，tcp协议报文中各个字段的含义如下：

源端口号：16位，标识出远端的端口号。

目的端口号：16位，标识出本地的端口号。

序列号：32位，表明发送的数据报的顺序。

确认序列号：32位，希望收到的下一个数据报的序列号。

首部长度：4位，表明tcp报头中包含多少个32位字。

接下来的6位保留未用。

urg(紧急位)：当urg＝1时，表示该报文应尽快传送不需要按本来的列队次序来传送。tcp的紧急方式是发送端向另一端发送紧急数据的一种方式，与紧急指针字段共同应用，紧急指针指向数据报内的某个字节，表示数据报内从第一字节到紧急指针所指 字节都是紧急数据，不进入接收缓冲就直接交给上层进程，其它的数据进入接收缓冲。

ack(acknowledgement，确认字符)：ack为1，表明确认序列号合法；如果ack为0，表明数据报不包含确认信息，确认字段被省略。

psh(push，推送)：当psh为1时，表示是带有push标志的数据，接收方请求数据报立即传送给应用程序而不必等到缓冲区装满时才传送。

rst(复位)：表示连接复位请求，用于复位由于主机崩溃或其它原因而出现的错误连接；还可以用于拒绝非法的数据报或拒绝连接请求。

syn(同步序号)：用于建立连接。

fin(final，结束信号)：表示发送端已经达到数据末尾，即，双方的数据传送完成连接将被断开。

窗口大小：16位，表示在确认了字节之后还可以发送多少个字节。

校验和：16位，是为了确保高可靠性而设置的。它校验头部、数据和伪tcp头部之和。

applicationinfooption(应用信息选项)：0个或多个32位字，本实施例中该字段用于承载业务数据的应用信息，其中，该字段包括option(选项)和padding(增加)两项，option项承载应用信息。

data(数据)：该字段用于承载业务数据。

在终端设备与服务器之间采用tls协议作为传输层加密协议的应用场景中，业务数据的应用信息可以以明文的方式写入tls协议报文的报头中。

参见图8，为本发明实施例提供的一种tls协议报文的消息格式示意图，应用信息可以写入tls报头的version字段和length字段之间。

如图8所示，tls协议报文中各个字段的含义如下：

type(类型)：表示后续字段的类型。

version(版本)：表示协议的版本信息。

applicationinfo(应用信息)：该字段为写入的应用信息，应用信息的消息格式如图3所示。

length(长度)：表示tsl帧报头的长度，用于示意应用信息在tls数据帧中的位置。

本领域技术人员可以理解的是，某些传输层的协议，例如，tcp、udp等，在传输层报头中加入一些校验、长度字段，封包设备在修改了tls报头写入应用信息的同时， 需要修改传输层底层协议的报头中的相关字段，避免后续节点处理错误。

在终端设备与服务器采用ip作为承载协议(基本所有互联网流量均使用ip协议)的应用场景中，应用信息可以写入到ip报头中。

参见图9，为本发明实施例提供的一种ipv4协议报文的消息格式示意图，应用信息填写到options字段中。

其中，ipv4协议中各个字段的含义如下：

ver(version，版本号)：4位，协议版本号是4，因此称作ipv4。

ihl(internetheaderlength，报头长度)：报头长度，4位，首部长度是指ip层头部占32位字的数目，即，ip层头部包含多少个4字节，包括任何选项。

tos(typeofservice，服务类型)：8位，指出上层协议对处理当前数据报所期望的服务质量，并对数据报按照重要性级别进行分配。这个字段用于分配优先级、延迟、吞吐量以及可靠性等。

totallength(ip包总长度)：指定整个ip数据包的字节长度，包括数据和协议头；其最大值为65,535字节，典型的主机可以接收576字节的数据报。

identification(标识符)：16位，该字段用于识别当前数据报。该字段由发送端分配帮助接收端集中数据报分片。

flags(标记)：3位，其中最低位(mf)控制分片，存在下一个分片置为1，否则置0代表结束分片。中间位(df)指出数据包是否可进行分片。第三位即最高位保留不使用，但是必须为0。

fragmentoff(fragmentoffset，片偏移)：13位，指出与源数据报的起始端相关的分片数据位置，支持目标ip适当重建源数据报。

ttl(timetolive，生存期)：8位，是一种计数器，在丢弃数据报的每个点值依次减1直至减少为0。这样确保数据包无止境的环路过程。

protocol(协议)：8位指出在ip处理过程完成之后，有哪种上层协议接收导入数据包。

headerchecksum(头部校验)：16位，帮助确保ip协议头的完整性。由于某些协议头字段的改变，如ttl，需要对每个点重新计算和检验。internet协议头需要进行处理。

sourceaddress(源地址)：32位，源主机ip地址。

destinationaddress(目标地址)：32位，目标主机ip地址。

applicationinfooptions(应用信息项)：该字段用于填充应用信息，其中，应用信息的消息格式如图3所示。

data(数据)：数据字段。

参见图10，为本发明实施例提供的一种ipv6协议报文的消息格式示意图，在ipv6的extensionheader(扩展头)字段中。

如图10所示，ipv6报头包含的各个字段的含义如下：

version(版本号)：4位，ip协议版本号，ipv6的版本号为6。

trafficclass(通信类别)：8位，指示ipv6数据流通信类别或优先级。功能类似于ipv4的tos字段。

flowlabel(流标记)：20位，ipv6新增字段，标记需要ipv6路由器特殊处理的数据流。该字段用于某些对连接的服务质量有特殊要求的通信，诸如音频或视频等实时数据传输。在ipv6中，同一信源和信宿之间可以有多种不同的数据流，彼此之间以非“0”流标记区分。如果不要求路由器做特殊处理，则该字段值置为“0”。

payloadlength(负载长度)：16位，负载长度包括扩展头和上层pdu(packetdataunit，分组数据单元)，16位最多可表示65535字节负载长度。超过这一字节数的负载，该字段值置为“0”，使用扩展头逐个跳段(hop-by-hop)选项中的巨量负载(jumbopayload)选项。

nextheader(下一包头)：8位，识别紧跟ipv6头后的包头类型，如扩展头(如果有扩展头)或某个传输层协议头(诸如tcp，udp或者icmpv6)。

hoplimit(跳段数限制)：8位，类似于ipv4的ttl字段，用数据包在路由器之间的转发次数来限定包的生命期。数据包每经过一次转发，该字段减1，减到0时就把这个包丢弃。

sourceaddress(源地址)：128位，发送方主机地址。

destinationaddress(目的地址)：128位，在大多数情况下，目的地址即信宿地址。但如果存在扩展头的话，目的地址可能是发送方路由表中下一个路由器接口。

applicationinfoextensionheader(应用信息扩展头)：应用信息填写在该字段中。

data(数据)：该字段填写数据。

终端设备与服务器之间的业务数据流基于udp协议进行传输的应用场景中，可以将应用信息写入udp协议报头以后的字段中。

参见图11，为本发明实施例提供的一种udp协议的消息格式示意图，如图11所示， udp协议包含的各个字段的含义如下：

源端口号：远端的端口号；

目的端口号：本地的端口号；

长度：整个报头的长度，以字节为单位；

校验和：确保高可靠性，校验头部和数据之和；

前导符(增加字段)：用于标识后续数据中包含应用信息；

applicationinfo(应用信息)：标识终端设备与服务器之间业务数据流所对应的应用信息；

data：此字段为数据字段。

在本发明的另一些实施例中，应用信息还可以通过带外传输方式进行传输，即应用信息独立于终端设备与服务器之间的业务数据流；应用信息与业务数据流分别单独传输，因此，还需要为业务数据流与应用信息建立关联，例如，在应用信息中包含终端设备与服务器之间的业务数据流的特征信息，例如，五元组，或特征字串，以便感知节点接收到应用信息后，能够根据该特征信息将应用信息与业务数据进行映射，从而正确建立本地应用信息的流表。

参见图12，为本发明实施例提供的一种icmp的协议消息格式示意图，应用信息可以在icmp协议中写入应用信息。如图12所示，icmp协议包含的各个字段的含义如下：

type(类型)：8位，标识icmp报文的类型；

code(代码)：8位，该字段与type字段共同决定了icmp报文的类型；

icmpchecksum(icmp包校验和)：包括数据在内的整个icmp报文的校验和；

applicationinfo(应用信息)：该字段承载应用信息，该字段内还应该包含业务数据流的特征信息。

下面将介绍通过带外传输方式传输应用信息时，各个节点的操作：服务器将应用信息及与该应用信息对应的业务数据的特征信息，传递给封包设备。封包设备根据应用信息及业务数据的特征信息生成通知消息，该通知消息包括应用信息及特征信息，并传输给感知节点。感知节点解析收到的通知消息，获得应用信息及业务数据的特征信息，并建立应用信息的流表；与此同时，服务器将业务数据流发送给封包设备，封包设备对该业务数据流不做任何修改直接转发给感知节点，感知节点再将该业务数据转发给下一个节点(终端设备、其它基于业务感知的业务系统或下一个感知节点)。

在另一种场景中，通过带外传输方式传输应用信息时，不需要对业务数据流做任何 修改，因此，在此应用场景中可以不设置封包设备。这样，业务数据对应的应用信息及特征信息由服务器封装成设定协议格式的通知消息，然后，将该通知消息发送给感知节点，感知节点解析该通知消息获得应用信息，并建立应用信息的流表。与此同时，服务器向感知节点发送业务数据流，感知节点通过业务数据的特征信息，查询应用信息流表，获知该业务数据流的应用信息。然后，感知节点将业务数据流转发给下一个节点。

相应于上述的数据传输方法实施例，本申请还提供了相应的装置实施例。

参见图13，为本发明实施例提供的一种服务器的框图，该服务器应用于互联网通信系统中，该系统包括终端设备、服务器和感知节点。如图13所示，该服务器包括：接收器210、处理器220和发送器230。

接收器210用于接收终端设备发送的应用访问请求，并传递给处理器220。

处理器220用于根据接收器210传递的应用访问请求获取加密后的第一业务数据及该第一业务数据对应的应用信息。其中，该应用信息用于表征第一业务数据的业务信息。

发送器230用于将处理器220获得的第一业务数据及应用信息提供给感知节点，从而使感知节点利用该应用信息识别第一业务数据的业务信息。

在本申请的一些实施例中，处理器220用于根据第一业务数据及对应的应用信息生成第一数据包，其中第一数据包包括消息头和载荷，该消息头承载应用信息，载荷承载第一业务数据。并由发送器230将处理器220生成的第一数据包发送给互联网通信系统中的感知节点。

在本申请的另一些实施例中，互联网通信系统还包括用于对数据进行重新封装的封包设备；在此种应用场景下，发送器230将应用信息及第一业务数据发送给封包设备，由封包设备根据应用信息和第一业务数据生成第一数据包，并由封包设备将第一数据包发送给感知节点；其中，封包设备生成的第一数据包包括消息头和载荷，消息头承载应用信息，载荷承载第一业务数据。

无论是服务器生成的第一数据包，还是封包设备生成的第一数据包，应用信息携带于第一业务数据的报文中进行传输，即带内传输方式；此种传输方式下，第一数据包所包含的消息头均可以包括tcp报文头、tls报文头、ip报文头或udp报文头。

在本申请的另一些实施例中，应用信息还可以以带外传输方式进行传输，即应用信息不携带于终端设备与服务器之间传输的业务数据中，即，业务数据及业务数据的应用信息分别单独传输。此种应用场景下，需要建立业务数据与应用信息之间的关联，以便感知节点获知业务数据关联的应用信息。

发送器230将第一业务数据发送给感知节点，同时，将第一业务数据对应的应用信 息及第一业务数据的特征信息发送给感知节点，以便感知节点根据特征信息建立第一业务数据及应用信息之间的关联。进而使感知节点根据应用信息识别第一业务数据的业务信息。

在本申请的一些实施例中，通过带外传输方式传输应用信息时，服务器将应用信息及第一业务数据的特征信息发送给封包设备，由封包设备根据应用信息及特征信息生成通知消息，该通知消息的消息头中包含该应用信息和特征信息，然后，封包设备将通知消息发送给感知节点。

在本申请的另一些实施例中，由服务器的处理器220直接根据第一业务数据的应用信息及特征信息生成通知消息，该通知消息的消息头中携带应用信息及特征信息。

本实施例提供的服务器，在向终端设备发送加密业务数据的过程中，服务器将感知节点需要的应用信息传递给感知节点，从而使感知节点能够根据该应用信息获知终端设备与服务器之间传输的加密业务数据的业务信息，进而使感知业务系统完成与业务内容相关的服务。其中，应用信息以明文方式传输，不需要服务器额外增加加解密协议簇，在保证终端设备与服务器之间业务数据加密的前提下，数据传输更方便、系统成本更低。

参见图14，为本发明实施例提供的一种封包设备的框图，该封包设备应用于互联网通信系统中，该系统包括服务器、感知节点和终端设备。如图14所示，该封包设备包括接收器310、处理器320和发送器330。

接收器310用于接收服务器发送的第一业务数据，以及，与所述第一业务数据对应的应用信息。

处理器320用于根据第一业务数据及应用信息生成第一数据包，所述第一数据包包括消息头和载荷，所述消息头承载所述应用信息，所述载荷承载所述第一业务数据。

发送器330用于将所述第一数据包发送给所述感知节点，以便所述感知节点根据所述应用信息识别所述第一业务数据的业务信息。

在本申请的一些实施例中，封包设备需要对服务器发送的第一业务数据对应的应用信息及特征信息进行重新封装，此种应用场景下，接收器310用于接收服务器发送的第一业务数据的应用信息及特征信息；处理器320用于根据接收到的应用信息及特征信息生成通知消息，在通知消息的消息头中携带应用信息及特征信息。发送器330用于将处理器320生成的通知消息发送给感知节点，以使感知节点根据特征信息建立第一业务数据与应用信息之间的管理，进而使感知节点根据应用信息识别第一业务数据的业务信息。

本实施例提供的封包设备，根据接收到的服务器发送的第一业务数据及对应的应用信息生成第一数据包，即，将应用信息写入第一业务数据的消息头中，从而使感知节点 在接收到第一业务数据的同时，能够获得该第一业务数据的应用信息，并根据该应用信息识别第一业务数据的业务信息，完成与业务内容相关的服务。其中，应用信息以明文方式传输，不需要服务器额外增加加解密协议簇，在保证终端设备与服务器之间业务数据加密的前提下，数据传输更方便、系统成本更低。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。