Protokol Transfer File: Dari Kermit hingga rsync

Mengapa protokol transfer file terus berubah

Setiap protokol transfer file dirancang untuk menghadapi jenis kegagalan pada zamannya. Kermit mengasumsikan bahwa koneksi akan merusak byte yang dikirim. XMODEM dan ZMODEM mengasumsikan bahwa koneksi lambat dan setiap menit penggunaannya berbayar. FTP (file transfer protocol) mengasumsikan bahwa jaringan di antara kedua pihak dapat bekerja sama. SSH mengasumsikan bahwa jaringan tersebut tidak tepercaya. Asumsi terakhir inilah yang bertahan. Karena itu, VPS saat ini menyediakan SFTP dan rsync melalui SSH, dengan pilihan lain yang sangat terbatas.

Ada alasan untuk membahas hal ini sekarang. C-Kermit 11.0.506 dirilis pada 3 August 2026. Ini adalah rilis non-beta pertama sejak C-Kermit 9.0.302 pada 20 August 2011. Protokol yang diimplementasikannya dirancang pada May 1981. Empat puluh lima tahun cukup lama untuk menyaksikan seluruh kategori teknologi diciptakan, distandardisasi, dirusak oleh jaringan tempatnya berjalan, lalu diserap ke dalam SSH.

Kermit, 1981: dirancang untuk jalur yang menghilangkan byte Anda

Kermit dibuat pada Mei 1981 di Columbia University Computer Center oleh Frank da Cruz dan Bill Catchings. Namanya berasal dari Kermit the Frog. Menurut kisah da Cruz, kalender Muppets tergantung di dinding ketika kelompok tersebut sedang mencari nama, dan tidak seorang pun menyangka bahwa program ini akan menyebar.

Masalah yang diselesaikan Kermit bukan kecepatan. Jalur antara terminal dan mainframe bukanlah pipa untuk byte sembarang. Jalur itu merupakan character device dengan batasan tertentu. Jalur tersebut dapat menggunakan 7-bit. Jalur tersebut dapat bersifat half duplex. Jalur tersebut dapat menghilangkan control character atau menjalankan salah satunya sebagai perintah. Mengirim file biner tanpa perubahan melalui jalur itu tidak berhasil.

Karena itu, desain Kermit secara langsung mengikuti batasan tersebut. Riwayat dari Kermit Project sendiri mencantumkan hal-hal berikut:

• paket pendek, karena sebagian besar mainframe tidak dapat menerima burst data masuk yang panjang dari terminal
• half-duplex stop-and-wait, karena mainframe IBM tidak mendukung komunikasi full-duplex
• encoding yang dapat dicetak untuk control character dan karakter 8-bit, karena keduanya tidak dapat melewati terminal driver mainframe
• checksum pada setiap paket, yang dijawab oleh penerima, sehingga paket yang rusak hanya memerlukan satu retransmission, bukan pengiriman ulang seluruh file

Poin ketiga adalah bagian yang menarik. Kermit mengirim encoding file yang aman untuk teks, bukan file itu sendiri. Byte kontrol diubah menjadi karakter prefix yang diikuti karakter yang dapat dicetak, dan byte dengan high bit aktif dapat di-encode dengan cara yang sama untuk link 7-bit. Apa pun yang berada di tengah dan hanya memahami teks yang dapat dicetak akan menerima teks yang dapat dicetak. Konsekuensinya adalah ukuran: file biner menjadi lebih besar saat dikirim melalui jaringan. Jika dibandingkan dengan front end mainframe yang akan merusak transfer sepenuhnya, pertukaran tersebut merupakan pilihan yang tepat.

Sifat Kermit lain yang tidak biasa adalah cakupannya. XMODEM memindahkan file antara dua mesin yang sudah sepakat tentang arti sebuah file. Kermit ditulis sebagai least common denominator di antara sistem yang tidak memiliki kesepakatan tersebut, dengan character set, record structure, dan aturan berbeda tentang apa yang mengakhiri baris teks. Itulah dunia yang dijelaskan dalam perjalanan panjang dari mainframe ke server cloud, dan Kermit adalah bentuk interoperabilitas sebelum network layer menanganinya untuk Anda.

