CN111741091A - 一种隐藏noVNC服务器IP及端口号的方法、装置及电子设备 - Google Patents

Abstract

本发明提供了一种隐藏noVNC服务器IP及端口号的方法、装置及电子设备，该方法使用中间层微服务对自客户端发起的访问请求执行解析服务，配置于中间层微服务中的开源网关修改自服务端对所述访问请求作出响应的html信息中所包含的IP及端口号执行修改，并在客户端中予以展现。通过本发明，解决了通过客户端中的浏览器展现返回的html信息安全性不佳的技术问题，有效地防止了用户在嵌布浏览器的客户端入侵部署noVNC服务器的物理机或者物理节点，在保证系统的安全性的同时又能显著地降低系统的部署成本及部署难度。

Description

一种隐藏noVNC服务器IP及端口号的方法、装置及电子设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种隐藏noVNC服务器IP及端口号的方法、装置及一种电子设备。

背景技术

noVNC服务器提供一种在浏览器上通过html5的Canvas，访问机器(即计算机或者集群服务器)上VNC服务器提供的VNC服务，需要执行TCP到WebSocket的转化，才能在html5中显示出来。浏览器作为一个客户端，类似windows操作系统中的vncviewer，只是此时携带的并不是裸露的VNC服务器的IP及端口号(PORT)，而是由noVNC服务器提供的websockets的代理，在noVNC服务器上配置每个VNC服务，noVNC服务器提供一个标识，去反向代理所配置的VNC服务。

noVNC系统被普遍用在各大云计算、虚拟机控制台中，比如OpenStack Dashboard和OpenNebula Sunstone。云平台，包括但不限于公有云、私有云、混合云等，都会提供一个连接虚机控制台的URL地址，甚至某些云平台所包含的远程控制台地址是以noVNC服务器来提供的远程控制台访问的，比如OpenStack的nova组件。NoVNC服务器可以让用户直接使用浏览器，以操作虚拟机(VM)，而无需再安装另外的程序。

然而，在用户使用noVNC的URL地址访问虚拟机或者对虚拟机执行具体的操作时，URL地址及由浏览器展现的html页面中会暴露虚拟机所在的物理机或者物理节点的IP地址及noVNC的端口号。因此，物理机或者物理节点的IP容易受到攻击或者泄露，从而导致云平台的安全性不高。虽然公开号为CN102523207A的中国发明专利等现有技术虽然指出VNC服务器可通过认证服务器等安全机制，以提高VNC客户端对部署于物理节点中的VNC服务器进行访问及操作时的安全性，但这又直接导致系统的部署成本及部署难度的增加。

有鉴于此，有必要对现有技术中的隐藏noVNC服务器IP及端口号的方法予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示一种隐藏noVNC服务器IP及端口号的方法、装置及电子设备，用以克服现有技术所存在的上述缺陷，尤其是为了解决通过客户端中的浏览器展现返回的html信息安全性不佳的技术问题，防止用户在嵌布浏览器的客户端入侵部署noVNC服务器的物理机或者物理节点，在保证系统的安全性的同时又能降低系统的部署成本及部署难度。

为实现上述第一个目的，本发明提供了一种隐藏noVNC服务器IP及端口号的方法，

使用中间层微服务对自客户端发起的访问请求执行解析服务，配置于中间层微服务中的开源网关修改自服务端对所述访问请求作出响应的html信息中所包含的IP及端口号执行修改，并在客户端中予以展现。

作为本发明的进一步改进，所述方法包括以下步骤：

S1、中间层微服务接收客户端发起的访问请求，自服务端调用与访问请求所对应的noVNC服务器所匹配的IP及端口号；

S2、根据访问请求生成唯一的token并与仅向服务端暴露的URL进行绑定，以生成新的URL；

S3、由新的URL保存https与WebSocket确定路由关系并将所述路由关系推送至客户端；

S4、向客户端重新输入新的URL，通过开源网关修改http请求头中的Host信息及Origin信息，并根据新的URL及所述路由关系确定https与WebSocket的转发路径；

S5、从服务端调用noVNC地址列表，使用开源网关使用noVNC地址列表修改html返回的http请求体所携带的IP及端口号，并在客户端中予以展现。

作为本发明的进一步改进，所述服务端由至少一个物理节点构成，所述物理节点中部署至少一个noVNC服务器，所述中间层微服务与服务端在逻辑上均彼此独立。

