数据传输方法及装置与流程

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

背景技术：

近年来，随着互联网技术的发展，移动终端普及率的提高，越来越多的用户通过在移动终端上浏览网页、观看视频、从事社交活动等丰富自己的生活。在移动终端的使用场景下，为了获得更好的体验效果，用户希望移动网络上的数据响应时间越短越好。由于移动网络上的数据响应时间主要取决于数据在移动网络上的传输方式，因此，如何进行数据传输，则成为了互联网领域的热点问题。

目前，现有技术在进行数据传输时，主要采用如下两种方式：

第一种方式：基于SPDY(发音同speedy)协议，当接收到移动终端发送的数据获取请求时，获取相应的数据，并通过优先级、多路复用、压缩及主动推动等技术，将数据传输给移动终端。

第二种方式：基于Zeta-TCP(Transmission Control Protocol，传输控制协议)，当接收到移动终端发送的数据获取请求时，获取相应的数据，并通过对当前传输链路的网络特性的学习，确定数据传输策略，进而按照确定的数据传输策略传输数据。

在实现本发明的过程中，发明人发现相关技术至少存在以下问题：

由于第一种方式需要移动终端和服务器同时支持SPDY协议，很难做到无缝升级，应用性较差；且SPDY协议主要应用于大数据的传输，而在小数据的传输场景下，加速效果并不理想。

由于第二种方式主要通过对当前网络特性的自适应学习来调整数据传输策略的，在小数据的传输场景下，Zeta-TCP协议还未学习到足够的网络特性，传输链路就已经断开，导致加速效果并不理想。

技术实现要素：

为了解决相关技术的问题，本发明实施例提供了一种数据传输方法及装置。所述技术方案如下：

一方面，提供了一种数据传输方法，所述方法包括：

获取当前时刻传输链路上的交互数据；

对交互数据进行分析，得到所述交互数据的数据属性信息；

根据所述交互数据的数据属性信息及所述传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽；

根据所述可用带宽向数据接收端传输数据包。

另一方面，提供了一种数据传输装置，所述装置包括：

获取模块，用于获取当前时刻传输链路上的交互数据；

分析模块，用于对交互数据进行分析，得到所述交互数据的数据属性信息；

第一确定模块，用于根据所述交互数据的数据属性信息及所述传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽；

第一传输模块，用于根据所述可用带宽向数据接收端传输数据包。

本发明实施例提供的技术方案带来的有益效果是：

根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽，进而根据可用带宽向数据接收端传输数据包。由于基于TCP协议进行数据传输，无论数据接收端还是数据发送端均无需支持额外的协议，应用性较强，且在确定可用带宽时综合考虑了传输链路上的交互数据及历史交互数据，使得确定的带宽更能体现当前的网络状况，显著地 提高了数据传输速率。

附图说明

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

图1是本发明一个实施例提供的TCPA的系统架构图；

图2是本发明另一个实施例提供的TCPA的逻辑架构图；

图3是本发明另一个实施例提供的一种数据传输方法流程图；

图4是本发明另一个实施例提供的一种数据传输方法流程图；

图5是本发明另一个实施例提供的一种对数据传输过程中的带宽进行控制的过程示意图；

图6是本发明另一个实施例提供的一种对数据传输过程中的拥塞进行控制的过程示意图；

图7是本发明另一个实施例提供的一种在数据传输过程中进行丢包探测的过程示意图；

图8是本发明另一个实施例提供的一种数据传输装置的结构示意图；

图9是本发明另一个实施例提供的一种数据传输装置的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

随着互联网技术的发展，图片分享作为互联网时代的高频使用场景，无论是国外的图片分享网站，还是国内的社交应用，用户的活跃度均非常高。当用户在浏览其他用户分享的图片过程中想要收藏某些图片时，用户需要借助移动 终端将这些图片从服务器上下载下来。在此过程中就涉及到数据在传输链路上的传输问题。由于图片数据较小，相应地，图片数据的传输场景也往往比较简单，目前每条传输链路上可同步传输1～3张大小在几百KB以内的图片。然而，由于移动网络相对于有线网络更为复杂，图片数据在传输过程中受到多方面因素影响，导致传输速率较低，图片数据的下载时间较长。

目前，移动终端下载图片数据耗时较长的原因主要有两方面，一方面是当前网络的RTT(Round-Trip Time，往返时延)较大，另一方面是部署在服务器端的TCP协议栈检测到网络拥塞后，主动降低数据传输量。其中，当前网络的RTT主要取决于传输介质、传输距离以及传输路径中每个节点的处理逻辑等因素，这些因素属于网络的基本性质，本实施例暂不关注。

