RFB（プロトコル）

RFB（Remote FrameBuffer ）は、グラフィカルユーザーインターフェースへのリモートアクセスのためのオープンでシンプルなプロトコルです。Microsoft Windows、macOS、X Window System、Waylandなど、あらゆるウィンドウシステムとアプリケーションに適用できます。

RFB は、仮想ネットワーク コンピューティングおよびその派生で使用されるプロトコルです。

説明

RFB は仮想ネットワークコンピュータの基盤です。デフォルトでは、ビューア/クライアントは TCP ポート 5900 を使用してサーバーに接続します（ブラウザアクセスの場合は 5800）。ただし、他のポートを使用するように設定することもできます。また、サーバーは「リスニングモード」（デフォルトではポート 5500）でビューアに接続することもできます。リスニングモードの利点の一つは、サーバー側でファイアウォール/NAT を設定して特定のポートへのアクセスを許可する必要がないことです。設定の負担はビューア側で行われるため、サーバー側にコンピュータの専門知識がなく、ビューア側にはより詳しい知識が求められる場合に便利です。

RFBは当初比較的シンプルなプロトコルでしたが、開発の過程でファイル転送などの追加機能や、より高度な圧縮・セキュリティ技術が導入され、強化されてきました。様々なVNCクライアントとサーバーの実装間でシームレスな相互互換性を維持するため、クライアントとサーバーは、双方がサポート可能な最適なRFBバージョンと、最適な圧縮・セキュリティオプションを使用して接続をネゴシエートします。

歴史

RFBは元々、オリベッティ研究所（ORL）において、ビデオタイルと呼ばれる非同期転送モード接続を備えたシンプルなシンクライアントで使用するリモートディスプレイ技術として開発されました。デバイスを可能な限りシンプルに保つため、RFBは既存のリモートディスプレイ技術よりも優先して開発され、使用されました。

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

2002年にORLが閉鎖された後、VNCとRFBの主要メンバーの一部がRealVNC Ltd.を設立し、VNCの開発を継続し、RFBプロトコルの保守に努めました。現在のRFBプロトコルはRealVNCのウェブサイトで公開されています。

バージョン

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

バージョン出版日付仕様
RFB 3.3オリベッティ（ORL）1998年1月リモートフレームバッファプロトコル 3.3
RFB 3.7RealVNC株式会社2003年8月リモートフレームバッファプロトコル 3.7
RFB 3.8（現在）RealVNC株式会社2007年6月リモートフレームバッファプロトコル 3.8
IETF RFC (3.8)RealVNC株式会社2011年3月RFC  6143

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

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

エンコーディングの種類

ネゴシエーションには複数のエンコーディングが用いられる。一部のエンコーディングは、特定の拡張機能を処理できることをアドバタイズするために使用される擬似エンコーディングである。[要出典]エンコーディングには以下が含まれる: [2]

  • 生
  • ズリブ
  • きつい
  • XZ
  • H.264
  • タイトPNG

公開されている画像ベースのエンコーディングの中で、最も効率的なのはTightエンコーディングです。TightVNCでは、Tightエンコーディング（ZlibとJPEGによる長方形、パレット、グラデーションの塗りつぶしに加え、Zlibとフィルタによる「基本圧縮」を組み合わせたもの）[3]とTight PNGエンコーディング（基本圧縮をPNGデータに置き換えたTightエンコーディング）の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 ただし、RFBプロトコルのコミュニティバージョンでは、「QEMUオーディオ」拡張機能が定義されています。[2]

参照

参考文献

  1. ^ 「リモートフレームバッファ（RFB）」www.iana.org。
  2. ^ abcdef 「RFBプロトコル、コミュニティ版」。GitHub 。 2025年5月12日。
  3. ^ 「VNC Tight Encoder - 比較結果」www.tightvnc.com。
  4. ^ Commander, DR. 「VNC環境におけるH.264エンコーディングの有用性に関する研究」turbovnc.org。
  5. ^ Richardson, Tristan (2010). 「セクション6.4.6、6.5.4」. RFBプロトコル - バージョン3.8 .
  • RFBプロトコル - コミュニティバージョン
  • RFC 6143: リモートフレームバッファプロトコル（バージョン3.8、2011年について説明）
  • RFBプロトコル - バージョン3.8（2010年11月26日）
  • RFBプロトコル - バージョン3.7（2003年8月12日）
  • RFBプロトコル - バージョン3.3 (1998-01) 2006年12月15日アーカイブ - Wayback Machine
  • RFBプロトコル - バージョン3.3（1998-01）
  • AT&T ケンブリッジ研究所 - RFB プロトコル
Retrieved from "https://en.wikipedia.org/w/index.php?title=RFB_(protocol)&oldid=1318129728"