作为本发明的进一步改进，所述物理节点保存至少一个由与客户端所发起的访问请求与noVNC服务器建立映射关系所形成的noVNC地址列表，所述noVNC地址列表以轻量级文件的形式保存于服务端，所述轻量级文件选自txt文件、JSON文件或者XML文件。

作为本发明的进一步改进，所述中间层微服务调用所述noVNC地址列表，并通过所述noVNC地址列表搜索出与访问请求所对应的noVNC服务器IP及端口号，隐藏所述noVNC服务器IP及端口号。

作为本发明的进一步改进，所述开源网关选自OpenResty、Kong、Zuul2或者SpringCloudGateway。

作为本发明的进一步改进，所述中间层微服务配置失效定时器，所述失效定时器对中间层微服务向客户端返回的html信息所对应的唯一的token设置有效期，失效定时器所设定的有效期的时间轴长度由noVNC服务器确定。

作为本发明的进一步改进，所述token的有效期不超过5分钟。

基于相同发明思想，本申请还揭示了一种隐藏noVNC服务器IP及端口号的装置，包括：

逻辑上独立于客户端与服务端的中间层微服务，所述中间层微服务配置开源网关；所述中间层微服务对自客户端发起的访问请求执行解析服务，配置于中间层微服务中的开源网关修改自服务端对所述访问请求作出响应的html信息中所包含的IP及端口号执行修改，并在客户端中予以展现。

作为本发明的进一步改进，所述服务端由至少一个物理节点构成，所述物理节点中部署至少一个noVNC服务器，所述中间层微服务与服务端及物理节在逻辑上均彼此独立；所述开源网关选自OpenResty、Kong、Zuul2或者Spring Cloud Gateway。

最后，本申请还揭示了一种电子设备，包括：

处理器，由至少一个存储单元组成的存储装置，以及

在处理器与存储装置之间建立通信连接的通信总线；

所述处理器用于执行存储装置中存储的一个或者多个程序，以实现如上述任一项发明创造所述的隐藏noVNC服务器IP及端口号的方法。

作为本发明的进一步改进，所述电子设备至少被配置为计算机、服务器、数据中心、虚拟集群、便携式移动终端。

与现有技术相比，本发明的有益效果是：

在本申请中，使用中间层微服务对用户自客户端发起的访问请求所对应的URL生成唯一的token并与仅向服务端暴露的URL进行绑定，以生成新的URL，然后在客户端中基于该新的URL及所述路由关系确定https与WebSocket的转发路径，在满足基于VNC系统对位于远端的服务端中的虚拟机或者虚拟资源进行访问的同时，解决了通过客户端中的浏览器展现返回的html信息安全性不佳的技术问题，有效地防止了用户在嵌布浏览器的客户端入侵部署noVNC服务器的物理机或者物理节点；

同时，由于新的URL与唯一的token进行绑定并为中间层微服务向客户端返回的html信息通过失效定时器对所对应的唯一的token设置有效期，有效地保证了整个系统(即服务端或者包含服务端的云平台)的安全性；并且，由于不需要使用认证服务器等安全机制以保证包向客户端返回与访问请求所对应的html信息的安全性，因此在保证系统的安全性的同时又能降低系统的部署成本及部署难度。

附图说明

图1为本发明一种隐藏noVNC服务器IP及端口号的方法的整体流程图；

图2为一种隐藏noVNC服务器IP及端口号的装置的拓扑图；

图3为基于图2示出的隐藏noVNC服务器IP及端口号的装置获取noVNC地址的示意图；

图4为隐藏noVNC服务器IP及端口号的装置中服务端由至少一个物理节点构成且与中间层微服务分别部署于两个独立的计算装置的示意图；

图5为隐藏noVNC服务器IP及端口号的装置中服务端由至少一个物理节点构成且与中间层微服务同时部署于一个计算装置但逻辑上相互独立的示意图；

图6为转发前noVNC地址在客户端的浏览器所显示的URL的一种实例；

图7为转发后noVNC地址在客户端的浏览器所显示的URL的一种实例；

图8为本发明一种电子设备的拓扑图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。在本实施例中，术语“IP”与“IP地址”具等同技术含义。

实施例一：

本实施例首先揭示了一种隐藏noVNC服务器IP及端口号的方法(以下简称“方法”)的具体实施例。申请人对本实施例所揭示的方法予以概述。

