Sejarah protokol pemindahan fail: Kermit hingga rsync

Mengapa protokol pemindahan fail sentiasa berubah

Setiap protokol pemindahan fail direka berdasarkan mod kegagalan pada dekad ia dicipta. Kermit mengandaikan talian akan merosakkan bait data anda. XMODEM dan ZMODEM mengandaikan sambungan adalah perlahan dan anda membayar untuk setiap minit penggunaan. FTP (file transfer protocol) mengandaikan rangkaian di antaranya bersifat kooperatif. SSH mengandaikan rangkaian bersifat bermusuhan. Andaian terakhir itulah yang menang, sebab itulah VPS hari ini hanya memberikan anda SFTP dan rsync melalui SSH dan hampir tiada yang lain.

Terdapat sebab untuk meneliti perkara ini sekarang. C-Kermit 11.0.506 telah dikeluarkan pada 3 Ogos 2026. Ia merupakan keluaran bukan beta pertama sejak C-Kermit 9.0.302 pada 20 Ogos 2011, dan protokol yang dilaksanakannya direka pada Mei 1981. Empat puluh lima tahun adalah tempoh yang cukup lama untuk melihat keseluruhan kategori dicipta, diseragamkan, dirosakkan oleh rangkaian yang melaksanakannya, dan kemudian diserap ke dalam SSH.

Kermit, 1981: direka untuk talian yang memakan bait anda

Kermit dicipta pada Mei 1981 di Pusat Komputer Universiti Columbia oleh Frank da Cruz dan Bill Catchings. Namanya diambil daripada Kermit the Frog. Menurut da Cruz, terdapat kalendar Muppets di dinding semasa kumpulan itu cuba memikirkan nama, dan tiada sesiapa menjangkakan perisian itu akan tersebar luas.

Masalah yang diselesaikan oleh Kermit bukanlah kelajuan. Laluan antara terminal dan kerangka utama (mainframe) bukanlah saluran untuk bait sebarangan. Ia merupakan peranti aksara yang mempunyai kekangan tersendiri. Ia mungkin 7-bit. Ia mungkin separuh dupleks (half-duplex). Ia boleh menelan aksara kawalan, atau bertindak balas terhadap salah satu daripadanya sebagai arahan. Menghantar fail binari melaluinya tanpa pengubahsuaian tidak akan berjaya.

Oleh itu, reka bentuknya mengambil kira kekangan tersebut secara literal. Sejarah Projek Kermit sendiri menyenaraikannya:

• paket pendek, kerana kebanyakan kerangka utama tidak dapat menerima aliran data masuk yang panjang daripada terminal
• henti-dan-tunggu separuh dupleks, kerana kerangka utama IBM tidak menyokong komunikasi dupleks penuh
• pengekodan boleh cetak untuk aksara kawalan dan aksara 8-bit, kerana kedua-duanya tidak boleh melepasi pemacu terminal kerangka utama
• checksum pada setiap paket, yang dijawab oleh penerima, supaya paket yang rosak hanya menyebabkan penghantaran semula satu paket dan bukan keseluruhan fail

Perkara ketiga adalah yang paling menarik. Kermit menghantar pengekodan teks selamat bagi fail anda dan bukannya fail itu sendiri. Bait kawalan menjadi aksara awalan diikuti oleh aksara boleh cetak, dan bait dengan bit tinggi ditetapkan boleh dikodkan dengan cara yang sama untuk pautan 7-bit. Mana-mana sistem di pertengahan yang hanya memahami teks boleh cetak akan melihat teks boleh cetak. Kosnya ialah saiz: fail binari akan membesar semasa dalam talian. Berbanding dengan bahagian hadapan kerangka utama yang akan merosakkan pemindahan sepenuhnya, itu adalah pertukaran yang wajar.

Satu lagi sifat luar biasa Kermit ialah skopnya. XMODEM memindahkan fail antara dua mesin yang sudah bersetuju tentang maksud fail tersebut. Kermit ditulis sebagai penyebut sepunya terkecil antara sistem yang tidak bersetuju, dengan set aksara yang berbeza, struktur rekod yang berbeza, dan idea yang berbeza tentang apa yang menamatkan baris teks. Itulah dunia yang diterangkan dalam pemindahan panjang daripada kerangka utama ke pelayan awan, dan Kermit ialah rupa bentuk kesalingoperasian sebelum lapisan rangkaian menguruskannya untuk anda.

