Pourquoi un partage de fichiers par VPN paraît lent : des allers-retours, pas des Mbps

Ouvrir un dossier partagé via le VPN et attendre que la liste du répertoire rampe est une expérience familière, et le premier réflexe est d'accuser la bande passante. La plupart du temps, le lien est presque inactif. Le protocole passe son temps à attendre des réponses, et chaque attente coûte un aller-retour complet que le réseau local ne facturait jamais. Corrigez la forme du travail, et le partage redevient utilisable.

La copie de travail distante n'a pas la bonne forme

SMB ouvre les fichiers, lit les métadonnées et acquitte en de nombreux petits échanges. Une copie de travail de gestion de versions sur un lecteur monté présuppose la latence du système de fichiers local et lit beaucoup de petits fichiers. Une base de données de bureau extrait des pages pendant que l'utilisateur travaille. Chacune de ces situations transforme le délai en multiplicateur, car le coût croît avec le nombre d'échanges que l'opération effectue ; un tunnel à 40 ms transforme donc quelques centaines d'opérations en plusieurs secondes. La taille de la charge utile est presque sans importance dans ce calcul.

Le surcoût du chiffrement en est une petite part ; la perte est pire, car une retransmission plus une fenêtre de congestion effondrée coûte bien plus que les octets concernés.

Comptez les allers-retours avant les mégaoctets

Mesurez le délai avant d'acheter de la capacité. Un seul ping vous dit ce que paie chaque échange.

ping -c 10 fileserver.example.net

Le résumé donne les temps d'aller-retour minimum, moyen et maximum, et la dispersion compte autant que la moyenne. Multipliez la moyenne par le nombre d'échanges qu'effectue une liste de répertoire, puis comparez-la au temps que vous observez réellement. Si un gros fichier se transfère vite alors que la navigation est lente, la latence et le nombre de requêtes sont la contrainte. Ajouter dix fois la capacité à un lien qui ne sature jamais ne change absolument rien.

Déplacez le travail, pas les octets

Changez l'endroit où le travail se fait au lieu de payer pour plus de tuyau. Servez le dépôt au lieu de le monter, et copiez en bloc avec un outil qui n'envoie que les différences.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

Servir le dépôt, comme le font hgweb ou un Git distant, permet au client de travailler sur un clone local, si bien que ses appels au système de fichiers ne traversent jamais le tunnel. rsync parcourt les deux côtés et envoie les blocs modifiés, éliminant la plupart des échanges qu'une copie naïve paie. Une base de données de bureau appartient à un moteur côté serveur, le client se réduisant à une interface, ou bien tout le client s'exécute sur un hôte interne. Chaque option change l'exposition du protocole à la latence, et c'est précisément l'enjeu.

Les blocages à taille égale sont un symptôme de MTU

Les transferts importants qui calent après à peu près la même quantité de données, alors que le ping et les petites pages fonctionnent, pointent la taille des paquets plutôt que la bande passante.

ping -M do -s 1400 -c 3 fileserver.example.net

Une sonde réussie signifie qu'un paquet IP de 1428 octets traverse le chemin sans fragmentation, puisque les en-têtes ICMP et IP ajoutent 28 octets. Un échec avec l'indicateur ne-pas-fragmenter suggère que la MTU utilisable du tunnel est plus petite que le serveur ne le suppose. Un serveur qui envoie des tampons de 9000 octets sur un chemin de 1500 octets impose la fragmentation ou des rejets, et la découverte de la MTU du chemin peut échouer silencieusement quand ICMP est filtré. Abaissez la MTU du tunnel, activez mssfix sous OpenVPN, ou réduisez les tampons du serveur, puis relancez le même transfert pour confirmer.

Mesurez l'écart qui compte

Exécutez la même opération de trois façons là où la politique le permet : en local, à travers le tunnel et par un chemin internet direct. Pour chacune, notez le temps d'aller-retour, le débit d'un gros flux et le temps que prend une liste de répertoire ou l'ouverture d'une application. Comparer l'exécution locale à l'exécution via le tunnel montre quel coût domine. Une copie qui se termine lentement suggère un problème de débit ou de délai, tandis qu'une copie qui meurt à un point constant suggère la taille des paquets ou un équipement à état sur le chemin.

Quand seuls les premiers mégaoctets traînent, regardez l'authentification et les métadonnées ; quand tout rampe, regardez la capacité et les pertes. Corrigez la cause correspondante et cessez d'attendre d'un lien WAN qu'il se comporte comme un câble de réseau local.