Pourquoi le transfert X11 est-il si inefficace?
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?
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 pour la première fois, les images de synthèse étaient beaucoup 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 flot d’instructions du type "tracez une ligne dans cette couleur à partir des coordonnées x, y jusqu'à (xx, yy), tracez un rectangle de W pixels de large, H pixels de haut avec le coin supérieur gauche à (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 une grande quantité d'informations redondantes que le client peut ou ne peut pas. pas 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 (pas d’animation, etc.) 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 plus conçus pour permettre au système distant de faire tout le travail difficile et à ce système de décider quelles 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.
Donc, dans la plupart des cas, essayez simplement tous les protocoles pris en charge entre votre client local et le serveur distant et utilisez 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 ajustement 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.
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 sur une connexion Internet, ils s'additionnent rapidement.
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 pense que lbx n’a jamais eu beaucoup d’attrait, 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é.