Geschiedenis van bestandsoverdracht: van Kermit tot rsync

Waarom bestandsoverdrachtprotocollen bleven veranderen

Bestandsoverdrachtprotocollen werden elk ontworpen met het oog op de faalmodi van hun eigen decennium. Kermit ging ervan uit dat de lijn uw bytes zou corrumperen. XMODEM en ZMODEM gingen ervan uit dat de verbinding traag was en dat u per minuut betaalde. FTP (file transfer protocol) ging ervan uit dat het tussenliggende netwerk coöperatief was. SSH ging ervan uit dat het vijandig was. Die laatste aanname is de winnende gebleken, en dat is de reden waarom een VPS tegenwoordig SFTP en rsync over SSH biedt en nauwelijks iets anders.

Er is nu een aanleiding om hiernaar te kijken. C-Kermit 11.0.506 werd uitgebracht op 3 augustus 2026. Het is de eerste niet-bèta release sinds C-Kermit 9.0.302 op 20 augustus 2011, en het protocol dat het implementeert werd ontworpen in mei 1981. Vijfenveertig jaar is lang genoeg om te zien hoe een hele categorie wordt uitgevonden, gestandaardiseerd, onbruikbaar wordt gemaakt door het netwerk waarop het draaide, en vervolgens wordt opgenomen in SSH.

Kermit, 1981: ontworpen voor een verbinding die uw bytes opeet

Kermit werd in mei 1981 ontwikkeld aan het Columbia University Computer Center door Frank da Cruz en Bill Catchings. De naam is afgeleid van Kermit de Kikker. Volgens Da Cruz hing er een Muppets-kalender aan de muur terwijl de groep een naam probeerde te bedenken, en niemand had verwacht dat het programma zo wijdverspreid zou raken.

Het probleem dat Kermit oploste, was niet de snelheid. Het pad tussen een terminal en een mainframe was geen pijplijn voor willekeurige bytes. Het was een karakter-device met beperkingen. Het kon 7-bit zijn. Het kon half-duplex zijn. Het kon controlekarakters inslikken of er een als commando uitvoeren. Het ongewijzigd versturen van een binair bestand werkte daarom niet.

Het ontwerp nam deze beperkingen letterlijk. De geschiedenis van het Kermit Project somt ze op:

• korte pakketten, omdat de meeste mainframes geen lange reeksen inkomende data van een terminal konden verwerken
• half-duplex stop-and-wait, omdat IBM-mainframes geen full-duplex communicatie ondersteunden
• afdrukbare coderingen voor controlekarakters en 8-bit karakters, omdat beide niet door de terminaldriver van het mainframe konden passeren
• een checksum op elk pakket, beantwoord door de ontvanger, zodat een corrupt pakket slechts één hertransmissie kost en niet het hele bestand

Het derde punt is het meest interessant. Kermit verstuurt een tekstveilige codering van uw bestand in plaats van het bestand zelf. Een controlebyte wordt een prefix-karakter gevolgd door een afdrukbaar karakter, en een byte met de high bit gezet kan op dezelfde manier worden gecodeerd voor een 7-bit verbinding. Alles daartussenin dat alleen afdrukbare tekst begrijpt, ziet ook alleen afdrukbare tekst. De prijs hiervan is de omvang: een binair bestand wordt groter tijdens de overdracht. Tegenover een mainframe-front-end die de overdracht anders volledig zou verminken, was dit de juiste afweging.

De andere ongebruikelijke eigenschap van Kermit is de reikwijdte. XMODEM verplaatste een bestand tussen twee machines die het al eens waren over wat een bestand was. Kermit werd geschreven als de kleinste gemene deler tussen systemen die het niet eens waren, met verschillende karaktersets, verschillende recordstructuren en verschillende ideeën over wat het einde van een tekstregel markeert. Dat is de wereld die wordt beschreven in de lange overgang van mainframes naar cloudservers, en Kermit is hoe interoperabiliteit eruitzag voordat de netwerklaag dit voor u afhandelde.