Columbia mengakhiri sponsorship pada 2011 dan merilis C-Kermit berdasarkan revised 3-clause BSD licence. Frank da Cruz tetap terlibat dalam proyek tersebut selama 44 tahun, dari desain pada 1981 hingga 2025. Rilis 2026 dikelola oleh OpenKermit project, dengan John Goerzen yang memodernisasi codebase C yang lebih tua daripada sebagian besar orang yang kini membacanya.

XMODEM dan ZMODEM: ketika biaya telepon membentuk desain

Ward Christensen menulis MODEM.ASM pada 1977, dan protokol yang diperkenalkannya adalah XMODEM. Pada 1978, ia dan Randy Suess membuat CBBS tersedia secara online, yaitu bulletin board system publik pertama. Christensen meninggal pada 11 October 2024.

XMODEM hampir sesederhana mungkin untuk sebuah protokol. Data dipindahkan dalam blok berukuran 128 byte. Setiap blok membawa checksum satu byte, yaitu jumlah 128 byte data modulo 256. Penerima mengakui setiap blok atau meminta pengiriman ulang. Bentuk ini dibuat karena pertimbangan biaya. Pada koneksi dial-up, Anda membayar berdasarkan waktu, sehingga error pada saluran seharusnya hanya mengharuskan pengiriman ulang satu blok, bukan seluruh transfer.

Kelemahannya terdapat pada kalimat yang sama. XMODEM menunggu acknowledgement setelah setiap 128 byte. Chuck Forsberg menjelaskannya secara langsung dalam spesifikasi ZMODEM: "Panjang blok yang pendek menyebabkan throughput menurun ketika digunakan dengan sistem timesharing, jaringan packet-switched, dan sirkuit satelit." Latensi, bukan bandwidth, yang membuat mekanisme stop-and-wait tidak efisien. Setiap round trip menjadi waktu kosong pada saluran yang biayanya terus berjalan.

YMODEM hadir berikutnya, dan Ward Christensen menciptakan nama tersebut pada 1985. Kontribusinya adalah transfer batch. Pengirim menyatakan nama file dan ukurannya sebelum data dikirim, sehingga beberapa file dapat dipindahkan dalam satu sesi dan penerima mengetahui batas setiap file.

ZMODEM adalah jawaban Chuck Forsberg, yang ditulis di Omen Technology. Spesifikasinya adalah revisi 14 October 1988, dan menyatakan bahwa "ZMODEM dikembangkan untuk public domain berdasarkan kontrak Telenet". Telenet mengoperasikan jaringan data packet-switched publik, dan kontrak tersebut tercermin dalam desainnya. ZMODEM melakukan escape terhadap karakter kontrol jaringan agar packet network di tengah koneksi tidak menggunakannya. Protokol ini menandai awal setiap frame dengan urutan karakter unik, alih-alih menyimpulkan batas frame dari keheningan, sehingga dapat pulih dari noise tanpa menunggu timeout. ZMODEM juga memiliki mekanisme resume eksplisit, sehingga transfer yang terputus dapat dimulai kembali dari posisi terakhir.

Yang paling penting, ZMODEM berhenti menunggu. Deskripsi dalam spesifikasinya sendiri menyatakan bahwa "ZMODEM pada praktiknya menggunakan seluruh file sebagai window". Pengirim melakukan streaming dan hanya berhenti ketika penerima melaporkan masalah. Ini adalah wawasan yang sama yang diterapkan TCP melalui window-nya, tetapi dicapai dari arah yang berlawanan oleh seseorang yang melihat modem dalam keadaan idle.

Mengapa dua koneksi FTP cepat menjadi usang

FTP lebih tua daripada semua teknologi tersebut. RFC 114, "A File Transfer Protocol", bertanggal 16 April 1971 dan ditulis oleh A. Bhushan.

Detail yang perlu diketahui adalah bahwa RFC 114 mempertimbangkan desain dua koneksi, lalu menolaknya. Bhushan menimbang "using two full-duplex links, one for control information, the other for data", lalu menyimpulkan: "We recommend using a single full-duplex connection for the exchange of both data and control information." Pemisahan tersebut muncul kemudian. RFC 354, bertanggal 8 July 1972, menyatakan bahwa "data and files are transferred only via the data connection", sedangkan perintah dikirim melalui koneksi Telnet terpisah. RFC 959, October 1985, yang ditulis oleh Postel dan Reynolds, adalah versi yang masih diimplementasikan hingga sekarang.

