Protocoles de transfert : de Kermit à rsync

Pourquoi les protocoles de transfert de fichiers n’ont cessé d’évoluer

Chaque protocole de transfert de fichiers a été conçu pour répondre au mode de défaillance caractéristique de son époque. Kermit partait du principe que la ligne pouvait corrompre vos octets. XMODEM et ZMODEM partaient du principe que la connexion était lente et que chaque minute était facturée. FTP (file transfer protocol) partait du principe que le réseau intermédiaire coopérait. SSH partait du principe qu’il était hostile. C’est cette dernière hypothèse qui s’est imposée. C’est pourquoi un VPS fournit aujourd’hui SFTP et rsync via SSH, et très peu d’autres solutions.

Il est pertinent de se pencher sur ce sujet maintenant. C-Kermit 11.0.506 est sorti le 3 août 2026. Il s’agit de la première version stable depuis C-Kermit 9.0.302, sorti le 20 août 2011. Le protocole qu’il implémente a été conçu en mai 1981. Quarante-cinq ans suffisent pour voir toute une catégorie apparaître, être standardisée, mise en échec par le réseau sur lequel elle fonctionnait, puis intégrée à SSH.

Kermit, 1981 : conçu pour une liaison qui mange vos octets

Kermit a été créé en mai 1981 au Columbia University Computer Center par Frank da Cruz et Bill Catchings. Son nom vient de Kermit la grenouille. Selon le récit de da Cruz, un calendrier des Muppets était accroché au mur pendant que le groupe cherchait un nom, et personne ne s’attendait à ce que le logiciel se diffuse autant.

Kermit ne résolvait pas un problème de vitesse. La liaison entre un terminal et un mainframe n’était pas un tuyau transportant des octets arbitraires. C’était un périphérique caractère avec ses propres contraintes. Elle pouvait être limitée à 7 bits. Elle pouvait fonctionner en semi-duplex. Elle pouvait supprimer des caractères de contrôle ou interpréter l’un d’eux comme une commande. L’envoi sans modification d’un fichier binaire par cette liaison ne fonctionnait donc pas.

La conception a donc pris ces contraintes au pied de la lettre. L’historique du Kermit Project les énumère :

• des paquets courts, car la plupart des mainframes ne pouvaient pas recevoir de longues rafales de données depuis un terminal
• un fonctionnement en semi-duplex avec attente après chaque paquet, car les mainframes IBM ne prenaient pas en charge les communications full-duplex
• des encodages imprimables pour les caractères de contrôle et les caractères 8 bits, car aucun des deux ne pouvait traverser le driver de terminal du mainframe
• une somme de contrôle sur chaque paquet, avec une réponse du récepteur, afin qu’un paquet corrompu entraîne une seule retransmission et non le renvoi du fichier entier

Le troisième point est le plus intéressant. Kermit envoie un encodage de votre fichier compatible avec le texte, et non le fichier lui-même. Un octet de contrôle devient un caractère préfixe suivi d’un caractère imprimable. Un octet dont le bit de poids fort est activé peut être encodé de la même façon pour une liaison 7 bits. Tout équipement intermédiaire qui ne comprend que le texte imprimable reçoit donc du texte imprimable. Le coût est une augmentation de la taille : un fichier binaire grossit pendant le transfert. Face à un frontal de mainframe qui aurait autrement entièrement altéré le transfert, c’était le bon compromis.

L’autre propriété inhabituelle de Kermit est sa portée. XMODEM transférait un fichier entre deux machines qui étaient déjà d’accord sur la définition d’un fichier. Kermit a été conçu comme un plus petit dénominateur commun entre des systèmes qui n’étaient pas d’accord, avec des jeux de caractères différents, des structures d’enregistrements différentes et des conceptions différentes de la fin d’une ligne de texte. C’est le monde décrit dans la longue transition des mainframes vers les serveurs cloud, et Kermit correspond à ce qu’était l’interopérabilité avant que la couche réseau ne la prenne en charge à votre place.

