Dosya aktarım protokollerinin evrimi: Kermit'ten rsync'e

Dosya aktarım protokolleri neden sürekli değişti

Dosya aktarım protokollerinin her biri, kendi döneminin hata modlarına karşı tasarlanmıştır. Kermit, hattın baytları bozacağını varsayıyordu. XMODEM ve ZMODEM, bağlantının yavaş olduğunu ve her dakika için ücret ödendiğini varsayıyordu. FTP (file transfer protocol), aradaki ağın işbirlikçi olduğunu varsayıyordu. SSH ise ağın düşmanca olduğunu varsaydı. Kazanan varsayım bu sonuncusu oldu; günümüzde bir VPS'in size SFTP ve rsync'i SSH üzerinden sunmasının ve bunun dışında çok az seçenek barındırmasının nedeni budur.

Buna bakmak için şu an uygun bir zaman. C-Kermit 11.0.506, 3 Ağustos 2026 tarihinde yayınlandı. Bu sürüm, 20 Ağustos 2011'deki C-Kermit 9.0.302 sürümünden bu yana çıkan ilk beta olmayan sürümdür ve uyguladığı protokol Mayıs 1981'de tasarlanmıştır. Kırk beş yıl, tüm bir kategorinin icat edilmesini, standartlaştırılmasını, üzerinde çalıştığı ağ tarafından bozulmasını ve ardından SSH bünyesine dahil edilmesini izlemek için yeterince uzun bir süredir.

Kermit, 1981: baytlarınızı yutan hatlar için tasarlandı

Kermit, Mayıs 1981'de Columbia Üniversitesi Bilgisayar Merkezi'nde Frank da Cruz ve Bill Catchings tarafından geliştirildi. İsmi, Kermit the Frog karakterinden gelmektedir. Da Cruz'un anlatımına göre, grup bir isim ararken duvarda bir Muppets takvimi asılıydı ve kimse bu yazılımın bu kadar yayılacağını tahmin etmiyordu.

Kermit'in çözdüğü sorun hız değildi. Bir terminal ile ana bilgisayar (mainframe) arasındaki yol, rastgele baytlar için bir boru hattı görevi görmüyordu. Bu, kendine has kuralları olan bir karakter aygıtıydı. 7-bit olabiliyordu. Yarı çift yönlü (half-duplex) çalışabiliyordu. Kontrol karakterlerini yutabiliyor veya bunlardan birini komut olarak algılayabiliyordu. İkili (binary) bir dosyayı olduğu gibi göndermek çalışmıyordu.

Bu nedenle tasarım, bu kısıtlamaları olduğu gibi kabul etti. The Kermit Project'in kendi geçmişi bunları şu şekilde listeler:

• Kısa paketler; çünkü çoğu ana bilgisayar, terminalden gelen uzun veri akışlarını kabul edemiyordu.
• Yarı çift yönlü dur-ve-bekle (stop-and-wait) protokolü; çünkü IBM ana bilgisayarları tam çift yönlü iletişimi desteklemiyordu.
• Kontrol karakterleri ve 8-bit karakterler için yazdırılabilir kodlamalar; çünkü bunların hiçbiri ana bilgisayarın terminal sürücüsünden geçemiyordu.
• Her pakette bir sağlama toplamı (checksum) ve alıcı tarafından verilen yanıt; böylece bozuk bir paket tüm dosyanın değil, sadece bir yeniden iletimin maliyetine neden oluyordu.

Üçüncü madde en ilginç olanıdır. Kermit, dosyanın kendisini göndermek yerine dosyanın metin tabanlı güvenli bir kodlamasını gönderir. Bir kontrol baytı, bir önek karakterini takip eden yazdırılabilir bir karaktere dönüşür; yüksek biti ayarlanmış bir bayt da 7-bitlik bir bağlantı için aynı şekilde kodlanabilir. Aradaki, sadece yazdırılabilir metinden anlayan herhangi bir sistem, sadece yazdırılabilir metin görür. Bunun maliyeti boyuttur: ikili bir dosya hat üzerinde büyür. Aksi takdirde aktarımı tamamen bozacak bir ana bilgisayar ön ucu karşısında, bu doğru bir takastı.