Columbia beëindigde de sponsoring in 2011 en bracht C-Kermit uit onder de herziene 3-clause BSD-licentie. Frank da Cruz bleef 44 jaar bij het project betrokken, van het ontwerp in 1981 tot en met 2025. De release van 2026 wordt onderhouden door het OpenKermit-project, waarbij John Goerzen het werk verricht om een C-codebase te moderniseren die ouder is dan de meeste mensen die dit nu lezen.

XMODEM en ZMODEM: toen de telefoonrekening het ontwerp bepaalde

Ward Christensen schreef MODEM.ASM in 1977, en het protocol dat hiermee werd geïntroduceerd is XMODEM. In 1978 brachten hij en Randy Suess CBBS online, het eerste publieke bulletin board system. Christensen overleed op 11 oktober 2024.

XMODEM is een van de meest compacte protocollen die er bestaan. Data wordt verplaatst in blokken van 128 bytes. Elk blok bevat een checksum van één byte, de som van de 128 databytes modulo 256. De ontvanger bevestigt elk blok of vraagt om een herhaling. De reden voor dit ontwerp is economisch. Op een inbelverbinding betaalt u voor de tijd, dus een lijnfout mag slechts één blok kosten in plaats van de gehele overdracht.

De zwakte schuilt in diezelfde beperking. XMODEM wacht na elke 128 bytes op een bevestiging. Chuck Forsberg verwoordde het helder in de ZMODEM-specificatie: "De korte bloklengte zorgt voor een lagere doorvoer bij gebruik van timesharing-systemen, pakketgeschakelde netwerken en satellietverbindingen." Latentie is wat stop-and-wait-protocollen vertraagt, niet de bandbreedte. Elke round-trip is verloren tijd op een lijn waarvoor u betaalt.

Daarna volgde YMODEM, een naam die Ward Christensen in 1985 bedacht. De bijdrage hiervan was batch-overdracht. De verzender geeft de bestandsnaam en de grootte op vóór de data, zodat meerdere bestanden in één sessie kunnen worden verstuurd en de ontvanger weet waar elk bestand eindigt.

ZMODEM is het antwoord van Chuck Forsberg, geschreven bij Omen Technology. De specificatie is herzien op 14 oktober 1988 en stelt dat "ZMODEM werd ontwikkeld voor het publieke domein onder een Telenet-contract". Telenet beheerde een publiek pakketgeschakeld datanetwerk, en dat contract is terug te zien in het ontwerp. ZMODEM ontsnapt aan netwerk-stuurkarakters zodat een pakketnetwerk in het midden deze niet consumeert. Het markeert het begin van elk frame met een unieke karakterreeks in plaats van framegrenzen af te leiden uit stilte, waardoor het herstelt van ruis zonder te wachten op een timeout. Het beschikt ook over een expliciete hervattingsfunctie, zodat een onderbroken overdracht doorgaat vanaf het punt waar deze stopte.

Het belangrijkste is dat het stopt met wachten. De beschrijving in de specificatie zelf is dat "ZMODEM in feite het gehele bestand als venster gebruikt". De verzender streamt en stopt alleen wanneer de ontvanger een probleem meldt. Dat is hetzelfde inzicht dat TCP in zijn venster verwerkt, bereikt vanuit de andere richting, door iemand die zag hoe een modem onbenut bleef.

Waarom de twee verbindingen van FTP zo slecht zijn verouderd

FTP is ouder dan al het andere. RFC 114, "A File Transfer Protocol", dateert van 16 april 1971 en is geschreven door A. Bhushan.

Het detail dat het vermelden waard is, is dat RFC 114 het ontwerp met twee verbindingen overwoog en verwierp. Bhushan woog het "gebruik van twee full-duplex verbindingen, één voor besturingsinformatie en de andere voor data" af en concludeerde: "Wij raden het gebruik van een enkele full-duplex verbinding aan voor de uitwisseling van zowel data als besturingsinformatie." De splitsing kwam later. RFC 354, gedateerd 8 juli 1972, stelt dat "data en bestanden alleen worden overgedragen via de dataverbinding", waarbij commando's via een afzonderlijke Telnet-verbinding verlopen. RFC 959, oktober 1985, door Postel en Reynolds, is de versie die iedereen nog steeds implementeert.

