CN112953850B - 数据传输方法、装置、计算机可读介质及电子设备 - Google Patents

Abstract

本申请属于计算机技术领域，具体涉及一种数据传输方法、数据传输装置、计算机可读介质以及电子设备。该方法包括：基于用户态协议栈将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包；通过原始套接字将所述下行TCP数据包发送至客户端，以使所述客户端通过TCP套接字接收所述下行TCP数据包；当通过所述原始套接字接收到由所述客户端返回的上行TCP数据包时，根据所述状态内存中记录的TCP连接的标识信息确定与所述上行TCP数据包相匹配的目标TCP连接，以将所述上行TCP数据包传输至对应于所述目标TCP连接的服务器。该方法可以提高数据传输效率和传输可靠性。

Description

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

技术领域

本申请属于计算机技术领域，具体涉及一种数据传输方法、数据传输装置、计算机可读介质以及电子设备。

背景技术

现有的音视频传输协议一般可以分为两类，即：基于TCP协议传输或者基于UDP协议传输。基于TCP协议进行音视频数据传输时，由于在网络丢包后需要缓冲等待，容易出现数据传输延迟高的问题，难以适用音视频实时播放的场景。基于UDP协议进行音视频数据传输虽然可以使用音视频实时播放的场景，但是由于缺少重传机制，高丢包率将导致音视频传输质量差的问题。因此，如何对音视频数据进行高效且稳定的传输是目前亟待解决的问题。

发明内容

本申请的目的在于提供一种数据传输方法、数据传输装置、计算机可读介质以及电子设备，至少在一定程度上克服相关技术中存在的音视频数据传输效率低、传输稳定性差等技术问题。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供一种数据传输方法，该方法包括：基于用户态协议栈将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包；通过原始套接字将所述下行TCP数据包发送至客户端，以使所述客户端通过TCP套接字接收所述下行TCP数据包；当通过所述原始套接字接收到由所述客户端返回的上行TCP数据包时，根据所述状态内存中记录的TCP连接的标识信息确定与所述上行TCP数据包相匹配的目标TCP连接，以将所述上行TCP数据包传输至对应于所述目标TCP连接的服务器。

根据本申请实施例的一个方面，提供一种数据传输装置，该装置包括：封装模块，被配置为基于用户态协议栈将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包；发送模块，被配置为通过原始套接字将所述下行TCP数据包发送至客户端，以使所述客户端通过TCP套接字接收所述下行TCP数据包；接收模块，被配置为当通过所述原始套接字接收到由所述客户端返回的上行TCP数据包时，根据所述状态内存中记录的TCP连接的标识信息确定与所述上行TCP数据包相匹配的目标TCP连接，以将所述上行TCP数据包传输至对应于所述目标TCP连接的服务器。

在本申请的一些实施例中，基于以上技术方案，所述封装模块包括：数据拆分单元，被配置为获取服务器产生的待发送数据，并将所述待发送数据拆分为多个数据帧；数据帧分割单元，被配置为基于用户态协议栈对所述数据帧进行分割处理，得到多个具有指定字节长度的数据段，并在状态内存中记录所述数据段；序列号确定单元，被配置为根据所述数据段在所述数据帧中的排列顺序以及所述数据段的数据量，确定各个所述数据段的TCP序列号；数据包封装单元，被配置为分别为各个所述数据段添加携带所述TCP序列号的TCP包头，得到具有TCP报文格式的下行TCP数据包。

在本申请的一些实施例中，基于以上技术方案，所述数据传输装置还包括：连接确定模块，被配置为当通过所述原始套接字接收到由所述客户端返回的上行ACK数据包时，根据所述TCP连接的标识信息确定与所述上行ACK数据包相匹配的目标TCP连接；数据段确定模块，被配置为获取所述状态内存中记录的对应于所述目标TCP连接的等待确认的目标数据段；数据包解析模块，被配置为解析所述上行ACK数据包，得到所述上行ACK数据包中携带的确认号；状态确定模块，被配置为根据所述确认号更新所述目标数据段的数据确认状态。

在本申请的一些实施例中，基于以上技术方案，所述数据传输装置还包括：时长监测模块，被配置为实时监测所述状态内存中记录的等待确认的数据段的发出时长；数据重传模块，被配置为当所述数据段的发出时长超过时长阈值时，基于所述用户态协议栈重新发送所述数据段，所述时长阈值小于TCP协议栈定义的超时时长。

在本申请的一些实施例中，基于以上技术方案，所述发送模块包括：节点获取单元，被配置为获取所述下行TCP数据包的发送时间节点；非冗余发送单元，被配置为若所述发送时间节点未处于数据传输高峰期，则通过原始套接字将所述下行TCP数据包发送至客户端，所述数据传输高峰期是根据网络传输状态动态调整的时间区间；冗余发送单元，被配置为若所述发送时间节点处于所述数据传输高峰期，则获取所述下行TCP数据包的冗余比例，并通过原始套接字将所述下行TCP数据包以及对应于所述冗余比例的冗余数据包发送至客户端。

