CN112040513A - 一种数据传输方法、数据传输装置及数据传输系统 - Google Patents

Abstract

本申请公开了一种数据传输方法、数据传输装置及数据传输系统。其中，该方法应用于报文的发送端，包括：当存在待发送的报文时，获取第一QoS配置信息，第一QoS配置信息为发送端在发送方向上的QoS配置信息；若基于第一QoS配置信息，确定第一流在报文的发送方向上的状态为允许状态，则获取第二QoS配置信息，第二QoS配置信息为报文的接收端在接收方向上的QoS配置信息，第一流为报文所对应的发送端的本地流；若基于第二QoS配置信息，确定第一流在报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送报文，以指示物理转发设备向接收端转发报文。本申请方案可减少对网络资源的浪费，增加系统的安全性。

Description

一种数据传输方法、数据传输装置及数据传输系统

技术领域

本申请属于通信技术领域，尤其涉及一种数据传输方法、数据传输装置及数据传输系统。

背景技术

云计算的核心思想是通过资源复用和协调编排，来提高资源的使用率和业务上线效率，从而降低成本并促进业务创新。用户的业务通常部署在物理机，虚拟机或者容器中，一台物理服务器会运行多个虚拟机或容器。云计算数据中心的网络转发路径一般是由虚拟实例出发，经历虚拟网络设备、虚拟交换路由设备、物理网卡、物理交换路由设备、网关设备及网络管理中台等多个组件。当前的服务质量(Quality of Service，QoS)机制仅基于单个的物理节点(也即物理组件)而实现，考虑到网络转发路径涉及的组件较多，这仍无法有效避免网络资源浪费和安全风险。

发明内容

本申请提供了一种数据传输方法、数据传输装置及数据传输系统，可减少对网络资源的浪费，增加系统的安全性。

第一方面，本申请提供了一种数据传输方法，应用于报文的发送端，包括：

当存在待发送的报文时，获取第一QoS配置信息，上述第一QoS配置信息为上述发送端在发送方向上的QoS配置信息；

若基于上述第一QoS配置信息，确定第一流在上述报文的发送方向上的状态为允许状态，则获取第二QoS配置信息，上述第二QoS配置信息为上述报文的接收端的接收方向上的QoS配置信息，上述第一流为上述报文所对应的上述发送端的本地流；

若基于上述第二QoS配置信息，确定上述第一流在上述报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送上述报文，以指示上述物理转发设备向上述接收端转发上述报文。

第二方面，本申请提供了一种数据传输方法，应用于报文的接收端，包括：

当接收到报文的发送端所发送的报文时，获取第二QoS配置信息，上述第二QoS配置信息为上述接收端在接收方向上的QoS配置信息；

若基于上述第二QoS配置信息，确定第二流在上述报文的接收方向上的状态为允许状态，则对上述报文进行处理，上述第二流为上述报文所对应的上述接收端的本地流。

第三方面，本申请提供了一种数据传输装置，应用于报文的发送端，包括：

第一获取单元，用于当存在待发送的报文时，获取第一QoS配置信息，上述第一QoS配置信息为上述发送端在发送方向上的QoS配置信息；

第二获取单元，用于若基于上述第一QoS配置信息，确定第一流在上述报文的发送方向上的状态为允许状态，则获取第二QoS配置信息，上述第二QoS配置信息为上述报文的接收端的接收方向上的QoS配置信息，上述第一流为上述报文所对应的上述发送端的本地流；

发送单元，用于若基于上述第二QoS配置信息，确定上述第一流在上述报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送上述报文，以指示上述物理转发设备向上述接收端转发上述报文。

第四方面，本申请提供了一种数据传输装置，其特征在于，应用于报文的接收端，包括：

第三获取单元，用于当接收到报文的发送端所发送的报文时，获取第二QoS配置信息，上述第二QoS配置信息为上述接收端在接收方向上的QoS配置信息；

处理单元，用于若基于上述第二QoS配置信息，确定第二流在上述报文的接收方向上的状态为允许状态，则对上述报文进行处理，上述第二流为上述报文所对应的上述接收端的本地流。

第五方面，本申请提供了一种数据传输系统，上述数据传输系统包括报文的发送端及报文的接收端，其中，上述发送端实现如上第一方面的方法，上述接收端实现如上第二方面的方法。

本申请与现有技术相比存在的有益效果是：在通信过程中，通过对发送端在发送方向上的QoS配置信息及接收端在接收方向上的QoS配置信息，来判断报文所对应的流的状态并以此决定是否可以向外发送报文。也即，通信过程中不仅考虑己方的发送能力，而且也会考虑对方的接收能力。而且，报文的发送端及接收端作为通信实体，往往为虚拟实例，也即，上述过程也对虚拟组件的QoS也予以考虑，能够减少对网络资源的浪费，增加系统的安全性。可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

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

图1是本申请实施例提供的现有的虚拟专有云的系统架构示意图；

图2是本申请实施例提供的改进后的虚拟专有云的系统架构示意图；

图3是本申请实施例提供的应用于报文的发送端的数据传输方法的实现流程示意图；

图4是本申请实施例提供的应用于报文的接收端的数据传输方法的实现流程示意图；

图5是本申请实施例提供的应用于报文的发送端的数据传输装置的结构框图；

图6是本申请实施例提供的应用于报文的接收端的数据传输装置的结构框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

请参阅图1，图1示出了云计算数据中心的虚拟专有云(Virtual Private Cloud，VPC)的系统架构。其中，云计算数据中心的网络转发路径一般会经历如下几个组件：

虚拟实例：用户业务的计算实体，可以是一个进程、虚拟机或者容器。

