Transférer des fichiers entre des appareils et des systèmes distants est une tâche essentielle dans le monde numérique d’aujourd’hui. Bien que les protocoles FTPS et SFTP soient largement utilisés pour le transfert de fichiers à distance, ils s’avèrent souvent lents lorsqu’il s’agit de traiter des petits fichiers (10 Ko et moins). Plus il y a de petits fichiers à transférer, plus l’impact de cette problématique se fait ressentir. Avec des volumes de données importants, le temps de sauvegarde peut être lourdement pénalisé.
ByteSync réduit drastiquement la durée des transferts de données, en étant au moins 10x plus rapide que FTPS et SFTP pour synchroniser les petits fichiers. Dans ce billet, je présente tout d’abord une comparaison des performances de transfert de petits fichiers entre FTPS, SFTP et ByteSync. J’aborde ensuite les raisons de la lenteur des protocoles FTPS et SFTP avant d’expliquer pourquoi ByteSync est si rapide pour transférer les petits fichiers.

Comparaison des performances de transfert des petits fichiers : FTPS, SFTP vs ByteSync

Pour mettre en évidence les différences de vitesse de transfert des petits fichiers, j’ai effectué des tests comparatifs à distance entre les protocoles FTPS et SFTP d’un côté, et le logiciel ByteSync de l’autre. Je n’ai pas retenu le protocole FTP pour ces comparaisons car, bien que plus léger et certainement plus rapide que FTPS, il présente l’inconvénient majeur de transférer les données en clair sur le réseau, ce qui est rédhibitoire en terme de sécurité pour de la sauvegarde ou de la synchronisation à distance via Internet.

Pour effectuer les tests, j’ai employé une machine Windows située dans mon réseau local et un machine virtuelle Linux hébergée par OVH (Virtual Private Server). Elles sont toutes deux de moyenne gamme et sont connectées à Internet avec des connexions de type fibre optique. J’ai utilisé les configurations logicielles suivantes :

• Pour les tests FTPS, la machine Windows utilise le client WinSCP et la machine virtuelle Linux utilise le serveur vsftpd, avec une configuration standard.
• Pour les tests SFTP, la machine Windows utilise le client WinSCP et la machine Linux utilise le serveur SSH par défaut.
• Pour les tests ByteSync, ByteSync est déployé en mode portable sur la machine Windows et sur la machine Linux.

Pour prendre des mesures pertinentes, j’ai transféré des petits fichiers depuis la machine Windows vers la machine Linux en deux jeux de tests. Le premier comportait 10 000 fichiers de 10 ko, le second 10 000 fichiers de 1 ko.
J’ai également pris en compte le fait qu’en augmentant le nombre de connexions parallèles FTPS et SFTP, on diminue le temps de global de sauvegarde. Je me suis basé sur ce que proposent habituellement les logiciels de synchronisation de sauvegarde existants, à savoir utiliser 1 seule ou 2 connexions simultanées pour envoyer les données.
Les deux tableaux ci-dessous présentent les meilleurs résultats obtenus après plusieurs tests.

Envoi de 10 000 fichiers de 10 ko (soit 102 400 000 octets) :

Envoi de 10 000 fichiers de 1 ko (soit 10 240 000 octets) :

Avant de commenter ces résultats, je tiens à souligner qu’ils ne doivent pas être considérés comme une vérité universelle. Bien que j’aie obtenu des valeurs similaires à plusieurs reprises, celles-ci dépendent des configurations matérielles, logicielles et réseau mises en place et il est probable que les performances varient dans d’autres environnements de test.
De plus, mes recherches sur le web indiquent généralement que FTPS est plus rapide que SFTP (par exemple ici, et ici). Pourtant, dans les résultats présentés dans ce billet, SFTP est clairement 3 à 4 fois plus rapide que FTPS. Étant donné que les deux serveurs sont configurés de manière standard, je ne suis pas en mesure d’expliquer SFTP a un avantage net en termes de performance.

Dans le contexte de ces tests, on constate que :