Kermit'in diğer sıra dışı özelliği kapsamıdır. XMODEM, dosyanın ne olduğu konusunda zaten anlaşmış iki makine arasında dosya taşıyordu. Kermit ise; farklı karakter setlerine, farklı kayıt yapılarına ve satır sonunun ne olduğu konusunda farklı fikirlere sahip, anlaşamayan sistemler arasında en küçük ortak payda olarak yazıldı. Bu, ana bilgisayarlardan bulut sunucularına uzun yolculuk başlığında tarif edilen dünyadır ve Kermit, ağ katmanı sizin için bunu halletmeden önce birlikte çalışabilirliğin nasıl göründüğünün bir kanıtıdır.

Columbia, 2011 yılında sponsorluğunu sonlandırdı ve C-Kermit'i revize edilmiş 3 maddeli BSD lisansı altında yayınladı. Frank da Cruz, 1981'deki tasarımdan 2025'e kadar 44 yıl boyunca projede kaldı. 2026 sürümü, şu an bu metni okuyanların çoğundan daha eski bir C kod tabanını modernize etme görevini üstlenen John Goerzen ile birlikte OpenKermit projesi tarafından sürdürülmektedir.

XMODEM ve ZMODEM: telefon faturalarının tasarımı şekillendirdiği dönem

Ward Christensen, 1977 yılında MODEM.ASM dosyasını yazdı ve bu dosyanın tanıttığı protokol XMODEM olarak adlandırıldı. 1978 yılında kendisi ve Randy Suess, ilk halka açık bülten panosu sistemi olan CBBS'i çevrimiçi hale getirdi. Christensen, 11 Ekim 2024 tarihinde hayatını kaybetti.

XMODEM, bir protokolün olabileceği kadar küçüktür. Veri, 128 baytlık bloklar halinde taşınır. Her blok, 128 baytlık verinin 256 moduna göre toplamı olan bir baytlık bir sağlama toplamı (checksum) taşır. Alıcı, her bloğu onaylar veya tekrar gönderilmesini ister. Bu yapının nedeni ekonomiktir. Çevirmeli ağ (dial-up) hatlarında süreye göre ücret ödenir; bu nedenle bir hat hatası, tüm aktarım yerine yalnızca bir bloğun maliyetine neden olmalıdır.

Zayıflık da aynı cümlede yatmaktadır. XMODEM, her 128 bayttan sonra bir onay bekler. Chuck Forsberg, ZMODEM teknik özelliklerinde bunu açıkça belirtmiştir: "Kısa blok uzunluğu, zaman paylaşımlı sistemler, paket anahtarlamalı ağlar ve uydu devreleri ile kullanıldığında veri aktarım hızının düşmesine neden olur." Dur-ve-bekle (stop-and-wait) yöntemini öldüren şey bant genişliği değil, gecikmedir. Her gidiş-dönüş süresi, ücretini ödediğiniz bir hat üzerinde boş geçen zamandır.

Ardından YMODEM geldi ve Ward Christensen bu ismi 1985 yılında türetti. YMODEM'in katkısı toplu dosya aktarımıydı. Gönderici, veriden önce dosya adını ve boyutunu belirtir; böylece tek bir oturumda birden fazla dosya aktarılabilir ve alıcı her birinin nerede bittiğini bilir.

