このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
RFB は、バイト指向の通信プロトコルである。
クライアントとサーバの間では、
メッセージと呼ばれる可変長のデータ構造の塊を
相互に受け渡して通信を行う。
クライアントがサーバに接続すると、
最初にプロトコルのバージョンや、
認証や解像度の取り決めなどの交渉を行う。
これは、ハンドシェイクと呼ばれている。
ハンドシェイクが終わると、セッションが確立され、
イベント駆動型の通信に移行する。
クライアントが任意のタイミングでメッセージを送り、
サーバがそれに対して返事をする形となる。
利用者が操作しなければメッセージは（ほとんど）流れない。
クライアントがサーバに送信するのは、
主に入力に関するメッセージである。
利用者の操作に対応して、マウスの移動、押下・解放や、
キーボードの押下・解放等のイベントを、
定められたメッセージにカプセル化してサーバに送る。
サーバがクライアントに送信するのは、
主に画面表示に関するメッセージである。
クライアントの入力メッセージに対応して、
画面上の任意の矩形領域の情報をクライアントに送り返す。
昨日述べたように、画面のデータ量は膨大なものになるが、
RFB では差分更新と、多彩な矩形符号化手法を用いて、
通信量を大幅に削減する仕組みを定めている。
差分更新とは、変化があった領域のデータだけを送る方法だ。
また、常に画面全体のビットデータを送るのではなく、
幾つかの矩形領域に分けて送信することで、
不定形な更新領域（L 字型等）でも効率よく対応できる。
符号化手法とは、矩形領域を表現するための様々な方法だ。
矩形領域の画素データそのままでは効率が悪いので、
単 1 色の矩形に対する最適な圧縮表現や、
既に表示されている他の領域のコピー、
そして zlib による圧縮などの方法を定めている。
RFB は、符号化を拡張できるように制定されているため、
VNC を発展させたソフトウェアは数多く存在し、
効率のよい独自に符号化機能を持つ実装も存在する。
RFB 自身は暗号化や認証機能については定めていない。
簡単な単一のパスワード認証は存在するのだが、
RFB の特性を考えるとこれだけでは安全とは言えない。
実は、RFB は下位層として使う通信基盤を限定していない。
VNC では、RFB を TCP の層の上で利用しているので、
SSH などの持っているトンネリング機能を使えば、
通信経路に SSL や認証を被せることは可能である。