Columbia menamatkan penajaannya pada 2011 dan mengeluarkan C-Kermit di bawah lesen BSD 3-klausa yang disemak semula. Frank da Cruz kekal bersama projek itu selama 44 tahun, dari reka bentuk 1981 sehingga 2025. Keluaran 2026 diselenggarakan oleh projek OpenKermit, dengan John Goerzen melakukan kerja memodenkan kod asas C yang lebih tua daripada kebanyakan orang yang membacanya sekarang.

XMODEM dan ZMODEM: apabila bil telefon membentuk reka bentuk

Ward Christensen menulis MODEM.ASM pada tahun 1977, dan protokol yang diperkenalkannya ialah XMODEM. Pada tahun 1978, beliau dan Randy Suess melancarkan CBBS, sistem papan buletin awam yang pertama. Christensen meninggal dunia pada 11 Oktober 2024.

XMODEM merupakan antara protokol yang paling ringkas. Data dipindahkan dalam blok 128-bait. Setiap blok membawa satu bait checksum, iaitu hasil tambah 128 bait data modulo 256. Penerima akan memberikan pengakuan (acknowledgement) bagi setiap blok atau memintanya semula. Sebab bagi bentuk ini adalah ekonomi. Pada talian dail-up, anda membayar mengikut masa, jadi ralat talian hanya merugikan satu blok dan bukannya keseluruhan pemindahan.

Kelemahannya terletak pada ayat yang sama. XMODEM menunggu pengakuan selepas setiap 128 bait. Chuck Forsberg menyatakannya dengan jelas dalam spesifikasi ZMODEM: "Panjang blok yang pendek menyebabkan throughput terjejas apabila digunakan dengan sistem perkongsian masa, rangkaian pensuisan paket, dan litar satelit." Latensi adalah punca utama kegagalan kaedah stop-and-wait, bukan lebar jalur. Setiap perjalanan pergi-balik (round trip) adalah masa terbuang pada talian yang anda bayar.

YMODEM menyusul kemudian, dan Ward Christensen mencipta nama tersebut pada tahun 1985. Sumbangannya ialah pemindahan kelompok (batch transfer). Pengirim menyatakan nama fail dan saiz sebelum data dihantar, supaya beberapa fail boleh dipindahkan dalam satu sesi dan penerima mengetahui di mana setiap fail berakhir.

ZMODEM ialah jawapan Chuck Forsberg, yang ditulis di Omen Technology. Spesifikasinya adalah semakan 14 Oktober 1988, dan ia menyatakan bahawa "ZMODEM dibangunkan untuk domain awam di bawah kontrak Telenet". Telenet mengendalikan rangkaian data pensuisan paket awam, dan kontrak itu terserlah dalam reka bentuknya. ZMODEM melakukan escape pada aksara kawalan rangkaian supaya rangkaian paket di pertengahan tidak menggunakannya. Ia menandakan permulaan setiap bingkai dengan jujukan aksara unik dan bukannya menyimpulkan sempadan bingkai daripada kesunyian, jadi ia pulih daripada gangguan tanpa perlu menunggu tamat masa (timeout). Ia juga mempunyai fungsi sambung semula (resume) yang jelas, jadi pemindahan yang terganggu akan bermula semula dari tempat ia terhenti.

Paling penting, ia berhenti menunggu. Deskripsi spesifikasi itu sendiri menyatakan bahawa "ZMODEM sebenarnya menggunakan keseluruhan fail sebagai tetingkap". Pengirim menstrim data, dan hanya berhenti apabila penerima melaporkan masalah. Itu adalah wawasan yang sama yang dikodkan oleh TCP dalam tetingkapnya, yang dicapai dari arah berbeza, oleh seseorang yang memerhatikan modem yang terbiar.

Mengapa dua sambungan FTP menjadi sangat ketinggalan zaman

FTP lebih lama daripada segala-galanya. RFC 114, "A File Transfer Protocol", bertarikh 16 April 1971 dan ditulis oleh A. Bhushan.

Perincian yang perlu diketahui ialah RFC 114 pernah mempertimbangkan reka bentuk dua sambungan dan menolaknya. Bhushan menimbang "penggunaan dua pautan full-duplex, satu untuk maklumat kawalan, satu lagi untuk data" dan kemudian membuat kesimpulan: "Kami mengesyorkan penggunaan satu sambungan full-duplex untuk pertukaran kedua-dua data dan maklumat kawalan." Pemisahan itu tiba kemudian. RFC 354, bertarikh 8 Julai 1972, menyatakan bahawa "data dan fail dipindahkan hanya melalui sambungan data", dengan arahan bergerak melalui sambungan Telnet yang berasingan. RFC 959, Oktober 1985, oleh Postel dan Reynolds, ialah versi yang masih dilaksanakan oleh semua orang.

RFC 959 juga menetapkan port tersebut. Port data lalai pelayan ialah "port yang bersebelahan dengan port sambungan kawalan (iaitu, L-1)", iaitu port 20 apabila sambungan kawalan ialah port 21.

Inilah bahagian yang tidak bertahan. Dalam mod asal FTP, pelayan membuka sambungan data kembali ke klien. Klien di sebalik NAT (network address translation) tidak mempunyai alamat yang boleh dicapai oleh pelayan, dan klien di sebalik firewall tidak menerima sambungan masuk, jadi sambungan data tidak pernah sampai dan pemindahan tergantung sebaik sahaja penyenaraian atau fail diminta. Jawapannya ialah PASV, yang ditakrifkan oleh RFC 959 sebagai permintaan untuk pelayan "untuk 'mendengar' pada port data (yang bukan port data lalainya) dan menunggu sambungan dan bukannya memulakannya apabila menerima arahan pemindahan". Pelayan membalas dengan alamat dan port untuk disambungkan:

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

Balasan itu bermaksud hos 203.0.113.10, port 195 darab 256 tambah 80, iaitu 50000. Baca semula dan masalah struktur itu kelihatan. Titik akhir sambungan kedua diumumkan di dalam payload sambungan pertama. Kotak NAT atau firewall tidak boleh melepasi sambungan itu melainkan ia menghuraikan saluran kawalan dan membuka port yang dilihatnya di sana. Linux menyertakan pembantu penjejakan sambungan yang melakukan perkara ini dengan tepat. Pembantu itu hanya berfungsi semasa sambungan kawalan dalam teks jelas (cleartext), jadi membungkus FTP dalam TLS (transport layer security) membutakan kotak perantara yang menjadikan FTP boleh digunakan.

Itulah pengajaran tentang FTP dalam satu ayat. Ia menjadikan rangkaian sebagai peserta dalam protokol. Protokol yang memerlukan rangkaian untuk memahaminya tidak boleh bertahan dalam rangkaian yang berhenti mempercayainya.

Pengakhirannya telah direkodkan. Firefox membuang sokongan FTP dalam versi 90 pada Julai 2021. Chrome membuang kod FTP dalam Chrome 95 pada Oktober 2021.

rcp dan arahan-r: kepercayaan melalui hostname

4.2BSD, yang dilancarkan pada tahun 1983 oleh Berkeley dengan pembiayaan DARPA, memperkenalkan rcp, rsh dan rlogin. Ia dibina untuk kampus mesin Unix dalam satu rangkaian, dan model pengesahannya mencerminkan perkara tersebut. Sebuah hos akan menyatakan pengguna mana yang membuat panggilan. Jika /etc/hosts.equiv atau ~/.rhosts milik pengguna menyatakan hos tersebut dipercayai, pernyataan itu diterima dan tiada kata laluan diminta.

Nyatakan mekanisme ini dengan jelas, kerana inilah sebab arahan-arahan ini tidak lagi digunakan. Kepercayaan bergantung pada alamat dan tuntutan. Kedua-duanya bergerak melalui rangkaian dalam teks jelas (cleartext), jadi sesiapa sahaja di sepanjang laluan tersebut boleh membacanya dan sesiapa sahaja boleh memalsukannya. Model itu masuk akal dalam persekitaran yang diterangkan dalam laluan daripada Unix ke Linux, di mana rangkaiannya hanyalah sebuah bangunan. Ia tidak lagi masuk akal sebaik sahaja rangkaian tersebut menjadi internet.

Apa yang dilakukan dengan betul oleh rcp ialah antara mukanya. Sumber, destinasi, selesai. Tiada sesi untuk dibuka, tiada mod pemindahan untuk dirundingkan, tiada sambungan kedua untuk diatur. Ia berkelakuan seperti cp dengan tanda titik bertindih dalam laluan. Antara muka itu bertahan lebih lama daripada protokolnya selama empat dekad.

SSH menguasai keseluruhan kategori

Pada tahun 1995, Tatu Ylonen, yang ketika itu merupakan penyelidik di Helsinki University of Technology, menulis SSH sebagai tindak balas terhadap serangan pengintipan kata laluan di rangkaian universiti tersebut. Beliau mengeluarkannya sebagai perisian bebas berserta kod sumber pada Julai 1995. Menjelang akhir tahun tersebut, dianggarkan terdapat sekitar 20,000 pengguna di 50 buah negara, dan pada Disember 1995, beliau mengasaskan SSH Communications Security untuk terus membangunkannya.

Lesen perisian tersebut menjadi lebih ketat pada versi-versi seterusnya, maka pembangun OpenBSD melakukan fork terhadap keluaran berlesen bebas yang terakhir, iaitu ssh 1.2.12. Import awal dilakukan pada 26 September 1999, dan OpenSSH 1.2.2 dikeluarkan bersama OpenBSD 2.6 pada 1 Disember 1999. Fork tersebut merupakan kajian kes ringkas tentang mengapa terma pelesenan sumber terbuka penting dalam praktiknya, kerana implementasi SSH yang digunakan oleh hampir semua orang hari ini adalah keturunan daripada satu-satunya versi yang lesennya masih membenarkannya.

Sebaik sahaja SSH wujud, pemindahan fail tidak lagi menjadi masalah yang berasingan. Strim terenkripsi yang disahkan dan membawa pelbagai saluran sudah menyediakan apa yang protokol lama perlu bina sendiri: integriti, penyusunan, dan laluan data kedua yang tidak memerlukan sambungan TCP kedua. Jika mekanik tersebut baharu bagi anda, mulakan dengan memahami apa itu SSH sebenarnya sebelum pergi lebih jauh.

Dua alat terhasil daripadanya. scp ialah protokol wayar rcp yang dijalankan di dalam sesi SSH, itulah sebabnya ia mewarisi baris perintah rcp sepenuhnya. SFTP mempunyai reka bentuk yang berbeza: protokol fail sebenar dengan penyenaraian direktori, atribut fail, dan akses rawak yang dibawa melalui saluran SSH. SFTP tidak pernah menjadi RFC. Draf IETF, draft-ietf-secsh-filexfer, mencapai versi 13 pada 18 Julai 2006 dan kemudian luput. OpenSSH mengimplementasikan versi 3 draf tersebut. Protokol pemindahan fail selamat yang paling banyak digunakan di dunia adalah semakan bernombor daripada draf yang telah ditinggalkan, dan ia berfungsi.

Protokol scp legasi kini telah ditamatkan juga. OpenSSH 8.8, yang dikeluarkan pada 26 September 2021, memberi amaran bahawa "keluaran OpenSSH masa depan akan menukar scp(1) daripada menggunakan protokol scp/rcp legasi kepada menggunakan SFTP secara lalai". OpenSSH 9.0, yang dikeluarkan pada 8 April 2022, telah melaksanakannya: "Keluaran ini menukar scp(1) daripada menggunakan protokol scp/rcp legasi kepada menggunakan protokol SFTP secara lalai."

Sebabnya menjelaskan satu cerita rakyat teknikal. Protokol scp lama mengembangkan wildcard nama fail jauh dengan menyerahkannya kepada shell jauh, itulah sebabnya orang belajar untuk meletakkan tanda petikan berganda pada setiap metakarakter dalam laluan jauh. Nota versi 8.8 menyatakan bahawa scp melalui SFTP "tidak lagi memerlukan petikan yang rumit dan rapuh ini". Jadi pada pelayan semasa, scp ialah klien SFTP yang menggunakan baris perintah rcp. Antara muka tahun 1983 itu bertahan. Protokol wayar tahun 1983 itu tidak.

rsync, 1996: hantar perbezaan, bukan fail

Andrew Tridgell dan Paul Mackerras mengumumkan rsync pada 19 Jun 1996 di Australian National University, bersama-sama laporan teknikal TR-CS-96-05, "The rsync algorithm".

Setiap protokol sebelum itu bertanya bagaimana untuk memindahkan fail tanpa merosakkannya. rsync bertanya berapa banyak bahagian fail ini yang sudah dimiliki oleh pihak penerima. Laporan tersebut menetapkan sasaran sebagai "pautan komunikasi dua hala yang berjalur lebar rendah dan berlatensi tinggi", dan matlamatnya adalah untuk mengenal pasti "bahagian fail sumber yang sama dengan mana-mana bahagian fail destinasi", supaya hanya bahagian yang tidak sepadan dihantar.

Mekanismenya perlu difahami kerana ia menjelaskan kelakuan rsync. Penerima memotong salinan sedia ada kepada blok bersaiz tetap dan mengira dua checksum bagi setiap blok, satu yang lemah dan murah, satu lagi yang kuat dan mahal. Ia menghantar senarai tersebut kepada penghantar. Penghantar meluncurkan tetingkap ke atas failnya sendiri satu bait pada satu masa dan mengemas kini checksum lemah secara berperingkat, yang menjadikan imbasan bait-demi-bait mampu dilakukan. Padanan lemah kemudian disahkan dengan checksum kuat. Padanan yang disahkan menjadi rujukan blok. Segala yang lain dihantar sebagai bait literal. Penerima membina semula fail daripada rujukan blok yang sudah dimilikinya ditambah dengan literal yang baru diterima.

Masukkan satu bait pada permulaan fail yang besar dan alat perbezaan biasa perlu menghantar keseluruhan fail, kerana setiap offset telah beralih. Tetingkap gelongsor menemui blok yang sama pada offset baharunya, jadi rsync hanya menghantar satu bait ditambah dengan data pengurusan. Sifat itulah yang menjadikan rsync alat yang tepat untuk direktori yang akan anda salin lebih daripada sekali.

Dua kelakuan sering mengejutkan pengguna, dan kedua-duanya ada dalam manual. Pertama, rsync tidak melakukan checksum pada fail untuk menentukan sama ada ia perlu diperiksa. Ia "mencari fail yang perlu dipindahkan menggunakan algoritma 'quick check' (secara lalai) yang mencari fail yang telah berubah dari segi saiz atau masa pengubahsuaian terakhir". Fail yang kandungannya berubah tetapi saiz dan cap masanya kekal sama akan dilangkau. --checksum mengubah perkara ini, dan memaksa kedua-dua pihak membaca setiap fail calon sepenuhnya. Kedua, algoritma delta dinyahaktifkan secara lalai apabila kedua-dua laluan adalah tempatan, kerana membaca dan melakukan checksum pada dua salinan dalam satu mesin memakan kos yang lebih tinggi daripada menyalin bait tersebut. Penjimatan hanya wujud apabila pautan rangkaian menjadi bahagian yang perlahan.

Perkara yang sebenarnya anda gunakan pada VPS, dan sebabnya

Versi ringkas: SFTP untuk beberapa fail, rsync melalui SSH untuk direktori yang akan anda salin semula.

Kedua-duanya menggunakan SSH, jadi kedua-duanya mewarisi pengesahan host key dan penyulitan tanpa konfigurasi tambahan. Itu adalah hasil kerja selama lima puluh tahun yang dimampatkan menjadi tetapan lalai. Pereka Kermit terpaksa mengandaikan talian akan merosakkan data, jadi mereka membina checksum dan penghantaran semula ke dalam protokol tersebut. TCP melakukan perkara itu sekarang. Christensen dan Forsberg terpaksa mengandaikan setiap bait memerlukan kos, jadi mereka membina fungsi sambung semula (resume) dan penstriman. Algoritma delta rsync melakukan perkara itu sekarang, dan melakukannya dengan lebih baik. Penulis FTP mengandaikan rangkaian hos yang bekerjasama, dan itu adalah satu-satunya andaian yang ternyata salah dengan cara yang tidak dapat diperbaiki oleh sebarang kerja protokol.

Apakah kegunaan checksum pada masa kini

Istilah "checksum" telah menjalankan tiga tugas berbeza sepanjang sejarah ini, dan ia tidak boleh ditukar ganti.

Checksum bagi setiap paket dalam Kermit dan XMODEM mengesan kerosakan data pada talian. Hari ini, checksum TCP dan pembetulan ralat dalam lapisan pautan (link layer) sudah mengendalikan tugas tersebut, itulah sebabnya tiada alat pemindahan moden yang meminta anda memikirkannya.

Checksum blok dalam rsync tidak menjawab soalan "adakah data ini betul". Ia menjawab soalan "adakah anda sudah mempunyai blok ini". Checksum yang kuat di situ berfungsi sebagai kunci carian, bukan pernyataan tentang asal-usul fail tersebut.

Tugas ketiga adalah satu-satunya yang masih menjadi tanggungjawab anda. Checksum yang diterbitkan pada fail release menjawab soalan yang tidak dapat dijawab oleh TLS. TLS membuktikan anda berhubung dengan pelayan yang betul. Ia tidak membuktikan fail yang betul berada di pelayan tersebut, dan ia tidak membantu bagi fail yang anda ambil daripada cermin (mirror). Itulah sebabnya checksum dan tandatangan release masih berbaloi untuk diperiksa dalam masa tiga puluh saat, dan tabiat ini mudah dibina: periksa checksum pada setiap muat turun yang anda pasang.

Segala perkara lain dalam cerita ini telah diselesaikan oleh lapisan di bawahnya. Tugas yang satu ini tidak selesai, kerana ia bukan masalah rangkaian.

FAQ

Adakah FTP masih selamat digunakan pada VPS?

Tidak. FTP biasa menghantar kelayakan dan kandungan fail dalam teks jelas, jadi sesiapa sahaja di sepanjang laluan tersebut boleh membacanya. Ia juga bergantung pada firewall yang menghuraikan saluran kawalannya, dan perkara itu tidak lagi dapat dilakukan sebaik sahaja anda menyulitkan saluran kawalan dengan TLS. Pelayar web telah pun menggugurkannya: Firefox membuang sokongan FTP dalam versi 90 pada Julai 2021, dan Chrome membuang kod tersebut dalam versi 95 pada Oktober 2021. Gunakan SFTP melalui SSH, yang hanya memerlukan satu port dan tidak memerlukan peranti perantara yang memahami protokol.

Mengapakah FTP memerlukan mod pasif?

Kerana dalam mod asal FTP, pelayan membuka sambungan data kembali ke klien. RFC 959 menetapkan port data lalai pelayan pada "port bersebelahan dengan port sambungan kawalan (iaitu, L-1)", jadi port 20 apabila kawalan berada pada port 21. Klien di sebalik NAT (network address translation) tidak mempunyai alamat yang boleh dicapai oleh pelayan, jadi sambungan itu tidak pernah sampai dan pemindahan terhenti. PASV menyongsangkan arah tersebut: pelayan pula yang mendengar, dan menjawab dengan alamat serta port di dalam balasan 227 Entering Passive Mode untuk disambungkan oleh klien.

Adakah scp masih menggunakan protokolnya sendiri?

Tidak lagi sejak OpenSSH 9.0, yang dikeluarkan pada 8 April 2022, yang "menukar scp(1) daripada menggunakan protokol scp/rcp legasi kepada menggunakan protokol SFTP secara lalai". OpenSSH 8.8 telah mengumumkan perubahan ini pada September 2021. Perbezaan yang ketara ialah penggunaan tanda petikan. Protokol lama mengembangkan wildcard jauh dengan menyerahkannya kepada shell jauh, manakala protokol berasaskan SFTP tidak berbuat demikian, jadi laluan yang bergantung pada pengembangan shell tersebut kini berkelakuan berbeza.

Bilakah rsync lebih baik daripada scp untuk VPS?

Apabila anda ingin menyalin pepohon fail yang sama lebih daripada sekali. rsync hanya menghantar bahagian setiap fail yang belum dimiliki oleh destinasi, jadi salinan kedua jauh lebih pantas berbanding yang pertama. Untuk satu fail tunggal yang belum pernah dilihat oleh destinasi, scp dan rsync memindahkan jumlah bait yang lebih kurang sama dan scp adalah lebih ringkas. Ingat bahawa rsync menentukan apa yang perlu diperiksa berdasarkan saiz dan masa pengubahsuaian secara lalai, jadi fail yang kandungannya berubah tetapi saiz dan cap masanya tidak berubah memerlukan --checksum sebelum rsync dapat mengesannya.

Mengapakah Kermit mengekod fail sebagai teks boleh cetak dan bukannya menghantar bait mentah?

Kerana sambungan yang disasarkannya ialah talian terminal ke kerangka utama (mainframe) dan bukannya paip bait. Pautan tersebut boleh jadi 7-bit, dan pemacu terminal kerangka utama bertindak balas terhadap aksara kawalan dan bukannya membiarkannya melaluinya. Kermit mengekod bait kawalan dan bait bit tinggi kepada aksara boleh cetak supaya tiada apa-apa di pertengahan yang akan bertindak balas terhadapnya. Pengekodan ini menjadikan fail binari lebih besar semasa penghantaran, yang merupakan pertukaran yang tepat berbanding pemindahan yang sebaliknya akan sampai dalam keadaan rosak.