ZMODEM, Chuck Forsberg'in Omen Technology bünyesinde yazdığı cevaptır. Teknik özelliklerin revizyon tarihi 14 Ekim 1988'dir ve "ZMODEM'in bir Telenet sözleşmesi kapsamında kamu malı olarak geliştirildiği" belirtilir. Telenet, halka açık bir paket anahtarlamalı veri ağı işletiyordu ve bu sözleşme tasarıma yansımıştır. ZMODEM, ağ kontrol karakterlerini kaçış dizileriyle (escape) korur; böylece aradaki bir paket ağı bu karakterleri tüketmez. Çerçeve sınırlarını sessizlikten çıkarmak yerine her çerçevenin başlangıcını benzersiz bir karakter dizisiyle işaretler; bu sayede zaman aşımını beklemeden gürültüden kurtulabilir. Ayrıca açık bir devam ettirme özelliği vardır, böylece kesintiye uğrayan bir aktarım kaldığı yerden devam eder.

En önemlisi, beklemeyi bırakır. Teknik özelliklerin kendi tanımıyla "ZMODEM, aslında tüm dosyayı bir pencere olarak kullanır". Gönderici akışı sağlar ve yalnızca alıcı bir sorun bildirdiğinde durur. Bu, TCP'nin pencere yapısında kodladığı içgörüyle aynıdır; ancak bu sonuca, bir modemin boşta bekleyişini izleyen biri tarafından diğer yönden ulaşılmıştır.

FTP'nin iki bağlantılı yapısı neden güncelliğini yitirdi

FTP, bunların hepsinden daha eskidir. 16 Nisan 1971 tarihli ve A. Bhushan tarafından yazılan RFC 114, "A File Transfer Protocol" adını taşır.

Bilinmesi gereken önemli detay, RFC 114'ün iki bağlantılı tasarımı değerlendirip reddetmiş olmasıdır. Bhushan, "biri kontrol bilgisi, diğeri veri için olmak üzere iki tam çift yönlü bağlantı kullanmayı" tartmış ve şu sonuca varmıştır: "Hem veri hem de kontrol bilgisinin değişimi için tek bir tam çift yönlü bağlantı kullanılmasını öneriyoruz." Ayrım daha sonra ortaya çıkmıştır. 8 Temmuz 1972 tarihli RFC 354, "veri ve dosyaların yalnızca veri bağlantısı üzerinden aktarıldığını", komutların ise ayrı bir Telnet bağlantısı üzerinden iletildiğini belirtir. Postel ve Reynolds tarafından Ekim 1985'te yayımlanan RFC 959 ise herkesin hâlâ uyguladığı sürümdür.

RFC 959 ayrıca portları da sabitlemiştir. Sunucunun varsayılan veri portu, "kontrol bağlantısı portunun bir eksiği (yani L-1)" olarak tanımlanmıştır; bu da kontrol bağlantısı 21 numaralı port olduğunda 20 numaralı port anlamına gelir.

İşte günümüze ulaşamayan kısım burasıdır. FTP'nin orijinal modunda sunucu, istemciye doğru veri bağlantısını kendisi açar. NAT (ağ adresi çevirisi) arkasındaki bir istemcinin sunucunun ulaşabileceği bir adresi yoktur; güvenlik duvarı arkasındaki bir istemci ise gelen bağlantıları kabul etmez. Bu nedenle veri bağlantısı asla kurulamaz ve bir dizin listesi veya dosya istendiği anda aktarım askıda kalır. Bunun çözümü, RFC 959'da sunucunun "bir veri portunda (varsayılan veri portu olmayan) 'dinlemeye' geçmesi ve bir aktarım komutu aldığında bağlantı başlatmak yerine bağlantı beklemesi" talebi olarak tanımlanan PASV modudur. Sunucu, bağlanılacak adresi ve portu şu şekilde yanıtlar:

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

