Pourquoi le transfert X11 est-il si inefficace?

97

Chaque fois que je lance à distance de grandes interfaces graphiques avec un transfert X11, même avec le commutateur -C, l'expérience est très insensible. Ma question est la suivante: qu'est-ce qui se passe au niveau concept / protocole?

Avec ma connexion à 25 Mbits, je peux diffuser de la vidéo HD sur mon ordinateur sans aucun problème. D'autre part, le manque de réactivité des interfaces utilisateur graphiques lancées à distance avec transfert X11 se produit même sur un réseau local à 100 mbits, où la latence devrait être proche de zéro.

Je comprends que, contrairement au streaming vidéo, la latence sera au mieux doublée (car l’entrée doit être envoyée à la machine distante et c’est seulement après que l’application peut répondre), mais en interne, existe-t-il d’autres facteurs qui augmentent la latence même plus loin?

Deuxièmement, la bande passante. Pourquoi en mange-t-il tant? En ce qui concerne les formats d'image et de vidéo, de nombreuses méthodes sont utilisées pour réduire considérablement la taille.

Dans le cas de .bmp vs .png, par exemple, une grande image en carré noir prendra beaucoup moins en représentation .png car les informations ne sont pas stockées pour chaque pixel, mais de manière très variable, à ma connaissance.

Dans le cas de vidéos, beaucoup d'informations peuvent être sauvegardées en envoyant la différence entre les images plutôt que les images entières.

Je sais que cela est très simplifié, mais X11 n’utilise-t-il pas ces méthodes? Est-ce que cela se comporte dans un principe bitmap-ish ou non différentiel à un certain niveau? Et si non, pourquoi utilise-t-il autant de bande passante?

utilisateur129186
la source
9
Anecdote: Xpra offre une approche intéressante.
Kamil Maciorowski
12
BTW - utiliser "-C" ralentira votre connexion si votre lien est assez rapide car la compression prend du temps. "-C" pourrait bénéficier à 100 Mo, mais probablement à 1 Go, et certainement à 10 Go. C'est également le cas que 'ssh' nuira à votre débit - de même que tout cryptage sur des liens rapides. Si vous avez une connexion directe entre ordinateurs ou une liaison interne sécurisée, allez directement avec votre connexion X sur TCP: 6000. Vous obtiendrez une amélioration notable de la vitesse.
Astara
2
On dirait que vous transférez via SSH, qui doit chiffrer / déchiffrer toutes les données. Cela va ajouter des frais généraux / latence. Des processeurs plus rapides peuvent aider, mais il y aura une certaine latence que cela ajoutera, peu importe ce que vous ferez. X est très "bavard", donc légère augmentation de la latence = baisse significative des performances. Dans le passé, j’étais capable d’utiliser X, tunnelisé via SSH sur un modem 28.8; cela utilisait lbxproxy (maintenant déconseillé) qui mettait en cache / compressait beaucoup de données et réduisait le "chattiness" de la connexion. L'utilisation de -C ne peut qu'ajouter plus de latence.
Meower68
Utilisez quelque chose comme ssh -Y -c blowfishpour minimiser les frais généraux tout en chiffrant. Si vous avez le contrôle total des deux bouts, apprenez à ssh à utiliser le chiffrement "aucun" pour obtenir une vitesse de transfert maximale sur la connexion.
Thorbjørn Ravn Andersen

Réponses:

116

Le protocole X11 n'a jamais été conçu pour gérer des opérations intensives sur le plan graphique (en termes de bitmaps / textures). À l'époque où X11 a été conçu, les images de synthèse étaient bien plus simples qu'aujourd'hui.

