CN113676605A - 数据传输方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例提供一种数据传输方法、装置、设备及计算机可读存储介质，其中，方法包括：向接收端发送数据包；当接收到所述接收端返回的与所述数据包对应的否定应答消息时，获取所述接收端在当前时刻之前的预设时间段内的丢包参数；根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔；按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传。通过本申请，能够极大的减小丢包重传的耗时，从而能够使得本申请实施例的丢包重传方案广泛的应用于实时性要求高的应用中。

Description

数据传输方法、装置、设备及计算机可读存储介质

技术领域

本申请实施例涉及通信技术领域，涉及但不限于一种数据传输方法、装置、设备及计算机可读存储介质。

背景技术

基于IP的语音传输(VoIP，Voice over Internet Protocol)是基于以太网的实时语音通话系统，网络质量、网络传输能力对VoIP双方通话质量有着决定性的影响，VoIP为了确保实时通话数据传输，通常采用的是UDP不可靠传输协议，在网络状况不佳情况下丢包是经常发生的，解决该问题的主要方法有前向纠错技术和丢包重传技术，其中丢包重传技术是常用的方法。

相关技术中，丢包重传技术需要每个数据报文都需要做接收状态确认，即需要发送接收确认报文，在一次重传后，发送方需要确认接收方是否接收成功，如果确认接收方没有成功接收到正确的数据报文，则发送方需要继续进行重传直到传输成功为止。因此，相关技术中的丢包重传是一种应答机制的重传方式。

但是，应答机制的丢包重传方法，在每一次交互过程中都需要耗用较多的时间，这对于实时性要求高的应用(例如VoIP通话)肯定是不利的，所以相关技术中的丢包重传方法在实时性要求高的应用中有较大的限制。

发明内容

本申请实施例提供一种数据传输方法、装置、设备及计算机可读存储介质，根据接收端的丢包参数确定重传次数和重传间隔，并按照重传次数和重传间隔对数据包进行至少两次重传，如此无需每次重传都要在接收端应答之后再进行，能够减小丢包重传的耗时，从而能够广泛的应用于实时性要求高的应用中。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种数据传输方法，包括：

向所述接收端发送数据包；

当接收到所述接收端返回的与所述数据包对应的否定应答消息时，获取所述接收端在当前时刻之前的预设时间段内的丢包参数；

根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔；

按照所述重传次数和重传间隔，对所述数据包进行至少两次重传。

本申请实施例提供一种数据传输方法，包括：

接收发送端发送的数据包；

当所述数据包接收失败或者所述数据包发送错误时，获取接收端在当前时刻之前的预设时间段内的丢包参数；

向所述发送端发送所述丢包参数和与所述数据包对应的否定应答消息，以使得所述发送端根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，并按照所述重传次数和重传间隔，对所述数据包进行至少两次重传；

接收所述发送端重传的所述数据包。

本申请实施例提供一种数据传输装置，包括：

第一发送模块，用于向接收端发送数据包；

第一获取模块，用于当接收到所述接收端返回的与所述数据包对应的否定应答消息时，获取所述接收端在当前时刻之前的预设时间段内的丢包参数；

确定模块，用于根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔；

重传模块，用于按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传。

本申请实施例提供一种数据传输装置，包括：

第一接收模块，用于接收发送端发送的数据包；

第二获取模块，用于当所述数据包接收失败或者所述数据包发送错误时，获取接收端在当前时刻之前的预设时间段内的丢包参数；

第二发送模块，用于向所述发送端发送所述丢包参数和与所述数据包对应的否定应答消息，以使得所述发送端根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，并按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传；

第二接收模块，用于接收所述发送端重传的所述数据包。

本申请实施例提供一种数据传输设备，包括：

存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现上述的方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现上述的方法。

本申请实施例具有以下有益效果：根据接收端在当前时刻之前的预设时间段内的丢包参数，确定与接收端对应的重传次数和重传间隔，并按照重传次数和重传间隔，对数据包进行至少两次重传。如此，由于可以直接按照重传次数和重传间隔对数据包进行至少两次重传，无需每次重传都要在接收端应答之后再进行，即无需考虑接收端的应答参数，因此，能够极大的减小丢包重传的耗时，从而能够将本申请实施例的丢包重传方案广泛的应用于实时性要求高的应用中。

附图说明

图1是相关技术中的选择性重传方式的流程图；

图2A是本申请实施例提供的数据传输系统20的一个可选的架构示意图；

图2B是本申请实施例提供的数据传输系统20应用于区块链系统的一个可选的结构示意图；

图2C是本申请实施例提供的区块结构的一个可选的示意图；

图3是本申请实施例提供的服务器300的结构示意图；

图4是本申请实施例提供的数据传输方法的一个可选的流程示意图；

图5是本申请实施例提供的数据传输方法的一个可选的流程示意图；

图6A是本申请实施例提供的数据传输方法的一个可选的流程示意图；

图6B是本申请实施例提供的数据传输方法的一个可选的流程示意图；

图7是本申请实施例提供的数据传输方法的一个可选的流程示意图；

图8是本申请实施例提供的数据传输方法的一个可选的流程示意图；

图9A是本申请实施例提供的数据传输方法的一个可选的流程示意图；

图9B是本申请实施例提供的数据传输方法的一个可选的流程示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

为了更好地理解本申请实施例中提供的数据传输方法，首先对相关技术中的数据传输方法进行说明：

VoIP通常采用的是用户数据报协议(UDP，User Datagram Protocol)，是不可靠传输协议，在网络状况不佳情况下丢包是经常发生的，解决该问题的主要方法有前向纠错技术和丢包重传技术。

前向纠错技术是利用冗余编码的方式，在实时数据包里面携带用于校正恢复的冗余信息，当出现丢包后接收端则会利用后继正常数据包的冗余信息对丢失数据包进行恢复，但是该技术是有较大局限的，因为前向纠错技术恢复能力有限，只能对丢包数较少的情况(例如连续丢包在4个以内)比较有效，而且对于每个数据包均要加入冗余信息，增大了传输带宽，同时冗余包的编码和解码也需要消耗一定的处理开销。

丢包重传技术是另一种解决丢包的技术，即当接收方检测目标数据包超时仍未接收到或者发现接收包出错，则接收端向发送端发出请求，请求发送方重传出错的数据包的一种技术手段。但是，丢包重传技术需要接收方发送更多的交互数据，对于网络能力较弱的情况也会增大网络负荷，在网络负荷重情况下效果不理想。

本申请实施例是在丢包重传技术的基础上提出的，其中，相关技术中的丢包重传技术通常是基于自动重传请求(ARQ，Automatic Repeat Request)的重传方式，相关技术中的ARQ技术方案主要是以下几种方式：停等式丢包重传方式、回退N帧丢包重传方式和选择性重传方式。