虚拟网络设备(未在图1中示出)：可以分配给虚拟实例使用的虚拟网络设备，与物理网卡类似。同一个服务器的虚拟实例独占一个或者多个虚拟网络设备。

虚拟交换路由设备：通常是运行于服务器内的软件交换路由实体。其下行连接虚拟网络设备，上行连接物理网卡。多个虚拟实例共享一个虚拟交换路由设备。

物理网卡：运行于服务器上的物理网卡，同一个服务器的虚拟实例共享物理网卡。

物理交换路由设备：云计算数据中心的网络设备，互联通信的物理终端。多个服务器的虚拟实例共享物理交换路由设备。

云网关：这里特指云的边缘网关，其主要作用是连接云虚拟网络和物理网络。多个服务器的虚拟实例共享云网关。

网络管理中台：用于管理、监控及配置物理网络和虚拟网络的业务平台，通常可以监控各个组件的运行状态，配置网络业务，对外提供网络业务API接口，实现网络自动化，也可以称做网络控制器。

在基于上述架构的转发路径中，虚拟路由交换设备、物理网卡、物理路由交换设备及云网关都是网络资源复用比例很高的设备。在当前的互联网背景下，大数据业务突发性增长已成常态，很容易造成网络拥塞和丢包的情况。然而，目前较为成熟的QoS方案只能在单个的物理组件上运行，无法或难以在虚拟组件上运行，这带来了网络资源浪费和安全风险。基于此，本申请提出了一种数据传输方法、数据传输装置及数据传输系统，可减少对网络资源的浪费，增加系统的安全性。为了说明本申请的技术方案，下面通过具体实施例来进行说明。

请参阅图2，本申请实施例中，对现有的VPC的系统架构进行了改进，新增了QoS业务子系统(QoS-S)，QoS业务控制子系统(QoS-C)和QoS业务代理子系统(QoS-A)。下面对各个子系统的原理及功能进行解释及说明：

对于QoS-S来说：

在传统网络业务的基础上，网络业务平台新增加QoS-S。其作为网络业务平台的主要子系统，是系统的用户接口，提供配置、监控、分析及干预系统QoS资源分配和调度的操作界面，并给出系统运行报告和改进建议。

QoS-S还新增加了虚拟实例的QoS指标及QoS配置信息，用于描述虚拟实例在接收及发送方向上的网络能力。一些QoS指标可以通过QoS-C和QoS-A来获取该指标的实时数据(也即QoS指标值)。主要涉及到的QoS指标及QoS配置信息的说明如下：

接收方向带宽(Receiving Direction Bandwidth，RBW)：虚拟实例当前接收方向的带宽；

接收方向最大预留带宽(Receiving Direction Maximum Reserved Bandwidth，RMRBW)：虚拟实例最大允许的接收方向带宽；

接收方向访问控制列表(Receiving Direction Access Control List，RACL)：虚拟实例接收方向的访问控制列表；

接收方向访问控制列表丢包数目(Receiving Direction Access Control ListDrop Number，RACLDN)：虚拟实例接收方向ACL丢包数目；

接收方向最近1分钟带宽(Receiving Direction Latest Bandwidth，RLBW)：虚拟实例最近1分钟的接收带宽；

发送方向带宽(Transmitting Bandwidth，TBW)：虚拟实例当前发送方向的带宽；

发送方向最大预留带宽(Transmitting Direction Maximum ReservedBandwidth，TMRBW)：虚拟实例最大允许的发送方向的带宽；

发送方向访问控制列表(Transmitting Direction Access Control List，TACL)：虚拟实例发送方向的ACL；

发送方向最近1分钟最大带宽(Transmitting Direction Latest Bandwidth，TLBW)：虚拟实例最近一分钟带宽；

最大缓冲区队列数目(Maximum Buffer Queue Length，MBQN)：虚拟实例网卡的最大队列数目；

最大缓冲区队列长度(Maximum Buffer Queue Number，MBQL)：虚拟实例网卡的队列长度；

当前流数(Flow Count，FN)：虚拟实例实时流数目，统计当前虚拟实例的通信情况；

最大预留流数(Flow Count，MRFN)：虚拟实例最大允许流数目，防止出现过载情况；

服务质量转发动作(QoS Forwarding Action，QFA)：服务质量转发动作,可以基于报文中携带的PCP、DSCP及EXP标识位做出对应的转为行为，比如延时优先、吞吐量优先或者丢弃处理。

除此之外，QoS-S还新增加了物理交换路由设备的QoS指标及QoS配置信息，用于描述物理交换路由在接收及发送方向上的网络能力。一些QoS指标可以通过QoS-C和QoS-A来获取其实时数据(也即QoS指标值)。主要涉及到的QoS指标及QoS配置信息的说明如下：

端口的发送带宽(Transmitting Port Bandwidth，TPBW)：物理交换路由设备端口的发送带宽；

端口的接收带宽(Receiving Port Bandwidth，RPBW)：物理交换路由设备端口的接收带宽；

端口的最大发送预留带宽(Transmitting Direction Port ReservedBandwidth，TPRBW)：交换路由设备端口的最大发送带宽；

端口的最大接收预留带宽(Receiving Direction Port Reserved Bandwidth，TRPRBW)：交换路由设备端口的最大接收带宽。

对于QoS-C来说：

网络管理中台新增加QoS-C，其起到承上启下的作用，对上和QoS-S交换数据，对下同虚拟交换路由设备、物理交换路由设备及云网关中的QoS-A交换数据。其支持API、OpenFlow及Netconf配置接口。具体地，对于虚拟网元，比如虚拟交换路由设备，可采用API或OpenFlow协议交换数据；对于物理网元，比如物理交换路由设备或者云网关，可采用Netconf协议交换数据。对于网络业务平台提供Rest Api接口，便于兼容不同的网络业务平台。