在本申请的一些实施例中，基于以上技术方案，所述冗余发送单元包括：信息获取子单元，被配置为获取所述下行TCP数据包对应的数据段的重要程度信息和所述数据段所在数据帧的数据长度；冗余比例确定子单元，被配置为根据所述重要程度信息和所述数据长度确定所述下行TCP数据包的冗余比例。

在本申请的一些实施例中，基于以上技术方案，所述发送模块还包括：第一冗余操作单元，被配置为按照所述冗余比例对所述下行TCP数据包进行复制操作，得到与所述下行TCP数据包具有相同内容的一个或者多个冗余数据包；第一发送单元，被配置为通过原始套接字将所述下行TCP数据包和所述冗余数据包发送至客户端。

在本申请的一些实施例中，基于以上技术方案，所述发送模块还包括：第二冗余操作单元，被配置为按照所述冗余比例对TCP序列号连续的多个下行TCP数据包进行异或运算，得到与所述多个下行TCP数据包相关联的一个冗余数据包；第二发送单元，被配置为通过原始套接字将所述多个下行TCP数据包和所述冗余数据包发送至客户端。

在本申请的一些实施例中，基于以上技术方案，所述数据传输装置还包括：丢包率检测模块，被配置为监测所述下行TCP数据包的丢包率；序列号获取模块，被配置为当所述丢包率大于预设的丢包率阈值时，获取等待重传的下行TCP数据包的TCP序列号；重传包头生成模块，被配置为生成携带所述等待重传的下行TCP数据包的TCP序列号的重传TCP包头；重传数据包生成模块，被配置为为所述状态内存中记录的最新视频帧的数据段添加所述重传TCP包头，得到具有TCP报文格式的重传TCP数据包；重传数据包发送模块，被配置为通过原始套接字将所述重传TCP数据包发送至客户端。

在本申请的一些实施例中，基于以上技术方案，所述重传TCP包头中携带重传标识字段，所述重传标识字段用于指示客户端丢弃在所述最新视频帧之前的其他视频帧的数据。

在本申请的一些实施例中，基于以上技术方案，所述数据传输装置还包括：拥塞状态确定模块，被配置为根据所述状态内存中记录的数据段的数据发送时间和数据确认时间，确定向所述客户端传输下行TCP数据包时的网络拥塞状态；数据量调整模块，被配置为向产生待发送数据的服务器发送携带所述网络拥塞状态的动态调整请求，所述动态调整请求用于指示所述服务器根据所述网络拥塞状态调整所述待发送数据的数据量。

在本申请的一些实施例中，基于以上技术方案，所述数据量调整模块还被配置为调整对所述待发送数据进行数据编码时使用的码率和帧率中的至少一种。

根据本申请实施例的一个方面，提供一种计算机可读介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如以上技术方案中的数据传输方法。

根据本申请实施例的一个方面，提供一种电子设备，该电子设备包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器被配置为经由执行所述可执行指令来执行如以上技术方案中的数据传输方法。

根据本申请实施例的一个方面，提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如以上技术方案中的数据传输方法。

在本申请实施例提供的技术方案中，通过使用用户态协议栈来进行数据封装，可以生成模拟TCP协议的TCP数据包，并进一步通过原始套接字来发送和接收TCP数据包，实现了基于UDP协议的模式来发送具有TCP报文格式的TCP数据包，既可以可靠传输，又可以避免数据重传带来的延迟增加，因此可以提高数据传输效率和传输可靠性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性地示出了应用本申请技术方案的示例性***架构框图。

图2示出了本申请实施例在云游戏应用场景中的整体架构示意图。

图3示出了本申请一个实施例中用于进行数据传输的***架构的架构细节示意图。

图4示出了本申请一个实施例中的数据传输方法的步骤流程图。

图5示出了本申请一个实施例中基于用户态协议栈封装下行TCP数据包的步骤流程图。

图6示意性地示出了本申请实施例提供的数据传输装置的结构框图。

图7示意性示出了适于用来实现本申请实施例的电子设备的计算机***结构框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1示意性地示出了应用本申请技术方案的示例性***架构框图。

如图1所示，***架构100可以包括终端设备110、网络120和服务器130。终端设备110可以包括智能手机、平板电脑、笔记本电脑、台式电脑等各种电子设备。服务器130可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。网络120可以是能够在终端设备110和服务器130之间提供通信链路的各种连接类型的通信介质，例如可以是有线通信链路或者无线通信链路。

根据实现需要，本申请实施例中的***架构可以具有任意数目的终端设备、网络和服务器。例如，服务器130可以是由多个服务器设备组成的服务器群组。另外，本申请实施例提供的技术方案可以应用于终端设备110，也可以应用于服务器130，或者可以由终端设备110和服务器130共同实施，本申请对此不做特殊限定。

本申请实施例提供的技术方案可以应用于基于云技术实现的云游戏场景中。云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络***的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台***进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的***后盾支撑，只能通过云计算来实现。

