Dateiübertragungsprotokolle: Von Kermit bis rsync

Warum sich Dateiübertragungsprotokolle ständig änderten

Dateiübertragungsprotokolle wurden jeweils für das typische Ausfallverhalten ihrer Zeit entwickelt. Kermit ging davon aus, dass die Leitung Ihre Bytes beschädigen würde. XMODEM und ZMODEM gingen davon aus, dass die Verbindung langsam war und jede Minute Kosten verursachte. FTP (file transfer protocol) ging davon aus, dass das Netzwerk dazwischen zuverlässig zusammenarbeitete. SSH ging davon aus, dass es feindlich war. Diese letzte Annahme setzte sich durch. Deshalb bietet ein VPS heute SFTP und rsync über SSH und nur sehr wenig anderes.

Es gibt einen Anlass, das jetzt zu betrachten. C-Kermit 11.0.506 wurde am 3. August 2026 veröffentlicht. Es ist die erste Nicht-Beta-Version seit C-Kermit 9.0.302 vom 20. August 2011. Das darin implementierte Protokoll wurde im Mai 1981 entwickelt. Fünfundvierzig Jahre reichen aus, um zu beobachten, wie eine ganze Kategorie entsteht, standardisiert wird, an dem von ihr genutzten Netzwerk scheitert und anschließend in SSH aufgeht.

Kermit, 1981: für eine Leitung entwickelt, die Ihre Bytes verändert

Kermit wurde im Mai 1981 am Computer Center der Columbia University von Frank da Cruz und Bill Catchings entwickelt. Der Name stammt von Kermit dem Frosch. Laut da Cruz hing ein Muppets-Kalender an der Wand, während die Gruppe nach einem Namen suchte. Niemand erwartete, dass sich das Programm verbreiten würde.

Das Problem, das Kermit löste, war nicht die Geschwindigkeit. Die Verbindung zwischen einem Terminal und einem Mainframe war keine Leitung für beliebige Bytes. Sie war ein zeichenorientiertes Gerät mit eigenen Einschränkungen. Sie konnte 7-bit sein. Sie konnte im Halbduplex arbeiten. Sie konnte Steuerzeichen verwerfen oder eines davon als Befehl ausführen. Eine Binärdatei unverändert darüber zu übertragen, funktionierte nicht.

Das Design berücksichtigte diese Einschränkungen daher direkt. Die Geschichte des Kermit Project nennt folgende Punkte:

• kurze Pakete, weil die meisten Mainframes keine langen Bursts eingehender Daten von einem Terminal verarbeiten konnten
• Halbduplex mit Stop-and-Wait, weil IBM-Mainframes keine Vollduplex-Kommunikation unterstützten
• druckbare Kodierungen für Steuerzeichen und 8-bit-Zeichen, weil beides den Terminaltreiber des Mainframes nicht passieren konnte
• eine Prüfsumme für jedes Paket, die vom Empfänger bestätigt wird, damit ein beschädigtes Paket nur eine erneute Übertragung und nicht die gesamte Datei erfordert

Der dritte Punkt ist besonders interessant. Kermit sendet eine textkompatible Kodierung Ihrer Datei und nicht die Datei selbst. Aus einem Steuerbyte wird ein Präfixzeichen gefolgt von einem druckbaren Zeichen. Ein Byte mit gesetztem höchstem Bit kann für eine 7-bit-Verbindung auf dieselbe Weise kodiert werden. Alles dazwischen, das nur druckbaren Text versteht, sieht dadurch druckbaren Text. Der Nachteil ist die Größe: Eine Binärdatei wird bei der Übertragung größer. Gegenüber einem Mainframe-Frontend, das die Übertragung andernfalls vollständig verfälschen würde, war das der richtige Kompromiss.

