Comment NuviraHub garde un bureau à distance réactif

Dans un bureau à distance, un chiffre compte plus que tous les autres : le temps entre un changement sur l'écran distant et le moment où vous le voyez. Au-delà de 100 ms, la souris semble se déplacer dans du miel ; autour de 40 ms, on n'y pense plus. Cet article explique comment NuviraHub garde ce délai bas et ce qui a mal tourné en chemin.

Comment nous mesurons

Chaque image vidéo porte l'instant où elle a été capturée. Le poste qui regarde connaît l'écart entre les deux horloges : il calcule donc la latence de la capture à l'affichage de chaque image et, toutes les 250 ms, renvoie la médiane et le minimum au PC contrôlé. Les mêmes valeurs s'affichent en direct dans la barre de session et dans le titre de la fenêtre.

Les chiffres ci-dessous viennent d'une configuration volontairement défavorable : écran avec une animation plein écran, donc une image qui change toujours ; réseau filaire. Quick Sync : PC contrôlé avec un Intel Core i7-10710U, poste qui regarde sur un portable avec un Intel Core i7-8550U. NVIDIA : PC contrôlé avec un AMD Ryzen 7 5700X et une RTX 4060 Ti, poste qui regarde sur le mini PC avec l'i7-10710U.

1. L'image reste dans la carte graphique

L'écran est capturé avec la Desktop Duplication de Windows, qui fournit déjà l'image sous forme de texture GPU. Le processeur vidéo du GPU la convertit dans le format attendu par l'encodeur (NV12), et l'encodeur H.264 matériel la prend directement, via Media Foundation. L'image ne repasse jamais par la mémoire du processeur : la conversion des couleurs prend environ 1 ms au lieu des 3 à 4 ms nécessaires sur le CPU.

Tous les PC n'ont pas un encodeur matériel utilisable : au démarrage, NuviraHub teste donc ceux qui sont disponibles et se replie au besoin sur OpenH264 en logiciel. Rien que compiler OpenH264 avec ses optimisations en assembleur l'a fait passer de 19 à 9 ms par image.

2. Ne jamais laisser vieillir une image

Les premières mesures entre deux vrais PC étaient bien pires que sur une seule machine. Trois problèmes, tous liés à des images qui attendaient alors qu'elles n'auraient pas dû :

• Un verrou tenu pendant l'attente. L'appel de capture attendait une nouvelle image (jusqu'à 100 ms) en tenant le verrou du périphérique graphique partagé, et la conversion et l'encodage attendaient derrière : jusqu'à 360 ms pour une seule image. Désormais, la capture interroge sans attendre.
• Des images qui vieillissent devant l'encodeur. Une image capturée attendait que l'encodeur soit libre et était déjà vieille quand elle était encodée. Désormais, on attend d'abord l'encodeur et on prend seulement ensuite l'image la plus récente : la latence est passée de 53 à 38 ms.
• Une file d'attente côté visionneuse. Quand la visionneuse était plus lente que le PC contrôlé, elle affichait quand même toutes les images dans l'ordre, et la latence montait jusqu'à 2,5 s. Désormais, elle affiche toujours la dernière image décodée et écarte celles déjà dépassées. Côté envoi, le tampon réseau est limité à 256 Ko : au-delà, des images sont sautées au lieu d'être mises en file.

3. S'adapter au réseau

Sur un réseau local propre, un débit fixe convient très bien. Sur un réseau avec délai et pertes, c'est un désastre : avec 25 ms, 1 % de pertes et 5 Mbit/s, la latence médiane était de 2,2 secondes, car la vidéo continuait à pousser plus que le lien ne pouvait transporter et tout s'accumulait dans les files d'attente.

Deux changements ont réglé le problème. Le premier est un débit adaptatif : quand la latence médiane de la dernière seconde dépasse de 60 ms le minimum des dix dernières secondes, pendant au moins une seconde, le débit baisse de 20 % ; quand elle reste proche, il augmente de 15 %, avec une pause après chaque changement. Le second est BBR comme contrôle de congestion de QUIC : avec des pertes aléatoires, les algorithmes classiques (NewReno, Cubic) interprètent chaque paquet perdu comme de la congestion et utilisaient moins de la moitié de la bande passante.

4. Ce que nous a appris le premier test sur un réseau mobile

Les simulations sont propres ; un partage de connexion de téléphone à travers le relais ne l'est pas. Le premier vrai test sur Internet a révélé cinq problèmes qu'aucune simulation n'avait montrés :

• Un encodage lent pris pour de la congestion. Sur un PC chargé, l'encodage prenait 130 ms par image ; la latence augmentait et le débit adaptatif réduisait la qualité au minimum, comme si le réseau était en cause. Désormais, il ne regarde que la partie réseau : de la fin de l'encodage à l'arrivée sur la visionneuse.
• Un écran immobile qui ressemble à un réseau bloqué. Avec presque rien à envoyer, la latence des rares paquets sur un réseau mobile saute toute seule entre 30 et 185 ms, et le débit tombait de 4 à 0,5 Mbit/s en 16 secondes sans que rien ne bouge. Désormais, le débit ne change que lorsque la vidéo en utilise réellement une bonne partie.
• Des pics isolés. Même avec peu de trafic, le réseau mobile avait des pics de 150 à 600 ms toutes les quelques secondes. Réagir à chacun ramenait le débit au minimum et les photos devenaient floues. Seule compte désormais une file d'attente qui dure une seconde entière.
• Un texte flou sur un écran immobile. La première image après un changement est encodée à la hâte et, sur un lien lent, le texte restait illisible. Désormais, quand l'écran cesse de changer, la dernière image est encodée à nouveau jusqu'à 15 fois, environ toutes les 100 ms : chaque passage consacre le débit à ce que le précédent avait laissé de côté, et une fois l'image identique, cela ne coûte presque rien.
• Un encodeur qui ignore les changements. Via Media Foundation, Quick Sync ignore les changements de débit une fois la session commencée. Au début nous le redémarrions, et l'image restait figée environ une seconde à chaque changement ; maintenant la session reste ouverte et l'encodeur est reconfiguré avec le nouveau débit en 1 à 4 ms.

5. En direct quand c'est possible, et chiffré même quand ça ne l'est pas

Les deux PC essaient de se joindre directement à travers leurs routeurs (hole punching), en utilisant aussi les adresses locales quand ils sont derrière le même routeur. En cas d'échec, le relais du serveur transmet les paquets QUIC tels quels, déjà chiffrés de bout en bout : en réseau local, le relais coûte environ 5 ms. Sur les réseaux qui bloquent l'UDP, les mêmes paquets passent dans un WebSocket, donc le chiffrement et la session sont identiques ; entre nos deux PC de test, ce tunnel est resté à 38–39 ms.

NuviraHub est open source : le débit adaptatif se trouve dans client/agent/src/abr.rs, les mesures et leur historique dans les documents du projet (en anglais). Si vous mesurez quelque chose sur votre réseau, surtout avec des cartes NVIDIA ou AMD, nous aimerions le savoir : ouvrez un ticket ou écrivez à support@nuvirahub.dev.