云计算(cloud computing)指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。云计算是网格计算(Grid Computing)、分布式计算(DistributedComputing)、并行计算(Parallel Computing)、效用计算(Utility Computing)、网络存储(Network StorageTechnologies)、虚拟化(Virtualization)、负载均衡(Load Balance)等传统计算机和网络技术发展融合的产物。

随着互联网、实时数据流、连接设备多样化的发展，以及搜索服务、社会网络、移动商务和开放协作等需求的推动，云计算迅速发展起来。不同于以往的并行分布式计算，云计算的产生从理念上将推动整个互联网模式、企业管理模式发生革命性的变革。

云游戏(Cloud gaming)又可称为游戏点播(gaming on demand)，是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高品质游戏。在云游戏场景下，游戏并不在玩家游戏终端，而是在云端服务器中运行，并由云端服务器将游戏场景渲染为视频音频流，通过网络传输给玩家游戏终端。玩家游戏终端无需拥有强大的图形运算与数据处理能力，仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。

图2示出了本申请实施例在云游戏应用场景中的整体架构示意图。如图2所示，该应用场景涉及云游戏服务器210、代理服务器220、云游戏客户端230等架构设施。

云游戏服务器210是游戏程序真正的运行位置，通过虚拟化技术将游戏产生的画面转换为音视频流，传送给代理服务器220做进一步的处理。云游戏服务器210可以是一个云端服务器，也可以是多个云端服务器组成的云游戏服务器集群。

代理服务器220通常部署于靠近用户240的边缘节点，在本申请实施例提供的技术方案中，代理服务器220可以使用原始套接字来模拟TCP协议向云游戏客户端230传输音视频下行数据，达到高吞吐低延迟的效果。

云游戏客户端230的核心能力可理解为是一个网络视频流播放器，当接收到代理服务器220传输的音视频下行数据时，可以向用户240呈现基于网络视频流的游戏内容。同时，云游戏客户端230可以接收用户240通过触控屏幕、鼠标、键盘、手柄等各种输入设备输入的游戏交互数据，并沿着上行路径依次向代理服务器220和云游戏服务器210返回用户输入的游戏交互数据。

本申请实施例提供的技术方案主要可以由代理服务器220执行。图3示出了本申请一个实施例中用于进行数据传输的***架构的架构细节示意图。如图3所示，代理服务器220整体上可以划分为分别用于实现数据上行和数据下行的两个部分。实现数据下行的部分包括：云游戏服务器通信模块221、状态内存模块222、用户态协议栈223和发包模块224。实现数据下行的部分包括：收包模块225、拥塞检测模块226、拥塞反馈模块227。下面结合数据传输过程对相关架构模块的功能做出详细说明。

下行的业务数据传输过程如下。

云游戏服务器210把游戏产生的画面压缩成音视频流，通过高速VPN网络传输给代理服务器220。

代理服务器220中的云游戏服务器通讯模块221负责接收数据，并且把数据拆分为多个视频帧。

每个视频帧会由状态内存模块222记录发送的、确认的各个数据段，根据IP协议的限制，每个数据段的极限大小为1500–20字节IP包头–20字节TCP包头＝1460字节。

状态内存模块222中记录的待发送的数据段可以通过用户态协议栈223来构造成对应的TCP协议的数据包。

用户态协议栈223构造好IP数据包后，由发包模块224通过原始套接字发送到云游戏客户端230。

云游戏客户端230使用TCP套接字应用程序接口(TCP socket API)来接收数据包，在将数据包还原为视频帧后，进行数据解码，然后渲染为游戏画面。

上行的业务数据传输过程如下。

云游戏客户端230每收到一定数量的TCP数据包后，便向代理服务器220发送一个ACK数据包。

代理服务器220中的收包模块225使用原始套接字来接收由云游戏客户端230返回的多个TCP数据包，并需要区分这些TCP数据包隶属于哪个TCP连接。

收包模块225接收到的确认包(ACK数据包)除了影响状态内存模块222中的数据确认状态以外，还会进入到拥塞检测模块226。拥塞检测模块226根据数据段发送完成的时间，以及收到这段数据的ACK数据包的时间，侦测网络是否已经开始拥堵。

当发现网络开始拥堵后，拥塞反馈模块227把拥塞情况发送给云游戏服务器210，通知云游戏服务器210动态地调整游戏的帧率，以及调整视频的码率，通过整体上减少数据量来避开网络的拥堵。

基于上述应用场景中的业务数据传输过程可知，本申请实施例提供的技术方案通过原始套接字再来发送具有TCP报文格式的数据包，本质上是把UDP协议伪装成TCP协议来使用。对于数据接收端(如云游戏客户端)而言，其接收数据包的过程采用的是基于TCP协议的方式。而对于数据发送端(如云游戏服务器或者代理服务器)而言，其发送数据包的过程采用的是基于UDP协议的方式。因此，本申请实施例方案可以兼顾两种套接字协议的优点，实现更加高效可靠的数据传输。

图4示出了本申请一个实施例中的数据传输方法的步骤流程图，该方法可以由终端设备或者服务器执行，也可以由终端设备和服务器共同执行，本申请实施例以该方法由图2所示的代理服务器执行作为示例进行说明。如图4所示，该数据传输方法主要可以包括如下的步骤S410至步骤S430。