Eine weitere ungewöhnliche Eigenschaft von Kermit ist sein Anwendungsbereich. XMODEM übertrug eine Datei zwischen zwei Rechnern, die sich bereits darauf geeinigt hatten, was eine Datei ist. Kermit wurde als kleinster gemeinsamer Nenner für Systeme entwickelt, die sich nicht einig waren, mit unterschiedlichen Zeichensätzen, unterschiedlichen Satzstrukturen und unterschiedlichen Vorstellungen davon, was eine Textzeile beendet. Diese Welt wird in der langen Entwicklung von Mainframes zu Cloud-Servern beschrieben. Kermit zeigt, wie Interoperabilität aussah, bevor die Netzwerkschicht diese Aufgabe übernahm.

Columbia beendete seine Unterstützung 2011 und veröffentlichte C-Kermit unter der überarbeiteten 3-clause-BSD-Lizenz. Frank da Cruz blieb 44 Jahre lang am Projekt beteiligt, vom Design im Jahr 1981 bis 2025. Die Version 2026 wird vom OpenKermit-Projekt gepflegt. John Goerzen modernisiert dabei eine C-Codebasis, die älter ist als die meisten Menschen, die sie heute lesen.

XMODEM und ZMODEM: wenn die Telefonrechnung das Design prägte

Ward Christensen schrieb 1977 MODEM.ASM, und das darin eingeführte Protokoll ist XMODEM. 1978 stellten er und Randy Suess CBBS online, das erste öffentliche Bulletin-Board-System. Christensen starb am 11. Oktober 2024.

XMODEM ist ungefähr so klein, wie ein Protokoll nur sein kann. Die Daten werden in Blöcken mit 128 Byte übertragen. Jeder Block enthält eine 1-Byte-Prüfsumme, also die Summe der 128 Datenbytes modulo 256. Der Empfänger bestätigt jeden Block oder fordert ihn erneut an. Der Grund für diesen Aufbau ist wirtschaftlicher Natur. Bei einer Einwahlverbindung bezahlen Sie nach Zeit. Ein Leitungsfehler sollte daher nur einen Block kosten und nicht die gesamte Übertragung.

Die Schwäche steckt im selben Satz. XMODEM wartet nach jeweils 128 Byte auf eine Bestätigung. Chuck Forsberg formulierte es in der ZMODEM-Spezifikation klar: „Die kurze Blocklänge beeinträchtigt den Durchsatz bei der Verwendung mit Timesharing-Systemen, paketvermittelten Netzwerken und Satellitenverbindungen.“ Nicht die Bandbreite, sondern die Latenz macht Stop-and-Wait langsam. Jede Round-Trip-Zeit ist Leerlauf auf einer Leitung, für deren Nutzung Sie bezahlen.

Als Nächstes kam YMODEM; Ward Christensen prägte den Namen 1985. Die wichtigste Neuerung war die Stapelübertragung. Der Sender übermittelt Dateiname und Dateigröße vor den Daten. Dadurch können mehrere Dateien in einer Sitzung übertragen werden, und der Empfänger weiß, wo jede Datei endet.

ZMODEM ist Chuck Forsbergs Antwort, die er bei Omen Technology schrieb. Die Spezifikation trägt den Revisionsstand 14. Oktober 1988 und erklärt: „ZMODEM wurde unter einem Telenet-Vertrag als Public-Domain-Software entwickelt.“ Telenet betrieb ein öffentliches paketvermitteltes Datennetz, und dieser Vertrag zeigt sich im Design. ZMODEM maskiert Netzwerk-Steuerzeichen, damit ein dazwischengeschaltetes Paketnetz sie nicht verarbeitet. Der Beginn jedes Frames wird durch eine eindeutige Zeichenfolge markiert, statt die Frame-Grenzen aus der Stille abzuleiten. Dadurch kann sich das Protokoll nach Störungen erholen, ohne auf einen Timeout warten zu müssen. Außerdem unterstützt es die explizite Wiederaufnahme, sodass eine unterbrochene Übertragung an der Abbruchstelle fortgesetzt wird.

