より効率的なX転送？
-X（または-Y）フラグを使用してSSHでGUIリモートプログラムを開きます。たとえば、
$ ssh -Y [email protected]
最近、私はこれをWebブラウジングのみで行うより効率的な方法があることを発見しました：
$ ssh -DNNNN [email protected]
ここで、NNNNは4桁のポート番号です。次に、ポートNNNNを介してプロキシ経由で接続するようにローカルブラウザを構成します。すべてのGUI情報をトンネル経由で転送する必要はなく、要求しているWebデータのみを転送する必要があるため、これは最初のSSH方法よりもはるかに効率的です。
私の質問は：一般的にX転送でSSHを実行するより効率的な方法はありますか？リモートでホストされているGUIプログラムの操作を支援するために、ローカルライブラリやレンダリングなどを利用するスキームがあるのではないでしょうか。
用語を混同しています。最初のものはX11転送であり、定義上非効率であり、それについてほとんど何もすることができません（これは高遅延接続や数十年前に作られたものではありません）。他の方法と比較すると、 （broswer？の）GUI全体をイモリで転送しています。
もう1つはSOCKSプロキシ（まったく別のもの）であり、目的のネットワークデータ（SOCKSプロトコルとSSHにカプセル化されている）のみを転送します。これは明らかにより効率的です。
あなたの質問は答えることができない方法で尋ねられます。何を達成しようとしていますか？ GUIプログラムを実行しますか？プロキシネットワーク接続？まったく違う何か？
Xpraをお試しください。これは最高のX11転送アプリであり、より安全です。それは、x264でさえ、多くのコーデックと圧縮フォーマットをサポートします。私はそれをリモート側でスカイプを実行するために使用しましたが、私はこれをビジネスで強制するときに、オープンソースコードのみでマシンを維持したいと考えていました。アプリは永続的に実行されているため、GNU screenと同様に、接続が失われた場合に再接続できます。
また、活発に開発されているオープンソースのNX実装であるX2GOもご覧ください。
X転送は、比較的高速なネットワークであっても、多くの場合低速です。帯域幅と遅延の両方に悩まされています。多くのアプリケーションはサーバーからの応答を待機することが多く、これは顕著な遅延につながる可能性があります。
圧縮することで帯域幅を改善できます。 SSHは-Cオプション。 dxpc を使用することもできます。これは、Xプロトコルを理解し、ジェネラリストの圧縮よりも優れたパフォーマンスを発揮する専用の圧縮プログラムです。ただし、制限要因がレイテンシである場合、これは役に立ちません。通常、dxpcは、低速リンクの軽量アプリケーションで多くの違いをもたらしますが、高速リンクの重量級アプリケーションではあまり改善しません。
[〜＃〜] nx [〜＃〜] は、dxpcのより高度な代替手段です。 dxpcとは異なり、それは単に圧縮するだけでなく、一部のデータもキャッシュするので、レイテンシに対抗できます。
多くの違いを生むことができる1つのことは、クライアントレンダリング（fontconfig）ではなくサーバーレンダリングフォント（クラシックX11テキストレンダリング）の使用です。リモートリンクよりもはるかに高速です。しかし、サーバーレンダリングフォントには欠点があります。醜く（アンチエイリアスなし）、アプリケーションではなくサーバーによって管理されます（本質的に欠点ではありませんが、多くのアプリケーションはフォントを完全に制御する必要があります）。単にそれらをもはやサポートしないでください。