针对于TCP协议栈导致的传输速率低的问题，传统的TCP协议栈主要通过滑动窗口控制数据传输速率，而滑动窗口主要受到数据接收端的接收窗口及拥塞控制窗口的限制。其中，数据接收端的接收窗口由数据接收端的数据接收能力决定，拥塞控制窗口主要由TCP协议栈的拥塞控制算法确定。目前，TCP协议栈的拥塞控制算法较多，这些拥塞控制算法主要基于丢包、或者延时波动来探测网络拥堵情况。TCP协议栈在有线网络的长连接传输场景下对数据传输过程的控制效果比较显著，但是在移动网络的短连接场景下，TCP协议栈对数据传输过程的控制效果并不显著，移动网络的高丢包率及不稳定的RTT，会使得TCP协议栈产生误判，在正常的移动网络环境中，TCP协议栈也会主动降低数据包的发送量，而这会导致数据在移动网络中的传输速率较低，移动终端下载图片的时间较长。

为了提高数据传输速率，本发明实施例提供了一种数据传输方法，该方法以图1所示的TCPA系统架构图为基础。如图1所示，TCPA系统由两部分组成，一部分为部署在内核态，主要由发送控制中心组成，该部分主要负责数据的具体传输。另一部分为部署在用户态，主要由连接特性分析模块、策略决策中心及历史数据仓库组成，该部分主要对数据发送策略进行决策，通过该部分决策 得到的决策结果可通过策略决策中心下发到内核态的发送控制中心，发送控制中心根据该决策结果对数据的传输过程进行控制。需要说明的是，图中的黑色箭头表示应用数据流的流向，图中的白色箭头表示决策数据流的流向。

基于上述图1中的系统架构图，图2为TCPA的逻辑架构图，当服务器与移动终端建立连接之后，服务器监控与移动终端之间进行交互的交互数据，通过调用链路特性分析模块对每条传输链路上的交互数据进行分析，进而将分析结果发送至策略决策中心，由策略决策中心根据分析结果及从历史数据仓库中获取到的历史交互数据进行决策，根据决策结果确定出一套数据传输策略，该数据传输策略直接影响到服务器的带宽控制、拥塞控制、丢包检测及重传控制。当服务器采用该数据传输策略进行数据传输时，可达到提高数据传输速率，减小数据下载时间的目的。

本发明实施例提供一种数据传输方法，参见图3，本实施例提供的方法流程包括：

301、获取当前时刻传输链路上的交互数据。

302、对交互数据进行分析，得到交互数据的数据属性信息。

303、根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽。

304、根据可用带宽向数据接收端传输数据包。

本发明实施例提供的方法，根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽，进而根据可用带宽向数据接收端传输数据包。由于基于TCP协议进行数据传输，无论数据接收端还是数据发送端均无需支持额外的协议，应用性较强，且在确定可用带宽时综合考虑了传输链路上的交互数据及历史交互数据，使得确定的带宽更能体现当前的网络状况，显著地提高了数据传输速率。

在本发明的另一个实施例中，数据属性信息包括时延信息，时延信息包括 往返时延RTT及RTT波动率；

根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽，包括：

根据交互数据的RTT波动率及历史交互数据的RTT波动率，从交互数据的RTT及历史交互数据的RTT中，选取出目标RTT；

根据目标RTT及目标RTT对应的数据传输量，确定本次传输数据的可用带宽。

在本发明的另一个实施例中，数据属性信息还包括丢包信息；

根据可用带宽向数据接收端传输数据包之后，还包括：

根据交互数据的丢包信息及历史交互数据的丢包信息，确定当前网络的拥堵状况；

根据拥堵状况，调整可用带宽；

在下一次向数据接收端传输数据包时，按照调整后的可用带宽进行传输。

在本发明的另一个实施例中，根据可用带宽向数据接收端传输数据包之后，还包括：

当检测到未传输数据包的时长达到预设时长，且已传输的数据包中存在未返回响应报文的数据包时，向数据接收端发送丢包探测报文；

当接收到响应报文，根据响应报文，从已传输的数据包中确定丢失的数据包，响应报文由数据接收端在接收到丢包探测报文时返回；

重新传输丢失的数据包。

在本发明的另一个实施例中，根据可用带宽向数据接收端传输数据包之后，还包括：

