CN117692277A - 一种数据传输方法、装置、设备及可读存储介质 - Google Patents

Abstract

本申请公开了计算机技术领域内的一种数据传输方法、装置、设备及可读存储介质。本申请利用第一转发端与第二转发端协商的数据传输规则进行第二报文的封装，数据传输规则包括会话映射关系，应用于VPN访问场景时隧道内的多个会话无需通过同一公网会话往外网传输，解决了远程访问过程中的流量封堵现象。同时，数据传输规则中的传输协议和数据处理要求可使第二转发端与第一转发端按照双方协商好的要求对二者之间所传输的数据进行处理，便于实现第二转发端与第一转发端之间的数据传输的扩展，也能够提高数据传输效率。

Description

一种数据传输方法、装置、设备及可读存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种数据传输方法、装置、设备及可读存储介质。

背景技术

目前，在VPN远程访问过程中容易出现网络拥堵现象。如：隧道内的UDP会话较多，而这些UDP会话需要通过同一公网会话往外网传输，从而出现的流量封堵现象，相应的，TCP(Transmission Control Protocol，传输控制协议)长链接也容易出现流量封堵现象。

因此，如何解决远程访问过程中的流量封堵现象，是本领域技术人员需要解决的问题。

发明内容

有鉴于此，本申请的目的在于提供一种数据传输方法、装置、设备及可读存储介质，以使一个会话与另一会话一对一，解决远程访问过程中的流量封堵现象。其具体方案如下：

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

获取第一报文；所述第一报文的目的端为第二转发端；

确定与所述第二转发端协商的数据传输规则；所述数据传输规则包括：所述第一转发端与所述第一报文的发送端形成的会话、所述第一转发端与所述第二转发端形成的会话的映射关系；

根据所述数据传输规则封装所述第一报文，得到第二报文；

发送所述第二报文至所述第二转发端。

可选地，所述确定与所述第二转发端协商的数据传输规则，包括：

以所述第二转发端的标识信息为查询关键字，在预设数据库中查询所述数据传输规则；

将与所述标识信息对应的数据传输规则确定为所述第一转发端与所述第二转发端协商的数据传输规则。

可选地，还包括：

若不存在所述数据传输规则，则与所述第二转发端协商确定所述数据传输规则。

可选地，所述与所述第二转发端协商确定所述数据传输规则，包括：

在原通信报文中添加所述第一转发端的第一要求，获得新通信报文；所述第一要求包括：所述第一转发端所在局域网中的终端IP地址及终端端口号、所述第一转发端的内网IP地址及内网端口号；

发送所述新通信报文至所述第二转发端，以使所述第二转发端解析所述新通信报文得到所述第一要求，若确认能够满足所述第一要求，则基于所述第一要求和第二端确认要求生成并记录所述数据传输规则，并在原确认报文中添加所述第二端确认要求，得到新确认报文；所述第二端确认要求包括：所述第二转发端的公网IP地址和公网端口号；

接收所述第二转发端发送的所述新确认报文，解析所述新确认报文得到所述第二端确认要求；

基于所述第一要求和所述第二端确认要求生成并记录所述数据传输规则。

可选地，所述原通信报文为握手报文；相应地，所述在原通信报文中添加所述第一转发端的第一要求，包括：在所述握手报文的拓展选项和/或紧急信息选项中添加所述第一要求；

所述原确认报文为所述握手报文的握手确认报文；相应地，所述在原确认报文中添加所述第二端确认要求，包括：在所述握手确认报文的拓展选项和/或紧急信息选项中添加所述第二端确认要求。

可选地，所述原通信报文为传输数据之前预设的信息协商报文；相应地，所述在原通信报文中添加所述第一转发端的第一要求，包括：在所述信息协商报文的载荷选项中添加所述第一要求；

所述原确认报文为所述信息协商报文的协商确认报文；相应地，所述在原确认报文中添加所述第二端确认要求，包括：在所述协商确认报文的载荷选项中添加所述第二端确认要求。

可选地，还包括：

所述数据传输规则还包括：所述第二转发端与所述第一转发端均适用的传输协议、所述第二转发端与所述第一转发端均适用的数据处理要求；

相应地，所述第一要求还包括：所述第一转发端适用的至少一种传输协议和至少一种数据处理要求；

