CN117978787A - 数据传输方法、装置、系统、电子设备及存储介质 - Google Patents

Abstract

本公开涉及数据处理领域，具体公开了一种数据传输方法、装置、系统、电子设备及存储介质。该方法包括：在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；其中，所述交互操作数据用于针对所述流媒体数据执行交互操作；在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端。该方式避免了突发的大流量交互操作数据影响流媒体数据传输的问题，提升了交互式流媒体的传输质量。

Description

数据传输方法、装置、系统、电子设备及存储介质

技术领域

本公开实施例涉及数据处理技术领域，具体涉及一种数据传输方法、装置、系统、电子设备及存储介质。

背景技术

在数据传输领域中，可以通过多种方式传输数据。例如，可以灵活选择各种传输协议或传输通道进行数据传输：可以通过用户数据报协议(User Datagram Protocol，UDP)或传输控制协议(Transmission Control Protocol，TCP)进行数据传输。

但是，在传统的传输方式中，针对所有数据都固定采用相同的传输方式，然而，由于不同数据的数据特征各不相同，且网络状态也可能动态变化，因此，固定不变的传输方式无法灵活适配各种场景的实际需求。

发明内容

鉴于上述问题，提出了本公开以便提供一种克服上述问题或者至少部分地解决上述问题的一种数据传输方法、装置、系统、电子设备及存储介质。

根据本公开实施例的一个方面，提供了一种数据传输方法，包括：

在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；其中，所述交互操作数据用于针对所述流媒体数据执行交互操作；

在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端。

在一种可选的实现方式中，所述交互操作数据满足分片条件包括以下中的至少一种：

所述交互操作数据的数据量大于当前时间片所支持的可用发送流量；其中，所述当前时间片所支持的可用发送流量根据当前时间片传输的流媒体数据的数据量和/或数据类型确定；

所述交互操作数据的数据类型属于预设类型，其中，所述预设类型包括：资源类型、和/或图片类型。

在一种可选的实现方式中，所述将所述交互操作数据拆分为多个数据分片包括：

通过第一传输协议，将所述交互操作数据拆分为多个数据分片；其中，所述多个数据分片对应于多个不同的分片标识、且对应于相同的消息标识；其中，所述第一传输协议是在业务层实现的自定义传输协议；

并且，所述将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端包括：

通过第二传输协议，将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端；其中，所述第二传输协议是在传输层实现的可靠传输协议。

在一种可选的实现方式中，所述将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端之后，还包括：将已发送的多个数据分片缓存至预设缓存空间；

并且，所述方法还包括：在接收到所述数据接收端返回的确认响应消息的情况下，获取所述确认响应消息中包含的分片标识和/或消息标识，删除所述预设缓存空间中与所述分片标识和/或消息标识相对应的数据分片。

在一种可选的实现方式中，所述将已发送的多个数据分片缓存至预设缓存空间之后，还包括：

在检测到网络状态满足预设暂停条件的情况下，暂停所述交互操作数据的发送操作，并将待发送的交互操作数据缓存至待发送队列；

并且，在检测到网络状态满足预设恢复条件的情况下，恢复所述交互操作数据的发送操作，以将所述待发送队列中缓存的交互操作数据发送至所述交互式流媒体应用中的数据接收端。

在一种可选的实现方式中，所述预设暂停条件包括：所述预设缓存空间的剩余存储空间小于第一预设阈值，和/或，检测到数据发送端与数据接收端之间的传输通道断连；

所述预设恢复条件包括：所述预设缓存空间的剩余存储空间不小于第二预设阈值，和/或，检测到数据发送端与数据接收端之间的传输通道重连。

在一种可选的实现方式中，所述恢复所述交互操作数据的发送操作之后，还包括：

获取所述预设缓存空间中未删除的数据分片，重新将所述未删除的数据分片发送至所述交互式流媒体应用中的数据接收端。

在一种可选的实现方式中，所述交互式流媒体应用为云游戏应用；所述交互操作数据包括：游戏登录数据、游戏操控指令、游戏资源数据；并且，所述交互式流媒体应用中的流媒体数据通过第三传输协议传输。

根据本公开实施例的又一个方面，提供了一种数据传输方法，适用于交互式流媒体应用中的数据接收端，包括：

在传输所述交互式流媒体应用中的流媒体数据的过程中，接收数据发送端将交互操作数据拆分后通过多个时间片发送的多个数据分片，以执行与所述多个数据分片组装后的交互操作数据相对应的交互操作。

在一种可选的实现方式中，所述接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片包括：

通过第二传输协议，接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片；

通过第一传输协议，获取每个数据分片中包含的分片标识以及消息标识，将对应于相同的消息标识、且分片标识符合组装条件的多个数据分片组装为一条数据消息，并根据组装得到的数据消息向所述数据发送端返回确认响应消息。

在一种可选的实现方式中，所述将对应于相同的消息标识、且分片标识符合组装条件的多个数据分片组装为一条数据消息之后，还包括：

根据所述数据消息中包含的消息标识，判断所述数据消息是否为重复接收的数据消息，若是，针对所述数据消息执行去重处理。

根据本公开实施例的又一个方面，提供了一种数据传输方法，所述方法包括：

数据发送端在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端；

数据接收端接收通过多个时间片发送的所述多个数据分片，以执行与所述多个数据分片组装后的交互操作数据相对应的交互操作。

根据本公开实施例的又一个方面，提供了一种数据传输装置，适用于交互式流媒体应用中的数据发送端，包括：

获取模块，适于在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；

拆分模块，适于在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端。

根据本公开实施例的又一个方面，提供了一种数据传输装置，适用于交互式流媒体应用中的数据接收端，包括：

接收模块，适于在传输所述交互式流媒体应用中的流媒体数据的过程中，接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片，以执行与所述多个数据分片相对应的交互操作。

根据本公开实施例的又一个方面，提供了一种数据传输系统，所述系统包括：数据发送端以及数据接收端。

依据本公开的再一方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如上述的数据传输方法。

依据本公开的再一方面，提供了一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如上述的数据传输方法。