对于停等式丢包重传方式，数据报文(即数据包)发送完成后，发送端等待接收端的状态报告，如果状态报告报文表示发送成功，发送端才会发送后续的数据报文，如果状态报告报文表示发送失败，则发送端重传该报文。在停等式重传方式下，发送端每发一帧数据之后，必须停下来等接接收端的确认，等收到确认报文后才可发下一帧，所以其缺点是信道利用率很低。

对于回退N帧丢包重传方式，在回退N帧重传方式中，当发送端接收到接收端的状态报文指示报文出错后，发送端将重传过去N个报文。回退N帧重传与停等式丢包重传不同的地方在于：该方式不需要在接收到上一个数据报文的状态确认报文后才发送下一个数据报文，而可以连续发送数据报文。在发送端发送数据报文的过程中，如果接收到对应已发的某个数据报文的失败状态确认报文，则发送端需要将该状态报文对应的数据报文及后续N帧报文进行重发。但这种重传方式对于报文乱序情况就会导致误判为丢包，导致N个成功报文被重发，影响了发送效率。

对于选择性重传方式，在选择性重传方式中，当发送端接收到接收端的状态报文指示报文出错后，发送端只需发送发生错误的报文。选择性重传与回退N帧重传方式差别在于：只对没有成功收到状态确认报文的数据报文进行重发，不需要对后续N帧都要重发，其效率有所提升。

如图1所示，是相关技术中的选择性重传方式的流程图，在丢包重传的具体实现过程中，发送端接收来自进程的Req请求11，发送端对数据包进行分组，并将分组后的数据包(如图1中的分组0、分组1、分组2和分组3)发送给接收端，接收端在分组到达时(即pArr)，数据包12被交付给应用层，进行数据解码和播放。在数据传输的过程中，会在开始传输数据的时候启动计时器，在接收到接收端返回的确认字符(ACK，Acknowledge Character)之后(如图1中的ACK 0、ACK 1、ACK2、ACK 3)，即ACK到达时(即aArr)，停止计时。

如图1所示，分组0传输成功，因此，在分组0传输成功之后接收到ACK0，计时器停止计时；分组1、分组2和分组3依次传输，其中，分组1传输失败，数据丢失，分组2和分组3传输成功，则在选择性重传方式中，在分组3传输成功返回ACK 3之后，由于超时(T-Out)，此时需要重启计时器，并重传分组1，当重传成功时，接收到ACK 1，此时停止计时。也就是说，在选择性重传方式中，发生丢包时接收端可以发送错误报文给发送端，为了避免状态报文传送失败导致发送端处于长期等待的问题，发送端会同时采用定时检测方式，即如果到了定时结束时仍没有收到状态报文，则等同于接收到失败状态报文。

相关技术中的丢包重传方式，需要每个数据报文都做接收状态确认，即在数据包的首次发送之后，需要接收到接收端发送的接收确认报文(ACK)才会停止重传，这种操作需要占用相当一部分网络带宽资源。如果第一次重传后，接收方仍然没有成功接收到正确的数据报文，则发送方需要继续进行重传直到成功为止，且在每次重传的过程中，均需要在接收到否定应答消息之后才确定出要继续重传，在接收到ACK之后确定出不需要再重传。那么，在网络能力较弱的情况下，每个数据报文都可能经历这样的过程，无疑是对网络带宽施加更大的压力，不利于解决网络丢包问题，更重要的是丢包重传是一种应答机制，所以每一次交互过程都需要耗用较多的时间(因为需要等待接收ACK)，这对于实时性要求高的应用肯定是不利的，例如VoIP通话过程，如果重传包到达时间超过了播放端声卡播放的有效时刻，则即使数据包到达接收端也是被当作无效包丢弃，所以丢包重传方法在实时性要求高的应用中有较大的限制。

基于相关技术所存在的上述至少一个问题，本申请实施例提供一种数据传输方法，用于实现数据包丢失后的重传。首先，向接收端发送数据包；然后，当接收到接收端返回的与数据包对应的否定应答消息时，获取接收端在当前时刻之前的预设时间段内的丢包参数；并根据丢包参数，确定与接收端对应的重传次数和重传间隔；最后，按照重传次数和重传间隔，对数据包进行至少两次重传。如此，由于可以直接按照重传次数和重传间隔对数据包进行至少两次重传，无需每次重传都要在接收端应答之后再进行，即无需考虑接收端的应答参数，因此，能够极大的减小丢包重传的耗时，从而能够将本申请实施例的丢包重传方案广泛的应用于实时性要求高的应用中。

下面说明本申请实施例提供的数据传输设备的示例性应用，本申请实施例提供的数据传输设备可以实施为笔记本电脑，平板电脑，台式计算机，移动设备(例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备)、智能机器人等任意的终端，也可以实施为服务器。下面，将说明信息推荐设备实施为服务器时的示例性应用。

参见图2A，图2A是本申请实施例提供的数据传输系统20的一个可选的架构示意图。为支撑任意一种视频播放应用，以实现对视频对应的数据包进行显示，数据传输系统20中包括终端100(作为接收端)、网络200和服务器300(作为发送端)。其中，终端100上运行有应用程序，在实现本申请实施例的数据传输方法时，用户通过在终端100进行交互操作，触发终端100通过网络200向服务器300发送数据发送请求(在S1步骤执行)，其中数据发送请求中包括数据包的标识，服务器300在接收到数据发送请求后，响应于终端100发送的数据发送请求，向终端100发送数据包；当接收到终端100返回的与数据包对应的否定应答消息(在S2步骤执行)时，获取终端100在当前时刻之前的预设时间段内的丢包参数；根据丢包参数，确定与终端100对应的重传次数和重传间隔；按照重传次数和重传间隔，对数据包进行至少两次重传，以使得终端100接收到重传数据包(在S3步骤执行)，并成功解析数据包，在终端100的当前页面100-1上显示数据包对应的视频。

本申请实施例涉及的数据传输系统20也可以是区块链系统的分布式系统201，参见图2B，图2B是本申请实施例提供的数据传输系统20应用于区块链系统的一个可选的结构示意图，其中，所述分布式系统201可以是由多个节点202(接入网络中的任意形式的计算设备，如服务器、用户终端)和客户端203形成的分布式节点，节点之间形成组成的点对点(P2P，Peer To Peer)网络，P2P协议是一个运行在传输控制协议(TCP，TransmissionControl Protocol)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。