相应地，所述第二端确认要求还包括：所述第二转发端与所述第一转发端均适用的传输协议、所述第二转发端与所述第一转发端均适用的数据处理要求；

若接收到报错报文，且确认存在所述第一转发端适用的、不在所述第一要求中的其他传输协议和其他数据处理要求，则用其他传输协议和其他数据处理要求替换所述第一要求中的传输协议和数据处理要求，并执行在原通信报文中添加所述第一转发端的第一要求及后续步骤；

其中，所述第二转发端若确认不能满足所述第一要求，则生成所述报错报文，并发送所述报错报文至所述第一转发端。

可选地，还包括：

若接收到所述报错报文，且确认不存在所述第一转发端适用的、不在所述第一要求中的其他传输协议和其他数据处理要求，则返回错误通知信息至所述第一报文的发送端。

可选地，所述映射关系为五元组映射关系；所述第二转发端与所述第一转发端均适用的传输协议包括：HTTPS、UDP和IPSEC；所述第二转发端与所述第一转发端均适用的数据处理要求包括：加密要求、数据完整性检测要求和身份认证要求。

可选地，所述五元组映射关系中的所述第二转发端的公网源端口号和所述第一转发端的公网目的端口号不重复。

第二方面，本申请提供了一种数据传输装置，应用于第一转发端，包括：

获取模块，用于获取第一报文；所述第一报文的目的端为第二转发端；

确定模块，用于确定与所述第二转发端协商的数据传输规则；所述数据传输规则包括：所述第一转发端与所述第一报文的发送端形成的会话、所述第一转发端与所述第二转发端形成的会话的映射关系；

封装模块，用于根据所述数据传输规则封装所述第一报文，得到第二报文；

发送模块，用于发送所述第二报文至所述第二转发端。

第三方面，本申请提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序，以实现前述公开的数据传输方法。

第四方面，本申请提供了一种可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的数据传输方法。

通过以上方案可知，本申请提供了一种数据传输方法，应用于第一转发端，包括：获取第一报文；确定与第二转发端协商的数据传输规则；所述数据传输规则包括：所述第一转发端与所述第一报文的发送端形成的会话、所述第一转发端与所述第二转发端形成的会话的映射关系；根据所述数据传输规则封装所述第一报文，得到第二报文；发送所述第二报文至所述第二转发端。

可见，本申请利用第一转发端与第二转发端协商的数据传输规则进行第二报文的封装，由于数据传输规则包括第一转发端与第一报文的发送端形成的会话、与第一转发端与第二转发端形成的会话的会话映射信息，因此前后两个会话具有唯一的一对一映射关系，应用于VPN访问场景中时，隧道内的多个会话无需通过同一公网会话往外网传输，解决了远程访问过程中的流量封堵现象。

相应地，本申请提供的一种数据传输装置、设备及可读存储介质，也同样具有上述技术效果。

附图说明

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

图1为本申请公开的一种数据传输方法流程图；

图2为本申请公开的一种数据传输规则协商过程示意图；

图3为本申请公开的一种第二转发端与第一转发端的发包流程示意图；

图4为本申请公开的一种第二转发端与第一转发端的收包流程示意图；

图5为本申请公开的一种数据传输装置示意图；

图6为本申请公开的一种电子设备示意图；

图7为本申请公开的另一种电子设备示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，在VPN远程访问过程中容易出现网络拥堵现象。如：隧道内的UDP会话较多，而这些UDP会话需要通过同一公网会话往外网传输，从而出现的流量封堵现象，相应的，TCP长链接也容易出现流量封堵现象。为此，本申请提供了一种数据传输方案，能够使隧道内会话与公网会话一对一映射，解决了远程访问过程中的流量封堵现象。同时，数据传输规则中的传输协议和数据处理要求可使第二转发端与第一转发端按照双方协商好的要求对二者之间所传输的数据进行处理，如：以协商好的密码算法对所传输的数据进行加密和解密、以协商好的检测手段对数据进行完整性检测等，由此便于实现第二转发端与第一转发端之间的数据传输的扩展。

下面对本申请涉及的专业技术用语进行介绍：

VPN(Virtual Private Network，虚拟专用网络)：一种用于连接中、大型企业或团体与团体间的私人网络的通讯方法，它利用隧道协议来达到保密、发送端认证、消息准确性等私人消息安全效果。

