Perché l'inoltro X11 è così inefficiente?

Ogni volta che lancio in remoto grandi GUI con l'inoltro X11, incluso lo switch -C, l'esperienza non risponde. La mia domanda è: cosa causa questo a livello di concetto / protocollo?

Con la mia connessione a 25 mbit, posso trasmettere in streaming video HD sul mio computer senza problemi. D'altra parte, la mancanza di risposta delle GUI lanciate in remoto con l'inoltro X11 si verifica anche su una LAN da 100 mbit, dove la latenza dovrebbe essere vicina allo zero.

Comprendo che, a differenza dello streaming video, la latenza sarà raddoppiata al meglio (poiché l'input deve essere inviato al computer remoto e solo successivamente l'applicazione può rispondere), ma internamente ci sono altri fattori che aumentano la latenza anche ulteriore?

In secondo luogo, la larghezza di banda. Perché ne mangia così tanto? Quando si tratta di formati di immagini e video, vengono utilizzati molti metodi per ridurre drasticamente le dimensioni.

Nel caso di .bmp vs .png, ad esempio, un'immagine quadrata nera di grandi dimensioni impiegherà molto meno nella rappresentazione .png perché le informazioni non sono memorizzate per ogni singolo pixel, ma per quanto io possa capire.

Nel caso dei video, è possibile salvare molte informazioni inviando la differenza tra i frame anziché i frame interi.

So che questo è molto semplificato, ma X11 non sta usando questi metodi? Si comporta in un bitmap-ish o in un principio non differenziale ad un certo livello? E se no, perché occupa così tanta larghezza di banda?

Il protocollo X11 non ha mai avuto lo scopo di gestire graficamente (in termini di bitmap / trame) operazioni intensive. Ai tempi in cui X11 fu progettato per la prima volta, la grafica per computer era molto più semplice di oggi.

Fondamentalmente X11 non invia lo schermo al tuo computer, ma invia le istruzioni di visualizzazione in modo che l'X-server sul tuo computer locale possa ricreare lo schermo sul tuo sistema locale. E questo deve essere fatto ad ogni cambio / aggiornamento del display.
Quindi il tuo computer riceve un flusso di istruzioni come "disegna una linea di questo colore dalle coordinate x, y a (xx, yy), disegna un rettangolo largo W pixel, alto H pixel con l'angolo superiore sinistro a (x, y), ecc. "
Il client locale non è realmente consapevole di ciò che deve essere aggiornato e il sistema remoto ha pochissime informazioni su ciò di cui il client ha effettivamente bisogno, quindi in pratica il server deve inviare molte informazioni ridondanti di cui il client potrebbe o meno aver bisogno.
Ciò è molto efficace se il display da rendere è costituito da un numero limitato di semplici forme grafiche e è necessaria solo una bassa frequenza di aggiornamento (nessuna animazione e simili). Qual era il caso ai tempi in cui X11 fu sviluppato per la prima volta.

Ma le moderne GUI hanno un sacco di piacere e molte di queste devono essere inviate dal sistema remoto al tuo client sotto forma di bitmap / trame / caratteri che richiedono molta larghezza di banda. E ogni sorta di eye-candy include effetti animati che richiedono aggiornamenti frequenti. E anche i display diventano sempre più grandi, il doppio della larghezza / altezza è il doppio del numero di pixel.

Naturalmente, nel tempo, sono stati apportati miglioramenti al protocollo X11 per ottimizzarlo il più possibile, ma il progetto di base di base non è, in sostanza, semplicemente adatto alle esigenze del tipo di persone che la GUI si aspetta oggi.

Altri protocolli (come RDP e VNC) sono più progettati per consentire al sistema remoto di fare tutto il duro lavoro e lasciare che quel sistema decida quali aggiornamenti inviare al client (come bitmap compresse) nel modo più efficiente possibile. Spesso questo risulta essere più efficiente per le moderne GUI.

Nessuno dei due metodi è perfetto e può affrontare ogni situazione ugualmente bene. Non esiste un unico protocollo di visualizzazione in grado di funzionare bene in ogni caso d'uso immaginabile.
Quindi, nella maggior parte dei casi, basta provare tutti i protocolli supportati tra il client locale e il server remoto e utilizzare quello che fornisce i risultati migliori. E in alcuni casi non c'è scelta e devi solo accontentarti di tutto ciò che è disponibile.

La maggior parte dei protocolli consente l'ottimizzazione delle prestazioni, ma molte di queste impostazioni sono solo lato server e non disponibili per l'utente medio. (E configurarli correttamente è un po 'un'arte arcana. Molti amministratori di sistema non saranno disposti a rovinarlo.)

Nella maggior parte dei casi, il modo più semplice per migliorare le prestazioni (a volte in modo piuttosto drammatico) è passare a un ambiente desktop più semplice con meno attenzione e rinunciare all'uso delle immagini di sfondo.

Esistono principalmente due motivi per cui le connessioni X11 sono lente, entrambe toccate nella domanda: larghezza di banda e latenza. Per capire perché le app X11 sono lente su una rete, discutiamo di entrambi.

Larghezza di banda

X11, per impostazione predefinita, non esegue alcuna compressione sui dati di rete che vengono passati tra l'applicazione e il server di visualizzazione. Come accennato, è possibile utilizzare l'opzione -C su SSH per abilitare la compressione e, sebbene ciò aiuti, non è ottimizzato per la compressione di dati grafici. Rispetto ai formati come H.264 che possono ottenere tassi di compressione da 100 a 1, la compressione -C sarà fortunata ad ottenere una compressione da 2 a 1. Una soluzione migliore consiste nell'utilizzare un codec grafico o video ottimizzato per il video X11, ma dobbiamo fare attenzione a non renderlo troppo smarrito poiché i desktop generalmente devono avere immagini più nitide di un film in modo che l'utente possa ancora leggere chiaramente il testo e distinguere i dettagli.

Latenza

X11 tende ad avere una latenza elevata perché la maggior parte delle operazioni richiede più round trip tra l'applicazione e il server di visualizzazione. Quando vengono eseguiti su una LAN in cui i tempi di ping misurano meno di un millisecondo, questi viaggi di andata e ritorno multipli non sono evidenti, ma attraverso una connessione Internet si sommano rapidamente.

soluzioni

Un certo numero di anni fa c'erano un paio di progetti realizzati per affrontare i problemi di larghezza di banda e latenza inerenti al protocollo X11. lbx (Low Bandwidth X) e dxpc (Differential X Protocol Compressor). Non credo che lbx abbia mai avuto molta trazione, ma dxpc è diventata la tecnologia di base utilizzata per un prodotto chiamato NX . NX utilizza sia la compressione con perdita di dati per ridurre i requisiti di larghezza di banda sia un algoritmo differenziale e la memorizzazione nella cache per ridurre il numero di passaggi di informazioni avanti e indietro che creano l'alta latenza. Ho usato NX abbastanza spesso e trovo che le prestazioni siano quasi buone come le applicazioni locali. Se ti senti all'altezza, potresti provare NX e vedere se funziona per te. L'aspetto negativo è che richiede l'installazione di software su entrambe le estremità della connessione, mentre X11 è generalmente già installato.