Fondamentalement, X11 n'envoie pas l'écran à votre ordinateur, mais envoie les instructions d'affichage afin que le serveur X de votre ordinateur local puisse recréer l'écran sur votre système local. Et cela doit être fait à chaque changement / rafraîchissement de l'affichage.
Ainsi, votre ordinateur reçoit un flux d’instructions du type "tracer une ligne dans cette couleur à partir des coordonnées x, y jusqu'à (xx, yy), tracer un rectangle de W pixels de large, H pixels de hauteur avec le coin supérieur gauche en (x, y), etc. "
Le client local ne sait pas vraiment ce qui doit être mis à jour et le système distant ne dispose que de très peu d'informations sur ses besoins. Par conséquent, le serveur doit envoyer un grand nombre d'informations redondantes dont le client peut ou non avoir besoin.
Ceci est très efficace si l'affichage à restituer consiste en un nombre limité de formes graphiques simples et qu'une faible fréquence de rafraîchissement (sans animations et autres) est nécessaire. Ce qui était le cas à l'époque du développement de X11.

Mais les interfaces graphiques modernes ont beaucoup de succès et une grande partie de cela doit être envoyée du système distant à votre client sous forme de bitmaps / textures / polices qui consomment beaucoup de bande passante. Et toutes sortes de friandises pour les yeux incluent des effets animés nécessitant des mises à jour fréquentes. Et les écrans ne cessent de grossir aussi, deux fois plus large / haut, c'est 4x le nombre de pixels.

Bien sûr, au fil du temps, le protocole X11 a été amélioré pour l'optimiser autant que possible, mais la conception de base sous-jacente n'est, par essence, tout simplement pas bien adaptée aux exigences du type de personnel attendu par les utilisateurs de l'interface graphique.

D'autres protocoles (tels que RDP et VNC) sont davantage conçus pour permettre au système distant de faire tout le travail et de laisser le système décider des mises à jour à envoyer au client (sous forme de bitmaps compressés) aussi efficacement que possible. Cela s'avère souvent plus efficace pour les interfaces graphiques modernes.

Aucune des méthodes n'est parfaite et ne peut traiter toutes les situations de la même manière. Il n’existe pas de protocole d’affichage unique qui puisse fonctionner dans tous les cas d’utilisation imaginables.
Ainsi, dans la plupart des cas, il vous suffit d'essayer tous les protocoles pris en charge entre votre client local et le serveur distant et d'utiliser celui qui donne les meilleurs résultats. Et dans certains cas, il n'y a pas de choix et il suffit de se débrouiller avec tout ce qui est disponible.

La plupart des protocoles permettent un certain réglage des performances, mais bon nombre de ces paramètres sont uniquement côté serveur et ne sont pas disponibles pour l'utilisateur moyen. (Et les configurer correctement est un peu un art mystérieux. Un grand nombre d'administrateurs système ne voudront pas jouer avec cela.)

Dans la plupart des cas, le moyen le plus simple d’améliorer les performances (parfois de façon spectaculaire) consiste à passer à un environnement de bureau plus simple, avec moins de vertige et l’abandon des images d’arrière-plan.

Tonny
la source
15
+1 Etant donné que RDP et VNC sont mentionnés, je devrais également mentionner x2go, qui est une solution de mise en cache / transfert X11 qui accélère réellement le transfert X11. Je l'ai utilisé avec succès dans le passé.
Rath
7
En ce qui concerne les "paramètres uniquement côté serveur" vers la fin, rappelez-vous que le serveur X est exécuté sur l'ordinateur connecté à l'écran physique et que le client X est le logiciel utilisé pour effectuer certaines tâches (par exemple, un navigateur Web ou un traitement de texte). ). Ainsi, les paramètres du serveur X seraient accessibles à l'utilisateur se connectant au système distant afin d'exécuter une application graphique. Cela n'enlève toutefois rien à la valeur de votre réponse.
un CVn
2
Techniquement, le protocole est RFB, pas VNC.
OrangeDog
6
Est-ce que je me trompe ou est-ce que vous confondez client et serveur dans votre deuxième paragraphe? Le client est le programme qui s'exécute à distance, le serveur est la machine locale.
Jonas Schäfer
2
Ce que vous avez couvert dans le troisième paragraphe a été largement atténué dans les années 90, car les ordinateurs exécutant des serveurs X ont commencé à disposer de suffisamment de mémoire pour que le stockage sur support devienne une opération pratique.
Blrfl
45