NAT(Network Address Translation，网络地址转换)：在计算机网络中是一种在IP数据包通过路由器或防火墙时重写来源IP地址或目的IP地址的技术。本申请的网络地址转换包括端口的映射，可看作PAT(Port Address Translations，端口地址转换)。使用NAT规则实现的VPN称为NatVPN。

TCP SYN：TCP握手的第一个报文。

TCP SYN+ACK：TCP握手的第二个报文。

TCP+ACK：TCP握手的第三个报文。

IP OPT/ip opt：ip头中的拓展选项，包括知名的拓展信息和私有的拓展信息，本申请可以选择使用知名的拓展头部，比如SR，也可以选择私有的拓展头部，来承载私有数据。

TCP OPT/tcp opt：TCP协议头部中的拓展选项，包括知名的拓展信息和私有的拓展信息，本申请可以选择知名的拓展选项和私有的拓展选项，来承载私有数据。

会话(session)：在网络传输过程中，一个五元组对应一个会话。

QUIC(Quick UDP Internet Connection，叫做快速UDP网络连接)：是Google提出的一个基于UDP的可靠的安全的传输协议。

参见图1所示，本申请实施例公开了一种数据传输方法，应用于第一转发端，包括：

S101、获取需发送至第二转发端的第一报文。

在本实施例中，第二转发端和第一转发端可以是两个网关，网关内可实现VPN功能，例如：作为第一转发端的网关部署于局域网1中，作为第二转发端的网关部署于局域网2中；再如：作为第二转发端的网关以服务端身份部署于位于A地区的企业总部的内网中，作为第一转发端的网关以客户端身份部署于位于B地区的企业分部的内网中。当然，第二转发端和第一转发端也可以是位于同一网络或位于不同网络内的主机服务器；或位于不同网络内的VPN设备。具体的，第二转发端和第一转发端上设有具备本实施例提供的报文封装功能的软件模块或硬件模块。

因此，本实施例可适用于企业分部网络的VPN设备访问企业总部网络的VPN设备的场景，企业总部网络的VPN设备访问企业分部网络的VPN设备的场景，同一网络内不同设备间的访问场景，以及不同网络内的不同主机间的访问场景。也即：第一转发端和第二转发端可以是两个网络的网关；也可以是两个主机，这两个主机不限制处于同一网络还是不同网络。

S102、确定与第二转发端协商的数据传输规则。

需要说明的是，第一转发端和第二转发端各自适用和支持的传输协议、数据处理要求可以灵活配置，且传输协议和数据处理要求的种类不止一个，但第一转发端和第二转发端之间传输的数据需要遵循相同的传输协议和相同的数据处理要求，故第一转发端和第二转发端需要进行数据传输规则的协商。

其中，数据传输规则包括：第一转发端与第一报文的发送端形成的会话(如VPN访问场景中的内网会话)、与第一转发端与第二转发端形成的会话(如VPN访问场景中的公网会话)的会话映射信息、第二转发端与第一转发端均适用的传输协议、第二转发端与第一转发端均适用的数据处理要求。在VPN访问场景中，内网会话即：发送第一报文的终端与第一转发端之间的会话，发送第一报文的终端与第一转发端处于同一局域网内；公网会话即：第二转发端与第一转发端之间的会话。

在一种实施方式中，映射关系为五元组映射关系，五元组包括：源IP地址、源端口号、目的IP地址、目的端口号和传输协议的名称；发送第一报文的终端与第一转发端之间的内网会话的这五个元素、与第二转发端与第一转发端之间的公网会话的这五个元素形成映射关系，也就得到了五元组映射关系。第二转发端与第一转发端均适用的传输协议包括：HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer，超文本传输安全协议)、UDP和IPSEC(Internet Protocol Security，Internet协议安全性，是一种开放标准的框架结构)。第二转发端与第一转发端均适用的数据处理要求包括：加密要求、数据完整性检测要求和身份认证要求。其中，五元组映射关系中的第二转发端的公网源端口号和第一转发端的公网目的端口号不重复。

第一转发端和第二转发端可以借助二者之间原本需传输的报文(如二者之间的握手报文)进行数据传输规则的协商，也可以特意设定专用于二者进行数据传输规则协商的报文，如：二者传输数据之前设定信息协商报文来进行数据传输规则的协商。协商成功后，第一转发端和第二转发端各自记录数据传输规则，如：第一转发端利用预设数据库记录数据传输规则，以便后续传输数据时使用。