需要说明的是，在分布式系统201中，每一节点202对应一终端100，在每一用户的终端100上，会收集该终端100的丢包参数，例如，收集该终端100在历史时间段内的丢包数量和接收的数据包的总数量，从而根据丢包数量和接收的数据包的总数量计算该终端100在历史时间段内的丢包率；或者，还可以收集该终端100在历史时间段内的连续丢包数量等丢包参数。通过收集这些丢包参数，并将丢包参数上链存储，能够保证在后续重传过程中，从区块链系统中直接获取到准确的丢包参数，并根据丢包参数直接确定出重传次数，实现对后续需要重传的数据包进行高效准确的重传。

本申请实施例中，在该区块链系统中，每一用户的终端100的丢包参数均会被记录下来，且不可更改，并且，随着终端100进一步接收数据包，会产生新的丢包参数，因此会存在丢包参数的更新，那么，区块链中所存储的数据也会发生更新，因此，能够及时地对丢包参数进行更新，从而使得发送端能够根据准确的丢包参数确定出合适的重传次数，以进一步对数据包进行高效准确的重传。

在另一些实施例中，所确定出的任一数据包对应的重传次数也可以进行上链存储，被记录于区块链系统中。这样，可以便于后续在继续传输该数据包的时候，在需要确定重传次数时，可以直接获取到该数据包对应的重传次数，或者可以按照当前所确定的重传次数进行新的重传次数的确定，为该数据包的新的重传次数的确定提供可靠的依据。

参见图2B示出的区块链系统中各节点的功能，下面对区块链系统中各节点涉及的功能进行详细介绍：

1)路由，节点具有的基本功能，用于支持节点之间的通信。节点除具有路由功能外，还可以具有以下功能：

2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。例如，应用实现的业务包括：2.1)钱包，用于提供进行电子货币的交易的功能，包括发起交易(即，将当前交易的交易记录发送给区块链系统中的其他节点，其他节点验证成功后，作为承认交易有效的响应，将交易的记录数据存入区块链的临时区块中；当然，钱包还支持查询电子货币地址中剩余的电子货币。2.2)共享账本，用于提供账目数据的存储、查询和修改等操作的功能，将对账目数据的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认账目数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的节点发送确认。2.3)智能合约，计算机化的协议，可以执行某个合约的条款，通过部署在共享账本上的用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的交易，例如查询买家所购买商品的物流状态，在买家签收货物后将买家的电子货币转移到商户的地址；当然，智能合约不仅限于执行用于交易的合约，还可以执行对接收的信息进行处理的合约。

3)区块链，包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。

4)共识(Consensus)，是区块链网络中的一个过程，用于在涉及的多个节点之间对区块中的交易达成一致，达成一致的区块将被追加到区块链的尾部，实现共识的机制包括工作量证明(PoW，Proof of Work)、权益证明(PoS，Pr oof of Stake)、股份授权证明(DPoS，Delegated Proof-of-Stake)、消逝时间量证明(PoET，Proof of Elapsed Time)等。

参见图2C，图2C是本申请实施例提供的区块结构(Block Structure)的一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了相关的信息，用于验证其信息的有效性(防伪)和生成下一个区块。

参见图3，图3是本申请实施例提供的服务器300的结构示意图，图3所示的服务器300包括：至少一个处理器310、存储器350、至少一个网络接口320和用户接口330。服务器300中的各个组件通过总线系统340耦合在一起。可理解，总线系统340用于实现这些组件之间的连接通信。总线系统340除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统340。

处理器310可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口330包括使得能够呈现媒体内容的一个或多个输出装置331，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口330还包括一个或多个输入装置332，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器350可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器350可选地包括在物理位置上远离处理器310的一个或多个存储设备。存储器350包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器350旨在包括任意适合类型的存储器。在一些实施例中，存储器350能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统351，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块352，用于经由一个或多个(有线或无线)网络接口320到达其他计算设备，示例性的网络接口320包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

输入处理模块353，用于对一个或多个来自一个或多个输入装置332之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图3示出了存储在存储器350中的一种数据传输装置354，该数据传输装置354可以是服务器300中的一种数据传输装置，其可以是程序和插件等形式的软件，包括以下软件模块：第一发送模块3541、第一获取模块3542、确定模块3543和重传模块3544，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

在另一些实施例中，存储在存储器350中的另一种数据传输装置，该数据传输装置可以是服务器中的另一种数据传输装置，其也可以是程序和插件等形式的软件，包括以下软件模块(图中未示出)：第一接收模块、第二获取模块、第二发送模块和第二接收模块，这些模块也是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。

在再一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的数据传输方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specif ic Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic De vice)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。

下面将结合本申请实施例提供的服务器300的示例性应用和实施，说明本申请实施例提供的数据传输方法。参见图4，图4是本申请实施例提供的数据传输方法的一个可选的流程示意图，将结合图4示出的步骤进行说明。

步骤S401，向接收端发送数据包。

这里，发送端可以响应于接收端发送的数据发送请求，向接收端发送数据包，或者，发送端主动向接收端发送数据包，或者，在数据传输系统中，除了发送端和接收端之外，还具有其他服务器，其他服务器响应于接收端或其他设备的数据传输指令，控制发送端向接收端发送数据包。

在一些实施例中，用户可以通过接收端发送数据发送请求，数据发送请求用于请求发送端向接收端发送数据包，数据发送请求中包括数据包的标识。当发送端接收到接收端发送的数据发送请求之后，响应于数据发送请求，向接收端发送数据包。

举例来说，当用户想要播放视频时，可以通过接收端向发送端发送视频播放请求，视频播放请求中包括视频的标识。当发送端接收到视频播放请求之后，响应于视频播放请求，向接收端发送该视频对应的视频数据包，以使得当接收端接收到视频数据包之后，可以对视频数据包进行解码和播放。

步骤S402，当接收到接收端返回的与数据包对应的否定应答消息时，获取接收端在当前时刻之前的预设时间段内的丢包参数。

这里，否定应答消息是指接收端在未收到数据包或者收到错误数据包之后所反馈的消息，否定应答消息可以是“告知没有收到”或者“没有告知收到”消息(NACK，Non-Acknowledge Character)。

当发送端接收到否定应答消息时，表明接收端未接收到或者接收到错误的数据包，所以需要发送端向接收端重发数据包，本申请实施例中，可以基于接收端的丢包参数来实现对接收端进行数据包的重传。丢包参数包括但不限于接收端在当前时刻之前的预设时间段内的丢包率、丢包数量、连续丢包数量和网络状态等参数，其中，丢包参数是接收端在当前时刻之前的任意预设时间段内的参数，例如，可以是当前时刻之前的1秒内的参数，或者是当前时刻之前的5秒内的参数等，本申请实施例对丢包参数所对应的预设时间段不做限定。

