File transfer protocols का इतिहास: Kermit से rsync तक

फाइल ट्रांसफर प्रोटोकॉल में बदलाव क्यों होते रहे

प्रत्येक फाइल ट्रांसफर प्रोटोकॉल को उसके दशक की विफलता की स्थितियों (failure modes) को ध्यान में रखकर डिजाइन किया गया था। Kermit यह मानकर चलता था कि लाइन आपके बाइट्स को करप्ट कर देगी। XMODEM और ZMODEM यह मानकर चलते थे कि कनेक्शन धीमा है और आप हर मिनट के लिए भुगतान कर रहे हैं। FTP (file transfer protocol) यह मानकर चलता था कि बीच का नेटवर्क सहयोगी है। SSH यह मानकर चलता था कि नेटवर्क शत्रुतापूर्ण है। यह अंतिम धारणा ही सफल रही, यही कारण है कि आज एक VPS आपको SFTP और rsync over SSH प्रदान करता है और इसके अलावा बहुत कम विकल्प देता है।

अब इस पर विचार करने का एक अवसर है। C-Kermit 11.0.506 को 3 August 2026 को रिलीज किया गया था। यह 20 August 2011 को आए C-Kermit 9.0.302 के बाद पहला नॉन-बीटा रिलीज है, और जिस प्रोटोकॉल को यह लागू करता है उसे May 1981 में डिजाइन किया गया था। पैंतालीस वर्ष का समय इतना लंबा होता है कि इसमें एक पूरी श्रेणी का आविष्कार होते, मानकीकृत होते, जिस नेटवर्क पर वह चलती थी उसके द्वारा बाधित होते और फिर SSH में समाहित होते देखा जा सकता है।

Kermit, 1981: एक ऐसी लाइन के लिए डिज़ाइन किया गया जो आपके बाइट्स खा जाती है

Kermit को मई 1981 में Columbia University Computer Center में Frank da Cruz और Bill Catchings द्वारा बनाया गया था। इसका नाम Kermit the Frog से लिया गया है। Da Cruz के अनुसार, जब समूह एक नाम सोचने की कोशिश कर रहा था, तब दीवार पर एक Muppets कैलेंडर लगा था, और किसी को उम्मीद नहीं थी कि यह इतना लोकप्रिय हो जाएगा।

Kermit ने जिस समस्या का समाधान किया, वह गति नहीं थी। टर्मिनल और मेनफ्रेम के बीच का रास्ता मनमाने बाइट्स के लिए एक पाइप नहीं था। यह एक ऐसा character device था जिसकी अपनी सीमाएं थीं। यह 7-bit हो सकता था। यह half-duplex हो सकता था। यह control characters को निगल सकता था, या उनमें से किसी एक को कमांड मानकर उस पर कार्रवाई कर सकता था। इसके माध्यम से किसी binary file को बिना बदले भेजना काम नहीं करता था।

इसलिए डिज़ाइन ने उन बाधाओं को अक्षरशः लिया। The Kermit Project का अपना इतिहास उन्हें सूचीबद्ध करता है:

• छोटे पैकेट, क्योंकि अधिकांश मेनफ्रेम टर्मिनल से आने वाले डेटा के लंबे bursts को नहीं संभाल सकते थे
• half-duplex stop-and-wait, क्योंकि IBM मेनफ्रेम full-duplex संचार का समर्थन नहीं करते थे
• control characters और 8-bit characters के लिए printable encodings, क्योंकि इनमें से कोई भी मेनफ्रेम के terminal driver से नहीं गुजर सकता था
• हर पैकेट पर एक checksum, जिसका उत्तर receiver द्वारा दिया जाता था, ताकि एक दूषित पैकेट के कारण पूरी फाइल के बजाय केवल एक retransmission की लागत आए

तीसरा बिंदु दिलचस्प है। Kermit फाइल के बजाय आपकी फाइल की एक text-safe encoding भेजता है। एक control byte एक prefix character बन जाता है जिसके बाद एक printable character आता है, और high bit set वाले बाइट को 7-bit लिंक के लिए उसी तरह encode किया जा सकता है। बीच में कोई भी सिस्टम जो केवल printable text समझता है, उसे केवल printable text ही दिखाई देता है। इसकी कीमत आकार है: एक binary file wire पर बड़ी हो जाती है। एक मेनफ्रेम फ्रंट एंड के खिलाफ, जो अन्यथा ट्रांसफर को पूरी तरह से खराब कर देता, यह एक सही समझौता था।