结合图2所示，该隐藏noVNC服务器IP及端口号的方法，使用中间层微服务20对自客户端10发起的访问请求执行解析服务，配置于中间层微服务20中的开源网关21修改自服务端30对由用户在客户端10中发起的访问请求作出响应的html信息中所包含的IP及端口号执行修改，并在客户端10中予以展现。该方法对服务端30中的一个或者多个物理节点中的noVNC服务器的IP及端口号进行替换，从而实现了对noVNC服务器的IP及端口号进行隐藏的目的，并使得用户在客户端10的可视化界面，例如浏览器中，无法获悉VNC服务器的IP及端口号。安装有VNC客户端的客户端10通过与安装有VNC服务器的私网主机(即物理节点)所承载的任意一台虚拟机建立连接，实现对私网主机的远程访问和远程控制，确保了对私网主机(即物理节点)进行远程访问过程的安全性。尤其的，申请人指出本实施所揭示的方法不需要基于网络地址转换(NAT)或者隧道服务对VNC服务器的IP执行转换与解析，并简化了应用该方法的装置(如实施例二所示)及电子设备(如实施例三所示)的拓扑结构，降低了部署及维护难度。

如图1及图2所示，本实施例所揭示的一种隐藏noVNC服务器IP及端口号的方法包括以下步骤。

步骤S1、中间层微服务20接收客户端10发起的访问请求，自服务端10调用与访问请求所对应的noVNC服务器所匹配的IP及端口号。

参图3所示，客户端10与服务端30之间可部署一个或者多个中间层微服务20，服务端30中保存noVNC地址列表31。客户端10发起获取noVNC服务器地址的请求，该请求包含noVNC服务器的IP地址及端口号。中间层微服务20具有微服务架构(MicroserviceArchitecture)，并以中间件的形式运行于逻辑上独立于服务端30的计算机系统或者计算介质或者虚拟机或者虚拟服务器或者内存或者虚拟内存中，甚至还可以是JVM(JAVA虚拟机)。用户在客户端10中以HTTP请求的方式发起对noVNC服务器_1可访问的URL。

步骤S2、根据访问请求生成唯一的token并与仅向服务端30暴露的URL进行绑定，以生成新的URL。Token由中间层微服务20所创建，且token与客户端10发起的访问请求一一对应，相同用户发起的内容相同的访问请求或者不同用户发起的内容不相同的访问请求所生成的token是唯一的，并与独立的访问请求一一对应。中间层微服务20从服务端30中调用包含noVNC服务器IP及端口号的noVNC地址列表31，并基于步骤S1中所确定的与访问请求具有映射关系的noVNC服务器所匹配的IP及端口号，以确定访问请求所对应的具体物理节点及其物理节点中的虚拟机的内网IP。服务端30向中间层微服务20作出响应后，由中间层微服务20生成唯一的token，并将生成的token集成到前述URL中，具体参图6所示。

如图6所示，客户端10嵌布形成可视化界面101，该可视化界面可为浏览器。可视化界面101由内容栏103及显示URL的地址栏102。在URL转换前，noVNC服务器_1提供的URL具体如下所示：

http://10.20.10.4:7080/vnc_auto.html？token＝6a5ab7db-8900-4a89-9d79-a2b035115bd8；其中，“10.20.10.4”是noVNC服务器_1的IP地址，“7080”是noVNC服务器_1的端口号，“6a5ab7db-8900-4a89-9d79-a2b035115bd8”是本次自客户端10发起的访问请求所生成的唯一的token值。

如图7所示，其示出了由中间层微服务20对上述URL进行截取改造后的新的URL实例，具体如下所示：

http://10.20.10.11/a77bd57d1ec0bd0c3495b395444e7458/console？token＝0f5b52dc-0989-4332-b43e-be1d3324fd78；其中，“10.20.10.11”为中间层微服务20的IP地址，“a77bd57d1ec0bd0c3495b395444e7458/console？”为由中间层微服务所生成的与对URL进行截取改造操作所生成的对应关系的值，该对应关系是指URL与noVNC服务器_1所具有的IP和端口号的映射关系；“token＝0f5b52dc-0989-4332-b43e-be1d3324fd78”为对前述的token值由中间层微服务重新生成一个新的token，该新的token与之前基于用户的访问请求所第一次生成的token不同。

在本实施例中，中间层微服务20对接收到上述URL进行截取改造，并具体为将前述noVNC服务器_1提供的URL中的noVNC服务器_1的IP地址及端口号全部去除，并确保新的URL中不存在noVNC服务器_1的IP地址及端口号，同时对前述的token值重新生成一个新的token，并将该新的token集成到新的URL中，作为中间层微服务20对客户端10作出响应的新的URL，具体参图7所示。在整个截取改造过程中，中间层微服务20并不对客户端10进行暴露，而仅向noVNC服务器-1及服务端30进行暴露，用户在客户端10无法感知截取改造过程。