在需要传输数据时，第一转发端即时确定与第二转发端协商的数据传输规则，包括：第一转发端以第二转发端的标识信息为查询关键字，在预设数据库中查询数据传输规则；将与标识信息对应的数据传输规则确定为第一转发端与第二转发端协商的数据传输规则。

如果第一转发端在需要传输数据时，查不到数据传输规则，那么第一转发端与第二转发端即时协商来确定数据传输规则。在一种实施方式中，第一转发端与第二转发端协商确定数据传输规则，包括：在原通信报文中添加所述第一转发端的第一要求，获得新通信报文；所述第一要求包括：所述第一转发端所在局域网中的终端IP地址及终端端口号、所述第一转发端的内网IP地址及内网端口号、所述第一转发端适用的至少一种传输协议和至少一种数据处理要求；发送所述新通信报文至所述第二转发端，以使所述第二转发端解析所述新通信报文得到所述第一要求，若确认能够满足所述第一要求，则基于所述第一要求和第二端确认要求生成并记录所述数据传输规则，并在原确认报文中添加所述第二端确认要求，得到新确认报文；所述第二端确认要求包括：所述第二转发端的公网IP地址、公网端口号、所述第二转发端与所述第一转发端均适用的传输协议、所述第二转发端与所述第一转发端均适用的数据处理要求；接收所述第二转发端发送的所述新确认报文，解析所述新确认报文得到所述第二端确认要求；基于所述第一要求和所述第二端确认要求生成并记录所述数据传输规则。

如前所述，第一转发端和第二转发端可以借助二者之间原本需传输的报文进行数据传输规则的协商，也可以特意设定专用于二者进行数据传输规则协商的报文。因此在一种实施方式中，原通信报文为握手报文；相应地，在原通信报文中添加第一转发端的第一要求，包括：在握手报文的拓展选项和/或紧急信息选项中添加第一要求；原确认报文为握手报文的握手确认报文；相应地，在原确认报文中添加第二端确认要求，包括：在握手确认报文的拓展选项和/或紧急信息选项中添加第二端确认要求。

在一种实施方式中，原通信报文为传输数据之前预设的信息协商报文；相应地，在原通信报文中添加第一转发端的第一要求，包括：在信息协商报文的载荷选项中添加第一要求；原确认报文为信息协商报文的协商确认报文；相应地，在原确认报文中添加第二端确认要求，包括：在协商确认报文的载荷选项中添加第二端确认要求。

如果第二转发端自身确认不能满足第一要求(如第二转发端不支持第一要求中的传输协议和/或数据处理要求等)，则生成报错报文，并发送报错报文至第一转发端。在一种实施方式中，若第一转发端接收到报错报文，且确认存在第一转发端适用的、不在第一要求中的其他传输协议和其他数据处理要求，则用其他传输协议和其他数据处理要求替换第一要求中的传输协议和数据处理要求，并执行在原通信报文中添加第一转发端的第一要求及后续步骤，第一转发端以此来更换传输协议和数据处理要求，再次与第二转发端进行数据传输规则的协商。

在一种实施方式中，若第一转发端接收到报错报文，且确认不存在第一转发端适用的、不在第一要求中的其他传输协议和其他数据处理要求，则返回错误通知信息至第一报文的发送端。也就是：第一转发端与第二转发端协商后，发现二者不支持相同的传输协议和相同的数据处理要求，此时第一转发端告知第一报文的发送端。其中，第一报文的发送端可以是：与第一转发端处于同一局域网中的终端设备。

S103、根据数据传输规则封装第一报文，得到第二报文。

S104、发送第二报文至第二转发端。

可见，本实施例利用第一转发端与第二转发端协商的数据传输规则进行第二报文的封装。在VPN访问场景中，第一转发端和第二转发端是两个网络的出口设置的VPN设备，数据传输规则包括内网会话与公网会话的映射关系，因此隧道内会话与公网会话就是一对一的映射，因而隧道内的多个会话无需通过同一公网会话往外网传输，解决了远程访问过程中的流量封堵现象。同时，数据传输规则中的传输协议和数据处理要求可使第二转发端与第一转发端按照双方协商好的要求对二者之间所传输的数据进行处理，如：以协商好的密码算法对所传输的数据进行加密和解密、以协商好的检测手段对数据进行完整性检测等，由此便于实现第二转发端与第一转发端之间的数据传输的扩展，也能够提高数据传输效率。