• ByteSync est beaucoup plus rapide que le protocole FTPS : le rapport va de 50 à 100 en faveur de ByteSync !
• ByteSync est beaucoup plus rapide que le protocole SFTP : le rapport va de 15 à 30 en faveur de ByteSync !
• ByteSync est 20 % plus rapide pour traiter les fichiers de 1 ko que ceux de 10 ko, là où le transfert en FTPS est plus lent (?!?) et le transfert en SFTP est seulement 7 % plus rapide. Il y a pourtant 10 fois moins de données à transmettre !

Vous pouvez constater par vous-même la différence de performances dans la vidéo ci-dessous. Attention : la vitesse de transfert des petits fichiers de ByteSync a été multipliée par 2 depuis l’enregistrement de cette vidéo.

Pourquoi FTPS et SFTP sont lents sur les petits fichiers

Le protocole FTPS (File Transfer Protocol Secure) et le protocole SFTP (Secure/SSH File Transfer Protocol) sont couramment utilisés pour transférer des fichiers sur Internet. Bien que différents, ces deux protocoles présentent de nombreuses similitudes. Ils reposent sur le protocole TCP (Transmission Control Protocol), sont conçus pour offrir une communication sécurisée entre le client et le serveur, et ils offrent une logique de fonctionnement analogue.
Malheureusement, les protocoles FTPS et FTPS sont peu efficaces pour traiter les petits fichiers. Comme nous l’avons constaté ci-dessus, plus la taille des fichiers diminue et plus la vitesse globale de transfert chute. Cette inefficacité s’explique en partie par trois raisons majeures dont les conséquences négatives se cumulent.

Processus de négociation

Une des principales causes de cette lenteur est le processus de négociation qui est requis pour chaque transfert de fichier. Cette négociation implique plusieurs échanges d’informations entre le client et le serveur. Le processus peut être résumé comme suit :

1. Le client annonce qu’il veut envoyer un fichier.
2. Le serveur autorise la demande du client.
3. Le client envoie les données.
4. Le serveur acquitte la réception des données, ferme le descripteur de fichier et met à jour les dates du fichier.

Puisque ce processus de négociation est répété pour chaque transfert de fichier, les étapes 1, 2 et 4 sont systématiques et ont la même durée, indépendamment de la taille du fichier. Par conséquent, plus les fichiers sont petits, plus l’étape 3 est courte et plus l’impact des étapes 1, 2 et 4 sur la durée totale du transfert est important.

Latence réseau

Par ailleurs, la latence réseau peut ralentir les aller-retours entre le client et le serveur et avoir un impact significatif sur les performances des protocoles FTPS et SFTP. La latence réseau correspond au temps que mettent les données pour transiter d’un point à un autre sur le réseau, et elle peut être influencée par divers facteurs tels que la distance géographique entre les deux points, la qualité de la connexion, la congestion du réseau, etc.
Plus la latence est élevée, plus il y a de temps entre le moment où le client envoie une commande et le moment où le serveur la reçoit, et inversement. Cela entraîne des retards dans la réponse du serveur aux commandes du client et ralentit les étapes 1, 2 et 4 du processus de négociation.
Que ce soit en FTPS ou en SFTP, durant l’étape 3, le client envoie les données en utilisant le protocole TCP. Ainsi, les données sont transmises sous la forme de segments consécutifs sans attendre l’acquittement du serveur. Le serveur pourra acquitter en une seule fois la réception de plusieurs segments de données. De ce fait, la latence réseau a moins d’impact sur l’étape 3 que sur les autres étapes, car les parties ont moins souvent besoin d’attendre la réponse de l’autre partie pour effectuer leurs traitements. Ce fonctionnement favorise la vitesse globale de transfert des gros fichiers.

Pour plus d’informations sur le fonctionnement du protocole TCP, vous pouvez consulter l’article https://www.ionos.fr/digitalguide/serveur/know-how/presentation-de-tcp/.

Entête TCP

