前回，ずいぶん遠回りしてしまったものの，なぜ手元の環境でVNCが必要となったのか，という話をしました。

VNCを使えば，隣りのマシンで動いているWindowsの画面をLinuxのデスクトップ中に表示することができ，KVMスイッチなどでキーボードや画面を切り替える必要もなく，キャプチャの開始や終了，ファイルの移動等の操作が可能になります。

この画面は，一見するとVirtualBox等の仮想環境でWindowsを動かしているのと変りなく見えます。しかし，ここで動いているキャプチャソフトはUSB外付けキャプチャボックスを操作しており，それを接続するために実際のWindowsマシン一式が必要となったわけです。

さて，それではVNCはどのようなしくみで異なる環境に画面を表示させているのでしょう？ 今回はVNCのしくみや歴史について紹介してみます。

VNCとRFB

VNCはサーバ・クライアントタイプのソフトウェアで，画面を飛ばしたい環境（上記の例ではWindows）でサーバ（vncserver）を動かし，画面を受けとりたい環境（同Linux）でクライアント（vncviewer）を動かします。VNCのサーバとクライアントはRFB（Remote Frame Buffer）という通信プロトコルを使ってデータをやりとりします。

RFBプロトコルは，"Remote Freme Buffer"という名が示すように，「⁠フレーム・バッファ」すなわち，画面データを直接やりとりするためのプロトコルです。

X Windows Systemのようにネットワーク透過に設計されたウィンドウシステムの場合，ネットワークに流れるのはX11プロトコル，すなわち画面をどのように描画するかを記述したデータになります。それに対し，RFBプロトコルでは，サーバが取得した画面データそのものがネットワーク経由でクライアントに送られます。すなわちVNCでは，サーバは常にスクリーンをキャプチャし続けてそのデータをクライアントに送り，クライアントは届いたキャプチャデータを使ってリモート環境の画面を表示しているわけです。

もちろん，キャプチャした画面データを全てそのままやりとりすると，データ量も膨大になって描画もスムーズにはいきません。そのためRFBプロトコルでは，画面を複数の領域に分割し，書き換えが必要な領域のデータのみを送ったり，データを圧縮してやりとりするような機能が定義されています。

一方，クライアントからサーバ側の環境を操作するために，クライアントが受けとったキーボードやマウスの入力をサーバ側に送信する機能もあります。RFBプロトコルでは，クライアントが受けとった入力はキーイベントやポインタイベントとしてサーバに送られ，サーバはそれらをあたかも手元で生じたイベントのように加工してOSへ送り，要求された操作を実現します。

VNCの基盤となっているRFBプロトコルは，1998年に最初のバージョン（RFB 3.3）が一般公開され，その後，数回のバージョンアップを経て，現在は2005年に公開されたバージョン3.8が広く利用されています。また，2011年にはRFC6143としてIETFにも承認され，特定の企業や組織から離れて真に誰でも自由に使えるプロトコルとなりました。

VNCの歴史と各種実装

RFBプロトコルとそれを実装したVNCというソフトウェアは，イタリアの老舗事務機器メーカのオリベッティ（Olivetti）が英国ケンブリッジ大学に設置したORL（Olivetti Research Laboratory）で行なっていたthin-clientに関する研究の中から，1998年ごろに生まれました。

"thin-client"とは，画面表示とユーザからの入力を受けとる程度の機能しか持たない端末のことです。この種の端末は単体では使いものにならないものの，ネットワーク経由で専用のサーバと接続し，必要な処理はサーバ側で行なって，端末側はその結果を表示する作業に専念するという分業体制を取ることで，通常のPCと同等の作業をこなすことができます。かつてコンピュータがずいぶん高価だったころ，低機能ながら安価な"thin-client"は十分魅力的な選択肢でした。

"thin-client"の代表がX Windows System用のX端末です。X端末はX Windows Systemの画面描画機能のみを組み込んだ安価なコンピュータで，外部のホストで動作させたX用のアプリケーションの画面を表示することができます。