在一些实施例中，丢包参数所对应的预设时间段的网络状态与当前时刻的网络状态相同，例如，可以通过检测当前时刻的网络带宽和预设时间段内的网络带宽，如果当前时刻的网络带宽与预设时间段内的网络带宽之间的差值小于阈值，则可以获取该预设时间段内的丢包参数。

步骤S403，根据丢包参数，确定与接收端对应的重传次数和重传间隔。

这里，重传次数是用于进行数据包重传的重传参数，重传参数包括但不限于重传次数和重传间隔，其中，重传次数是指数据包需要重传的次数，重传间隔是指每次重传与上一层传输之间的时间间隔。需要说明的是，当重传次数为多次时，重传间隔可以相同也可以不同。举例来说，当根据丢包参数确定的重传参数为重传2次、重传间隔依次为40ms和30ms，则可以在发送端发送数据包之后的40ms时，对数据包进行第一次重传，在第一次重传之后的30ms时，对数据包进行第二次重传。

本申请实施例中，根据丢包参数确定与接收端对应的重传次数，可以是根据接收端的丢包率确定重传次数，接收端的丢包率越高，重传次数越低；接收端的丢包率越高，重传次数越低。重传间隔可以在确定出重传次数之后，根据重传次数来确定，重传次数越高，重传间隔越小，重传次数越低，重传间隔越大。或者，重传间隔也可以是一固定值，重传间隔与重传次数一一对应，当确定出重传次数的同时，即可确定出与重传次数对应的重传间隔。

步骤S404，按照重传次数和重传间隔，对数据包进行至少两次重传。

本申请实施例中，重传次数为至少两次。在确定出重传次数之后，按照重传次数对数据包进行重传，可以按照重传次数对数据包进行多次重传。

本申请实施例中，在确定出重传次数和重传间隔之后，即可按照重传次数和重传间隔对数据包进行重传，不用等待接收端的反馈信息，即在重传的过程中，可以不需要接收到接收端反馈的否定应答消息(例如NACK报文)或确认应答消息(例如ACK报文)，或者不考虑接收端发送的否定应答消息或确认应答消息，即如果在重传的过程中接收到确认应答消息，还可以继续对数据包进行重传，直到完成重传参数规定的重传次数，也就是说，只需按照所确定出的重传次数对数据包进行连续重传，以完成与重传次数对应的数据包重传过程即可。

在一些实施例中，还可以在确定出重传次数之后，先连续重传预设次数(例如重传两次或三次)，然后，确定是否接收到否定应答消息或确认应答消息，如果接收到否定应答消息时，则继续后续的重传；如果已经接收到确认应答消息时，停止对数据包的重传。

在一些实施例中，在按照所确定出的重传次数进行重传完成之后，如果检测到接收端反馈的仍然是否定应答消息时，可以采用步骤S402至步骤S404的步骤，重新确定重传次数，并继续对数据包进行重传。或者，在按照所确定出的重传次数进行重传完成之后，如果检测到接收端反馈的仍然是否定应答消息时，可以停止对该数据包的重传，向接收端发送下一个数据包。

本申请实施例提供的数据传输方法，根据接收端在当前时刻之前的预设时间段内的丢包参数，确定与接收端对应的重传次数和重传间隔，并按照重传次数和重传间隔，对数据包进行至少两次重传。如此，由于可以直接按照重传次数和重传间隔对数据包进行至少两次重传，无需每次重传都要在接收端应答之后再进行，即无需考虑接收端的应答参数，因此，能够极大的减小丢包重传的耗时，从而能够将本申请实施例的丢包重传方案广泛的应用于实时性要求高的应用中。

在一些实施例中，数据传输系统中包括作为接收端的终端和作为发送端的服务器，本申请实施例以接收端和发送端为例，对本申请实施例提供的数据传输方法进行说明。图5是本申请实施例提供的数据传输方法的一个可选的流程示意图，如图5所示，方法包括以下步骤：

步骤S501，接收端向发送端发送数据发送请求，数据发送请求用于请求发送端发送数据包。这里，数据发送请求中包括数据包的标识。

步骤S502，发送端响应于数据发送请求，获取与数据包的标识对应的数据包。

步骤S503，发送端向接收端发送数据包。

步骤S504，当数据包接收失败或者数据包发送错误时，获取接收端在当前时刻之前的预设时间段内的丢包参数。

这里，数据接收失败是指接收端未成功接收到数据包，数据包发送错误是指所发送的数据包与数据发送请求所请求的数据包不同。接收端在接收到数据包之后，会对数据包进行解析，确定数据包中的数据格式、数据内容等信息是否正确，如果正确的话，将解析后的数据包在接收端设备上进行播放，并且，向发送端反馈确认应答消息；如果确定数据包中的数据格式、数据内容等任一信息不正确的话，则会向发送端反馈否定应答消息。本申请实施例中，在反馈否定应答消息之前，先获取接收端在当前时刻之前的预设时间段内的丢包参数。丢包参数用于表征接收端在预设时间段内的丢包状况和网络状态。

在一些实施例中，步骤S504中可以是由接收端获取自身在当前时刻之前的预设时间段内的丢包参数，也可以是接收端或发送端从区块链系统中获取接收端在当前时刻之前的预设时间段内的丢包参数。

步骤S505，接收端向发送端发送丢包参数和与数据包对应的否定应答消息。

这里，如果接收端获取丢包参数的话，接收端将丢包参数和否定应答消息发送给发送端；如果发送端自己获取丢包参数的话，接收端将否定应答消息发送给发送端。

步骤S506，发送端根据丢包参数，确定与接收端对应的重传次数和重传间隔。

步骤S507，发送端按照重传次数和重传间隔，对数据包进行至少两次重传，以使得接收端接收到数据包。

本申请实施例中，对于接收端来说，当接收到重传的数据包且重传的数据包解析正确时，可以向发送端反馈确认应答消息(例如ACK消息)；当接收端未接收到重传的数据包或者重传的数据包解析错误时，向发送端反馈否定应答消息(例如NACK消息)。对于发送端来说，可以不考虑接收反馈的消息，只是按照重传次数和重传间隔进行重传即可，或者，在一些实施例中，可以在重传几次之后，对接收端反馈的消息进行分析，如果接收端反馈了ACK消息，则可以停止后续的重传步骤，如果接收端仍然反馈的是NACK消息，则继续进行重传，直至完成重传次数规定的次数为止。

本申请实施例提供的数据传输方法，发送端响应于接收端的数据发送请求，向接收端发送数据包，当数据包接收失败或者数据包发送错误时，接收端向发送端返回否定应答消息，发送端基于否定应答消息，根据接收端在当前时刻之前的预设时间段内的丢包参数，确定与接收端对应的重传次数和重传间隔，并按照重传次数和重传间隔，对数据包进行至少两次重传，以使得接收端接收到数据包。如此，能够极大的减小发送端与接收端之间丢包重传的耗时。