QoS-C还集成了网络QoS优化功能，其主要根据采集到的指标数据实时优化系统的QoS质量。

对于QoS-A：

QoS-A根据底层平台的不同，可以包括用户态进程和内核态进程，或者完全用户态进程及网卡组件，分别完成各项QoS指标值的采集、计算及汇总，以及网络报文指令的操作。

对于虚拟交换路由设备，QoS-A主要采集虚拟实例的QoS指标值(上文已介绍)，计算并汇总后上报给网络管理中台。

对于物理交换路由设备，QoS-A主要采集物理交换路由设备的端口转发情况，也即物理交换路由设备的QoS指标值(上文已介绍)，计算并汇总后上报给网络管理中台。

基于上述对VPC的系统架构的改进，下面对本申请实施例提供的一种数据传输方法进行描述，该数据传输方法应用于报文的发送端，也即通信过程中发送报文的一方。请参阅图3，该数据传输方法包括：

步骤301，当存在待发送的报文时，获取第一QoS配置信息；

在本申请实施例中，在通信开始前，需要通过网络业务平台开启虚拟实例的网络QoS-S中的参数设置，也即，设置各个虚拟实例在接收及发送方向上的配置信息。一般来说，可以对不同的虚拟实例设置不同的缺省值；并且，根据实际应用场景的不同，还可以分别在公网业务的参数设置场景下及私网业务的参数设置场景下设置不同的缺省值。上述缺省值可以是根据理论和实践证明的推荐最佳值。需要注意的是，上述缺省值可由系统主动进行智能分析后设置，也可由后台人员人工手动设置，此处不作限定。

当有一虚拟实例需要发送报文时，该虚拟实例即为报文的发送端。此时，QoS-A会基于QoS-S对该虚拟实例的配置，来获取到第一QoS配置信息，其中，该第一QoS配置信息指的是该虚拟实例在发送方向上的QoS配置信息。基于上文对QoS配置信息的介绍，此处的QoS配置信息具体包括：TACL、TMRBW、MBQN、MBQL及QFA。

在一些实施例中，当该虚拟实例是向一个新的接收端发送报文时，还需要对该虚拟实例的本地流的数目进行检测，以确定是否超出其处理能力。则上述步骤301可具体表现为：

A1、根据上述报文的报文特征，确定上述发送端是否已存在上述第一流；

其中，报文特征包括：通信协议、源IP地址、目的IP地址、源端口、目的端口。一组报文特征即定义了一条流。基于此，可根据待发送的报文的报文特征，确定发送端的本地是否已存在该报文所对应的流，也即第一流。

A2、若已存在上述第一流，则获取第一QoS配置信息；

A3、若不存在上述第一流，则检测上述发送端的当前流数目是否满足预设的发送端的流条件；

其中，当发送端的本地已存在该第一流时，可直接获取第一QoS配置信息。当发送端的本地还不存在该第一流时，则需要检测发送端的当前流数目是否满足预设的发送端的流条件。其中，发送端的当前流数目为上文所提出的一项QoS指标FN，该发送端的流条件可基于该发送端的QoS配置信息而得。基于上文对QoS配置信息的介绍，此处的QoS配置信息具体包括MRFN。该预设的发送端的流条件为：发送端的FN小于发送端的MRFN。

A4、若上述发送端的当前流数目满足上述发送端的流条件，则建立上述第一流，并获取第一QoS配置信息。

其中，当检测发现发送端的FN小于发送端的MRFN时，即可确定发送端的当前流数目满足上述发送端的流条件，此时可根据该报文建立对应的第一流，并获取第一QoS配置信息。

在一些实施例中，上述MRFN可以不是定值；也即，可以在通信过程中对该MRFN进行修改。具体地，可以是在发送端的FN大于发送端的MRFN时，再进一步检测该发送端的MRFN是否达到预设的系统最大预留数目；若该发送端的MRFN已经达到该系统最大预留数目，则丢弃该报文，触发流溢出警告；反之，若该发送端的MRFN仍未达到该系统最大预留数目，则可将MRFN修改为原来的2倍；若修改后的发送端的MRFN大于或等于该系统最大预留数目，则再将发送端的MRFN修改为系统最大预留数目。

步骤302，若基于上述第一QoS配置信息，确定第一流在上述报文的发送方向上的状态为允许状态，则获取第二QoS配置信息；

在本申请实施例中，该第一流指的是该报文所对应的该发送端的本地流，其中，一对端点(endpoint)之间双向传输的数据包的集合即为流。可根据第一QoS配置信息来确定该第一流在报文的发送方向上的状态，该状态包括允许状态及丢弃状态。具体地，可通过如下方式确定该第一流在报文的发送方向上的状态：

B1、获取上述发送端在发送方向上的至少一项预设的QoS指标值，记作第一QoS指标值；

在本申请实施例中，基于上文对QoS指标的介绍，此处可获取的第一QoS指标值包括但不限于：队列的信息及TBW等，其中，该TBW具体指的是TLBW。

B2、基于上述第一QoS配置信息及上述第一QoS指标值，判断是否满足第一QoS条件；

在本申请实施例中，基于上文对QoS配置信息的介绍，此处的第一QoS配置信息包括但不限于发送端的TACL、TMRBW、QFA、MBQN和MBQL。相应地，第一QoS条件为：

对于发送端的TACL，判断发送端的TACL是否允许通行，若是，则该项通过判断；

对于发送端的TLBW，判断发送端的TLBW小于发送端的TMRBW，若是，则该项通过判断；

对于发送端的队列的信息，根据MBQN和MBQL判断是否有空闲的发送队列，若是，则该项通过判断；