RFC 959 legde ook de poorten vast. De standaard datapoort van de server is "de poort naast de poort voor de besturingsverbinding (oftewel L-1)", wat poort 20 is wanneer de besturingsverbinding poort 21 is.

Dit is het onderdeel dat niet heeft standgehouden. In de oorspronkelijke modus van FTP opent de server de dataverbinding terug naar de client. Een client achter NAT (network address translation) heeft geen adres dat de server kan bereiken, en een client achter een firewall accepteert geen inkomende verbindingen. Hierdoor komt de dataverbinding nooit tot stand en blijft de overdracht hangen zodra een lijst of bestand wordt opgevraagd. De oplossing was PASV, dat RFC 959 definieert als een verzoek aan de server "om te 'luisteren' op een datapoort (die niet de standaard datapoort is) en te wachten op een verbinding in plaats van er zelf een te initiëren bij ontvangst van een overdrachtcommando". De server antwoordt met het adres en de poort waarmee verbinding moet worden gemaakt:

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

Dat antwoord betekent host 203.0.113.10, poort 195 maal 256 plus 80, wat 50000 is. Lees het opnieuw en het structurele probleem wordt zichtbaar. Het eindpunt van de tweede verbinding wordt aangekondigd in de payload van de eerste. Een NAT-box of firewall kan die verbinding niet doorlaten tenzij deze het besturingskanaal parseert en de poort opent die daar wordt vermeld. Linux levert een connection tracking helper die precies dit doet. De helper werkt alleen zolang de besturingsverbinding in leesbare tekst (cleartext) is; het inpakken van FTP in TLS (transport layer security) maakt de tussenliggende apparatuur die FTP bruikbaar hield, blind.

Dat is de les van FTP in één zin. Het maakte het netwerk een deelnemer in het protocol. Een protocol dat vereist dat het netwerk het begrijpt, kan niet overleven in een netwerk dat het niet langer vertrouwt.

Het einde is officieel. Firefox verwijderde FTP-ondersteuning in versie 90 in juli 2021. Chrome verwijderde de FTP-code in Chrome 95 in oktober 2021.

rcp en de r-commando's: vertrouwen op basis van hostnaam

4.2BSD, in 1983 uitgebracht door Berkeley met financiering van DARPA, introduceerde rcp, rsh en rlogin. Deze waren gebouwd voor een campus vol Unix-machines op één netwerk, en het authenticatiemodel weerspiegelt dit. Een host claimde welke gebruiker de aanroep deed. Als /etc/hosts.equiv of een ~/.rhosts van een gebruiker aangaf dat de host vertrouwd was, werd de claim geaccepteerd en werd er niet om een wachtwoord gevraagd.

Beschrijf het mechanisme helder, want dit is de reden waarom deze commando's zijn verdwenen. Vertrouwen was gebaseerd op een adres en een claim. Beide reizen in leesbare tekst over het netwerk, waardoor iedereen op het pad ze kan lezen en iedereen op het pad ze kan vervalsen. Dat model was logisch in de omgeving die wordt beschreven in het pad van Unix naar Linux, waar het netwerk een gebouw was. Het verloor zijn logica op het moment dat het netwerk het internet werd.

Wat rcp goed deed, was de interface. Bron, bestemming, klaar. Geen sessie om te openen, geen overdrachtsmodus om te onderhandelen, geen tweede verbinding om te regelen. Het gedraagt zich als cp met een dubbele punt in het pad. Die interface heeft zijn protocol met vier decennia overleefd.

SSH absorbeert de gehele categorie

