X11転送がなぜそれほど非効率的なのですか？
-Cスイッチを含めて、X11転送を使用して大きなGUIをリモートで起動したときはいつでも、その経験は非常に無反応です。私の質問は、コンセプト/プロトコルレベルでこれが何を引き起こすのでしょうか。
私の25mbit接続で、私は問題なく絶対に私のコンピュータにHDビデオを流すことができます。一方、X11転送を使用したリモートで起動されたGUIの無応答は、待ち時間がゼロに近いはずの100mbit LAN上でさえも起こります。
ビデオストリーミングとは対照的に、待ち時間はせいぜい2倍になるでしょう（入力はリモートマシンに送信され、その後にアプリケーションが応答できるようになる必要があるため）、内部的には待ち時間をさらに増加させる要因さらに？
第二に、帯域幅です。それはなぜそれをそんなに多く食べますか？画像やビデオのフォーマットに関しては、サイズを大幅に縮小するために多くの方法が使用されています。
例えば.bmp vs .pngの場合、大きな黒い四角い画像は.png表現では情報が1ピクセルごとに保存されるわけではなく、私が理解する限り範囲に近い方法で保存されます。
ビデオの場合、フレーム全体ではなくフレーム間の差分を送信することで、大量の情報を保存できます。
これは非常に単純化されていますが、X11はこれらの方法を使用していませんか？それはあるレベルではビットマップ風の、あるいは非微分的な原理で振る舞いますか？そうでなければ、なぜそれがそんなに多くの帯域幅を占有するのでしょうか。
X11プロトコルは、（ビットマップ/テクスチャに関して）集中的な操作をグラフィカルに処理することを意図したものではありませんでした。 X11が最初に設計された当時、コンピューターグラフィックスは今日よりもずっとシンプルでした。
基本的にX11はスクリーンをあなたのコンピュータに送らないが、それはあなたのローカルコンピュータのXサーバがあなたのローカルシステムのスクリーンを作り直すことができるようにdisplay-instructionを送る。そしてこれはディスプレイの変更/更新ごとに行われる必要があります。
それで、あなたのコンピュータは、「この色で、座標x、yから（xx、yy）に線を引き、幅Wピクセル、高さHピクセルを（x、）に描画する」のような命令のストリームを受け取る。 y）など」
ローカルクライアントは何を更新する必要があるのか実際には気付いておらず、リモートシステムはクライアントが実際に必要としているものに関する情報をほとんど持っていません。いらない。
これは、レンダリングされるディスプレイが限られた数の単純なグラフィック形状で構成され、低いリフレッシュ頻度（アニメーションなどは不要）だけで構成される場合、非常に効率的である。これはX11が最初に開発された頃の話です。
しかし、最近のGUIには目を見張るものがたくさんあり、その多くは、かなりの帯域幅を必要とするビットマップ/テクスチャ/フォントの形式でリモートシステムからクライアントに送信する必要があります。そしてあらゆる種類のアイキャンディーには、頻繁な更新が必要なアニメーション効果が含まれています。また、ディスプレイも大きくなり続けており、幅/高さの2倍はピクセル数の4倍になります。
もちろん、時間の経過とともに、X11プロトコルの機能強化は可能な限り最適化するために行われましたが、基本的な基本設計は、本質的に、今日の人々が期待する種類のGUIの要求にはあまり適していません。
他のプロトコル（RDPやVNCなど）は、リモートシステムにすべての面倒な仕事をさせ、その更新をできるだけ効率的に（圧縮ビットマップとして）クライアントに送信する更新を決定させるように設計されています。多くの場合、これは最新のGUIにとってより効率的です。
どちらの方法も完璧ではなく、あらゆる状況に同等に対応できます。考えられるすべてのユースケースでうまく実行できる単一の表示プロトコルのようなものはありません。
したがって、ほとんどの場合、ローカルクライアントとリモートサーバーの間でサポートされているすべてのプロトコルを試して、最も良い結果が得られるものを使用するだけです。そして場合によっては選択肢がなく、利用可能なものなら何でもしなければならないことがあります。
ほとんどのプロトコルでパフォーマンスの調整が可能ですが、これらの設定の多くはサーバー側のみであり、一般のユーザーは利用できません。 （そしてそれらを適切に設定することはちょっと難解な技術です。多くのsys-adminはそれを混乱させようとは思わないでしょう。）
ほとんどの場合、パフォーマンスを向上させるための最も簡単な方法は（ときには非常に劇的に）、見た目がよく、背景画像の使用を控えて、より単純なデスクトップ環境に切り替えることです。
X11接続が遅くなる主な理由は2つあります。どちらも帯域幅と待ち時間です。なぜX11アプリケーションがネットワーク上で遅いのかを理解するために、これら両方について説明しましょう。
帯域幅
X11は、デフォルトでは、アプリケーションとディスプレイサーバーの間でやり取りされるネットワークデータに対して圧縮を行いません。すでに説明したように、SSHで-Cオプションを使用して圧縮を有効にすることができますが、これは役立ちますが、グラフィカルデータの圧縮には最適化されていません。 H.264のような100から1の圧縮率を得ることができるフォーマットと比較して、-Cの圧縮は2から1の圧縮を達成するのに幸運でしょう。よりよい解決策はX11ビデオにグラフィックまたはビデオに最適化されたコーデックを使用することですが、デスクトップは一般的に映画よりもシャープな画像を持つ必要があるので、紛失しすぎないように注意してください。細かい詳細を確認してください。
待ち時間
ほとんどの操作では、アプリケーションとディスプレイサーバー間で複数のラウンドトリップが必要になるため、X11では待ち時間が長くなる傾向があります。 ping時間が1ミリ秒未満で測定されるLANを介して実行した場合、これらの複数のラウンドトリップは目立つことはありませんが、インターネット接続を介して迅速に加算されます。
解決策
何年も前に、X11プロトコルに固有の帯域幅と待ち時間の問題に対処するためにいくつかのプロジェクトが構築されました。 lbx（低帯域幅X）およびdxpc（差動Xプロトコルコンプレッサ）。私はlbxがこれほど大きな牽引力を得たとは思わないが、dxpcは NX と呼ばれる製品に使用される基礎技術となった。 NXは、帯域幅の要件を減らすために非可逆圧縮を使用し、高遅延を生み出す情報の受け渡し回数を減らすために差分アルゴリズムとキャッシングを使用します。私はNXを頻繁に使用していますが、パフォーマンスはローカルアプリケーションとほぼ同等であることがわかりました。あなたがそれに慣れているならば、あなたはNXを試して、それがあなたのために働くかどうか確かめるかもしれません。欠点は、接続の両端にソフトウェアをインストールする必要があるのに対し、X11はすでにインストールされていることです。