FirefoxがSSHでこんなに遅いのはなぜですか?


39

を使用して、SSH経由でFirefoxを起動しようとしました

ssh -X user@hostname

その後

firefox -no-remote

しかし、それは非常に遅いです。

どうすれば修正できますか?接続の問題ですか?


3
信じられないほど高いレベルの暗号化がある場合、またはsshを実行しているサーバーの負荷が高い場合を除き、おそらくsshが方程式の一部ではありません。通常、帯域幅や遅延の問題です。
-Bratchley

1
これを見てください:stackoverflow.com/q/12977879/252489
Gowtham

@Gowthamだから私は使用できます:ssh -X -C user @ hostname?
DevOps85

回答:


25

デフォルトのssh設定では、接続がかなり遅くなります。代わりに次を試してください。

ssh -YC4c arcfour,blowfish-cbc user@hostname firefox -no-remote

使用されるオプションは次のとおりです。

-Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not
         subjected to the X11 SECURITY extension controls.
 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11 and TCP connections).  The
         compression algorithm is the same used by gzip(1), and the
         “level” can be controlled by the CompressionLevel option for pro‐
         tocol version 1.  Compression is desirable on modem lines and
         other slow connections, but will only slow down things on fast
         networks.  The default value can be set on a host-by-host basis
         in the configuration files; see the Compression option.
 -4      Forces ssh to use IPv4 addresses only.
 -c cipher_spec
         Selects the cipher specification for encrypting the session.

         For protocol version 2, cipher_spec is a comma-separated list of
         ciphers listed in order of preference.  See the Ciphers keyword
         in ssh_config(5) for more information.

ここでの主なポイントは、異なる暗号化暗号(この場合はデフォルトよりも速いarcfour)を使用し、転送されるデータを圧縮することです。


注:私はこれに関する専門家とは非常にかけ離れています。上記のコマンドは、ブログの投稿で見つけた後に使用したもので、速度が大幅に改善されていることに気付きました。以下のさまざまなコメンターは、彼らが何について話しているかを知っていると確信しており、これらの暗号化暗号は最良のものではないかもしれません。この回答の中で本当に重要なのは、-Cスイッチを使用して転送されるデータを圧縮することだけである可能性が非常に高いです。


11
実際に暗号化設定を変更することで接続のスループットを改善できますが、X-over-ssh接続を非常に遅くするレイテンシーにはほとんど影響がありません...またはそうでなければ:転送を達成することができますファイルは速くなりますが、転送を開始するのにかかる時間は(ほとんど)変わりません。これはXプロトコルの問題です。クライアントとサーバー間の多くのメッセージと確認応答が関係するため、インターネット上では、ボタンがステータスを変更するのを見るまで、数ミリ秒の待ち時間が何度も増加します。
アリエル

8
-4、ここで実際に関連する(IPv4)の?
Cornstalks

6
「アークフール」暗号は廃止予定です。ところで
モニカを

5
圧縮は役立ちますが、奇跡は起こりません。Firefoxは非常に要求が厳しいです。暗号化方式を変更しても、CPU時間が非常に限られている場合を除き、違いが生じることはほとんどありません。スマートフォンやPCなどのハイエンドデバイスでは、暗号化/復号化時間はネットワークの遅延と帯域幅に比べて無視できます。
ジル 'SO-悪であるのをやめる'

6
提案された暗号は間違った方法です。Gillesが言うように、最近のデバイスの大部分はデフォルトのAES-CTRではまったく問題ありません。特に、使用するハードウェアにAES命令セットがある場合、非常に高速です。RC4は弱く、ネット全体で段階的に廃止されており、Blowfish-CBCはAES-CTRよりも必ずしも高速ではない場合があります。
レイド

32

一部のXクライアントをリモートで起動する際の最大の問題の1つはXプロトコルであり、sshのオーバーヘッドではありません!Xプロトコルは、リモートアプリケーションの場合にパフォーマンスを完全に低下させる、クライアントとサーバー間の多くのピンポンを必要とします。

「x2go」のようなもの(これもデフォルトのセットアップでsshを経由します)を試してみてください。Firefoxが比較すると「飛ぶ」ことに気づくでしょう。