下面以第一转发端和第二转发端是两个网络的出口设置的VPN网关为例进行方案介绍。

如果第一转发端和第二转发端通过TCP协议传输数据，那么在二者协商NAT规则之前需要交换两个网关之间的配置特性，使用TCP保证数据交换的可靠性，请参见图2，需交换的配置特性包括：安全特性标签(Feature Flags)：比如是否支持加密，是否支持完整性，以及是否压缩等其他叠加特性。安全参数(Security Param)：加密算法，完整性算法，秘钥材料(DH群等)。拓展选项列表(Ext-option List)：包括ip头选项，tcp头选项等。认证信息(Auth Info)：用于身份验证。

请参见图2，NatVPN CLIENT(第一转发端)和NatVPN SERVER(第二转发端)在TCP握手阶段进行数据传输规则的协商，具体过程包括：NatVPN CLIENT在TCP的SYN包中的IP层ipopt中添加私有数据或在TCP头部的tcp opt中添加私有数据，私有数据即：NatVPN CLIENT支持的传输协议、数据所用的加密算法、NatVPN CLIENT所在局域网中的终端IP地址及终端端口号、NatVPN CLIENT的内网IP和内网端口等，也就是第一要求。NatVPN SERVER如果收到这个SYN包，说明客户端到服务端可以使用ip opt或者tcp opt来承载私有数据，那么NatVPN SERVER基于数据包中的私有数据确认自身是否支持相同的传输协议、加密算法等要求，若支持，则NatVPN SERVER将自身支持相同的传输协议、加密算法等要求、自身公网IP和公网端口作为私有数据，也就是第二端确认要求，也以相同的方式添加在SYN+ACK包中并发出；同时NatVPN SERVER学习并记录NAT规则(即数据传输规则)。如果TCP握手能够成功，说明服务端到客户端可以使用ip opt或者tcp opt来承载私有数据，且二者成功完成协商；如果握手不成功，则需要换另一种传输协议或另一种加密算法再次尝试协商。另一种传输协议如：ESP(封装安全载荷协议)、UDP(User Datagram Protocol，用户数据报协议)等。其中，ESP、UDP没有握手的过程，并且四层协议头部没有拓展位置，但可以使用ip opt来装载私有数据进行协商。

可见，针对有握手过程的协议，用握手报文的IP层ip opt或TCP头部的tcp opt装载私有数据进行协商，针对没有握手过程的协议，用ip opt来装载私有数据进行协商。

NatVPN CLIENT和NatVPN SERVER协商规则完成后，二者进行数据传输的过程请参见图3和图4。如图3所示，NatVPN CLIENT或NatVPN SERVER在向公网发包时，先判断当前所发数据的目的端是否对应有NAT规则，有则基于此规则进行数据包的封装，然后进行地址转换后将数据包发往公网；无则即时进行NAT规则的生成，然后基于生成的规则进行数据包的封装，然后进行地址转换后将数据包发往公网。如图4所示，NatVPN CLIENT或NatVPNSERVER在收到数据包后，先进行常规的安全校验，校验通过后判断当前数据的发送端是否对应有NAT规则，有则基于此规则还原数据包为隧道内数据，然后进行地址转换后将数据包发往内网；无则即时进行NAT规则的生成，然后基于生成的规则还原数据包为隧道内数据，然后进行地址转换后将数据包发往内网。NAT记录是形成NAT规则的基础信息，可认为是前述第一要求进而客户端确认要求的集合。

其中，NAT规则包括隧道内原始session的五元组跟公网五元组的映射关系。隧道内发包的时候，根据五元组查询对应的隧道外session，进行封包发送。通过该NAT规则学习后，对端收到包会根据隧道外五元组查询隧道内五元组信息后进行数据还原。不同NAT规则需要进行冲突判断，不存在冲突的时候才会生成。换句话来说就是一个隧道内session不能对应多个隧道外session，一个隧道外session也不能对应多个隧道内session，隧道内session与隧道外session必须一一映射。本端生成的映射规则很容易避免冲突，但还需要避免从对端学习过来的规则跟本端的规则冲突，可以采用约定的方式避免此问题，如：NatVPN server端发起的session的源端口使用奇数端口，NatVPN client端发起的session的源端口使用偶数端口作为目的端口。极端情况下都是一端发起session，除去知名端口，端口划分范围为2万，至少有20000×20000/2共约2亿个session，完全足够使用。一般在部署网关的时候，NatVPN client一般部署在分支内网，NatVPN server部署在总部内网。