Kermit की एक और असामान्य विशेषता इसका दायरा है। XMODEM ने दो मशीनों के बीच एक फाइल को स्थानांतरित किया जो पहले से ही इस बात पर सहमत थीं कि फाइल क्या है। Kermit को उन सिस्टमों के बीच एक न्यूनतम सामान्य भाजक (least common denominator) के रूप में लिखा गया था जो सहमत नहीं थे, जिनमें अलग-अलग character sets, अलग-अलग record structures और text की लाइन समाप्त होने के बारे में अलग-अलग विचार थे। यह वह दुनिया है जिसका वर्णन मेनफ्रेम से क्लाउड सर्वर तक के लंबे सफर में किया गया है, और Kermit वह था जो नेटवर्क लेयर द्वारा आपके लिए सब कुछ संभालने से पहले इंटरऑपरेबिलिटी (interoperability) के रूप में दिखता था।

Columbia ने 2011 में अपनी प्रायोजन समाप्त कर दी और C-Kermit को संशोधित 3-clause BSD licence के तहत जारी किया। Frank da Cruz 1981 के डिज़ाइन से लेकर 2025 तक, 44 वर्षों तक इस प्रोजेक्ट के साथ जुड़े रहे। 2026 का रिलीज़ OpenKermit प्रोजेक्ट द्वारा बनाए रखा गया है, जिसमें John Goerzen उस C codebase को आधुनिक बनाने का काम कर रहे हैं जो इसे पढ़ने वाले अधिकांश लोगों से भी पुराना है।

XMODEM और ZMODEM: जब फोन बिल ने डिजाइन को आकार दिया

Ward Christensen ने 1977 में MODEM.ASM लिखा था, और जिस प्रोटोकॉल को उन्होंने पेश किया वह XMODEM है। 1978 में उन्होंने और Randy Suess ने CBBS को ऑनलाइन किया, जो पहला सार्वजनिक बुलेटिन बोर्ड सिस्टम था। Christensen का निधन 11 अक्टूबर 2024 को हुआ।

XMODEM एक प्रोटोकॉल के रूप में जितना छोटा हो सकता है, उतना ही है। डेटा 128-बाइट के ब्लॉक में चलता है। प्रत्येक ब्लॉक में एक-बाइट का चेकसम होता है, जो 128 डेटा बाइट्स का योग मॉड्यूलो 256 होता है। रिसीवर प्रत्येक ब्लॉक को स्वीकार करता है या उसे फिर से भेजने के लिए कहता है। इस आकार का कारण आर्थिक है। डायल-अप लाइन पर आप समय के लिए भुगतान करते हैं, इसलिए एक लाइन त्रुटि के कारण पूरे ट्रांसफर के बजाय केवल एक ब्लॉक का नुकसान होना चाहिए।

इसकी कमजोरी भी उसी वाक्य में निहित है। XMODEM हर 128 बाइट्स के बाद पावती (acknowledgement) की प्रतीक्षा करता है। Chuck Forsberg ने ZMODEM विनिर्देश में इसे स्पष्ट रूप से कहा है: "छोटा ब्लॉक आकार टाइमशेयरिंग सिस्टम, पैकेट स्विच्ड नेटवर्क और सैटेलाइट सर्किट के साथ उपयोग किए जाने पर थ्रूपुट को प्रभावित करता है।" लेटेंसी वह चीज है जो स्टॉप-एंड-वेट को खत्म करती है, न कि बैंडविड्थ। हर राउंड ट्रिप उस लाइन पर बेकार का समय है जिसके लिए आपसे बिल लिया जा रहा है।

इसके बाद YMODEM आया, और Ward Christensen ने 1985 में यह नाम गढ़ा। इसका योगदान बैच ट्रांसफर था। भेजने वाला डेटा से पहले फाइल का नाम और आकार बताता है, ताकि एक सत्र में कई फाइलें भेजी जा सकें और रिसीवर को पता हो कि प्रत्येक फाइल कहाँ समाप्त होती है।