Columbia a mis fin à son soutien au projet en 2011 et a publié C-Kermit sous la licence BSD révisée à 3 clauses. Frank da Cruz est resté associé au projet pendant 44 ans, de la conception de 1981 jusqu’en 2025. La version 2026 est maintenue par le projet OpenKermit, avec John Goerzen chargé de moderniser une base de code C plus ancienne que la plupart des personnes qui la lisent aujourd’hui.

XMODEM et ZMODEM : quand le coût des communications a façonné la conception

Ward Christensen a écrit MODEM.ASM en 1977, et le protocole qu’il a introduit est XMODEM. En 1978, lui et Randy Suess ont mis CBBS en ligne, le premier bulletin board system public. Christensen est mort le 11 octobre 2024.

XMODEM est presque aussi minimal qu’un protocole puisse l’être. Les données circulent par blocs de 128 octets. Chaque bloc contient une somme de contrôle d’un octet, correspondant à la somme des 128 octets de données modulo 256. Le récepteur accuse réception de chaque bloc ou demande sa retransmission. Cette conception répond à des contraintes économiques. Sur une ligne commutée, vous payez le temps de connexion. Une erreur de transmission doit donc coûter un bloc, et non l’intégralité du transfert.

La faiblesse se trouve dans la même caractéristique. XMODEM attend un accusé de réception après chaque bloc de 128 octets. Chuck Forsberg l’explique clairement dans la spécification de ZMODEM : « La petite taille des blocs dégrade le débit lorsqu’ils sont utilisés avec des systèmes en temps partagé, des réseaux à commutation de paquets ou des liaisons satellite. » C’est la latence, et non la bande passante, qui pénalise le fonctionnement en attente après chaque bloc. Chaque aller-retour laisse la ligne inactive alors que vous êtes facturé.

YMODEM est arrivé ensuite, et Ward Christensen a créé ce nom en 1985. Son apport est le transfert par lots. L’émetteur indique le nom et la taille du fichier avant les données. Plusieurs fichiers peuvent ainsi être transférés au cours d’une même session, et le récepteur sait où se termine chacun d’eux.

ZMODEM est la réponse de Chuck Forsberg, écrite chez Omen Technology. La spécification est datée du 14 octobre 1988 et indique que « ZMODEM a été développé pour le domaine public dans le cadre d’un contrat avec Telenet ». Telenet exploitait un réseau public de données à commutation de paquets, et ce contrat se retrouve dans la conception. ZMODEM échappe les caractères de contrôle réseau afin qu’un réseau à commutation de paquets situé sur le trajet ne les consomme pas. Il marque le début de chaque trame avec une séquence de caractères unique, au lieu de déduire les limites des trames à partir des silences. Il peut ainsi récupérer après du bruit sans attendre l’expiration d’un timeout. Il dispose également d’une reprise explicite : un transfert interrompu reprend là où il s’était arrêté.

Surtout, il cesse d’attendre. La spécification décrit elle-même ce fonctionnement ainsi : « ZMODEM utilise en pratique l’intégralité du fichier comme fenêtre. » L’émetteur transmet en continu et ne s’arrête que lorsque le récepteur signale un problème. C’est la même idée que TCP encode dans sa fenêtre, mais abordée dans l’autre sens, par quelqu’un qui regardait un modem rester inactif.

Pourquoi les deux connexions de FTP ont si mal vieilli

FTP est plus ancien que tous ces protocoles. La RFC 114, « A File Transfer Protocol », date du 16 avril 1971 et a été rédigée par A. Bhushan.

