RFB (プロトコル)

RFB (「リモート フレームバッファ」) は、グラフィカル ユーザー インターフェイスへのリモート アクセス用のオープンでシンプルなプロトコルです。フレームバッファレベルで動作するため、Microsoft Windows、macOS、X Window System、Waylandなど、すべてのウィンドウ システムとアプリケーションに適用できます。RFB は、 Virtual Network Computing (VNC) とその派生製品で使用されるプロトコルです。

デフォルトでは、ビューア/クライアントは TCP ポート 5900 を使用してサーバーに接続します (ブラウザー アクセスの場合は 5800)。ただし、他のポートを使用するように設定することもできます。また、サーバーは「リスニング モード」でビューアに接続できます (デフォルトではポート 5500)。リスニング モードの利点の 1 つは、サーバー サイトがファイアウォール/NAT を設定して、指定されたポートへのアクセスを許可する必要がないことです。その負担はビューア側にあります。これは、サーバー サイトにコンピューターの専門知識がない場合に便利ですが、ビューア ユーザーはより詳しい知識を持っていることが期待されます。

RFB は比較的単純なプロトコルとして始まりましたが、開発が進むにつれて、追加機能 (ファイル転送など) や、より高度な圧縮およびセキュリティ技術によって強化されてきました。さまざまな VNC クライアントとサーバーの実装間でシームレスな相互互換性を維持するために、クライアントとサーバーは、最適な RFB バージョンと、両方がサポートできる最も適切な圧縮およびセキュリティ オプションを使用して接続をネゴシエートします。

RFB はもともと、ビデオタイルと呼ばれる非同期転送モード接続を備えたシンプルなシンクライアントで使用されるリモート ディスプレイ テクノロジとして、Olivetti Research Laboratory (ORL)で開発されました。デバイスをできるだけシンプルに保つために、RFB は既存のリモート ディスプレイ テクノロジよりも優先して開発され、使用されました。

RFB は、VNC が開発されたときに、2 番目でより永続的な用途を見つけました。VNC はオープン ソースソフトウェアとしてリリースされ、RFB 仕様は Web 上で公開されました。それ以来、RFB は誰でも使用できる無料のプロトコルとなっています。

2002 年に ORL が閉鎖された後、VNC と RFB の主要人物の一部がRealVNC社を設立し、VNC の開発を継続し、RFB プロトコルを維持しました。現在の RFB プロトコルは RealVNC の Web サイトで公開されています。

RFB プロトコルの公開バージョンは次のとおりです。

開発者はエンコーディングとセキュリティのタイプを自由に追加できますが、番号が衝突しないように、プロトコルの保守担当者にこれらの固有の識別番号を予約する必要があります。タイプ番号が衝突すると、接続のハンドシェイク時に混乱が生じ、実装間の相互互換性が損なわれます。エンコーディングとセキュリティのタイプのリストは、RealVNC Ltd によって管理されており、プロトコル仕様とは別になっているため、仕様を再発行することなく新しいタイプを追加できます。2012 年 12 月以降、リストはIANAに渡されました。^[1]

既存のすべての拡張機能を文書化することを目的としたRFBプロトコル仕様のコミュニティバージョンは、TigerVNCプロジェクトによってホストされています。^[2]

複数のエンコーディングがネゴシエーションの一部です。エンコーディングの一部は、特定の拡張機能を処理できることを宣伝するために使用される疑似エンコーディングです。^{[引用が必要]}エンコーディングには次のものが含まれます: ^[2]

• 生
• ズリブ
• きつい
• XZ
• 264 形式
• タイトPNG

公開されている画像ベースのエンコーディングのうち、最も効率的なのは Tight エンコーディング タイプです。TightVNC では、Tight エンコーディング (zlib と JPEG を使用した長方形、パレット、グラデーションの塗りつぶしと、Zlib とフィルタによる「基本圧縮」の混合) ^[3]と Tight PNG エンコーディング (基本圧縮をPNGデータに置き換えたタイト エンコーディング) の 2 種類のエンコーディングが定義されています。

H.264 はRFB データのエンコードに研究されてきましたが、 TurboVNC開発者は予備的な結果 (Open H.264 形式を使用) を満足のいくものではないと評しました。I フレーム (キーフレーム) が少ないほど効率は上がりますが、CPU 使用率は依然として問題です。^[4]

クリップボードデータの転送に関しては、「現在、Latin-1文字セット以外のテキストを転送する方法はありません」。^[5]一般的な疑似エンコーディング拡張は、拡張形式でUTF-8を使用することでこの問題を解決します。 ^{[2] : § 7.7.27}

VNC プロトコルはピクセルベースです。これにより柔軟性が高まりますが (つまり、あらゆるタイプのデスクトップを表示できます)、X11やRDPなどのデスクトップなどの基盤となるグラフィック レイアウトをよりよく理解するソリューションよりも効率が劣ることがよくあります。これらのプロトコルは、グラフィック プリミティブまたは高レベルのコマンドをより単純な形式 (例: ウィンドウを開く) で送信しますが、RFB は圧縮されていても生のピクセル データのみを送信します。

VNC プロトコルはマウス ボタンの状態を 1 バイトで表現し、バイナリ アップ/ダウンとして表します。これにより、マウス ボタンの数は 8 個に制限されます (ボタン 0 が「無効」を意味するという慣例により、実質的には 7 個になります)。最近のマウスの多くは 9 個以上のボタンを列挙するため、進む/戻るボタンは RFB では効果がありません。この問題は、「GII」拡張機能によって解決されます。^{[2] : § 7.7.11}

サウンドデータを転送するための標準は全くありませんが、唯一の例外は、サーバーがクライアントにベル（ビープ音、通知音）を鳴らすように指示することです。 ^{[2] ：§7.6.3}

• リモートデスクトップソフトウェアの比較
• 効率的なリモート X ウィンドウ システム接続を実現するNX テクノロジーとXpra
• スパイス
• リモート デスクトップ プロトコル(RDP)

• RFB プロトコル - コミュニティ バージョン
• RFC 6143: リモート フレームバッファ プロトコル (バージョン 3.8、2011 について説明)
• RFB プロトコル - バージョン 3.8 (2010-11-26)
• RFB プロトコル - バージョン 3.7 (2003-08-12)
• RFB プロトコル - バージョン 3.3 (1998-01)