在一些实施例中，丢包参数包括接收端在预设时间段内的丢包率，根据丢包参数确定的重传参数除了重传次数之外，还包括重传间隔。图6A是本申请实施例提供的数据传输方法的一个可选的流程示意图，如图6A所示，步骤S506可以通过以下步骤实现：

步骤S601，获取丢包率与重传次数之间的第一映射关系列表。

这里，第一映射关系列表中存储有丢包率与重传次数之间的映射关系，当丢包率确定时，可以通过丢包率在第一映射关系列表中快速的查找出对应的重传次数。第一映射关系列表可以是预设的映射关系列表，本申请实施例对第一映射关系列表的形成方式不做限定。

丢包率是指接收端在预设时间段内的丢包数量与接收的总数据包数量之间的比值，总数据包数量既包括成功接收到的数据包的数量，还包括未成功接收到的数据包的数量，即总数据包数量是发送端向接收端发送的数据包的总量。

在一些实施例中，可以预先设定每一丢包率对应的重传次数，例如，当丢包率为90％时，重传次数可以是3次，当丢包率为80％时，重传次数可以是4次。丢包率与重传次数之间的映射关系可以根据实验测量得到，也可以是工程上的经验值。

步骤S602，在第一映射关系列表中，匹配出与丢包率对应的重传次数。

步骤S603，根据重传次数，确定重传间隔。

请继续参照图6A，在另一些实施例中，丢包参数包括接收端在预设时间段内的连续丢包数量，步骤S506还可以通过以下步骤实现：

步骤S604，获取连续丢包数量与重传次数之间的第二映射关系列表。

这里，第二映射关系列表中存储有连续丢包数量与重传次数之间的映射关系，当连续丢包数量确定时，可以通过连续丢包数量在第二映射关系列表中快速的查找出对应的重传次数。第二映射关系列表也可以是预设的映射关系列表，本申请实施例对第二映射关系列表的形成方式不做限定。

连续丢包数量是指发送端连续发送的数据包均没有被接收端接收到的数量。例如，发送端连续发送了4个数据包，其中，接收端成功接收到第一个数据包，但是后3个数据包均丢失，则连续丢包数据为3。

步骤S605，在第二映射关系列表中，匹配出与连续丢包数量对应的重传次数。在匹配出重传次数之后，继续执行步骤S603，根据重传次数，确定重传间隔。

请继续参照图6A，在一些实施例中，方法还包括：

步骤S606，接收端存储自身的丢包率和连续丢包数量。

在一些实施例中，为了保证数据包重传过程中能够快速有效的获取到数据包，可以在第一次发送数据包的同时，对数据包进行存储，以保证在后续对该数据包进行重传时，可以直接从存储位置获取到数据包。在另一些实施例中，接收端可以将丢包率和连续丢包数量存储至接收端所在的区块链系统中，以保证丢包率和连续丢包数量的安全和准确存储。

基于图6A，图6B是本申请实施例提供的数据传输方法的一个可选的流程示意图，如图6B所示，在一些实施例中，在确定出重传次数之后，步骤S603中根据重传次数确定重传间隔的步骤包括：

步骤S611，判断重传次数是否大于1。

当判断结果为是，则执行步骤S613；当判断结果为否是，表明重传次数等于1，则执行步骤S612。需要说明的是，本申请实施例中重传次数可以至少为1，因为当重传次数为0时，表明当前的网络状态非常好，不会出现丢包的情况，或者表明所获取的丢包参数表明接收端的丢包率为0，无需重传数据包。本申请实施例暂不考虑重传次数为0的情况，将在其他实施例中描述关于重传次数为0的情况。

步骤S612，当重传次数等于1时，确定一次重传的重传间隔为预设时长。

举例来说，如果重传次数等于1，则可以确定重传间隔为30ms。上述预设时长可以是固定值，也可以随着发送端与接收端之间的网络状态和数据包的大小进行调整。

步骤S613，当重传次数大于1时，确定每相邻两次重传之间的所述重传间隔为相等时长的重传间隔，或者按照时长递减的规则依次确定每相邻两次重传之间的所述重传间隔。

这里，当重传次数大于1时，多次重传的重传间隔可以相等也可以不相等。当相等时，能够实现等时间间隔的数据包重传；当不相等时，可以实现不等时间间隔的数据包重传。当需要不等时间间隔的数据包重传时，可以是按照时长递减的规则，每次重传的重传间隔小于上一次重传的重传间隔。这样，由于在前期的重传过程中，距离数据包的播放时刻较远，且可能存在接收端响应延迟的可能，因此，重传间隔较大，可以在保证重传成功的基础上，减小带宽消耗；而随着重传的进行，每重传一次，距离数据包的播放时刻越近，因此，依次减小重传间隔，能够加速重传进度，从而极大的保证了数据包重传成功的可能。

在其他实施例中，在步骤S611之前还可以包括一步判断步骤：判断重传次数是否等于0，如果等于0，则直接结束流程，无需重传数据包；如果不等于0，则表明重传次数大于或等于1，因此，执行步骤S611。

在其他实施例中，方法还包括以下步骤：步骤S614，在匹配得到重传次数的同时，在第一映射关系列表或第二映射关系列表中匹配出重传间隔。

本申请实施例中，第一映射关系列表和第二映射关系列表中还可以包括重传间隔，即，第一映射关系列表中存储有丢包率与重传次数和重传间隔之间的映射关系，第二映射关系列表中存储有连续丢包数量与重传次数和重传间隔之间的映射关系。当确定出丢包率之后，可以在第一映射关系列表中直接查询出对应的重传次数和重传间隔；当确定出连续丢包数量之后，可以在第二映射关系列表中直接查询出对应的重传次数和重传间隔。

在一些实施例中，步骤S506还可以通过以下步骤实现(图中未示出)：

步骤S61，确定接收端进行丢包重传、且重传成功时对应的至少两段历史时间段。

本申请实施例中，根据接收端在之前重传成功的参数来分析确定出本次丢包重传的参数。重传成功是指在历史时间段内进行丢包重传时，采用该历史时间段内的丢包重传次数和丢包重传间隔进行丢包重传之后，接收端成功的接收到了重传数据包。

步骤S62，获取每一历史时间段内的丢包重传次数和丢包重传间隔。

这里，可以获取大量的丢包重传次数和丢包重传间隔进行本次丢包重传的参数确定，以分析得到更加合适的重传次数和重传间隔。

