HTML5執行個體：利用HTML5打造noVNC用戶端

HTML5正在成為互連網乃至各大互連網巨頭炒作的焦點，雖然規範並沒有完全定稿，但已經有部分規範的實現浮出水面，而為了搶佔市場先機，各大瀏覽器廠商紛紛推出了針對這些規範的實現。那HTML5到底能給我們帶來什嗎？今天筆者發現了一個HTML5執行個體，作者通過使用HTML5的WebSockets、Canvas和JavaScript打造出一個noVNC用戶端。vnc是一個用於遠端存取的工具，功能類似window下的遠端桌面功能。下面讓我們一起來進入HTML5的世界看看神器的HTML5給web帶來了什麼樣的翻天覆地的變化。

　　noVNC是個VNC用戶端，採用HTML 5 WebSockets、Canvas和JavaScript實現。近日，InfoQ有幸採訪到了Joel Martin以瞭解noVNC及其在HTML 5應用
開發上的經驗：

InfoQ：Joel，能否談談noVNC的整體架構，各個組件是如何搭配到一起的？

Joel：noVNC的架構主要由以下6個組件構成：

• 核心的VNC/RFB實現：該組件封裝了所有的RFB協議相關的內容，是驅動其他組件的主要狀態機器。
• Canvas抽象：該組件為HTML5 canvas API提供了一個抽象，還會進行Canvas特性檢測，對於沒有完整支援HTML5 canvas規範或是實現有問題的瀏覽器，組件會採取其他一些辦法解決這個問題。
• 使用者介面：封裝了所有的HTML DOM互動（除了canvas）。該組件會渲染頁面控制項，如串連/中斷連線按鈕、設定以及狀態反饋。noVNC的一個設計目標就是要能輕鬆加到現有的套件 當中，因此該組件是可選的。
• 協助工具功能：包含了noVNC所用的一些雜項功能與擴充，包括對JavaScript數組的擴充（使之可以當作隊列使用）、 跨瀏覽器的事件處理以及調試與日誌等。我還會從其他一些資源中引入一些JavaScript庫以處理base64編解碼和DES加密（用於VNC認證）。
• WebSockets回退：現在的大多數瀏覽器都沒有本地的WebSockets支援，因此我為這些瀏覽器添加了一個Flash（Flex）模擬器，使用 WebSockets加密技術擴充了最初的項目。
• WebSockets到TCP的代理：WebSockets標準並非純粹的TCP socket實現。標準中有類似於HTTP的握手以建立初始串連，接下來的每一幀都以0位元組開始，255位元組結束。在VNC伺服器開始支援 WebSockets前（ 我很希望能做到這一點），我們還是需要代理在WebSockets和標準的TCP sockets之間進行轉換。我已經實現了一個通用代理（有Python和C兩個版本），這對於那些從事著WebSockets開發的人來說有一定的協助 作用。

InfoQ：在開發HTML5應用時遇到的挑戰主要有哪些？開發人員需要提防哪些陷阱呢？

Joel：主要的挑戰在於對那些缺乏HTML5特性以及只支援部分HTML5特性、甚至連部分特性都支援不好的 瀏覽器提供回退支援。比如說，雖然Chrome 5和Safari 5都提供了本地的WebSockets支援，但目前的版本的Firefox和Opera則不支援。一些老版本的瀏覽器也沒有提供canvas像素操縱 API（更糟的是，有的瀏覽器雖然提供了支援，但一使用Arora 0.5就崩潰了）。發行的各個版本的Internet
Explorer都沒有內建WebSockets，甚至連最基本的內建canvas支援都沒有（IE 9 Preview開始提供canvas支援）。另一個挑戰在於跨越多個瀏覽器的效能最佳化問題。每個瀏覽器都有不同的效能特質，在同一瀏覽器的不同版本中這一 點也不盡相同（甚至同一個瀏覽器的不同作業系統版本也不一樣）。只有很少的地方需要使用到瀏覽器檢測技術，但對於效能最佳化問題，我覺得瀏覽器檢測技術是必 不可少的。

InfoQ：你都使用了哪些工具？目前的開發工具足以承擔起構建HTML5應用的重任嗎？你希望今後能出來哪些新工具呢？

Joel：我的開發環境非常精簡，使用vim（加上很多擴充）在Linux上編寫代碼。頻繁使用firefox上 的firebug和Chrome中內建的開發人員工具進行調試與分析。我還使用了Crockford的JSLint以保持JavaScript代碼的整潔 性。

我希望firebug與Chrome中的分析工具能給出比函數層級粒度更細的反饋資訊，能告訴我們哪部分代碼對垃圾收集產生了重要影響。現在noVNC代 碼還在不斷最佳化，垃圾收集器已經成為一個主要的效能瓶頸，我開始深入到其中解決問題了。