Am wichtigsten ist, dass ZMODEM nicht mehr wartet. Die Spezifikation beschreibt es selbst so: „ZMODEM verwendet effektiv die gesamte Datei als Fenster.“ Der Sender überträgt kontinuierlich und hält nur an, wenn der Empfänger ein Problem meldet. Das ist dieselbe Erkenntnis, die TCP in seinem Fenster umsetzt, jedoch aus der entgegengesetzten Richtung entwickelt: von jemandem, der beobachtete, wie ein Modem untätig blieb.

Warum die zwei Verbindungen von FTP so schlecht gealtert sind

FTP ist älter als alle genannten Protokolle. RFC 114, „A File Transfer Protocol“, ist auf den 16. April 1971 datiert und wurde von A. Bhushan verfasst.

Wichtig ist, dass RFC 114 das Design mit zwei Verbindungen bereits prüfte und verwarf. Bhushan erwog „zwei Vollduplex-Verbindungen, eine für Steuerinformationen und die andere für Daten“ und kam anschließend zu dem Schluss: „Wir empfehlen, für den Austausch von Daten und Steuerinformationen eine einzige Vollduplex-Verbindung zu verwenden.“ Die Aufteilung kam später. RFC 354 vom 8. Juli 1972 legt fest, dass „Daten und Dateien ausschließlich über die Datenverbindung übertragen werden“ und die Befehle über eine separate Telnet-Verbindung laufen. RFC 959 vom Oktober 1985 von Postel und Reynolds ist die Version, die bis heute von allen implementiert wird.

RFC 959 legte auch die Ports fest. Der standardmäßige Datenport des Servers ist „der Port neben dem Port der Steuerverbindung, also L-1“. Wenn die Steuerverbindung Port 21 verwendet, ist dies Port 20.

Der folgende Teil hat sich nicht bewährt. Im ursprünglichen FTP-Modus baut der Server die Datenverbindung zum Client auf. Ein Client hinter NAT (network address translation) hat keine Adresse, die der Server erreichen kann. Ein Client hinter einer Firewall akzeptiert keine eingehenden Verbindungen. Deshalb kommt die Datenverbindung nicht zustande und die Übertragung hängt, sobald ein Verzeichnislisting oder eine Datei angefordert wird. Die Lösung war PASV. RFC 959 definiert PASV als Aufforderung an den Server, „an einem Datenport zu lauschen, der nicht sein standardmäßiger Datenport ist, und auf eine Verbindung zu warten, statt nach Erhalt eines Übertragungsbefehls selbst eine Verbindung zu initiieren“. Der Server antwortet mit der Adresse und dem Port, zu denen eine Verbindung hergestellt werden soll:

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

Diese Antwort bedeutet: Host 203.0.113.10, Port 195 mal 256 plus 80, also 50000. Lesen Sie die Antwort noch einmal. Dann wird das strukturelle Problem sichtbar. Der Endpunkt der zweiten Verbindung wird innerhalb der Nutzlast der ersten Verbindung angekündigt. Ein NAT-Gerät oder eine Firewall kann diese Verbindung nur weiterleiten, wenn es den Steuerkanal analysiert und den darin angegebenen Port öffnet. Linux liefert einen Connection-Tracking-Helper, der genau das erledigt. Der Helper funktioniert nur, solange die Steuerverbindung im Klartext übertragen wird. Wenn FTP mit TLS (transport layer security) abgesichert wird, kann das zwischengeschaltete Gerät, das FTP erst nutzbar gemacht hat, den Inhalt nicht mehr erkennen.

Das ist die Lehre aus FTP in einem Satz: FTP machte das Netzwerk zu einem Teilnehmer des Protokolls. Ein Protokoll, das das Netzwerk verstehen muss, kann ein Netzwerk nicht überleben, das ihm nicht mehr vertraut.

Das Ende ist dokumentiert. Firefox entfernte die FTP-Unterstützung im Juli 2021 mit Version 90. Chrome entfernte den FTP-Code im Oktober 2021 mit Chrome 95.