Le point important est que la RFC 114 avait étudié la conception à deux connexions, puis l’avait rejetée. Bhushan a envisagé « l’utilisation de deux liaisons bidirectionnelles, l’une pour les informations de contrôle et l’autre pour les données », avant de conclure : « Nous recommandons d’utiliser une seule connexion bidirectionnelle pour l’échange des données et des informations de contrôle. » La séparation est arrivée plus tard. La RFC 354, datée du 8 juillet 1972, indique que « les données et les fichiers sont transférés uniquement via la connexion de données », tandis que les commandes circulent sur une connexion Telnet distincte. La RFC 959, publiée en octobre 1985 par Postel et Reynolds, est la version que tout le monde implémente encore.

La RFC 959 a également fixé les ports. Le port de données par défaut du serveur est « le port adjacent au port de la connexion de contrôle (c’est-à-dire L-1) », soit le port 20 lorsque la connexion de contrôle utilise le port 21.

Voici ce qui n’a pas résisté. Dans le mode FTP d’origine, c’est le serveur qui ouvre la connexion de données vers le client. Un client derrière un NAT (network address translation) n’a pas d’adresse que le serveur puisse joindre. Un client derrière un firewall n’accepte pas les connexions entrantes. La connexion de données n’arrive donc jamais et le transfert se bloque dès qu’une liste de fichiers ou un fichier est demandé. La réponse a été PASV. La RFC 959 le définit comme une demande adressée au serveur pour « écouter sur un port de données (qui n’est pas son port de données par défaut) et attendre une connexion au lieu d’en initier une à la réception d’une commande de transfert ». Le serveur répond avec l’adresse et le port auxquels se connecter :

PASV
227 Entering Passive Mode (203,0,113,10,195,80)

Cette réponse signifie que l’hôte est 203.0.113.10 et que le port vaut 195 multiplié par 256, plus 80, soit 50000. Relisez-la : le problème structurel apparaît clairement. Le point de terminaison de la deuxième connexion est annoncé dans la charge utile de la première. Un équipement NAT ou un firewall ne peut pas laisser passer cette connexion s’il n’analyse pas le canal de contrôle et n’ouvre pas le port qui y est indiqué. Linux fournit un helper de suivi des connexions qui fait exactement cela. Ce helper ne fonctionne que tant que la connexion de contrôle reste en clair. Chiffrer FTP avec TLS (transport layer security) rend donc aveugle le middlebox qui permettait à FTP de fonctionner.

C’est la leçon de FTP en une phrase. FTP faisait du réseau un participant au protocole. Un protocole qui a besoin que le réseau le comprenne ne peut pas survivre à un réseau qui cesse de lui faire confiance.

La fin est documentée. Firefox a supprimé la prise en charge de FTP dans la version 90, en juillet 2021. Chrome a supprimé le code FTP dans Chrome 95, en octobre 2021.

rcp et les r-commandes : la confiance par nom d’hôte

4.2BSD, publié en 1983 par Berkeley avec un financement de la DARPA, a introduit rcp, rsh et rlogin. Ces commandes étaient conçues pour un campus regroupant des machines Unix sur un même réseau, et leur modèle d’authentification le montre. Un hôte indiquait quel utilisateur se connectait. Si /etc/hosts.equiv ou le ~/.rhosts de l’utilisateur indiquait que cet hôte était approuvé, cette déclaration était acceptée et aucun mot de passe n’était demandé.

Il faut décrire clairement ce mécanisme, car c’est la raison pour laquelle ces commandes ont disparu. La confiance reposait sur une adresse et une déclaration. Ces deux éléments circulaient en clair sur le réseau. Toute personne située sur le chemin pouvait donc les lire et les falsifier. Ce modèle était cohérent dans l’environnement décrit dans le chemin d’Unix vers Linux, où le réseau se limitait à un bâtiment. Il a cessé de l’être dès que le réseau est devenu Internet.

rcp avait correctement conçu son interface. Source, destination, terminé. Aucune session à ouvrir, aucun mode de transfert à négocier, aucune seconde connexion à établir. Son fonctionnement ressemble à celui de cp avec deux-points dans le chemin. Cette interface a survécu à son protocole de quatre décennies.

SSH couvre toute la catégorie