步骤S3、由新的URL保存https与WebSocket确定路由关系并将所述路由关系推送至客户端10。确定https与WebSocket所形成的路由关系能够将用户在客户端10发起的访问请求引导至服务端30指定的物理节点中的指定的noVNC服务器，例如图4中的noVNC服务器_1。

步骤S4、向客户端10重新输入新的URL，即在图7的地址栏102中由用户重新输入新的URL。然后将新的URL所表征的http请求发送至中间层微服务20，并由中间层微服务20所配置的开源网关21修改http请求头中的Host信息及Origin信息，并根据新的URL及所述路由关系确定https与WebSocket的转发路径。重新确定的转发路径被保存在noVNC地址列表31中。

步骤S5、从服务端30调用noVNC地址列表31，使用开源网关21使用noVNC地址列表31修改html返回的http请求体所携带的IP及端口号，并在客户端10中予以展现。客户端10最终为用户展现基于访问请求所展现的信息或者数据。此处的“修改”具体为根据前述步骤S3中所确定的路由关系，将客户端10重新传入的新的URL中所包含的noVNC服务器_1的IP及端口号进行替换的操作。因此，本实施例所揭示的方法不需要对访问请求通过隧道服务来执行IP地址及端口号的解析。

配合参照图4及图5所示，在本实施例中，该服务端30由至少一个物理节点构成，物理节点中部署至少一个noVNC服务器，中间层微服务20与服务端30在逻辑上均彼此独立。具体的，参图4所示，服务端30可由物理节点_1至物理节点_n组成，参数n取大于或者等于二的正整数。物理节点_1中部署VM31、VM32等多个虚拟机，以及noVNC服务器_1(IP地址为10.20.10.4)，物理节点_n中部署VM34、VM35等多个虚拟机，以及VNC服务器_n。中间层微服务的IP地址为10.20.10.11。

物理节点_1中保存至少一个由与客户端10所发起的访问请求与noVNC服务器_1(IP地址：10.20.10.4)建立映射关系所形成的noVNC地址列表31，所述noVNC地址列表31以轻量级文件的形式保存于服务端30；具体的，该轻量级文件选自txt文件、JSON文件或者XML文件。

参图2所示，中间层微服务20调用所述noVNC地址列表31，并通过所述noVNC地址列表31搜索出与访问请求所对应的noVNC服务器IP及端口号，隐藏所述noVNC服务器IP及端口号。开源网关21选自OpenResty、Kong、Zuul2或者Spring Cloud Gateway，并在本实施例中该开源网关21优选为Spring Cloud Gateway。

Spring Cloud Gateway旨在为中间层微服务20提供简单、有效和统一的API路由管理方式，其不仅提供统一的路由方式，并且还基于Filter链的方式提供了网关基本的功能，例如安全、监控/埋点、限流等功能。中间层微服务20可执行程序形式保存并运行于物理内存、虚拟内存或者逻辑上独立于服务端30的数据库或者服务器中，且不需要实时地保存到具体路径的文件中。

重新参图2所示，在本实施例中，中间层微服务20配置失效定时器22，并由失效定时器22对中间层微服务20向客户端10返回的html信息所对应的唯一的token设置有效期，失效定时器22所设定的有效期的时间轴长度由noVNC服务器确定，失效定时器22所设定的有效期发送至开源网关21。具体的，由失效定时器22所设定的token的有效期不超过5分钟。通过上述技术方案，进一步提高了该方法以及基于该方法的实施例二揭示的隐藏noVNC服务器IP及端口号的装置在响应用户发起的访问请求并予以响应过程中的安全性，以确保每个访问请求所生成的token及新的token不会被持久的暴露在外部攻击中，尤其是来自于客户端10发起的恶意攻击。

当超过token的有效期后，客户端10会重新接收到中间层微服务20发送的另一个新的URL(其包含另一个新的token)，以供用户在客户端10重新发起对noVNC服务器_1的访问请求，从而确保了每次访问请求的安全性，从而有效地防止了用户在嵌布浏览器的客户端10入侵部署noVNC服务器的物理机或者物理节点。

通过本实施例所揭示的方法，有效地保证了应用该方法的整个系统，例如服务端30或者包含服务端30的云平台或者集群服务器或者数据中心的安全性。同时，由于不需要使用认证服务器等安全机制以保证包向客户端10返回与访问请求所对应的html信息的安全性，因此在保证系统的安全性。由于中间层微服务20具有只关注业务层面且能够独立地提供对外服务，因此能够显著降低系统(参前文所述)的部署成本及系统的部署难度。

