Qualcuno conosce un modo per accelerare l'inoltro X11 su SSH, ad eccezione dell'utilizzo di una crittografia e una compressione più veloci, senza installare alcun software sul server? Nel mio caso, non ho alcuna autorizzazione per installare software sul server. Appartiene alla mia università. Tuttavia, vorrei che i programmi GUI eseguiti sul server e visualizzati sul mio computer di casa fossero effettivamente utilizzabili .
Risposte:
Il tunneling da X11 a SSH è piuttosto costoso in termini di larghezza di banda e il protocollo X non è ideale per collegamenti RTT elevati. Potresti semplicemente non avere abbastanza larghezza di banda, o troppa latenza, per essere utilizzabile.
Sembra che tu abbia già ristretto le opzioni che hai:
opzioni che richiedono l'installazione di software su entrambe le estremità (un ottimizzatore del protocollo X come x2go, FreeNX o altri, oppure utilizzando un protocollo diverso da X su SSH come VNC o Desktop remoto)
usando la compressione (o no, dovrebbe essere meglio con ma provate entrambi): opzione -C
usando un protocollo di cifratura meno costoso come BlowFish-CBC o arcfour (il secondo è meno sicuro): aggiungi l'opzione -c blowfish-cbc
L'unico che sembra esserti perso è se il tuo programma X è Firefox, nel qual caso sembra che l'impostazione network.http.pipelininge l'uso del multiplexing ssh possano fare la differenza .
Uso ssh-hpn , una serie di patch al codice SSH ufficiale per prestazioni più elevate, per qualsiasi momento ho bisogno di SSH ad alte prestazioni. Alcune piattaforme come FreeBSD lo includono immediatamente, in altri puoi installarlo tramite un gestore di pacchetti, oppure puoi compilarlo dal sorgente e aggiungere le patch in te stesso.
Se sei su una piattaforma popolare, puoi probabilmente trovare una distribuzione binaria di ssh-hpn (anche se per ovvi motivi di sicurezza, costruire da sorgenti è sempre meglio con un software come questo).
Se davvero non ti interessa affatto la sicurezza, puoi usare X11 su netcat (aka nc) invece di ssh. Probabilmente è già installato anche sul tuo computer.
Idea n. 1: disattiva la compressione. Sì, spento. È possibile che il tuo problema non riguardi la larghezza di banda, ma la latenza. La compressione nel canale rende normalmente una latenza molto negativa per le applicazioni della GUI. Se hai una buona larghezza di banda, suggerirei un bel tentativo di sembrare strano al primo posto: disattivare la compressione ovunque.
Idea n. 2: prova a usare un'altra implementazione ssh. Quindi openssh è un po 'noto per la sua velocità. Probabilmente la sua parziale ragione per cui i suoi sviluppatori si stanno concentrando sulla sicurezza e la velocità è una cosa secondaria per loro. La causa della latenza probabilmente non lo èla lentezza degli algoritmi di crittografia, ma la gestione inefficiente degli eventi simultanei di trasferimento dei dati (in molte direzioni, sia in entrata che in uscita), e anche le cose di calcolo / compressione / crittografia in un software a thread singolo, non orientato agli eventi. (Ad esempio: funzionamento tipico del software: prima crittografa un blocco di dati, quindi lo invia alla rete, infine legge ciò che il lato remoto ci ha inviato e lo decodifica. Sembra perfettamente a posto, ma contiene una terribile latenza: i blocchi di dati arrivati non verranno letti fino a quando la compressione dei blocchi effettiva non sarà pronta ... Dovrebbe essere implementata in modo multithread, o almeno asincrono, e openssh è molto, molto, molto male in questo).
Idea n. 3: controlla la configurazione su entrambi i lati. La compressione può essere impostata su entrambi i server e anche nella configurazione client. Non mi sembra irrealistico, che forse hai installato solo su uno dei lati. Controlla, controlla davvero che accada davvero su entrambi i lati (anche se probabilmente sul lato di invio non è molto importante, perché i movimenti del mouse e i colpi della tastiera non usano troppa larghezza di banda per quello. Forse una soluzione asimmetrica, comprimendo anche la grande le operazioni di immagine sul lato server-> client, mentre l'invio di dati client-> server non compressi a bassa latenza promettono il miglior risultato.