Bu yanıt, 203.0.113.10 ana bilgisayarı, 195 çarpı 256 artı 80, yani 50000 numaralı port anlamına gelir. Tekrar okunduğunda yapısal sorun belirginleşir. İkinci bağlantının uç noktası, ilk bağlantının yükü (payload) içinde duyurulur. Bir NAT cihazı veya güvenlik duvarı, kontrol kanalını ayrıştırıp orada gördüğü portu açmadığı sürece bu bağlantıyı geçiremez. Linux, tam olarak bunu yapan bir bağlantı izleme yardımcısı (connection tracking helper) ile gelir. Bu yardımcı yalnızca kontrol bağlantısı düz metin (cleartext) olduğunda çalışır; bu nedenle FTP'yi TLS (taşıma katmanı güvenliği) ile sarmalamak, FTP'yi kullanılabilir kılan ara kutuyu (middlebox) kör eder.

FTP'nin dersi tek bir cümlede şudur: Ağı, protokolün bir katılımcısı haline getirmiştir. Ağın kendisini anlamasını gerektiren bir protokol, ağın ona güvenmeyi bıraktığı bir ortamda varlığını sürdüremez.

Sonuç kayıtlara geçmiştir. Firefox, Temmuz 2021'de yayımlanan 90 numaralı sürümünde FTP desteğini kaldırmıştır. Chrome ise Ekim 2021'de yayımlanan Chrome 95 sürümünde FTP kodunu tamamen çıkarmıştır.

rcp ve r-komutları: ana bilgisayar adına dayalı güven

1983 yılında DARPA fonuyla Berkeley tarafından yayınlanan 4.2BSD; rcp, rsh ve rlogin araçlarını beraberinde getirdi. Bu araçlar, tek bir ağ üzerindeki Unix makinelerinden oluşan bir kampüs ortamı için geliştirilmişti ve kimlik doğrulama modeli de bu amaca hizmet ediyordu. Bir ana bilgisayar, hangi kullanıcının çağrı yaptığını beyan ederdi. Eğer /etc/hosts.equiv veya kullanıcının ~/.rhosts dosyası, o ana bilgisayarın güvenilir olduğunu belirtiyorsa, beyan kabul edilir ve parola sorulmazdı.

Bu mekanizmayı açıkça ifade etmek gerekir; çünkü bu komutların artık kullanılmamasının nedeni budur. Güven, bir adrese ve bir iddiaya dayanıyordu. Her ikisi de ağ üzerinden açık metin olarak iletildiği için, yol üzerindeki herhangi biri bunları okuyabilir veya taklit edebilirdi. Bu model, Unix'ten Linux'a giden yol içerisinde tanımlanan, ağın tek bir binadan ibaret olduğu ortamda mantıklıydı. Ağın internete dönüştüğü anda ise bu model geçerliliğini yitirdi.

rcp'nin başarılı olduğu nokta arayüzüydü. Kaynak, hedef ve işlem tamam. Açılacak bir oturum, üzerinde anlaşılacak bir aktarım modu veya ayarlanacak ikinci bir bağlantı yoktu. Yol kısmında iki nokta üst üste kullanılan cp gibi davranır. Bu arayüz, kendi protokolünden kırk yıl daha uzun süre varlığını sürdürdü.

SSH tüm kategoriyi kapsıyor

1995 yılında, o dönem Helsinki Teknoloji Üniversitesi'nde araştırmacı olan Tatu Ylonen, üniversite ağındaki bir parola dinleme saldırısına yanıt olarak SSH'i yazdı. Temmuz 1995'te kaynak kodlarıyla birlikte özgür yazılım olarak yayınladı. Aynı yılın sonunda 50 ülkede yaklaşık 20.000 kullanıcıya ulaştı ve Aralık 1995'te geliştirmeye devam etmek için SSH Communications Security şirketini kurdu.

İlerleyen sürümlerde lisans koşulları ağırlaşınca, OpenBSD geliştiricileri özgür lisanslı son sürüm olan ssh 1.2.12'yi çatalladı (fork). İlk içe aktarma 26 Eylül 1999'da yapıldı ve OpenSSH 1.2.2, 1 Aralık 1999'da OpenBSD 2.6 ile birlikte piyasaya sürüldü. Bu çatallanma, açık kaynak lisans koşullarının pratikte neden önemli olduğuna dair kompakt bir vaka çalışmasıdır; çünkü bugün herkesin kullandığı SSH uygulaması, lisansı buna izin veren tek sürümden türemiştir.

