'ssh -X'を介したアプリケーションが 'ssh-X'を介したvncviewerよりも遅いのはなぜですか
X-forwardを介してプログラムを実行すると、アニメーションに関しては非常にパフォーマンスが低下します。例えば。：
ssh -X <USER>@<SERVER> "application"
しかし、リモートvncサーバーを起動してssh経由で接続するとリモートで、アニメーションやその他すべてのものがはるかにスムーズに実行されます。例えば。：
DSPLY=1 && ssh -X <USER>@<SERVER> "vncserver :$DSPLY ; vncviewer localhost:$DSPLY"
私の意見では、sshを介して送信する必要があるのは（多かれ少なかれ）同じ量のデータです。では、なぜこれほど大きな速度の違いがあるのでしょうか。
問題はおそらくXプロトコル自体です。それは非常におしゃべりで、データの生の量はかなり少ないですが、それはWAN接続で問題になる多くのラウンドトリップを引き起こします。
コンストラクトは、使用するアプリケーションが接続しているリモートxserverを起動します。したがって、アプリケーションの観点からは、xserverはローカルであり、ラウンドトリップ遅延はわずかです。アーキテクチャの観点からは、vncウィンドウは非常に単純であるため、vncviewerウィンドウが適切に機能するために必要なチャットとラウンドトリップは、「実際の」アプリケーションと比較してはるかに少なくなります。
さらに、従来のvnc実装でさえ、必要なチャットを積極的に減らすことで、このRTDの問題を特に対象としています。これにより、vncviewerウィンドウとローカルxserver間のチャットも減ります。
知らないうちに、使用する暗号化プロトコルに帰着すると思います。これについてデバッグしたり詳細を説明したりするのに十分な知識はありませんが、使用するプロトコルを変更してみると、エクスポートされたXプログラムの応答性が大幅に向上します。
したがって、ssh -X user@Hostの代わりに、
ssh -YC4c arcfour,blowfish-cbc user@Host
詳細については、 ここ を参照してください（ただし、速度については、-Yの代わりに-Xを使用することをお勧めします）。
VNCがプロトコル固有の圧縮を適用している可能性があります。異なるVNC実装はデフォルトで異なる圧縮アルゴリズムを使用し、圧縮ネゴシエーションは十分に文書化されていないため、特定することは困難です。
SSHに-Cオプションを使用してみてください。アプリケーションとVNCの実装に応じて、VNCの結果が良くなることも悪くなることもあり、ssh -C + VNCはVNC単独よりも良くなることも悪くなることもあります。