Firefox neden SSH'ye göre bu kadar yavaş?


39

Kullanarak Firefox'u SSH üzerinden başlatmaya çalışıyorum

ssh -X user@hostname

ve sonra

firefox -no-remote

ama çok çok yavaş.

Bunu nasıl düzeltebilirim? Bir bağlantı sorunu mu var?


3
İnanılmaz derecede yüksek bir şifreleme düzeyiniz yoksa ya da içine girdiğiniz sunucunun yoğun bir yükü yoksa, muhtemelen denklemin ssh parçası değildir. Bu genellikle bir bant genişliği ve / veya gecikme sorunu.
Bratchley


@Gowtham kullanabildiğim için: ssh -X -C user @ hostname?
DevOps85,

Yanıtlar:


25

Varsayılan ssh ayarları oldukça yavaş bir bağlantı sağlar. Bunun yerine aşağıdakileri deneyin:

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

Kullanılan seçenekler:

-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.

Buradaki ana nokta, farklı bir şifreleme şifresi kullanmak, bu durumda varsayılandan daha hızlı olan arcfour kullanmak ve aktarılan verileri sıkıştırmaktır.


NOT: Bu konuda bir uzmandan çok çok uzaktayım. Yukarıdaki komut, bir blog postasında bulduktan sonra kullandığım şeydir ve hızda büyük bir gelişme olduğunu fark ettim. Aşağıdaki çeşitli yorumcuların neden bahsettiğini bildiklerinden ve bu şifreleme sifirelerinin en iyi olanlar olamayacağından eminim. Bu sorunun cevabının gerçekten ilgili olan tek kısmı -C, aktarılan verileri sıkıştırmak için anahtarın kullanılmasıdır .


11
Aslında şifreleme ayarlarını değiştirerek bağlantının verimliliğini artırabilirsiniz , ancak bu X-ssh bağlantısını X'in bağlantısını bu kadar yavaş yapan gecikme üzerinde neredeyse hiçbir etkisi olmaz ... Veya aksi takdirde: bir dosya daha hızlı, ancak aktarımın başlaması için geçen süre değişmeyecek (neredeyse). X protokolünün sorunu budur, müşteri ve sunucu arasında birçok mesaj ve onay içerir, bu yüzden internet üzerinden birkaç milisaniyelik gecikme süresi bir düğmenin durumunu değiştirene kadar birçok kez çarpılır.
Ariel,

8
-4burada gerçekten ilgili (IPv4)?
Cornstalks

6
'Arcfour' şifresi kullanımdan kaldırıldı, btw.
Monica'yı yeniden

5
Sıkıştırma yardımcı olur, ancak mucizeler yaratmaz. Firefox çok zorlu. Şifreyi değiştirmenin, işlemci zamanında çok sınırlı olmadığı sürece, fark yaratması pek mümkün değildir: akıllı telefonlar ve PC'ler gibi ileri teknoloji cihazlarda şifreleme / şifre çözme süresi ağ gecikmesi ve bant genişliği ile karşılaştırıldığında önemsizdir.
Gilles 'SO- kötülük' dur

6
Önerilen şifreler gitmek için yanlış yoldur. Gilles'un dediği gibi, günümüzde cihazların çoğunluğu varsayılan AES-CTR ile hiç sorun yaşamayacak: özellikle kullanılan donanım AES komut setine sahipse çok hızlı . RC4 zayıftır ve ağda aşamalı olarak gerçekleşir ve Blowfish-CBC, mutlaka AES-CTR'den daha hızlı olmayabilir.
Reid,

32

Bazı X-istemcilerini uzaktan başlatırken en büyük sorunlardan biri, X-protokolüdür, genel gider değil! X-protokolü, istemci ile sunucu arasında uzak uygulamalar durumunda kesinlikle performansı düşüren çok sayıda pinpon gerektiriyor.

"X2go" (varsayılan ayarlarla ssh üzerinden de geçer) gibi bir şey deneyin, eğer firefox’un "uçup gittiğini" fark edeceksiniz!

Çeşitli dağıtımlar, x2go paketlerini kutudan, örneğin Debian testi veya Stabil-Backports'ta sağlar. Ancak değilse, http://wiki.x2go.org/doku.php/download:start adresini ziyaret edin , birçok dağıtım için önceden oluşturulmuş ikili paketler / depolar sağlarlar. X2goclient ('firefox' kullanmak istediğiniz bilgisayara) ve x2goserver (firefox'un çalıştığı bilgisayarda) yüklemelisiniz, ardından oturumlarınızı tam masaüstü görünümleri için tek X uygulamaları için yapılandırabilirsiniz. Bağlantının kendisi ssh üzerinde olur. Bu gerçekten harika bir araçtır :)

Kullanmak için "x2goclient" komutunu çalıştırırsınız, yeni bir oturum oluşturabileceğiniz bir GUI başlatır: sunucunun, portun, ssh verisinin vb. Adının adını girin ve ardından "oturum türünü" seçersiniz Örneğin tam bir uzaktan KDE veya GNOME masaüstü veya sadece bir "tek uygulama" istiyorsanız, oraya "firefox" yazınız.


1
x2go'yu nasıl deneyebilirim? komut
DevOps85

3
x2goserverDebian'da (veya Ubuntu) bir paket yok gibi görünüyor . Ayrıca, tünel açmaya izin verecek şekilde yapılandırılabilir mi? Örneğin, machineX kullanıyorum, ancak yalnızca machineY üzerinden ssh yapabiliyorum. X2go bununla başa çıkabilir mi?
terdon

