當前位置 主頁 > 服務器問題 > Linux/apache問題 > 最大化 縮小

    no-vnc和node.js實現web遠程桌面的完整步驟

    欄目:Linux/apache問題 時間:2019-10-08 13:40

    引言

    項目需求,要求在瀏覽器端進行遠程桌面的訪問,如圖所示:

    實現遠程桌面,需要依賴VNC協議:

    VNC(Virtual Network Computing),為一種使用RFB協議的屏幕畫面分享及遠程操作軟件。此軟件借由網絡,可發送鍵盤與鼠標的動作及即時的屏幕畫面。

    相關的參考比較少,去谷歌搜索出來的文章大多都是如何使用客戶端進行VNC的搭建與訪問,很少有將其內嵌到web里的,騰訊云有相關的功能,但因為業務安全性,咱也看不著人家咋實現的。

    再見,百度。用百度查了一次之后,我才知道原來VNC是口紅。

    所以VNC實踐之路就是如下流程:

    根據自己已有的知識與技能,設計一個VNC方案。 嘗試,分析可行性。 根據可行性修改方案細節,或推翻方案重新設計。

    從整體的最開始設計,到最終落地方案,大約經歷了以下七個方案的迭代:

    SpringBoot調用REALVNC的C++類庫,前后臺進行數據交互。失敗,因為REALVNC太貴了,客戶承受不起。 SpringBoot中模仿TightVNC實現JavaViewer獲取數據,前后臺進行數據交互。失敗,因為TightVNC JavaViewer的源碼沒注釋,看不懂。 SpringBoot中手寫VNC客戶端,前后臺數據交互。失敗,因為從0實現一個協議太復雜了,時間成本太高。 瀏覽器端只做VNC鏈接,使用原生客戶端,直接訪問主機。失敗,需要安裝軟件,且只能訪問局域網中的主機。 原生客戶端 + nginx數據轉發。失敗,需要安裝軟件,無法實現動態轉發(無法動態變更nginx配置文件)。 no-vnc + nginx數據轉發。失敗,無法實現動態轉發(無法動態變更nginx配置文件)。 no-vnc + node.js數據轉發。成功,完美實現。

    實現

    思想

    整體思想如下圖所示:nginx轉發前臺的websocket連接,為了實現外網轉發,添加開發的node.js服務器作為代理,將瀏覽器端no-vnc的websocket數據報在運輸層轉發給目標主機。

    why nginx ?

    如果思考過的話,其實發現不用nginx也能實現功能,這里使用nginx主要是減少了前臺對后臺架構的耦合。

    添加網關轉發所有請求,對前臺只暴露一個端口,不管后臺用什么技術,用什么架構,用什么微服務,在前臺看來,就好像在訪問單體應用一樣。

    就像目前的華軟項目一樣,后臺用了spring-boot、.net、node.js,各語言各框架發揮各自的優勢,通過nginx的轉發將各模塊連接起來,無論后臺的架構怎么變,對前臺毫無影響,這應該是微服務架構的最佳實踐。

    這是spring官方推薦的微服務架構圖,我們學習并實踐了api網關,spring推薦netflix zuul,我們用的nginx,在請求轉發上,二者性能不相上下。

    隨著業務需求的增長,我們肯定也會服務拆分,服務注冊,服務發現,消息隊列,RPC調用。然后用上eureka、zookeeper、hystrix、feign等一個個優秀的開源組件,一起探索spring-cloud的最佳實踐。

    websocket

    之前一直不了解websocket,就是知道個名,具體細節沒有學習。

    http協議:請求響應,客戶端請求,服務器響應,一次請求就結束。服務端無法主動向客戶端推送數據。

    為了解決這個問題,websocket應運而生。如果所示,不做贅述。

在线观看中文字幕理论片