En 1995, Tatu Ylonen, alors chercheur à l’université de technologie d’Helsinki, a écrit SSH en réaction à une attaque par interception de mots de passe sur le réseau de l’université. Il l’a publié comme logiciel libre avec son code source en juillet 1995. À la fin de cette année, on estimait qu’il comptait environ 20,000 utilisateurs dans 50 pays. En décembre 1995, il a fondé SSH Communications Security pour poursuivre son développement.

La licence est devenue plus restrictive dans les versions suivantes. Les développeurs d’OpenBSD ont donc créé un fork à partir de la dernière version distribuée sous une licence libre, ssh 1.2.12. L’import initial a eu lieu le 26 septembre 1999. OpenSSH 1.2.2 a été publié avec OpenBSD 2.6 le 1 décembre 1999. Ce fork illustre concrètement pourquoi les conditions des licences open source sont importantes, car l’implémentation SSH utilisée par presque tout le monde aujourd’hui descend de la seule version dont la licence l’autorisait encore.

Une fois SSH disponible, le transfert de fichiers a cessé d’être un problème distinct. Un flux authentifié et chiffré qui transporte plusieurs canaux fournit déjà ce que les anciens protocoles devaient implémenter eux-mêmes : l’intégrité, l’ordre des données et un second chemin de données qui ne nécessite pas de seconde connexion TCP. Si ces mécanismes vous sont nouveaux, commencez par voir ce qu’est réellement SSH avant d’aller plus loin.

Deux outils en sont issus. scp était le protocole filaire de rcp exécuté dans une session SSH. C’est pourquoi il a repris exactement la ligne de commande de rcp. SFTP repose sur une conception différente : c’est un véritable protocole de fichiers, avec la liste des répertoires, les attributs des fichiers et l’accès aléatoire, transporté sur un canal SSH. SFTP n’est jamais devenu une RFC. Le draft de l’IETF, draft-ietf-secsh-filexfer, a atteint la version 13 le 18 juillet 2006, puis a expiré. OpenSSH implémente la version 3 de ce draft. Le protocole de transfert de fichiers sécurisé le plus utilisé au monde est une révision numérotée d’un draft abandonné, et il fonctionne.

Le protocole scp historique a lui aussi été retiré. OpenSSH 8.8, publié le 26 septembre 2021, avertissait qu’une « future version proche d’OpenSSH basculerait scp(1) du protocole scp/rcp historique vers SFTP par défaut ». OpenSSH 9.0, publié le 8 avril 2022, l’a fait : « Cette version bascule scp(1) du protocole scp/rcp historique vers le protocole SFTP par défaut. »

La raison explique une pratique bien connue. L’ancien protocole scp développait les jokers des noms de fichiers distants en les transmettant au shell distant. C’est pourquoi les utilisateurs ont appris à placer chaque métacaractère d’un chemin distant entre guillemets doubles. Les notes de version de la 8.8 indiquent que scp sur SFTP « ne nécessite plus cette gestion minutieuse et fragile des guillemets ». Ainsi, sur un serveur actuel, scp est un client SFTP qui utilise la ligne de commande de rcp. L’interface de 1983 a survécu. Le protocole filaire de 1983, lui, n’a pas survécu.

rsync, 1996 : envoyer les différences, pas le fichier

Andrew Tridgell et Paul Mackerras ont annoncé rsync le 19 June 1996 à l’Australian National University, avec le rapport technique TR-CS-96-05, « The rsync algorithm ».

Avant rsync, chaque protocole cherchait à transférer un fichier sans le corrompre. rsync a posé une autre question : quelle partie de ce fichier l’autre extrémité possède-t-elle déjà ? Le rapport décrit la cible comme « une liaison de communication bidirectionnelle à faible bande passante et forte latence » et l’objectif comme l’identification des « parties du fichier source qui sont identiques à une partie du fichier de destination », afin de n’envoyer que les parties qui ne correspondent pas.