本实施例将NAT规则存在ip opt或者tcp opt中，一般只会在学习阶段才会放到ipopt或者tcp opt中，并且不同协议的学习阶段不一样。比如TCP协议，会在握手阶段学习NAT规则，握手之后的报文不会携带NAT规则。而UDP协议的首包进行NAT规则学习，为避免首包丢包，考虑在前面几个包中都携带NAT规则，由于UDP没有连接，可以使相关NAT规则存在一定有效期，长时间没有进行UDP发包需要携带NAT规则，避免规则不存在导致不同。UDP传输协议是不可靠的，可以选择将UDP协议映射成QUIC协议，对UDP协议进行可靠性传输，一条隧道内UDP会话映射成QUIC会话进行传输。

具体的，NAT规则中可以规定数据的私密性、完整性及数据源认证和秘钥保护等数据处理要求。私密性：可以选择AES、chacha20、3DES、RSA、SM3、SM4等安全加密算法，针对四层载荷进行加密；秘钥在配置特性的协商阶段协商出来，比如使用DH群。完整性和数据源认证：可以选择hmac-sha、hmac-sha2等算法，对四层载荷以及私有拓展数据进行完整性保护，秘钥在配置特性的协商阶段协商出来。秘钥保护：协商出来的秘钥属于基础秘钥，命名为skey_d。会话秘钥是通过skey_d派生出来，可以使用skey_s＝HMAC_SHA256(skey_d，NAT规则|秘钥类型)进行生成，也就是使用hmac_sha256算法，以skey_d为秘钥，对报文进行加密。秘钥类型有两种，加密和完整性保护，会生成对应的秘钥。

当前VPN隧道协议固定并且单一，容易被中间网络封堵，本申请能够使隧道内会话直接通过NAT规则一一映射到公网，打破了VPN隧道与公网传输的固定单一的缺陷，提高了网络穿透性，同时降低了带宽的消耗。主要内容包括：通过NAT规则将隧道会话一一映射到公网，公网上跑多条会话，避免中间网络封堵，大大提高了网络的穿透性。通过NAT规则的学习，避免手动配置NAT规则麻烦，降低了NAT规则的管理难度。通过ip opt和tcp opt私有字段来传递NAT规则，避免对tcp包长度的破坏导致seq的破坏，保留了tcp的高可靠性。并且通过ip opt和tcp opt探测来测试网络对私有拓展信息的穿透性，保证了NAT规则的成功学习。在nat的基础上叠加安全特性，比原始的网关nat方案增加了安全，保护了网关之间数据传输的安全。本实施例还允许使用不同的协议进行可靠性叠加，包括但不限于QUIC、RUDP(可靠用户数据报协议)、RTP(实时传输协议)、UDT(基于UDP的数据传输协议)等。

本实施例通过数据包协调NAT规则，将隧道内session跟隧道外session进行一一映射，实现公网环境中多session运行，隧道内多session运行，解决公网单会话带来的封堵问题。只需要在NAT规则学习阶段进行协商，有安全需求的会话携带安全参数，无安全需求的会话不需要携带安全参数，不会增加额外数据。也就是说：数据处理要求根据实际传输需求可有可无。

下面对本申请实施例提供的一种数据传输装置进行介绍，下文描述的一种数据传输装置与上文描述的一种数据传输方法可以相互参照。

参见图5所示，本申请实施例公开了一种数据传输装置，应用于第一转发端，包括：

获取模块501，用于获取需发送至第二转发端的第一报文；

确定模块502，用于确定与第二转发端协商的数据传输规则；数据传输规则包括：内网会话与公网会话的映射关系、第二转发端与第一转发端均适用的传输协议、第二转发端与第一转发端均适用的数据处理要求；

封装模块503，用于根据数据传输规则封装第一报文，得到第二报文；

发送模块504，用于发送第二报文至第二转发端。

在一种实施方式中，确定模块具体用于：

以第二转发端的标识信息为查询关键字，在预设数据库中查询数据传输规则；

将与标识信息对应的数据传输规则确定为第一转发端与第二转发端协商的数据传输规则。