In 1995 schreef Tatu Ylonen, destijds onderzoeker aan de Technische Universiteit van Helsinki, SSH als reactie op een aanval waarbij wachtwoorden werden onderschept op het universiteitsnetwerk. Hij bracht het in juli 1995 uit als vrije software inclusief broncode. Tegen het einde van dat jaar werd het aantal gebruikers geschat op ongeveer 20.000 in 50 landen, en in december 1995 richtte hij SSH Communications Security op om de verdere ontwikkeling te waarborgen.

De licentievoorwaarden werden bij latere versies strenger, waardoor ontwikkelaars van OpenBSD de laatste vrij gelicentieerde versie, ssh 1.2.12, hebben geforkt. De initiële import vond plaats op 26 september 1999 en OpenSSH 1.2.2 werd op 1 december 1999 uitgebracht met OpenBSD 2.6. Die fork is een compacte casestudy in waarom open-sourcelicentievoorwaarden in de praktijk ertoe doen, omdat de SSH-implementatie die vrijwel iedereen tegenwoordig gebruikt, afstamt van de enige versie waarvan de licentie dit nog toestond.

Zodra SSH bestond, was bestandsoverdracht niet langer een apart probleem. Een geauthenticeerde, versleutelde stream die meerdere kanalen ondersteunt, biedt al wat oudere protocollen zelf moesten opbouwen: integriteit, volgorde en een tweede datapad waarvoor geen tweede TCP-verbinding nodig is. Als die mechanismen nieuw voor u zijn, begin dan bij wat SSH daadwerkelijk is voordat u verdergaat.

Er kwamen twee tools uit voort. scp was het wire-protocol van rcp dat binnen een SSH-sessie werd uitgevoerd, wat verklaart waarom het de command-line van rcp exact heeft overgenomen. SFTP is een ander ontwerp: een echt bestandsprotocol met directory-listing, bestandskenmerken en random access, uitgevoerd over een SSH-kanaal. SFTP is nooit een RFC geworden. Het IETF-concept, draft-ietf-secsh-filexfer, bereikte versie 13 op 18 juli 2006 en is daarna verlopen. OpenSSH implementeert versie 3 van dat concept. Het meest gebruikte protocol voor veilige bestandsoverdracht ter wereld is een genummerde revisie van een verlaten concept, en het werkt.

Het legacy scp-protocol is inmiddels ook uitgefaseerd. OpenSSH 8.8, uitgebracht op 26 september 2021, waarschuwde dat "een toekomstige release van OpenSSH standaard zal overschakelen van het legacy scp/rcp-protocol naar SFTP voor scp(1)". OpenSSH 9.0, uitgebracht op 8 april 2022, voerde dit door: "Deze release schakelt scp(1) standaard over van het legacy scp/rcp-protocol naar het SFTP-protocol."

De reden verklaart een stukje folklore. Het oude scp-protocol breidde wildcards in externe bestandsnamen uit door ze door te geven aan de externe shell; daarom leerden mensen om elk metakarakter in een extern pad tussen dubbele aanhalingstekens te plaatsen. De aantekeningen bij 8.8 vermelden dat scp via SFTP "deze kieskeurige en fragiele quoting niet langer vereist". Op een huidige server is scp dus een SFTP-client die de command-line van rcp gebruikt. De interface uit 1983 is blijven bestaan. Het wire-protocol uit 1983 niet.

rsync, 1996: verstuur het verschil, niet het bestand

Andrew Tridgell en Paul Mackerras kondigden rsync aan op 19 juni 1996 aan de Australian National University, gelijktijdig met het technisch rapport TR-CS-96-05, "The rsync algorithm".

Elk protocol daarvoor stelde de vraag hoe een bestand verplaatst kon worden zonder corruptie. rsync stelde de vraag hoeveel van dit bestand de andere kant al bezit. Het rapport definieert het doel als "een bidirectionele communicatieverbinding met lage bandbreedte en hoge latentie", en het doel als het identificeren van "delen van het bronbestand die identiek zijn aan een deel van het doelbestand", zodat alleen de niet-overeenkomende delen worden verzonden.