Il est utile de comprendre le mécanisme, car il explique le comportement de rsync. Le récepteur découpe sa copie existante en blocs de taille fixe et calcule deux sommes de contrôle par bloc : une faible et rapide à calculer, l’autre forte et coûteuse à calculer. Il envoie cette liste à l’émetteur. L’émetteur fait glisser une fenêtre sur son propre fichier, un octet à la fois, et met à jour progressivement la somme de contrôle faible. C’est ce qui rend possible une analyse octet par octet à un coût raisonnable. Une correspondance faible est ensuite confirmée avec la somme de contrôle forte. Les correspondances confirmées deviennent des références de blocs. Tout le reste est envoyé sous forme d’octets littéraux. Le récepteur reconstruit le fichier à partir des références vers les blocs qu’il possède déjà et des octets littéraux qu’il vient de recevoir.

Si vous insérez un octet au début d’un fichier volumineux, un outil de comparaison naïf doit envoyer le fichier entier, car tous les offsets ont changé. La fenêtre glissante retrouve les mêmes blocs à leurs nouveaux offsets. rsync envoie donc un octet et les informations de gestion associées. C’est pour cette raison que rsync reste adapté à un répertoire que vous copierez plusieurs fois.

Deux comportements surprennent régulièrement les utilisateurs. Ils sont tous les deux documentés dans le manuel. Premièrement, rsync ne calcule pas la somme de contrôle des fichiers pour décider s’il doit les examiner. Il « trouve les fichiers qui doivent être transférés avec un algorithme de “vérification rapide” (par défaut), qui recherche les fichiers dont la taille ou la date de dernière modification a changé ». Un fichier dont le contenu a changé alors que sa taille et son horodatage sont restés identiques est ignoré. --checksum modifie ce comportement et force les deux extrémités à lire entièrement chaque fichier candidat. Deuxièmement, l’algorithme delta est désactivé par défaut lorsque les deux chemins sont locaux, car lire et calculer la somme de contrôle de deux copies sur une même machine coûte plus cher que de copier les octets. Le gain n’existe que lorsque la liaison constitue le facteur limitant.

Ce que vous utiliserez réellement sur un VPS, et pourquoi

En bref : SFTP pour quelques fichiers, rsync sur SSH pour un répertoire que vous recopierez.

Les deux utilisent SSH. Ils bénéficient donc tous deux de la vérification de la clé de l’hôte et du chiffrement, sans configuration supplémentaire. Cela condense cinquante ans de travail dans une configuration par défaut. Les concepteurs de Kermit devaient partir du principe que la ligne corromprait les données. Ils ont donc intégré des sommes de contrôle et la retransmission au protocole. TCP s’en charge aujourd’hui. Christensen et Forsberg devaient partir du principe que chaque octet coûtait de l’argent. Ils ont donc intégré la reprise et le streaming. L’algorithme delta de rsync s’en charge aujourd’hui, et le fait mieux. Les auteurs de FTP partaient du principe que le réseau regroupait des hôtes coopératifs. C’est la seule de ces hypothèses qui s’est révélée fausse d’une manière qu’aucun travail sur le protocole ne pouvait corriger.

Ce que les sommes de contrôle garantissent encore

Le terme « checksum » a eu trois fonctions différentes au cours de cette histoire. Elles ne sont pas interchangeables.

Les checksums par paquet de Kermit et XMODEM détectaient les corruptions sur le réseau. Le checksum TCP et la correction d’erreurs de la couche liaison couvrent aujourd’hui ce besoin. C’est pourquoi aucun outil de transfert moderne ne vous demande d’y penser.

Les checksums par bloc de rsync ne répondent pas à la question « ces données sont-elles correctes ? ». Ils répondent à la question « avez-vous déjà ce bloc ? ». Un checksum fort sert ici de clé de recherche, pas d’indication sur l’origine du fichier.