ZMODEM, Chuck Forsberg का जवाब है, जिसे Omen Technology में लिखा गया था। विनिर्देश का संशोधन 14 अक्टूबर 1988 का है, और यह बताता है कि "ZMODEM को Telenet अनुबंध के तहत पब्लिक डोमेन के लिए विकसित किया गया था"। Telenet एक सार्वजनिक पैकेट-स्विच्ड डेटा नेटवर्क चलाता था, और वह अनुबंध इसके डिजाइन में दिखता है। ZMODEM नेटवर्क कंट्रोल कैरेक्टर्स को एस्केप करता है ताकि बीच में मौजूद पैकेट नेटवर्क उन्हें उपभोग न कर ले। यह प्रत्येक फ्रेम की शुरुआत को एक अद्वितीय कैरेक्टर सीक्वेंस के साथ चिह्नित करता है, बजाय इसके कि साइलेंस से फ्रेम की सीमाओं का अनुमान लगाया जाए, इसलिए यह टाइमआउट की प्रतीक्षा किए बिना शोर से उबर जाता है। इसमें स्पष्ट रूप से रिज्यूमे की सुविधा भी है, इसलिए एक बाधित ट्रांसफर वहीं से शुरू होता है जहाँ वह रुका था।

सबसे महत्वपूर्ण बात, यह प्रतीक्षा करना बंद कर देता है। विनिर्देश का अपना विवरण यह है कि "ZMODEM प्रभावी रूप से पूरी फाइल को एक विंडो के रूप में उपयोग करता है"। भेजने वाला स्ट्रीम करता है, और केवल तभी रुकता है जब रिसीवर किसी समस्या की रिपोर्ट करता है। यह वही अंतर्दृष्टि है जिसे TCP अपनी विंडो में एन्कोड करता है, जिसे दूसरी दिशा से प्राप्त किया गया है, एक ऐसे व्यक्ति द्वारा जिसने मॉडम को बेकार बैठे देखा था।

FTP के दो कनेक्शन इतने पुराने और अप्रचलित क्यों हो गए

FTP इन सबसे पुराना है। RFC 114, "A File Transfer Protocol", 16 अप्रैल 1971 का है और इसे A. Bhushan ने लिखा था।

जानने योग्य मुख्य विवरण यह है कि RFC 114 ने दो-कनेक्शन वाले डिज़ाइन पर विचार किया था और उसे अस्वीकार कर दिया था। Bhushan ने "कंट्रोल जानकारी के लिए एक और डेटा के लिए दूसरा, दो फुल-डुप्लेक्स लिंक का उपयोग करने" पर विचार किया और निष्कर्ष निकाला: "हम डेटा और कंट्रोल जानकारी दोनों के आदान-प्रदान के लिए एक ही फुल-डुप्लेक्स कनेक्शन का उपयोग करने की अनुशंसा करते हैं।" यह विभाजन बाद में आया। 8 जुलाई 1972 का RFC 354 बताता है कि "डेटा और फाइलें केवल डेटा कनेक्शन के माध्यम से ट्रांसफर की जाती हैं", जबकि कमांड एक अलग Telnet कनेक्शन पर चलते हैं। अक्टूबर 1985 का RFC 959, जिसे Postel और Reynolds ने लिखा था, वह संस्करण है जिसे आज भी हर कोई लागू करता है।

RFC 959 ने पोर्ट्स को भी निर्धारित किया। सर्वर का डिफ़ॉल्ट डेटा पोर्ट "कंट्रोल कनेक्शन पोर्ट के बगल वाला पोर्ट (अर्थात L-1)" है, जो कि पोर्ट 20 होता है जब कंट्रोल कनेक्शन पोर्ट 21 पर हो।

यहाँ वह हिस्सा है जो समय की कसौटी पर खरा नहीं उतरा। FTP के मूल मोड में, सर्वर क्लाइंट के पास वापस डेटा कनेक्शन खोलता है। NAT (नेटवर्क एड्रेस ट्रांसलेशन) के पीछे मौजूद क्लाइंट के पास ऐसा कोई पता नहीं होता जिस तक सर्वर पहुँच सके, और फायरवॉल के पीछे मौजूद क्लाइंट इनबाउंड कनेक्शन स्वीकार नहीं करता है। इसलिए, डेटा कनेक्शन कभी नहीं पहुँचता और जैसे ही कोई लिस्टिंग या फाइल मांगी जाती है, ट्रांसफर हैंग हो जाता है। इसका समाधान PASV था, जिसे RFC 959 सर्वर के लिए एक अनुरोध के रूप में परिभाषित करता है कि वह "एक डेटा पोर्ट पर 'listen' करे (जो उसका डिफ़ॉल्ट डेटा पोर्ट नहीं है) और ट्रांसफर कमांड मिलने पर कनेक्शन शुरू करने के बजाय कनेक्शन की प्रतीक्षा करे"। सर्वर उस पते और पोर्ट के साथ उत्तर देता है जिससे कनेक्ट करना है:

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