rcp und die r-Befehle: Vertrauen anhand des Hostnamens

4.2BSD, das Berkeley 1983 mit Finanzierung durch DARPA veröffentlichte, brachte rcp, rsh und rlogin. Sie wurden für einen Verbund von Unix-Rechnern in einem gemeinsamen Netzwerk entwickelt, und das Authentifizierungsmodell zeigt diese Herkunft. Ein Host gab an, welcher Benutzer den Aufruf ausführte. Wenn /etc/hosts.equiv oder das ~/.rhosts eines Benutzers angab, dass diesem Host vertraut wurde, wurde diese Angabe akzeptiert und es wurde kein Passwort abgefragt.

Der Mechanismus muss klar benannt werden, denn genau deshalb sind diese Befehle verschwunden. Das Vertrauen beruhte auf einer Adresse und einer Behauptung. Beides wurde unverschlüsselt über das Netzwerk übertragen. Jeder Teilnehmer auf dem Übertragungsweg konnte die Daten lesen und fälschen. Dieses Modell war in der in dem Weg von Unix zu Linux beschriebenen Umgebung sinnvoll, in der das Netzwerk auf ein Gebäude beschränkt war. Sobald das Netzwerk das Internet war, war es nicht mehr sinnvoll.

Was rcp richtig machte, war die Schnittstelle. Quelle, Ziel, fertig. Es musste keine Sitzung geöffnet, kein Übertragungsmodus ausgehandelt und keine zweite Verbindung eingerichtet werden. Es verhält sich wie cp mit einem Doppelpunkt im Pfad. Diese Schnittstelle überlebte ihr Protokoll um vier Jahrzehnte.

SSH deckt die gesamte Kategorie ab

1995 schrieb Tatu Ylonen, damals Forscher an der Helsinki University of Technology, SSH als Reaktion auf einen Angriff zum Mitschneiden von Passwörtern im Universitätsnetzwerk. Im Juli 1995 veröffentlichte er es als freie Software einschließlich Quelltext. Bis zum Jahresende lag die Schätzung bei etwa 20,000 Benutzern in 50 Ländern. Im Dezember 1995 gründete er SSH Communications Security, um die Entwicklung fortzuführen.

Die Lizenz wurde bei späteren Versionen restriktiver. Deshalb for kten die OpenBSD-Entwickler die letzte frei lizenzierte Version, ssh 1.2.12. Der erste Import erfolgte am 26. September 1999. OpenSSH 1.2.2 wurde am 1. Dezember 1999 mit OpenBSD 2.6 veröffentlicht. Dieser Fork ist ein kompaktes Beispiel dafür, warum Open-Source-Lizenzbedingungen in der Praxis wichtig sind, denn die SSH-Implementierung, die heute fast alle verwenden, geht auf die einzige Version zurück, deren Lizenz dies noch erlaubte.

Nachdem SSH existierte, war die Dateiübertragung kein separates Problem mehr. Ein authentifizierter, verschlüsselter Datenstrom mit mehreren Kanälen bietet bereits das, was die älteren Protokolle selbst implementieren mussten: Integrität, Reihenfolge und einen zweiten Datenpfad, der keine zweite TCP-Verbindung benötigt. Wenn diese Mechanismen für Sie neu sind, beginnen Sie mit einer Erklärung, was SSH tatsächlich ist, bevor Sie fortfahren.

Daraus gingen zwei Werkzeuge hervor. scp war das Netzwerkprotokoll von rcp, das innerhalb einer SSH-Sitzung ausgeführt wurde. Deshalb übernahm es die Befehlszeile von rcp unverändert. SFTP ist ein anderes Design: ein echtes Dateiübertragungsprotokoll mit Verzeichnisauflistungen, Dateiattributen und wahlfreiem Zugriff, das über einen SSH-Kanal übertragen wird. SFTP wurde nie zu einem RFC. Der IETF-Entwurf draft-ietf-secsh-filexfer erreichte am 18. Juli 2006 Version 13 und lief danach aus. OpenSSH implementiert Version 3 dieses Entwurfs. Das weltweit am weitesten verbreitete sichere Dateiübertragungsprotokoll ist eine nummerierte Revision eines aufgegebenen Entwurfs. Trotzdem funktioniert es.