对于发送端的QFA，判断该QFA的转发行为是否为丢弃，若否，则该项通过判断，且还可根据该QFA的结果修改报文内容；

在一些实施例中，上述TMRBW可以不是定值；也即，可以在通信过程中对该TMRBW进行修改。具体地，可以是在发送端的TLBW大于发送端的TMRBW时，触发业务警告，并进一步检测该发送端的TMRBW是否达到预设的第一带宽，该第一带宽是系统允许的最大发送带宽值；若该发送端的TMRBW已经达到该第一带宽，则丢弃该报文；反之，若该发送端的TMRBW仍未达到该第一带宽，则可将TMRBW修改为原来的2倍；若修改后的发送端的TMRBW大于或等于该第一带宽，则再将发送端的TMRBW修改为第一带宽。

需要注意的是，上述各个判断可以是逐一进行，此处不对其判断顺序作出限定。当所有判断均通过时，可确定满足该第一QoS条件；只要任意判断未通过，则可确定不满足该第一QoS条件，也即此时第一流在报文的发送方向上的状态为丢弃状态。

B3、若满足上述第一QoS条件，则确定上述第一流在上述报文的发送方向上的状态为允许状态；

B4、在确定上述第一流在上述报文的发送方向上的状态为允许状态后，获取上述第二QoS配置信息。

在确定该第一流在发送方向上的状态为允许状态后，即可确认发送端具备向外发送该报文的网络能力；但此时，仍不能向外发送该报文，因为还未能确定接收端是否具备接收该报文的网络能力。基于此，发送端可再通过QoS-C来获取到第二QoS配置信息，该第二QoS配置信息指的是接收端在接收方向上的QoS配置信息。基于上文对QoS配置信息的介绍，此处的QoS配置信息具体包括：RACL、RMRBW、MBQN、MBQL及QFA。

步骤303，若基于上述第二QoS配置信息，确定上述第一流在上述报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送上述报文，以指示上述物理转发设备向上述接收端转发上述报文。

在本申请实施例中，可根据第二QoS配置信息来确定该第一流在接收方向上的状态，该状态包括允许状态及丢弃状态。具体地，可通过如下方式确定该第一流在接收方向上的状态：

C1、获取上述接收端在接收方向上的至少一项预设的QoS指标值，记作第二QoS指标值；

在本申请实施例中，基于上文对QoS指标的介绍，此处可获取的第一QoS指标值包括但不限于：队列的信息及RBW等，其中，该RBW具体指的是RLBW。

C2、基于上述第二QoS配置信息及上述第二QoS指标值，判断是否满足第二QoS条件；

在本申请实施例中，发送端可以向QoS-C请求接收端的第二QoS配置信息。进一步地，发送端还可向QoS-C订阅接收端的第二QoS配置信息，以使得后续该接收端的第二QoS配置信息一旦产生更新，即可主动推送给该发送端(也即订阅者)。基于上文对QoS配置信息的介绍，此处的第二QoS配置信息包括但不限于接收端的RACL、RMRBW、QFA、MBQN和MBQL。相应地，第二QoS条件为：

对于接收端的RACL，判断接收端的RACL是否允许通行，若是，则该项通过判断；

对于接收端的RLBW，判断接收端的RLBW小于发送端的RMRBW，若是，则该项通过判断；

对于接收端的队列的信息，根据MBQN和MBQL判断是否有空闲的接收队列，若是，则该项通过判断；

对于接收端的QFA，判断该QFA的转发行为是否为丢弃，若否，则该项通过判断，且还可根据该QFA的结果修改报文内容；

在一些实施例中，上述RMRBW可以不是定值；也即，可以在通信过程中对该RMRBW进行修改。具体地，可以是在接收端的RLBW大于接收端的RMRBW时，触发业务警告，并进一步检测该发送端的RMRBW是否达到预设的第二带宽，该第二带宽是系统允许的最大接收带宽值；若该发送端的RMRBW已经达到该第二带宽，则丢弃该报文；反之，若该发送端的RMRBW仍未达到该第二带宽，则可将RMRBW修改为原来的2倍；若修改后的发送端的RMRBW大于或等于该第二带宽，则再将发送端的RMRBW修改为第二带宽。

需要注意的是，上述各个判断可以是逐一进行，此处不对其判断顺序作出限定。当所有判断均通过时，可确定满足该第二QoS条件；只要任意判断未通过，则可确定不满足该第二QoS条件，也即此时第一流在报文的接收方向上的状态为丢弃状态。

C3、若满足上述第二QoS条件，则确定上述第一流在上述报文的接收方向上的状态为允许状态；

C4、在确定上述第一流在上述报文的接收方向上的状态为允许状态后，向上述物理转发设备发送上述报文。

在确定该第一流在接收方向上的状态为允许状态后，即可确认接收端此时具备接收该报文的网络能力。基于此，可向物理转发设备发送上述报文，如上文上述，物理转发设备包括物理网卡、物理交换路由设备及网关设备等，此处不再赘述。需要注意的是，各个物理转发设备也有其转发策略，只有转发路径上的各个物理转发设备的转发策略均允许转发该报文时，该报文才可最终转发至接收端处；否则，该报文会被丢弃。具体地，对于物理交换路由设备来说，其转发策略为：周期性检测物理交换路由设备的TPBW、RPBW及丢包计数，并触发测物理交换路由设备的丢包告警到网络业务中台；如果有丢包，则调整接收和发送方向限速为原来的两倍。对于接收方向，如果调整后的值超过或达到RPRBW，则将接收方向限速设置为RPRBW；对于发送方向，如果调整后的值超过或达到TPRBW，则将发送方向限速设置为TPRBW。

