CN112291181B - 一种基于多网卡的数据传输方法以及相关装置 - Google Patents
一种基于多网卡的数据传输方法以及相关装置 Download PDFInfo
- Publication number
- CN112291181B CN112291181B CN201910666801.4A CN201910666801A CN112291181B CN 112291181 B CN112291181 B CN 112291181B CN 201910666801 A CN201910666801 A CN 201910666801A CN 112291181 B CN112291181 B CN 112291181B
- Authority
- CN
- China
- Prior art keywords
- network
- data
- network card
- server
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请公开了一种基于多网卡的数据传输方法,当通过第一网卡连接至第一网络时,通过第二网络向服务器发送连接建立请求,连接建立请求携带第二网卡的网卡信息,连接建立请求用于请求服务器与客户端建立Socket连接,第二网卡用于连接至第二网络,第二网卡与第一网卡为部署于同一个终端设备中不同的网卡;当Socket连接建立成功时,根据第二网卡的网卡信息生成数据传输请求;通过第二网络向服务器发送数据传输请求,数据传输请求用于请求业务数据;通过第二网络接收服务器发送的业务数据。本申请还公开了一种客户端以及终端设备。本申请使得客户端具有同时连接多个网络的能力,无需用户手动切换网络,不但减少了操作的复杂度,还提升了网络传输的效率。
Description
技术领域
本申请涉及互联网技术领域,尤其涉及一种基于多网卡的数据传输方法以及相关装置。
背景技术
随着现代生活水平不断提高和社会经济的不断发展,人们对移动通信的要求越来越高。终端设备和无线通信工具(比如无线局域网以及无线调制解调器)的不断发展,促使人们对高速率的无线网络通信需求增加,刺激了无线通信的发展。
目前,终端设备通常支持与多类网络进行通信,比如,当无线保真(WirelessFidelity,WiFi)网络不稳定时,可以手动切换至第四代移动通信技术(the 4thGeneration mobile communication technology,4G)网络进行通信,或者,当4G网络不稳定时,可以手动切换至WiFi网络进行通信。
然而,终端设备不能保证每一次连接的网络都能够正常使用,因此,往往需要用户手动进行多次网络切换,不仅增加了操作的复杂度,而且还降低了网络传输的效率。
发明内容
本申请实施例提供了一种基于多网卡的数据传输方法以及相关装置,使得客户端具有同时连接多个网络的能力,无需用户手动切换网络,不但减少了操作的复杂度,还提升了网络传输的效率。
有鉴于此,本申请一个方面提供一种基于多网卡的数据传输方法,当通过第一网卡连接至第一网络时,所述方法包括:
通过第二网络向服务器发送连接建立请求,其中,所述连接建立请求携带第二网卡的网卡信息,所述连接建立请求用于请求所述服务器与客户端建立套接字Socket连接,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡;
当所述Socket连接建立成功时,根据所述第二网卡的网卡信息生成数据传输请求;
通过所述第二网络向所述服务器发送所述数据传输请求,其中,所述数据传输请求用于请求业务数据;
通过所述第二网络接收所述服务器发送的所述业务数据。
本申请另一个方面提供一种客户端,当通过第一网卡连接至第一网络时,所述客户端包括:
发送模块,用于通过第二网络向服务器发送连接建立请求,其中,所述连接建立请求携带第二网卡的网卡信息,所述连接建立请求用于请求所述服务器与客户端建立套接字Socket连接,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡;
生成模块,用于当所述Socket连接建立成功时,根据所述第二网卡的网卡信息生成数据传输请求;
所述发送模块,还用于通过所述第二网络向所述服务器发送所述生成模块生成的所述数据传输请求,其中,所述数据传输请求用于请求业务数据;
接收模块,用于通过所述第二网络接收所述服务器发送的所述业务数据。
在一种可能的设计中,所述客户端还包括检测模块以及执行模块;
所述检测模块,用于在所述发送模块通过第二网络向服务器发送连接建立请求之前,检测所述第一网络的网络状态是否满足网络重连条件;
所述执行模块,用于若所述检测模块检测得到所述第一网络的网络状态满足所述网络重连条件,则执行所述通过第二网络向服务器发送连接建立请求的步骤;
所述接收模块,还用于若所述检测模块检测得到所述第一网络的网络状态未满足所述网络重连条件,则通过所述第一网络接收所述服务器发送的所述业务数据。
在一种可能的设计中,所述客户端还包括执行模块;
所述接收模块,还用于在所述发送模块通过第二网络向服务器发送连接建立请求之前,接收网络切换指令,其中,所述网络切换指令中携带所述第二网络的标识;
所述执行模块,用于响应于所述接收模块接收的所述网络切换指令,根据所述第二网络的标识,执行所述通过第二网络向服务器发送连接建立请求的步骤。
在一种可能的设计中,所述客户端还包括获取模块;
所述获取模块,用于在所述生成模块根据所述第二网卡的网卡信息生成数据传输请求之前,获取至少一个应用程序编程接口API;
所述获取模块,还用于通过所述至少一个API获取所述第二网卡的网卡信息,其中,所述第二网卡的网卡信息包括所述第二网卡的网卡类型以及所述第二网卡的网际互联协议IP地址。
在一种可能的设计中,所述客户端还包括判断模块以及执行模块;
所述判断模块,用于在所述获取模块通过所述至少一个API获取所述第二网卡的网卡信息之后,判断所述第二网卡的网卡类型是否属于预设网卡类型;
所述执行模块,还用于若所述判断模块判断得到所述第二网卡的网卡类型属于所述预设网卡类型,则执行所述根据所述第二网卡的网卡信息生成数据传输请求的步骤;
所述接收模块,还用于若所述判断模块判断得到所述第二网卡的网卡类型不属于所述预设网卡类型,则通过所述第一网络接收所述服务器发送的所述业务数据。
在一种可能的设计中,所述发送模块,具体用于若所述第二网络的连接类型为超文本传输协议HTTP连接,则通过所述第二网络向所述服务器的第一预设端口发送所述连接建立请求,以使所述服务器通过所述第一预设端口与所述客户端建立Socket连接;
若所述第二网络的连接类型为安全超文本传输协议HTTPS连接,则通过所述第二网络向所述服务器的第二预设端口发送所述连接建立请求,以使所述服务器通过所述第二预设端口与所述客户端建立Socket连接。
在一种可能的设计中,所述生成模块,具体用于生成Socket传输请求,其中,所述Socket传输请求携带第一头部信息以及请求数据;
将所述第二网卡的网卡信息添加至所述第一头部信息,得到第二头部信息;
根据所述第二头部信息以及所述请求数据,生成所述数据传输请求。
在一种可能的设计中,所述接收模块,具体用于通过所述第二网络接收服务器发送的待解析业务数据,其中,所述待解析业务数据包括第一分隔符以及第二分隔符,所述第一分隔符用于分割待解析状态数据与待解析头部数据,所述第二分隔符用于分割所述待解析头部数据与待解析主体数据;
根据所述第一分隔符以及所述第二分隔符,对所述待解析业务数据进行解析,得到所述业务数据。
在一种可能的设计中,所述接收模块,具体用于根据所述第一分隔符获取所述待解析状态数据;
对所述待解析状态数据进行解析,得到状态数据;
若根据所述状态数据确定所述客户端的所述数据传输请求已发起成功,则根据所述第二分隔符获取所述待解析头部数据以及所述待解析主体数据;
对所述待解析头部数据进行解析,得到头部数据;
若所述待解析主体数据为二进制数据,则根据所述头部数据获取所述业务数据;
若所述待解析主体数据不为二进制数据,则获取所述业务数据。
在一种可能的设计中,所述客户端还包括获取模块以及确定模块;
所述获取模块,用于在所述接收模块通过所述第二网络接收所述服务器发送的所述业务数据之后,从所述业务数据中获取第一验证信息;
所述确定模块,用于根据所述业务数据确定第二验证信息;
所述确定模块,还用于若所述获取模块获取的所述第一验证信息与所述第二验证信息一致,则确定所述业务数据为合法数据;
所述确定模块,还用于若所述获取模块获取的所述第一验证信息与所述第二验证信息不一致,则确定所述业务数据为非法数据。
本申请另一个方面提供一种终端设备,当所述终端设备通过第一网卡连接至第一网络时,所述终端设备包括:存储器、收发器、处理器以及总线系统;
其中,所述存储器用于存储程序;
所述处理器用于执行所述存储器中的程序,包括如下步骤:
通过第二网络向服务器发送连接建立请求,其中,所述连接建立请求携带第二网卡的网卡信息,所述连接建立请求用于请求所述服务器与客户端建立套接字Socket连接,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡;
当所述Socket连接建立成功时,根据所述第二网卡的网卡信息生成数据传输请求;
通过所述第二网络向所述服务器发送所述数据传输请求,其中,所述数据传输请求用于请求业务数据;
通过所述第二网络接收所述服务器发送的所述业务数据;
所述总线系统用于连接所述存储器以及所述处理器,以使所述存储器以及所述处理器进行通信。
本申请的另一个方面提供了一种计算机可读存储介质,计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述各方面的方法。
从以上技术方案可以看出,本申请实施例具有以下优点:
本申请实施例中,提供了一种基于多网卡的数据传输方法,当通过第一网卡连接至第一网络时,客户端可以通过第二网络向服务器发送连接建立请求,其中,连接建立请求携带第二网卡的网卡信息,第二网卡与第一网卡为部署于同一个终端设备中不同的网卡,当Socket连接建立成功时,客户端根据第二网卡的网卡信息生成数据传输请求,然后通过第二网络向服务器发送数据传输请求,最后,客户端通过第二网络接收服务器发送的业务数据。通过上述方式,客户端与服务器建立Socket连接后,由于Socket连接建立在传输层上,因此,可以在传输层上对数据传输请求进行封装,以加入第二网卡的网卡信息,在客户端连接至第一网络的情况下,同时通过第二网络接收服务器下发的业务数据,从而使得客户端具有同时连接多个网络的能力,无需用户手动切换网络,不但减少了操作的复杂度,还提升了网络传输的效率。
附图说明
图1为本申请实施例中数据传输系统的一个架构示意图;
图2为本申请应用场景中网络连接方式的一个架构示意图;
图3为本申请实施例中基于多网卡的数据传输方法一个实施例示意图;
图4为本申请实施例中网络互连的一个四层架构示意图;
图5为本申请实施例中网络互连的一个七层架构示意图;
图6为本申请实施例中基于多路传输控制协议MPTCP的一个网络架构示意图;
图7为本申请实施例中客户端展示业务数据的一个界面示意图;
图8为本申请实施例中拉取业务数据的一个流程示意图;
图9为本申请实施例中触发网络切换指令的一个界面示意图;
图10为本申请应用场景中数据传输请求的一个头部信息示意图;
图11为本申请应用场景中基于头部信息展示业务数据的一个界面示意图;
图12为本申请实施例中待解析业务数据的一个格式示意图;
图13为本申请实施例中业务数据的一个解析流程示意图;
图14为本申请实施例中基于多网卡的数据传输方法一个整体流程示意图;
图15为本申请实施例中客户端的一个实施例示意图;
图16为本申请实施例中客户端的另一个实施例示意图;
图17为本申请实施例中客户端的另一个实施例示意图;
图18为本申请实施例中客户端的另一个实施例示意图;
图19为本申请实施例中客户端的另一个实施例示意图;
图20为本申请实施例中客户端的另一个实施例示意图;
图21为本申请实施例中终端设备的一个结构示意图。
具体实施方式
本申请实施例提供了一种基于多网卡的数据传输方法以及相关装置,使得客户端具有同时连接多个网络的能力,无需用户手动切换网络,不但减少了操作的复杂度,还提升了网络传输的效率。
本申请的说明书和权利要求书及上述附图中的术语“第二”、“第一”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“对应于”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应理解,本申请提供的数据传输方法可以应用于多链路并行通信的场景,具体可以应用于包括多个网卡的终端设备,该终端设备上运行有客户端,需要说明的是,存在至少一个客户端能够通过指定网卡与服务器建立通信连接,而其他客户端可以通过其他网卡与服务器建立通信连接,从而实现多网卡并行通信的目标。比如,一个客户端在多网卡共存状态下,例如无线保真(Wireless Fidelity,WiFi)网络与第四代移动通信技术(the 4thGeneration mobile communication technology,4G)网络共存时,在应用内部选择不同的网卡进行不同的网络请求,实现多链路并行,提高一定时间内的网络利用率,实现网络分流,并进一步提高网络请求的成功率。
为了便于理解,本申请提出了一种基于多网卡的数据传输方法,该方法应用于图1所示的数据传输系统,请参阅图1,图1为本申请实施例中数据传输系统的一个架构示意图,如图所示,一个终端设备中可以部署多个网卡,网卡又可以称为网络接口控制器(networkinterface controller,NIC),网卡是非常重要的连接设备,计算机主要通过网卡连接网络。在网络中,网卡的工作是双重的。一方面它负责接收网络上传过来的数据包,解包后将数据通过主板上的总线传输给本地计算机。另一方面它将本地计算机上的数据打包后送入网络。每个网卡拥有其对应的介质访问控制(Media Access Control,MAC)。终端设备上安装有至少一个支持通过指定网卡接入对应网络的客户端,从而实现客户端与服务器的通信。以图1为例,假设终端设备上安装有客户端A和客户端B,其中,客户端A可以通过网卡A接入网络A,实现与应用服务器A的数据传输。客户端B可以通过网卡B接入网络B,实现与应用服务器B的数据传输。
需要说明的是,终端设备包含但不仅限于平板电脑、笔记本电脑、掌上电脑、手机、语音交互设备及个人电脑(personal computer,PC),此处不做限定。其中,语音交互设备包含但不仅限于智能音响以及智能家电。客户端具体可以表现为应用程序或者应用平台。服务器可以是一个服务器,也可以是服务器集群,此处不做限定。
为了便于说明,请参阅图2,图2为本申请应用场景中网络连接方式的一个架构示意图,如图所示,以用户甲持有的终端设备A为例,假设终端设备A同时具有WiFi网卡和4G网卡,用户甲需要在工作的环境下连接固定的局域网,于是在主网卡连接局域网的情况下,其他网卡仍正常访问广域网,也即是在工作的时候用户甲使用的终端设备A连接WiFi网络,同时终端设备A中的“开心小游戏”客户端通过蜂窝网络访问广域网,使得工作生活两不误。
其中,广域网(Wide Area Network,WAN)通常跨接很大的物理范围,所覆盖的范围从几十公里到几千公里,它能连接多个城市或国家,或横跨几个洲并能提供远距离通信,形成国际性的远程网络。广域网的通信子网主要使用分组交换技术。广域网的通信子网可以利用公用分组交换网、卫星通信网和无线分组交换网,它将分布在不同地区的局域网或计算机系统互连起来,达到资源共享的目的。
局域网(Local Area Network,LAN)是指在某一区域内由多台计算机互联成的计算机组。一般是方圆几千米以内。局域网可以实现文件管理、应用软件共享、打印机共享、工作组内的日程安排、电子邮件和传真通信服务等功能。局域网是封闭型的,可以由办公室内的两台计算机组成,也可以由一个公司内的上千台计算机组成。
结合上述介绍,下面将对本申请中基于多网卡的数据传输方法进行介绍,请参阅图3,本申请实施例提供一种基于多网卡的数据传输方法,该方法应用于客户端,该客户端部署于终端设备上,当该终端设备通过第一网卡连接至第一网络时,基于多网卡的数据传输方法包括:
101、通过第二网络向服务器发送连接建立请求,其中,连接建立请求携带第二网卡的网卡信息,连接建立请求用于请求服务器与客户端建立套接字Socket连接,第二网卡用于连接至第二网络,第二网卡与第一网卡为部署于同一个终端设备中不同的网卡;
本实施例中,终端设备上可以安装有至少一个客户端,假设仅存在一个客户端,那么在终端设备通过第一网卡连接至第一网络的情况下,该客户端可以通过第二网卡连接至第二网络。也就是说,客户端可以自主通过指定网卡连接指定网络,独立于终端设备的系统,将本申请提供的数据传输方法集成于客户端,配合不同的产品即可完成相应的功能。
假设存在多个客户端,那么在终端设备的客户端A通过第一网卡连接至第一网络的情况下,在终端设备的客户端B可以通过第二网卡连接至第二网络,其中,第一网卡与第二网卡为部署于同一个终端设备中不同的网卡,第一网络和第二网络属于两种不同类型的网络,比如,第一网卡可以是WiFi网卡,第一网络即为WiFi网络,第二网卡可以是4G网卡,第二网络即为4G网络。具体地,客户端采用第二网卡,通过第二网络向服务器发送连接建立请求,该连接建立请求可以是套接字(Socket)连接请求,在连接建立请求携带第二网卡的网卡信息,使得服务器根据第二网卡的网卡信息确定客户端需要通过第二网络建立连接。
可以理解的是,本申请采用的网络互联架构可以是四层架构,也可以是七层架构,为了便于理解,请参阅图4,图4为本申请实施例中网络互连的一个四层架构示意图,如图所示,四层架构为传输控制协议(Transmission Control Protocol,TCP)/网际互联协议(Internet Protocol Address,IP)族模型,其中,TCP/IP协议族模型按层次分别为应用层、传输层、网络层和数据链路层。下面将对各个层进行介绍:
应用层决定了向用户提供应该服务时通信的活动,HTTP协议也处于该层。
传输层对应用层提供处于网络连接中两台计算机之间的数据传输。
网络层用于处理在网络上流动的数据包。
数据链路层用于处理连接网络的硬件部分。
请参阅图5,图5为本申请实施例中网络互连的一个七层架构示意图,如图所示,七层架构为开放式系统互联(Open System Interconnect,OSI)网络架构模型,其中,OSI网络架构模型按层次分别为应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。下面将对各个层进行介绍:
应用层是用户与网络的接口。该层通过应用程序来完成网络用户的应用需求,如文件传输以及收发电子邮件等。
表示层处理流经结点的数据编码的表示方式问题,以保证一个系统应用层发出的信息可被另一系统的应用层读出。
会话层主要功能是管理和协调不同主机上各种进程之间的通信,即负责建立、管理和终止应用程序之间的会话。
传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务,包括处理差错控制和流量控制等问题。
网络层是为传输层提供服务的,传送的协议数据单元称为数据包或分组。
数据链路层是为网络层提供服务的,解决两个相邻结点之间的通信问题。
物理层利用传输介质为数据链路层提供物理连接。
无论是OSI网络架构模型还是TCP/IP协议族模型,每一层实现各自的功能和协议,并完成与相邻层的接口通信。
102、当Socket连接建立成功时,根据第二网卡的网卡信息生成数据传输请求;
本实施例中,服务器在接收到客户端发送的连接建立请求之后,响应于该连接建立请求,并且可以与客户端建立Socket连接,然后客户端可以根据第二网卡的网卡信息,在传输层上生成一个数据传输请求,其中,这里生成的数据传输请求是通过应用层发送至服务器的,从而使得服务器在收到该数据传输请求之后,能够进行相应的处理。
其中,网络上的两个程序通过一个双向的通信连接实现数据的交换,这个连接的一端称为一个Socket。
103、通过第二网络向服务器发送数据传输请求,其中,数据传输请求用于请求业务数据;
本实施例中,客户端在生成数据传输请求之后,通过第二网络向服务器发送该数据传输请求。具体地,终端设备与服务器是通过网络层的TCP来完成多链路的并行操作。为了便于即,请参阅图6,图6为本申请实施例中基于多路传输控制协议MPTCP的一个网络架构示意图,如图所示,基于多路传输控制协议(MultiPath TCP,MPTCP),允许在一条TCP链路中建立多个子通道。当一条通道按照三次握手的方式建立起来后,可以按照三次握手的方式建立其他的子通道,这些通道以三次握手建立连接和四次挥手解除连接。这些通道都会绑定于MPTCP会话,发送端的数据可以选择其中一条通道进行传输。其中,MPTCP由互联网工程任务组(The Internet Engineering Task Force,IETF)的MPTCP工作组研发,其目的是允许TCP连接使用多个路径来最大化信道资源使用。
104、通过第二网络接收服务器发送的业务数据。
本实施例中,客户端向服务器发送数据传输请求之后,该服务器可以响应于数据传输请求,然后向客户端发送业务数据,可以理解的是,业务数据包含但不仅限于图片数据、视频数据、音频数据以及其他的网络资源。下面将以业务数据为图片数据为例进行介绍,请参阅图7,图7为本申请实施例中客户端展示业务数据的一个界面示意图,如图所示,用户甲使用手机上安装的“小信鸽”应用程序与用户乙传送短消息,此时,“小信鸽”应用程序是通过手机上的4G网卡接入4G网络,再通过4G网络向用户乙传送短消息。此时,用户甲又在该手机上开启了“WiFi小管家”应用程序,于是“WiFi小管家”应用程序可以通过手机上的WiFi网卡接入WiFi网络,在通过WiFi网络拉取图片数据,即在“WiFi小管家”应用程序上展示“点我来领红包吧”的图片,以及“第二份半价”的图片。
本申请实施例中,提供了一种基于多网卡的数据传输方法,当通过第一网卡连接至第一网络时,客户端可以通过第二网络向服务器发送连接建立请求,其中,连接建立请求携带第二网卡的网卡信息,第二网卡与第一网卡为部署于同一个终端设备中不同的网卡,当Socket连接建立成功时,客户端根据第二网卡的网卡信息生成数据传输请求,然后通过第二网络向服务器发送数据传输请求,最后,客户端通过第二网络接收服务器发送的业务数据。通过上述方式,客户端与服务器建立Socket连接后,由于Socket连接建立在传输层上,因此,可以在传输层上对数据传输请求进行封装,以加入第二网卡的网卡信息,在客户端连接至第一网络的情况下,同时通过第二网络接收服务器下发的业务数据,从而使得客户端具有同时连接多个网络的能力,无需用户手动切换网络,不但减少了操作的复杂度,还提升了网络传输的效率。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,通过第二网络向服务器发送连接建立请求之前,还可以包括:
检测第一网络的网络状态是否满足网络重连条件;
若第一网络的网络状态满足网络重连条件,则执行通过第二网络向服务器发送连接建立请求的步骤;
若第一网络的网络状态未满足网络重连条件,则通过第一网络接收服务器发送的业务数据。
本实施例中,介绍了一种客户端主动连接第二网络的方法。即客户端需要主动判断当前终端设备使用的第一网络的网络状态是否达到网络重连条件,如果满足网络重连条件,那么客户端就可以向服务器请求连接第二网络,如果没有满足网络重连条件,那么客户端继续使用第一网络与服务器进行通信。
可以理解的是,网络重连条件可以是心跳超时和回包超时,心跳超时和回包超时即客户端每间隔一定时间(比如15秒)通过第一网络向服务器发送一次请求,从而判断对方是否存活,如果客户端发送请求成功后,长久(比如60秒)为收到服务器的响应,则认为第一网络不稳定,也就达到了网络重连条件。网络重连条件也可以是网络延迟,通常可以采用两种方式评估延迟,分别为信号强度(received signal strength indication,RSSI)估计和收发包时间统计,如果RSSI低于预设门限,则表示满足网络重连条件,或,基于过往的数据包计算平均网络延迟,如果网络延迟大于预设门限,则表示满足网络重连条件。
为了便于理解,请参阅图8,图8为本申请实施例中拉取业务数据的一个流程示意图,如图所示,具体地:
在步骤S1中,客户端接收用户通过终端设备触发的业务请求,该业务请求可以是拉取图片的请求;
在步骤S2中,客户端判断终端设备当前是否连接WiFi网络,若连接了WiFi网络,则执行步骤S3,若未连接WiFi网络,则跳转至步骤S6;
在步骤S3中,在终端设备已连接WiFi网络的情况下,客户端判断当前连接的WiFi网络是否需要重试,即检测WiFi网络的网络状态是否满足网络重连条件,若满足网络重连条件,则执行步骤S4,若未满足网络重连条件,则跳转至步骤S5;
在步骤S4中,在WiFi网络满足网络重连条件的情况下,客户端判断当前终端设备是否存在多个网卡,若存在多个网卡,则进入步骤S7,若不存在多个网卡,则跳转至步骤S5;
在步骤S5中,在WiFi网络未满足网络重连条件的情况下,客户端可以继续基于WiFi网络拉取图片资源,或者,在终端设备不存在多个网卡的情况下,客户端也可以继续基于WiFi网络拉取图片资源;
在步骤S6中,在终端设备未连接WiFi网络的情况下,客户端可以通过无线广域网(Wireless Wide Area Network,WWAN)拉取图片资源;
在步骤S7中,在终端设备存在多个网卡的情况下,客户端可以通过WWAN网卡与服务器建立新的通信连接;
在步骤S8中,客户端模拟数据传输请求,并且在模拟的数据传输请求中配置相关的请求数据,比如业务数据的格式以及类型等;
在步骤S9中,客户端通过WWAN网络向服务器发送模拟得到的数据传输请求;
在步骤S10中,客户端判断当前业务请求所请求的图片是否拉取成功,如果已经拉取到图片,则进入步骤S11,如果未拉取到所需图片,则再次执行步骤S2所对应的流程;
在步骤S11中,结束用户发起的业务请求。
由此可见,本申请通过多链路拉取网络资源的方式运用到应用中,可以很大程度上提升拉取资源的成功率,尤其是针对于终端设备连接了弱WiFi网络,或无WiFi网络的情况下,绝大多数终端设备没有能力判断当前WiFi网络是否能够正常使用的,因此也无法给终端设备提供一种稳定的网络环境。而不同于WiFi网络,WWAN网络相对稳定很多,绝大多数WWAN网络都会处于一个相对稳定的状态,因此多链路的使用,可以有效的给终端设备提供一个稳定的网络环境,尤其是针对于网络需求非常高的应用而言,更是至关重要。
之所以没有一开始就选择使用WWAN去拉取资源,是为了将用户的流量损耗降到最低,如果有特殊的业务需求,也可以考虑最开始就采用WWAN去拉取资源,此次仅为一个示意,图8所示的流程仅为一个示意,不应理解为对本申请的限定。
其次,本申请实施例中,提供了一种客户端主动连接第二网络的方案,即客户端先检测第一网络的网络状态是否满足网络重连条件,若第一网络的网络状态满足网络重连条件,则通过第二网络向服务器发送连接建立请求,反之,则继续通过第一网络接收服务器发送的业务数据。通过上述方式,可以实现用户无感知的网络切换方案,客户端能够根据实时的网络状态选择合理的数据传输方式,一方面能够节省网络切换的时间,另一方面能够更高效地应用不同网络下的网络资源,从而提升方案的灵活性。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,通过第二网络向服务器发送连接建立请求之前,还可以包括:
接收网络切换指令,其中,网络切换指令中携带第二网络的标识;
响应于网络切换指令,根据第二网络的标识,执行通过第二网络向服务器发送连接建立请求的步骤。
本实施例中,介绍了一种客户端被动连接第二网络的方法。为了便于理解,请参阅图9,图9为本申请实施例中触发网络切换指令的一个界面示意图,如图所示,假设用户甲使用的终端设备已经连接了第一网络(假设为WiFi网络),此时,用户甲又开启终端设备上的“WiFi小管家”客户端,于是在“WiFi小管家”客户端的界面上会展示一个交互对话框,在该交互对话框中显示“需要使用以下哪种网络进行连接?”的提示,用户甲可以通过手动选择其中一种网络进行连接,由于当前已经连接至WiFi网络,那么用户可以点选“4G”这个选项,由此触发网络切换指令,在该网络切换指令中携带第二网络的标识(比如标识为111)。“WiFi小管家”客户端在接收用户触发的网络切换指令之后,即可响应于该网络切换指令,然后根据第二网络的标识,通过第二网络向服务器发送连接建立请求。
可以理解的是,用户也可以选择“WiFi”选项,此时,网络切换指令中携带了第一网络的标识,“WiFi小管家”客户端在接收到该网络切换指令后,可以不对网络切换,即需要使用第一网络向服务器发送连接建立请求。
其次,本申请实施例中,提供了一种客户端被动连接第二网络的方案,即客户端先接收网络切换指令,网络切换指令中携带第二网络的标识,然后响应于网络切换指令,根据第二网络的标识,执行通过第二网络向服务器发送连接建立请求的步骤。通过上述方式,用户可以根据实际需求手动选择希望连接的网络类型,由此,提升方案的灵活性和可操作性,交互操作具有可靠性、易用性和多样性的优势。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,根据第二网卡的网卡信息生成数据传输请求之前,还可以包括:
获取至少一个应用程序编程接口API;
通过至少一个API获取第二网卡的网卡信息,其中,第二网卡的网卡信息包括第二网卡的网卡类型以及第二网卡的网际互联协议IP地址。
本实施例中,提供了一种获取网卡信息的方法,客户端需要在生成数据传输请求之前,获取第二网卡的网卡信息,可以理解的是,客户端能够通过调用应用程序编程接口(Application Programming Interface,API)获取当前终端设备的网卡信息,即客户端不但可以获取第二网卡的网卡信息,还可以获取第一网卡的网卡信息。
具体地,尤尼斯(UNIX)操作系统内核方法暴露了足够的API,由此可以获取终端设备的网卡信息,可以通过内核方法“getifaddrs”获取终端设备中所有网卡的网卡信息,比如包括第一网卡的网卡类型以及第一网卡的IP地址,以及第二网卡的网卡类型以及第二网卡的IP地址,可选地,客户端还可以获取到第一网卡的协议族、第一网卡的媒体访问控制地址(Media Access Control Address,MAC)、第二网卡的协议族以及第二网卡的MAC等。
其中,函数getifaddrs(int getifaddrs(struct ifaddrs**__ifap))能够获取本地网络接口信息,将之存储于链表中,链表头结点指针存储于“__ifap”中带回,函数执行成功返回0,失败返回-1,且为errno(即记录系统的最后一次错误代码)赋值。函数getifaddrs用于获取本机接口信息,比如最典型的获取本机IP地址。
其次,本申请实施例中,提供了一种获取网卡信息的方法,即在客户端根据第二网卡的网卡信息生成数据传输请求之前,还可以获取至少一个API,然后通过至少一个API获取第二网卡的网卡信息,该第二网卡的网卡信息包括第二网卡的网卡类型以及第二网卡的网际互联协议IP地址。通过上述方式,能够灵活地调用不同的API来获取所需的网卡信息,基于不同的应用场景可以调用不同的API,从而获取到不同的网卡信息,由此,提升方案的可行性和可操作性。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,通过至少一个API获取第二网卡的网卡信息之后,还可以包括:
判断第二网卡的网卡类型是否属于预设网卡类型;
若第二网卡的网卡类型属于预设网卡类型,则执行根据第二网卡的网卡信息生成数据传输请求的步骤;
若第二网卡的网卡类型不属于预设网卡类型,则通过第一网络接收服务器发送的业务数据。
本实施例中,介绍了一种检测终端设备中是否存在指定网卡的方法。即通过内核方法“getifaddrs”获取终端设备中第二网卡的网卡信息之后,客户端需要判断该第二网卡的网卡类型是否属于预设网卡类型,假设预设网卡类型为4G网卡类型,如果第二网卡的网卡类型也属于4G网卡类型,那么客户端可以根据第二网卡的网卡信息生成数据传输请求。如果第二网卡的网卡类型属于3G网卡类型,也就是不属于预设网卡类型,则客户端只能继续通过第一网络接收服务器发送的业务数据。
具体地,通过内核方法“getifaddrs”可以获取ifaddrs结构体,ifaddrs结构体提供了每一个网卡所对应的具体网卡信息,比如,是否属于本地环回(loopback)网络,是否为网际协议版本4(Internet Protocol version 4,IPv4),是否为网际协议版本6(InternetProtocol version 6,IPv6)等。因此,就可以利用ifaddrs结构体的信息来确定是否为客户端需要连接的网卡。其中,网卡类型可以采用相应的标识进行标识,比如,标识“en0”对应无线网卡,标识“pdp_ip0”对应蜂窝网卡,此处仅为一个示意,不应理解为对本申请的限定。
客户端需要连接的网卡即为预设网卡类型,也就是客户端执行指定业务的所需网卡,比如在WiFi网络下观看视频有些卡顿,那么可以采用第五代移动通信技术(5thgeneration mobile networks,5G)所对应的网卡来加载视频。
再次,本申请实施例中,提供了一种检测网络连接可行性的方法,即客户端需要判断第二网卡的网卡类型是否属于预设网卡类型,如果是,则根据第二网卡的网卡信息生成数据传输请求,反之,则继续通过第一网络接收服务器发送的业务数据。通过上述方式,客户端会自动检测当前采用的第二网卡是否属于指定网卡,如果不是指定网卡,该客户端就不能采用第二网卡进行网络连接,如此,一方面能够有针对性地连接指定网络,从而有利于提升业务效率,另一方面,避免采用连接至不安全的网络,比如公共网络等,仅对安全可靠的网络进行连接,从而提升方案的安全性。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,通过第二网络向服务器发送连接建立请求,可以包括:
若第二网络的连接类型为超文本传输协议HTTP连接,则通过第二网络向服务器的第一预设端口发送连接建立请求,以使服务器通过第一预设端口与客户端建立Socket连接;
若第二网络的连接类型为安全超文本传输协议HTTPS连接,则通过第二网络向服务器的第二预设端口发送连接建立请求,以使服务器通过第二预设端口与客户端建立Socket连接。
本实施例中,介绍了一种服务器与客户端建立Socket连接的方法,建立Socket连接的可以包括三个步骤,第一个步骤为服务器监听,是服务器的Socket并不定位具体的客户端套接字,而是处于等待连接的状态,实时监控网络状态。第二个步骤为客户端请求,由客户端的Socket发起连接建立请求,要连接的目标是服务器端的Socket。为此,客户端的Socket首先描述它要连接的服务器的Socket,指出服务器端Socket的地址和端口号,然后就向服务器端Socket提出连接请求。第三个步骤为连接确认,当服务器端Socket监听到,或者接收到客户端Socket的连接请求,它就响应客户端Socket的请求,建立一个新的线程,把服务器端Socket的描述发给客户端,一旦客户端确认了此描述,连接就建立完成。而服务器Socket继续处于监听状态,继续接收其他客户端Socket的连接请求。
需要说明的是,在传输层需要通过获取到的网卡IP地址与服务端建立Socket连接。非专属服务端是不会将指定的端口号暴露给外界的,也就是说,如果客户端需访问网站A的网页,而网站A的服务器并不会单独给这个访问请求开设一个新的端口,因此,客户端可以向服务器指定的端口发送连接建立请求,这样可以很大程度上保证Socket连接的成功率。
具体地,如果客户端需要通过超文本传输安全协议(Hypertext TransferProtocol Secure,HTTPS)与服务器建立连接,则客户端需要通过第二网络向服务器的第二预设端口发送连接建立请求,其中,第一预设端口可以为服务器的80端口。如果客户端需要通过超文本传输协议(HyperText Transfer Protocol,HTTP)与服务器建立连接,则客户端需要通过第二网络向服务器的第二预设端口发送连接建立请求,其中,第二预设端口可以为服务器的443端口。
下面将对HTTP和HTTPS进行介绍。HTTP是互联网上应用非常广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准,用于从服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
HTTPS是以安全为目标的HTTP通道,也就是HTTP的安全版,即HTTP下加入安全套接层(Secure Sockets Layer,SSL)层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。
80端口是HTTP的默认端口,可以表示为:
Socket socket=new Socket(InetAddress.getByName(url.getHost()),80);
443端口是HTTPS的默认端口,可以表示为:
Socketsocket=(SSLSocket)((SSLSocketFactory)SSLSocketFactory.getDefault()).createSocket(InetAddress.getByName(url.getHost()),443);
其次,本申请实施例中,提供了一种客户端与服务器建立通信连接的方法,若第二网络的连接类型为HTTP连接,则通过第二网络向服务器的第一预设端口发送连接建立请求,若第二网络的连接类型为HTTPS连接,则通过第二网络向服务器的第二预设端口发送连接建立请求。通过上述方式,能够根据不同网络的连接类型选择合适的连接方式,从而提升方案的可行性和灵活性。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,根据第二网卡的网卡信息生成数据传输请求,可以包括:
生成Socket传输请求,其中,Socket传输请求携带第一头部信息以及请求数据;
将第二网卡的网卡信息添加至第一头部信息,得到第二头部信息;
根据第二头部信息以及请求数据,生成数据传输请求。
本实施例中,介绍了一种生成数据传输请求的方法,其中,该数据传输请求具体可以是HTTP请求或HTTPS请求,由于本申请采用的是非应用层协议,因此,HTTP请求或者HTTPS请求需要通过传输层的Socket基础上进行模拟。之所以需要在传输层上模拟数据传输请求,是因为在应用层上无法封装指定网卡的网卡信息,而在底层可以封装指定网卡的网卡信息,因此可以在传输层上将第二网卡的网卡信息(比如IP地址以及端口)封装到数据传输请求中。
具体地,首先客户端在传输层上生成一个Socket传输请求,在该Socket传输请求中携带第一头部信息以及请求数据,其中,第一头部信息为Socket传输请求中的头部信息,请求数据表示客户端向服务器请求的参数。在封装数据传输请求的过程中,还需要加入第二网卡的网卡信息,从而得到新的头部信息,即得到第二头部信息。最后将第二头部信息以及请求数据进行封装,得到数据传输请求。
在服务器与客户端建立Socket连接之后,通过指定网卡(即第二网卡)模拟HTTP请求或者HTTPS请求,由此使得服务器能够无感知地响应客户端发起的请求。然而,对于外部的服务器可能无法了解到正确的请求参数以及请求头部,因此,还可以通过如下方式查看正确的请求参数以及请求头部。用户可以打开任意浏览器,然后进入开发者模式,接下来在网络(Network)的页面里来查看浏览器发起请求使用的头部字段,最后可以在Socket请求数据中模拟HTTP或HTTPS所使用的相关字段,模拟的方式为配置请求参数。
为了便于理解,下面将以“WiFi小管家”客户端请求拉取图片资源为例进行介绍,请参阅图10,图10为本申请应用场景中数据传输请求的一个头部信息示意图,如图所示,用户在进入Network页面后,可以看到服务器反馈给客户端的业务数据。其中,K1所指示的代码段表示头部数据(Header),K2所指示的代码段表示状态数据(Status Line)。具体地,头部数据的代码可以是:
access-control-allow-origin:*
cache-control:max-age-86400
content-length:8
content-type:image/jpeg
data:Mon,20May 201906:14:12GMT
expires:Tue,21May 201906:14:11GMT
server:NvSs
x-nws-log-uuid:9f9434c5-2c8e-482a-a820-42a8cb858384
其中,access-control-allow-origin这个字段是在服务器响应客户端的时候带上的头部信息。如果设置access-control-allow-origin:*,则允许所有域名的脚本访问该资源。cache-control这个字段用于指定所有缓存机制在整个请求或响应链中服从的指令,如果设置cache-control:max-age-86400,则表示设置静态页面的缓存。content-length这个字段是指头部数据以外的内容长度,如果设置content-length:8,则表示内容长度为8个比特。content-type这个字段表示数据内容,如果设置content-type:image/jpeg,则表示数据内容为联合照片专家组(Joint Photographic Experts Group,JPEG)格式的图像。data这个字段表示生效时间,如果设置data:Mon,20May 201906:14:12GMT,则表示这个请求生效的时间是格林威治时间(Greenwich Mean Time,GMT)2019年5月20日星期一的06时14分12秒。expires这个字段表示失效时间,如果设置expires:Tue,21May 201906:14:11GMT,则表示这个请求失效的时间是2019年5月21日星期二的06时14分11秒。Server表示服务器的标识,如果设置server:NvSs,则表示该服务器的名称为NvSs。x-nws-log-uuid这个字段是登录的唯一标识,如果设置x-nws-log-uuid:9f9434c5-2c8e-482a-a820-42a8cb858384,则表示该登录标识为9f9434c5-2c8e-482a-a820-42a8cb858384。
状态数据的代码可以是:
status:304
其中,status这个字段是指状态代码,如果设置status:304,则表示客户端的缓存资源是最新的,需要客户端使用缓存。
可以理解的是,状态代码还可以包括如下示例,请参阅表1,表1为状态代码与其对应含义之间的一个示意。
表1
状态代码 | 状态代码含义 |
200OK | 服务器成功处理了请求 |
301 | 重定向,请求的统一资源定位器已移走 |
403 | 禁止,请求被服务器拒绝 |
404 | 未找到资源 |
500 | 内部服务器错误,服务器遇到一个错误,使其无法为请求提供服务 |
可以理解的是,表1提供的状态代码以及状态代码的含义仅为一个示意,在实际应用中还存在其他的状态代码,此处不一一进行列举。
当客户端请求之后,服务器会向客户端返回业务数据,请参阅图11,图11为本申请应用场景中基于头部信息展示业务数据的一个界面示意图,如图所示,假设业务数据为图片数据,于是客户端在收到图片数据之后,将对图片数据进行渲染,生成最终可以展示在终端设备界面的上的图片,比如图11所示的“点我来领红包吧”的图片。
其次,本申请实施例中,提供了一种生成数据传输请求的方法,客户端首先生成Socket传输请求,该Socket传输请求携带第一头部信息以及请求数据,然后将第二网卡的网卡信息添加至第一头部信息,得到第二头部信息,最后根据第二头部信息以及请求数据,生成数据传输请求。通过上述方式,客户端能够模拟得到HTTP请求或HTTPS请求,即对Socket传输请求进行重新封装,使得服务器无感知地响应于客户端发起的请求,从而能够在终端设备连接了不合适的无线网络时,还可以有效的保证网络请求正常的进行,在一定程度上保证应用的健壮性。并且在恰当的时机使用多网卡配合工作,可以完成更加复杂的网络请求。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,通过第二网络接收服务器发送的业务数据,可以包括:
通过第二网络接收服务器发送的待解析业务数据,其中,待解析业务数据包括第一分隔符以及第二分隔符,第一分隔符用于分割待解析状态数据与待解析头部数据,第二分隔符用于分割待解析头部数据与待解析主体数据;
根据第一分隔符以及第二分隔符,对待解析业务数据进行解析,得到业务数据。
本实施例中,介绍了一种解析得到业务数据的方法。由于本申请并未采用传统HTTP请求或者HTTPS请求的发送方式,而是基于Socket连接自行模拟数据传输请求,因此,需要模拟HTTP请求或者HTTPS请求进行数据解析。在客户端通过第二网络发送数据传输请求成功之后,服务器会通过第二网络向客户端反馈待解析业务数据。其中,待解析业务数据的格式如图12所示,请参阅图12,图12为本申请实施例中待解析业务数据的一个格式示意图,如图所示,待解析业务数据包括第一分隔符以及第二分隔符,第一分隔符用于分割待解析状态数据(Status Line)与待解析头部数据(Header),第二分隔符用于分割待解析头部数据与待解析主体数据(Body)。即待解析业务数据可以表示为Status Line+Header+Body。
需要说明的是,第一分隔符可以表示为\r\n,第二分隔符可以表示为\r\n\r\n,假设待解析状态数据为AAAAA,待解析头部数据为BBBBB,待解析主体数据CCCCC,于是得到的待解析业务数据格式可以表示为AAAAA\r\n BBBBB\r\n\r\n CCCCC。客户端通过字节解析出第一分隔符“\r\n”来分割待解析状态数据和待解析头部数据,此外,待解析头部数据中的每个不同的字段也是通过“\r\n”来分割的,而待解析头部数据与待解析主体数据需要通过第二分隔符“\r\n\r\n”来分割。待解析业务数据解析后得到状态数据、头部数据以及主体数据,下面将分别对这三个部分进行介绍。
待解析状态数据的结构如下:
Status-Line=HTTP-Version SP Status-Code SP Reason-Phrase CRLF
其中,常见的状态代码(Status-Code)可以包括:
1xx表示信息(Informational),即收到请求,继续处理。
2xx表示成功(Success),即行动已成功接收,理解和接受。
3xx表示重定向(Redirection),即必须采取进一步措施才能完成请求。
4xx表示客户端错误(Client Error),即请求包含错误的语法或无法满足。
5xx表示服务器错误(Server Error),即服务器无法满足明显有效的请求。
头部数据的本质上是一些文本键值对,每个键值对的形式为,Key:空格Value回车换行(Carriage-Return Line-Feed,CRLF)。将若干个上述格式的键值对组合起来,就成了HTTP请求的头部数据。最后一个键值对之后再跟一个CRLF,就表示头部数据结束了。
主体数据里面包含请求的实际数据,比如请求的对象为图片,那么返回主体数据就是图片的二进制数据。实际的业务数据都存放于主体数据当中。
进一步地,本申请实施例中,提供了一种解析得到业务数据的方法,即客户端先通过第二网络接收服务器发送的待解析业务数据,然后根据第一分隔符以及第二分隔符,对待解析业务数据进行解析,得到业务数据。通过上述方式,客户端能够利用不同的分隔符对待解析业务数据进行准确地解析,从而获取到客户端请求的业务数据,由此保证了方案的可行性和可操作性。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,根据第一分隔符以及第二分隔符,对待解析业务数据进行解析,得到业务数据,可以包括:
根据第一分隔符获取待解析状态数据;
对待解析状态数据进行解析,得到状态数据;
若根据状态数据确定客户端的数据传输请求已发起成功,则根据第二分隔符获取待解析头部数据以及待解析主体数据;
对待解析头部数据进行解析,得到头部数据;
若待解析主体数据为二进制数据,则根据头部数据获取业务数据;
若待解析主体数据不为二进制数据,则获取业务数据。
本实施例中,将详细地介绍客户端如何对待解析业务数据进行解析,在确定待解析业务数据的格式之后,即可分割出需要的信息,为了便于理解,请参阅图13,图13为本申请实施例中业务数据的一个解析流程示意图,如图所示,具体为:
在步骤Q1中,客户端接收服务器返回的待解析业务数据;
在步骤Q2中,客户端从响应的数据响应信息中截取待解析状态数据,其中,待解析业务数据格式可以表示为AAAAA\r\nBBBBB\r\n\r\nCCCCC,客户端根据第一分隔符“\r\n”获取待解析状态数据AAAAA;
在步骤Q3中,客户端对该待解析状态数据进行解析,得到状态数据,比如状态数据可以200OK;
在步骤Q4中,客户端根据状态数据判断数据传输请求是否发送成功,若数据传输请求发送成功,则进入步骤Q5,反之,若数据传输请求发送失败,则跳转至步骤Q2;
在步骤Q5中,如果根据状态数据确定客户端的数据传输请求已发起成功,则该客户端继续根据第二分隔符“\r\n\r\n”获取待解析头部数据BBBBB以及待解析主体数据CCCCC;
在步骤Q6中,客户端在解析得到头部数据之后,判断待解析主体数据是否属于二进制数据,如果待解析主体数据属于二进制数据,则执行步骤Q7,反之,如果待解析主体数据不属于二进制数据,则跳转至步骤Q11;
在步骤Q7中,客户端从头部数据中读取数据长度,比如数据长度为2048字节,可以表示图片数据的长度具有2048个字节;
在步骤Q8中,客户端持续接收服务器下发的数据,直至达到步骤Q7所确定的数据长度;
在步骤Q9中,客户端从头部数据中读取数据类型,比如数据类型是可以图片,具体的图片格式包含但不仅限于JEGP或者图形交换格式(Graphics Interchange Format,GIF)等,比如数据类型是可以视频,具体的视频格式包含但不仅限于动态图像专家组(MovingPicture Experts Group,MPEG)格式或者音频视频交错(Audio Video Interleaved,AVI)格式;
在步骤Q10中,客户端可以根据数据长度和数据类型,对待解析主体数据进行解析,得到业务数据;
在步骤Q11中,在待解析主体数据不属于二进制数据的情况下,客户端可以直接解析JS对象简谱(JavaScript Object Notation,JSON)中的内容;
在步骤Q12中,客户端完成对待解析业务数据进行解析的过程,至此,结束解析流程。
更进一步地,本申请实施例中,提供了一种对待解析业务数据进行解析的方法,即客户首先根据第一分隔符获取待解析状态数据,然后对待解析状态数据进行解析,得到状态数据,若根据状态数据确定客户端的数据传输请求已发起成功,则根据第二分隔符获取待解析头部数据以及待解析主体数据,此时需要对待解析头部数据进行解析,得到头部数据,若待解析主体数据为二进制数据,则根据头部数据获取业务数据,反之,则客户端直接获取业务数据。通过上述方式,客户端能够利用不同的分隔符对待解析业务数据进行准确地解析,从而获取到客户端请求的业务数据,由此保证了方案的可行性和可操作性。
可选地,在上述图3对应的各个实施例的基础上,本申请实施例提供的基于多网卡的数据传输方法一个可选实施例中,通过第二网络接收服务器发送的业务数据之后,还可以包括:
从业务数据中获取第一验证信息;
根据业务数据确定第二验证信息;
若第一验证信息与第二验证信息一致,则确定业务数据为合法数据;
若第一验证信息与第二验证信息不一致,则确定业务数据为非法数据。
本实施例中,介绍了一种客户端根据安全策略进行数据验证的方法,在客户端接收到业务数据之后,首先从业务数据中提取第一验证信息,第一验证信息是服务器端生成的,可以由多个比特位组成,比如第一验证信息可以是11223344。客户端还可以从业务数据中提取相关的校验参数,然后采用已知的公式对这些校验参数进行计算,得到第二验证信息,如果第二验证信息与第一验证信息一致,表示业务数据没有被篡改过,属于合法数据,反之,如果第二验证信息与第一验证信息不一致,表示业务数据被篡改过,属于非法数据。针对合法数据直接使用即可,针对非法数据,客户端可以丢弃该非法数据,或者,客户端可以向服务器上报错误信息,以使服务器下次向客户端下发请求的业务数据。
例如,从服务器下载业务数据,该业务数据的第一验证信息是1e07ab3591d25583eff5129293dc98d2,如果下载该业务数据计算第二验证信息,发现其值却是81395f50b94bb4891a4ce4ffb6ccf64b,那说明该业务数据已经被他人修改过。
可以理解的是,客户端还可以采用如下方式对业务数据进行安全性验证比如,可以采用消息摘要算法(Message-Digest Algorithm,MD5)对业务数据进行安全性验证,MD5是一个安全的散列算法,输入两个不同的明文不会得到相同的输出值,根据输出值,不能得到原始的明文,即其过程不可逆。所以要解密MD5只能用穷举法,把可能出现的明文,用MD5算法散列之后,把得到的散列值和原始的数据形成一个一对一的映射表,通过比在表中比破解密码的MD5算法散列值,通过匹配从映射表中找出破解密码所对应的原始明文。
可选地,还可以采用数据加密标准(Data Encryption Standard,DES)对业务数据进行安全性验证,或者采用基于DES的三个数据加密标准算法(Triple DES,3DES)对业务数据进行安全性验证,或者采用国际数据加密算法(International Data EncryptionAlgorithm,IDEA)对业务数据进行安全性验证,或者采用数字签名算法(DigitalSignature Algorithm,DSA)对业务数据进行安全性验证,或者采用高级加密标准(Advanced Encryption Standard,AES)对业务数据进行安全性验证,此处不对具体的加密方式进行限定。
其次,本申请实施例中,提供了一种客户端根据安全策略进行数据验证的方案,即客户端会接收业务数据之后,先从业务数据中获取第一验证信息,然后根据业务数据计算出第二验证信息,若第一验证信息与第二验证信息一致,则认为业务数据为合法数据,反之,则认为该业务数据为非法数据。通过上述方式,客户端可以对解析后得到的业务数据进行校验,保证业务数据的完整性和准确性,防止在通信过程中遭到他人的恶意篡改,由此增强方案的可靠性。
为了便于介绍,请参阅图14,图14为本申请实施例中基于多网卡的数据传输方法一个整体流程示意图,如图所示,具体包括如下步骤:
201、当通过第一网卡连接至第一网络时,客户端检测第一网络的网络状态是否满足网络重连条件;
202、客户端通过第二网络向服务器发送连接建立请求,其中,连接建立请求携带第二网卡的网卡信息,连接建立请求用于请求服务器与客户端建立Socket连接,第二网卡用于连接至第二网络,第二网卡与第一网卡为部署于同一个终端设备中不同的网卡;
203、客户端获取至少一个API;
204、客户端通过至少一个API获取第二网卡的网卡信息,其中,第二网卡的网卡信息包括第二网卡的网卡类型以及第二网卡的网际互联协议IP地址;
205、当Socket连接建立成功时,若第二网卡的网卡类型属于预设网卡类型,则客户端根据第二网卡的网卡信息生成数据传输请求;
206、客户端通过第二网络向服务器发送数据传输请求,其中,数据传输请求用于请求业务数据;
207、客户端通过第二网络接收服务器发送的业务数据;
208、客户端从业务数据中获取第一验证信息;
209、客户端根据业务数据确定第二验证信息;
210、客户端根据业务数据确定第二验证信息;
211、若第一验证信息与第二验证信息一致,则客户端确定业务数据为合法数据。
可以理解的是,步骤201至步骤211中每个步骤的具体内容可以参阅图3对应的各个实施例,此处不做赘述。
下面对本申请中的客户端进行详细描述,请参阅图15,图15为本申请实施例中客户端的一个实施例示意图,当通过第一网卡连接至第一网络时,客户端30包括:
发送模块301,用于通过第二网络向服务器发送连接建立请求,其中,所述连接建立请求携带第二网卡的网卡信息,所述连接建立请求用于请求所述服务器与客户端建立套接字Socket连接,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡;
生成模块302,用于当所述Socket连接建立成功时,根据所述第二网卡的网卡信息生成数据传输请求;
所述发送模块301,还用于通过所述第二网络向所述服务器发送所述生成模块302生成的所述数据传输请求,其中,所述数据传输请求用于请求业务数据;
接收模块303,用于通过所述第二网络接收所述服务器发送的所述业务数据。
本实施例中,发送模块301通过第二网络向服务器发送连接建立请求,其中,所述连接建立请求携带第二网卡的网卡信息,所述连接建立请求用于请求所述服务器与客户端建立套接字Socket连接,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡,当所述Socket连接建立成功时,生成模块302根据所述第二网卡的网卡信息生成数据传输请求,所述发送模块301通过所述第二网络向所述服务器发送所述生成模块302生成的所述数据传输请求,其中,所述数据传输请求用于请求业务数据,接收模块303通过所述第二网络接收所述服务器发送的所述业务数据。
本申请实施例中,提供了一种基于多网卡的数据传输方法,当通过第一网卡连接至第一网络时,客户端可以通过第二网络向服务器发送连接建立请求,其中,连接建立请求携带第二网卡的网卡信息,第二网卡与第一网卡为部署于同一个终端设备中不同的网卡,当Socket连接建立成功时,客户端根据第二网卡的网卡信息生成数据传输请求,然后通过第二网络向服务器发送数据传输请求,最后,客户端通过第二网络接收服务器发送的业务数据。通过上述方式,客户端与服务器建立Socket连接后,由于Socket连接建立在传输层上,因此,可以在传输层上对数据传输请求进行封装,以加入第二网卡的网卡信息,在客户端连接至第一网络的情况下,同时通过第二网络接收服务器下发的业务数据,从而使得客户端具有同时连接多个网络的能力,无需用户手动切换网络,不但减少了操作的复杂度,还提升了网络传输的效率。
可选地,在上述图15所对应的实施例的基础上,请参阅图16,本申请实施例提供的客户端30的另一实施例中,所述客户端30还包括检测模块304以及执行模块305;
所述检测模块304,用于在所述发送模块301通过第二网络向服务器发送连接建立请求之前,检测所述第一网络的网络状态是否满足网络重连条件;
所述执行模块305,用于若所述检测模块304检测得到所述第一网络的网络状态满足所述网络重连条件,则执行所述通过第二网络向服务器发送连接建立请求的步骤;
所述接收模块303,还用于若所述检测模块304检测得到所述第一网络的网络状态未满足所述网络重连条件,则通过所述第一网络接收所述服务器发送的所述业务数据。
其次,本申请实施例中,提供了一种客户端主动连接第二网络的方案,即客户端先检测第一网络的网络状态是否满足网络重连条件,若第一网络的网络状态满足网络重连条件,则通过第二网络向服务器发送连接建立请求,反之,则继续通过第一网络接收服务器发送的业务数据。通过上述方式,可以实现用户无感知的网络切换方案,客户端能够根据实时的网络状态选择合理的数据传输方式,一方面能够节省网络切换的时间,另一方面能够更高效地应用不同网络下的网络资源,从而提升方案的灵活性。
可选地,在上述图15所对应的实施例的基础上,请参阅图17,本申请实施例提供的客户端30的另一实施例中,所述客户端30还包括执行模块305;
所述接收模块303,还用于在所述发送模块301通过第二网络向服务器发送连接建立请求之前,接收网络切换指令,其中,所述网络切换指令中携带所述第二网络的标识;
所述执行模块305,用于响应于所述接收模块303接收的所述网络切换指令,根据所述第二网络的标识,执行所述通过第二网络向服务器发送连接建立请求的步骤。
其次,本申请实施例中,提供了一种客户端被动连接第二网络的方案,即客户端先接收网络切换指令,网络切换指令中携带第二网络的标识,然后响应于网络切换指令,根据第二网络的标识,执行通过第二网络向服务器发送连接建立请求的步骤。通过上述方式,用户可以根据实际需求手动选择希望连接的网络类型,由此,提升方案的灵活性和可操作性,交互操作具有可靠性、易用性和多样性的优势。
可选地,在上述图15所对应的实施例的基础上,请参阅图18,本申请实施例提供的客户端30的另一实施例中,所述客户端30还包括获取模块306;
所述获取模块306,用于在所述生成模块302根据所述第二网卡的网卡信息生成数据传输请求之前,获取至少一个应用程序编程接口API;
所述获取模块306,还用于通过所述至少一个API获取所述第二网卡的网卡信息,其中,所述第二网卡的网卡信息包括所述第二网卡的网卡类型以及所述第二网卡的网际互联协议IP地址。
其次,本申请实施例中,提供了一种获取网卡信息的方法,即在客户端根据第二网卡的网卡信息生成数据传输请求之前,还可以获取至少一个API,然后通过至少一个API获取第二网卡的网卡信息,该第二网卡的网卡信息包括第二网卡的网卡类型以及第二网卡的网际互联协议IP地址。通过上述方式,能够灵活地调用不同的API来获取所需的网卡信息,基于不同的应用场景可以调用不同的API,从而获取到不同的网卡信息,由此,提升方案的可行性和可操作性。
可选地,在上述图18所对应的实施例的基础上,请参阅图19,本申请实施例提供的客户端30的另一实施例中,所述客户端30还包括判断模块307以及执行模块305;
所述判断模块307,用于在所述获取模块306通过所述至少一个API获取所述第二网卡的网卡信息之后,判断所述第二网卡的网卡类型是否属于预设网卡类型;
所述执行模块305,还用于若所述判断模块307判断得到所述第二网卡的网卡类型属于所述预设网卡类型,则执行所述根据所述第二网卡的网卡信息生成数据传输请求的步骤;
所述接收模块303,还用于若所述判断模块307判断得到所述第二网卡的网卡类型不属于所述预设网卡类型,则通过所述第一网络接收所述服务器发送的所述业务数据。
再次,本申请实施例中,提供了一种检测网络连接可行性的方法,即客户端需要判断第二网卡的网卡类型是否属于预设网卡类型,如果是,则根据第二网卡的网卡信息生成数据传输请求,反之,则继续通过第一网络接收服务器发送的业务数据。通过上述方式,客户端会自动检测当前采用的第二网卡是否属于指定网卡,如果不是指定网卡,该客户端就不能采用第二网卡进行网络连接,如此,一方面能够有针对性地连接指定网络,从而有利于提升业务效率,另一方面,避免采用连接至不安全的网络,比如公共网络等,仅对安全可靠的网络进行连接,从而提升方案的安全性。
可选地,在上述图15至图19中任意一个图所对应的实施例的基础上,本申请实施例提供的客户端30的另一实施例中,
所述发送模块301,具体用于若所述第二网络的连接类型为超文本传输协议HTTP连接,则通过所述第二网络向所述服务器的第一预设端口发送所述连接建立请求,以使所述服务器通过所述第一预设端口与所述客户端建立Socket连接;
若所述第二网络的连接类型为安全超文本传输协议HTTPS连接,则通过所述第二网络向所述服务器的第二预设端口发送所述连接建立请求,以使所述服务器通过所述第二预设端口与所述客户端建立Socket连接。
其次,本申请实施例中,提供了一种客户端与服务器建立通信连接的方法,若第二网络的连接类型为HTTP连接,则通过第二网络向服务器的第一预设端口发送连接建立请求,若第二网络的连接类型为HTTPS连接,则通过第二网络向服务器的第二预设端口发送连接建立请求。通过上述方式,能够根据不同网络的连接类型选择合适的连接方式,从而提升方案的可行性和灵活性。
可选地,在上述图15至图19中任意一个图所对应的实施例的基础上,本申请实施例提供的客户端30的另一实施例中,
所述生成模块302,具体用于生成Socket传输请求,其中,所述Socket传输请求携带第一头部信息以及请求数据;
将所述第二网卡的网卡信息添加至所述第一头部信息,得到第二头部信息;
根据所述第二头部信息以及所述请求数据,生成所述数据传输请求。
其次,本申请实施例中,提供了一种生成数据传输请求的方法,客户端首先生成Socket传输请求,该Socket传输请求携带第一头部信息以及请求数据,然后将第二网卡的网卡信息添加至第一头部信息,得到第二头部信息,最后根据第二头部信息以及请求数据,生成数据传输请求。通过上述方式,客户端能够模拟得到HTTP请求或HTTPS请求,即对Socket传输请求进行重新封装,使得服务器无感知地响应于客户端发起的请求,从而能够在终端设备连接了不合适的无线网络时,还可以有效的保证网络请求正常的进行,在一定程度上保证应用的健壮性。并且在恰当的时机使用多网卡配合工作,可以完成更加复杂的网络请求。
可选地,在上述图15至图19中任意一个图所对应的实施例的基础上,本申请实施例提供的客户端30的另一实施例中,
所述接收模块303,具体用于通过所述第二网络接收服务器发送的待解析业务数据,其中,所述待解析业务数据包括第一分隔符以及第二分隔符,所述第一分隔符用于分割待解析状态数据与待解析头部数据,所述第二分隔符用于分割所述待解析头部数据与待解析主体数据;
根据所述第一分隔符以及所述第二分隔符,对所述待解析业务数据进行解析,得到所述业务数据。
进一步地,本申请实施例中,提供了一种解析得到业务数据的方法,即客户端先通过第二网络接收服务器发送的待解析业务数据,然后根据第一分隔符以及第二分隔符,对待解析业务数据进行解析,得到业务数据。通过上述方式,客户端能够利用不同的分隔符对待解析业务数据进行准确地解析,从而获取到客户端请求的业务数据,由此保证了方案的可行性和可操作性。
可选地,在上述图15至图19中任意一个图所对应的实施例的基础上,本申请实施例提供的客户端30的另一实施例中,
所述接收模块303,具体用于根据所述第一分隔符获取所述待解析状态数据;
对所述待解析状态数据进行解析,得到状态数据;
若根据所述状态数据确定所述客户端的所述数据传输请求已发起成功,则根据所述第二分隔符获取所述待解析头部数据以及所述待解析主体数据;
对所述待解析头部数据进行解析,得到头部数据;
若所述待解析主体数据为二进制数据,则根据所述头部数据获取所述业务数据;
若所述待解析主体数据不为二进制数据,则获取所述业务数据。
更进一步地,本申请实施例中,提供了一种对待解析业务数据进行解析的方法,即客户首先根据第一分隔符获取待解析状态数据,然后对待解析状态数据进行解析,得到状态数据,若根据状态数据确定客户端的数据传输请求已发起成功,则根据第二分隔符获取待解析头部数据以及待解析主体数据,此时需要对待解析头部数据进行解析,得到头部数据,若待解析主体数据为二进制数据,则根据头部数据获取业务数据,反之,则客户端直接获取业务数据。通过上述方式,客户端能够利用不同的分隔符对待解析业务数据进行准确地解析,从而获取到客户端请求的业务数据,由此保证了方案的可行性和可操作性。
可选地,在上述图15至图19中任意一个图所对应的实施例的基础上,请参阅图20,本申请实施例提供的客户端30的另一实施例中,所述客户端30还包括获取模块306以及确定模块308;
所述获取模块306,用于在所述接收模块303通过所述第二网络接收所述服务器发送的所述业务数据之后,从所述业务数据中获取第一验证信息;
所述确定模块308,用于根据所述业务数据确定第二验证信息;
所述确定模块308,还用于若所述获取模块306获取的所述第一验证信息与所述第二验证信息一致,则确定所述业务数据为合法数据;
所述确定模块308,还用于若所述获取模块306获取的所述第一验证信息与所述第二验证信息不一致,则确定所述业务数据为非法数据。
其次,本申请实施例中,提供了一种客户端根据安全策略进行数据验证的方案,即客户端会接收业务数据之后,先从业务数据中获取第一验证信息,然后根据业务数据计算出第二验证信息,若第一验证信息与第二验证信息一致,则认为业务数据为合法数据,反之,则认为该业务数据为非法数据。通过上述方式,客户端可以对解析后得到的业务数据进行校验,保证业务数据的完整性和准确性,防止在通信过程中遭到他人的恶意篡改,由此增强方案的可靠性。
本申请实施例还提供了另一种客户端,如图21所示,为了便于说明,仅示出了与本申请实施例相关的部分,具体技术细节未揭示的,请参照本申请实施例方法部分。该终端设备可以为包括手机、平板电脑、个人数字助理(Personal Digital Assistant,PDA)、销售终端设备(Point of Sales,POS)、车载电脑等任意终端设备,以终端设备为手机为例:
图21示出的是与本申请实施例提供的终端设备相关的手机的部分结构的框图。参考图21,手机包括:射频(Radio Frequency,RF)电路410、存储器420、输入单元430、显示单元440、传感器450、音频电路460、无线保真(wireless fidelity,WiFi)模块470、处理器480、以及电源490等部件。本领域技术人员可以理解,图21中示出的手机结构并不构成对手机的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图21对手机的各个构成部件进行具体的介绍:
RF电路410可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,给处理器480处理;另外,将设计上行的数据发送给基站。通常,RF电路410包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier,LNA)、双工器等。此外,RF电路410还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议,包括但不限于全球移动通讯系统(GlobalSystem of Mobile communication,GSM)、通用分组无线服务(General Packet RadioService,GPRS)、码分多址(Code Division Multiple Access,CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution,LTE)、电子邮件、短消息服务(Short Messaging Service,SMS)等。
存储器420可用于存储软件程序以及模块,处理器480通过运行存储在存储器420的软件程序以及模块,从而执行手机的各种功能应用以及数据处理。存储器420可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外,存储器420可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
输入单元430可用于接收输入的数字或字符信息,以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地,输入单元430可包括触控面板431以及其他输入设备432。触控面板431,也称为触摸屏,可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板431上或在触控面板431附近的操作),并根据预先设定的程式驱动相应的连接装置。可选的,触控面板431可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测装置检测用户的触摸方位,并检测触摸操作带来的信号,将信号传送给触摸控制器;触摸控制器从触摸检测装置上接收触摸信息,并将它转换成触点坐标,再送给处理器480,并能接收处理器480发来的命令并加以执行。此外,可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板431。除了触控面板431,输入单元430还可以包括其他输入设备432。具体地,其他输入设备432可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元440可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元440可包括显示面板441,可选的,可以采用液晶显示器(Liquid CrystalDisplay,LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板441。进一步的,触控面板431可覆盖显示面板441,当触控面板431检测到在其上或附近的触摸操作后,传送给处理器480以确定触摸事件的类型,随后处理器480根据触摸事件的类型在显示面板441上提供相应的视觉输出。虽然在图21中,触控面板431与显示面板441是作为两个独立的部件来实现手机的输入和输入功能,但是在某些实施例中,可以将触控面板431与显示面板441集成而实现手机的输入和输出功能。
手机还可包括至少一种传感器450,比如光传感器、运动传感器以及其他传感器。具体地,光传感器可包括环境光传感器及接近传感器,其中,环境光传感器可根据环境光线的明暗来调节显示面板441的亮度,接近传感器可在手机移动到耳边时,关闭显示面板441和/或背光。作为运动传感器的一种,加速计传感器可检测各个方向上(一般为三轴)加速度的大小,静止时可检测出重力的大小及方向,可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等;至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器,在此不再赘述。
音频电路460、扬声器461,传声器462可提供用户与手机之间的音频接口。音频电路460可将接收到的音频数据转换后的电信号,传输到扬声器461,由扬声器461转换为声音信号输出;另一方面,传声器462将收集的声音信号转换为电信号,由音频电路460接收后转换为音频数据,再将音频数据输出处理器480处理后,经RF电路410以发送给比如另一手机,或者将音频数据输出至存储器420以便进一步处理。
WiFi属于短距离无线传输技术,手机通过WiFi模块470可以帮助用户收发电子邮件、浏览网页和访问流式媒体等,它为用户提供了无线的宽带互联网访问。虽然图21示出了WiFi模块470,但是可以理解的是,其并不属于手机的必须构成,完全可以根据需要在不改变发明的本质的范围内而省略。
处理器480是手机的控制中心,利用各种接口和线路连接整个手机的各个部分,通过运行或执行存储在存储器420内的软件程序和/或模块,以及调用存储在存储器420内的数据,执行手机的各种功能和处理数据,从而对手机进行整体监控。可选的,处理器480可包括一个或多个处理单元;可选的,处理器480可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器480中。
手机还包括给各个部件供电的电源490(比如电池),可选的,电源可以通过电源管理系统与处理器480逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
尽管未示出,手机还可以包括摄像头、蓝牙模块等,在此不再赘述。
在本申请实施例中,该终端设备所包括的处理器480还具有以下功能:
当通过第一网卡连接至第一网络时,通过第二网络向服务器发送连接建立请求,其中,所述连接建立请求携带第二网卡的网卡信息,所述连接建立请求用于请求所述服务器与客户端建立套接字Socket连接,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡;
当所述Socket连接建立成功时,根据所述第二网卡的网卡信息生成数据传输请求;
通过所述第二网络向所述服务器发送所述数据传输请求,其中,所述数据传输请求用于请求业务数据;
通过所述第二网络接收所述服务器发送的所述业务数据。
可选地,处理器480还用于执行如下步骤:
检测所述第一网络的网络状态是否满足网络重连条件;
若所述第一网络的网络状态满足所述网络重连条件,则执行所述通过第二网络向服务器发送连接建立请求的步骤;
若所述第一网络的网络状态未满足所述网络重连条件,则通过所述第一网络接收所述服务器发送的所述业务数据。
可选地,处理器480还用于执行如下步骤:
接收网络切换指令,其中,所述网络切换指令中携带所述第二网络的标识;
响应于所述网络切换指令,根据所述第二网络的标识,执行所述通过第二网络向服务器发送连接建立请求的步骤。
可选地,处理器480还用于执行如下步骤:
获取至少一个应用程序编程接口API;
通过所述至少一个API获取所述第二网卡的网卡信息,其中,所述第二网卡的网卡信息包括所述第二网卡的网卡类型以及所述第二网卡的网际互联协议IP地址。
可选地,处理器480还用于执行如下步骤:
判断所述第二网卡的网卡类型是否属于预设网卡类型;
若所述第二网卡的网卡类型属于所述预设网卡类型,则执行所述根据所述第二网卡的网卡信息生成数据传输请求的步骤;
若所述第二网卡的网卡类型不属于所述预设网卡类型,则通过所述第一网络接收所述服务器发送的所述业务数据。
可选地,处理器480具体用于执行如下步骤:
若所述第二网络的连接类型为超文本传输协议HTTP连接,则通过所述第二网络向所述服务器的第一预设端口发送所述连接建立请求,以使所述服务器通过所述第一预设端口与所述客户端建立Socket连接;
若所述第二网络的连接类型为安全超文本传输协议HTTPS连接,则通过所述第二网络向所述服务器的第二预设端口发送所述连接建立请求,以使所述服务器通过所述第二预设端口与所述客户端建立Socket连接。
可选地,处理器480具体用于执行如下步骤:
生成Socket传输请求,其中,所述Socket传输请求携带第一头部信息以及请求数据;
将所述第二网卡的网卡信息添加至所述第一头部信息,得到第二头部信息;
根据所述第二头部信息以及所述请求数据,生成所述数据传输请求。
可选地,处理器480具体用于执行如下步骤:
通过所述第二网络接收服务器发送的待解析业务数据,其中,所述待解析业务数据包括第一分隔符以及第二分隔符,所述第一分隔符用于分割待解析状态数据与待解析头部数据,所述第二分隔符用于分割所述待解析头部数据与待解析主体数据;
根据所述第一分隔符以及所述第二分隔符,对所述待解析业务数据进行解析,得到所述业务数据。
可选地,处理器480具体用于执行如下步骤:
根据所述第一分隔符获取所述待解析状态数据;
对所述待解析状态数据进行解析,得到状态数据;
若根据所述状态数据确定所述客户端的所述数据传输请求已发起成功,则根据所述第二分隔符获取所述待解析头部数据以及所述待解析主体数据;
对所述待解析头部数据进行解析,得到头部数据;
若所述待解析主体数据为二进制数据,则根据所述头部数据获取所述业务数据;
若所述待解析主体数据不为二进制数据,则获取所述业务数据。
可选地,处理器480还用于执行如下步骤:
从所述业务数据中获取第一验证信息;
根据所述业务数据确定第二验证信息;
若所述第一验证信息与所述第二验证信息一致,则确定所述业务数据为合法数据;
若所述第一验证信息与所述第二验证信息不一致,则确定所述业务数据为非法数据。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
Claims (8)
1.一种基于多网卡的数据传输方法,其特征在于,当通过第一网卡连接至第一网络时,所述方法包括:
通过第二网络向服务器发送连接建立请求,包括:若所述第二网络的连接类型为超文本传输协议HTTP连接,则通过所述第二网络向所述服务器的第一预设端口发送所述连接建立请求,以使所述服务器通过所述第一预设端口与客户端建立Socket连接;若所述第二网络的连接类型为安全超文本传输协议HTTPS连接,则通过所述第二网络向所述服务器的第二预设端口发送所述连接建立请求,以使所述服务器通过所述第二预设端口与所述客户端建立Socket连接;其中,所述连接建立请求携带第二网卡的网卡信息,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡;所述第一网络为WiFi网络;所述第二网络为4G网络,所述客户端与所述服务器是通过网络层的TCP来完成多链路的并行操作,基于多路传输控制协议允许TCP连接使用多个路径来最大化信道资源使用;
当所述Socket连接建立成功时,根据所述第二网卡的网卡信息生成数据传输请求;
通过所述第二网络向所述服务器发送所述数据传输请求,其中,所述数据传输请求用于请求业务数据;
通过所述第二网络接收所述服务器发送的所述业务数据;
其中,所述根据所述第二网卡的网卡信息生成数据传输请求,包括:
在传输层生成Socket传输请求,其中,所述Socket传输请求携带第一头部信息以及请求数据;
将所述第二网卡的网卡信息添加至所述第一头部信息,得到第二头部信息;
根据所述第二头部信息以及所述请求数据,生成所述数据传输请求。
2.根据权利要求1所述的方法,其特征在于,所述通过第二网络向服务器发送连接建立请求之前,所述方法还包括:
检测所述第一网络的网络状态是否满足网络重连条件;
若所述第一网络的网络状态满足所述网络重连条件,则执行所述通过第二网络向服务器发送连接建立请求的步骤;
若所述第一网络的网络状态未满足所述网络重连条件,则通过所述第一网络接收所述服务器发送的所述业务数据。
3.根据权利要求1所述的方法,其特征在于,所述通过第二网络向服务器发送连接建立请求之前,所述方法还包括:
接收网络切换指令,其中,所述网络切换指令中携带所述第二网络的标识;
响应于所述网络切换指令,根据所述第二网络的标识,执行所述通过第二网络向服务器发送连接建立请求的步骤。
4.根据权利要求1所述的方法,其特征在于,所述根据所述第二网卡的网卡信息生成数据传输请求之前,所述方法还包括:
获取至少一个应用程序编程接口API;
通过所述至少一个API获取所述第二网卡的网卡信息,其中,所述第二网卡的网卡信息包括所述第二网卡的网卡类型以及所述第二网卡的网际互联协议IP地址。
5.根据权利要求4所述的方法,其特征在于,所述通过所述至少一个API获取所述第二网卡的网卡信息之后,所述方法还包括:
判断所述第二网卡的网卡类型是否属于预设网卡类型;
若所述第二网卡的网卡类型属于所述预设网卡类型,则执行所述根据所述第二网卡的网卡信息生成数据传输请求的步骤;
若所述第二网卡的网卡类型不属于所述预设网卡类型,则通过所述第一网络接收所述服务器发送的所述业务数据。
6.根据权利要求1至5中任一项所述的方法,其特征在于,所述通过所述第二网络接收所述服务器发送的所述业务数据,包括:
通过所述第二网络接收服务器发送的待解析业务数据,其中,所述待解析业务数据包括第一分隔符以及第二分隔符,所述第一分隔符用于分割待解析状态数据与待解析头部数据,所述第二分隔符用于分割所述待解析头部数据与待解析主体数据;
根据所述第一分隔符以及所述第二分隔符,对所述待解析业务数据进行解析,得到所述业务数据。
7.根据权利要求6所述的方法,其特征在于,所述根据所述第一分隔符以及所述第二分隔符,对所述待解析业务数据进行解析,得到所述业务数据,包括:
根据所述第一分隔符获取所述待解析状态数据;
对所述待解析状态数据进行解析,得到状态数据;
若根据所述状态数据确定所述客户端的所述数据传输请求已发起成功,则根据所述第二分隔符获取所述待解析头部数据以及所述待解析主体数据;
对所述待解析头部数据进行解析,得到头部数据;
若所述待解析主体数据为二进制数据,则根据所述头部数据获取所述业务数据;
若所述待解析主体数据不为二进制数据,则获取所述业务数据。
8.一种客户端,其特征在于,当通过第一网卡连接至第一网络时,所述客户端包括:
发送模块,用于通过第二网络向服务器发送连接建立请求,包括:若所述第二网络的连接类型为超文本传输协议HTTP连接,则通过所述第二网络向所述服务器的第一预设端口发送所述连接建立请求,以使所述服务器通过所述第一预设端口与所述客户端建立Socket连接;若所述第二网络的连接类型为安全超文本传输协议HTTPS连接,则通过所述第二网络向所述服务器的第二预设端口发送所述连接建立请求,以使所述服务器通过所述第二预设端口与所述客户端建立Socket连接;其中,所述连接建立请求携带第二网卡的网卡信息,所述第二网卡用于连接至第二网络,所述第二网卡与所述第一网卡为部署于同一个终端设备中不同的网卡;所述第一网络为WiFi网络;所述第二网络为4G网络,所述客户端与所述服务器是通过网络层的TCP来完成多链路的并行操作,基于多路传输控制协议允许TCP连接使用多个路径来最大化信道资源使用;
生成模块,用于当所述Socket连接建立成功时,根据所述第二网卡的网卡信息生成数据传输请求;
所述发送模块,还用于通过所述第二网络向所述服务器发送所述生成模块生成的所述数据传输请求,其中,所述数据传输请求用于请求业务数据;
接收模块,用于通过所述第二网络接收所述服务器发送的所述业务数据;
其中,所述生成模块具体用于:
在传输层生成Socket传输请求,其中,所述Socket传输请求携带第一头部信息以及请求数据;
将所述第二网卡的网卡信息添加至所述第一头部信息,得到第二头部信息;
根据所述第二头部信息以及所述请求数据,生成所述数据传输请求。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910666801.4A CN112291181B (zh) | 2019-07-23 | 2019-07-23 | 一种基于多网卡的数据传输方法以及相关装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910666801.4A CN112291181B (zh) | 2019-07-23 | 2019-07-23 | 一种基于多网卡的数据传输方法以及相关装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112291181A CN112291181A (zh) | 2021-01-29 |
CN112291181B true CN112291181B (zh) | 2023-03-10 |
Family
ID=74419271
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910666801.4A Active CN112291181B (zh) | 2019-07-23 | 2019-07-23 | 一种基于多网卡的数据传输方法以及相关装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112291181B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113747203B (zh) * | 2021-09-01 | 2022-08-30 | 腾讯科技(深圳)有限公司 | 一种视频信息传输方法、装置、电子设备及存储介质 |
CN115811748A (zh) * | 2021-09-13 | 2023-03-17 | 华为技术有限公司 | 通信方法、系统及电子设备 |
CN115277726A (zh) * | 2022-05-30 | 2022-11-01 | 浪潮软件集团有限公司 | 一种双网络的集群数据传输方法及系统 |
CN115086207A (zh) * | 2022-06-14 | 2022-09-20 | 深信服科技股份有限公司 | 一种网卡检测方法、装置及电子设备和存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1519742A (zh) * | 2003-01-23 | 2004-08-11 | 英业达股份有限公司 | 可均衡负载的网卡测试方法 |
CN104579727A (zh) * | 2013-10-17 | 2015-04-29 | 国际商业机器公司 | 一种管理网络节点的网络连接的方法和装置 |
CN104639578A (zh) * | 2013-11-08 | 2015-05-20 | 华为技术有限公司 | 多协议栈负载均衡方法及装置 |
CN104702518A (zh) * | 2015-03-05 | 2015-06-10 | 安徽清新互联信息科技有限公司 | 一种基于无线网络的多卡路由器装置及其数据传输方法 |
CN109088799A (zh) * | 2018-09-28 | 2018-12-25 | 腾讯科技(深圳)有限公司 | 一种客户端接入方法、装置、终端以及存储介质 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005076649A1 (en) * | 2004-02-10 | 2005-08-18 | Forward Information Technologies Sa | Method and system for seamless handover of mobile devices in heterogenous networks |
CN105392020B (zh) * | 2015-11-19 | 2019-01-25 | 广州华多网络科技有限公司 | 一种互联网视频直播方法,及系统 |
CN105722142A (zh) * | 2016-02-26 | 2016-06-29 | 努比亚技术有限公司 | 移动终端及基于多链路的数据分流方法 |
-
2019
- 2019-07-23 CN CN201910666801.4A patent/CN112291181B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1519742A (zh) * | 2003-01-23 | 2004-08-11 | 英业达股份有限公司 | 可均衡负载的网卡测试方法 |
CN104579727A (zh) * | 2013-10-17 | 2015-04-29 | 国际商业机器公司 | 一种管理网络节点的网络连接的方法和装置 |
CN104639578A (zh) * | 2013-11-08 | 2015-05-20 | 华为技术有限公司 | 多协议栈负载均衡方法及装置 |
CN104702518A (zh) * | 2015-03-05 | 2015-06-10 | 安徽清新互联信息科技有限公司 | 一种基于无线网络的多卡路由器装置及其数据传输方法 |
CN109088799A (zh) * | 2018-09-28 | 2018-12-25 | 腾讯科技(深圳)有限公司 | 一种客户端接入方法、装置、终端以及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN112291181A (zh) | 2021-01-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112291181B (zh) | 一种基于多网卡的数据传输方法以及相关装置 | |
CN113518085B (zh) | 一种基于多通道的数据传输方法以及相关装置 | |
US10959124B2 (en) | Uplink data transmission method, terminal, network side device and system | |
US9832621B2 (en) | Method, terminal, server, and system for audio signal transmission | |
CN106686070B (zh) | 一种数据库数据迁移方法、装置、终端及系统 | |
CN104580167B (zh) | 一种传输数据的方法、装置和系统 | |
CN107040609B (zh) | 一种网络请求处理方法和装置 | |
US20150229669A1 (en) | Method and device for detecting distributed denial of service attack | |
CN109905380B (zh) | 一种分布式系统中的节点控制方法和相关装置 | |
CN109088799B (zh) | 一种客户端接入方法、装置、终端以及存储介质 | |
WO2016112728A1 (zh) | 一种数据传输的方法、网络服务器、用户终端及系统 | |
CN112087362B (zh) | 一种客户端之间的消息转发方法和装置以及终端 | |
CN109729384A (zh) | 视频转码的选择方法和装置 | |
CN112242972B (zh) | 网络请求处理方法、装置、存储介质及终端 | |
CN108270764B (zh) | 一种应用登陆方法、服务器及移动端 | |
CN107104760B (zh) | 一种传输数据包的方法、客户端以及服务器 | |
CN107786423B (zh) | 一种即时通讯的方法和系统 | |
US9965341B2 (en) | Method and device for exchanging data between processes | |
WO2019036851A1 (zh) | 一种信道状态信息测量及反馈方法及相关产品 | |
CN110138887B (zh) | 一种数据处理方法、装置及存储介质 | |
WO2017166093A1 (zh) | 前置系统 | |
CN112118207B (zh) | 数据传输方法、服务器以及电子设备 | |
CN107315623B (zh) | 一种上报统计数据的方法和装置 | |
CN110831060A (zh) | 一种承载数据包的mac ce的方法和设备 | |
WO2017166095A1 (zh) | 服务器前置方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |