Ewolucja protokołów przesyłania plików: od Kermit do rsync

Dlaczego protokoły przesyłania plików ulegały ciągłym zmianom

Każdy z protokołów przesyłania plików został zaprojektowany w odpowiedzi na awarie typowe dla swojej dekady. Protokół Kermit zakładał, że linia transmisyjna będzie powodować uszkodzenia bajtów. XMODEM i ZMODEM zakładały, że połączenie jest wolne i płatne za każdą minutę. FTP (file transfer protocol) zakładał, że sieć pośrednicząca jest godna zaufania. SSH zakładało, że sieć jest wroga. To ostatnie założenie okazało się zwycięskie, dlatego dzisiejszy VPS oferuje SFTP oraz rsync przez SSH i niewiele więcej.

Istnieje powód, by przyjrzeć się temu obecnie. Wersja C-Kermit 11.0.506 została wydana 3 sierpnia 2026. Jest to pierwsze stabilne wydanie od czasu C-Kermit 9.0.302 z 20 sierpnia 2011, a sam protokół został zaprojektowany w maju 1981. Czterdzieści pięć lat to wystarczająco długi okres, aby zaobserwować, jak cała kategoria rozwiązań powstaje, zostaje ustandaryzowana, ulega awariom z powodu ograniczeń sieci, a ostatecznie zostaje wchłonięta przez SSH.

Kermit, 1981: zaprojektowany dla łącza, które pożera bajty

Protokół Kermit powstał w maju 1981 roku w Columbia University Computer Center, a jego twórcami byli Frank da Cruz oraz Bill Catchings. Nazwa pochodzi od żaby Kermita. Według relacji da Cruza, na ścianie wisiał kalendarz z Muppetami, gdy zespół szukał nazwy dla projektu; nikt nie przypuszczał, że rozwiązanie to zyska tak dużą popularność.

Problem, który rozwiązywał Kermit, nie dotyczył szybkości. Ścieżka między terminalem a komputerem typu mainframe nie była kanałem dla dowolnych bajtów. Było to urządzenie znakowe z własnymi ograniczeniami. Mogło obsługiwać tylko 7 bitów. Mogło pracować w trybie half-duplex. Mogło połykać znaki sterujące lub interpretować je jako komendy. Przesyłanie plików binarnych w stanie surowym kończyło się niepowodzeniem.

Dlatego projekt uwzględnił te ograniczenia w sposób dosłowny. Historia projektu Kermit wymienia je następująco:

• krótkie pakiety, ponieważ większość mainframe'ów nie radziła sobie z długimi seriami danych przychodzących z terminala;
• mechanizm stop-and-wait w trybie half-duplex, ponieważ mainframe'y IBM nie wspierały komunikacji full-duplex;
• kodowanie znaków sterujących i 8-bitowych na postać drukowalną, ponieważ sterownik terminala mainframe'u nie przepuszczał ich w formie surowej;
• suma kontrolna dla każdego pakietu, potwierdzana przez odbiorcę, dzięki czemu uszkodzony pakiet powoduje retransmisję tylko tego fragmentu, a nie całego pliku.

Trzeci punkt jest szczególnie interesujący. Kermit przesyła bezpieczne tekstowo kodowanie pliku, a nie sam plik. Bajt sterujący staje się znakiem prefiksu, po którym następuje znak drukowalny, a bajt z ustawionym najstarszym bitem może być zakodowany w ten sam sposób dla łącza 7-bitowego. Każde urządzenie pośredniczące, które rozumie tylko tekst drukowalny, widzi właśnie taki tekst. Kosztem jest rozmiar: plik binarny zwiększa swoją objętość podczas transmisji. W starciu z interfejsem mainframe'u, który w przeciwnym razie całkowicie zniekształby transfer, był to właściwy kompromis.

Drugą nietypową cechą Kermita jest jego zakres. XMODEM przenosił plik między dwiema maszynami, które już wcześniej uzgodniły, czym jest plik. Kermit został napisany jako najmniejszy wspólny mianownik dla systemów, które nie posiadały wspólnego języka, miały różne zestawy znaków, odmienne struktury rekordów i różne definicje końca linii tekstu. To świat opisany w długiej drodze od mainframe'ów do serwerów chmurowych, a Kermit stanowi przykład tego, jak wyglądała interoperacyjność, zanim warstwa sieciowa zaczęła zajmować się tym automatycznie.

Columbia University zakończył sponsorowanie projektu w 2011 roku i udostępnił C-Kermit na zmodyfikowanej licencji BSD 3-clause. Frank da Cruz pozostał związany z projektem przez 44 lata, od fazy projektowania w 1981 roku aż do 2025 roku. Wydanie z 2026 roku jest utrzymywane przez projekt OpenKermit, w ramach którego John Goerzen zajmuje się modernizacją kodu w języku C, starszego niż większość osób czytających ten tekst.

XMODEM i ZMODEM: kiedy rachunek telefoniczny kształtował projekt

Ward Christensen napisał MODEM.ASM w 1977 roku, a protokół, który wprowadził, to XMODEM. W 1978 roku wraz z Randym Suessem uruchomił CBBS, pierwszy publiczny system tablic ogłoszeniowych (BBS). Christensen zmarł 11 października 2024 roku.

XMODEM jest tak prostym protokołem, jak to tylko możliwe. Dane przesyłane są w blokach o rozmiarze 128 bajtów. Każdy blok zawiera jednobajtową sumę kontrolną, będącą sumą 128 bajtów danych modulo 256. Odbiorca potwierdza każdy blok lub prosi o jego ponowne przesłanie. Przyczyną takiego kształtu protokołu były względy ekonomiczne. W łączach komutowanych płaciło się za czas połączenia, więc błąd transmisji powinien kosztować utratę tylko jednego bloku, a nie całego transferu.

Słabość protokołu wynika z tego samego założenia. XMODEM czeka na potwierdzenie po każdych 128 bajtach. Chuck Forsberg ujął to jasno w specyfikacji ZMODEM: „Krótka długość bloku powoduje spadek przepustowości w systemach z podziałem czasu, sieciach z komutacją pakietów oraz łączach satelitarnych”. To opóźnienie (latency), a nie przepustowość, zabija mechanizm stop-and-wait. Każdy cykl komunikacji w obie strony to czas bezczynności na łączu, za który użytkownik płaci.

Następnie pojawił się YMODEM, którego nazwę ukuł Ward Christensen w 1985 roku. Jego wkładem było wprowadzenie transferu wsadowego. Nadawca podaje nazwę pliku i jego rozmiar przed wysłaniem danych, dzięki czemu w jednej sesji można przesłać kilka plików, a odbiorca wie, gdzie kończy się każdy z nich.

ZMODEM to odpowiedź Chucka Forsberga, stworzona w firmie Omen Technology. Specyfikacja pochodzi z 14 października 1988 roku i stwierdza, że „ZMODEM został opracowany dla domeny publicznej w ramach kontraktu z Telenet”. Telenet obsługiwał publiczną sieć danych z komutacją pakietów, co widać w projekcie protokołu. ZMODEM stosuje znaki ucieczki (escape) dla znaków sterujących sieci, dzięki czemu sieć pakietowa znajdująca się pomiędzy węzłami nie interpretuje ich jako własnych poleceń. Początek każdej ramki oznaczany jest unikalną sekwencją znaków, zamiast wnioskowania o granicach ramek na podstawie ciszy, co pozwala na odzyskanie transmisji po zakłóceniach bez oczekiwania na upłynięcie limitu czasu (timeout). Protokół posiada również funkcję jawnego wznawiania, dzięki czemu przerwany transfer można kontynuować od miejsca, w którym został zatrzymany.

Co najważniejsze, ZMODEM eliminuje oczekiwanie. W specyfikacji opisano to następująco: „ZMODEM w efekcie wykorzystuje cały plik jako okno”. Nadawca przesyła strumień danych i zatrzymuje się tylko wtedy, gdy odbiorca zgłosi problem. Jest to ta sama koncepcja, którą TCP koduje w swoim oknie przesuwnym, osiągnięta z przeciwnego kierunku przez osobę obserwującą bezczynność modemu.

Dlaczego dwa połączenia FTP tak źle się zestarzały

Protokół FTP jest starszy niż wszystko inne. Dokument RFC 114, "A File Transfer Protocol", datowany jest na 16 kwietnia 1971 roku i został napisany przez A. Bhushana.

Warto wiedzieć, że RFC 114 rozważał projekt oparty na dwóch połączeniach i odrzucił go. Bhushan rozważył "użycie dwóch pełnodupleksowych łączy, jednego dla informacji sterujących, drugiego dla danych" i doszedł do wniosku: "Zalecamy użycie pojedynczego pełnodupleksowego połączenia do wymiany zarówno danych, jak i informacji sterujących". Podział wprowadzono później. Dokument RFC 354 z 8 lipca 1972 roku stanowi, że "dane i pliki są przesyłane wyłącznie przez połączenie danych", podczas gdy polecenia przesyłane są oddzielnym połączeniem Telnet. RFC 959 z października 1985 roku, autorstwa Postela i Reynoldsa, to wersja, którą wszyscy nadal implementują.

RFC 959 ustalił również porty. Domyślnym portem danych serwera jest "port sąsiadujący z portem połączenia sterującego (tj. L-1)", co oznacza port 20, gdy połączenie sterujące odbywa się na porcie 21.

Oto element, który nie przetrwał próby czasu. W oryginalnym trybie FTP to serwer otwiera połączenie danych z powrotem do klienta. Klient znajdujący się za NAT (network address translation) nie posiada adresu, do którego serwer mógłby dotrzeć, a klient za firewallem nie akceptuje połączeń przychodzących. W rezultacie połączenie danych nigdy nie zostaje nawiązane, a transfer zawiesza się natychmiast po żądaniu listy plików lub samego pliku. Rozwiązaniem stał się tryb PASV, który RFC 959 definiuje jako żądanie, aby serwer "nasłuchiwał na porcie danych (innym niż domyślny port danych) i oczekiwał na połączenie, zamiast inicjować je po otrzymaniu polecenia transferu". Serwer odpowiada adresem i portem, z którym należy się połączyć:

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

Ta odpowiedź oznacza host 203.0.113.10, port 195 razy 256 plus 80, czyli 50000. Po ponownej analizie widać problem strukturalny. Punkt końcowy drugiego połączenia jest ogłaszany wewnątrz ładunku (payload) pierwszego połączenia. Urządzenie NAT lub firewall nie może przepuścić tego połączenia, chyba że analizuje kanał sterujący i otwiera port, który w nim widzi. System Linux dostarcza mechanizm śledzenia połączeń (connection tracking helper), który wykonuje dokładnie to zadanie. Mechanizm ten działa tylko wtedy, gdy połączenie sterujące jest przesyłane otwartym tekstem, więc zawinięcie FTP w TLS (transport layer security) oślepia urządzenie pośredniczące, które czyniło FTP użytecznym.

To lekcja płynąca z FTP w jednym zdaniu. Protokół ten uczynił sieć uczestnikiem komunikacji. Protokół, który wymaga, aby sieć go rozumiała, nie może przetrwać w sieci, która przestaje mu ufać.

Koniec jest udokumentowany. Przeglądarka Firefox usunęła obsługę FTP w wersji 90 w lipcu 2021 roku. Chrome usunął kod FTP w wersji 95 w październiku 2021 roku.

rcp i polecenia z rodziny r: zaufanie na podstawie nazwy hosta

Wydany w 1983 roku przez Berkeley przy wsparciu finansowym DARPA system 4.2BSD wprowadził rcp, rsh oraz rlogin. Narzędzia te zaprojektowano z myślą o kampusie maszyn Unix w obrębie jednej sieci, co odzwierciedla ich model uwierzytelniania. Host deklarował, który użytkownik nawiązuje połączenie. Jeśli plik /etc/hosts.equiv lub ~/.rhosts użytkownika wskazywał, że dany host jest zaufany, deklaracja była przyjmowana bez pytania o hasło.

Mechanizm ten należy określić jasno, gdyż stanowi on przyczynę wycofania tych poleceń. Zaufanie opierało się na adresie oraz deklaracji. Oba te elementy przesyłane są w sieci otwartym tekstem, co oznacza, że każdy podmiot na ścieżce transmisji może je odczytać lub sfałszować. Model ten był uzasadniony w środowisku opisanym w droga od Unix do Linux, gdzie sieć ograniczała się do jednego budynku. Przestał on mieć sens w momencie, gdy sieć stała się Internetem.

Tym, co rcp zrealizowało poprawnie, był interfejs. Źródło, cel, gotowe. Brak konieczności otwierania sesji, negocjowania trybu transferu czy zestawiania drugiego połączenia. Narzędzie zachowuje się jak cp z dwukropkiem w ścieżce. Ten interfejs przetrwał protokół, na którym bazował, o cztery dekady.

SSH przejmuje całą kategorię

W 1995 roku Tatu Ylonen, ówczesny pracownik naukowy Helsinki University of Technology, napisał SSH w odpowiedzi na atak polegający na przechwytywaniu haseł w sieci uniwersyteckiej. W lipcu 1995 roku udostępnił oprogramowanie jako wolne, wraz z kodem źródłowym. Pod koniec tego samego roku szacowano liczbę użytkowników na około 20 000 w 50 krajach, a w grudniu 1995 roku założył firmę SSH Communications Security w celu dalszego rozwoju projektu.

Licencja zaostrzyła się wraz z kolejnymi wersjami, dlatego programiści OpenBSD stworzyli fork ostatniego wydania na wolnej licencji, czyli ssh 1.2.12. Początkowy import miał miejsce 26 września 1999 roku, a OpenSSH 1.2.2 ukazało się wraz z OpenBSD 2.6 w dniu 1 grudnia 1999 roku. Ten fork stanowi zwięzłe studium przypadku na temat tego, dlaczego warunki licencji open source mają znaczenie w praktyce, ponieważ implementacja SSH, z której korzysta dziś niemal każdy, wywodzi się z tej jednej wersji, której licencja na to pozwalała.

Gdy SSH zaistniało, przesyłanie plików przestało być odrębnym problemem. Uwierzytelniony, szyfrowany strumień obsługujący wiele kanałów zapewnia już to, co starsze protokoły musiały budować samodzielnie: integralność, zachowanie kolejności oraz drugi kanał danych, który nie wymaga osobnego połączenia TCP. Jeśli te mechanizmy są nowe, zacznij od zrozumienia, czym faktycznie jest SSH, zanim przejdziesz dalej.

Z tego rozwiązania wyewoluowały dwa narzędzia. scp było protokołem sieciowym rcp uruchamianym wewnątrz sesji SSH, dlatego odziedziczyło dokładnie ten sam interfejs wiersza poleceń. SFTP to odrębny projekt: rzeczywisty protokół plikowy z obsługą listowania katalogów, atrybutów plików i dostępu swobodnego, przesyłany kanałem SSH. SFTP nigdy nie stało się standardem RFC. Projekt IETF, draft-ietf-secsh-filexfer, osiągnął wersję 13 w dniu 18 lipca 2006 roku, a następnie wygasł. OpenSSH implementuje wersję 3 tego projektu. Najpowszechniej używany bezpieczny protokół przesyłania plików na świecie jest numerowaną wersją porzuconego projektu i działa poprawnie.

Starszy protokół scp został obecnie wycofany. OpenSSH 8.8, wydane 26 września 2021 roku, ostrzegało, że „w niedalekiej przyszłości OpenSSH zmieni domyślne działanie scp(1) z używania protokołu scp/rcp na SFTP”. OpenSSH 9.0, wydane 8 kwietnia 2022 roku, wprowadziło tę zmianę: „To wydanie zmienia domyślne działanie scp(1) z używania protokołu scp/rcp na protokół SFTP”.

Powód tej zmiany wyjaśnia pewien element wiedzy potocznej. Stary protokół scp rozwijał symbole wieloznaczne w zdalnych nazwach plików, przekazując je do zdalnej powłoki, dlatego użytkownicy nauczyli się brać w podwójny cudzysłów każdy metaznak w zdalnej ścieżce. Informacje o wydaniu 8.8 podają, że scp działające przez SFTP „nie wymaga już tego kłopotliwego i kruchego cytowania”. Zatem na współczesnym serwerze scp jest klientem SFTP korzystającym z interfejsu wiersza poleceń rcp. Interfejs z 1983 roku przetrwał. Protokół sieciowy z 1983 roku – nie.

rsync, 1996: przesyłanie różnic, a nie całego pliku

Andrew Tridgell oraz Paul Mackerras ogłosili powstanie rsync 19 czerwca 1996 roku na Australian National University, publikując jednocześnie raport techniczny TR-CS-96-05 pod tytułem "The rsync algorithm".

Każdy protokół istniejący przed nim stawiał pytanie, jak przenieść plik bez jego uszkodzenia. rsync zapytał, jaką część tego pliku posiada już druga strona. Raport definiuje cel jako "dwukierunkowe łącze komunikacyjne o niskiej przepustowości i wysokim opóźnieniu", a zadanie jako identyfikację "części pliku źródłowego, które są identyczne z częściami pliku docelowego", tak aby przesyłane były wyłącznie niedopasowane fragmenty.

Mechanizm ten jest wart zrozumienia, ponieważ wyjaśnia sposób działania rsync. Odbiorca dzieli posiadaną kopię na bloki o stałym rozmiarze i oblicza dla każdego z nich dwie sumy kontrolne: jedną słabą i tanią obliczeniowo oraz drugą silną i kosztowną. Listę tę wysyła do nadawcy. Nadawca przesuwa okno nad swoim plikiem bajt po bajcie i aktualizuje słabą sumę kontrolną w sposób przyrostowy, co sprawia, że skanowanie bajt po bajcie jest w ogóle wykonalne. Słabe dopasowanie jest następnie weryfikowane za pomocą silnej sumy kontrolnej. Potwierdzone dopasowania stają się odniesieniami do bloków. Wszystko inne jest przesyłane jako dosłowne bajty. Odbiorca odtwarza plik z odniesień do bloków, które już posiada, oraz z otrzymanych dosłownych danych.

Wstawienie jednego bajtu na początku dużego pliku zmusza naiwne narzędzie do przesyłania całego pliku, ponieważ każdy offset uległ zmianie. Przesuwne okno znajduje te same bloki pod nowymi offsetami, więc rsync przesyła tylko jeden bajt oraz dane pomocnicze. Ta właściwość sprawia, że rsync pozostaje właściwym narzędziem dla katalogów, które kopiuje się więcej niż raz.

Dwa zachowania regularnie zaskakują użytkowników i oba są opisane w dokumentacji. Po pierwsze, rsync nie oblicza sum kontrolnych plików, aby zdecydować, czy należy się nimi zająć. "Wyszukuje pliki wymagające przesłania za pomocą algorytmu 'szybkiego sprawdzania' (domyślnie), który sprawdza, czy zmienił się rozmiar pliku lub czas jego ostatniej modyfikacji". Plik, którego zawartość uległa zmianie przy zachowaniu identycznego rozmiaru i znacznika czasu, jest pomijany. Flaga --checksum zmienia to zachowanie i wymusza na obu stronach pełne odczytanie każdego pliku kandydującego. Po drugie, algorytm delta jest domyślnie wyłączony, gdy obie ścieżki są lokalne, ponieważ odczyt i obliczanie sum kontrolnych dwóch kopii na jednej maszynie kosztuje więcej niż skopiowanie bajtów. Oszczędność występuje tylko wtedy, gdy to łącze jest wąskim gardłem.

Z czego faktycznie korzysta się na VPS i dlaczego

W skrócie: SFTP do pojedynczych plików, rsync przez SSH do katalogów, które będą kopiowane wielokrotnie.

Oba narzędzia działają w oparciu o SSH, więc dziedziczą weryfikację klucza hosta oraz szyfrowanie bez dodatkowej konfiguracji. To pięćdziesiąt lat pracy skondensowane w ustawieniach domyślnych. Projektanci protokołu Kermit musieli zakładać, że łącze będzie uszkadzać dane, dlatego wbudowali w niego sumy kontrolne i retransmisję. Obecnie realizuje to TCP. Christensen i Forsberg musieli zakładać, że każdy bajt kosztuje, więc wbudowali wznawianie transferu i strumieniowanie. Algorytm delta w rsync robi to teraz lepiej. Autorzy FTP zakładali istnienie sieci współpracujących hostów i jest to jedyne z tych założeń, które okazało się błędne w sposób, którego nie naprawi żadna ilość pracy nad protokołem.

Do czego nadal służą sumy kontrolne

Termin „suma kontrolna” pełnił w historii trzy różne funkcje, które nie są zamienne.

Sumy kontrolne dla poszczególnych pakietów w protokołach Kermit i XMODEM wykrywały uszkodzenia danych podczas transmisji. Obecnie zadanie to realizuje suma kontrolna TCP oraz mechanizmy korekcji błędów w warstwie łącza danych, dlatego żadne nowoczesne narzędzie do przesyłania plików nie wymaga od użytkownika zajmowania się tym zagadnieniem.

Sumy kontrolne bloków w rsync nie odpowiadają na pytanie, czy dane są poprawne. Odpowiadają na pytanie, czy dany blok danych już istnieje. Silna suma kontrolna w tym kontekście jest kluczem wyszukiwania, a nie potwierdzeniem pochodzenia pliku.

Trzecia funkcja jest tą, która nadal pozostaje w gestii użytkownika. Opublikowana suma kontrolna pliku z wydaniem odpowiada na pytanie, na które TLS nie jest w stanie odpowiedzieć. TLS potwierdza jedynie nawiązanie połączenia z właściwym serwerem. Nie gwarantuje, że na tym serwerze znajdował się właściwy plik, i nie zapewnia żadnej ochrony w przypadku pobrania pliku z serwera lustrzanego. Dlatego sumy kontrolne i podpisy plików z wydaniami nadal są warte poświęcenia trzydziestu sekund, a nawyk ten łatwo wyrobić: sprawdzaj sumę kontrolną każdego pobieranego pliku przed instalacją.

Wszystkie pozostałe problemy opisane w tej historii zostały rozwiązane przez niższe warstwy systemu. Ten jeden pozostał, ponieważ nigdy nie był problemem sieciowym.

FAQ

Czy FTP jest nadal bezpieczny w użyciu na VPS?

Nie. Standardowy protokół FTP przesyła dane uwierzytelniające oraz zawartość plików otwartym tekstem, co pozwala każdemu podmiotowi na ścieżce transmisji na ich odczytanie. FTP wymaga również firewalla, który analizuje kanał sterujący, co staje się niemożliwe w momencie szyfrowania tego kanału za pomocą TLS. Przeglądarki internetowe wycofały już obsługę tego protokołu: Firefox usunął wsparcie dla FTP w wersji 90 w lipcu 2021 roku, a Chrome usunął kod obsługi w wersji 95 w październiku 2021 roku. Należy używać SFTP przez SSH, co wymaga otwarcia tylko jednego portu i nie wymaga pośredników świadomych protokołu.

Dlaczego FTP w ogóle potrzebuje trybu pasywnego?

Ponieważ w oryginalnym trybie FTP serwer otwiera połączenie danych zwrotnie do klienta. RFC 959 definiuje domyślny port danych serwera jako „port sąsiadujący z portem połączenia sterującego (tj. L-1)”, czyli port 20, gdy sterowanie odbywa się na porcie 21. Klient znajdujący się za NAT (network address translation) nie posiada adresu, z którym serwer mógłby się połączyć, więc połączenie nigdy nie dociera do celu, a transfer zostaje zawieszony. Tryb PASV odwraca ten kierunek: serwer nasłuchuje połączeń i odpowiada adresem oraz portem wewnątrz odpowiedzi 227 Entering Passive Mode, z którymi klient może się połączyć.

Czy scp nadal używa własnego protokołu?

Nie od czasu wydania OpenSSH 9.0 w dniu 8 kwietnia 2022 roku, które „przełącza scp(1) z używania przestarzałego protokołu scp/rcp na domyślne używanie protokołu SFTP”. OpenSSH 8.8 zapowiedziało tę zmianę we wrześniu 2021 roku. Widoczną różnicą jest sposób cytowania. Stary protokół rozwijał znaki wieloznaczne (wildcards) poprzez przekazywanie ich do zdalnej powłoki, podczas gdy implementacja oparta na SFTP tego nie robi. W rezultacie ścieżki polegające na takim rozwijaniu przez powłokę zachowują się obecnie inaczej.

Kiedy rsync jest lepszy od scp w przypadku VPS?

Gdy planowane jest wielokrotne kopiowanie tego samego drzewa katalogów. rsync przesyła tylko te części plików, których nie ma jeszcze w miejscu docelowym, dzięki czemu druga kopia jest znacznie szybsza niż pierwsza. W przypadku pojedynczego pliku, którego miejsce docelowe jeszcze nie posiada, scp i rsync przesyłają mniej więcej taką samą liczbę bajtów, a scp jest prostszy w użyciu. Należy pamiętać, że rsync domyślnie decyduje o konieczności synchronizacji na podstawie rozmiaru i czasu modyfikacji, więc plik, którego zawartość uległa zmianie bez zmiany rozmiaru i znacznika czasu, wymaga użycia flagi --checksum, aby rsync wykrył różnicę.

Dlaczego Kermit kodował pliki jako tekst drukowalny zamiast przesyłać surowe bajty?

Ponieważ połączenie, do którego był przeznaczony, było linią terminalową do komputera typu mainframe, a nie strumieniem bajtów. Takie łącza mogły być 7-bitowe, a sterownik terminala mainframe'a reagował na znaki sterujące zamiast je przepuszczać. Kermit kodował bajty sterujące oraz bajty z ustawionym ósmym bitem na znaki drukowalne, aby urządzenia pośredniczące nie reagowały na nie. Kodowanie to zwiększa rozmiar plików binarnych w transmisji, co było właściwym kompromisem w obliczu transferu, który w przeciwnym razie dotarłby do celu uszkodzony.