@ terdon haklısın, sadece müşteriyi kontrol ettim. Ancak x2go deposunu ekleyebilirsiniz (wiki.x2go.org/doku.php/download:start bağlantısına bakın ) ve sunucu oradadır. Neden sadece müşterinin Debian'da olduğunu bilmiyorum. Tünelleme: elbette mümkün, ama hiç denemedim. Sadece ~/.ssh/configssh'yi yapılandırmak ve x2go oturumunuzda doğru (tünellenmiş) ana bilgisayar adını kullanmak için yeterli olacağını bekliyorum .
Ariel,

@terdon: x2go oturum yapılandırmasında "SSH bağlantısı için proxy sunucusu kullan" (ssh / http) seçeneği var. Yani bu da hile yapmak gerekir!
Ariel,

Bu ilginç görünüyor, onunla biraz daha oynayacağım. Şimdiye kadar tüneli yapılandırmanın .ssh/configyeterli olmadığını onaylayabilirim . Kurulumu yaptım, böylece ssh machineBaslında bir tünelden geçiyor machineAama x2go bunu görmüyor.
terdon

17

sshTrafiği başka bir makineye yönlendirmek için tünel kullanma konusunda daha iyi bir deneyimim var . Zaten ssh erişiminiz olduğundan, kurulumu çok kolaydır. Bilgisayarınızdaki bir terminalde,

ssh -vv -ND 8080 user@yourserver

Bu pencereyi açık tutun ve tünelden akan verilerle ilgili bazı ayrıntılı mesajlar göndermesini izleyin.

İçinde firefoxTercihler -> Gelişmiş -> Ağ -> Bağlantı: Ayarlar bölümüne gidin.

Manuel proxy yapılandırmasını seçin ve bir SOCKS v5proxy ekleyin :

 SOCKS Host:   localhost    Port 8080

Http://whatismyipaddress.com/ adresine giderek yeni IP adresinizi kontrol edin .

Proxy'leri dinamik olarak değiştirmek için bir proxy gibi bir proxy kullanabilirsiniz.


Geliştirilmiş, bu, NX tabanlı sıkıştırma (x2go vb.) Kullanılmasına çok uygun bir alternatif, ssh şifreleme ayarlarıyla karıştırmaktan çok daha kullanışlı :)
Ariel

Ben her zaman ssh -L 8080: localhost: 8080 kullandım, ancak -ND seçeneğini beğendim ama bunun yerine Dinamic veya Remote veya Listen'ı neden kullandığınızdan emin değilim. Bu arada, proxy kullanarak -X kullanmaktan çok daha iyi, ancak, daha fazla X programına ihtiyacınız varsa ve sadece Firefox'a ihtiyaç duymuyorsanız, VNC kullanmak daha iyi bir yöntem.
erm3nda

kurulumu kolay ve verimli çalışıyor!
david.perez


0

Ssh üzerinde göz atmanızı geliştirecek bir başka şey de Firefox'ta boru hattını etkinleştirmektir. Aç about:configve network.http.pipeliningdoğru olarak değiştir .


Bu seçenek, web sayfalarının yüklenmesini daha hızlı hale getirmelidir, ancak tarayıcının bir SSH tüneli üzerinde çalışıp çalışmadığı ile tamamen alakasızdır. Her neyse, gelişmiş seçeneklere dokunduğunuzda "ama's" a dikkat edin ... bkz. Kb.mozillazine.org/Network.http.pipelining
Ariel

Tecrübelerime göre, ssh'ye göz atmak yavaşlıyor ve boru hattı talepleri büyük bir yardımcı oluyor çünkü aksi takdirde verilen herhangi bir istek, eğer zamanında olursa olsun veya hiç tamamlayamamış olan önceki talepleri beklemelidir. Ben de bunu ssh multiplexing ile birleştiriyorum. Göze çarpan bir fark yaratıyor. Boru hattını kapatmak, benim durumumda dayanılmaz derecede yavaş olmaya geri dönüyor.
Tanath

0

Özel darboğazlarınızla neyin işe yarayacağını görmek için deneme yapmalısınız.

Benim için, sıkıştırmanın ( -C) etkinleştirilmesi , kullanılamaz durumdan yalnızca fark edilebilir gecikmeye kadar duyarlılığı arttırdı.

Şifreleme seçiminin, bazılarının söylediklerinin aksine, bir etkisi olabilir. Çevrimiçi olarak ölçüt paylaşan kişileri bulabilirsiniz, ancak sonuçlarınızın aynı olacağını sanmayın. Hangi şifre sizin için en iyisi donanıma bağlıdır. Benim için varsayılan şifrem (chacha20-poly1305@openssh.com) zaten en hızlı olana bağlıydı.

İlgili şifreleri biraz gerçekçi koşullar altında kıyaslamak için hızlı bir senaryo yazdım. Yorumlardaki açıklamalar:

#!/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]

İstemcinin ve ana makinenin aynı makine olduğu bir SSH bağlantısıyla test etmeyi seçebilir veya daha gerçekçi bir senaryoda test edebilirsiniz, burada ana makinenin X11 iletimini yaptığınız makine olduğu, hangisinin daha yararlı olması gerektiği, çünkü performans sadece müşterinin deşifre etmesine değil aynı zamanda sunucunun performansına da bağlıdır.

Uzaktaki bir makineyle yapılan testler, test sırasında internet bağlantınızdaki verimin değişmesi durumunda gürültü çıkarmanın dezavantajına neden olabilir. Bu durumda, her şifrenin test edilme sayısını arttırmak isteyebilirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.