उस उत्तर का अर्थ है होस्ट 203.0.113.10, पोर्ट 195 गुना 256 प्लस 80, जो कि 50000 है। इसे फिर से पढ़ें और संरचनात्मक समस्या स्पष्ट हो जाएगी। दूसरे कनेक्शन का एंडपॉइंट पहले कनेक्शन के पेलोड के अंदर घोषित किया जाता है। एक NAT बॉक्स या फायरवॉल उस कनेक्शन को तब तक पास नहीं कर सकता जब तक कि वह कंट्रोल चैनल को पार्स न करे और वहां दिखने वाले पोर्ट को न खोले। Linux में एक कनेक्शन ट्रैकिंग हेल्पर होता है जो बिल्कुल यही काम करता है। यह हेल्पर केवल तभी काम करता है जब कंट्रोल कनेक्शन क्लियरटेक्स्ट में हो, इसलिए FTP को TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) में रैप करने से वह मिडलबॉक्स अंधा हो जाता है जो FTP को उपयोग करने योग्य बना रहा था।

यह एक वाक्य में FTP का सबक है। इसने नेटवर्क को प्रोटोकॉल का एक भागीदार बना दिया। एक ऐसा प्रोटोकॉल जिसे काम करने के लिए नेटवर्क की समझ की आवश्यकता हो, वह ऐसे नेटवर्क में जीवित नहीं रह सकता जो उस पर भरोसा करना बंद कर दे।

इसका अंत रिकॉर्ड पर है। Firefox ने जुलाई 2021 में संस्करण 90 में FTP सपोर्ट हटा दिया। Chrome ने अक्टूबर 2021 में Chrome 95 में FTP कोड हटा दिया।

rcp और r-commands: hostname पर आधारित भरोसा

1983 में DARPA की फंडिंग से Berkeley द्वारा जारी 4.2BSD, rcp, rsh और rlogin लेकर आया। इन्हें एक ही नेटवर्क पर मौजूद Unix मशीनों के कैंपस के लिए बनाया गया था, और इनका ऑथेंटिकेशन मॉडल यही दर्शाता है। एक होस्ट यह दावा करता था कि कौन सा यूजर कॉल कर रहा है। यदि /etc/hosts.equiv या किसी यूजर की ~/.rhosts फाइल में उस होस्ट को भरोसेमंद बताया गया होता, तो उस दावे को स्वीकार कर लिया जाता था और कोई पासवर्ड नहीं मांगा जाता था।

इस तंत्र को स्पष्ट रूप से समझें, क्योंकि यही कारण है कि ये कमांड्स अब चलन में नहीं हैं। भरोसा एक एड्रेस और एक दावे पर टिका था। दोनों नेटवर्क पर प्लेनटेक्स्ट (cleartext) में यात्रा करते हैं, इसलिए रास्ते में मौजूद कोई भी व्यक्ति उन्हें पढ़ सकता है और कोई भी उन्हें फर्जी तरीके से बना सकता है। वह मॉडल Unix से Linux तक का सफर में वर्णित वातावरण में तर्कसंगत था, जहाँ नेटवर्क केवल एक इमारत तक सीमित था। जिस क्षण नेटवर्क इंटरनेट बना, उस क्षण से यह मॉडल तर्कहीन हो गया।

rcp ने जो सही किया, वह था इसका इंटरफेस। सोर्स, डेस्टिनेशन, काम पूरा। न कोई सेशन खोलने की जरूरत, न ट्रांसफर मोड तय करने की, न ही दूसरा कनेक्शन व्यवस्थित करने की। यह पाथ में कोलन के साथ cp की तरह व्यवहार करता है। वह इंटरफेस अपने प्रोटोकॉल से चार दशक अधिक समय तक जीवित रहा।

SSH ने पूरी श्रेणी को समाहित कर लिया