步骤S410：基于用户态协议栈将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包。

步骤S420：通过原始套接字将下行TCP数据包发送至客户端，以使客户端通过TCP套接字接收下行TCP数据包。

步骤S430：当通过原始套接字接收到由客户端返回的上行TCP数据包时，根据状态内存中记录的TCP连接的标识信息确定与上行TCP数据包相匹配的目标TCP连接，以将上行TCP数据包传输至对应于目标TCP连接的服务器。

在本申请实施例提供的数据传输方法中，通过使用用户态协议栈来进行数据封装，可以生成模拟TCP协议的TCP数据包，并进一步通过原始套接字来发送和接收TCP数据包，实现了基于UDP协议的模式来发送具有TCP报文格式的TCP数据包，既可以可靠传输，又可以避免数据重传带来的延迟增加，因此可以提高数据传输效率和传输可靠性。

下面分别对以上实施例中的数据传输方法的各个方法步骤做详细说明。

在步骤S410中，基于用户态协议栈将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包。

用户态协议栈，是在Linux用户态上实现的网络协议栈处理程序，底层支撑技术被称为内核旁路技术，又可细分为完全内核旁路及部分内核旁路。其思路大抵是绕过内核，直接将网络硬件设备交给运行在用户态的应用程序使用，常见的内核旁路技术实现有PF_RING、Snabbswitch、Netmap以及DPDK。基于内核旁路技术，用户可以编写自己的网络协议栈，让协议栈功能变得更加灵活，专注于某些高级特性，并且针对特定的业务需求来实现数据流量转发控制以及性能提升。

图5示出了本申请一个实施例中基于用户态协议栈封装下行TCP数据包的步骤流程图。如图5所示，在以上实施例的基础上，步骤S410中的基于用户态协议栈将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包，可以包括如下的步骤S510至步骤S540。

步骤S510：获取服务器产生的待发送数据，并将待发送数据拆分为多个数据帧。

以云游戏应用场景为例，云游戏服务器在游戏程序运行过程中，可以把游戏产生的画面压缩成音视频流，并通过高速VPN网络传输至代理服务器，代理服务器对接收到的音视频流进行数据拆分得到多个数据帧。

步骤S520：基于用户态协议栈对数据帧进行分割处理，得到多个具有指定字节长度的数据段，并在状态内存中记录数据段。

根据IP协议的限制，每个分块的极限大小为1500–20字节IP包头–20字节TCP包头＝1460字节。在每个IP包允许的范围内，除去TCP包头占用的20字节，在剩余的1460个字节中(相当于数据包的body部分)，body部分的前面2个字节为当前数据包真实的长度；因此，对于客户端来说，每隔最多1460字节，就是下一个数据段的长度信息。在此基础上，基于用户态协议栈把视频帧的数据切割为多个数据段，每个数据段的长度不大于1460-2＝1458字节。视频帧通过多个数据段发送到客户端，最后由客户端拼装成完整的一个视频帧。

步骤S530：根据数据段在数据帧中的排列顺序以及数据段的数据量，确定各个数据段的TCP序列号。

TCP序列号用于跟踪基于TCP连接发出的数据量，例如第一个数据段的TCP序列号为100，其数据量为300字节，那么在其排列顺序之后的第二个数据段的TCP序列号为100+300＝400。基于TCP序列号可以保持数据段发送的有序性。

步骤S540：分别为各个数据段添加携带TCP序列号的TCP包头，得到具有TCP报文格式的下行TCP数据包。

举例而言，一个视频帧的大小为100kb，预先设定每个数据段的最大值为1460字节-10字节预留＝1450字节，那么100kb数据需要分割为100*1024/1450＝71个数据段。

71个分割得到的数据段代表着代理服务器会发送71个IP数据包，这71个IP数据包的TCP包头会根据先后顺序使用TCP的序列号串联起来。最终，客户端会收到顺序的完整一帧的数据。

由于使用了用户态协议栈和原始套接字，因此在封装TCP数据包时，数据并不存在层层拷贝的问题，待发送的数据会直接进入驱动级的发送缓冲区，带来类似零拷贝的性能加速效果。

在步骤S420中，通过原始套接字将下行TCP数据包发送至客户端，以使客户端通过TCP套接字接收下行TCP数据包。

在本申请的一个实施例中，为了实现可靠传输，可以采用冗余机制来进行数据传输。本申请实施例在通过原始套接字将下行TCP数据包时，可以获取下行TCP数据包的发送时间节点，并监测各个时间节点的网络传输状态，从而确定一个具有一定时间长度的数据传输高峰期，数据传输高峰期是根据网络传输状态动态调整的时间区间。若发送时间节点未处于数据传输高峰期，则通过原始套接字将下行TCP数据包发送至客户端。若发送时间节点处于数据传输高峰期，则获取下行TCP数据包的冗余比例，并通过原始套接字将下行TCP数据包以及对应于冗余比例的冗余数据包发送至客户端。