在一些实施例中，QoS-A会基于报文的报文特征，在其本地创建对应的流表，以追踪报文所对应的流的状态。

由上可见，在通信过程中，在通信过程中，通过对发送端在发送方向上的QoS配置信息及接收端在接收方向上的QoS配置信息，来判断报文所对应的流的状态并以此决定是否可以向外发送报文。也即，通信过程中不仅考虑己方的发送能力，而且也会考虑对方的接收能力。而且，报文的发送端及接收端作为通信实体，往往为虚拟实例，也即，上述过程也对虚拟组件的QoS也予以考虑，能够减少对网络资源的浪费，增加系统的安全性。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

基于对系统架构的上述改进，下面对本申请实施例提供的另一种数据传输方法进行描述，该数据传输方法应用于报文的接收端，也即通信过程中接收报文的一方。请参阅图4，该数据传输方法包括：

步骤401，当接收到报文的发送端所发送的报文时，获取第二QoS配置信息，上述第二QoS配置信息为上述接收端在接收方向上的QoS配置信息；

本申请实施例中，当有虚拟实例接收到报文时，该虚拟实例即为报文的接收端。此时，需要先去获取第二QoS配置信息，其中，该第二QoS配置信息指的是该虚拟实例在接收方向上的QoS配置信息。基于上文对QoS配置信息的介绍，此处的QoS配置信息具体包括：RACL、RMRBW、MBQN、MBQL及QFA。

在一些实施例中，当该虚拟实例是接收到的是一个新的发送端所发送的报文时，还需要对该接收端的本地流的数目进行检测，以确定是否超出其处理能力。则上述步骤401可具体表现为：

D1、根据上述报文的报文特征，确定上述接收端是否已存在上述第二流；

其中，报文特征包括：通信协议、源IP地址、目的IP地址、源端口、目的端口。一组报文特征即定义了一条流。基于此，可根据该报文的报文特征，确定接收端的本地是否已存在该报文所对应的流，也即第二流。

D2、若已存在上述第二流，则获取上述第二QoS配置信息；

D3、若不存在上述第二流，则检测上述接收端的当前流数目是否满足预设的接收端的流条件；

其中，当接收端的本地已存在该第二流时，可直接获取第二QoS配置信息。当接收端的本地还不存在该第二流时，则需要检测接收端的当前流数目是否满足预设的接收端的流条件。其中，接收端的当前流数目为上文所提出的一项QoS指标FN，该接收端的流条件可基于该接收端的QoS配置信息而得。基于上文对QoS配置信息的介绍，此处的QoS配置信息具体包括MRFN。该预设的接收端的流条件为：接收端的FN小于接收端的MRFN。

D4、若上述接收端的当前流数目满足上述接收端的流条件，则建立上述第二流，并获取第二QoS配置信息。

其中，当检测发现接收端的FN小于接收端的MRFN时，即可确定接收端的当前流数目满足上述接收端的流条件，此时可根据该报文建立对应的第二流，并获取第二QoS配置信息。

在一些实施例中，上述MRFN可以不是定值；也即，可以在通信过程中对该MRFN进行修改。具体地，可以是在接收端的FN大于接收端的MRFN时，再进一步检测该接收端的MRFN是否达到预设的系统最大预留数目；若该接收端的MRFN已经达到该系统最大预留数目，则丢弃该报文，触发流溢出警告；反之，若该接收端的MRFN仍未达到该系统最大预留数目，则可将MRFN修改为原来的2倍；若修改后的接收端的MRFN大于或等于该系统最大预留数目，则再将接收端的MRFN修改为系统最大预留数目。

步骤402，若基于上述第二QoS配置信息，确定第二流在上述报文的接收方向上的状态为允许状态，则对上述报文进行处理，上述第二流为上述报文所对应的上述接收端的本地流。

该第二流指的是该报文所对应的该接收端的本地流。可根据第二QoS配置信息来确定该第二流在该报文的接收方向上的状态，该状态包括允许状态及丢弃状态。具体地，可通过如下方式确定该第二流在该报文的发送方向上的状态：

E1、获取上述接收端在接收方向上的至少一项预设的QoS指标值，记作第二QoS指标值；

在本申请实施例中，基于上文对QoS指标的介绍，此处可获取的第二QoS指标值包括但不限于：队列的信息及RBW等，其中，该RBW具体指的是RLBW。

E2、基于上述第二QoS配置信息及上述第二QoS指标值，判断是否满足第二QoS条件；

在本申请实施例中，基于上文对QoS配置信息的介绍，此处的第二QoS配置信息包括但不限于接收端的RACL、RMRBW、QFA、MBQN和MBQL。相应地，第二QoS条件为：

对于接收端的TACL，判断接收端的TACL是否允许通行，若是，则该项通过判断；

对于接收端的TLBW，判断接收端的TLBW小于接收端的TMRBW，若是，则该项通过判断；

对于接收端的队列的信息，根据MBQN和MBQL判断是否有空闲的发送队列，若是，则该项通过判断；

对于接收端的QFA，判断该QFA的转发行为是否为丢弃，若否，则该项通过判断，且还可根据该QFA的结果修改报文内容；

在一些实施例中，上述RMRBW可以不是定值；也即，可以在通信过程中对该RMRBW进行修改。具体地，可以是在接收端的RLBW大于接收端的RMRBW时，触发业务警告，并进一步检测该接收端的RMRBW是否达到预设的第二带宽，该第二带宽是系统允许的最大接收带宽值；若该接收端的TMRBW已经达到该第二带宽，则丢弃该报文；反之，若该接收端的TMRBW仍未达到该第二带宽，则可将TMRBW修改为原来的2倍；若修改后的接收端的TMRBW大于或等于该第二带宽，则再将接收端的TMRBW修改为第二带宽。