1995 में Helsinki University of Technology के एक शोधकर्ता Tatu Ylonen ने विश्वविद्यालय के नेटवर्क पर हुए पासवर्ड-स्निफिंग हमले के जवाब में SSH लिखा। उन्होंने जुलाई 1995 में इसे सोर्स कोड के साथ फ्री सॉफ्टवेयर के रूप में जारी किया। उस वर्ष के अंत तक 50 देशों में लगभग 20,000 उपयोगकर्ता होने का अनुमान था, और दिसंबर 1995 में उन्होंने इसके विकास को जारी रखने के लिए SSH Communications Security की स्थापना की।

बाद के संस्करणों के साथ लाइसेंस की शर्तें सख्त हो गईं, इसलिए OpenBSD डेवलपर्स ने अंतिम स्वतंत्र रूप से लाइसेंस प्राप्त संस्करण, ssh 1.2.12 को फोर्क (fork) कर लिया। इसका प्रारंभिक इम्पोर्ट 26 सितंबर 1999 को हुआ था, और OpenSSH 1.2.2 को 1 दिसंबर 1999 को OpenBSD 2.6 के साथ रिलीज किया गया। वह फोर्क ओपन सोर्स लाइसेंसिंग शर्तों के व्यावहारिक महत्व का एक संक्षिप्त केस स्टडी है, क्योंकि आज लगभग हर कोई जिस SSH इम्प्लीमेंटेशन का उपयोग करता है, वह उसी संस्करण से निकला है जिसका लाइसेंस इसकी अनुमति देता था।

एक बार SSH के अस्तित्व में आने के बाद, फाइल ट्रांसफर एक अलग समस्या नहीं रहा। कई चैनलों को ले जाने वाला एक ऑथेंटिकेटेड और एन्क्रिप्टेड स्ट्रीम पहले से ही वह सब प्रदान करता है जिसके लिए पुराने प्रोटोकॉल को खुद व्यवस्था करनी पड़ती थी: इंटीग्रिटी, ऑर्डरिंग, और एक दूसरा डेटा पाथ जिसे किसी दूसरे TCP कनेक्शन की आवश्यकता नहीं होती। यदि ये मैकेनिक्स आपके लिए नए हैं, तो आगे बढ़ने से पहले SSH वास्तव में क्या है, इससे शुरुआत करें।

इससे दो टूल निकले। scp एक SSH सेशन के अंदर चलने वाला rcp का वायर प्रोटोकॉल था, इसीलिए इसने rcp की कमांड लाइन को हूबहू अपना लिया। SFTP एक अलग डिज़ाइन है: यह डायरेक्टरी लिस्टिंग, फाइल एट्रिब्यूट्स और रैंडम एक्सेस के साथ एक वास्तविक फाइल प्रोटोकॉल है, जो SSH चैनल पर चलता है। SFTP कभी RFC नहीं बना। IETF ड्राफ्ट, draft-ietf-secsh-filexfer, 18 जुलाई 2006 को संस्करण 13 तक पहुँचा और फिर समाप्त हो गया। OpenSSH उस ड्राफ्ट के संस्करण 3 को लागू करता है। दुनिया में सबसे व्यापक रूप से उपयोग किया जाने वाला सुरक्षित फाइल ट्रांसफर प्रोटोकॉल एक छोड़े गए ड्राफ्ट का क्रमांकित संशोधन है, और यह काम करता है।

पुराना scp प्रोटोकॉल भी अब रिटायर हो चुका है। 26 सितंबर 2021 को रिलीज हुए OpenSSH 8.8 ने चेतावनी दी थी कि "OpenSSH का निकट भविष्य का रिलीज scp(1) को डिफ़ॉल्ट रूप से पुराने scp/rcp प्रोटोकॉल से SFTP का उपयोग करने पर स्विच कर देगा"। 8 अप्रैल 2022 को रिलीज हुए OpenSSH 9.0 ने ऐसा कर दिया: "यह रिलीज scp(1) को डिफ़ॉल्ट रूप से पुराने scp/rcp प्रोटोकॉल से SFTP प्रोटोकॉल का उपयोग करने पर स्विच करता है।"

इसका कारण एक लोककथा की व्याख्या करता है। पुराना scp प्रोटोकॉल रिमोट फाइलनाम वाइल्डकार्ड को रिमोट शेल को सौंपकर एक्सपैंड करता था, यही कारण है कि लोगों ने रिमोट पाथ में हर मेटाकैरेक्टर को डबल-कोट करना सीखा। 8.8 के नोट्स कहते हैं कि SFTP पर scp को "अब इस तरह की पेचीदा और नाजुक कोटिंग की आवश्यकता नहीं है"। इसलिए एक वर्तमान सर्वर पर, scp rcp की कमांड लाइन पहने हुए एक SFTP क्लाइंट है। 1983 का इंटरफ़ेस जीवित रहा। 1983 का वायर प्रोटोकॉल नहीं।