在本申请的一个实施例中，获取下行TCP数据包对应的数据段的重要程度信息和数据段所在数据帧的数据长度；根据重要程度信息和数据长度确定下行TCP数据包的冗余比例。对于重要程度高的数据以及数据量较大的数据帧，可以确定相对较大的冗余比例。

在本申请的一个实施例中，基于冗余机制发送数据的方法可以包括：按照冗余比例对下行TCP数据包进行复制操作，得到与下行TCP数据包具有相同内容的一个或者多个冗余数据包；通过原始套接字将下行TCP数据包和冗余数据包发送至客户端。

举例而言，当冗余比例为N：1时，每个下行TCP数据包可以经过复制操作形成另外N-1个内容完全相同的冗余数据包。下行TCP数据包与冗余数据包共同发送至客户端，即便某个TCP数据包丢失，也能够利用冗余数据包进行补充，避免客户端的长时间等待。

在本申请的一个实施例中，基于冗余机制发送数据的方法可以包括：按照冗余比例对TCP序列号连续的多个下行TCP数据包进行异或运算，得到与多个下行TCP数据包相关联的一个冗余数据包；通过原始套接字将多个下行TCP数据包和冗余数据包发送至客户端。

举例而言，当冗余比例为1：N时，每隔N-1个下行TCP数据包可以生成一个与这些下行TCP数据包相关联的冗余数据包，该冗余数据包是对N-1个下行TCP数据包进行异或运算得到的。在将N-1个下行TCP数据包和1个冗余数据包发送至客户端后，当其中任意一个下行TCP数据包丢失时，可以利用另外N-2个下行TCP数据包与冗余数据包进行反向运算，得到丢失的TCP数据包的数据内容。

在步骤S430中，当通过原始套接字接收到由客户端返回的上行TCP数据包时，根据状态内存中记录的TCP连接的标识信息确定与上行TCP数据包相匹配的目标TCP连接，以将上行TCP数据包传输至对应于目标TCP连接的服务器。

在状态内存中，可以利用标识信息记录各个服务器与各个客户端之间建立的TCP连接，该标识信息例如可以是TCP连接的四元组，即源IP地址(source_ip)、源端口(source_port)、目标IP地址(destination_ip)和目标端口(destination_port)。

在本申请的一个实施例中，当通过原始套接字接收到由客户端返回的上行ACK数据包时，根据TCP连接的标识信息确定与上行ACK数据包相匹配的目标TCP连接；获取状态内存中记录的对应于目标TCP连接的等待确认的目标数据段；解析上行ACK数据包，得到上行ACK数据包中携带的确认号；根据确认号更新目标数据段的数据确认状态。

与UDP协议所不同的是，本申请实施例利用原始套接字来模拟TCP协议，对于客户端而言，接收到下行TCP数据包后，可以向服务器返回上行ACK数据包以通知服务器数据包被客户端正确接收。

在本申请的一个实施例中，代理服务器可以实时监测状态内存中记录的等待确认的数据段的发出时长；当数据段的发出时长超过时长阈值时，基于用户态协议栈重新发送数据段，该时长阈值小于TCP协议栈定义的超时时长。在本申请实施例中，状态内存会记录数据段的发送情况，以及收到ACK数据包的情况。对于超过一定时间未收到ACK数据包的数据段，用户态协议栈会执行“超时重传”的逻辑。并且，这里的超时重传的时间远远小于TCP协议栈所定义的时间，从而带来更低的延迟。

在本申请的一个实施例中，服务器可以监测下行TCP数据包的丢包率；当丢包率大于预设的丢包率阈值时，获取等待重传的下行TCP数据包的TCP序列号；生成携带等待重传的下行TCP数据包的TCP序列号的重传TCP包头；为状态内存中记录的最新视频帧的数据段添加重传TCP包头，得到具有TCP报文格式的重传TCP数据包；通过原始套接字将重传TCP数据包发送至客户端。

在本申请的一个实施例中，重传TCP包头中携带重传标识字段，重传标识字段用于指示客户端丢弃在最新视频帧之前的其他视频帧的数据。

在极端情况下，某个数据段的下行TCP数据包可能会多次丢包，导致客户端一直在等待这个数据包，而无法后续的收包流程。即便最终通过重传机制补上了这个序列号的数据包，但是整个视频流会卡顿较长的时间。本申请实施例通过配置携带标识字段的重传TCP数据包，采用“同序列号但是不同内容”的技术来解决这个问题。一般而言，对于同一个序列号的TCP数据包，重传包的内容与第一次传输的内容是完全一样的。而通过原始套接字发送的数据包可以绕开这一点：当丢包率较高的时候，重传的内容直接传输最新的视频帧的分片内容，并在数据头的相关字段中进行说明。客户端收到数据后，根据标志得知最新的视频帧的信息，然后可以丢弃旧的视频帧的数据，从最新的位置开始拼装视频帧数据。通过这样的方法，可能让画面出现一定的丢帧现象，但是能够保障游戏画面的连续性。