RFC 959 juga menetapkan port. Port data default server adalah "the port adjacent to the control connection port (i.e., L-1)", yaitu port 20 ketika koneksi kontrol menggunakan port 21.

Bagian berikutnya tidak bertahan. Dalam mode asli FTP, server membuka koneksi data kembali ke client. Client di belakang NAT (network address translation) tidak memiliki alamat yang dapat dijangkau server. Client di belakang firewall juga tidak menerima koneksi masuk. Akibatnya, koneksi data tidak pernah tiba dan transfer berhenti segera setelah listing atau file diminta. Solusinya adalah PASV. RFC 959 mendefinisikannya sebagai permintaan agar server "'listen' on a data port (which is not its default data port) and to wait for a connection rather than initiate one upon receipt of a transfer command". Server membalas dengan alamat dan port yang harus digunakan untuk koneksi:

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

Balasan tersebut berarti host 203.0.113.10 dan port 195 dikali 256 ditambah 80, yaitu 50000. Baca kembali balasan tersebut. Masalah strukturalnya terlihat jelas. Endpoint koneksi kedua diumumkan di dalam payload koneksi pertama. Perangkat NAT atau firewall tidak dapat meneruskan koneksi tersebut kecuali perangkat itu mengurai channel kontrol dan membuka port yang tercantum di dalamnya. Linux menyediakan connection tracking helper yang melakukan hal ini. Helper tersebut hanya berfungsi selama koneksi kontrol menggunakan cleartext. Karena itu, membungkus FTP dengan TLS (transport layer security) membuat middlebox yang sebelumnya memungkinkan FTP berfungsi tidak dapat membaca koneksi tersebut.

Itulah pelajaran FTP dalam satu kalimat. FTP menjadikan jaringan sebagai peserta dalam protokol. Protokol yang mengharuskan jaringan memahaminya tidak dapat bertahan ketika jaringan berhenti mempercayainya.

Akhirnya tercatat dalam dokumentasi. Firefox menghapus dukungan FTP pada version 90 pada July 2021. Chrome menghapus kode FTP pada Chrome 95 pada October 2021.

rcp dan r-command: kepercayaan berdasarkan hostname

4.2BSD, yang dirilis pada 1983 oleh Berkeley dengan pendanaan DARPA, memperkenalkan rcp, rsh, dan rlogin. Perintah-perintah ini dibuat untuk lingkungan kampus yang memiliki beberapa mesin Unix dalam satu jaringan, dan model autentikasinya mencerminkan lingkungan tersebut. Sebuah host menyatakan pengguna mana yang sedang melakukan permintaan. Jika /etc/hosts.equiv atau ~/.rhosts milik pengguna menyatakan bahwa host tersebut tepercaya, pernyataan itu diterima dan kata sandi tidak diminta.

Jelaskan mekanismenya secara langsung karena mekanisme inilah yang menyebabkan perintah-perintah tersebut ditinggalkan. Kepercayaan hanya bergantung pada alamat dan sebuah klaim. Keduanya dikirim melalui jaringan dalam teks biasa. Karena itu, siapa pun yang berada di jalur jaringan dapat membacanya dan memalsukannya. Model tersebut masuk akal dalam lingkungan yang dijelaskan di perjalanan dari Unix ke Linux, ketika jaringan hanya mencakup sebuah gedung. Model itu tidak lagi masuk akal sejak jaringan tersebut menjadi Internet.

Hal yang benar dari rcp adalah antarmukanya. Sumber, tujuan, selesai. Tidak ada sesi yang harus dibuka, mode transfer yang harus dinegosiasikan, atau koneksi kedua yang harus diatur. Perintah ini berperilaku seperti cp dengan titik dua di dalam path. Antarmuka tersebut bertahan empat dekade lebih lama daripada protokolnya.

SSH mencakup seluruh kategori