需要说明的是，所获取的丢包重传次数和丢包重传间隔对应的网络状态相同或相近，即获取同一种网络状态下的丢包重传次数和丢包重传间隔。或者，所获取的丢包重传次数和丢包重传间隔对应的历史重传数据包与本次待重传的数据包相同，或者数据包大小相同，或者历史重传数据包的大小与本次待重传的数据包的大小之间的差值小于阈值。

步骤S63，分别确定接收端在至少两段历史时间段内对应的至少两个丢包重传次数的第一均值、和至少两个丢包重传间隔的第二均值。

这里，对获取到的至少两个丢包重传次数求均值，得到第一均值；对获取到的至少两个丢包重传间隔求均值，得到第二均值。

步骤S64，将第一均值确定为重传次数，将第二均值确定为重传间隔。

本申请实施例中，将至少两段历史时间段内对应的至少两个丢包重传次数的第一均值确定为重传次数，将至少两段历史时间段内对应的至少两个丢包重传间隔的第二均值确定为重传间隔，即采用历史丢包重传的大量数据，分析得到适用于本次丢包重传的参数，以历史丢包重传的参数为本次丢包重传提供依据，从而能够得到更加准确且有效的重传次数和重传间隔。

图7是本申请实施例提供的数据传输方法的一个可选的流程示意图，如图7所示，在执行步骤S503的同时，方法还包括：步骤S701，将数据包保存至发送端的缓存器中。对应地，步骤S507可以通过以下步骤实现：

步骤S702，发送端从缓存器中获取到数据包。

步骤S703，按照重传次数和重传间隔，对从缓存器中获取到的数据包进行重传，以使得接收端接收到数据包。

请继续参照图7，在一些实施例中，还可以采用循环缓存方式，对缓存器进行数据清理，可以通过以下步骤实现：

步骤S704，当缓存器中所保存的数据包的数量大于或等于阈值时，发送端按照缓存器保存每一数据包的时间先后顺序，依次删除预设数量的数据包。

在另一些实施例中，对缓存器进行数据清理，可以通过以下步骤实现：

步骤S705，发送端确定出当前时刻超过缓存器中所保存的每一数据包的播放时刻的时长。

这里，当当前时刻超过数据包的播放时刻时，确定当前时刻与数据包的播放时刻之间的时差，对应得到时长，该时长表征数据包超出播放时刻的时长。

步骤S706，当任一数据包的时长大于时长阈值时，发送端删除该时长对应的数据包。

在一些实施例中，还可定期或不定期的对缓存器中存储的数据包进行删除。

本申请实施例提供的数据传输方法，在初次传输数据包的时候，即将数据包存储于缓存器中，如此，在后续需要对数据包进行重传时，可以直接从缓存器中获取到该数据包，从而能够避免数据包的丢失和重传失效。并且，采用循环缓存方式，对于超时的数据包或超出存储容量的数据包及时进行删除，能够保证缓存器循环的对数据包进行存储，提高缓存器利用率。

图8是本申请实施例提供的数据传输方法的一个可选的流程示意图，如图8所示，方法还包括：

步骤S801，判断当前时刻是否到达数据包的播放时刻。

这里，数据包的播放时刻是指数据包在接收端被解析后播放的时刻，例如，当数据包是视频数据包时，数据包的播放时刻即该视频数据包的视频播放时刻。

如果判断结果为是，则执行步骤S802；如果判断结果为否，则执行步骤S507(需要说明的是，图8中示出了步骤S507包括步骤S805至步骤S810，因此，如果判断结果为否时，图8中示出的是执行步骤S805)。步骤S802，禁止对所述数据包进行重传。

请继续参照图8，在一些实施例中，方法还包括：

步骤S803，确定当前时刻与数据包的播放时刻之间的时间差。

步骤S804，判断时间差是否小于数据包的传输时延。

这里，数据包的传输时延可以是根据历史传输时延确定的时长，也可以是实验测量的时长，或者还可以是预测值。如果判断结果为是，则执行步骤S802；如果判断结果为否，则执行步骤S507(即执行图8中的步骤S805)。

请继续参照图8，在一些实施例中，步骤S507可以通过以下步骤实现：

步骤S805，判断当前重传次数是否达到上述重传次数。如果判断结果为是，则结束流程；如果判断结果为否，则执行步骤S806。

步骤S806，确定当前时刻与当前时刻之前的数据包传输时刻之间的时长。

这里，当前时刻之前的数据包传输时刻是指与当前时刻最近邻的前一次数据包传输时刻，该数据包传输时刻可以是数据包的首次传输时刻，也可以是数据包的重传时刻。举例来说，如果在当前时刻之前仅进行了一次数据包传输过程，则步骤S806所确定出的时长是数据包传输过程对应的时刻与当前时刻之间的时长；如果在当前时刻之前进行了一次数据包传输过程和一次数据包重传过程，则步骤S806所确定出的时长是数据包重传过程对应的时刻与当前时刻之间的时长。

步骤S807，判断时长是否达到重传间隔。

如果判断结果为是，则执行步骤S808；如果判断结果为否，则执行步骤S809。

步骤S808，对数据包进行一次重传，并将当前重传次数加一，并返回继续执行步骤S805。

步骤S809，判断是否接收到接收端返回的与数据包对应的确认应答消息。

如果判断结果为是，则执行步骤S810；如果判断结果为否，则在下一时刻返回继续执行步骤S807。

步骤S810，停止对数据包的重传。

本申请实施例提供的数据传输方法，依次判断当前时刻是否到达数据包的播放时刻、当前时刻与数据包的播放时刻之间的时间差是否小于数据包的传输时延、当前重传次数是否达到上述重传次数、和判断时长是否达到重传间隔，即基于当前时刻、数据包的播放时刻、数据包的传输时延、当前重传次数、重传次数和重传间隔等条件，对当前是否要继续重传数据包进行判断，从而实现整个流程的有序且准确的进行，保证了对数据包的有序重传，提高重传效率，且能够避免非必要的重传造成带宽浪费。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

本申请实施例提供一种数据传输方法，主要用于进行丢包重传，该方法解决了传统丢包重传方法重传效率低、耗时大且难以满足实时通话应用需求的问题。本申请实施例提出的数据传输方法，根据接收端丢包状况(即丢包参数)，对待重传的数据包进行自适应的多次及不定间距发送，进而可以提升重传效率，且降低重传失败后导致的多次反复重传过程的大量耗时问题。

本申请实施例的数据传输方法是一种丢包重传方法，可以解决传统丢包重传方法效率低的问题。图9A是本申请实施例提供的数据传输方法的一个可选的流程示意图，如图9A所示，对于发送端来说，方法包括以下步骤：