根据交互数据的丢包信息及传输链路上的历史交互数据的丢包信息，确定重传时机及待重传的数据包；

当达到重传时机时，重新传输待重传的数据包。

上述所有可选技术方案，可以采用任意结合形成本发明的可选实施例，在 此不再一一赘述。

本发明实施例提供了一种数据传输方法，该方法适用于移动终端通过移动网络下载图片数据的场景，在该种场景下，当前网络即为移动网络。参见图4，本实施例提供的方法流程包括：

401、服务器与数据接收端建立连接状态。

其中，数据接收端为进行图片数据下载的移动终端，如智能手机、平板电脑等。在互联网技术领域，为了能够进行数据传输，服务器与数据接收端在进行数据传输之前，通常会进行三次握手。

数据接收端与服务器第一次握手：数据接收端会向服务器发送SYN(Synchronize Sequence Numbers，同步序列标号)包，并进入SYN_SENT状态，等待服务器确认。

数据接收端与服务器第二次握手：当接收到数据接收端发送的SYN包时，服务器通过向数据接收端发送ACK(Acknowledgement，确认字符)包对接收到的SYN包进行确认，同时服务器也会向数据接收端发送一个SYN包，服务器进入SYN_RECV状态。

数据接收端与服务器第三次握手：数据接收端接收到服务器发送的SYN-ACK包时，并向服务器返回一个ACK包，此后，数据接收端和服务器即进入连接状态。

在上述三次握手完成后，服务器和数据接收端即可建立连接。

402、服务器获取当前时刻传输链路上的交互数据。

基于建立的连接，服务器可对传输链路上的每一次数据交互过程进行监控，直至建立的连接断开。在过程中，当服务器监控到当前时刻传输链路上有交互数据时，服务器将获取该交互数据。其中，交互数据包括TCP报文的编号、flag(用于记载变量的一个参数)、时间戳、TCP负载大小等数据，本实施例不对交互数据的内容作具体的限定。

403、服务器对交互数据进行分析，得到交互数据的数据属性信息。

当获取到交互数据之后，服务器将调用链路特征分析模块对获取到交互数据进行分析，通过分析可得到传输链路上交互数据的数据属性信息。在本实施例中，交互数据的数据属性信息包括时延信息、丢包信息、重传信息等，其中，时延信息至少包括当前链路的RTT、RTT波动率等，丢包信息至少包括丢包率、丢包位置等，重传信息至少包括重传时延、重传大小、重复ACK包等。

针对数据属性信息的不同，下面将对分别进行介绍。

(1)、时延信息。

当服务器向数据接收端传输数据时，服务器通常会在传输数据包中添加一个时间戳信息，数据接收端接收到服务器发送的数据包后，会向服务器返回一个响应报文，该响应报文中携带一个时间戳信息。当接收到数据接收端返回的响应报文，基于发送的数据包中携带的时间戳信息及响应报文中的时间戳信息，服务器可即计算出数据包从发送到接收之间的时间差，该时间差即为RTT。由于移动网络并不稳定，当将同一数据包在同一链路上传输时，每次计算出的RTT可能是不同的，服务器通过对多次传输过程中的RTT进行分析，即可得到RTT波动率。

(2)、丢包信息。

为了便于对待传输的数据进行管理，服务器向数据接收端传输数据时，通常会将待发送的数据包进行编号，进而在后续进行数据传输时，按照编号由小到大的顺序对待发送的数据包进行传输，如果数据接收端接收到服务器发送的数据，数据接收端会向服务器返回一个响应报文，该响应报文用于通知服务器发送的数据包中被确认的数据包编号，服务器根据发送数据包的编号及被确认的数据包编号，即可确定出传输过程中丢失的数据包以及丢失的数据包在发送的数据包中的位置，该位置即为丢包位置。

(3)、重传信息。

为了保证接收端接收到的数据完整，当服务器检测到某一数据包在传输过 程中丢失后，服务器会将该丢失的数据包重新传输给数据接收端，依据重传的数据包的数量，服务器可确定出重传大小，依据初次传输的数据包中携带的时间戳信息及重传数据包中携带的时间戳信息，服务器可确定出重传时延。另外，在该过程中，如果某一数据包丢失，位于该数据之前的数据包及位于该数据包之后的数据包均会向服务器发送一个ACK包，基于接收到的ACK包，服务器即可确定出重复ACK包。

另外，服务器在调用链路分析模块对当前时刻传输链路上的交互数据进行分析之后，服务器还将以IP为维度，将获取到的交互数据写回历史数据仓库，从而为后续数据传输提供数据支撑。