实施例二：

参图2至图5所示，本实施例基于实施例一所揭示的方法还揭示了一种隐藏noVNC服务器IP及端口号的装置(以下简称“装置”)的一种实施例。该装置运行如实施例一所揭示的方法。

在本实施例中，该装置包括逻辑上独立于客户端10与服务端30的中间层微服务20，中间层微服务20配置开源网关21，并优选的配置失效定时器22。失效定时器22对中间层微服务20向客户端10返回的html信息所对应的唯一的token设置有效期，失效定时器22所设定的有效期的时间轴长度由noVNC服务器确定。

具体的，由失效定时器22所设定的token的有效期不超过5分钟。中间层微服务20对自客户端10发起的访问请求执行解析服务，配置于中间层微服务20中的开源网关21修改自服务端30对所述访问请求作出响应的html信息中所包含的IP及端口号执行修改，并在客户端10中予以展现，并具体为在客户端10所形成的浏览器的可视化界面101由内容栏103予以展现与访问请求所对应的信息或者数据。

服务端30由至少一个物理节点构成，物理节点中部署至少一个noVNC服务器，中间层微服务20与服务端30在逻辑上均彼此独立。开源网关21选自OpenResty、Kong、Zuul2或者Spring Cloud Gateway。

在本实施例中，该开源网关21选自Zuul2。

Zuul2基于Netty Server实现了异步IO来接入访问请求，同时基于Netty Client实现了到后端业务服务API的请求，从而具有更高的性能及更低的延迟的技术优势。

尤其的，结合参照图4及图5所示，本实施例中所谓“中间层微服务20与服务端30在逻辑上均彼此独立”并不排除中间层微服务20仅以运行于内存或者虚拟内存的形式运行于服务端30或者服务端30中具体的物理节点中的形式。中间层微服务20既可以运行于内存或者虚拟内存的形式运行于独立于并与服务端30或者服务端30中具体的物理节点建立网络通信的计算机系统中(参图4所示)；也可以运行于内存或者虚拟内存的形式运行于服务端30或者服务端30中具体的物理节点中(参图5所示)，在此场景中，承载中间层微服务20的内存或者虚拟内存属于客户端30，但独立于所有的物理节点。

本实施例与实施例一中具有相同部分的技术方案，请参实施例一所述，在此不再赘述。

实施例三：

基于实施例一和/或实施例二所揭示的方法和/或装置的具体实施例，本实施例还揭示了一种电子设备500的一种具体实施例。

结合图8所述，本申请还揭示了一种电子设备500，其包括：处理器51，由至少一个存储单元组成的存储装置52，以及在处理器51与存储装置52之间建立通信连接的通信总线53。处理器51用于执行存储装置52中存储的一个或者多个程序，以实现如实施例一所揭示的一种隐藏noVNC服务器IP及端口号的方法。

具体的，该存储装置52可由存储单元521～存储单元52j所组成，其中，参数j取大于或者等于1的正整数。处理器51可为ASIC、FPGA、CPU、MCU或者其他具有指令处理功能的物理硬件或者虚拟设备。通信总线53的形式并不需要予以具体限定，I²C总线、SPI总线、SCI总线、PCI总线、PCI-E总线、ISA总线等，并可根据电子设备500的具体类型及应用场景需求予以合理变更。通信总线53并非本申请发明点，故在本申请中不予展开陈述。

存储装置52可基于Ceph或者GlusterFS等分布式文件系统，也可为RAID0～RAID7磁盘阵列，也可被配置为一块或者多块硬盘或者可移动存储装置、数据库服务器、SSD(Solid-state Disk)、NAS存储系统或者SAN存储系统组成。具体的，在本实施例中，该电子设备500可被配置为超融合一体机、计算机、服务器、数据中心、虚拟集群、便携式移动终端、Web系统、金融支付平台或者ERP系统，以及虚拟在线支付平台/系统等；其中，超融合一体机是一种高性能多节点服务器，主要是分布式存储和服务器虚拟化技术，把计算节点、存储资源、网络交换高度集成到一台1U、2U或者4U服务器中，给企业或者终端用户提供超融合基础架构设施，以全面提升企业的IT能力。