rsync, 1996: पूरी फाइल के बजाय केवल अंतर भेजें

Andrew Tridgell और Paul Mackerras ने 19 June 1996 को Australian National University में rsync की घोषणा की, जिसके साथ तकनीकी रिपोर्ट TR-CS-96-05, "The rsync algorithm" भी जारी की गई।

इससे पहले का हर प्रोटोकॉल यह पूछता था कि फाइल को बिना खराब किए कैसे भेजा जाए। rsync ने यह पूछा कि फाइल का कितना हिस्सा दूसरी तरफ पहले से मौजूद है। यह रिपोर्ट लक्ष्य को "कम बैंडविड्थ और उच्च लेटेंसी वाला द्वि-दिशात्मक संचार लिंक" मानती है, और इसका उद्देश्य "सोर्स फाइल के उन हिस्सों की पहचान करना है जो डेस्टिनेशन फाइल के किसी हिस्से के समान हैं", ताकि केवल बेमेल (unmatched) हिस्से ही भेजे जाएं।

इसकी कार्यप्रणाली को समझना महत्वपूर्ण है, क्योंकि यह rsync के व्यवहार की व्याख्या करती है। रिसीवर अपनी मौजूदा कॉपी को निश्चित आकार के ब्लॉक्स में काटता है और प्रति ब्लॉक दो चेकसम (checksums) की गणना करता है: एक कमजोर और सस्ता, दूसरा मजबूत और महंगा। वह यह सूची सेंडर को भेजता है। सेंडर अपनी फाइल पर एक विंडो को एक बार में एक बाइट खिसकाता है और कमजोर चेकसम को क्रमिक रूप से अपडेट करता है, जो बाइट-दर-बाइट स्कैन को किफायती बनाता है। कमजोर मैच की पुष्टि मजबूत चेकसम के साथ की जाती है। पुष्टि किए गए मैच ब्लॉक रेफरेंस बन जाते हैं। बाकी सब कुछ लिटरल बाइट्स के रूप में भेजा जाता है। रिसीवर फाइल को उन ब्लॉक्स के रेफरेंस से फिर से बनाता है जो उसके पास पहले से हैं, साथ ही उन लिटरल बाइट्स के साथ जो उसे अभी प्राप्त हुए हैं।

एक बड़ी फाइल की शुरुआत में एक बाइट डालें, तो एक साधारण डिफरेंस टूल को पूरी फाइल भेजनी पड़ेगी, क्योंकि हर ऑफसेट बदल गया है। रोलिंग विंडो उन्हीं ब्लॉक्स को उनके नए ऑफसेट पर ढूंढ लेती है, इसलिए rsync केवल एक बाइट और कुछ बुककीपिंग डेटा भेजता है। यही कारण है कि rsync उस डायरेक्टरी के लिए सही टूल है जिसे आप एक से अधिक बार कॉपी करेंगे।

दो व्यवहार अक्सर लोगों को आश्चर्यचकित करते हैं, और दोनों मैनुअल में दिए गए हैं। पहला, rsync यह तय करने के लिए फाइलों का चेकसम नहीं करता कि उन्हें देखना है या नहीं। यह "डिफ़ॉल्ट रूप से एक 'क्विक चेक' एल्गोरिदम का उपयोग करके उन फाइलों को ढूंढता है जिनका आकार या अंतिम-संशोधन समय बदल गया है"। जिस फाइल की सामग्री बदल गई है लेकिन आकार और टाइमस्टैम्प समान हैं, उसे छोड़ दिया जाता है। --checksum इसे बदल देता है, और दोनों तरफ की हर संभावित फाइल को पूरी तरह से पढ़ने के लिए मजबूर करता है। दूसरा, जब दोनों पाथ लोकल होते हैं तो डेल्टा एल्गोरिदम डिफ़ॉल्ट रूप से बंद रहता है, क्योंकि एक ही मशीन पर दो प्रतियों को पढ़ने और चेकसम करने की लागत बाइट्स को कॉपी करने से अधिक होती है। बचत केवल तभी होती है जब लिंक धीमा हो।

