Perché Firefox è così lento su SSH?


39

Provo ad avviare Firefox su SSH, usando

ssh -X user@hostname

e poi

firefox -no-remote

ma è molto molto lento.

Come posso risolvere questo problema? È un problema di connessione?


3
A meno che tu non abbia un livello di crittografia incredibilmente alto o che il server in cui stai utilizzando abbia un carico elevato, probabilmente non è la parte SSH dell'equazione. Di solito è un problema di larghezza di banda e / o latenza.
Bratchley,

1
Date un'occhiata a questo: stackoverflow.com/q/12977879/252489
Gowtham

@Gowtham così posso usare: ssh -X -C user @ hostname?
DevOps85,

Risposte:


25

Le impostazioni predefinite di ssh rendono la connessione piuttosto lenta. Prova invece quanto segue:

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

Le opzioni utilizzate sono:

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

Il punto principale qui è usare un cifrario di crittografia diverso, in questo caso arcfour che è più veloce del valore predefinito e comprimere i dati che vengono trasferiti.


NOTA: sono molto, molto lontano da un esperto in questo. Il comando sopra è quello che uso dopo averlo trovato su un post sul blog da qualche parte e ho notato un enorme miglioramento della velocità. Sono sicuro che i vari commentatori qui sotto sanno di cosa stanno parlando e che questi cifrari potrebbero non essere i migliori. È molto probabile che l'unica parte di questa risposta che sia veramente pertinente sia l'uso dello -Cswitch per comprimere i dati trasferiti.


11
In realtà modificando le impostazioni di crittografia è possibile migliorare il throughput della connessione, ma ciò non avrà quasi alcuna influenza sulla latenza che è ciò che rende la connessione X-over-ssh così lenta ... O detto altrimenti: è possibile ottenere il trasferimento un file più veloce, ma il tempo necessario per iniziare il trasferimento non cambierà (quasi). Questo è il problema del protocollo X, coinvolge molti messaggi e riconoscimenti tra il client e il server, quindi su Internet la latenza di pochi millisecondi viene moltiplicata molte volte fino a quando non si vede un pulsante che cambia il suo stato, ad esempio.
Ariel,

8
Is -4(IPv4) davvero rilevante qui?
Cornstalks,

6
Il codice "arcfour" è deprecato, tra l'altro.
Ripristina Monica - M. Schröder,

5
La compressione aiuta, ma non fa miracoli. Firefox è molto impegnativo. È improbabile che la modifica della cifra faccia la differenza a meno che uno dei lati non sia molto limitato nel tempo della CPU: con dispositivi di fascia alta come smartphone e PC, il tempo di crittografia / decrittografia è trascurabile rispetto alla latenza della rete e alla larghezza di banda.
Gilles 'SO- smetti di essere malvagio'

6
Le cifre suggerite sono la strada sbagliata da percorrere. Come dice Gilles, la maggior parte dei dispositivi al giorno d'oggi non avrà alcun problema con l'AES-CTR predefinito: è molto veloce, specialmente se l'hardware utilizzato ha l'istruzione AES impostata. RC4 è debole e viene gradualmente eliminato attraverso la rete e Blowfish-CBC potrebbe non essere necessariamente più veloce di AES-CTR comunque.
Reid

32

Uno dei maggiori problemi all'avvio remoto di alcuni client X è il protocollo X, non tanto il sovraccarico di ssh! Il protocollo X richiede un sacco di ping-pong tra il client e il server, il che uccide assolutamente le prestazioni nel caso di applicazioni remote.

Prova qualcosa come "x2go" (che va anche su ssh con le impostazioni predefinite) noterai che firefox "vola" in confronto!

Diverse distribuzioni forniscono i pacchetti x2go pronti all'uso, ad esempio i test Debian o in Stable-Backports. Altrimenti, vedi http://wiki.x2go.org/doku.php/download:start , forniscono pacchetti / repository binari predefiniti per molte distribuzioni. È necessario installare x2goclient (sul computer su cui si desidera "utilizzare" firefox) e x2goserver (sul computer su cui Firefox dovrebbe essere in esecuzione), è quindi possibile configurare le sessioni per applicazioni X singole per visualizzazioni desktop complete ecc. La connessione stessa succede su ssh. È uno strumento davvero meraviglioso :)

Per usarlo, esegui "x2goclient", avvia una GUI in cui puoi creare una nuova sessione: fornisci il nome dns del server, porta, dati ssh, ecc. E poi selezioni il "tipo di sessione", cioè se vuoi un desktop KDE o GNOME remoto completo per esempio, o solo una "singola applicazione" e lì inserisci "firefox".


1
come posso provare x2go? il comando
DevOps85,

3
Sembra che non ci siano x2goserverpacchetti su Debian (o Ubuntu). Inoltre, può essere configurato per consentire il tunneling? Ad esempio, utilizzo machineX ma posso solo usarlo tramite machineY. X2go potrebbe occuparsene?
terdon