Het mechanisme is het begrijpen waard, omdat het het gedrag van rsync verklaart. De ontvanger verdeelt zijn bestaande kopie in blokken van vaste grootte en berekent twee checksums per blok: een zwakke en goedkope, en een sterke en dure. Deze lijst wordt naar de zender gestuurd. De zender schuift een venster byte voor byte over zijn eigen bestand en werkt de zwakke checksum incrementeel bij; dit maakt een byte-voor-byte scan überhaupt haalbaar. Een zwakke match wordt vervolgens bevestigd aan de hand van de sterke checksum. Bevestigde matches worden blokverwijzingen. Al het overige wordt als letterlijke bytes verzonden. De ontvanger herbouwt het bestand op basis van verwijzingen naar blokken die hij al bezit, aangevuld met de letterlijke bytes die hij zojuist heeft ontvangen.

Voeg één byte toe aan het begin van een groot bestand en een eenvoudige 'difference'-tool moet het hele bestand opnieuw versturen, omdat elke offset is verschoven. Het schuivende venster vindt dezelfde blokken op hun nieuwe offsets, waardoor rsync slechts één byte plus wat administratieve gegevens verstuurt. Die eigenschap is de reden waarom rsync nog steeds de juiste tool is voor een map die u vaker dan één keer kopieert.

Twee gedragingen verrassen mensen regelmatig, en beide staan in de handleiding. Ten eerste controleert rsync bestanden niet met checksums om te bepalen of ze bekeken moeten worden. Het "vindt bestanden die overgezet moeten worden met een 'quick check'-algoritme (standaard), dat zoekt naar bestanden waarvan de grootte of de laatste wijzigingstijd is veranderd". Een bestand waarvan de inhoud is gewijzigd terwijl de grootte en tijdstempel identiek bleven, wordt overgeslagen. --checksum verandert dit en zorgt ervoor dat beide kanten elk kandidaat-bestand volledig inlezen. Ten tweede staat het delta-algoritme standaard uit wanneer beide paden lokaal zijn, omdat het lezen en berekenen van checksums van twee kopieën op één machine meer kost dan het simpelweg kopiëren van de bytes. De besparing bestaat alleen wanneer de verbinding de vertragende factor is.

Wat u daadwerkelijk gebruikt op een VPS, en waarom

De korte versie: SFTP voor enkele bestanden, rsync over SSH voor een map die u vaker zult kopiëren.

Beide maken gebruik van SSH, waardoor ze automatisch de host key-verificatie en encryptie overnemen zonder extra configuratie. Dat is vijftig jaar aan ontwikkeling samengevat in een standaardinstelling. De ontwerpers van Kermit moesten ervan uitgaan dat de verbinding gegevens zou beschadigen, dus bouwden ze checksums en hertransmissie in het protocol. TCP doet dat tegenwoordig. Christensen en Forsberg moesten ervan uitgaan dat elke byte geld kostte, dus bouwden ze hervatting en streaming in. Het delta-algoritme van rsync doet dat nu, en doet het beter. De auteurs van FTP gingen uit van een netwerk van samenwerkende hosts, en dat is de enige van die aannames die onjuist bleek op een manier die geen enkele protocolwijziging kon herstellen.

Wat checksums u nog steeds opleveren

De term "checksum" heeft in de loop der geschiedenis drie verschillende functies vervuld, en deze zijn niet uitwisselbaar.

De checksums per pakket van Kermit en XMODEM detecteerden corruptie op de lijn. De TCP-checksum en de foutcorrectie in de linklaag dekken dit tegenwoordig af, wat de reden is dat geen enkele moderne overdrachtstool van u vraagt hierover na te denken.

De blok-checksums van rsync beantwoorden niet de vraag "is deze data correct". Ze beantwoorden de vraag "heeft u dit blok al". Een sterke checksum is daar een opzoeksleutel, geen verklaring over de herkomst van het bestand.