La troisième fonction est la seule qui vous incombe encore. Un checksum publié avec un fichier de release répond à une question à laquelle TLS ne peut pas répondre. TLS prouve que vous avez communiqué avec le bon serveur. Il ne prouve pas que le bon fichier se trouvait sur ce serveur, et il ne protège pas un fichier récupéré depuis un mirror. C’est pourquoi les checksums et signatures des releases valent toujours les trente secondes nécessaires. L’habitude est facile à prendre : vérifiez le checksum de chaque téléchargement que vous installez.

Tout le reste de cette histoire a été résolu par la couche sous-jacente. Ce problème ne l’a pas été, car il n’a jamais relevé du réseau.

FAQ

FTP est-il toujours sûr à utiliser sur un VPS ?

Non. FTP en clair transmet les identifiants et le contenu des fichiers sans chiffrement. Toute personne située sur le chemin peut donc lire les deux. FTP dépend aussi d’un firewall capable d’analyser son canal de contrôle. Cela devient impossible dès que vous chiffrez ce canal avec TLS. Les navigateurs l’ont déjà abandonné : Firefox a supprimé la prise en charge de FTP dans la version 90, en juillet 2021, et Chrome a supprimé le code correspondant dans la version 95, en octobre 2021. Utilisez SFTP sur SSH. Cette solution ne nécessite qu’un seul port et aucun équipement intermédiaire capable d’interpréter le protocole.

Pourquoi FTP a-t-il besoin d’un mode passif ?

Parce que, dans le mode d’origine de FTP, le serveur ouvre la connexion de données vers le client. La RFC 959 définit le port de données par défaut du serveur comme « le port adjacent au port de la connexion de contrôle, c’est-à-dire L-1 ». Le port est donc 20 lorsque le contrôle utilise le port 21. Un client derrière un NAT (network address translation) n’a pas d’adresse que le serveur puisse joindre. La connexion n’arrive donc jamais et le transfert reste bloqué. PASV inverse le sens de la connexion : le serveur se met à l’écoute, puis renvoie une adresse et un port dans une réponse 227 Entering Passive Mode, auxquels le client se connecte.

scp utilise-t-il toujours son propre protocole ?

Plus depuis OpenSSH 9.0, publié le 8 avril 2022. Cette version « fait passer scp(1) de l’ancien protocole scp/rcp au protocole SFTP par défaut ». OpenSSH 8.8 avait annoncé ce changement en septembre 2021. La différence visible concerne les guillemets. L’ancien protocole développait les jokers distants en les transmettant au shell distant. Le protocole basé sur SFTP ne le fait pas. Les chemins qui dépendaient de cette expansion par le shell se comportent donc différemment maintenant.

Quand rsync est-il préférable à scp pour un VPS ?

Lorsque vous copiez la même arborescence plusieurs fois. rsync n’envoie que les parties de chaque fichier que la destination ne possède pas déjà. La deuxième copie coûte donc beaucoup moins cher que la première. Pour un fichier unique que la destination n’a jamais reçu, scp et rsync transfèrent à peu près le même nombre d’octets, et scp est plus simple. N’oubliez pas que rsync détermine par défaut les fichiers à examiner à partir de leur taille et de leur date de modification. Si le contenu d’un fichier a changé alors que sa taille et son horodatage sont restés identiques, il faut --checksum avant que rsync puisse le détecter.

Pourquoi Kermit encodait-il les fichiers sous forme de texte imprimable au lieu d’envoyer les octets bruts ?

Parce que la connexion visée était une ligne de terminal reliée à un mainframe, et non un flux d’octets. Ces liaisons pouvaient être limitées à 7 bits, et le pilote de terminal du mainframe interprétait les caractères de contrôle au lieu de les transmettre. Kermit encodait les octets de contrôle et les octets de poids fort sous forme de caractères imprimables afin qu’aucun équipement intermédiaire ne réagisse à leur contenu. Cet encodage augmente la taille des fichiers binaires sur le réseau. C’était toutefois le bon compromis face à un transfert qui serait autrement arrivé corrompu.