SSH var olduğunda, dosya transferi ayrı bir sorun olmaktan çıktı. Birden fazla kanal taşıyan kimlik doğrulamalı ve şifreli bir akış, eski protokollerin kendi başlarına inşa etmek zorunda kaldığı bütünlük, sıralama ve ikinci bir TCP bağlantısına ihtiyaç duymayan ikinci bir veri yolu gibi özellikleri zaten sağlar. Bu mekanizmalar sizin için yeniyse, devam etmeden önce SSH'in gerçekte ne olduğuna dair temel bilgilere göz atın.

Bu süreçten iki araç çıktı. scp, bir SSH oturumu içinde çalışan rcp kablo protokolüydü; bu yüzden rcp'nin komut satırı arayüzünü birebir devraldı. SFTP ise farklı bir tasarımdır: dizin listeleme, dosya öznitelikleri ve rastgele erişim özelliklerine sahip, bir SSH kanalı üzerinden taşınan gerçek bir dosya protokolüdür. SFTP hiçbir zaman RFC haline gelmedi. IETF taslağı olan draft-ietf-secsh-filexfer, 18 Temmuz 2006'da 13. sürüme ulaştı ve ardından süresi doldu. OpenSSH, bu taslağın 3. sürümünü uygular. Dünyada en yaygın kullanılan güvenli dosya transfer protokolü, terk edilmiş bir taslağın numaralandırılmış bir revizyonudur ve çalışmaktadır.

Eski scp protokolü de artık emekliye ayrıldı. 26 Eylül 2021'de yayınlanan OpenSSH 8.8, "OpenSSH'in yakın gelecekteki bir sürümünün scp(1) komutunu varsayılan olarak eski scp/rcp protokolü yerine SFTP kullanacak şekilde değiştireceği" uyarısında bulundu. 8 Nisan 2022'de yayınlanan OpenSSH 9.0 bunu gerçekleştirdi: "Bu sürüm, scp(1) komutunu varsayılan olarak eski scp/rcp protokolü yerine SFTP protokolünü kullanacak şekilde değiştirdi."

Bunun nedeni bir efsaneyi de açıklıyor. Eski scp protokolü, uzak dosya adı joker karakterlerini (wildcard) uzak kabuğa göndererek genişletiyordu; bu yüzden insanlar uzak yollardaki her meta karakteri çift tırnak içine almayı öğrendi. 8.8 sürüm notları, SFTP üzerinden scp kullanımının "artık bu zahmetli ve kırılgan tırnak işaretlerine ihtiyaç duymadığını" belirtiyor. Yani güncel bir sunucuda scp, rcp'nin komut satırı arayüzünü kullanan bir SFTP istemcisidir. 1983 tarihli arayüz hayatta kaldı, ancak 1983 tarihli kablo protokolü kalmadı.

rsync, 1996: dosyanın tamamını değil, farkı gönderin

Andrew Tridgell ve Paul Mackerras, 19 Haziran 1996 tarihinde Avustralya Ulusal Üniversitesi'nde, TR-CS-96-05 numaralı "The rsync algorithm" başlıklı teknik raporla birlikte rsync aracını duyurdu.

rsync öncesindeki tüm protokoller, bir dosyanın bozulmadan nasıl taşınacağını sorguluyordu. rsync ise karşı tarafın elinde bu dosyanın ne kadarının zaten mevcut olduğunu sordu. Rapor, hedefi "düşük bant genişlikli, yüksek gecikmeli çift yönlü bir iletişim bağlantısı" olarak tanımlar. Amaç, "kaynak dosyanın hedef dosyadaki herhangi bir kısımla aynı olan bölümlerini" tespit etmek ve yalnızca eşleşmeyen kısımları göndermektir.