L’entête TCP entraîne une surcharge qui est proportionnellement beaucoup plus forte sur les très petits fichiers. Présente au début de chaque segment transféré, l’entête comprend les informations nécessaires à la transmission des données sur le réseau. La taille de l’entête peut varier, mais elle utilise dans la plupart des cas 20 octets en IPv4 et 40 octets en IPv6 (elle peut être plus longue, jusqu’à 40 octets supplémentaires, si elle contient des options TCP additionnelles).

L’impact de l’entête TCP dépend de la taille des paquets qui transitent. En considérant un MTU (Maximum Transmission Unit) de 1 500 octets, qui est une valeur commune sur Internet :

• Si la longueur du fichier à transférer est de 1 000 octets, l’entête TCP en IPv4 (20 octets) représente une surcharge de 2 %, et l’entête TCP en IPv6 (40 octets) représente une surcharge de 4 %.
• Si la longueur du fichier à transférer est de 100 octets, l’entête TCP en IPv4 représente une surcharge de 20 %, et l’entête TCP en IPv6 représente une surcharge de 40 %.
• Si la longueur du fichier à transférer est de 10 octets, l’entête TCP en IPv4 représente une surcharge de 200 %, et l’entête TCP en IPv6 représente une surcharge de 400 %.
• Quand le fichier est plus volumineux et qu’il doit être découpé en plusieurs paquets, la surcharge moyenne de l’entête TCP reste proportionnellement faible en comparaison avec la taille du fichier.

Pour des exemples de cas plus détaillés, vous pouvez consulter l’article https://packetpushers.net/tcp-over-ip-bandwidth-overhead/.

Pourquoi ByteSync est beaucoup plus rapide que FTPS et SFTP pour transférer les petits fichiers

ByteSync est une solution de synchronisation de fichiers de haute performance. Pour transférer les fichiers, la solution utilise le protocole HTTPS (Hypertext Transfer Protocol Secure) et les fait transiter temporairement par les serveurs Azure. Par sécurité, les données sont chiffrées avant leur transmission en AES-256 dans le cadre du chiffrement de bout-en-bout (End-to-end encryption) propre à chaque session de synchronisation. Initialement conçu pour le transfert des contenus Web, et aujourd’hui massivement utilisé dans les API et les échanges Cloud, le protocole HTTPS fonctionne différemment des protocoles FTPS et SFTP, mais tout comme eux, repose sur le protocole TCP.

Ainsi, les problématiques liées à la latence réseau et à l’entête TCP, que nous avons vues plus haut, s’appliquent également aux transferts de petits fichiers avec le protocole HTTPS. De plus, comme le client ByteSync émetteur dépose dans un premier temps les données sur les serveurs Azure avant que le client ByteSync destinataire ne les télécharge, une nouvelle latence est introduite à chaque transfert. Dans les mesures initiales effectuées avec ByteSync, la latence liée à la mise en tampon sur les serveurs Azure était beaucoup plus importante que la lenteur liée aux processus de négociation des protocoles FTPS et SFTP.

Afin d’optimiser la vitesse de transfert de ByteSync et d’obtenir les excellents résultats présentés plus haut, deux systèmes logiciels complémentaires ont été développés et intégrés à la solution.

Archive temporaire de transfert

Au lieu de transférer les petits fichiers un par un, ByteSync les ajoute à une archive temporaire de transfert. Lorsque cette archive comprend suffisamment de fichiers, elle est chiffrée en AES-256, téléchargée sur les serveurs Azure, puis téléchargée depuis les serveurs Azure par le client destinataire. Elle est alors extraite par le client destinataire et enfin, les dates de création et de dernière modification des fichiers sont rétablies.
Ainsi, pour 10 000 fichiers de 10 ko, les données sont envoyées sous la forme d’une douzaines d’archives. On passe alors de 10 000 envois et téléchargements à 12 envois et téléchargements.
En comparaison avec les lenteurs engendrées à la fois par les processus de négociation de FTPS et SFTP, l’entête TCP, et la mise en tampon sur le serveur Azure, il est évident le temps de préparation et d’extraction de ces archives temporaires est négligeable.