Auch das veraltete scp-Protokoll wurde inzwischen außer Betrieb genommen. OpenSSH 8.8, veröffentlicht am 26. September 2021, warnte: „Eine zukünftige OpenSSH-Version wird scp(1) von der Verwendung des veralteten scp/rcp-Protokolls standardmäßig auf SFTP umstellen.“ OpenSSH 9.0, veröffentlicht am 8. April 2022, setzte dies um: „Diese Version stellt scp(1) von der Verwendung des veralteten scp/rcp-Protokolls standardmäßig auf das SFTP-Protokoll um.“

Der Grund erklärt ein Stück technischer Folklore. Das alte scp-Protokoll expandierte Platzhalter für entfernte Dateinamen, indem es sie an die entfernte Shell übergab. Deshalb lernten viele, jedes Metazeichen in einem entfernten Pfad doppelt zu maskieren. In den Hinweisen zu 8.8 steht, dass scp über SFTP „diese umständliche und fehleranfällige Maskierung nicht mehr benötigt“. Auf einem aktuellen Server ist scp daher ein SFTP-Client mit der Befehlszeile von rcp. Die Schnittstelle von 1983 ist erhalten geblieben. Das Netzwerkprotokoll von 1983 ist es nicht.

rsync, 1996: Unterschiede übertragen, nicht die Datei

Andrew Tridgell und Paul Mackerras kündigten rsync am 19. Juni 1996 an der Australian National University zusammen mit dem technischen Bericht TR-CS-96-05, „The rsync algorithm“, an.

Vor rsync stellte jedes Protokoll die Frage, wie eine Datei übertragen werden kann, ohne sie zu beschädigen. rsync stellte stattdessen die Frage, wie viel von dieser Datei die andere Seite bereits besitzt. Der Bericht beschreibt als Ziel eine „bidirektionale Kommunikationsverbindung mit geringer Bandbreite und hoher Latenz“ und soll „Teile der Quelldatei identifizieren, die mit Teilen der Zieldatei identisch sind“, damit nur die nicht übereinstimmenden Teile übertragen werden.

Der Mechanismus ist verständlich, weil er das Verhalten von rsync erklärt. Der Empfänger teilt seine vorhandene Kopie in Blöcke fester Größe auf und berechnet für jeden Block zwei Prüfsummen: eine schwache und schnell berechnete sowie eine starke und aufwendiger berechnete. Diese Liste sendet er an den Sender. Der Sender verschiebt ein Fenster Byte für Byte über seine eigene Datei und aktualisiert die schwache Prüfsumme inkrementell. Dadurch bleibt der Scan auf Byte-Ebene überhaupt effizient. Eine schwache Übereinstimmung wird anschließend anhand der starken Prüfsumme bestätigt. Bestätigte Übereinstimmungen werden zu Blockverweisen. Alles andere wird als unveränderte Bytefolge übertragen. Der Empfänger rekonstruiert die Datei aus Verweisen auf bereits vorhandene Blöcke und den gerade empfangenen unveränderten Bytefolgen.

Wird am Anfang einer großen Datei ein Byte eingefügt, muss ein naives Differenzwerkzeug die gesamte Datei übertragen, weil sich jeder Offset verschoben hat. Das gleitende Fenster findet dieselben Blöcke an ihren neuen Offsets. rsync überträgt daher ein Byte plus Verwaltungsinformationen. Deshalb ist rsync weiterhin das richtige Werkzeug für ein Verzeichnis, das Sie mehr als einmal kopieren.