在本申请的一个实施例中，根据状态内存中记录的数据段的数据发送时间和数据确认时间，确定向客户端传输下行TCP数据包时的网络拥塞状态；向产生待发送数据的服务器发送携带网络拥塞状态的动态调整请求，动态调整请求用于指示服务器根据网络拥塞状态调整待发送数据的数据量。调整待发送数据的数据量例如可以包括：调整对待发送数据进行数据编码时使用的码率和帧率中的至少一种。

本申请实施例可以建立网络带宽的预测模型，根据数据段的数据发送时间和数据确认时间，预测当前网络传输的网络带宽的剩余量，从而判断网络拥塞状态。当网络拥塞程度较高时，可以通过降低码流的码率和/或帧率的方式来减少待发送数据的数据量。当网络拥塞程度较低时，可以通过提高码流的码率和/或帧率的方式来恢复待发送数据的数据量。

从运营商的角度来看，部分运营商为了避免网络拥塞，通常在高峰期对UDP进行随机丢包。对于这种UDP协议不友好的情况，UDP协议的应用在高峰期会有较多的体验问题。而本申请实施例基于用户态协议栈和原始套接字，模拟TCP协议封包，但是用UDP的模式发送，绕开了运营商的这一策略。

此外，运营商的部分网络设备会修改TCP协议的滑动窗口值，本方案也会顺利的绕过去。对客户端而言，虽然窗口变小，但是来自服务器的数据包仍然源源不断的到来，对收包没有影响；发送方面，上行数据大多仅为ACK数据包，内容很少，滑动窗口也不会造成影响。对于服务器端而言，发包是基于原始套接字的，完全绕开了TCP协议栈，滑动窗口的数据并不影响后续的发包策略。

本申请实施例针对云游戏这种下行数据需要高带宽低延迟、而上行数据微乎其微的应用场景，提出了基于原始套接字的方案来进行TCP协议的封包，最终达到高发送性能、低延迟、强抗网络抖动、冗余发送、避免运营商可以丢包等效果。

应当注意，尽管在附图中以特定顺序描述了本申请中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的数据传输方法。图6示意性地示出了本申请实施例提供的数据传输装置的结构框图。如图6所示，数据传输装置600主要可以包括：封装模块610，被配置为基于用户态协议栈将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包；发送模块620，被配置为通过原始套接字将所述下行TCP数据包发送至客户端，以使所述客户端通过TCP套接字接收所述下行TCP数据包；接收模块630，被配置为当通过所述原始套接字接收到由所述客户端返回的上行TCP数据包时，根据所述状态内存中记录的TCP连接的标识信息确定与所述上行TCP数据包相匹配的目标TCP连接，以将所述上行TCP数据包传输至对应于所述目标TCP连接的服务器。

在本申请的一些实施例中，基于以上各实施例，所述封装模块610包括：数据拆分单元，被配置为获取服务器产生的待发送数据，并将所述待发送数据拆分为多个数据帧；数据帧分割单元，被配置为基于用户态协议栈对所述数据帧进行分割处理，得到多个具有指定字节长度的数据段，并在状态内存中记录所述数据段；序列号确定单元，被配置为根据所述数据段在所述数据帧中的排列顺序以及所述数据段的数据量，确定各个所述数据段的TCP序列号；数据包封装单元，被配置为分别为各个所述数据段添加携带所述TCP序列号的TCP包头，得到具有TCP报文格式的下行TCP数据包。

在本申请的一些实施例中，基于以上各实施例，所述数据传输装置600还包括：连接确定模块，被配置为当通过所述原始套接字接收到由所述客户端返回的上行ACK数据包时，根据所述TCP连接的标识信息确定与所述上行ACK数据包相匹配的目标TCP连接；数据段确定模块，被配置为获取所述状态内存中记录的对应于所述目标TCP连接的等待确认的目标数据段；数据包解析模块，被配置为解析所述上行ACK数据包，得到所述上行ACK数据包中携带的确认号；状态确定模块，被配置为根据所述确认号更新所述目标数据段的数据确认状态。

在本申请的一些实施例中，基于以上各实施例，所述数据传输装置600还包括：时长监测模块，被配置为实时监测所述状态内存中记录的等待确认的数据段的发出时长；数据重传模块，被配置为当所述数据段的发出时长超过时长阈值时，基于所述用户态协议栈重新发送所述数据段，所述时长阈值小于TCP协议栈定义的超时时长。

在本申请的一些实施例中，基于以上各实施例，所述发送模块620包括：节点获取单元，被配置为获取所述下行TCP数据包的发送时间节点；非冗余发送单元，被配置为若所述发送时间节点未处于数据传输高峰期，则通过原始套接字将所述下行TCP数据包发送至客户端，所述数据传输高峰期是根据网络传输状态动态调整的时间区间；冗余发送单元，被配置为若所述发送时间节点处于所述数据传输高峰期，则获取所述下行TCP数据包的冗余比例，并通过原始套接字将所述下行TCP数据包以及对应于所述冗余比例的冗余数据包发送至客户端。