いくつかのディストリビューションでは、DebianテストやStable-Backportsなどのx2goパッケージをそのまま提供しています。ただし、そうでない場合は、http: //wiki.x2go.org/doku.php/download : startを参照してください。多くのディストリビューション用のビルド済みのバイナリパッケージ/リポジトリを提供します。x2goclient(firefoxを「使用」するコンピューターに)とx2goserver(firefoxを実行するコンピューターに)をインストールする必要があります。その後、フルデスクトップビューなどの単一Xアプリケーションのセッションを構成できます。接続自体sshで発生します。それは本当に素晴らしいツールです:)

それを使用するには、「x2goclient」を実行し、新しいセッションを作成できるGUIを起動します。サーバーのDNS名、ポート、sshデータなどを指定し、「セッションタイプ」を選択します。たとえば、完全なリモートKDEまたはGNOMEデスクトップ、または単に「単一のアプリケーション」が必要な場合は、「firefox」と入力します。


1
どうすればx2goを試すことができますか?コマンド
-DevOps85

3
x2goserverDebian(またはUbuntu)にはパッケージがないようです。また、これはトンネリングを許可するように構成できますか?たとえば、machineXを使用していますが、machineY経由でのみsshできます。x2goはそれを処理できますか?
テルドン

@terdonあなたは正しいです、私はクライアントだけをチェックしました。ただし、x2goリポジトリを追加するだけで(wiki.x2go.org/doku.php/download:startリンクを参照)、サーバーはそこにあります。クライアントだけがDebianにいる理由はわかりません。トンネリング:確かに可能ですが、試したことはありません。sshを設定~/.ssh/configしてx2goセッションで正しい(トンネル化された)ホスト名を使用するだけで十分だと思います。
アリエル

@terdon:x2goセッション構成には「SSH接続にプロキシサーバーを使用する」(ssh / http)オプションがあります。それで、それもトリックをするはずです!
アリエル

これは面白そうだ、もう少し遊んでみよう。これまでのところ、トンネルを設定する.ssh/configだけでは十分ではないことを確認できます。ssh machineB実際にトンネル経由で実行されるようにセットアップしていますmachineAが、x2goには表示されないようです。
テルドン

17

私は、sshトンネルを使用して別のマシンを介してトラフィックをルーティングすることで、はるかに良い経験をしています。とにかくsshにアクセスできるため、セットアップは非常に簡単です。コンピューターのターミナルで、次のように入力します

ssh -vv -ND 8080 user@yourserver

このウィンドウを開いたままにして、トンネルを流れるデータに関する詳細なメッセージが表示されるのを確認します。

firefox、[設定]-> [詳細設定]-> [ネットワーク]-> [接続:設定]に移動します。

手動プロキシ設定を選択し、SOCKS v5プロキシを追加します

 SOCKS Host:   localhost    Port 8080

http://whatismyipaddress.com/などに移動して、新しいIPを確認します。

foxyプロキシのようなfirefoxアドオンを使用して、プロキシを動的に切り替えることができます。


賛成、これはNXベースの圧縮(x2goなど)を使用する非常に有効な代替手段であり、ssh暗号化設定をいじるよりもはるかに便利です:)
Ariel

常にssh -L 8080:localhost:8080を使用しましたが、-NDオプションは好きでしたが、代わりにDinamicまたはRemoteまたはListenを使用した理由がわかりません。ちなみに、プロキシを使用すると-Xを使用するよりもはるかに優れていますが、Firefoxだけでなく、より多くのXプログラムが必要な場合はVNCを使用する方が良いと思います。
erm3nda

セットアップが簡単で効率的に動作します!
david.perez

2

Firefoxは新しいビルドのfirefoxが複数のインスタンスを許可するため、SSHで非常に遅くなります。帯域幅に問題がある場合は、dilloのような軽いブラウザを使用してください。接続速度に気付かないでしょう。



1
これは問題とは何の関係もありません-問題は、ブラウザが、X11のリモートプロトコルではありません
ジョアン・アントゥネス

0

sshでのブラウジングを改善するもう1つのことは、Firefoxでパイプラインを有効にすることです。開いてtrueにabout:config変更network.http.pipeliningします。


このオプションを使用すると、Webページの読み込みが高速になりますが、ブラウザーがSSHトンネルを介して実行されているかどうかとはまったく関係ありません。とにかく、あなたは高度なオプションをタッチすると、「しかしだ」...見るには注意してくださいkb.mozillazine.org/Network.http.pipelining
アリエル