VPS पर आप वास्तव में किन चीजों का उपयोग करते हैं, और क्यों

संक्षेप में: कुछ फाइलों के लिए SFTP, और ऐसी डायरेक्टरी के लिए rsync over SSH जिसका आप दोबारा कॉपी बनाएंगे।

दोनों SSH का उपयोग करते हैं, इसलिए दोनों को बिना किसी अतिरिक्त कॉन्फ़िगरेशन के host key verification और एन्क्रिप्शन का लाभ मिलता है। यह पचास वर्षों के काम का एक डिफ़ॉल्ट रूप में संकुचित परिणाम है। Kermit के डिजाइनरों को यह मानकर चलना पड़ता था कि लाइन डेटा को करप्ट कर देगी, इसलिए उन्होंने प्रोटोकॉल में ही चेकसम और रिट्रांसमिशन को शामिल किया। TCP अब यह काम करता है। Christensen और Forsberg को यह मानकर चलना पड़ता था कि हर बाइट की कीमत चुकानी पड़ती है, इसलिए उन्होंने रिज्यूम और स्ट्रीमिंग की सुविधा बनाई। rsync का डेल्टा एल्गोरिदम अब यह काम बेहतर तरीके से करता है। FTP के लेखकों ने सहयोगी होस्ट के नेटवर्क की कल्पना की थी, और यह उन धारणाओं में से एकमात्र ऐसी धारणा है जो इस तरह से गलत साबित हुई कि प्रोटोकॉल में कोई भी सुधार उसे ठीक नहीं कर सका।

Checksums का वर्तमान महत्व

इतिहास के दौरान "checksum" शब्द ने तीन अलग-अलग भूमिकाएँ निभाई हैं, और ये एक-दूसरे के स्थान पर इस्तेमाल नहीं किए जा सकते।

Kermit और XMODEM के प्रति-पैकेट (per-packet) checksums वायर पर होने वाले डेटा करप्शन (corruption) का पता लगाते थे। आज TCP checksum और लिंक लेयर में मौजूद error correction यह काम करते हैं, इसीलिए कोई भी आधुनिक ट्रांसफर टूल आपसे इसके बारे में सोचने के लिए नहीं कहता।

rsync के ब्लॉक checksums यह जवाब नहीं देते कि "क्या यह डेटा सही है"। वे यह जवाब देते हैं कि "क्या आपके पास यह ब्लॉक पहले से मौजूद है"। वहाँ एक मजबूत checksum एक लुकअप की (lookup key) है, न कि इस बारे में कोई प्रमाण कि फाइल कहाँ से आई है।

तीसरी भूमिका वह है जो अभी भी आपके पास है। किसी रिलीज फाइल पर प्रकाशित checksum उस सवाल का जवाब देता है जिसे TLS नहीं दे सकता। TLS यह साबित करता है कि आपने सही सर्वर से बात की है। यह साबित नहीं करता कि उस सर्वर पर सही फाइल मौजूद थी, और मिरर से ली गई फाइल के लिए यह कुछ नहीं करता। यही कारण है कि रिलीज checksums और signatures अभी भी तीस सेकंड का समय देने योग्य हैं, और यह आदत डालना आसान है: हर डाउनलोड जिसे आप इंस्टॉल करते हैं, उसका checksum चेक करें।

इस कहानी की बाकी सभी समस्याओं का समाधान निचली लेयर द्वारा कर दिया गया है। इसका समाधान नहीं हुआ, क्योंकि यह कभी भी नेटवर्क की समस्या नहीं थी।

FAQ

क्या VPS पर FTP का उपयोग करना अभी भी सुरक्षित है?

नहीं। Plain FTP क्रेडेंशियल्स और फ़ाइल सामग्री को cleartext में भेजता है, इसलिए रास्ते में कोई भी व्यक्ति इन्हें पढ़ सकता है। यह एक ऐसे फायरवॉल पर भी निर्भर करता है जो इसके कंट्रोल चैनल को पार्स करता है, और जैसे ही आप TLS के साथ कंट्रोल चैनल को एन्क्रिप्ट करते हैं, यह संभव नहीं रह जाता। ब्राउज़रों ने पहले ही इसे हटा दिया है: Firefox ने जुलाई 2021 में version 90 में FTP सपोर्ट हटा दिया था, और Chrome ने अक्टूबर 2021 में version 95 में इसका कोड हटा दिया। SSH पर आधारित SFTP का उपयोग करें, जिसके लिए केवल एक पोर्ट की आवश्यकता होती है और किसी protocol-aware middlebox की जरूरत नहीं पड़ती।