在一种实施方式中，确定模块还用于：

若不存在数据传输规则，则与第二转发端协商确定数据传输规则。

在一种实施方式中，确定模块还用于：

在原通信报文中添加所述第一转发端的第一要求，获得新通信报文；所述第一要求包括：所述第一转发端所在局域网中的终端IP地址及终端端口号、所述第一转发端的内网IP地址及内网端口号、所述第一转发端适用的至少一种传输协议和至少一种数据处理要求；

发送所述新通信报文至所述第二转发端，以使所述第二转发端解析所述新通信报文得到所述第一要求，若确认能够满足所述第一要求，则基于所述第一要求和第二端确认要求生成并记录所述数据传输规则，并在原确认报文中添加所述第二端确认要求，得到新确认报文；所述第二端确认要求包括：所述第二转发端的公网IP地址、公网端口号、所述第二转发端与所述第一转发端均适用的传输协议、所述第二转发端与所述第一转发端均适用的数据处理要求；

接收所述第二转发端发送的所述新确认报文，解析所述新确认报文得到所述第二端确认要求；

基于所述第一要求和所述第二端确认要求生成并记录所述数据传输规则。

在一种实施方式中，原通信报文为握手报文；相应地，确定模块还用于：在握手报文的拓展选项和/或紧急信息选项中添加第一要求；

原确认报文为握手报文的握手确认报文；相应地，确定模块还用于：在握手确认报文的拓展选项和/或紧急信息选项中添加第二端确认要求。

在一种实施方式中，原通信报文为传输数据之前预设的信息协商报文；确定模块还用于：在信息协商报文的载荷选项中添加第一要求；

原确认报文为信息协商报文的协商确认报文；确定模块还用于：在协商确认报文的载荷选项中添加第二端确认要求。

在一种实施方式中，确定模块还用于：

若接收到报错报文，且确认存在第一转发端适用的、不在第一要求中的其他传输协议和其他数据处理要求，则用其他传输协议和其他数据处理要求替换第一要求中的传输协议和数据处理要求，并执行在原通信报文中添加第一转发端的第一要求及后续步骤；

其中，第二转发端若确认不能满足第一要求，则生成报错报文，并发送报错报文至第一转发端。

在一种实施方式中，还包括：

报错模块，用于若接收到报错报文，且确认不存在第一转发端适用的、不在第一要求中的其他传输协议和其他数据处理要求，则返回错误通知信息至第一报文的发送端。

在一种实施方式中，第二转发端与第一转发端均适用的传输协议包括：HTTPS、UDP和IPSEC；第二转发端与第一转发端均适用的数据处理要求包括：加密要求、数据完整性检测要求和身份认证要求。

其中，关于本实施例中各个模块、单元更加具体的工作过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

可见，本实施例提供了一种数据传输装置，该装置使隧道内会话与公网会话一对一，解决远程访问过程中的流量封堵现象。

下面对本申请实施例提供的一种电子设备进行介绍，下文描述的一种电子设备与上文描述的一种数据传输方法及装置可以相互参照。

参见图6所示，本申请实施例公开了一种电子设备，包括：

存储器601，用于保存计算机程序；

处理器602，用于执行所述计算机程序，以实现上述任意实施例公开的方法。

请参考图7，图7为本实施例提供的另一种电子设备示意图，该电子设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processingunits，CPU)322(例如，一个或一个以上处理器)和存储器332，一个或一个以上存储应用程序342或数据344的存储介质330(例如一个或一个以上海量存储设备)。其中，存储器332和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对数据处理设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储介质330通信，在电子设备301上执行存储介质330中的一系列指令操作。

电子设备301还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作***341。例如，Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等。

在图7中，应用程序342可以是执行数据传输方法的程序，数据344可以是执行数据传输方法所需的或产生的数据。

上文所描述的数据传输方法中的步骤可以由电子设备的结构实现。

下面对本申请实施例提供的一种可读存储介质进行介绍，下文描述的一种可读存储介质与上文描述的一种数据传输方法、装置及设备可以相互参照。

一种可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的数据传输方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本申请涉及的“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法或设备固有的其它步骤或单元。

需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的可读存储介质中。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种数据传输方法，其特征在于，应用于第一转发端，包括：

获取第一报文；所述第一报文的目的端为第二转发端；