Pada 1995, Tatu Ylonen, yang saat itu merupakan peneliti di Helsinki University of Technology, menulis SSH sebagai tanggapan terhadap serangan penyadapan kata sandi pada jaringan universitas tersebut. Ia merilisnya sebagai perangkat lunak gratis beserta kode sumbernya pada Juli 1995. Pada akhir tahun itu, jumlah penggunanya diperkirakan mencapai sekitar 20,000 orang di 50 negara. Pada Desember 1995, ia mendirikan SSH Communications Security untuk melanjutkan pengembangannya.

Lisensinya menjadi lebih ketat pada versi-versi berikutnya. Karena itu, pengembang OpenBSD mem-fork rilis terakhir yang masih berlisensi bebas, yaitu ssh 1.2.12. Impor awal dilakukan pada 26 September 1999. OpenSSH 1.2.2 dirilis bersama OpenBSD 2.6 pada 1 Desember 1999. Fork tersebut menjadi contoh ringkas mengapa ketentuan lisensi open source penting dalam praktik, karena implementasi SSH yang digunakan hampir semua orang saat ini berasal dari satu versi yang lisensinya masih mengizinkannya.

Setelah SSH tersedia, transfer file tidak lagi menjadi masalah terpisah. Stream terautentikasi dan terenkripsi yang membawa banyak channel sudah menyediakan hal-hal yang sebelumnya harus dibangun sendiri oleh protokol lama: integritas, pengurutan, dan jalur data kedua yang tidak memerlukan koneksi TCP kedua. Jika mekanisme ini masih baru bagi Anda, mulailah dari penjelasan tentang SSH sebenarnya sebelum melanjutkan.

Dua alat lahir dari SSH. scp adalah protokol wire rcp yang dijalankan di dalam sesi SSH. Karena itu, sintaks command line-nya sama persis dengan rcp. SFTP merupakan desain yang berbeda: protokol file yang sebenarnya, dengan listing direktori, atribut file, dan akses acak, yang dibawa melalui channel SSH. SFTP tidak pernah menjadi RFC. Draf IETF, draft-ietf-secsh-filexfer, mencapai versi 13 pada 18 Juli 2006, lalu kedaluwarsa. OpenSSH mengimplementasikan versi 3 dari draf tersebut. Protokol transfer file aman yang paling banyak digunakan di dunia merupakan revisi bernomor dari draf yang telah ditinggalkan, dan protokol itu tetap berfungsi.

Protokol scp lama kini juga telah dihentikan. OpenSSH 8.8, yang dirilis pada 26 September 2021, memperingatkan bahwa "a near-future release of OpenSSH will switch scp(1) from using the legacy scp/rcp protocol to using SFTP by default". OpenSSH 9.0, yang dirilis pada 8 April 2022, menerapkannya: "This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default."

Alasannya menjelaskan salah satu pengetahuan umum yang sering diwariskan. Protokol scp lama memperluas wildcard nama file jarak jauh dengan menyerahkannya kepada shell jarak jauh. Karena itu, pengguna mempelajari bahwa setiap metakarakter dalam path jarak jauh harus diapit tanda kutip ganda. Catatan versi 8.8 menyatakan bahwa scp melalui SFTP "no longer requires this finicky and brittle quoting". Jadi, pada server saat ini, scp adalah client SFTP yang menggunakan sintaks command line milik rcp. Antarmuka dari 1983 tetap bertahan. Protokol wire dari 1983 tidak.

rsync, 1996: mengirimkan perbedaan, bukan file

Andrew Tridgell dan Paul Mackerras mengumumkan rsync pada 19 June 1996 di Australian National University, bersamaan dengan technical report TR-CS-96-05, "The rsync algorithm".

Setiap protokol sebelumnya membahas cara memindahkan file tanpa merusaknya. rsync membahas seberapa banyak bagian file ini yang sudah dimiliki pihak lain. Laporan tersebut menetapkan targetnya sebagai "a low-bandwidth high-latency bi-directional communications link", dengan tujuan mengidentifikasi "parts of the source file which are identical to some part of the destination file", sehingga hanya bagian yang tidak cocok yang dikirim.