在本公开的实施例中，能够在交互式流媒体应用中的交互操作数据满足分片条件的情况下，将交互操作数据拆分为多个数据分片，从而将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端。其中，交互操作数据用于针对交互式流媒体应用中的流媒体数据执行交互操作，并且，交互操作数据通常在流媒体数据的传输过程中产生，因此，为了避免交互操作数据挤占流媒体数据传输资源的问题，预先针对交互操作数据设置了分片条件，并在交互操作数据满足分片条件的情况下将其拆分为多个数据分片，并分别通过多个时间片进行传输，从而避免了突发的大流量交互操作数据影响流媒体数据传输的问题，提升了交互式流媒体的传输质量。

上述说明仅是本公开技术方案的概述，为了能够更清楚了解本公开的技术手段，而可依照说明书的内容予以实施，并且为了让本公开的上述和其它目的、特征和优点能够更明显易懂，以下特举本公开的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本公开的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本公开一个实施例提供的一种数据传输方法的流程图；

图2示出了本公开又一个实施例提供的一种数据传输方法的流程图；

图3示出了一个具体示例中的数据传输方法的流程示意图；

图4示出了根据第一传输协议拆分得到的一个数据分片的数据结构示意图；

图5示出了本公开又一实施例提供的一种数据传输装置的示意图；

图6示出了本公开又一实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了本公开一个实施例提供的一种数据传输方法的流程图。其中，该方法适用于交互式流媒体应用中的数据发送端。如图1所示，该方法具体包括：

步骤S110：在传输交互式流媒体应用中的流媒体数据的过程中，获取交互式流媒体应用中的交互操作数据；其中，交互操作数据用于针对流媒体数据执行交互操作。

其中，交互式流媒体应用包括：云游戏应用、远程桌面应用、虚拟展厅应用等各类应用。在交互式流媒体中，流媒体数据(如视频流)能够根据用户触发的交互操作实时变化产生反馈。例如，在云游戏类型的交互式流媒体中，游戏画面能够随用户的交互操作而动态改变。

在交互式流媒体应用中，至少包含流媒体数据以及交互操作数据。其中，流媒体数据主要是指音视频数据，如云游戏中的游戏画面等；交互操作数据用于针对流媒体数据执行交互操作，例如可以是云游戏中的控制指令等数据。通常情况下，交互操作数据是在流媒体数据的传输过程中动态产生的数据。

步骤S120：在交互操作数据满足分片条件的情况下，将交互操作数据拆分为多个数据分片，以将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端。

其中，可以确定交互操作数据的数据属性，并根据交互操作数据的数据属性判断交互操作数据是否满足分片条件。由此可见，分片条件主要是根据交互操作数据的数据属性设定的。其中，交互操作数据的数据属性可以包括：数据类型、数据量等。相应的，分片条件可以根据交互操作数据的数据类型和/或数据量设定。

例如，可以在交互操作数据的数据类型为预设类型，或者，在交互操作数据的数据量大于预设阈值的情况下，确定交互操作数据满足分片条件。相应的，将交互操作数据拆分为多个数据分片，以便将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端。其中，多个时间片可以与多个数据分片一一对应。例如，每个数据分片通过对应的一个时间片进行传输，由此实现数据限流传输的效果，以避免突发的大流量交互操作数据挤占流媒体资源的问题。

其中，多个数据分片具体可以封装为多个数据包进行传输。例如，在交互操作数据不满足分片条件的情况下，将交互操作数据封装为一个数据包，并在一个时间片内进行传输；在交互操作数据满足分片条件的情况下，将交互操作数据拆分为多个数据分片，并封装为多个数据包，以便在多个时间片内进行传输，从而降低单个时间片内的传输流量。

由此可见，在本公开的实施例中，为了避免交互操作数据挤占流媒体数据传输资源的问题，预先针对交互操作数据设置了分片条件，并在交互操作数据满足分片条件的情况下将其拆分为多个数据分片，并分别通过多个时间片进行传输，从而避免了突发的大流量交互操作数据影响流媒体数据传输的问题，提升了交互式流媒体的传输质量。

本领域技术人员还可以对上述实施例进行各种改动和变形：

在一种可选的实现方式中，交互操作数据满足分片条件包括以下中的至少一种：

在第一种情况中，分片条件根据数据量设定，相应的，交互操作数据满足分片条件包括：交互操作数据的数据量大于当前时间片所支持的可用发送流量。其中，当前时间片所支持的可用发送流量可以根据当前时间片传输的流媒体数据的数据量和/或数据类型确定。

其中，当前时间片所支持的可用发送流量是指：在当前时间片内，用于传输交互式流媒体应用中的交互操作数据的网络流量，具体可以为固定值(如每个时间片支持的可用发送流量都是相同的数值)，或者，也可以为动态调整的可变值。在后一种方式中，可以根据当前时间片传输的流媒体数据的数据量或数据类型的重要度，动态确定当前时间片所支持的可用发送流量。例如，在流媒体数据的数据量较少(如流媒体数据的数据量小于预设数据量阈值)或数据重要度不高的情况下，当前时间片所支持的可用发送流量可以设置得略高一些；反之，在流媒体数据的数据量较大(如流媒体数据的数据量大于预设数据量阈值)或数据重要度较高的情况下，当前时间片所支持的可用发送流量可以设置得略低一些，从而防止对游戏音视频带宽的挤占。其中，流媒体数据的数据重要度可以根据流媒体数据的数据种类确定。总之，通过数据量判断交互操作数据是否满足分片条件，能够针对数据量较大的交互操作数据进行限流分片处理，从而防止突发流量对流媒体数据的影响。

在第二种情况中，交互操作数据满足分片条件包括：交互操作数据的数据类型属于预设类型，其中，预设类型包括：资源类型、和/或图片类型。例如，在云游戏应用中，可以通过截图方式得到图片类型的交互操作数据，或者，也可以生成图像、视频等形式的资源类型的交互操作数据。该种预设类型的交互操作数据的数据量通常较大，因此，为了避免对流媒体数据资源的挤占，需要通过限流分片的方式进行传输。由此可见，在该方式中，可以直接根据交互操作数据的数据类型快速判断是否满足分片条件。