De derde functie is de enige die nog bij u ligt. Een gepubliceerde checksum bij een release-bestand beantwoordt een vraag die TLS niet kan beantwoorden. TLS bewijst dat u met de juiste server heeft gecommuniceerd. Het bewijst niet dat het juiste bestand op die server stond, en het doet niets voor een bestand dat u van een mirror heeft gehaald. Daarom zijn checksums en handtekeningen bij releases nog steeds de dertig seconden waard, en de gewoonte is eenvoudig aan te leren: controleer de checksum bij elke download die u installeert.

Al het andere in dit verhaal werd opgelost door de onderliggende laag. Dat laatste punt niet, omdat het nooit een netwerkprobleem was.

FAQ

Is FTP nog veilig om te gebruiken op een VPS?

Nee. Standaard FTP verstuurt inloggegevens en bestandsinhoud in leesbare tekst, waardoor iedereen op het netwerkpad deze kan onderscheppen. Het is bovendien afhankelijk van een firewall die het controlekanaal kan analyseren, wat onmogelijk wordt zodra u het controlekanaal versleutelt met TLS. Browsers hebben de ondersteuning inmiddels stopgezet: Firefox verwijderde FTP-ondersteuning in versie 90 in juli 2021, en Chrome verwijderde de code in versie 95 in oktober 2021. Gebruik SFTP over SSH; dit vereist slechts één poort en geen protocolbewuste tussenliggende netwerkapparatuur.

Waarom heeft FTP überhaupt een passieve modus nodig?

Omdat de server in de oorspronkelijke modus van FTP de dataverbinding terug opent naar de client. RFC 959 stelt de standaard datapoort van de server in op "de poort naast de poort van de controleverbinding (d.w.z. L-1)", dus poort 20 wanneer de controleverbinding op poort 21 loopt. Een client achter NAT (network address translation) heeft geen adres dat de server kan bereiken, waardoor die verbinding nooit aankomt en de overdracht blijft hangen. PASV draait de richting om: de server luistert in plaats daarvan en antwoordt met een adres en poort binnen een 227 Entering Passive Mode-bericht, zodat de client hiermee verbinding kan maken.

Gebruikt scp nog steeds zijn eigen protocol?

Niet meer sinds OpenSSH 9.0, uitgebracht op 8 april 2022, dat "scp(1) standaard omschakelt van het verouderde scp/rcp-protocol naar het SFTP-protocol". OpenSSH 8.8 kondigde deze wijziging aan in september 2021. Het zichtbare verschil zit in het gebruik van aanhalingstekens. Het oude protocol breidde remote wildcards uit door ze door te geven aan de remote shell; het op SFTP gebaseerde protocol doet dit niet. Paden die afhankelijk waren van die shell-expansie gedragen zich daarom nu anders.

Wanneer is rsync beter dan scp voor een VPS?

Wanneer u dezelfde mappenstructuur vaker dan één keer wilt kopiëren. rsync verstuurt alleen de delen van elk bestand die de bestemming nog niet heeft, waardoor de tweede kopie aanzienlijk sneller is dan de eerste. Voor een enkel bestand dat de bestemming nog nooit heeft gezien, verplaatsen scp en rsync ongeveer evenveel bytes en is scp eenvoudiger. Houd er rekening mee dat rsync standaard beslist wat het moet bekijken op basis van grootte en wijzigingstijd; een bestand waarvan de inhoud is gewijzigd terwijl de grootte en tijdstempel gelijk bleven, heeft --checksum nodig voordat rsync de wijziging opmerkt.

Waarom codeerde Kermit bestanden als afdrukbare tekst in plaats van ruwe bytes te versturen?

Omdat de verbinding waarvoor het bedoeld was een terminalverbinding met een mainframe was, en geen transparante byte-pipe. Die verbindingen konden 7-bits zijn, en de terminaldriver van het mainframe reageerde op stuurkarakters in plaats van ze door te laten. Kermit codeerde stuurbytes en bytes met een hoge bit naar afdrukbare tekens, zodat niets in het middenpad erop zou reageren. De codering maakt binaire bestanden groter tijdens de overdracht, wat een acceptabele afweging was tegen een overdracht die anders corrupt zou aankomen.