在本申请的一些实施例中，基于以上各实施例，所述冗余发送单元包括：信息获取子单元，被配置为获取所述下行TCP数据包对应的数据段的重要程度信息和所述数据段所在数据帧的数据长度；冗余比例确定子单元，被配置为根据所述重要程度信息和所述数据长度确定所述下行TCP数据包的冗余比例。

在本申请的一些实施例中，基于以上各实施例，所述发送模块620还包括：第一冗余操作单元，被配置为按照所述冗余比例对所述下行TCP数据包进行复制操作，得到与所述下行TCP数据包具有相同内容的一个或者多个冗余数据包；第一发送单元，被配置为通过原始套接字将所述下行TCP数据包和所述冗余数据包发送至客户端。

在本申请的一些实施例中，基于以上各实施例，所述发送模块620还包括：第二冗余操作单元，被配置为按照所述冗余比例对TCP序列号连续的多个下行TCP数据包进行异或运算，得到与所述多个下行TCP数据包相关联的一个冗余数据包；第二发送单元，被配置为通过原始套接字将所述多个下行TCP数据包和所述冗余数据包发送至客户端。

在本申请的一些实施例中，基于以上各实施例，所述数据传输装置600还包括：丢包率检测模块，被配置为监测所述下行TCP数据包的丢包率；序列号获取模块，被配置为当所述丢包率大于预设的丢包率阈值时，获取等待重传的下行TCP数据包的TCP序列号；重传包头生成模块，被配置为生成携带所述等待重传的下行TCP数据包的TCP序列号的重传TCP包头；重传数据包生成模块，被配置为为所述状态内存中记录的最新视频帧的数据段添加所述重传TCP包头，得到具有TCP报文格式的重传TCP数据包；重传数据包发送模块，被配置为通过原始套接字将所述重传TCP数据包发送至客户端。

在本申请的一些实施例中，基于以上各实施例，所述重传TCP包头中携带重传标识字段，所述重传标识字段用于指示客户端丢弃在所述最新视频帧之前的其他视频帧的数据。

在本申请的一些实施例中，基于以上各实施例，所述数据传输装置600还包括：拥塞状态确定模块，被配置为根据所述状态内存中记录的数据段的数据发送时间和数据确认时间，确定向所述客户端传输下行TCP数据包时的网络拥塞状态；数据量调整模块，被配置为向产生待发送数据的服务器发送携带所述网络拥塞状态的动态调整请求，所述动态调整请求用于指示所述服务器根据所述网络拥塞状态调整所述待发送数据的数据量。

在本申请的一些实施例中，基于以上各实施例，所述数据量调整模块还被配置为调整对所述待发送数据进行数据编码时使用的码率和帧率中的至少一种。

本申请各实施例中提供的数据传输装置的具体细节已经在对应的方法实施例中进行了详细的描述，此处不再赘述。

图7示意性地示出了用于实现本申请实施例的电子设备的计算机***结构框图。

需要说明的是，图7示出的电子设备的计算机***700仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图7所示，计算机***700包括中央处理器701(Central Processing Unit，CPU)，其可以根据存储在只读存储器702(Read-Only Memory，ROM)中的程序或者从存储部分708加载到随机访问存储器703(Random Access Memory，RAM)中的程序而执行各种适当的动作和处理。在随机访问存储器703中，还存储有***操作所需的各种程序和数据。中央处理器701、在只读存储器702以及随机访问存储器703通过总线704彼此相连。输入/输出接口705(Input/Output接口，即I/O接口)也连接至总线704。

以下部件连接至输入/输出接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如局域网卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至输入/输出接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本申请的实施例，各个方法流程图中所描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理器701执行时，执行本申请的***中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (14)

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

基于用户态协议栈绕过内核将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包；

通过原始套接字将所述下行TCP数据包发送至客户端，以使所述客户端通过TCP套接字接收所述下行TCP数据包；

监测所述下行TCP数据包的丢包率；

当所述丢包率大于预设的丢包率阈值时，获取等待重传的下行TCP数据包的TCP序列号；

生成携带所述等待重传的下行TCP数据包的TCP序列号的重传TCP包头；

为所述状态内存中记录的最新视频帧的数据段添加所述重传TCP包头，得到具有TCP报文格式的重传TCP数据包；

通过原始套接字将所述重传TCP数据包发送至客户端；

当通过所述原始套接字接收到由所述客户端返回的上行TCP数据包时，根据所述状态内存中记录的TCP连接的标识信息确定与所述上行TCP数据包相匹配的目标TCP连接，以将所述上行TCP数据包传输至对应于所述目标TCP连接的服务器。

2.根据权利要求1所述的数据传输方法，其特征在于，基于用户态协议栈绕过内核将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包，包括：

获取服务器产生的待发送数据，并将所述待发送数据拆分为多个数据帧；

基于用户态协议栈绕过内核对所述数据帧进行分割处理，得到多个具有指定字节长度的数据段，并在状态内存中记录所述数据段；

根据所述数据段在所述数据帧中的排列顺序以及所述数据段的数据量，确定各个所述数据段的TCP序列号；