rsync'in çalışma biçimini açıkladığı için mekanizmasını anlamak önemlidir. Alıcı taraf, elindeki mevcut kopyayı sabit boyutlu bloklara böler ve her blok için biri zayıf ve düşük maliyetli, diğeri güçlü ve yüksek maliyetli olmak üzere iki sağlama toplamı (checksum) hesaplar. Bu listeyi göndericiye iletir. Gönderici, kendi dosyası üzerinde bir pencereyi her seferinde bir bayt kaydırarak zayıf sağlama toplamını artımlı olarak günceller; bayt bayt taramanın uygulanabilir olmasını sağlayan şey budur. Zayıf bir eşleşme, güçlü sağlama toplamı ile doğrulanır. Doğrulanan eşleşmeler blok referanslarına dönüşür. Geriye kalan her şey ise doğrudan baytlar halinde gönderilir. Alıcı, dosyayı elinde zaten tuttuğu blok referansları ve yeni aldığı baytlarla yeniden oluşturur.

Büyük bir dosyanın başına tek bir bayt eklerseniz, basit bir fark aracı tüm dosyayı yeniden göndermek zorundadır çünkü her baytın ofseti değişmiştir. Kayan pencere mekanizması ise aynı blokları yeni ofsetlerinde bulur; bu sayede rsync yalnızca o tek baytı ve gerekli kayıt bilgilerini gönderir. Bu özellik, rsync'in birden fazla kez kopyalayacağınız dizinler için neden hâlâ en doğru araç olduğunu açıklar.

İki davranış kullanıcıları düzenli olarak şaşırtır ve her ikisi de kılavuzda yer alır. Birincisi, rsync dosyaları inceleyip incelemeyeceğine karar vermek için sağlama toplamı kullanmaz. Varsayılan olarak, "dosya boyutundaki veya son değiştirilme zamanındaki değişiklikleri kontrol eden bir 'hızlı kontrol' algoritması kullanarak aktarılması gereken dosyaları bulur". İçeriği değişmiş ancak boyutu ve zaman damgası aynı kalmış bir dosya atlanır. --checksum bayrağı bu durumu değiştirir ve her iki tarafın da tüm aday dosyaları tamamen okumasını sağlar. İkincisi, her iki yol da yerel olduğunda delta algoritması varsayılan olarak kapalıdır; çünkü tek bir makinedeki iki kopyayı okuyup sağlama toplamı hesaplamak, baytları doğrudan kopyalamaktan daha maliyetlidir. Tasarruf, yalnızca bağlantının yavaş olduğu durumlarda gerçekleşir.

Bir VPS üzerinde gerçekte neye ihtiyaç duyarsınız ve neden

Kısa cevap: Birkaç dosya için SFTP, tekrar kopyalayacağınız bir dizin için ise SSH üzerinden rsync.

Her ikisi de SSH üzerinde çalıştığından, ek bir yapılandırma gerektirmeden ana bilgisayar anahtarı doğrulamasını ve şifrelemeyi devralır. Bu, elli yıllık çalışmanın varsayılan bir ayara sıkıştırılmış halidir. Kermit'in tasarımcıları hattın veriyi bozacağını varsaymak zorundaydı, bu yüzden protokolün içine sağlama toplamları ve yeniden iletim mekanizmaları inşa ettiler. TCP bunu artık hallediyor. Christensen ve Forsberg her baytın bir maliyeti olduğunu varsaymak zorundaydı, bu yüzden kaldığı yerden devam etme ve akış özelliklerini geliştirdiler. rsync'in delta algoritması artık bunu yapıyor ve daha iyi bir şekilde gerçekleştiriyor. FTP'nin yazarları iş birliği yapan bir ağ varsaymıştı ve bu varsayımlar arasında, hiçbir protokol çalışmasının düzeltemeyeceği şekilde yanlış çıkan tek şey budur.