步骤S901，发送第i帧数据并缓存第i帧数据。

本申请实施例中，可以将发送的第i帧数据包同时保存到历史发送包的缓存器(buffer)中，实现缓存数据管理。缓存可采用循环缓冲方式，即可以缓存一定数量的数据包，但超出缓存器最大缓存容量大小，则会自动删除缓存器最早的数据包。

本申请实施例中，发送的每个数据包都要保存，在实际工程中还可以保存到环形缓冲区，环形缓冲区可以保存一定量的数据，超过环形缓冲区的保存数据量阈值的保存数据将被新数据包冲掉。

步骤S902，判断是否接收到NACK包。

如果判断结果为是，则执行步骤S902。

步骤S903，根据接收端丢包状态设置重传次数和重传间隔。

发送端发送第i帧数据后，如果收到接收端发送过来的第i帧的NACK包，说明接收端没有收到第i帧数据，这时发送端将根据接收端统计的丢包状态，例如，接收端丢包率等，将丢包状态作为重传决策依据，来决定第i帧的重传次数和重传间隔，如表1所示，是本申请实施例提供的一种丢包重传策略。

本申请实施例中，可以在一个统计周期内做一次接收端的丢包统计，例如一秒统计一次，根据一秒内收到的包数量进行丢包率的计算。

表1 丢包重传策略

丢包率(％)	[0，20)	[20，50)	[50，70)	[70，100)
					重发次数	1	2	3	4
重发间隔(ms)	40	30	20	20

步骤S904，对第i帧重传数据包进行发送队列管理及发送。

在确定出重传次数和重传间隔之后，发送端可以从历史发送缓存器里面获取第i帧数据并按照重传决策进行多次重传发送，确保了重传的有效性。

图9B是本申请实施例提供的数据传输方法的一个可选的流程示意图，如图9B所示，对于接收端来说，方法包括以下步骤：

步骤S911，对接收到的数据进行接收数据管理。

步骤S912，对接收端进行丢包状态检测，得到丢包率等丢包参数。

步骤S913，判断第i帧数据是否丢失。如果判断结果为是，则执行步骤S914。

步骤S914，向发送端发送NACK包。

本申请实施例中，根据接收端丢包状态设置重传次数和重传间隔，并按照重传次数和重传间隔对第i帧数据进行重传的方法是本申请实施例有别于传统重传方法的关键点，因为传统重传方法每次的重传数据包只有一个，在丢包严重的网络环境下极容易出现重传数据包继续丢失的情况，导致第i帧丢包重传失效，进而触发下一轮的第i帧丢包重传。而当几轮丢包重传后，接收端即使接收到第i帧数据包但可能已经错过了接收端播放第i帧的最后时间，而使得第i帧仍然失效。

传统丢包重传的效率低，而本申请实施例的方法是根据实际网络状况控制待重传的第i帧数据包的重传次数和重传间隔，例如重传次数为2，重传间隔是20ms，则第i帧将在当前时刻发送一次以及当前时刻后的20ms后，继续重传第i帧。本申请实施例根据网络丢包状态预测重传帧丢失的概率，从而采取主动多次重传的方式，较好地避免了丢包重传数据包丢失的可能，而且这种方式可以减少传统丢包重传方法的耗时。

下面继续说明本申请实施例提供的数据传输装置354实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器350的数据传输装置354中的软件模块可以是服务器300中的数据传输装置，包括：

第一发送模块3541，用于向接收端发送数据包；第一获取模块3542，用于当接收到所述接收端返回的与所述数据包对应的否定应答消息时，获取所述接收端在当前时刻之前的预设时间段内的丢包参数；确定模块3543，用于根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔；重传模块3544，用于按照所述重传次数和重传间隔，对所述数据包进行至少两次重传。

在一些实施例中，所述丢包参数包括所述接收端在所述预设时间段内的丢包率；所述确定模块还用于：获取所述丢包率与重传次数之间的第一映射关系列表；在所述第一映射关系列表中，匹配出与所述丢包率对应的所述重传次数；根据所述重传次数，确定所述重传间隔。

在一些实施例中，所述丢包参数包括所述接收端在所述预设时间段内的连续丢包数量；所述确定模块还用于：获取所述连续丢包数量与重传次数之间的第二映射关系列表；在所述第二映射关系列表中，匹配出与所述连续丢包数量对应的所述重传次数；根据所述重传次数，确定所述重传间隔。

在一些实施例中，所述确定模块还用于：确定所述接收端进行丢包重传、且重传成功时对应的至少两段历史时间段；获取每一所述历史时间段内的丢包重传次数和丢包重传间隔；分别确定所述接收端在所述至少两段历史时间段内对应的至少两个所述丢包重传次数的第一均值、和至少两个所述丢包重传间隔的第二均值；将所述第一均值确定为所述重传次数，将所述第二均值确定为所述重传间隔。

在一些实施例中，所述确定模块还用于：当所述重传次数等于1时，确定一次重传的重传间隔为预设时长；或者，当所述重传次数大于1时，确定每相邻两次重传之间的重传间隔为相等时长的重传间隔，或者按照时长递减的规则依次确定每相邻两次重传之间的所述重传间隔；或者，在匹配得到所述重传次数的同时，在所述第一映射关系列表或所述第二映射关系列表中匹配出所述重传间隔。

在一些实施例中，所述重传模块还用于：在对所述数据包连续重传预设次数之后，当当前重传次数未达到所述重传次数，且当前时刻与当前时刻之前的数据包传输时刻之间的时长未达到所述重传间隔时，确定是否接收到所述接收端返回的与所述数据包对应的确认应答消息；当接收到所述确认应答消息时，停止对所述数据包的重传。

在一些实施例中，所述装置还包括：保存模块，用于在向所述接收端发送所述数据包的同时，将所述数据包保存至所述发送端的缓存器中；对应地，所述重传模块还用于：按照所述重传次数，对从所述缓存器中获取到的所述数据包进行重传，以使得所述接收端接收到所述数据包。

在一些实施例中，所述装置还包括：删除模块，用于当所述缓存器中所保存的数据包的数量大于或等于阈值时，按照所述缓存器保存每一数据包的时间先后顺序，依次删除预设数量的数据包；或者，确定当前时刻超过所述缓存器中所保存的每一数据包的播放时刻的时长，且当任一数据包的所述时长大于时长阈值时，删除所述时长对应的数据包。

在一些实施例中，所述装置还包括：禁止模块，用于当当前时刻到达所述数据包的播放时刻时，禁止对所述数据包进行重传；或者，当当前时刻与所述数据包的播放时刻之间的时间差小于所述数据包的传输时延时，禁止对所述数据包进行重传。