确定与所述第二转发端协商的数据传输规则；所述数据传输规则包括：所述第一转发端与所述第一报文的发送端形成的会话、所述第一转发端与所述第二转发端形成的会话的映射关系；

根据所述数据传输规则封装所述第一报文，得到第二报文；

发送所述第二报文至所述第二转发端。

2.根据权利要求1所述的数据传输方法，其特征在于，所述确定与所述第二转发端协商的数据传输规则，包括：

以所述第二转发端的标识信息为查询关键字，在预设数据库中查询所述数据传输规则；

将与所述标识信息对应的数据传输规则确定为所述第一转发端与所述第二转发端协商的数据传输规则。

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

若不存在所述数据传输规则，则与所述第二转发端协商确定所述数据传输规则。

4.根据权利要求3所述的数据传输方法，其特征在于，所述与所述第二转发端协商确定所述数据传输规则，包括：

在原通信报文中添加所述第一转发端的第一要求，获得新通信报文；所述第一要求包括：所述第一转发端所在局域网中的终端IP地址及终端端口号、所述第一转发端的内网IP地址及内网端口号；

发送所述新通信报文至所述第二转发端，以使所述第二转发端解析所述新通信报文得到所述第一要求，若确认能够满足所述第一要求，则基于所述第一要求和第二端确认要求生成并记录所述数据传输规则，并在原确认报文中添加所述第二端确认要求，得到新确认报文；所述第二端确认要求包括：所述第二转发端的公网IP地址和公网端口号；

接收所述第二转发端发送的所述新确认报文，解析所述新确认报文得到所述第二端确认要求；

基于所述第一要求和所述第二端确认要求生成并记录所述数据传输规则。

5.根据权利要求4所述的数据传输方法，其特征在于，

所述原通信报文为握手报文；相应地，所述在原通信报文中添加所述第一转发端的第一要求，包括：在所述握手报文的拓展选项和/或紧急信息选项中添加所述第一要求；

所述原确认报文为所述握手报文的握手确认报文；相应地，所述在原确认报文中添加所述第二端确认要求，包括：在所述握手确认报文的拓展选项和/或紧急信息选项中添加所述第二端确认要求；

所述原通信报文为传输数据之前预设的信息协商报文；相应地，所述在原通信报文中添加所述第一转发端的第一要求，包括：在所述信息协商报文的载荷选项中添加所述第一要求；

所述原确认报文为所述信息协商报文的协商确认报文；相应地，所述在原确认报文中添加所述第二端确认要求，包括：在所述协商确认报文的载荷选项中添加所述第二端确认要求。

6.根据权利要求4所述的数据传输方法，其特征在于，所述数据传输规则还包括：所述第二转发端与所述第一转发端均适用的传输协议、所述第二转发端与所述第一转发端均适用的数据处理要求；

相应地，所述第一要求还包括：所述第一转发端适用的至少一种传输协议和至少一种数据处理要求；

相应地，所述第二端确认要求还包括：所述第二转发端与所述第一转发端均适用的传输协议、所述第二转发端与所述第一转发端均适用的数据处理要求；

相应地，还包括：

若接收到报错报文，且确认存在所述第一转发端适用的、不在所述第一要求中的其他传输协议和其他数据处理要求，则用其他传输协议和其他数据处理要求替换所述第一要求中的传输协议和数据处理要求，并执行在原通信报文中添加所述第一转发端的第一要求及后续步骤；其中，所述第二转发端若确认不能满足所述第一要求，则生成所述报错报文，并发送所述报错报文至所述第一转发端。

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

若接收到所述报错报文，且确认不存在所述第一转发端适用的、不在所述第一要求中的其他传输协议和其他数据处理要求，则返回错误通知信息至所述目标报文的发送端。

8.一种数据传输装置，其特征在于，应用于第一转发端，包括：

获取模块，用于获取第一报文；所述第一报文的目的端为第二转发端；

确定模块，用于确定与所述第二转发端协商的数据传输规则；所述数据传输规则包括：所述第一转发端与所述第一报文的发送端形成的会话、所述第一转发端与所述第二转发端形成的会话的映射关系；

封装模块，用于根据所述数据传输规则封装所述第一报文，得到第二报文；

发送模块，用于发送所述第二报文至所述第二转发端。

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

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序，以实现如权利要求1至7任一项所述的数据传输方法。

10.一种可读存储介质，其特征在于，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的数据传输方法。