私の経験では、sshを介したブラウジングは遅くなり、リクエストのパイプライン化は大きな助けになります。さもないと、与えられたリクエストは前のリクエストを待つ必要があります。また、これをssh多重化と組み合わせます。それは顕著な違いになります。パイプラインをオフにすると、私の場合は耐えられないほど遅くなります。
タナス

0

特定のボトルネックに役立つものを確認するには、実験する必要があります。

私にとって、圧縮を有効にすると(-C)応答性が使用不能から単なる顕著な遅延に改善されました。

一部の人々が言っ​​たことに反して、暗号の選択も影響を与える可能性があります。オンラインでベンチマークを共有している人を見つけることができますが、結果が同じであると思い込まないでください。どの暗号が最適かはハードウェアに依存します。私にとって、デフォルトの暗号(chacha20-poly1305@openssh.com)はすでに最速のものに結び付けられていました。

少し現実的な条件下で、関連する暗号をベンチマークするための簡単なスクリプトを書きました。コメント内の説明:

#!/usr/bin/bash

# Ciphers available to you depends on the intersection of ciphers compiled 
# into your client and the ciphers compiled into your host.
# Should be manually copied from "Ciphers:" section in your `man ssh_config`
# The script will try all ciphers specified here and will gracefully skip
# ciphers unavailable in the host.
#ciphers=""
# Example:
ciphers="3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com aes256-gcm@openssh.com chacha20-poly1305@openssh.com"

tmp_file=tmp.bin

# Recommend to use an identity file without a passphrase.
# That way you won't have to retype the password at each iteration.
ssh_identity_file=~/.ssh/tmp_id_no_passphrase

ssh_host="user@host"

# Size of test file, before encryption.
test_file_size_megabytes=8

# Only create test file if it doesn't yet exists.
# Doesn't check if relevant variables changed, so you'll have to delete
# the $tmp_file to regenerate it.
if test ! -f $tmp_file; then
  echo "Creating random data file" \
    "(size $test_file_size_megabytes MB): $tmp_file"

  # Not the same format as the ssh ciphers.
  # Can be left as is, unless this cipher is not supported by your openssl.
  tmp_file_cipher=aes-128-cbc

  # The purpose of encrypting the $tmp_file is to make it uncompressable.
  # I do not know if that is a concern in this scenario,
  # but better safe than sorry.

  dd if=/dev/zero bs=1M count=$test_file_size_megabytes \
    | openssl enc -$tmp_file_cipher -pass pass:123 \
    > $tmp_file
fi

for cipher in $ciphers ; do
  # Benchmark each $cipher multiple times
  for i in 1 2 3 ; do
    echo
    echo "Cipher: $cipher (try $i)"
    # Time piping the $tmp_file via SSH to $ssh_host using $cipher.
    # At destination received data is discarded.
    cat $tmp_file \
      | /usr/bin/time -p \
      ssh -i $ssh_identity_file -c "$cipher" $ssh_host 'cat > /dev/null'
  done
done

# Sample output:

# Creating random data file (size 8 MB): tmp.bin
# *** WARNING : deprecated key derivation used.                                   Using -iter or -pbkdf2 would be better.                                         8+0 records in
# 8+0 records out
# 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0567188 s, 148 MB/s

## [redacted]

# Cipher: aes256-cbc (try 3)
# Unable to negotiate with 192.168.99.99 port 22: no matching cipher found. Their offer: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
# real 0.12
# user 0.03
# sys 0.03

# Cipher: aes128-ctr (try 1)
# real 9.68
# user 0.28
# sys 0.51

# Cipher: aes128-ctr (try 2)
# real 10.85
# user 0.26
# sys 0.29

## [redacted]

クライアントとホストが同じマシンであるSSH接続でテストするか、ホストがX11転送を行っているマシンであるより現実的なシナリオでテストするかを選択できます。パフォーマンスは、クライアントのパフォーマンス解読だけでなく、ホストのパフォーマンスにも依存するためです。

リモートマシンでのテストには、ベンチマーク中にインターネット接続のスループットが変化した場合にノイズが発生するというデメリットがあります。その場合、各暗号がテストされる回数を増やしたいかもしれません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.