尤其的，本实施例所揭示的电子设备500可基于实施例一所揭示的一种隐藏noVNC服务器IP及端口号的方法或者包含一个或者多个实施例二所示出的一种隐藏noVNC服务器IP及端口号的装置，对基于用户在客户端10中发起的访问请求或者操作所对应的一个任务或者多个并行任务予以可靠响应，尤其是在对实时性及安全性要求非常严苛的场景，例如购物网站的在线支付系统、金融机构的结算系统、电子购票系统等场景中。

本实施例所揭示的电子设备500可被理解为具有物理形态的实体设备(例如POS机、自动取款机)，也可被理解为运行有如实施例一所揭示的一种隐藏noVNC服务器IP及端口号的方法的软件系统(财务系统或者ERP系统)或者一种互联网在线应用(APP软件)，甚至可以通过光纤或者网线互联的两台或者多台组成直连拓扑结构或者树形拓扑结构或者星型拓扑结构的计算机系统/数据中心。

本实施例所揭示的电子设备500与实施例一和/或实施例二中相同部分的技术方案，请参实施例一和/或实施例二所述，在此不再赘述。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (12)

1.一种隐藏noVNC服务器IP及端口号的方法，其特征在于，

使用中间层微服务对自客户端发起的访问请求执行解析服务，配置于中间层微服务中的开源网关修改自服务端对所述访问请求作出响应的html信息中所包含的IP及端口号执行修改，并在客户端中予以展现。

2.根据权利要求1所述的方法，其特征在于，所述方法包括以下步骤：

S1、中间层微服务接收客户端发起的访问请求，自服务端调用与访问请求所对应的noVNC服务器所匹配的IP及端口号；

S2、根据访问请求生成唯一的token并与仅向服务端暴露的URL进行绑定，以生成新的URL；

S3、由新的URL保存https与WebSocket确定路由关系并将所述路由关系推送至客户端；

S4、向客户端重新输入新的URL，通过开源网关修改http请求头中的Host信息及Origin信息，并根据新的URL及所述路由关系确定https与WebSocket的转发路径；

S5、从服务端调用noVNC地址列表，使用开源网关使用noVNC地址列表修改html返回的http请求体所携带的IP及端口号，并在客户端中予以展现。

3.根据权利要求2所述的方法，其特征在于，所述服务端由至少一个物理节点构成，所述物理节点中部署至少一个noVNC服务器，所述中间层微服务与服务端在逻辑上均彼此独立。

4.根据权利要求3所述的方法，其特征在于，所述物理节点保存至少一个由与客户端所发起的访问请求与noVNC服务器建立映射关系所形成的noVNC地址列表，所述noVNC地址列表以轻量级文件的形式保存于服务端，所述轻量级文件选自txt文件、JSON文件或者XML文件。

5.根据权利要求4所述的方法，其特征在于，所述中间层微服务调用所述noVNC地址列表，并通过所述noVNC地址列表搜索出与访问请求所对应的noVNC服务器IP及端口号，隐藏所述noVNC服务器IP及端口号。

6.根据权利要求1所述的方法，其特征在于，所述开源网关选自OpenResty、Kong、Zuul2或者SpringCloudGateway。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述中间层微服务配置失效定时器，所述失效定时器对中间层微服务向客户端返回的html信息所对应的唯一的token设置有效期，失效定时器所设定的有效期的时间轴长度由noVNC服务器确定。

8.根据权利要求7所述的方法，其特征在于，所述token的有效期不超过5分钟。

9.一种隐藏noVNC服务器IP及端口号的装置，其特征在于，包括：

逻辑上独立于客户端与服务端的中间层微服务，所述中间层微服务配置开源网关；所述中间层微服务对自客户端发起的访问请求执行解析服务，配置于中间层微服务中的开源网关修改自服务端对所述访问请求作出响应的html信息中所包含的IP及端口号执行修改，并在客户端中予以展现。

10.根据权利要求9所述的装置，其特征在于，所述服务端由至少一个物理节点构成，所述物理节点中部署至少一个noVNC服务器，所述中间层微服务与服务端在逻辑上均彼此独立；所述开源网关选自OpenResty、Kong、Zuul2或者Spring Cloud Gateway。

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

处理器，由至少一个存储单元组成的存储装置，以及

在处理器与存储装置之间建立通信连接的通信总线；

所述处理器用于执行存储装置中存储的一个或者多个程序，以实现如权利要求1至8中任一项所述的隐藏noVNC服务器IP及端口号的方法。

12.根据权利要求11所述的电子设备，其特征在于，所述电子设备至少被配置为计算机、服务器、数据中心、虚拟集群、便携式移动终端。

Images