404、服务器根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽。

由于传统的TCP协议栈主要通过滑动窗口机制控制数据发送端的可用带宽，而滑动窗口主要受拥塞窗口及数据接收端的接收窗口限制。且在服务器与数据接收端的连接建立之初，TCP协议栈是无法检测到当前网络的拥塞状况，此时滑动窗口主要受限于服务器设置的初始窗口和数据接收端的接收窗口。又由于移动网络的网络环境相对于有线网络的网络环境要复杂的多，而不同数据接收端所处的网络环境相差巨大，这使得设置的初始窗口在不同的网络环境下并不适用，此时根据初始窗口和数据接收端的接收窗口所确定的滑动窗口并不能准确的反映出当前的网络状况，进而确定的可用带宽并不准确。

为了提高所确定的可用带宽的准确性，服务器在对当前传输链路上的交互数据进行分析，得出交互数据的数据属性信息之后，服务器还将从历史数据仓库中获取该条传输链路上当前时刻的历史交互数据，进而采用与对当前获取到的交互数据相同方式对历史交互数据进行分析，得到传输链路上的历史交互数据的数据属性信息。之后，服务器通过调用数据链路分析模块对交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息进行离线分析，可得出本次传输数据的可用带宽。

在本步骤中，服务器在确定本次传输数据的可用带宽时，主要依据数据属性信息中的时延信息进行确定的。具体确定时，服务器先根据交互数据的RTT波动率及历史交互数据的RTT波动率，从交互数据的RTT及历史交互数据的RTT中，选取出目标RTT，然后根据目标RTT及目标RTT对应的数据传输量，确定本次传输数据的可用带宽。

对于上述过程为了便于理解，下面将一个具体的例子进行说明。

例如，服务器通过对当前时刻传输链路进行监控，获取到交互数据的RTT为20ms(毫秒)，从历史数据仓库中获取到该传输链路上最近三天的历史交互数据的RTT分别为18ms、16ms、21ms，通过对获取到的交互数据及历史交互数据的RTT进行分析可知，该条传输链路上的RTT是波动的。为了避免传输过程中数据包丢失，使得数据接收端接收到的数据完整，服务器可依据交互数据及历史交互数据的RTT波动率，从中选取一个最小的RTT作为目标RTT，进而通过将该RTT与该RTT对应的数据传输量相乘，得到一个带宽，该带宽即为本次传输数据的可用带宽。

405、服务器根据可用带宽向数据接收端传输数据包。

基于确定的可用带宽，服务器即可按照所确定的可用带宽向数据接收端传输数据包。在网络环境较好的情况下，服务器采用所确定的可用带宽传输数据包时，可将一张10KB的小图片一次性的传输至数据接收端，避免了受TCP协议栈滑动窗口的限制，提高了数据的传输速率。

为了直观地展示采用本实施例提供的方法在传输数据时的优越性，下面以图5为例进行说明。

参见图5，在网络状况较好时，如果采用原有的TCP协议栈的可用带宽进行数据传输，在一次数据传输过程中仅能传输三个数据包，而采用本实施所确定的可用带宽进行数据传输时，在一次传输过程中可发送四个数据包。由于一次发送的数据包的数量增多了，因此，提高了数据的传输速率。

至此，通过上述过程实现了数据的发送，在此基础上，本实施例提供的方 法还支持对确定的可用带宽进行调整、对发送的数据包进行丢包检测以及对丢失的数据包进行重传等。具体参见下述内容。

由于网络中的存储转发节点的数量有限，当网络中传输的数据包较多时，将导致网络能力下降，如果采用传统的数据传输方法，服务器根据TCP协议栈会通过拥塞控制算法如cubic、bic等，判断出当前网络拥塞后，服务器会主动减少可用带宽，以缓解当前网络的拥塞程度。然而在实际应用中，乱序引起的重复ACK以及网络信号减弱或者切换造成的丢包，并不能作为网络拥堵的特征，而服务器借助传统的TCP协议栈分析后，确定此时网络拥堵，将降低可用带宽，使得数据传输速率较低。为了避免传输带宽被无谓的降低，本实施例中服务器还将根据数据属性信息中的丢包信息对当前网络的拥堵状况进行分析，以根据分析结果重新调整传输带宽。该过程在具体实施时，服务器可根据交互数据的丢包信息及历史交互数据的丢包信息，确定出传输链路在同一时段的历史丢包情况及当前的丢包位置及丢包率等因素，并根据这些因素确定出当前网络的拥堵状况，进而根据所确定的拥堵状况，调整可用带宽，从而在下一次向数据接收端传输数据包时，按照调整后的可用带宽进行传输。