FTP को passive mode की आवश्यकता क्यों होती है?

क्योंकि FTP के मूल मोड में सर्वर क्लाइंट के पास वापस डेटा कनेक्शन खोलता है। RFC 959 सर्वर के डिफ़ॉल्ट डेटा पोर्ट को "कंट्रोल कनेक्शन पोर्ट के बगल वाला पोर्ट (अर्थात, L-1)" निर्धारित करता है, इसलिए जब कंट्रोल पोर्ट 21 होता है तो डेटा पोर्ट 20 होता है। NAT (network address translation) के पीछे मौजूद क्लाइंट का कोई ऐसा पता नहीं होता जिस तक सर्वर पहुँच सके, इसलिए वह कनेक्शन कभी नहीं पहुँचता और ट्रांसफर रुक जाता है। PASV दिशा को उलट देता है: सर्वर इसके बजाय listen करता है, और क्लाइंट के कनेक्ट करने के लिए 227 Entering Passive Mode रिप्लाई के अंदर एक पता और पोर्ट प्रदान करता है।

क्या scp अभी भी अपने स्वयं के प्रोटोकॉल का उपयोग करता है?

8 अप्रैल 2022 को जारी OpenSSH 9.0 के बाद से नहीं, जो "scp(1) को legacy scp/rcp प्रोटोकॉल से डिफ़ॉल्ट रूप से SFTP प्रोटोकॉल का उपयोग करने के लिए स्विच करता है"। OpenSSH 8.8 ने सितंबर 2021 में इस बदलाव की घोषणा की थी। दिखने वाला अंतर कोट्स (quoting) का है। पुराना प्रोटोकॉल रिमोट वाइल्डकार्ड्स को रिमोट शेल में पास करके एक्सपैंड करता था, जबकि SFTP-आधारित प्रोटोकॉल ऐसा नहीं करता है, इसलिए जो पाथ उस शेल एक्सपेंशन पर निर्भर थे, वे अब अलग तरह से व्यवहार करते हैं।

VPS के लिए rsync, scp से बेहतर कब होता है?

जब आप एक ही ट्री को एक से अधिक बार कॉपी करेंगे। rsync केवल उन फ़ाइलों के हिस्सों को भेजता है जो डेस्टिनेशन के पास पहले से नहीं हैं, इसलिए दूसरी कॉपी पहली की तुलना में बहुत कम समय और बैंडविड्थ लेती है। ऐसी एकल फ़ाइल के लिए जिसे डेस्टिनेशन ने पहले कभी नहीं देखा है, scp और rsync लगभग समान बाइट्स ट्रांसफर करते हैं और scp अधिक सरल है। याद रखें कि rsync डिफ़ॉल्ट रूप से आकार और मॉडिफिकेशन टाइम के आधार पर यह तय करता है कि क्या देखना है, इसलिए यदि किसी फ़ाइल की सामग्री बदल गई है लेकिन उसका आकार और टाइमस्टैम्प नहीं बदला है, तो rsync द्वारा उसे नोटिस करने से पहले --checksum की आवश्यकता होगी।

Kermit ने फ़ाइलों को raw bytes के बजाय printable text के रूप में एन्कोड क्यों किया?

क्योंकि जिस कनेक्शन को यह टारगेट करता था, वह बाइट पाइप के बजाय मेनफ्रेम के लिए एक टर्मिनल लाइन थी। वे लिंक 7-बिट के हो सकते थे, और मेनफ्रेम का टर्मिनल ड्राइवर कंट्रोल कैरेक्टर्स को पास करने के बजाय उन पर प्रतिक्रिया करता था। Kermit ने कंट्रोल बाइट्स और हाई-बिट बाइट्स को printable कैरेक्टर्स में एन्कोड किया ताकि बीच में कोई भी चीज़ उन पर प्रतिक्रिया न करे। यह एन्कोडिंग बाइनरी फ़ाइलों को वायर पर बड़ा बना देती है, जो कि उस ट्रांसफर के मुकाबले एक सही समझौता था जो अन्यथा करप्ट होकर पहुँचता।