需要注意的是，上述各个判断可以是逐一进行，此处不对其判断顺序作出限定。当所有判断均通过时，可确定满足该第二QoS条件；只要任意判断未通过，则可确定不满足该第二QoS条件，也即此时第二流在该报文的接收方向上的状态为丢弃状态。

E3、若满足上述第二QoS条件，则确定上述第二流在上述报文的接收方向上的状态为允许状态；

E4、在确定上述第二流在上述报文的接收方向上的状态为允许状态后，对上述报文进行处理。

在确定该第二流在该报文的接收方向上的状态为允许状态后，即可确认接收端可以接收该报文，至此，该报文的传输已完成。接收端可以根据需求对该报文进行处理。若该报文的接收端为通信过程中的Rx，也即被动响应报文的一方，则可基于所接收到的报文，向该报文的发送端进行反馈；也即，发送端及接收端将调转身份，由接收端作为新的发送端，由发送端作为新的接收端，再次实现数据传输。

由上可见，在通信过程中，接收端在接收到报文后，会基于自身的虚拟组件的QoS考虑是否能够真正接收并处理该报文，能够减少对网络资源的浪费，增加系统的安全性。

为便于说明，此处记通信发起实体为Tx，通信接收实体为Rx，对一次完整的数据交互过程进行简单说明。其中，Tx及Rx均为虚拟实例，Tx首先发起通信，Rx被动响应报文：

Tx首先向Rx发送报文1，该报文1对应的流为Flow，其中，该Flow在Tx本地为本地流Flow1。当Rx是第一次与Tx通信时，会根据Tx的FN及MRFN判断是否能新建Flow1，并在可以新建Flow1时执行后续操作；否则即丢弃报文1。当Rx已与Tx建立有通信时，无需对Tx的FN进行检测，直接执行后续步骤。

随后基于Tx的TACL、TLBW、TMRBW、MBQN、MBQL及QFA，检测该Flow1在报文1流出Tx的方向上的状态是否为允许，若允许，则执行后续操作，若不允许，则丢弃报文1。

Tx再请求Rx的QoS配置信息及QoS指标值，并基于请求到的Rx的RACL、RLBW、RMRBW、MBQN、MBQL及QFA，检测该Flow1在报文1流入Rx的方向上的状态是否为允许，若允许，则执行后续操作，若不允许，则丢弃报文1。

Tx将报文1发送至物理转发设备，以使得物理转发设备向Rx转发该报文1。该过程中也涉及有物理转发设备的转发策略，此处不再赘述。当物理转发设备的转发策略均允许报文1通行时，报文1将被发送至Rx处。

Rx接收报文1，该报文1对应的流为Flow，其中，该Flow在Rx本地为本地流Flow2。当Rx是第一次与Tx通信时，会根据Rx的FN及MRFN判断是否能新建Flow2，并在可以新建Flow2时执行后续操作，其中，该Flow2初始的出向及入向上的状态均为允许；否则即丢弃报文1。当Rx已与Tx建立有通信时，无需对Rx的FN进行检测，直接执行后续步骤。

随后基于Rx的RACL、RLBW、RMRBW、MBQN、MBQL及QFA，检测该Flow2在报文1流入Rx的方向上的状态是否为允许，若允许，则基于该报文1，生成要向Tx进行反馈的报文2，若不允许，则丢弃报文1。

此时，对于报文2，Rx已经成为了报文2的发送端。需要注意的是，流是双向的，因而，Rx仍基于Flow2与Tx通信。基于Rx的QoS配置信息及QoS指标值，包括TACL、TLBW、TMRBW、MBQN、MBQL及QFA等，检测该Flow2在报文2流出Rx的方向上的状态是否为允许，若允许，则执行后续操作，若不允许，则丢弃报文2。

Rx再请求Tx的QoS配置信息及QoS指标值，并基于Tx的RACL、RLBW、RMRBW、MBQN、MBQL及QFA，检测该Flow2在报文2流入Tx的方向上的状态是否为允许，若允许，则执行后续操作，若不允许，则丢弃报文2。

Rx将报文2发送至物理转发设备，以使得物理转发设备向Tx转发该报文2。该过程中也涉及有物理转发设备的转发策略，此处不再赘述。当物理转发设备的转发策略均允许报文2通行时，报文2将被发送至Tx处。

Tx接收报文2，由于流是双向的，Tx本地已建立有与Rx通信的本地流Flow1，因而，此处无需新建流。基于Tx的RACL、RLBW、RMRBW、MBQN、MBQL及QFA，检测Flow1在报文2流入Rx的方向上的状态是否为允许，若允许，则对该报文2进行相应处理，若不允许，则丢弃该报文2。

至此，Tx及Rx完成一次数据交互，该数据交互过程中涉及两次数据传输，分别为Tx传输报文至Rx，及Rx反馈报文回Tx；每次数据传输均涉及三次状态检测，分别是在报文的发送端检测在流出发送端方向上的状态、在流入接收端方向上的状态，以及在报文的接收端检测在流入接收端方向上的状态。其中，对于流入接收端方向上的状态的检测，会在报文的发送端及接收端均执行，这是因为在转发过程中报文可能发生修改；并且，网络传输会带来时延，这可能导致接收端的QoS指标值出现变化，出于可靠性的考虑，才需要进行上述检测。

由上可见，通过本申请实施例，可以节省虚拟专有云的网络宽带资源，一定程度上提升网络资源的复用率。并且由于数据传输过程中同时考虑收发双发的能力，因而使得原先非对称的服务质量管理体系变成对称的服务质量管理体系，可提前对节点的过载情况做出预警和自愈调节，提高系统健壮性，能够抵御大规模的DDos攻击，改善服务质量，在降低用户的延时的同时还可提高吞吐量。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文所提出的应用于报文的发送端的数据传输方法，下面对本申请实施例提供的一种数据传输装置进行描述，请参阅图5，上述数据传输装置5包括：

第一获取单元，用于当存在待发送的报文时，获取第一QoS配置信息，上述第一QoS配置信息为上述发送端在发送方向上的QoS配置信息；

第二获取单元，用于若基于上述第一QoS配置信息，确定第一流在上述报文的发送方向上的状态为允许状态，则获取第二QoS配置信息，上述第二QoS配置信息为上述报文的接收端的接收方向上的QoS配置信息，上述第一流为上述报文所对应的上述发送端的本地流；

发送单元，用于若基于上述第二QoS配置信息，确定上述第一流在上述报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送上述报文，以指示上述物理转发设备向上述接收端转发上述报文。

可选地，上述第一获取单元，包括

第一流确定子单元，用于根据上述报文的报文特征，确定上述发送端是否已存在上述第一流；

第一信息获取子单元，用于若已存在上述第一流，则获取第一QoS配置信息；

第一流数目检测子单元，用于若不存在上述第一流，则检测上述发送端的当前流数目是否满足预设的发送端的流条件；

第二信息获取子单元，用于若上述发送端的当前流数目满足上述发送端的流条件，则建立上述第一流，并获取第一QoS配置信息。

可选地，上述第二获取单元，包括：

第一指标值获取子单元，用于获取上述发送端在发送方向上的至少一项预设的QoS指标值，记作第一QoS指标值；

第一条件判断子单元，用于基于上述第一QoS配置信息及上述第一QoS指标值，判断是否满足第一QoS条件；

第一状态确定子单元，用于若满足上述第一QoS条件，则确定上述第一流在上述报文的发送方向上的状态为允许状态；

第二信息获取子单元，用于在确定上述第一流在上述报文的发送方向上的状态为允许状态后，获取上述第二QoS配置信息。

可选地，上述发送单元，包括：

第二指标值获取子单元，用于获取上述接收端在接收方向上的至少一项预设的QoS指标值，记作第二QoS指标值；

第二条件判断子单元，用于基于上述第二QoS配置信息及上述第二QoS指标值，判断是否满足第二QoS条件；

第二状态确定子单元，用于若满足上述第二QoS条件，则确定上述第一流在上述报文的接收方向上的状态为允许状态；

报文发送子单元，用于在确定上述第一流在上述报文的接收方向上的状态为允许状态后，向上述物理转发设备发送上述报文。

由上可见，在通信过程中，通过对发送端在发送方向上的QoS配置信息及接收端在接收方向上的QoS配置信息，来判断报文所对应的流的状态并以此决定是否可以向外发送报文。也即，通信过程中不仅考虑己方的发送能力，而且也会考虑对方的接收能力，且还对虚拟组件的QoS也予以考虑，能够减少对网络资源的浪费，增加系统的安全性。

对应于上文所提出的应用于报文的接收端的数据传输方法，下面对本申请实施例提供的另一种数据传输装置进行描述，请参阅图6，上述数据传输装置6包括：

第三获取单元，用于当接收到报文的发送端所发送的报文时，获取第二QoS配置信息，上述第二QoS配置信息为上述接收端在接收方向上的QoS配置信息；

处理单元，用于若基于上述第二QoS配置信息，确定第二流在上述报文的接收方向上的状态为允许状态，则对上述报文进行处理，上述第二流为上述报文所对应的上述接收端的本地流。

可选地，上述第三获取单元，包括：

第二流确定子单元，用于根据上述报文的报文特征，确定上述接收端是否已存在上述第二流；

第三信息获取子单元，用于若已存在上述第二流，则获取上述第二QoS配置信息；

第二流数目检测子单元，用于若不存在上述第二流，则检测上述接收端的当前流数目是否满足预设的接收端的流条件；

若上述接收端的当前流数目满足上述接收端的流条件，则建立上述第二流，并获取上述第二QoS配置信息。

可选地，上述处理单元，包括：

第三指标值获取子单元，获取上述接收端在接收方向上的至少一项预设的QoS指标值，记作第二QoS指标值；

第三条件判断子单元，基于上述第二QoS配置信息及上述第二QoS指标值，判断是否满足第二QoS条件；

第三状态确定子单元，若满足上述第二QoS条件，则确定上述第二流在上述报文的接收方向上的状态为允许状态；

报文处理子单元，用于在确定上述第二流在上述报文的接收方向上的状态为允许状态后，对上述报文进行处理。

由上可见，在通信过程中，接收端在接收到报文后，会基于自身的虚拟组件的QoS考虑是否能够真正接收并处理该报文，能够减少对网络资源的浪费，增加系统的安全性。

本申请实施例还提出了一种数据传输系统，该数据传输系统应用于上文提出的改进后的VPC系统中，包括报文的发送端以及报文的接收端，其中，报文的发送端可实现上文所提出的应用于报文的发送端的数据传输方法，报文的接收端可实现上文提出的应用于报文的接收端的数据传输方法，此处不再赘述。具体地，VPC系统中的任一虚拟实例均可作为报文的接收端和/或发送端，此处不作限定。通过该数据传输系统，可以节省虚拟专有云的网络宽带资源，一定程度上提升网络资源的复用率。并且由于数据传输过程中同时考虑收发双发的能力，因而使得原先非对称的服务质量管理体系变成对称的服务质量管理体系，可提前对节点的过载情况做出预警和自愈调节，提高系统健壮性，能够抵御大规模的DDos攻击，改善服务质量，在降低用户的延时的同时还可提高吞吐量。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将上述系统的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，上述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，模块或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