在一种可选的实现方式中，在将交互操作数据拆分为多个数据分片时，可以通过以下方式实现：

首先，通过第一传输协议，将交互操作数据拆分为多个数据分片；其中，多个数据分片对应于多个不同的分片标识、且对应于相同的消息标识；其中，第一传输协议是在业务层实现的自定义协议。其中，第一传输协议的协议格式是根据具体业务场景自定义的，第一传输协议主要用于定义各个数据分片对应的数据包的报文格式。其中，每个数据分片中包含分片标识以及消息标识，其中，一条交互操作数据拆分得到的多个数据分片都对应于相同的消息标识，以便通过消息标识识别出多个数据分片属于同一条消息。另外，每个数据分片具有唯一的分片标识，以便唯一标识该数据分片。

然后，在将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端时，可以通过第二传输协议，将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端。其中，第二传输协议是在传输层实现的可靠传输协议。其中，第二传输协议用于实现传输层的可靠传输，具体可以是基于TCP的websocket协议，基于UDP的KCP协议等。

由此可见，在上述方式中，通过已有的第一传输协议(即可靠传输协议)确保数据包在传输层的可靠传输，并且，通过自定义的第二传输协议，确保数据包在业务层的可靠传输。具体的，由于第二传输协议针对各个数据分片设置了唯一的分片标识，因此，可以在业务层基于该分片标识判断对应的数据分片是否被有效处理，进而针对未得到有效处理的数据分片进行重传，从而实现业务层的可靠传输。由此可见，通过第一传输协议与第二传输协议相互嵌套的方式，能够确保传输层与业务层两个层面的可靠传输。

在一种可选的实现方式中，在将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端之后，进一步将已发送的多个数据分片缓存至预设缓存空间。其中，该预设缓存空间可以为缓存、内存等各类空间，具体的，可以将已发送的多个数据分片缓存至预设缓存空间中的待确认消息队列中。相应的，上述方法还包括：在接收到数据接收端返回的确认响应消息的情况下，获取确认响应消息中包含的分片标识和/或消息标识，删除预设缓存空间中与分片标识和/或消息标识相对应的数据分片。由此可见，预设缓存空间用于存储已经发送的、待确认的各个数据分片，并且，在接收到对应的确认响应消息的情况下，则说明对应的数据分片已经被接收端可靠接收，因此，从预设缓存空间中删除对应的数据分片。通过该方式，能够借助预设缓存空间快速查询当前已经发送、且未被确认的数据分片，以便于针对这些数据分片执行后续处理。

在一种可选的实现方式中，在将已发送的多个数据分片缓存至预设缓存空间之后，进一步执行以下操作：在检测到网络状态满足预设暂停条件的情况下，暂停所述交互操作数据的发送操作，并将待发送的交互操作数据缓存至发送队列；并且，在检测到网络状态满足预设恢复条件的情况下，恢复交互操作数据的发送操作，以将待发送队列中缓存的交互操作数据发送至交互式流媒体应用中的数据接收端。可选的，预设暂停条件包括：预设缓存空间的剩余存储空间小于第一预设阈值，和/或，检测到数据发送端与数据接收端之间的传输通道断连。预设恢复条件包括：预设缓存空间的剩余存储空间不小于第二预设阈值，和/或，检测到数据发送端与数据接收端之间的传输通道重连。由此可见，该方式能够在预设缓存空间中存储的已经发送、且未被确认的数据分片的数量较多、进而导致预设缓存空间的剩余存储空间不足的情况下，暂停交互操作数据的发送操作，从而避免在网络状态不佳的情况下堆积大量未确认的数据分片，从而导致这些堆积的数据分片无法在业务层实现可靠处理的问题。该方式能够确保网络出现短暂故障的情况下的数据包的可靠传输，避免在网络故障的情况下堆积较多数据包的问题。

在一种可选的实现方式中，在恢复交互操作数据的发送操作之后，进一步获取预设缓存空间中未删除的数据分片，重新将未删除的数据分片发送至交互式流媒体应用中的数据接收端。其中，由于传输通道断连后，往往会导致接收端在业务处理层面的中断，因此，为了确保业务层的可靠传输(传输层的可靠传输是由可靠传输协议保证的，但是业务层面可能因为应用死机、意外退出或卡死等原因而未针对传输层已送达的数据进行有效处理)，需要将预设缓存空间中未收到确认响应消息的数据重新发送。由此可见，在业务层，能够在传输操作恢复之后，自动针对预设缓存空间中未删除的数据分片执行重传操作，从而确保业务层的可靠处理。

其中，在重新将未删除的数据分片发送至交互式流媒体应用中的数据接收端时，可以根据数据分片的类型确定重传策略：

在一种实现方式中，针对部分重要类型的数据分片，可以采取全部重传的策略。在又一种实现方式中，针对一部分操作类型的数据分片，由于在后的操作结果将覆盖在前的操作结果，因此，只针对最新的数据分片执行重传即可。例如，假设某一组数据分片用于实现改变鼠标样式的操作，假设用户共发送了四次改变鼠标样式的操作数据，由于在后的操作数据将覆盖在前的操作数据，因此，只针对最新的一个数据分片执行重传即可。在又一种实现方式中，针对另一部分操作类型的数据分片，其在后的操作结果与在前的操作结果共同作用从而得到最终的操作结果，此时，可以针对多个数据分片对应的操作进行归并处理，并针对归并处理后得到的数据分片执行重传，从而节约数据传输量，提升传输效率。比如，假设某一组数据分片用于改变目标对象的位置，假设用户共发送了三次改变对象位置的操作数据，由于在后的操作是基于上一次操作后的位置实现的，因此，可以针对多个操作数据执行归并处理，从而得到归并处理后的数据分片，并针对归并后的数据分片执行重传操作。