Il y a principalement deux raisons pour lesquelles les connexions X11 sont lentes. Vous avez toutes les deux évoqué votre question: la bande passante et la latence. Pour comprendre pourquoi les applications X11 sont lentes sur un réseau, examinons ces deux points.

Bande passante

X11, par défaut, n'effectue aucune compression sur les données réseau transmises entre l'application et le serveur d'affichage. Comme vous l'avez mentionné, vous pouvez utiliser l'option -C sur SSH pour activer la compression. Bien que cela aide, elle n'est pas optimisée pour la compression des données graphiques. Par rapport aux formats tels que H.264, qui peuvent obtenir des taux de compression de 100 à 1, la compression -C aura la chance d’obtenir une compression de 2 à 1. Une meilleure solution consiste à utiliser un codec optimisé pour les graphiques ou les vidéos pour la vidéo X11, mais vous devez faire attention à ne pas le perdre car les ordinateurs de bureau ont généralement besoin d’images plus nettes qu’un film pour que l’utilisateur puisse toujours lire clairement le texte. faire des détails fins.

Latence

X11 a tendance à avoir une latence élevée car la plupart des opérations nécessitent plusieurs allers-retours entre l'application et le serveur d'affichage. Lorsqu'ils sont exécutés sur un réseau local (LAN) où les temps de ping mesurent moins d'une milliseconde, ces allers-retours multiples ne sont pas perceptibles, mais s'ajoutent rapidement via une connexion Internet.

Solutions

Il y a plusieurs années, quelques projets ont été élaborés pour résoudre les problèmes de bande passante et de latence inhérents au protocole X11. lbx (bande passante réduite X) et dxpc (compresseur de protocole différentiel X). Je ne pense pas que lbx ait jamais eu beaucoup d’adhérence, mais dxpc est devenue la technologie sous-jacente utilisée pour un produit appelé NX . NX utilise à la fois une compression avec perte pour réduire les besoins en bande passante et un algorithme différentiel et une mise en cache pour réduire le nombre d'informations échangées qui créent la latence élevée. J'ai souvent utilisé NX et trouve que les performances sont presque aussi bonnes que celles des applications locales. Si vous vous sentez à la hauteur, essayez NX et voyez si cela vous convient. L'inconvénient est qu'il nécessite l'installation d'un logiciel aux deux extrémités de la connexion, alors que X11 est généralement déjà installé.

Virtex
la source
3
Lié au sujet de la latence serait que X11 sera TCP, vs UDP pour la plupart des vidéos en streaming. Il existe quelques autres produits permettant de travailler à distance. Tony a mentionné RDP et VNC. Oracle vend toujours Sun Global Desktop (SGD) qui fonctionne bien. Citrix avait quelque chose (XenApp?). Notre évaluation a révélé que SGD était une meilleure option pour nos besoins, mais avait déjà utilisé deux produits Citrix.
sleepyweasel
x2go a très bien fonctionné pour moi, même avec "server" un vieil ordinateur portable. opérationnel en quelques minutes ... forte augmentation de la performance de X11 FWD (inutilisable avec ma config)
comte
En ce qui concerne la latence, sur les machines * ix, les sessions X11 sur des écrans locaux utilisent généralement des sockets de domaine Unix au lieu de TCP; Les sockets de domaine Unix sont plusieurs fois plus rapides que TCP aux allers-retours, même vers localhost stackoverflow.com/questions/14973942/… . Pour les applications X11 avec un très grand nombre d'allers et retours pathologiquement, cela pourrait faire la différence entre une performance correcte et une performance sensiblement lente.
Rakslice