Checksum değerlerinin günümüzdeki işlevi

"Checksum" terimi tarih boyunca üç farklı görev üstlenmiştir ve bu görevler birbirinin yerine kullanılamaz.

Kermit ve XMODEM protokollerinin paket bazlı checksum değerleri, hat üzerindeki veri bozulmalarını tespit ediyordu. Günümüzde TCP checksum ve veri bağı katmanındaki hata düzeltme mekanizmaları bu işi üstlendiği için, hiçbir modern transfer aracı sizden bu konu üzerinde düşünmenizi beklemez.

rsync aracının blok checksum değerleri "bu veri doğru mu" sorusuna yanıt vermez. Bunun yerine "bu bloğa zaten sahip misin" sorusunu yanıtlar. Buradaki güçlü bir checksum, dosyanın kaynağına dair bir kanıt değil, bir arama anahtarıdır.

Üçüncü görev ise hâlâ sizin sorumluluğunuzdadır. Bir sürüm dosyası üzerinde yayınlanan checksum, TLS protokolünün yanıtlayamadığı bir soruyu yanıtlar. TLS, doğru sunucuyla iletişim kurduğunuzu kanıtlar. Ancak o sunucuda doğru dosyanın bulunduğunu kanıtlamaz ve bir yansıma (mirror) sunucusundan çektiğiniz dosya için hiçbir koruma sağlamaz. İşte bu yüzden sürüm checksum değerlerini ve imzalarını kontrol etmek, harcayacağınız otuz saniyeye değer; bu alışkanlığı edinmek de oldukça kolaydır: yüklediğiniz her indirme dosyasının checksum değerini kontrol edin.

Bu hikayedeki diğer tüm sorunlar, alttaki katmanlar tarafından çözülmüştür. Bu sorun ise çözülmemiştir, çünkü hiçbir zaman bir ağ problemi olmamıştır.

FAQ

Is FTP still safe to use on a VPS?

No. Plain FTP sends credentials and file contents in cleartext, so anyone on the path reads both. It also depends on a firewall that parses its control channel, and that stops being possible the moment you encrypt the control channel with TLS. The browsers already dropped it: Firefox removed FTP support in version 90 in July 2021, and Chrome removed the code in version 95 in October 2021. Use SFTP over SSH, which needs one port and no protocol-aware middlebox.

Why does FTP need a passive mode at all?

Because in FTP's original mode the server opens the data connection back to the client. RFC 959 puts the server's default data port at "the port adjacent to the control connection port (i.e., L-1)", so port 20 when control is port 21. A client behind NAT (network address translation) has no address the server can reach, so that connection never arrives and the transfer hangs. PASV reverses the direction: the server listens instead, and answers with an address and port inside a 227 Entering Passive Mode reply for the client to connect to.

Does scp still use its own protocol?

Not since OpenSSH 9.0, released 8 April 2022, which "switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default". OpenSSH 8.8 announced the change in September 2021. The visible difference is quoting. The old protocol expanded remote wildcards by passing them to the remote shell, and the SFTP-based one does not, so paths that relied on that shell expansion behave differently now.

When is rsync better than scp for a VPS?

When you will copy the same tree more than once. rsync sends only the parts of each file that the destination does not already have, so the second copy is far cheaper than the first. For a single file the destination has never seen, scp and rsync move roughly the same bytes and scp is simpler. Remember that rsync decides what to look at by size and modification time by default, so a file whose contents changed while its size and timestamp did not needs --checksum before rsync will notice it.

Why did Kermit encode files as printable text instead of sending raw bytes?

Because the connection it targeted was a terminal line into a mainframe rather than a byte pipe. Those links could be 7-bit, and the mainframe's terminal driver acted on control characters instead of passing them through. Kermit encoded control bytes and high-bit bytes into printable characters so that nothing in the middle would react to them. The encoding makes binary files larger on the wire, which was the correct trade against a transfer that would otherwise arrive corrupted.