在一种可选的实现方式中，交互式流媒体应用为云游戏应用；交互操作数据包括：游戏登录数据、游戏操控指令、游戏资源数据等；并且，交互式流媒体应用中的流媒体数据可以通过第三传输协议传输。其中，第三传输协议可以为WebRTC协议等。由此可见，交互式流媒体应用中的流媒体数据采用第三传输协议传输，而交互操作数据则采用第一传输协议与第二传输协议相结合的方式进行传输，从而便于根据不同类型的数据特点灵活制定不同的传输策略。其中，第一传输协议主要用于针对交互操作数据实现设置分片标识、根据分片标识判断业务层是否可靠接收、以及在业务层未可靠接收的情况下自动进行重传等一系列操作，从而确保业务层的可靠传输。

图2示出了本公开又一个实施例提供的一种数据传输方法的流程图。如图2所示，该方法适用于交互式流媒体应用中的数据接收端，具体包括：

步骤S210：在传输交互式流媒体应用中的流媒体数据的过程中，接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片。

步骤S220：执行与多个数据分片组装后的交互操作数据相对应的交互操作。

其中，交互式流媒体应用中的数据接收端可以为云游戏应用中的客户端设备或服务端设备。相应的，客户端接收到通过多个时间片发送的多个数据分片之后，针对多个数据分片执行组装操作，从而还原出对应的交互操作数据，进而执行与交互操作数据相对应的交互操作。

另外，本申请又一实施例还提供了一种数据传输方法，该方法包括以下步骤：

步骤一、数据发送端在传输交互式流媒体应用中的流媒体数据的过程中，获取交互式流媒体应用中的交互操作数据；在交互操作数据满足分片条件的情况下，将交互操作数据拆分为多个数据分片，以将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端。

步骤二、数据接收端接收通过多个时间片发送的多个数据分片，以执行与多个数据分片组装后的交互操作数据相对应的交互操作。

为了便于理解，下面以一个示例为例，介绍上述实施例的实现方式。本示例主要应用于云游戏领域，云游戏是一种游戏运行和渲染在远程服务器上，用户通过网络实时接收视频流并发送控制信号的游戏模式。云游戏的优势在于降低了用户设备的性能要求，使采用性能较低的设备的用户也能获得高质量的游戏体验。然而，正是由于云游戏将游戏的运行过程和渲染过程部署在远程服务器上，因此，云游戏对网络延迟和带宽的要求非常高，以此确保良好的游戏体验。

下面先针对本示例中涉及的部分概念进行解释说明：

云游戏：云游戏是一种在云端服务器上运行的在线游戏。云游戏将游戏场景渲染成音视频流后，利用网络传输至玩家的游戏终端，并获取玩家在终端的输入指令，形成交互。

游戏数据：运行在云端服务器的游戏与终端玩家交互的关键信息，包括：玩家登录信息，游戏内操控信息，游戏资源信息等。

业务层可靠消息传输：在云游戏业务场景中指的是：游戏数据在玩家终端和云端服务器之间的交互过程中做到有序，不丢失，不重复。

网络流量整形：网络流量整形或者速率控制的主要目的是控制数据注入网络的速率，平滑突发的网络流量。

游戏控制数据(Game Control Data)：游戏控制数据是在网络游戏中，用于传输与用户的控制方式相关的数据，例如，游戏控制数据可以包括：用户的操作指令、控制指令以及游戏状态信息等数据。游戏控制数据也可以称作游戏操控数据，需要实时、准确地传输，以确保游戏同步和玩家之间的互动。游戏控制数据的传输性能直接影响到游戏体验的质量。

KCP协议：快速可靠传输协议，是一种面向无连接的可靠传输协议。KCP协议通过优化重传和流量控制算法实现了比传统TCP更高效的数据传输，尤其适用于实时通信和游戏等对延迟敏感的场景。

RTC：实时通信(Real-Time Communication)指在网络中实时传输语音、视频和数据的通信技术。RTC技术需要低延迟、高可靠性的网络环境，常用于在线会议、视频聊天、实时在线游戏等场景。例如，WebRTC(Web Real-Time Communications)是一项实时通讯技术，其允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点(Peer-to-Peer)的连接，实现视频流和/或音频流或者其他任意数据的传输。

重传(Retransmission)：重传是指在网络通信中，当发送方发现数据包未成功到达接收方时，重新发送该数据包的过程。重传机制是许多传输协议(如TCP和KCP)保证数据可靠传输的关键组成部分。然而，过多的重传可能导致网络拥塞和延迟增加，从而影响通信质量。KCP协议通过自定义的重传机制提升了数据传输效率，能够兼顾传输的可靠性和实时性。

随着互联网技术的高速发展和普及，云游戏作为一种新型的游戏模式逐渐引起广泛关注。云游戏将游戏的运行和渲染过程从本地设备转移到远程服务器，玩家通过网络实时接收服务器传输的视频流并发送操控数据。这种模式降低了玩家设备的性能要求，使得更多人能够轻松地享受到高品质的游戏体验。然而，云游戏对网络延迟和带宽的要求较高，以确保实时性和游戏体验。与传统的本地游戏不同，云游戏将游戏的运行和渲染过程从本地设备转移到远程服务器，因此，用户通过本地设备发送的游戏控制数据并不能直接在本地设备进行处理，而需要传输至远程服务器，由远程服务器根据接收到的游戏控制数据对游戏资源重新进行加载及渲染，进而得到根据游戏控制数据进行响应后的游戏画面，并将该响应后的游戏画面传输至本地设备。

由此可见，云游戏场景中需要在服务器和客户端之间传输大量的数据，主要包括游戏的音视频数据(即流媒体数据)以及游戏控制数据两种类型。由于上述两种类型的数据都需要通过服务器和客户端之间的带宽资源进行传输，因此，在游戏控制数据的突发流量较大的情况下，将导致游戏的音视频数据出现卡顿，进而影响音视频数据的播放效果。因此，为了保障音视频数据的播放效果，需要尽量避免突发的大流量游戏控制数据的传输。另外，游戏控制数据的可靠性要求较高，一旦游戏控制数据出现丢包、乱序等情况，将导致游戏交互环节出现错误，进而影响游戏功能的正常实现。由此可见，在云游戏这一特殊的应用场景中，既要尽量避免突发的大流量游戏控制数据挤占音视频数据的传输资源，又要确保游戏控制数据的可靠传输。因此，云游戏场景对于游戏控制数据的传输要求较高。