Zwei Verhaltensweisen überraschen Anwender regelmäßig. Beide sind im Handbuch beschrieben. Erstens berechnet rsync keine Prüfsummen, um zu entscheiden, ob eine Datei geprüft werden soll. Stattdessen „findet rsync mit einem standardmäßig verwendeten Algorithmus zur schnellen Prüfung Dateien, die übertragen werden müssen. Dabei wird geprüft, ob sich die Dateigröße oder der Zeitpunkt der letzten Änderung geändert hat“. Eine Datei, deren Inhalt geändert wurde, während Größe und Zeitstempel unverändert geblieben sind, wird übersprungen. --checksum ändert dieses Verhalten und veranlasst beide Seiten, jede infrage kommende Datei vollständig zu lesen. Zweitens ist der Delta-Algorithmus standardmäßig deaktiviert, wenn beide Pfade lokal sind. Das Lesen und Berechnen von Prüfsummen für zwei Kopien auf demselben Rechner kostet mehr, als die Bytes zu kopieren. Die Einsparung entsteht nur, wenn die Verbindung der langsame Teil ist.

Was Sie auf einem VPS tatsächlich verwenden und warum

Die Kurzfassung: SFTP für einige Dateien, rsync über SSH für ein Verzeichnis, das Sie erneut kopieren werden.

Beide verwenden SSH. Daher übernehmen beide ohne zusätzliche Konfiguration die Prüfung von Hostschlüsseln und die Verschlüsselung. Darin stecken fünfzig Jahre Entwicklungsarbeit, die in einem Standard gebündelt sind. Die Entwickler von Kermit mussten davon ausgehen, dass die Leitung Daten beschädigt. Deshalb integrierten sie Prüfsummen und Wiederholungsübertragungen in das Protokoll. Das erledigt heute TCP. Christensen und Forsberg mussten davon ausgehen, dass jedes Byte Kosten verursacht. Deshalb integrierten sie die Wiederaufnahme unterbrochener Übertragungen und Streaming. Das erledigt heute der Delta-Algorithmus von rsync, und zwar besser. Die Entwickler von FTP gingen von einem Netzwerk kooperierender Hosts aus. Das ist die einzige dieser Annahmen, die sich als falsch erwies und die sich durch noch so viel Protokollarbeit nicht korrigieren ließ.

Welche Sicherheit bieten Prüfsummen noch?

Das Wort „Prüfsumme“ hat in dieser Entwicklungsgeschichte drei verschiedene Aufgaben erfüllt. Diese Aufgaben sind nicht austauschbar.

Die paketweisen Prüfsummen von Kermit und XMODEM erkannten Übertragungsfehler auf der Leitung. Heute übernehmen das die TCP-Prüfsumme und die Fehlerkorrektur in der Sicherungsschicht. Deshalb fordert kein modernes Übertragungsprogramm mehr, dass Sie sich damit befassen.

Die Block-Prüfsummen von rsync beantworten nicht die Frage „Sind diese Daten korrekt?“. Sie beantworten die Frage „Ist dieser Block bereits vorhanden?“. Eine starke Prüfsumme ist dort ein Suchschlüssel, keine Aussage darüber, woher die Datei stammt.

Die dritte Aufgabe bleibt Ihnen weiterhin überlassen. Eine veröffentlichte Prüfsumme für eine Release-Datei beantwortet eine Frage, die TLS nicht beantworten kann. TLS bestätigt, dass Sie mit dem richtigen Server kommuniziert haben. Es bestätigt nicht, dass die richtige Datei auf diesem Server lag. Für eine Datei, die Sie von einem Mirror abgerufen haben, bietet TLS ebenfalls keinen Schutz. Deshalb sind Prüfsummen und Signaturen für Releases die dreißig Sekunden weiterhin wert. Die Gewohnheit lässt sich leicht entwickeln: Prüfen Sie die Prüfsumme jedes Downloads, den Sie installieren.