Parallélisation des opérations et gestion des ressources

Comme les opérations de création, de transfert et d’extraction des archives temporaires de transfert prennent chacune du temps (plusieurs secondes au moins), un travail important d’optimisation a été effectué au niveau de la parallélisation des actions et de la gestion de la mémoire. Tout est mis en œuvre pour que les actions soient effectuées en parallèle sans surcharger l’usage des ressources disponibles sur les machines.

Ainsi, pendant qu’une archive temporaire de transfert est préparée sur le client émetteur, une archive créée précédemment est transférée tandis qu’une autre plus ancienne est décompressée par le client destinataire.

ByteSync va encore plus loin

Comme évoqué précédemment, ByteSync utilise des serveurs Azure pour faire office de tampon dans le Cloud entre le client émetteur et le client destinataire. C’est le fonctionnement de base pour une session avec 2 clients distants.
Toutefois, ByteSync autorise jusqu’à 5 clients distants par session. Et dans le cas où les mêmes données sont envoyées à plusieurs clients, le client émetteur les envoie en une seule fois sur les serveurs Azure puis chaque client destinataire les télécharge en parallèle. Ce fonctionnement est plus performant que celui des synchronisations avec FTPS et SFTP, dans lesquelles les mêmes données doivent être envoyées par l’émetteur à chacun des destinataires.
Ainsi, si nous appliquons les exemples des comparaisons ci-dessus à un cas où 1 client envoie les mêmes données à 4 clients distants, le temps global de transfert de ByteSync reste sensiblement le même, là où les durées globales de transfert en FTPS et SFTP sont multipliées par 4 !

Par ailleurs, ByteSync ne réserve pas uniquement le système des archives temporaires de transfert à la synchronisation initiale des petits fichiers. Ces archives sont aussi utilisées pour le transfert des différences entre les fichiers, qui sont stockées dans fichiers deltas, si ces fichiers deltas sont suffisamment petits. Ainsi, même dans le cas d’une resynchronisation massive où les différences entre les fichiers sont peu nombreuses, les performances de ByteSync sont optimales.

La gestion des différences et la compression delta de ByteSync ne sont pas traitées dans ce billet, mais je tenais à préciser que même dans ce cas là, tout est fait pour que obtenir la meilleure vitesse de transfert !

Conclusion

Les protocoles FTPS et SFTP peuvent être lents lorsqu’il s’agit de synchroniser ou de sauvegarder des petits fichiers. En effet, leurs processus de négociation alourdissent le transfert des petits fichiers et l’entête des segments TCP affecte plus négativement les échanges de très petits fichiers. De plus l’impact de latence réseau, qui ralentit les aller-retour d’informations entre client et serveur, est proportionnellement plus important sur les petits fichiers.
Par ailleurs, cette problématique de vitesse de transfert touche aussi de nombreux des logiciels de sauvegarde et de synchronisation qui opèrent fichier par fichier. Plus il y a de petits fichiers à transmettre, plus elle se fait ressentir.

Cependant, la lenteur de transfert des petits fichiers n’est pas une fatalité. ByteSync, qui repose également sur le protocole TCP et qui utilise les serveurs Azure comme zone de tampon, est soumis à des contraintes analogues. Pour remédier à ces difficultés, le logiciel exploite une archive temporaire de transfert dans laquelle sont copiés les fichiers à transférer, et il utilise des processus de parallélisation évolués pour éviter les temps morts.

Ainsi, le logiciel de synchronisation de données ByteSync est 10x plus rapide que les protocoles FTPS et SFTP pour échanger les petits fichiers. Ces performances en font le choix idéal pour tous ceux qui transfèrent fréquemment de petits fichiers et ont besoin d’une solution vraiment efficace. Si vous recherchez une solution de transfert de fichiers rapide, sécurisée et facile à utiliser, essayez ByteSync !