前述のように，X Windows Systemの場合，ネットワーク経由でやりとりするのは画面の描画手順を記述したX11プロトコルなので，X端末はXに対応したアプリケーションの画面しか表示できません。一方，90年代も後半になってくると，WindowsやMacOSなども広く使われるようになり，より汎用性が高い"thin-client"が求められるようになりました。そこで考案されたのが，描画された画面そのものを転送しようというRFBプロトコルのアイデアで，それを実装したソフトウェアとしてVNCが生まれました。

RFBプロトコルは，画面に出力された結果を転送するように設計されているので，XやWindows，MacOSといった設計が根本から異なるウィンドウシステム間でも動作可能です。そこでORLの開発者たちは，VNCをGPLに基づくフリーソフトウェアとして公開し，さらに多くのプラットフォームに対応させようとしました。

その後，ORLはAT&Tに買収され，しばらくは「AT&Tケンブリッジ研究所」として運営されたものの，AT&T自身が経営不振におちいった結果，2002年に閉鎖されてしまいました。そこでVNCの関係者たちは，VNCの開発を継続するために自らでRealVNCという会社を設立し，RFBプロトコルを実装した新しいソフトウェアを社名と同じ"RealVNC"という名称で開発，販売することにしました。

"RealVNC"は，"VNC"の元々の開発者たちが作った正統な後継ソフトウェアではあるものの，商用ソフトウェアとして開発されているため，かってのようにソースコードは公開されず，機能が限られたトライアル版のみ無料でダウンロードできるようになっています。

一方，もともとのVNCのソースコードはGPLに基づいて公開されていたため，それを元にした派生ソフトウェアも開発されていきました。それら派生ソフトウェアは，もともとのVNCのソースコードを利用しつつ，RFBプロトコルの新バージョンに対応したり，転送するデータを効率よく圧縮したり，OpenGLの機能を利用して描画の高速化を図るなど，オリジナルには無い便利な機能が追加されています。以下，現在も開発が続いている主要なVNCソフトウェアを紹介しましょう。

TightVNC

TightVNCはオリジナルのVNCにtight encodeと呼ばれる，JPEGとzlibを用いたデータ圧縮機能を追加した派生バージョンです。"tight encode"を使えば，サーバからクライアントに送るデータ量を大幅に削減でき，ネットワークの負荷は減る反面，データの圧縮，展開にかかるCPUの負荷は増えます。

TigerVNC

TightVNCを元に，OpenGLの機能も利用して画面描画を高速化した派生バージョンです。OpenGLを利用するためにFLTK（Fast, Light ToolKit）というGUIライブラリを利用しているので，TigerVNCを使う際には事前にFLTKをインストールしておく必要があります。

TurboVNC

TightVNCとTigerVNCを元に，3D機能や動画処理に便利な機能を追加した派生バージョンです。TigerVNCの開発者のうち，3D機能や動画処理の強化に関心を持つ人々が，それらをあまり重視しないTigerVNCの開発方針に反発して立ちあげたプロジェクトです。TurboVNCでは，最近のCPUが持つ並列化機能（SIMD機能）を積極的に利用しているJpeg-turboライブラリを採用して，データの圧縮，展開の高速化を目指しています。

UltraVNC

元々のVNCが持っていたマルチプラットフォーム性を廃して，Windows用に特化することで性能や信頼性を高めることを目指した派生バージョンです。UltraVNC自身はWindows以外の環境では動作しないものの，Linuxで動いているVNCクライアントからUltraVNCサーバに接続したり，UltraVNCのクライアントからLinuxのVNCサーバに接続することは問題ありません。

gtk-VNC

GNOME系のデスクトップ環境が利用しているGTKツールキット向けに開発されたVNC用ウィジェットです。VNC（RFBプロトコル）の機能をGTKツールキットの一部として利用できるので，RFBプロトコルに対応したソフトウェアを簡単に作成できるものの，対応する機能的には上記専用のソフトウェアに比べるとやや見劣りがするようです。

LibVNCServer/LibVNCClient

VNCのサーバ/クライアントの機能をそれぞれライブラリとして実装したソフトウェアです。gtk-VNC同様，専用のVNCソフトウェアに比べると機能的には後追いの感があるものの，必要な機能をライブラリとして容易に利用できるため，KDE用のリモートデスクトップクライアントKRDCやVirtualBoxの組み込みVNCサーバ機能などがこのライブラリを利用しています。