为了满足云游戏场景中的特殊需求，本示例提供了一种基于自定义传输协议实现的限流分片传输方法，并且，该自定义传输协议还能够设置分片标识从而基于分片标识实现业务层的可靠传输。

图3示出了本示例中的数据传输方法的流程图，如图3所示，该数据传输方法包括以下步骤：

步骤S301：在传输交互式流媒体应用中的流媒体数据的过程中，获取交互式流媒体应用中的交互操作数据；其中，交互操作数据用于针对流媒体数据执行交互操作。

在一种实现方式中，交互式流媒体应用中的交互操作数据即为上述的游戏控制数据。换言之，交互操作数据包括游戏控制数据中的各种类型的数据，如用户的操作指令、控制指令以及游戏状态信息等。

在又一种实现方式中，交互式流媒体应用中的交互操作数据包括：上述游戏控制数据中的指定类型的数据。在该方式中，交互操作数据可以仅包括游戏控制数据中数据量较大和/或对可靠性要求较高的部分特定类型的数据。例如，交互操作数据可以仅包括：游戏控制数据中的游戏状态信息、用于互动的资源类信息(如截屏产生的图片类资源信息、或话筒捕获的语音类资源信息)。该类信息通常数据量略大，且对于传输的可靠性要求较高，因此，更优选的，在本示例中，可以从获取到的游戏控制数据中，提取指定类型的数据作为交互式流媒体应用中的交互操作数据，从而针对提取得到的交互操作数据执行后续处理。

步骤S302：根据交互操作数据的数据量和/或数据类型，判断交互操作数据是否满足分片条件。

在一种可选的实现方式中，交互操作数据满足分片条件包括：交互操作数据的数据量大于当前时间片所支持的可用发送流量。在本示例中，当前时间片所支持的可用发送流量可以根据当前时间片传输的流媒体数据的数据量和/或数据类型动态确定。

在又一种可选的实现方式中，交互操作数据满足分片条件还可以包括：交互操作数据的数据类型属于预设类型，该预设类型包括：资源类型、和/或图片类型。

其中，分片条件可以根据实际业务场景灵活设定，主要用于识别突发的大流量数据，以便针对突发的大流量数据执行限流分片处理。

步骤S303：通过第一传输协议，将交互操作数据拆分为多个数据分片。

其中，第一传输协议是在业务层实现的自定义传输协议，用于实现数据分片的拆分、重组、重传等处理。其中，由同一条交互操作数据拆分得到的多个数据分片对应于多个不同的分片标识、且对应于相同的消息标识，以便通过消息标识快速识别属于同一交互操作数据的多个数据分片，并基于分片标识对多个数据分片进行排序重组操作。

图4示出了根据第一传输协议拆分得到的一个数据分片的数据结构示意图。如图4所示，从交互操作数据中拆分得到的一个数据分片包括协议头以及协议体两大部分。其中，协议头也叫消息头，对应于图4中的数据分片的第一个分片片段，协议头用于存储消息ID，该消息ID是一个64位的无符号整数，且严格单调递增。通常情况下，一个交互操作数据拆分得到的多个数据分片中的消息ID都是相同的，且多个依次产生的交互操作数据所对应的消息ID是严格单调递增的。由此可见，协议头中包含一个严格递增的消息ID，用来标识一条消息。

数据分片的第二个至第五个分片片段共同构成协议体部分，协议体部分用于存储序列化分片后的交互操作数据的数据内容。

其中，第一个分片片段用于表征消息类型，具体可以为一个8位的无符号整数。消息类型用于表征数据包的具体类型，可以包括：原始数据包类型、重传数据包类型、重建数据包类型、确认包数据类型。其中，原始数据包类型对应于初次传输的数据包。重传数据包类型对应于传输失败后重传的数据包。重建数据包类型对应于经过业务重建后再次发送的数据包，其内容通常与原始数据包不同。确认包数据类型对应于接收端返回的确认响应消息对应的数据包。相应的，接收端可以根据消息类型中的数据包类型信息确定不同的处理方式。

第二个分片片段用于表征当前分片消息的序列号，具体可以为一个32位的无符号整数。其中，当前分片消息的序列号即为当前数据分片的分片标识。

第三个分片片段用于表征当前分片消息的消息长度，具体可以为一个32位的无符号整数。其中，当前分片消息的消息长度即为当前数据分片的分片长度。

第四个分片片段用于表征当前数据分片所属的交互操作数据对应的消息总长度，具体可以为一个32位的无符号整数。例如，假设当前数据分片所属的交互操作数据对应的消息划分为3个数据分片，每个数据分片的分片长度为12，则消息总长度为36。

由此可见，对于通过限流分片方式发送的消息，可以通过当前分片消息的序列号和当前分片消息的消息长度，共同确定该分片消息在整包数据中的位置，其中，最后一个分片片段为整包消息的总长度。

当然，需要说明的是，对于不满足分片条件的交互操作数据而言，交互操作数据直接通过一个数据分片发送，即：交互操作数据对应的消息中只包含一个数据包，因此，可以省略上述协议体中的第二个分片片段以及第三个分片片段。

步骤S304：通过第二传输协议，将多个数据分片通过多个时间片发送至交互式流媒体应用中的数据接收端。

其中，第二传输协议是在传输层实现的可靠传输协议，具体可以是基于TCP/或者UDP的可靠传输协议。例如，第二传输协议可以是KCP协议，该协议通过优化重传和流量控制算法实现了较为高效的数据传输。由此可见，借助第二传输协议，能够在传输层实现数据的可靠传输和丢包重传。

在本示例中，通过第二传输协议与第一传输协议的嵌套使用，能够同时保证传输层和业务层的可靠处理。由此可见，业务层实现可靠消息传输的底层网络传输协议采用可靠传输协议实现，在此之上额外增加采用业务层可靠通信协议(即第一传输协议所对应的自定义协议)来携带实现业务层可靠通信必需的消息内容，具体包括图4中的各个分片片段。