分别为各个所述数据段添加携带所述TCP序列号的TCP包头，得到具有TCP报文格式的下行TCP数据包。

3.根据权利要求1所述的数据传输方法，其特征在于，所述方法还包括：

当通过所述原始套接字接收到由所述客户端返回的上行ACK数据包时，根据所述TCP连接的标识信息确定与所述上行ACK数据包相匹配的目标TCP连接；

获取所述状态内存中记录的对应于所述目标TCP连接的等待确认的目标数据段；

解析所述上行ACK数据包，得到所述上行ACK数据包中携带的确认号；

根据所述确认号更新所述目标数据段的数据确认状态。

4.根据权利要求1所述的数据传输方法，其特征在于，所述方法还包括：

实时监测所述状态内存中记录的等待确认的数据段的发出时长；

当所述数据段的发出时长超过时长阈值时，基于所述用户态协议栈重新发送所述数据段，所述时长阈值小于TCP协议栈定义的超时时长。

5.根据权利要求1所述的数据传输方法，其特征在于，通过原始套接字将所述下行TCP数据包发送至客户端，包括：

获取所述下行TCP数据包的发送时间节点；

若所述发送时间节点未处于数据传输高峰期，则通过原始套接字将所述下行TCP数据包发送至客户端，所述数据传输高峰期是根据网络传输状态动态调整的时间区间；

若所述发送时间节点处于所述数据传输高峰期，则获取所述下行TCP数据包的冗余比例，并通过原始套接字将所述下行TCP数据包以及对应于所述冗余比例的冗余数据包发送至客户端。

6.根据权利要求5所述的数据传输方法，其特征在于，获取所述下行TCP数据包的冗余比例，包括：

获取所述下行TCP数据包对应的数据段的重要程度信息和所述数据段所在数据帧的数据长度；

根据所述重要程度信息和所述数据长度确定所述下行TCP数据包的冗余比例。

7.根据权利要求5所述的数据传输方法，其特征在于，通过原始套接字将所述下行TCP数据包以及对应于所述冗余比例的冗余数据包发送至客户端，包括：

按照所述冗余比例对所述下行TCP数据包进行复制操作，得到与所述下行TCP数据包具有相同内容的一个或者多个冗余数据包；

通过原始套接字将所述下行TCP数据包和所述冗余数据包发送至客户端。

8.根据权利要求5所述的数据传输方法，其特征在于，通过原始套接字将所述下行TCP数据包以及对应于所述冗余比例的冗余数据包发送至客户端，包括：

按照所述冗余比例对TCP序列号连续的多个下行TCP数据包进行异或运算，得到与所述多个下行TCP数据包相关联的一个冗余数据包；

通过原始套接字将所述多个下行TCP数据包和所述冗余数据包发送至客户端。

9.根据权利要求1至8中任意一项所述的数据传输方法，其特征在于，所述重传TCP包头中携带重传标识字段，所述重传标识字段用于指示客户端丢弃在所述最新视频帧之前的其他视频帧的数据。

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

根据所述状态内存中记录的数据段的数据发送时间和数据确认时间，确定向所述客户端传输下行TCP数据包时的网络拥塞状态；

向产生待发送数据的服务器发送携带所述网络拥塞状态的动态调整请求，所述动态调整请求用于指示所述服务器根据所述网络拥塞状态调整所述待发送数据的数据量。

11.根据权利要求10所述的数据传输方法，其特征在于，调整所述待发送数据的数据量，包括：

调整对所述待发送数据进行数据编码时使用的码率和帧率中的至少一种。

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

封装模块，被配置为基于用户态协议栈绕过内核将状态内存中记录的待发送的数据段封装为具有TCP报文格式的下行TCP数据包；

发送模块，被配置为通过原始套接字将所述下行TCP数据包发送至客户端，以使所述客户端通过TCP套接字接收所述下行TCP数据包；

丢包率检测模块，被配置为监测所述下行TCP数据包的丢包率；

序列号获取模块，被配置为当所述丢包率大于预设的丢包率阈值时，获取等待重传的下行TCP数据包的TCP序列号；

重传包头生成模块，被配置为生成携带所述等待重传的下行TCP数据包的TCP序列号的重传TCP包头；

重传数据包生成模块，被配置为为所述状态内存中记录的最新视频帧的数据段添加所述重传TCP包头，得到具有TCP报文格式的重传TCP数据包；

重传数据包发送模块，被配置为通过原始套接字将所述重传TCP数据包发送至客户端；

接收模块，被配置为当通过所述原始套接字接收到由所述客户端返回的上行TCP数据包时，根据所述状态内存中记录的TCP连接的标识信息确定与所述上行TCP数据包相匹配的目标TCP连接，以将所述上行TCP数据包传输至对应于所述目标TCP连接的服务器。

13.一种计算机可读介质，其上存储有计算机程序，该计算机程序被处理器执行时实现权利要求1至11中任意一项所述的数据传输方法。

14.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至11中任意一项所述的数据传输方法。

Images