发明内容
本发明实施例提供一种远程终端管理方法及系统,能解决TR069协议不能双向实时通信的问题,提升交互的便捷性。
本发明一实施例提供一种远程终端管理方法,包括:
当客户端需要与服务端建立连接时,客户端向服务端发送QUI C握手请求,以使所述服务端在同意握手时,根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密;
当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥,完成与所述服务端的连接建立;
当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,随后在所述连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,所述客户端与所述服务端通过所述若干个传输协议流进行通信;其中,所述客户端通过所述第二会话密钥对通信数据进行加密或解密;所述服务端通过所述第一会话密钥对通信数据进行加密或解密。
与现有技术相比,本发明实施例公开的一种远程终端管理方法通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
进一步的,所述客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密,具体包括:
客户端在发送QUI C握手请求后,利用自身预存的服务端配置参数和所述QUI C握手请求中包含的公开数计算第二初始密钥;
客户端在收到服务端发送的握手同意信息后,利用所述第二初始密钥对所述握手同意信息进行解密;
若解密成功,则提取所述握手同意信息中的临时随机数继续进行第二会话密钥的计算;
若解密失败,则向服务端发送配置参数请求信息,请求服务端传输配置参数,随后继续利用所述配置参数和所述公开数计算第二初始密钥对握手同意信息进行解密;
重复向服务端发送所述配置参数请求信息,直至成功解密所述握手同意信息。
通过服务端利用第一初始密钥对握手同意信息进行加密,同时客户端利用第二初始密钥进行解密,保证了使客户端解密成功的第二初始密钥与第一初始密钥相同,为后续计算会话密钥作下铺垫。
进一步的,所述当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥以及所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥,具体包括:
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥;
服务端根据所述临时随机数和第一初始密钥,基于SHA-256算法推导出第一会话密钥。
双方各自基于相同算法计算第一和第二会话密钥,由于有初始密钥的铺垫,第一会话密钥与第二会话密钥也应相同,此后双方舍弃初始密钥,改为使用会话密钥进行通信,提高了连接的可靠性。
进一步的,所述当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,具体包括:
当连接建立完成后,所述连接将由一个唯一标识符进行标识,所述唯一标识符分别保存在所述客户端与所述服务端中,当客户端端口发生变化时,所述客户端向服务端发送所述标识符以使服务端确认标识符后继续进行数据传输。
通过设计专属标识符标识连接,避免当客户端端口发生变化时需要重新建立与服务端的连接,降低了弱网络或移动场景下的TCP和TLS重连代价。
进一步的,所述每个传输协议流各自配置一个唯一标识数值,具体包括:
所述若干个传输协议流分别以若干个一一对应的标识数值进行标识,所述若干个标识数值各不相同,且所述标识数值的编码为一个可变长度整型;
所述标识数值的最小有效位标识流的发起者,若所述传输协议流为客户端发起的流,则将所述最小有效位设置为第一阈值,若所述传输协议流为服务端发起的流,则将所述最小有效位设置为第二阈值;
所述标识数值的次小有效位标识流的通信类型,若所述传输协议流为双向流,则将所述次小有效位设置为第三阈值,若所述传输协议流为单向流,则将所述次小有效为设置为第四阈值。
设计若干个与传输协议流一一对应的标识数值对传输协议流进行标识,再通过设置所述标识数值的最小有效位及次小有效位将其对应的传输协议流变为包括双向通信类型的各种类型,实现了客户端与服务端之间的双向实时通信,提升了交互的便捷性。
作为一个优选的实施例,所述若干个传输协议流相互独立且各自拥有一个独立的滑动窗口,所述若干个传输协议流的标识数值由所述客户端与所述服务端共同决定,各传输协议流对应的标识数值各不相同。
通过在连接中设置多个相互独立的流通道并行发送业务信息,解决TCP存在的队头阻塞问题,提高了连接的便捷性。
进一步的,所述客户端与所述服务端通过所述若干个传输协议流进行通信,具体包括:
所述客户端通过所述若干个传输协议流与所述服务端连接,所述服务端通过连接的所述唯一标识符与传输协议流的所述唯一标识数值对所述客户端进行绑定,在通信过程中,所述客户端与服务端使用QU I C作为传输协议,所述通信数据为TR069协议信令数据。
本发明另一实施例对应提供了一种远程终端管理系统,包括:客户端、服务端、若干个QUI C通信模块以及连接平台;
所述客户端用于执行如上述发明实施例所述的一种远程终端管理方法;
所述服务端用于当客户端需要与服务端建立连接时,接收客户端发送的QUI C握手请求,在同意握手后,服务端根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
所述若干个QUI C通信模块分别位于客户端与服务端,所述客户端与服务端通过所述若干个QUI C通信模块进行通信;
所述连接平台依靠互联网进行搭建,用于承载所述客户端与服务端之间的连接,以使所述客户端与所述服务端通过所述连接中的若干个传输协议流进行通信。
与现有技术相比,本发明实施例公开的一种远程终端管理系统通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
进一步的,当所述客户端与所述服务端的连接建立完成后,设计一个唯一标识符用于标识所述连接,随后在所述连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,所述客户端与所述服务端通过所述若干个传输协议流进行通信;其中,所述客户端通过第二会话密钥对通信数据进行加密或解密;所述服务端通过所述第一会话密钥对通信数据进行加密或解密。
作为一个优选的实施例,所述客户端通过第二会话密钥对通信数据进行加密或解密,具体包括:
客户端在发送QUI C握手请求后,利用自身预存的服务端配置参数和所述QUI C握手请求中包含的公开数计算第二初始密钥;
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
参见图1,是本发明一实施例提供的一种远程终端管理方法的流程示意图,包括步骤S101至步骤S104。各步骤具体如下:
S101:当客户端需要与服务端建立连接时,客户端向服务端发送QUI C握手请求,以使服务端在同意握手时,根据本地存储的第一服务端配置参数和握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,握手同意信息是根据第一初始密钥和临时随机数而加密生成;服务端还根据第一初始密钥和临时随机数生成第一会话密钥;
S102:客户端根据预存的第二服务端配置参数和公开数,生成第二初始密钥,并采用第二初始密钥对握手同意信息进行解密;
S103:当所述客户端成功解密并提取临时随机数后,根据临时随机数和第二初始密钥,生成第二会话密钥,完成与服务端的连接建立;
S104:当连接建立完成后,客户端与服务端设计一个唯一标识符用于标识连接,随后在连接中建立若干个传输协议流,每个传输协议流各自配置一个唯一标识数值,客户端与服务端通过若干个传输协议流进行通信;其中,客户端通过第二会话密钥对通信数据进行加密或解密;服务端通过第一会话密钥对通信数据进行加密或解密。
本发明实施例公开的一种远程终端管理方法通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
对于步骤S101,具体的,客户端与服务端协商初始密钥的过程如下:
(1)客户端判断本地是否已有服务端的全部配置参数,如果有则直接跳转到(5),否则继续;
(2)客户端向服务端发送i nchoate c l i ent he l l o(CHLO)消息,请求服务端传输配置参数;
(3)服务端收到CHLO,回复reject i on(REJ)消息,其中包含服务端的部分配置参数;
(4)客户端收到REJ,提取并存储服务端配置参数,跳回到(1);
(5)客户端向服务端发送fu l l c l i ent he l l o消息,开始正式握手,消息中包括客户端选择的公开数;
(6)服务端收到fu l l c l i ent he l l o,如果不同意连接就回复REJ,同(3);如果同意连接,根据客户端的公开数计算出初始密钥,回复server he l l o(SHLO)消息,SHLO用初始密钥加密,并且其中包含服务端选择的一个临时公开数。
通过服务端利用第一初始密钥对握手同意信息进行加密,同时客户端利用第二初始密钥进行解密,保证了使客户端解密成功的第二初始密钥与第一初始密钥相同,为后续计算会话密钥作下铺垫。
对于步骤S102,具体的,所述客户端根据预存的第二服务端配置参数和所述公开数,生成第二初始密钥,并采用所述第二初始密钥对所述握手同意信息进行解密,具体包括:
客户端在发送QU I C握手请求后,利用自身预存的服务端配置参数和所述QU I C握手请求中包含的公开数计算第二初始密钥;
客户端在收到服务端发送的握手同意信息后,利用所述第二初始密钥对所述握手同意信息进行解密;
若解密成功,则提取所述握手同意信息中的临时随机数继续进行第二会话密钥的计算;
若解密失败,则向服务端发送配置参数请求信息,请求服务端传输配置参数,随后继续利用所述配置参数和所述公开数计算第二初始密钥对握手同意信息进行解密;
重复向服务端发送所述配置参数请求信息,直至成功解密所述握手同意信息。
在一个优选的实施例中,客户端在向服务端发送fu l l c l ient he l l o消息后,客户端即可根据获取的服务端配置参数和自己选择的公开数计算出初始密钥。然后,客户端利用该初始密钥对服务端发送过来的SHLO消息进行解密,若解密成功则说明客户端计算的初始密钥与服务端计算的初始密钥相同。
对于步骤S103,具体的,所述当所述客户端成功解密并提取所述临时随机数后,根据所述临时随机数和第二初始密钥,生成第二会话密钥,具体包括:
客户端收到由服务端发送的握手同意信息后,利用所述第二初始密钥解密并从所述握手同意信息中提取出临时随机数;
客户端根据所述临时随机数和第二初始密钥,基于SHA-256算法推导出第二会话密钥;
同时,对于步骤S101中所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥,具体包括:所述服务端根据所述临时随机数和第一初始密钥,基于SHA-256算法推导出第一会话密钥。
在一个优选的实施例中,当客户端解密SHLO消息完成后,从SHLO消息中提取出服务端选择的一个临时随机数,此时客户端和服务器根据临时随机数和初始密钥,各自基于SHA-256算法推导出会话密钥。此后,双方更换为使用会话密钥通信,初始密钥此时已无用,QU I C握手过程完毕。之后会话密钥更新的流程与以上过程类似,只是数据包中的某些字段略有不同。
双方各自基于相同算法计算第一和第二会话密钥,由于有初始密钥的铺垫,第一会话密钥与第二会话密钥也应相同,此后双方舍弃初始密钥,改为使用会话密钥进行通信,提高了连接的可靠性。
对于步骤S104,具体的,所述当连接建立完成后,所述客户端与所述服务端设计一个唯一标识符用于标识所述连接,具体包括:
当连接建立完成后,所述连接将由一个唯一标识符进行标识,所述唯一标识符分别保存在所述客户端与所述服务端中,当客户端端口发生变化时,所述客户端向服务端发送所述标识符以使服务端确认标识符后继续进行数据传输。
在一个优选的实施例中,通过设计一个标识符(Connect i on I D)来标识客户端与服务端之间的连接,当QUI C连接进行连接迁移,也就是在四元组发生变化时,QUI C使用Connect ion I D来“保留”断开之前的连接,从而维持数据传输不中断。QUI C协议连接不再以I P及端口四元组标识,而是以一个64位的Connect ion I D作为I D来标识,这样就算I P或者端口发生变化时,只要I D不变,这条连接依然维持着,上层业务逻辑感知不到变化,不会中断,也就不需要重连。也就是说,当客户端之前已连接过服务端,客户端将服务端传输配置参数和加密公钥等信息保存在客户端,当客户端后续再重新连接的时,便无需再进行配置参数和加密公钥等信息的交互,可以立即传输数据,实现0RTT(Round-Tr ipTime,往返时延)发送业务数据的效果。
通过设计专属标识符标识连接,避免当客户端端口发生变化时需要重新建立与服务端的连接,降低了弱网络或移动场景下的TCP和TLS重连代价。
对于步骤S104,具体的,所述每个传输协议流各自配置一个唯一标识数值,具体包括:
所述若干个传输协议流分别以若干个一一对应的标识数值进行标识,所述若干个标识数值各不相同,且所述标识数值的编码为一个可变长度整型;
所述标识数值的最小有效位标识流的发起者,若所述传输协议流为客户端发起的流,则将所述最小有效位设置为第一阈值,若所述传输协议流为服务端发起的流,则将所述最小有效位设置为第二阈值;
所述标识数值的次小有效位标识流的通信类型,若所述传输协议流为双向流,则将所述次小有效位设置为第三阈值,若所述传输协议流为单向流,则将所述次小有效为设置为第四阈值。
在一个优选的实施例中,完成QU I C握手之后,需要对传输协议流(Stream)进行申请和建立,建立过程中需要设置Stream为双向通信类型,即可使QU I C连接支持双向实时通信。流可以是单向或双向的,单向流往一个方向传输数据,双向流允许双端向对端发送数据。
在连接中,流以一个数字值标识,称为Stream I D。一个Stream I D与同连接中其他流的Stream I D严格区分。Stream I D编码为一个可变长度整型。一个QU I C终端必须不能在同一个连接的不同流上重复使用同一个数值作为Stream I D。
Stream I D的最小有效位(0x01)标识流的发起者。客户端发起的流的I D是偶数(该位被置为0),服务端发起的流的I D是奇数(该位被置为1)。
Stream I D的次小有效位(0x02)标识流是双向流(该位被置为0)抑或单向流(该位被置为1)。
也就是说,Stream I D的最小两个有效位用来标识一条流是总共四种流类型中的哪一种,总结在如下表:
于是,在申请流过程中,如果需要QU I C连接支持双向实时通信,则设置Stream ID次小有效位=0x00即可。
进一步的,所述若干个传输协议流相互独立且各自拥有一个独立的滑动窗口,所述若干个传输协议流的标识数值由所述客户端与所述服务端共同决定,各传输协议流对应的标识数值各不相同。
在一个优选的实施例中,一条QU I C连接上可以通过若干个传输协议流并行发送多个请求。每一个传输协议流都分配了一个独立的滑动窗口,这样使得一个连接上的多个传输协议流之间没有依赖关系,都是相互独立的,当出现某个传输协议流丢失数据时,不会影响其他传输协议流,其他传输协议流中的数据可以顺利提交给应用层处理。
通过在连接中设置多个相互独立的流通道并行发送业务信息,解决TCP存在的队头阻塞问题,提高了连接的便捷性。
对于步骤S104,具体的,所述客户端与所述服务端通过所述若干个传输协议流进行通信,具体包括:
所述客户端通过所述若干个传输协议流与所述服务端连接,所述服务端通过连接的所述唯一标识符与传输协议流的所述唯一标识数值对所述客户端进行绑定,在通信过程中,所述客户端与服务端使用QU I C作为传输协议,所述通信数据为TR069协议信令数据。
在一个优选的实施例中,当QU I C连接建立完后,服务端主要是通过标识符Connect i on I D来标识与CPE设备的QU I C网络连接,另外结合标识数值StreamI D标识与客户端的业务数据的网络传输通道,服务端通过内存存储Connect i on I D对客户端设备进行绑定,然后利用Stream I D找到对应的传输协议流,即可向客户端设备实时发送数据。
在一个优选的实施例中,参见图2,在双方通信的过程中,客户端设备通过互联网与服务端连接,使用QUI C作为传输协议,QU I C负载的内容为TR069协议信令数据。在现有技术中,TR069协议是使用HTTP1.1协议作为传输协议进行传输通信,而在本发明提供的一实施例中,将TR069协议的传输协议HTTP1.1协议替换为QUI C协议,由于HTTP和QUI C协议都是点对点通信的协议,因此除了替换对应的发送和接收模块外,替换完成后TR069协议的其他整体框架没有变化。
参见图3,本发明另一实施例对应提供了一种远程终端管理系统,包括:客户端301、服务端302、若干个QUI C通信模块303以及连接平台304;
所述客户端301用于执行如上述发明实施例所述的一种远程终端管理方法;
所述服务端302用于当客户端需要与服务端建立连接时,接收客户端发送的QUI C握手请求,在同意握手后,服务端根据本地存储的第一服务端配置参数和所述握手请求中的公开数,计算出第一初始密钥,并向客户端反馈握手同意信息;其中,所述握手同意信息是根据所述第一初始密钥和临时随机数而加密生成;所述服务端还根据所述第一初始密钥和临时随机数生成第一会话密钥;
所述若干个QUI C通信模块303分别位于客户端与服务端,所述客户端与服务端通过所述若干个QUI C通信模块进行通信;
所述连接平台304依靠互联网进行搭建,用于承载所述客户端与服务端之间的连接,以使所述客户端与所述服务端通过所述连接中的若干个传输协议流进行通信。
与现有技术相比,本发明实施例公开的一种远程终端管理系统通过客户端和服务端共同协商初始密钥,再由所述初始密钥计算会话密钥完成双方的连接建立,最后在双方的连接中建立多个传输协议流,各传输协议流可设置为不同类型,解决了TR069协议不能双向实时通信的问题,提升交互的便捷性。
需说明的是,本发明方法不仅适用于5G网络通信场景,也适用于有线WAN、4G、WI FI、Lora等网络场景。本发明方法实现以CPE设备为例,实际上可替换为任意支持TR069功能的路由设备,如企业路由器、家庭路由器设备、W I F I路由器、光路由、4G/5G CPE、VO I P设备、M I F I等设备。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围。