上述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，上述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，上述计算机程序包括计算机程序代码，上述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。上述计算机可读介质可以包括：能够携带上述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，上述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括是电载波信号和电信信号。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种数据传输方法，其特征在于，应用于报文的发送端，包括：

当存在待发送的报文时，获取第一QoS配置信息，所述第一QoS配置信息为所述发送端在发送方向上的QoS配置信息；

若基于所述第一QoS配置信息，确定第一流在所述报文的发送方向上的状态为允许状态，则获取第二QoS配置信息，所述第二QoS配置信息为所述报文的接收端在接收方向上的QoS配置信息，所述第一流为所述报文所对应的所述发送端的本地流；

若基于所述第二QoS配置信息，确定所述第一流在所述报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送所述报文，以指示所述物理转发设备向所述接收端转发所述报文。

2.如权利要求1所述的数据传输方法，其特征在于，所述当存在待发送的报文时，获取第一QoS配置信息，包括：

根据所述报文的报文特征，确定所述发送端是否已存在所述第一流；

若已存在所述第一流，则获取第一QoS配置信息；

若不存在所述第一流，则检测所述发送端的当前流数目是否满足预设的发送端的流条件；

若所述发送端的当前流数目满足所述发送端的流条件，则建立所述第一流，并获取第一QoS配置信息。

3.如权利要求1所述的数据传输方法，其特征在于，所述若基于所述第一QoS配置信息，确定第一流在所述报文的发送方向上的状态为允许状态，则获取第二QoS配置信息，包括：

获取所述发送端在发送方向上的至少一项预设的QoS指标值，记作第一QoS指标值；

基于所述第一QoS配置信息及所述第一QoS指标值，判断是否满足第一QoS条件；

若满足所述第一QoS条件，则确定所述第一流在所述报文的发送方向上的状态为允许状态；

在确定所述第一流在所述报文的发送方向上的状态为允许状态后，获取所述第二QoS配置信息。

4.如权利要求1所述的数据传输方法，其特征在于，所述若基于所述第二QoS配置信息，确定所述第一流在所述报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送所述报文，包括：

获取所述接收端在接收方向上的至少一项预设的QoS指标值，记作第二QoS指标值；

基于所述第二QoS配置信息及所述第二QoS指标值，判断是否满足第二QoS条件；

若满足所述第二QoS条件，则确定所述第一流在所述报文的接收方向上的状态为允许状态；

在确定所述第一流在所述报文的接收方向上的状态为允许状态后，向所述物理转发设备发送所述报文。

5.一种数据传输方法，其特征在于，应用于报文的接收端，包括：

当接收到报文的发送端所发送的报文时，获取第二QoS配置信息，所述第二QoS配置信息为所述接收端在接收方向上的QoS配置信息；

若基于所述第二QoS配置信息，确定第二流在所述报文的接收方向上的状态为允许状态，则对所述报文进行处理，所述第二流为所述报文所对应的所述接收端的本地流。

6.如权利要求5所述的数据传输方法，其特征在于，所述当接收到报文的发送端所发送的报文时，获取第二QoS配置信息，包括：

根据所述报文的报文特征，确定所述接收端是否已存在所述第二流；

若已存在所述第二流，则获取所述第二QoS配置信息；

若不存在所述第二流，则检测所述接收端的当前流数目是否满足预设的接收端的流条件；

若所述接收端的当前流数目满足所述接收端的流条件，则建立所述第二流，并获取所述第二QoS配置信息。

7.如权利要求5所述的数据传输方法，其特征在于，所述若基于所述第二QoS配置信息，确定第二流在所述报文的接收方向上的状态为允许状态，则对所述报文进行处理，包括：

获取所述接收端在接收方向上的至少一项预设的QoS指标值，记作第二QoS指标值；

基于所述第二QoS配置信息及所述第二QoS指标值，判断是否满足第二QoS条件；

若满足所述第二QoS条件，则确定所述第二流在所述报文的接收方向上的状态为允许状态；

在确定所述第二流在所述报文的接收方向上的状态为允许状态后，对所述报文进行处理。

8.一种数据传输装置，其特征在于，应用于报文的发送端，包括：

第一获取单元，用于当存在待发送的报文时，获取第一QoS配置信息，所述第一QoS配置信息为所述发送端在发送方向上的QoS配置信息；

第二获取单元，用于若基于所述第一QoS配置信息，确定第一流在所述报文的发送方向上的状态为允许状态，则获取第二QoS配置信息，所述第二QoS配置信息为所述报文的接收端的接收方向上的QoS配置信息，所述第一流为所述报文所对应的所述发送端的本地流；

发送单元，用于若基于所述第二QoS配置信息，确定所述第一流在所述报文的接收方向上的状态为允许状态，则向预设的物理转发设备发送所述报文，以指示所述物理转发设备向所述接收端转发所述报文。

9.一种数据传输装置，其特征在于，应用于报文的接收端，包括：

第三获取单元，用于当接收到报文的发送端所发送的报文时，获取第二QoS配置信息，所述第二QoS配置信息为所述接收端在接收方向上的QoS配置信息；

处理单元，用于若基于所述第二QoS配置信息，确定第二流在所述报文的接收方向上的状态为允许状态，则对所述报文进行处理，所述第二流为所述报文所对应的所述接收端的本地流。

10.一种数据传输系统，其特征在于，所述数据传输系统包括报文的发送端及报文的接收端，其中，所述发送端实现如权利要求1-4任一项所述的方法，所述接收端实现如权利要求5-7任一项所述的方法。

Images