步骤S305：将已发送的多个数据分片缓存至待确认消息队列。

其中，每当一个数据分片发送完毕之后，将其缓存至待确认消息队列。需要说明的是，本示例中以数据分片为例进行介绍，实际上，对于不满足分片条件的交互操作数据所对应的数据包的处理方式相同，即：可以将不满足分片条件的交互操作数据所对应的数据包视为一种特殊的数据分片。

步骤S306：根据接收到的确认响应消息删除待确认消息队列中对应的数据分片。

具体的，在接收到数据接收端返回的确认响应消息的情况下，获取确认响应消息中包含的分片标识和/或消息标识，删除待确认消息队列中与分片标识和/或消息标识相对应的数据分片。

步骤S307：在检测到网络状态满足预设暂停条件的情况下，暂停交互操作数据的发送操作，并将待发送的交互操作数据缓存至待发送队列。

其中，预设暂停条件可以包括：待发送队列的剩余存储空间小于第一预设阈值(例如待发送队列已满)，和/或，检测到数据发送端与数据接收端之间的传输通道断连。

例如，在检测到待发送队列已满的情况下，说明已发送的多个数据分片均未收到接收端的确认反馈，此时接收端很可能出现了死机、意外退出等故障，因此，为了确保因接收端故障而导致的数据包堆积问题，暂停交互操作数据的发送操作。具体实施时，可以将数据发送端设置为挂起状态，当数据发送端处于挂起状态时，新增的待发送的交互操作数据将缓存至待发送队列。

又如，在检测到数据发送端与数据接收端之间的传输通道断连的情况下，说明网络连接出现了异常，也需要将数据发送端设置为挂起状态。其中，检测数据发送端与数据接收端之间的传输通道断连可以通过探测数据包等方式实现。

步骤S308：在检测到网络状态满足预设恢复条件的情况下，恢复交互操作数据的发送操作，以将待发送队列中缓存的交互操作数据发送至交互式流媒体应用中的数据接收端。

其中，预设恢复条件包括：待发送队列的剩余存储空间不小于第二预设阈值(例如待发送队列出现若干空位)，和/或，检测到数据发送端与数据接收端之间的传输通道重连。其中，第二预设阈值与第一预设阈值可以相同也可以不同。检测数据发送端与数据接收端之间的传输通道重连可以通过探测数据包或心跳数据包等方式实现。

例如，在检查到待发送队列中的空位数量达到预设值的情况下，确定网络状态已恢复，从而恢复交互操作数据的发送操作。具体实施时，可以将数据发送端从挂起状态切换为连通状态，以便将待发送队列中缓存的交互操作数据发送至交互式流媒体应用中的数据接收端。

步骤S309：获取待发送队列中未删除的数据分片，重新将未删除的数据分片发送至交互式流媒体应用中的数据接收端。

其中，步骤S309的触发条件可以根据实际需要灵活设置。例如，在可靠性要求较高的业务场景中，一旦检测到数据发送端从挂起状态切换为连通状态，则执行步骤S309，以便针对尚未收到确认响应消息的数据分片重新发送。

又如，在其他业务场景中，可以设置一个断网时长阈值，在检测到数据发送端从挂起状态切换为连通状态后，进一步判断挂起状态的持续时长是否达到断网时长阈值，并在挂起状态的持续时长达到断网时长阈值的情况下，触发步骤S309，以便重新将待发送队列中未删除的数据分片发送至交互式流媒体应用中的数据接收端。在该方式中，若网络经过短暂的断开后立即恢复，则传输层ARQ机制会保证恢复和重传，业务层只需要等待传输层恢复即可(无需针对尚未收到确认响应消息的数据分片重新发送)。但是，若由于接收端应用异常或者长时间断连，此时，在网络恢复之后，接收端需要重新与发送端建立传输通道，为了防止在重新建立传输通道的过程中出现传输层已可靠送达但业务层未及时处理的情况，发送端在与接收端重连成功后会主动将待发送队列和待确认消息队列中的缓存消息按顺序重传。相应的，接收端根据消息类型和消息ID，对消息ID相同的重传包进行去重处理，确保每个消息只被业务层处理一次。通过上述方式，能够确保业务层的可靠传输。

另外，除根据断网时长阈值判断是否触发本步骤之外，还可以根据发送端设置为挂起状态的原因进行判断。例如，若发送端设置为挂起状态的原因为待发送队列出现堆积，则表明数据发送端与数据接收端之间的传输通道一直是正常的，只需等待传输层恢复即可，无需触发本步骤；若发送端设置为挂起状态的原因为数据发送端与数据接收端之间的传输通道断连，则表明数据发送端与数据接收端之间的传输通道出现了断开，为了防止在断开过程中出现传输层已送达但业务层未处理的消息，则需要触发本步骤，以确保业务层的可靠传输。总之，本步骤可以在检测到数据发送端与数据接收端之间的传输通道出现断连并重连的情况下触发，从而提升业务层的传输可靠性。

步骤S310：数据接收端接收数据发送端将交互操作数据拆分后通过多个时间片发送的多个数据分片，以执行与多个数据分片组装后的交互操作数据相对应的交互操作。

其中，数据接收端通过第二传输协议，接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片。其中，第二传输协议即为传输层的可靠传输协议，用于实现传输层的可靠送达。

并且，通过第一传输协议，获取每个数据分片中包含的分片标识以及消息标识，将对应于相同的消息标识、且分片标识符合组装条件的多个数据分片组装为一条数据消息，并根据组装得到的数据消息向数据发送端返回确认响应消息。其中，第一传输协议用于解析得到数据分片的分片消息序列号、分片消息长度等内容，以便实现针对数据分片的组装处理，从而实现业务层的可靠送达。

另外，为了避免重复处理的问题，在将对应于相同的消息标识、且分片标识符合组装条件的多个数据分片组装为一条数据消息之后，进一步根据数据消息中包含的消息标识，判断数据消息是否为重复接收的数据消息，若是，针对该重复接收的数据消息执行去重处理。

