X11フォワーディングがそれほど効率的でないのはなぜですか？

-Cスイッチを含めて、X11転送を使用して大規模なGUIをリモートで起動するたびに、エクスペリエンスが非常に応答しなくなります。私の質問は、何がコンセプト/プロトコルレベルでこれを引き起こすのですか？

25mbit接続を使用すると、HDビデオをコンピューターにまったく問題なくストリーミングできます。一方、X11転送を使用してリモートで起動されたGUIの無応答性は、待ち時間がゼロに近い100メガビットLAN上でも発生します。

ビデオストリーミングとは対照的に、レイテンシはせいぜい2倍になることを理解しています（入力をリモートマシンに送信し、その後アプリケーションが応答できるようにする必要があるため）が、内部的にはレイテンシを増加させる他の要因もありますさらに？

第二に、帯域幅。なぜそんなに多く食べるのですか？画像およびビデオ形式に関しては、サイズを大幅に削減するために多くの方法が使用されます。

たとえば、.bmpと.pngの場合、情報はすべてのピクセルごとに保存されるのではなく、私の知る限り範囲に近い方法で保存されるため、大きな黒い正方形の画像は.png表現ではあまり効果がありません。

ビデオの場合、フレーム全体ではなくフレーム間の差分を送信することで、大量の情報を保存できます。

これは非常に単純化されていますが、X11はこれらの方法を使用していませんか？あるレベルでビットマップのように振る舞うのか、それとも非微分の原理で振る舞うのか？そうでない場合、なぜそんなに多くの帯域幅を占有するのですか？

X11プロトコルは、（ビットマップ/テクスチャに関して）グラフィカルに集中的な操作を処理することを意図していませんでした。X11が最初に設計された当時、コンピューターグラフィックスは現在よりもずっとシンプルでした。

基本的に、X11は画面をコンピューターに送信しませんが、表示命令を送信して、ローカルコンピューターのXサーバーがローカルシステムで画面を再作成できるようにします。そして、これはディスプレイの変更/更新ごとに行う必要があります。
そのため、コンピュータは「座標x、yから（xx、yy）までこの色で線を描く、幅Wピクセル、高さHピクセルを（x、y）の左上隅に描くなど）の命令のストリームを受け取ります。 」
ローカルクライアントは何を更新する必要があるかを実際に認識しておらず、リモートシステムにはクライアントが実際に必要なものに関する情報がほとんどないため、基本的にサーバーはクライアントが必要とする可能性のある冗長な情報を大量に送信する必要があります。
これは、レンダリングされるディスプレイが限られた数の単純なグラフィカルシェイプで構成されており、必要なリフレッシュ頻度が低い（アニメーションなどがない）場合に非常に効率的です。これは、X11が最初に開発された当時のことです。

しかし、最近のGUIには見た目がよく、その多くはビットマップ/テクスチャ/フォントの形式でリモートシステムからクライアントに送信する必要があり、かなりの帯域幅を必要とします。そして、あらゆる種類の目を楽しませるには、頻繁な更新が必要なアニメーション効果が含まれます。そして、ディスプレイも大きくなり続け、幅/高さはピクセル数の4倍になります。

もちろん、時間の経過とともに、これを可能な限り最適化するためにX11プロトコルの機能強化が行われましたが、基本的な基本設計は、本質的に、今日期待されている種類のGUIの要求にあまり適していません。

他のプロトコル（RDPやVNCなど）は、リモートシステムがすべてのハードワークを実行し、そのシステムがクライアントに（圧縮ビットマップとして）どの更新を送信するかを可能な限り効率的に決定できるように設計されています。多くの場合、最新のGUIではより効率的です。

どちらの方法も完璧ではなく、あらゆる状況に等しくうまく対処できます。考えられるすべてのユースケースでうまく機能する単一のディスプレイプロトコルのようなものはありません。
そのため、ほとんどの場合、ローカルクライアントとリモートサーバー間でサポートされているすべてのプロトコルを試し、最良の結果が得られるプロトコルを使用します。また、場合によっては選択の余地がなく、利用可能なもので間に合わせる必要があります。

ほとんどのプロトコルではパフォーマンスの調整が可能ですが、これらの設定の多くはサーバー側のみであり、平均的なユーザーは使用できません。（そして、それらを適切に構成するのはちょっと難解な芸術です。多くのシステム管理者はそれをいじるつもりはありません。）

ほとんどの場合、パフォーマンスを向上させる最も簡単な方法は（非常に劇的な場合もあります）、目を楽しませ、背景画像の使用を控えた、よりシンプルなデスクトップ環境に切り替えることです。

X11接続が遅くなるには、主に2つの理由があります。どちらも質問で触れたものです。帯域幅と遅延です。X11アプリがネットワーク上で遅い理由を理解するために、これらの両方について説明しましょう。

帯域幅

X11は、デフォルトでは、アプリケーションとディスプレイサーバーの間で受け渡されるネットワークデータに対して圧縮を行いません。前述したように、SSHで-Cオプションを使用して圧縮を有効にできますが、これは役立ちますが、グラフィカルデータの圧縮には最適化されていません。100対1の圧縮率を得ることができるH.264のような形式と比較して、-C圧縮は2対1の圧縮を達成することができます。X11ビデオにはグラフィックスまたはビデオ最適化コーデックを使用することをお勧めしますが、デスクトップは一般に映画よりも鮮明な画像を必要とするため、ユーザーがテキストをはっきりと読むことができるように、損失が大きくなりすぎないように注意する必要があります細部を作ります。

待ち時間

X11では、ほとんどの操作でアプリケーションとディスプレイサーバー間の複数のラウンドトリップが必要になるため、待ち時間が長くなる傾向があります。ping時間の測定が1ミリ秒未満のLANで実行した場合、これらの複数のラウンドトリップは目立ちませんが、インターネット接続ではすぐに増加します。

解決策

数年前、X11プロトコルに固有の帯域幅と遅延の問題に対処するために構築されたプロジェクトがいくつかありました。lbx（低帯域幅X）およびdxpc（Differential X Protocol Compressor）。lbxがこれまで大きな牽引力を獲得したとは思いませんが、dxpcはNXと呼ばれる製品に使用される基礎となるテクノロジーになりました。NXは、損失の多い圧縮を使用して帯域幅要件を削減し、差分アルゴリズムとキャッシングを使用して、待ち時間が長くなる前後の情報の受け渡し回数を削減します。NXを非常に頻繁に使用しましたが、パフォーマンスはローカルアプリケーションとほぼ同等でした。気分がよければ、NXを試して、それが自分に合っているかどうかを確認してください。欠点は、接続の両端にソフトウェアをインストールする必要があることですが、X11は通常既にインストールされています。