Mekanismenya penting untuk dipahami karena menjelaskan perilaku rsync. Receiver membagi salinan yang sudah dimilikinya menjadi blok berukuran tetap, lalu menghitung dua checksum untuk setiap blok: satu checksum lemah dan murah, serta satu checksum kuat dan mahal. Receiver mengirimkan daftar tersebut kepada sender. Sender menggeser window pada filenya sendiri satu byte setiap kali dan memperbarui checksum lemah secara inkremental. Proses inilah yang membuat pemindaian byte demi byte tetap efisien. Kecocokan lemah kemudian dikonfirmasi dengan checksum kuat. Kecocokan yang terkonfirmasi menjadi referensi blok. Semua bagian lainnya dikirim sebagai byte literal. Receiver membangun kembali file dari referensi ke blok yang sudah dimilikinya dan byte literal yang baru diterima.

Jika satu byte disisipkan di awal file besar, tool perbedaan yang naif harus mengirim seluruh file karena setiap offset berubah. Rolling window menemukan blok yang sama pada offset baru, sehingga rsync hanya mengirim satu byte dan bookkeeping. Sifat inilah yang membuat rsync tetap menjadi tool yang tepat untuk direktori yang akan Anda salin lebih dari satu kali.

Dua perilaku sering mengejutkan pengguna, dan keduanya dijelaskan dalam manual. Pertama, rsync tidak melakukan checksum pada file untuk menentukan apakah file tersebut perlu diperiksa. rsync "finds files that need to be transferred using a 'quick check' algorithm (by default) that looks for files that have changed in size or in last-modified time". File yang isinya berubah, tetapi ukuran dan timestamp-nya tetap sama, akan dilewati. --checksum mengubah perilaku tersebut dan membuat kedua sisi membaca setiap file kandidat secara lengkap. Kedua, delta algorithm secara default dinonaktifkan jika kedua path bersifat lokal karena membaca dan menghitung checksum pada dua salinan di satu mesin membutuhkan biaya lebih besar daripada menyalin byte. Penghematan hanya terjadi jika link menjadi bagian yang lambat.

Yang sebenarnya Anda gunakan pada VPS, dan alasannya

Versi singkatnya: gunakan SFTP untuk beberapa file, dan rsync melalui SSH untuk direktori yang akan Anda salin lagi.

Keduanya menggunakan SSH, sehingga mewarisi verifikasi kunci host dan enkripsi tanpa konfigurasi tambahan. Itu adalah hasil kerja selama lima puluh tahun yang diringkas dalam konfigurasi default. Perancang Kermit harus mengasumsikan bahwa jalur komunikasi dapat merusak data, sehingga mereka menambahkan checksum dan pengiriman ulang ke dalam protokol. Sekarang TCP yang melakukan hal tersebut. Christensen dan Forsberg harus mengasumsikan bahwa setiap byte memerlukan biaya, sehingga mereka menambahkan kemampuan melanjutkan transfer dan streaming. Sekarang algoritme delta rsync yang melakukan hal tersebut, dan melakukannya dengan lebih baik. Pembuat FTP mengasumsikan adanya jaringan host yang saling bekerja sama. Hanya asumsi inilah yang terbukti keliru dengan cara yang tidak dapat diperbaiki oleh pekerjaan protokol sebanyak apa pun.

Checksum masih bermanfaat untuk apa

Istilah "checksum" telah menjalankan tiga fungsi berbeda sepanjang sejarah ini, dan ketiganya tidak dapat saling menggantikan.

Checksum per paket milik Kermit dan XMODEM mendeteksi kerusakan data saat transmisi melalui jaringan. Saat ini, checksum TCP dan koreksi error pada lapisan link menangani hal tersebut. Karena itu, tidak ada alat transfer modern yang meminta Anda memikirkannya.

Checksum blok rsync tidak menjawab pertanyaan "apakah data ini benar". Checksum tersebut menjawab "apakah Anda sudah memiliki blok ini". Dalam konteks ini, checksum yang kuat berfungsi sebagai kunci pencarian, bukan sebagai pernyataan tentang asal file.