综上可知，在上述示例中，业务消息的可靠到达是由ACK确认和重传机制保证的，具体在已有的可靠传输协议之上嵌套了一层自定义传输协议，由自定义传输协议实现业务层的ACK确认和重传机制。另外，在发送端配置了两个队列：即待发送队列以及待确认消息队列。相应的，将需要发送的消息先缓存如待发送队列，当传输通道未建连时，消息在待发送队列中缓存，待建连后立刻发送。借助待发送队列，可以解决游戏启动和网络建连时机不同步造成的游戏数据丢失的问题。如果传输通道已经建连，则消息进入待发送队列后会立刻发出，发出后的消息进入待确认消息队列中。

另外，为了减少确认响应消息的发送频次，从而减少传输资源的占用、提升传输效率。接收端可以不必针对每个接收到的消息发送确认响应消息，而在连续接收到的各个消息的消息ID的增长数量达到预设值的情况下，统一发送一次确认响应消息，以通过该确认响应消息对之前接收到的多个消息进行确认。例如，接收端每收到一个完整的消息都会记录下当前接收到的消息ID，并在此消息ID相比上一次发送确认响应消息(即ACK确认消息)时接收到的消息ID相距达到预设阈值的情况下，向发送端发送携带当前消息ID的确认响应消息。其中，预设阈值可以根据待确认消息队列的长度灵活设定，例如，可以为待确认消息队列的队列长度的1/3。相应的，发送端收到该确认响应消息后，会将待确认消息队列中小于等于该消息ID的消息清空。其中，由于传输层已经实现了消息的可靠连续传输，因此，借助于传输层的可靠传输协议，能够保证连续接收到的多个消息的消息ID是连续的(由于可靠传输协议会针对丢包数据进行重传，因此，接收到的多个数据包不会出现丢包现象，进而能够确保多个消息的ID是连续的)。相应的，通过该方式能够简化确认响应消息的发送成本，并且，能够针对业务层可能出现的数据积压、网络断连等异常问题进行识别和处理。

另外，本示例能够很好的解决资源类游戏数据过大时，突发流量可能会挤占游戏视频流的带宽、造成卡顿影响玩家体验的问题。在本示例中，将将交互操作数据拆分为多个数据分片时，可以使用基于漏桶算法的分片发送方式，以平滑发送突发的网络流量。其中，漏桶算法的原理是将流入的流量以固定的速率流出。在发送大流量数据时，本示例使发送端进入平滑发送模式，在该模式下，待发送队列会周期性地计算当前可用的发送流量，并将队列中的消息分片到该可用流量以下进行发送，从而控制发送流量在预设带宽的上限以下。具体实施时，可以在发送端设置限流器，从而通过限流器实现限流分片发送的目的。接收端的接收器(如组包接收器)自动识别出分片消息，对于分片消息进行组包，并在收到完整消息后将组包完成的消息发送给业务层，然后发送ACK确认消息给发送端。

总之，在云游戏场景中，游戏本体运行在云端服务器上，玩家在终端的登录信息和操控数据经过网络传输到服务端，服务端将相应的游戏场景渲染后并将相应的音视频流后发送给玩家。其中有些数据是比较关键的信息，不能有乱序，丢失和重复，比如关键的操控信息，用户登录信息和影响玩家侧游戏表现的其它信息等。这类要求可靠性传输的消息会选择可靠传输协议进行传输，如基于TCP的websocket协议，基于UDP的KCP协议等等。但这些可靠的传输协议只能保证“传输层”的可靠性，并不能完全保证“业务层”的可靠性。在云游戏场景中，需要保证关键游戏数据即使在发生信道断线后重连，或者玩家客户端意外退出后重连以后，仍可以保证不丢失，不重复地到达对端，仅仅依靠现有的可靠传输协议并不能完全解决这个问题。现有的传输层可靠协议仅能保证网络传输层的可靠性，在发生网络连接异常或者应用处理异常(如意外退出或卡死)时，无法确认确保对端的应用层已经正确接受并处理了这个消息。因此本示例设计了一个业务层的可靠传输机制，确保关键的游戏交互数据可以正确到达对端并处理。同时针对云游戏的特殊场景，需要优先保证音视频流的传输带宽，防止被过大的突发资源类游戏数据抢占，影响玩家游戏体验，本示例针对大流量的游戏数据设计了一种限制发送流量的分片式可靠发送方法。其中，针对云游戏场景，设计了一种业务层的可靠消息的收发算法和协议，通过ACK确认和重传机制，解决了各种可能场景下游戏数据丢失的问题，通过接收端的消息去重机制，解决重传后消息可能重复的问题。并且，针对突发大流量的游戏数据，设计了一种限流分片发送的可靠传输算法，解决了大流量数据挤占音视频流带宽的问题。同时通过优化定时发送和重传机制，提升了算法本身的性能和传输效率。其中，对关键的游戏数据应用本示例设计的可靠消息收发算法，结合可靠的底层传输层协议，能够解决云游戏各种场景下游戏数据可能丢失的问题，同时能够防止重传产生的消息重复。对于突发的大流量游戏数据，可切换至分片限流的可靠收发模式，将消息限制在一定流量下进行发送，防止挤占游戏视频流的带宽，造成游戏画面卡顿。

图5示出了本公开又一实施例提供的一种数据传输装置的示意图，该数据传输装置适用于交互式流媒体应用中的数据发送端，该装置具体包括：

获取模块51，适于在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；

拆分模块52，适于在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端。

本公开又一实施例提供还提供了一种数据传输装置，该数据传输装置适用于交互式流媒体应用中的数据接收端，所述装置包括：

接收模块，适于在传输所述交互式流媒体应用中的流媒体数据的过程中，接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片，以执行与所述多个数据分片相对应的交互操作。

另外，本申请又一实施例还提供了一种数据传输系统，该系统包括：上述的数据发送端以及数据接收端。

图6示出了根据本公开又一实施例的一种电子设备的结构示意图，本公开具体实施例并不对电子设备的具体实现做限定。

如图6所示，该电子设备可以包括：处理器(processor)502、通信接口(Communications Interface)506、存储器(memory)504、以及通信总线508。

其中：