Alles andere in dieser Entwicklungsgeschichte wurde durch die darunterliegende Schicht gelöst. Diese Aufgabe nicht, weil sie nie ein Netzwerkproblem war.

FAQ

Ist FTP auf einem VPS noch sicher?

Nein. Unverschlüsseltes FTP überträgt Zugangsdaten und Dateiinhalte im Klartext, sodass jeder Teilnehmer auf dem Übertragungsweg beides mitlesen kann. Außerdem benötigt FTP eine Firewall, die seinen Steuerkanal analysiert. Das ist nicht mehr möglich, sobald Sie den Steuerkanal mit TLS verschlüsseln. Auch Browser haben FTP bereits entfernt: Firefox entfernte die FTP-Unterstützung in Version 90 im Juli 2021, Chrome entfernte den Code in Version 95 im Oktober 2021. Verwenden Sie SFTP über SSH. Dafür benötigen Sie nur einen Port und keine protokollbewusste Middlebox.

Warum benötigt FTP überhaupt einen passiven Modus?

Weil der Server im ursprünglichen FTP-Modus die Datenverbindung zum Client zurück öffnet. RFC 959 legt den standardmäßigen Datenport des Servers auf „the port adjacent to the control connection port (i.e., L-1)“ fest, also auf Port 20, wenn die Steuerverbindung Port 21 verwendet. Ein Client hinter NAT (network address translation) hat keine Adresse, die der Server erreichen kann. Deshalb kommt diese Verbindung nie an und die Übertragung bleibt hängen. PASV kehrt die Richtung um: Der Server lauscht stattdessen und antwortet mit einer Adresse und einem Port in einer 227 Entering Passive Mode-Antwort, zu dem der Client eine Verbindung herstellt.

Verwendet scp weiterhin ein eigenes Protokoll?

Nicht seit OpenSSH 9.0, das am 8. April 2022 veröffentlicht wurde und „switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default“. OpenSSH 8.8 kündigte diese Änderung im September 2021 an. Der sichtbare Unterschied betrifft die Maskenexpansion. Das alte Protokoll expandierte Wildcards auf dem entfernten System, indem es sie an die entfernte Shell übergab. Das SFTP-basierte Verfahren tut dies nicht. Daher verhalten sich Pfade, die auf dieser Shell-Expansion beruhten, jetzt anders.

Wann ist rsync für einen VPS besser geeignet als scp?

Wenn Sie denselben Verzeichnisbaum mehr als einmal kopieren. rsync überträgt nur die Teile jeder Datei, die am Ziel noch nicht vorhanden sind. Deshalb ist die zweite Kopie deutlich günstiger als die erste. Bei einer einzelnen Datei, die das Ziel noch nie gesehen hat, übertragen scp und rsync ungefähr gleich viele Bytes, und scp ist einfacher. Beachten Sie, dass rsync standardmäßig anhand von Größe und Änderungszeit entscheidet, welche Dateien geprüft werden. Wenn sich der Inhalt einer Datei geändert hat, während Größe und Zeitstempel unverändert blieben, benötigt rsync --checksum, bevor es die Änderung erkennt.

Warum codierte Kermit Dateien als druckbaren Text, statt rohe Bytes zu übertragen?

Weil die Verbindung, für die Kermit entwickelt wurde, eine Terminalleitung zu einem Mainframe und keine Byte-Leitung war. Solche Verbindungen konnten 7-Bit-Daten übertragen, und der Terminaltreiber des Mainframes verarbeitete Steuerzeichen, statt sie unverändert weiterzuleiten. Kermit codierte Steuerbytes und Bytes mit gesetztem höchstem Bit als druckbare Zeichen, damit kein Gerät auf dem Übertragungsweg auf sie reagierte. Durch die Codierung werden Binärdateien bei der Übertragung größer. Das war jedoch der richtige Kompromiss gegenüber einer Übertragung, bei der die Datei andernfalls beschädigt angekommen wäre.