本申请实施例再提供一种数据传输装置，本申请实施例提供的数据传输装置可以实施为软件模块，在一些实施例中，该数据传输装置也可以存储在存储器350的数据传输装置354中，可以是服务器300中的数据传输装置，包括：第一接收模块，用于接收发送端发送的数据包；第二获取模块，用于当所述数据包接收失败或者所述数据包发送错误时，获取接收端在当前时刻之前的预设时间段内的丢包参数；第二发送模块，用于向所述发送端发送所述丢包参数和与所述数据包对应的否定应答消息，以使得所述发送端根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，并按照所述重传次数和重传间隔，对所述数据包进行至少两次重传；第二接收模块，用于接收所述发送端重传的所述数据包。

在一些实施例中，所述丢包参数包括所述接收端在所述预设时间段内的丢包率、和所述接收端在所述预设时间段内的连续丢包数量；所述装置还包括：存储模块，用于将所述丢包率和所述连续丢包数量存储至所述接收端所在的区块链系统中。

需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图4示出的方法。

在一些实施例中，存储介质可以是计算机可读存储介质，例如，铁电存储器(FRAM，Ferromagnetic Random Access Memory)、只读存储器(ROM，R ead Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read Only Memory)、带电可擦可编程只读存储器(EEPROM，Electrically Erasable Programmable Read Only Memory)、闪存、磁表面存储器、光盘、或光盘只读存储器(CD-ROM，Compact Disk-Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(H TML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (15)

1.一种数据传输方法，其特征在于，包括：

向接收端发送数据包；

当接收到所述接收端返回的与所述数据包对应的否定应答消息时，获取所述接收端在当前时刻之前的预设时间段内的丢包参数；

根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔；

按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传。

2.根据权利要求1所述的方法，其特征在于，所述丢包参数包括所述接收端在所述预设时间段内的丢包率；

所述根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，包括：

获取所述丢包率与重传次数之间的第一映射关系列表；

在所述第一映射关系列表中，匹配出与所述丢包率对应的所述重传次数；

根据所述重传次数，确定所述重传间隔。

3.根据权利要求1所述的方法，其特征在于，所述丢包参数包括所述接收端在所述预设时间段内的连续丢包数量；

所述根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，包括：

获取所述连续丢包数量与重传次数之间的第二映射关系列表；

在所述第二映射关系列表中，匹配出与所述连续丢包数量对应的所述重传次数；

根据所述重传次数，确定所述重传间隔。

4.根据权利要求1所述的方法，其特征在于，所述根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，包括：

确定所述接收端进行丢包重传、且重传成功时对应的至少两段历史时间段；

获取每一所述历史时间段内的丢包重传次数和丢包重传间隔；

分别确定所述接收端的至少两个所述丢包重传次数的第一均值、和至少两个所述丢包重传间隔的第二均值；

将所述第一均值确定为所述重传次数，将所述第二均值确定为所述重传间隔。

5.根据权利要求2或3所述的方法，其特征在于，所述根据所述重传次数，确定所述重传间隔，包括：

当所述重传次数等于1时，确定一次重传的重传间隔为预设时长；或者，

当所述重传次数大于1时，确定每相邻两次重传之间的重传间隔为相等时长的重传间隔，或者按照时长递减的规则依次确定每相邻两次重传之间的所述重传间隔；或者，

在匹配得到所述重传次数的同时，在所述第一映射关系列表或所述第二映射关系列表中匹配出所述重传间隔。

6.根据权利要求1所述的方法，其特征在于，所述按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传，包括：

在对所述数据包连续重传预设次数之后，当当前重传次数未达到所述重传次数，且当前时刻与当前时刻之前的数据包传输时刻之间的时长未达到所述重传间隔时，确定是否接收到所述接收端返回的与所述数据包对应的确认应答消息；

当接收到所述确认应答消息时，停止对所述数据包的重传。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：在向所述接收端发送所述数据包的同时，将所述数据包保存至所述发送端的缓存器中；

对应地，所述按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传，包括：

按照所述重传次数和所述重传间隔，对从所述缓存器中获取到的所述数据包进行重传，以使得所述接收端接收到所述数据包。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

当所述缓存器中所保存的数据包的数量大于或等于阈值时，按照所述缓存器保存每一数据包的时间先后顺序，依次删除预设数量的数据包；

或者，

确定当前时刻超过所述缓存器中所保存的每一数据包的播放时刻的时长，且当任一数据包的所述时长大于时长阈值时，删除所述时长对应的数据包。

9.根据权利要求1至8任一项所述的方法，其特征在于，所述方法还包括：

当当前时刻到达所述数据包的播放时刻时，禁止对所述数据包进行重传；

或者，

当当前时刻与所述数据包的播放时刻之间的时间差小于所述数据包的传输时延时，禁止对所述数据包进行重传。

10.一种数据传输方法，其特征在于，包括：

接收发送端发送的数据包；

当所述数据包接收失败或者所述数据包发送错误时，获取接收端在当前时刻之前的预设时间段内的丢包参数；

向所述发送端发送所述丢包参数和与所述数据包对应的否定应答消息，以使得所述发送端根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，并按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传；

接收所述发送端重传的所述数据包。

11.根据权利要求10所述的方法，其特征在于，所述丢包参数包括所述接收端在所述预设时间段内的丢包率、和所述接收端在所述预设时间段内的连续丢包数量；

所述方法还包括：将所述丢包率和所述连续丢包数量存储至所述接收端所在的区块链系统中。

12.一种数据传输装置，其特征在于，包括：

第一发送模块，用于向接收端发送数据包；

第一获取模块，用于当接收到所述接收端返回的与所述数据包对应的否定应答消息时，获取所述接收端在当前时刻之前的预设时间段内的丢包参数；

确定模块，用于根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔；

重传模块，用于按照所述重传次数和所述重传间隔，对所述数据包进行至少两次重传。

13.一种数据传输装置，其特征在于，包括：

第一接收模块，用于接收发送端发送的数据包；

第二获取模块，用于当所述数据包接收失败或者所述数据包发送错误时，获取接收端在当前时刻之前的预设时间段内的丢包参数；

第二发送模块，用于向所述发送端发送所述丢包参数和与所述数据包对应的否定应答消息，以使得所述发送端根据所述丢包参数，确定与所述接收端对应的重传次数和重传间隔，并按照所述重传次数和重传间隔，对所述数据包进行至少两次重传；

第二接收模块，用于接收所述发送端重传的所述数据包。

14.一种数据传输设备，其特征在于，包括：

存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至9任一项，或者，权利要求10或11所述的方法。

15.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至9任一项，或者，权利要求10或11所述的方法。

Images