为了直观地展示采用本实施例提供的方法在传输数据时的优越性，下面以图6为例进行说明。

参见图6，在网络状况较好时，采用传统方法所确定的滑动窗口一次仅能传输三个数据包，而根据本发明实施例提供的方法调整的滑动窗口一次可发送四个数据包。由于一次发送的数据包的数量增多了，因此，提高了数据的传输速率。

在互联网领域，为了保证数据接收端接收到的数据完整，服务器在向数据接收端传输数据包之后，还将对传输的数据包进行丢包检测。丢包检测主要用于传输的数据包中尾部丢包的检测，以在发现尾部数据包丢失后，及时重传，降低数据下载时间，提高用户的体验效果。

参见图7中的左图，当服务器向数据接收端传输1、2、3、4、5、6六个数 据包之后，传统的丢包检测方法检测到数据包4、5、6丢失之后，需要经过一个RTO(Recovery Time Object，恢复时间目标)时间才启动重传机制重新传输丢失的数据包，该过程时间较长。在移动终端下载图片的场景下，10KB以内的占比非常高，同一传输链路中，图片下载同步进行，使得尾部丢包发生的概率将大大提升，如果采用图7中左图中方法检测丢包时，下载一个10KB以内的图片，用户可能也将等待几秒钟的时间，用户体验效果较差。

为了提高数据传输速率，改善用户体验，本实施例提供的方法在根据可用带宽向数据接收端传输数据之后，还将检测传输链路上未传输数据包的时长是否达到预设时长，当检测到未传输数据包的时长达到预设时长，且已传输的数据包中存在未返回响应报文的数据包时，服务器将向数据接收端发送丢包探测报文，数据接收端接收到丢包探测报文时，根据本次数据的接收情况，生成一个响应报文，该响应报文用于指示本次传输的数据包在数据接收端的接收情况，并将生成的相应报文发送给服务器。当接收到响应报文，服务器根据响应报文，可从已传输的数据包中确定丢失的数据包，进而及时地将丢失的数据包传输给数据接收端。其中，预设时长可以为3ms、5ms、7ms等，本实施例不对预设时长作具体的限定。

参见图7中的右图，当服务器向数据接收端传输1、2、3、4、5、6六个数据包之后，服务器检测到为传输数据包的时长达到预设时长，且未接收到数据包4、5、6返回的ACK包时，服务器将向数据接收端发送一个丢包探测报文，数据接收端接收到丢包探测报文之后，向服务器返回一个响应报文，该响应报文用于通知服务器数据包4、5、6丢失，当接收到响应报文时，服务器将数据包4、5、6重新传输给数据接收端。

上述过程为服务器自主检测数据包丢失后重新将丢失的数据包传输给数据接收端的过程。当然，为了提高数据传输速率，减少等待时间，服务器还可调用策略决策中心，对交互数据的丢包信息及传输链路上的历史交互数据的丢包信息进行分析，通过分析获取到数据包中丢包频繁的位置、重复ACK的位置及 数量，并根据数据包中丢包频繁的位置、重复ACK的位置及数量，确定出重传时机及待重传的数据包，进而在达到重传时机时，将待重传的数据包重新传输给数据接收端。

本发明实施例提供的方法，根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽，进而根据可用带宽向数据接收端传输数据包。由于基于TCP协议进行数据传输，无论数据接收端还是数据发送端均无需支持额外的协议，应用性较强，且在确定可用带宽时综合考虑了传输链路上的交互数据及历史交互数据，使得确定的带宽更能体现当前的网络状况，显著地提高了数据传输速率。

参见图8，本发明实施例提供了一种数据传输装置，该装置包括：

获取模块801，用于获取当前时刻传输链路上的交互数据；

分析模块802，用于对交互数据进行分析，得到交互数据的数据属性信息；

第一确定模块803，用于根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽；

第一传输模块804，用于根据可用带宽向数据接收端传输数据包。

在本发明的另一个实施例中，数据属性信息包括时延信息，时延信息包括往返时延RTT及RTT波动率；

第一确定模块803，用于根据交互数据的RTT波动率及历史交互数据的RTT波动率，从交互数据的RTT及历史交互数据的RTT中，选取出目标RTT；根据目标RTT及目标RTT对应的数据传输量，确定本次传输数据的可用带宽。

在本发明的另一个实施例中，数据属性信息还包括丢包信息；

该装置还包括：

第二确定模块，用于根据交互数据的丢包信息及历史交互数据的丢包信息，确定当前网络的拥堵状况；

调整模块，用于根据拥堵状况，调整可用带宽；

第二传输模块，用于在下一次向数据接收端传输数据包时，按照调整后的可用带宽进行传输。

在本发明的另一个实施例中，该装置还包括：

发送模块，用于当检测到未传输数据包的时长达到预设时长，且已传输的数据包中存在未返回响应报文的数据包时，向数据接收端发送丢包探测报文；

第三确定模块，用于当接收到响应报文，根据响应报文，从已传输的数据包中确定丢失的数据包，响应报文由数据接收端在接收到丢包探测报文时返回；

第三传输模块，用于重新传输丢失的数据包。

在本发明的另一个实施例中，该装置还包括：

第四确定模块，用于根据交互数据的丢包信息及传输链路上的历史交互数据的丢包信息，确定重传时机及待重传的数据包；

第四传输模块，用于当达到重传时机时，重新传输待重传的数据包。

综上所述，本发明实施例提供的装置，根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽，进而根据可用带宽向数据接收端传输数据包。由于基于TCP协议进行数据传输，无论数据接收端还是数据发送端均无需支持额外的协议，应用性较强，且在确定可用带宽时综合考虑了传输链路上的交互数据及历史交互数据，使得确定的带宽更能体现当前的网络状况，显著地提高了数据传输速率。

图9是根据一示例性实施例示出的一种用于数据传输的装置。参照图9，该装置可以为服务器900，服务器900包括处理组件922，其进一步包括一个或多个处理器，以及由存储器932所代表的存储器资源，用于存储可由处理组件922的执行的指令，例如应用程序。存储器932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件922被配置为执行指令，以执行上述数据传输方法中服务器所执行的功能，该方法包括：

获取当前时刻传输链路上的交互数据；

对交互数据进行分析，得到交互数据的数据属性信息；

根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽；

根据可用带宽向数据接收端传输数据包。

在本发明的另一个实施例中，数据属性信息包括时延信息，时延信息包括往返时延RTT及RTT波动率；

根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽，包括：

根据交互数据的RTT波动率及历史交互数据的RTT波动率，从交互数据的RTT及历史交互数据的RTT中，选取出目标RTT；

根据目标RTT及目标RTT对应的数据传输量，确定本次传输数据的可用带宽。

在本发明的另一个实施例中，数据属性信息还包括丢包信息；

根据可用带宽向数据接收端传输数据包之后，还包括：

根据交互数据的丢包信息及历史交互数据的丢包信息，确定当前网络的拥堵状况；

根据拥堵状况，调整可用带宽；

在下一次向数据接收端传输数据包时，按照调整后的可用带宽进行传输。

在本发明的另一个实施例中，根据可用带宽向数据接收端传输数据包之后，还包括：

当检测到未传输数据包的时长达到预设时长，且已传输的数据包中存在未返回响应报文的数据包时，向数据接收端发送丢包探测报文；

当接收到响应报文，根据响应报文，从已传输的数据包中确定丢失的数据包，响应报文由数据接收端在接收到丢包探测报文时返回；

重新传输丢失的数据包。

在本发明的另一个实施例中，根据可用带宽向数据接收端传输数据包之后， 还包括：

根据交互数据的丢包信息及传输链路上的历史交互数据的丢包信息，确定重传时机及待重传的数据包；

当达到重传时机时，重新传输待重传的数据包。

服务器900还可以包括一个电源组件926被配置为执行服务器900的电源管理，一个有线或无线网络接口950被配置为将服务器900连接到网络，和一个输入输出(I/O)接口958。服务器900可以操作基于存储在存储器932的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

本发明实施例提供的服务器，根据交互数据的数据属性信息及传输链路上的历史交互数据的数据属性信息，确定本次传输数据的可用带宽，进而根据可用带宽向数据接收端传输数据包。由于基于TCP协议进行数据传输，无论数据接收端还是数据发送端均无需支持额外的协议，应用性较强，且在确定可用带宽时综合考虑了传输链路上的交互数据及历史交互数据，使得确定的带宽更能体现当前的网络状况，显著地提高了数据传输速率。

需要说明的是：上述实施例提供的数据传输装置在传输数据时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将数据传输装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的数据传输装置与数据传输方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。