@terdon hai ragione, ho controllato solo il cliente. Ma puoi semplicemente aggiungere il repository x2go (vedi il link wiki.x2go.org/doku.php/download:start ) e il server è lì. Non so perché solo il client sia in Debian. Tunneling: sicuramente è possibile, ma mai provato. Mi aspetto che dovrebbe essere sufficiente configurare ssh in ~/.ssh/confige usare il nome host (tunnelizzato) giusto nella sessione x2go.
Ariel,

@terdon: esiste un'opzione "Usa server proxy per connessione SSH" (ssh / http) nella configurazione della sessione x2go. Quindi anche questo dovrebbe fare il trucco!
Ariel,

Sembra interessante, ci giocherò ancora un po '. Finora posso confermare che la configurazione del tunnel .ssh/confignon è sufficiente. L'ho installato in modo che ssh machineBattraversi effettivamente un tunnel machineAma x2go non sembra vederlo.
terdon

17

Ho un'esperienza molto migliore nell'uso di un sshtunnel per instradare il traffico attraverso un'altra macchina. È molto facile da configurare poiché hai comunque accesso a ssh. In un terminale sul computer, digitare

ssh -vv -ND 8080 user@yourserver

Tieni aperta questa finestra e guardala mentre consegna alcuni messaggi dettagliati sui dati che fluiscono attraverso il tunnel.

In firefox, vai su Preferenze -> Avanzate -> Rete -> Connessione: Impostazioni.

Seleziona Configurazione proxy manuale e aggiungi un SOCKS v5proxy:

 SOCKS Host:   localhost    Port 8080

Controlla il tuo nuovo IP visitando ad esempio http://whatismyipaddress.com/ .

È possibile utilizzare un componente aggiuntivo di Firefox come proxy foxy per cambiare dinamicamente i proxy.


Eseguito l'upgrade, questa è un'alternativa molto valida all'utilizzo della compressione basata su NX (x2go ecc.), Molto più utile che armeggiare con le impostazioni di crittografia ssh :)
Ariel

Ho sempre usato ssh -L 8080: localhost: 8080, ma mi è piaciuta l'opzione -ND ma non so perché hai usato Dinamic o Remote o Listen. A proposito, usare il proxy è molto meglio dell'uso di -X, ma penso che il modo migliore sia usare VNC se hai bisogno di più programmi X e non solo di Firefox.
m3nda,

facile da installare e funziona in modo efficiente!
david.perez,

2

Firefox è così lento su SSH perché le nuove build di firefox consentono più istanze. Se hai problemi di larghezza di banda, usa un browser leggero come Dillo e non noterai nemmeno la velocità di connessione.


Questa risposta proviene da un post sul forum ArchLinux .
Andrew T.

1
questo non ha nulla a che fare con il problema - il problema non è il browser ma il protocollo remoto X11
João Antunes

0

Un'altra cosa che migliorerà la tua navigazione su ssh è abilitare il pipelining in Firefox. Apri about:confige cambia network.http.pipeliningin vero.


Tale opzione dovrebbe velocizzare il caricamento delle pagine Web, ma non è completamente correlata al fatto che il browser sia in esecuzione su un tunnel SSH o meno. In ogni caso, fai attenzione ai "ma" quando tocchi le opzioni avanzate ... vedi kb.mozillazine.org/Network.http.pipelining
Ariel

Nella mia esperienza, la navigazione su ssh diventa lenta e le richieste di pipeline sono di grande aiuto poiché altrimenti una determinata richiesta deve attendere quelle precedenti che possono o non possono essere completate in modo tempestivo se non del tutto. Unisco anche questo al multiplexing ssh. Fa una notevole differenza. La disattivazione della pipeline ritorna ad essere insopportabilmente lenta nel mio caso.
Tanath,

0

Devi sperimentare per vedere cosa ti aiuta con i tuoi colli di bottiglia specifici.

Per me, abilitare la compressione ( -C) ha migliorato la reattività da inutilizzabile a notevole ritardo.

Anche la scelta della cifra può avere un impatto, contrariamente a quanto affermato da alcune persone. Puoi trovare persone che condividono benchmark online, ma non presumere che i tuoi risultati saranno gli stessi. Quale cifra è la migliore per te dipende dall'hardware. Per me il mio codice predefinito (chacha20-poly1305@openssh.com) era già legato per il più veloce.

Ho scritto una sceneggiatura rapida per confrontare le cifre pertinenti in condizioni alquanto realistiche. Spiegazioni nei commenti:

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

Puoi scegliere di testare con una connessione SSH in cui il client e l'host sono la stessa macchina, oppure puoi testare in uno scenario più realistico, in cui l'host è la macchina da cui stai eseguendo l'inoltro X11, che dovrebbe essere più utile, perché le prestazioni non dipendono solo dalla decodifica delle prestazioni del client, ma anche da quella dell'host.

Il test con una macchina remota può avere lo svantaggio di introdurre rumore se il throughput della connessione Internet cambia nel corso del benchmark. In tal caso, potrebbe essere necessario aumentare il numero di volte in cui ciascun codice viene testato.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.