我希望出來的新工具是程式碼分析器（就像JSLint那樣），可以掃描Javascript代碼基並產生好看的瀏覽器支援表格。我期望的輸出形式是這樣的： 上面是代碼中所用的特性列表，左邊則是主要的瀏覽器與版本號碼。接下來，每個儲存格就會報告代碼使用特性的方式是否為給定的瀏覽器/版本所支援。雖說這麼做 並不會導致不同瀏覽器上代碼測試的工作量，但毫無疑問，它有助於我們在開發過程中瞭解是否已經偏離了軌道。在理想情況下，掃描器還應該檢測出 Javascript是否針對某個特性使用了恰當的檢測/問題解決辦法。

InfoQ：對於目前的規範與實現來說，要克服的局限性主要有哪些呢？

Joel：值得慶幸的是規範做的很棒。

RFB（VNC）協議的文檔在這裡http://tigervnc.org/cgi-bin/rfbproto。

這個網站提供了很好的Javascript參考資訊（包括哪個瀏覽器版本支援哪些特性）：http://www.hunlock.com/

我發現一個非常棒的網站，裡面歸納了哪些瀏覽器支援哪些特性（涵蓋了HTML5等內容），網址是http://caniuse.com/。網站http://quirksmode.org更是無價之寶（這就是著名的PPK站
點，他是知名的JavaScript圖書PPK on JavaScript的作者——譯者注），詳盡列出了哪些瀏覽器支援哪些API以及如何解決眾多的限制。我要克服的最困難的瀏覽器限制就是缺乏本地的跨瀏 覽器WebSockets支援。這是最近才出來的標準，還處在變更當中，但很多瀏覽器都紛紛採用了該標準。目前webkit支援該標準，因此Chrome 5和Safari 5都支援，不久之後iPhone也會支援。firefox 4可能也會加入對其的支援。當然了，Opera也會在不久的將來支援它。最大的問題在於IE 9是否會支援。

如前所述，我使用Flash WebSockets模擬器來支援那些沒有本地支援的瀏覽器。擴充、修複以及解決Flash（ActionScript）代碼中的bug是個艱巨的任務。 橋接Javascript和Flash也是個讓人頭疼的問題。Adobe提供了FABridge（模擬器使用到了），但這個橋太慢、太笨重，難以調試。

聽說IE 9將提供完整（速度也很快）的canvas支援後我感到興奮異常，但我還得解決舊版本IE缺乏本地canvas支援這個局限性，因為IE用的實在是太多 了。現在有兩個辦法，一個是explorercanvas，另一個是fxcanvas。前者是個JavaScript庫，它基於IE的VML支援建立了一 個canvas API；後者則是個canvas的Flash實現，但這兩個辦法都不是十全十美的。Explorercanvas不支援像素操縱（這是因為VML是向量而
非光柵），而fxcanvas則提供了一個類似於canvas的API，它存在一些嚴重的非同步處理問題。遺憾的是，相對於其他支援canvas類比的瀏覽 器來說，IE 6、7和8中的JavaScript引擎太慢了，這兩個辦法都沒法很好地應用到IE上，現在我只能期望人們使用Chrome Frame了。

InfoQ：關於noVNC項目，未來的計劃如何？

Joel：現在，我感覺最興奮的事情就是能與一些QEMU/KVM開發人員們（包括一個Google編碼之夏的學生）一起工作來設 計新的VNC編碼器，新的編碼器針對瀏覽器渲染進行了大量的最佳化，這個新的VNC/RFB編碼器會以PNG格式傳輸映像資料。除了極佳的無損映像壓縮外
（相對於緊密編碼來說），瀏覽器幾乎不需要什麼解碼工作就能渲染PNG資料流（這一點與緊密壓縮大不相同）。
WebSockets到TCP sockets代理的需求對於noVNC的普及是個障礙，我希望VNC伺服器能加入WebSockets支援，現在我的主要精力都放在了 libvncserver（用於構建不同的VNC伺服器）和QEMU/KVM上，但還是希望能協助並鼓勵其他的VNC伺服器開發人員增加對 WebSockets的支援。將WebSockets支援加到其他的VNC用戶端用處也很大，因為WebSockets協議設計之初就考慮到支援的方便性 並且可由Web伺服器代理（因此會有相容於HTTP的握手）。這將有助於解決VNC的一個老大難問題：與防火牆的互動。

之所以把這個項目命名為“noVNC”，一個原因是我還希望出現其他的“虛擬網路電腦”協議的實現，比如RDP、NX以及Red Hat的Spice協議。

如果iPhone能增加本地的WebSockets支援（顯然Flash的回退已經超出了問題本身），我就會讓noVNC運行在iPhone之上。我想增 加的一個非常有用的特性是視角與縮放支援，這對於智能手機來說也非常關鍵。對於Google來說，如果能在Android上支援noVNC將是一件多麼美 妙的事情啊。

　　Guacamole項目也採取了類似的處理方式，它同樣是 一個HTML5 VNC查看器，利用了伺服器端的代理，它使用Java編寫。目前版本的響應速度號稱可以達到VNC的水平，只要瀏覽器支援HTML5
canvas標籤就可以使用Guacamole。

　　感興趣的讀者可以在InfoQ上找到關於HTML5和RIA的更多資訊！

查看英文原文：HTML5
Case Study: Building the noVNC Client with WebSockets, Canvas and JavaScript
摘自：infoq