Fungsi ketiga masih menjadi tanggung jawab Anda. Checksum yang dipublikasikan pada file rilis menjawab pertanyaan yang tidak dapat dijawab oleh TLS. TLS membuktikan bahwa Anda terhubung ke server yang benar. TLS tidak membuktikan bahwa file yang benar berada di server tersebut, dan tidak melindungi file yang Anda unduh dari mirror. Karena itu, checksum dan signature rilis masih layak diperiksa selama tiga puluh detik. Kebiasaan ini juga mudah dibangun: periksa checksum pada setiap unduhan yang Anda instal.

Semua hal lain dalam cerita ini telah ditangani oleh lapisan di bawahnya. Hal yang satu ini belum, karena sejak awal hal tersebut bukan masalah jaringan.

FAQ

Apakah FTP masih aman digunakan pada VPS?

Tidak. FTP biasa mengirim kredensial dan isi file dalam teks biasa, sehingga siapa pun yang berada di jalur jaringan dapat membaca keduanya. FTP juga bergantung pada firewall yang mem-parsing kanal kontrol, dan hal itu tidak lagi memungkinkan setelah kanal kontrol dienkripsi dengan TLS. Browser sudah menghentikan dukungan ini: Firefox menghapus dukungan FTP pada versi 90 pada Juli 2021, dan Chrome menghapus kodenya pada versi 95 pada Oktober 2021. Gunakan SFTP melalui SSH. SFTP hanya memerlukan satu port dan tidak memerlukan middlebox yang memahami protokol.

Mengapa FTP memerlukan mode pasif?

Karena pada mode asli FTP, server membuka koneksi data kembali ke client. RFC 959 menetapkan port data default server pada "port yang bersebelahan dengan port koneksi kontrol (yaitu, L-1)", sehingga portnya adalah 20 jika port kontrolnya 21. Client di belakang NAT (network address translation) tidak memiliki alamat yang dapat dijangkau server. Akibatnya, koneksi tersebut tidak pernah tiba dan transfer terhenti. PASV membalik arah koneksi: server justru menunggu koneksi, lalu memberikan alamat dan port dalam balasan 227 Entering Passive Mode agar client dapat terhubung.

Apakah scp masih menggunakan protokolnya sendiri?

Tidak sejak OpenSSH 9.0, yang dirilis pada 8 April 2022 dan "mengalihkan scp(1) dari penggunaan protokol scp/rcp lama ke protokol SFTP secara default". OpenSSH 8.8 mengumumkan perubahan ini pada September 2021. Perbedaan yang terlihat adalah cara menangani tanda kutip. Protokol lama memperluas wildcard jarak jauh dengan meneruskannya ke shell jarak jauh. Protokol yang berbasis SFTP tidak melakukan hal itu. Karena itu, path yang bergantung pada perluasan oleh shell tersebut kini berperilaku berbeda.

Kapan rsync lebih baik daripada scp untuk VPS?

Gunakan rsync jika Anda akan menyalin tree yang sama lebih dari satu kali. rsync hanya mengirim bagian setiap file yang belum dimiliki tujuan, sehingga penyalinan kedua jauh lebih hemat daripada penyalinan pertama. Untuk satu file yang belum pernah ada di tujuan, scp dan rsync memindahkan jumlah byte yang kurang lebih sama, dan scp lebih sederhana. Ingat bahwa secara default rsync menentukan file yang perlu diperiksa berdasarkan ukuran dan waktu modifikasi. Jadi, file yang isinya berubah tetapi ukuran dan timestamp-nya tidak berubah memerlukan --checksum sebelum rsync dapat mendeteksi perubahan tersebut.

Mengapa Kermit menyandikan file sebagai teks yang dapat dicetak, bukan mengirim byte mentah?

Karena koneksi yang dituju adalah saluran terminal ke mainframe, bukan pipe byte. Koneksi tersebut dapat menggunakan 7-bit, dan driver terminal mainframe memproses karakter kontrol, bukan meneruskannya begitu saja. Kermit menyandikan byte kontrol dan byte bit tinggi menjadi karakter yang dapat dicetak agar tidak ada komponen di tengah yang bereaksi terhadapnya. Penyandian ini membuat file biner berukuran lebih besar saat dikirim melalui jaringan. Namun, itulah kompromi yang tepat dibandingkan transfer yang jika tidak dilakukan demikian akan menghasilkan file rusak.