处理器502、通信接口506、以及存储器504通过通信总线508完成相互间的通信。

通信接口506，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器502，用于执行程序510，具体可以执行上述视频图像的检测方法实施例中的相关步骤。

具体地，程序510可以包括程序代码，该程序代码包括计算机操作指令。

处理器502可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本公开实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU。也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器504，用于存放程序510。存储器504可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序510具体可以用于使得处理器502执行上述视频图像的检测方法实施例中对应的各个操作。

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本公开也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本公开的内容，并且上面对特定语言所做的描述是为了披露本公开的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本公开的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个公开方面中的一个或多个，在上面对本公开的示例性实施例的描述中，本公开的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本公开要求比在每个权利要求中所明确记载的特征更多的特征。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本公开的范围之内并且形成不同的实施例。例如，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本公开的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本公开实施例的装置中的一些或者全部部件的一些或者全部功能。本公开还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本公开的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本公开进行说明而不是对本公开进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (17)

1.一种数据传输方法，适用于交互式流媒体应用中的数据发送端，包括：

在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；其中，所述交互操作数据用于针对所述流媒体数据执行交互操作；

在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端。

2.根据权利要求1所述的方法，其中，所述交互操作数据满足分片条件包括以下中的至少一种：

所述交互操作数据的数据量大于当前时间片所支持的可用发送流量；其中，所述当前时间片所支持的可用发送流量根据当前时间片传输的流媒体数据的数据量和/或数据类型确定；

所述交互操作数据的数据类型属于预设类型，其中，所述预设类型包括：资源类型、和/或图片类型。

3.根据权利要求1或2所述的方法，其中，所述将所述交互操作数据拆分为多个数据分片包括：

通过第一传输协议，将所述交互操作数据拆分为多个数据分片；其中，所述多个数据分片对应于多个不同的分片标识、且对应于相同的消息标识；其中，所述第一传输协议是在业务层实现的自定义传输协议；

并且，所述将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端包括：

通过第二传输协议，将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端；其中，所述第二传输协议是在传输层实现的可靠传输协议。

4.根据权利要求3所述的方法，其中，所述将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端之后，还包括：将已发送的多个数据分片缓存至预设缓存空间；

并且，所述方法还包括：在接收到所述数据接收端返回的确认响应消息的情况下，获取所述确认响应消息中包含的分片标识和/或消息标识，删除所述预设缓存空间中与所述分片标识和/或消息标识相对应的数据分片。

5.根据权利要求4所述的方法，其中，所述将已发送的多个数据分片缓存至预设缓存空间之后，还包括：

在检测到网络状态满足预设暂停条件的情况下，暂停所述交互操作数据的发送操作，并将待发送的交互操作数据缓存至待发送队列；

并且，在检测到网络状态满足预设恢复条件的情况下，恢复所述交互操作数据的发送操作，以将所述待发送队列中缓存的交互操作数据发送至所述交互式流媒体应用中的数据接收端。

6.根据权利要求5所述的方法，其中，所述预设暂停条件包括：所述预设缓存空间的剩余存储空间小于第一预设阈值，和/或，检测到数据发送端与数据接收端之间的传输通道断连；

所述预设恢复条件包括：所述预设缓存空间的剩余存储空间不小于第二预设阈值，和/或，检测到数据发送端与数据接收端之间的传输通道重连。

7.根据权利要求5或6所述的方法，其中，所述恢复所述交互操作数据的发送操作之后，还包括：

获取所述预设缓存空间中未删除的数据分片，重新将所述未删除的数据分片发送至所述交互式流媒体应用中的数据接收端。

8.根据权利要求1-7任一所述的方法，其中，所述交互式流媒体应用为云游戏应用；所述交互操作数据包括：游戏登录数据、游戏操控指令、游戏资源数据；并且，所述交互式流媒体应用中的流媒体数据通过第三传输协议传输。

9.一种数据传输方法，适用于交互式流媒体应用中的数据接收端，包括：

在传输所述交互式流媒体应用中的流媒体数据的过程中，接收数据发送端将交互操作数据拆分后通过多个时间片发送的多个数据分片，以执行与所述多个数据分片组装后的交互操作数据相对应的交互操作。

10.根据权利要求9所述的方法，其中，所述接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片包括：

通过第二传输协议，接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片；

通过第一传输协议，获取每个数据分片中包含的分片标识以及消息标识，将对应于相同的消息标识、且分片标识符合组装条件的多个数据分片组装为一条数据消息，并根据组装得到的数据消息向所述数据发送端返回确认响应消息。

11.根据权利要求10所述的方法，其中，所述将对应于相同的消息标识、且分片标识符合组装条件的多个数据分片组装为一条数据消息之后，还包括：

根据所述数据消息中包含的消息标识，判断所述数据消息是否为重复接收的数据消息，若是，针对所述数据消息执行去重处理。

12.一种数据传输方法，包括：

数据发送端在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端；

数据接收端接收通过多个时间片发送的所述多个数据分片，以执行与所述多个数据分片组装后的交互操作数据相对应的交互操作。

13.一种数据传输装置，适用于交互式流媒体应用中的数据发送端，包括：

获取模块，适于在传输所述交互式流媒体应用中的流媒体数据的过程中，获取所述交互式流媒体应用中的交互操作数据；

拆分模块，适于在所述交互操作数据满足分片条件的情况下，将所述交互操作数据拆分为多个数据分片，以将所述多个数据分片通过多个时间片发送至所述交互式流媒体应用中的数据接收端。

14.一种数据传输装置，适用于交互式流媒体应用中的数据接收端，包括：

接收模块，适于在传输所述交互式流媒体应用中的流媒体数据的过程中，接收数据发送端将满足分片条件的交互操作数据拆分后通过多个时间片发送的多个数据分片，以执行与所述多个数据分片相对应的交互操作。

15.一种数据传输系统，包括：权利要求13所述的适用于交互式流媒体应用中的数据发送端的数据传输装置、以及权利要求14所述的适用于交互式流媒体应用中的数据接收端的数据传输装置。

16.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-12中任一项所述的数据传输方法。

17.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-12中任一项所述的数据传输方法。