फाईल ट्रान्सफर प्रोटोकॉलचा इतिहास: Kermit ते rsync

फाईल ट्रान्सफर प्रोटोकॉल का बदलत गेले

प्रत्येक फाईल ट्रान्सफर प्रोटोकॉलची रचना त्या दशकातील तांत्रिक त्रुटींवर मात करण्यासाठी करण्यात आली होती. Kermit ने असे गृहीत धरले होते की नेटवर्क लाईन तुमच्या बाईट्समध्ये बिघाड करेल. XMODEM आणि ZMODEM ने असे गृहीत धरले होते की कनेक्शन संथ आहे आणि तुम्हाला प्रत्येक मिनिटासाठी पैसे मोजावे लागतात. FTP (file transfer protocol) ने असे गृहीत धरले होते की मधील नेटवर्क सहकार्य करणारे आहे. SSH ने असे गृहीत धरले की ते प्रतिकूल आहे. हे शेवटचे गृहीतक यशस्वी ठरले, म्हणूनच आजचा VPS तुम्हाला SFTP आणि rsync over SSH व्यतिरिक्त फारसे काही देत नाही.

याकडे आता पाहण्याचे एक कारण आहे. C-Kermit 11.0.506 हे 3 ऑगस्ट 2026 रोजी रिलीज झाले. 20 ऑगस्ट 2011 रोजी आलेल्या C-Kermit 9.0.302 नंतरची ही पहिली नॉन-बीटा रिलीज आहे आणि तो जो प्रोटोकॉल कार्यान्वित करतो, त्याची रचना मे 1981 मध्ये करण्यात आली होती. पंचेचाळीस वर्षे हा काळ एका संपूर्ण श्रेणीचा शोध लागण्यासाठी, ती प्रमाणित होण्यासाठी, ती ज्या नेटवर्कवर चालत होती त्याद्वारे ती निकामी होण्यासाठी आणि शेवटी SSH मध्ये विलीन होण्यासाठी पुरेसा मोठा आहे.

Kermit, 1981: बाइट्स खाणाऱ्या लाईनसाठी डिझाइन

Kermit ची निर्मिती मे 1981 मध्ये कोलंबिया युनिव्हर्सिटी कॉम्प्युटर सेंटरमध्ये Frank da Cruz आणि Bill Catchings यांनी केली होती. याचे नाव 'Kermit the Frog' वरून आले आहे. Da Cruz यांच्या मते, जेव्हा गट नावाचा विचार करत होता तेव्हा भिंतीवर Muppets चे कॅलेंडर होते आणि हे तंत्रज्ञान इतके पसरेल अशी कोणालाही अपेक्षा नव्हती.

Kermit ने सोडवलेली समस्या वेग वाढवण्याची नव्हती. टर्मिनल आणि मेनफ्रेममधील मार्ग हा कोणत्याही बाइट्ससाठी पाइप नव्हता. ते एक विशिष्ट गुणधर्म असलेले कॅरेक्टर डिव्हाइस होते. ते 7-bit असू शकत होते. ते हाफ-डुप्लेक्स असू शकत होते. ते कंट्रोल कॅरेक्टर्स गिळू शकत होते किंवा त्यातील एकाला कमांड म्हणून वागवू शकत होते. त्यातून बायनरी फाईल जशीच्या तशी पाठवणे शक्य नव्हते.

त्यामुळे डिझाइनने या मर्यादांचा अक्षरशः विचार केला. The Kermit Project च्या स्वतःच्या इतिहासामध्ये त्यांची यादी दिली आहे:

• लहान पॅकेट्स, कारण बहुतेक मेनफ्रेम टर्मिनलवरून येणारा डेटाचा मोठा प्रवाह स्वीकारू शकत नव्हते.
• हाफ-डुप्लेक्स स्टॉप-अँड-वेट, कारण IBM मेनफ्रेम फुल-डुप्लेक्स कम्युनिकेशनला सपोर्ट करत नव्हते.
• कंट्रोल कॅरेक्टर्स आणि 8-bit कॅरेक्टर्ससाठी प्रिंट करण्यायोग्य एन्कोडिंग, कारण यापैकी काहीही मेनफ्रेमच्या टर्मिनल ड्रायव्हरमधून जाऊ शकत नव्हते.
• प्रत्येक पॅकेटवर चेकसम, ज्याला रिसीव्हरकडून उत्तर दिले जाते, जेणेकरून खराब झालेल्या पॅकेटमुळे संपूर्ण फाईलऐवजी फक्त एकच रिट्रान्समिशन करावे लागेल.

तिसरा मुद्दा मनोरंजक आहे. Kermit फाईल पाठवण्याऐवजी तुमच्या फाईलचे टेक्स्ट-सेफ एन्कोडिंग पाठवते. एक कंट्रोल बाइट हे प्रीफिक्स कॅरेक्टर आणि त्यानंतर प्रिंट करण्यायोग्य कॅरेक्टर बनते, आणि हाय-बिट सेट असलेला बाइट 7-bit लिंकसाठी त्याच प्रकारे एन्कोड केला जाऊ शकतो. मधल्या ज्या यंत्रणेला फक्त प्रिंट करण्यायोग्य मजकूर समजतो, तिला फक्त तोच मजकूर दिसतो. याची किंमत म्हणजे आकार: बायनरी फाईल वायरवर मोठी होते. मेनफ्रेम फ्रंट-एंड जे अन्यथा ट्रान्सफर पूर्णपणे खराब करू शकले असते, त्या तुलनेत हा योग्य व्यवहार होता.

Kermit चा दुसरा असामान्य गुणधर्म म्हणजे त्याची व्याप्ती. XMODEM ने अशा दोन मशीनमध्ये फाईल हलवली ज्यांनी फाईल म्हणजे काय यावर आधीच सहमती दर्शवली होती. Kermit हे अशा प्रणालींमधील सर्वात कमी सामाईक दुवा (least common denominator) म्हणून लिहिले गेले होते ज्यांची एकमेकांशी सहमती नव्हती; ज्यांचे कॅरेक्टर सेट्स, रेकॉर्ड स्ट्रक्चर्स आणि मजकुराची ओळ कशाने संपते याबद्दलचे विचार वेगळे होते. मेनफ्रेमपासून क्लाउड सर्व्हरपर्यंतचा प्रदीर्घ प्रवास मध्ये हेच जग वर्णन केले आहे आणि नेटवर्क लेयरने तुमच्यासाठी काम करण्यापूर्वी इंटरऑपरेबिलिटी कशी दिसत असे, याचे उदाहरण म्हणजे Kermit.

कोलंबियाने 2011 मध्ये आपले प्रायोजकत्व संपवले आणि C-Kermit ला सुधारित 3-clause BSD लायसन्स अंतर्गत रिलीज केले. Frank da Cruz 1981 च्या डिझाइनपासून ते 2025 पर्यंत, 44 वर्षे या प्रकल्पाशी जोडलेले राहिले. 2026 चे रिलीज OpenKermit प्रकल्पाद्वारे मेंटेन केले जाते, ज्यामध्ये John Goerzen हे सध्या वाचणाऱ्या बहुतेक लोकांपेक्षा जुन्या असलेल्या C कोडबेसचे आधुनिकीकरण करण्याचे काम करत आहेत.

XMODEM आणि ZMODEM: जेव्हा फोन बिल डिझाइन ठरवत असे

Ward Christensen यांनी 1977 मध्ये MODEM.ASM लिहिले आणि त्यांनी सादर केलेल्या प्रोटोकॉलला XMODEM असे म्हणतात. 1978 मध्ये त्यांनी आणि Randy Suess यांनी CBBS ऑनलाइन आणले, जे पहिले सार्वजनिक बुलेटिन बोर्ड सिस्टम होते. Christensen यांचे 11 ऑक्टोबर 2024 रोजी निधन झाले.

XMODEM हा शक्य तितक्या लहान प्रोटोकॉलपैकी एक आहे. डेटा 128-बाइटच्या ब्लॉक्समध्ये हलतो. प्रत्येक ब्लॉक एक-बाइट चेकसम वाहून नेतो, जो 128 डेटा बाइट्सची बेरीज modulo 256 असतो. रिसीव्हर प्रत्येक ब्लॉकची पोचपावती देतो किंवा तो पुन्हा पाठवण्यास सांगतो. या रचनेचे कारण आर्थिक आहे. डायल-अप लाइनवर तुम्ही वेळेसाठी पैसे देता, त्यामुळे लाइनमधील त्रुटीमुळे संपूर्ण ट्रान्सफरऐवजी फक्त एक ब्लॉक वाया जावा, हा त्यामागचा उद्देश होता.

याची कमजोरी याच वाक्यात दडलेली आहे. XMODEM प्रत्येक 128 बाइट्सनंतर पोचपावतीची वाट पाहतो. Chuck Forsberg यांनी ZMODEM स्पेसिफिकेशनमध्ये हे स्पष्टपणे मांडले आहे: "जेव्हा टाइमशेअरिंग सिस्टम, पॅकेट स्विच्ड नेटवर्क किंवा सॅटेलाइट सर्किट्सवर वापरले जाते, तेव्हा लहान ब्लॉक लांबीमुळे थ्रूपुटवर परिणाम होतो." स्टॉप-अँड-वेट पद्धतीला बँडविड्थ नाही, तर लॅटन्सी (latency) मारते. प्रत्येक राउंड ट्रिप म्हणजे अशा लाइनवर वाया गेलेला वेळ आहे, ज्यासाठी तुम्ही पैसे मोजत आहात.

त्यानंतर YMODEM आले आणि Ward Christensen यांनी 1985 मध्ये हे नाव दिले. त्याचे योगदान म्हणजे बॅच ट्रान्सफर. सेंडर डेटाच्या आधी फाइलचे नाव आणि आकार सांगतो, जेणेकरून एकाच सत्रात अनेक फाइल्स हलवता येतात आणि रिसीव्हरला प्रत्येक फाइल कुठे संपते हे समजते.

ZMODEM हे Chuck Forsberg यांचे उत्तर आहे, जे Omen Technology मध्ये लिहिण्यात आले. याचे स्पेसिफिकेशन 14 ऑक्टोबर 1988 चे आहे आणि त्यात नमूद केले आहे की "ZMODEM हे Telenet करारांतर्गत पब्लिक डोमेनसाठी विकसित केले गेले होते". Telenet एक सार्वजनिक पॅकेट-स्विच्ड डेटा नेटवर्क चालवत असे आणि तो करार डिझाइनमध्ये दिसून येतो. ZMODEM नेटवर्क कंट्रोल कॅरेक्टर्सना एस्केप (escape) करते, जेणेकरून मधील पॅकेट नेटवर्क त्यांना वापरून घेणार नाही. हे प्रत्येक फ्रेमची सुरुवात एका युनिक कॅरेक्टर सीक्वेन्सने चिन्हांकित करते, त्याऐवजी शांततेवरून फ्रेमच्या सीमांचा अंदाज घेत नाही; त्यामुळे टाइमआउटची वाट न पाहता ते नॉइजमधून सावरते. यात स्पष्टपणे 'रिझ्युम' (resume) करण्याची सोय आहे, त्यामुळे खंडित झालेले ट्रान्सफर जिथे थांबले होते तिथून पुन्हा सुरू होते.

सर्वात महत्त्वाचे म्हणजे, हे वाट पाहणे थांबवते. स्पेसिफिकेशनचे स्वतःचे वर्णन असे आहे की "ZMODEM प्रत्यक्षात संपूर्ण फाइलला एक विंडो म्हणून वापरते". सेंडर डेटा स्ट्रीम करतो आणि जेव्हा रिसीव्हर समस्येची नोंद करतो तेव्हाच थांबतो. ही तीच समज आहे जी TCP आपल्या विंडोमध्ये वापरते, जी दुसऱ्या बाजूने, मोडेमला रिकामे बसलेले पाहणाऱ्या व्यक्तीने मिळवली होती.

FTP चे दोन कनेक्शन का कालबाह्य ठरले

FTP हे या सर्वांपेक्षा जुने आहे. RFC 114, "A File Transfer Protocol", 16 एप्रिल 1971 रोजी A. Bhushan यांनी लिहिले होते.

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

RFC 959 ने पोर्ट्स देखील निश्चित केले. सर्व्हरचा डीफॉल्ट डेटा पोर्ट हा "कंट्रोल कनेक्शन पोर्टच्या लगतचा पोर्ट (म्हणजेच L-1)" असतो, जो कंट्रोल कनेक्शन पोर्ट 21 असताना पोर्ट 20 असतो.

येथे तो भाग आहे जो टिकला नाही. FTP च्या मूळ मोडमध्ये सर्व्हर क्लायंटकडे डेटा कनेक्शन परत सुरू करतो. NAT (network address translation) च्या मागे असलेल्या क्लायंटकडे सर्व्हर पोहोचू शकत नाही आणि फायरवॉलच्या मागे असलेला क्लायंट इनबाउंड कनेक्शन स्वीकारत नाही. त्यामुळे डेटा कनेक्शन कधीच पोहोचत नाही आणि फाइल लिस्टिंग किंवा फाइलची विनंती केल्यावर ट्रान्सफर हँग होते. याचे उत्तर PASV होते, ज्याची व्याख्या RFC 959 मध्ये अशी केली आहे की सर्व्हरने "डेटा पोर्टवर (जो त्याचा डीफॉल्ट डेटा पोर्ट नाही) 'लिसेन' करावे आणि ट्रान्सफर कमांड मिळाल्यावर कनेक्शन सुरू करण्याऐवजी कनेक्शनची वाट पाहावी". सर्व्हर कनेक्ट करण्यासाठी पत्ता आणि पोर्टसह उत्तर देतो:

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

या उत्तराचा अर्थ असा की होस्ट 203.0.113.10, पोर्ट 195 गुणिले 256 अधिक 80, म्हणजेच 50000. हे पुन्हा वाचल्यास त्यातील संरचनात्मक समस्या स्पष्ट होते. दुसऱ्या कनेक्शनचा एंडपॉईंट पहिल्या कनेक्शनच्या पेलोडमध्ये घोषित केला जातो. NAT बॉक्स किंवा फायरवॉल तोपर्यंत ते कनेक्शन पास करू शकत नाही जोपर्यंत तो कंट्रोल चॅनेल पार्स करत नाही आणि तिथे दिसणारा पोर्ट उघडत नाही. Linux मध्ये एक कनेक्शन ट्रॅकिंग हेल्पर असतो जो नेमके हेच काम करतो. हा हेल्पर फक्त तेव्हाच काम करतो जेव्हा कंट्रोल कनेक्शन प्लेनटेक्स्टमध्ये असते, त्यामुळे FTP ला TLS (transport layer security) मध्ये गुंडाळल्यास मधल्या उपकरणाला (middlebox) ते दिसत नाही, ज्यामुळे FTP वापरण्यायोग्य राहत नाही.

FTP चा धडा एका वाक्यात सांगायचा तर: त्याने नेटवर्कला प्रोटोकॉलचा एक भाग बनवले. ज्या प्रोटोकॉलला नेटवर्कने समजून घेणे आवश्यक असते, तो प्रोटोकॉल अशा नेटवर्कमध्ये टिकू शकत नाही जे त्यावर विश्वास ठेवणे थांबवते.

याचा शेवट अधिकृत आहे. Firefox ने जुलै 2021 मध्ये आवृत्ती 90 मध्ये FTP सपोर्ट काढून टाकला. Chrome ने ऑक्टोबर 2021 मध्ये Chrome 95 मध्ये FTP कोड काढून टाकला.

rcp आणि r-commands: होस्टनेमवर आधारित विश्वास

1983 मध्ये DARPA च्या निधीतून बर्कलेने रिलीज केलेल्या 4.2BSD ने rcp, rsh आणि rlogin ही साधने आणली. ही साधने एकाच नेटवर्कवरील Unix मशीनच्या कॅम्पससाठी तयार करण्यात आली होती आणि त्यांची ऑथेंटिकेशन मॉडेल हेच दर्शवते. एखादा होस्ट कोणता वापरकर्ता कॉल करत आहे हे सांगायचा. जर /etc/hosts.equiv किंवा वापरकर्त्याच्या ~/.rhosts मध्ये तो होस्ट 'trusted' (विश्वासार्ह) म्हणून नमूद असेल, तर तो दावा स्वीकारला जाई आणि पासवर्ड विचारला जात नसे.

या यंत्रणेचे स्वरूप स्पष्टपणे समजून घेणे आवश्यक आहे, कारण याच कारणामुळे ही कमांड्स आता कालबाह्य झाली आहेत. हा विश्वास एका पत्त्यावर आणि दाव्यावर आधारित होता. हे दोन्ही घटक नेटवर्कवरून 'cleartext' मध्ये प्रवास करतात, त्यामुळे मार्गातील कोणीही ते वाचू शकतो आणि कोणीही ते बनावट (forge) करू शकतो. Unix ते Linux चा प्रवास मध्ये वर्णन केलेल्या वातावरणात हे मॉडेल तर्कसंगत होते, कारण तेव्हा नेटवर्क म्हणजे केवळ एक इमारत होती. ज्या क्षणी नेटवर्क म्हणजे इंटरनेट बनले, त्या क्षणी हे मॉडेल निरर्थक ठरले.

rcp ने एक गोष्ट योग्य केली होती, ती म्हणजे त्याचा इंटरफेस. सोर्स, डेस्टिनेशन आणि काम पूर्ण. कोणतेही सेशन उघडण्याची गरज नाही, ट्रान्सफर मोड ठरवण्याची गरज नाही, किंवा दुसरे कनेक्शन जुळवण्याची गरज नाही. हे अगदी cp प्रमाणे काम करते, फक्त पाथमध्ये एक कोलन (colon) वापरावा लागतो. हा इंटरफेस त्याच्या प्रोटोकॉलपेक्षाही चार दशके जास्त काळ टिकला आहे.

SSH ने संपूर्ण श्रेणी व्यापली आहे

1995 मध्ये हेलसिंकी युनिव्हर्सिटी ऑफ टेक्नॉलॉजीचे संशोधक Tatu Ylonen यांनी विद्यापीठाच्या नेटवर्कवर झालेल्या पासवर्ड-स्निफिंग हल्ल्याला उत्तर म्हणून SSH विकसित केले. जुलै 1995 मध्ये त्यांनी हे सॉफ्टवेअर सोर्स कोडसह मुक्त सॉफ्टवेअर म्हणून प्रसिद्ध केले. त्या वर्षाच्या अखेरीस 50 देशांतील सुमारे 20,000 वापरकर्ते याचा वापर करत होते आणि डिसेंबर 1995 मध्ये त्यांनी याचा विकास सुरू ठेवण्यासाठी SSH Communications Security ही कंपनी स्थापन केली.

पुढील आवृत्त्यांमध्ये परवाना अटी कडक झाल्यामुळे, OpenBSD डेव्हलपर्सनी शेवटची मुक्त परवाना असलेली आवृत्ती, ssh 1.2.12, फोर्क केली. 26 सप्टेंबर 1999 रोजी याचे सुरुवातीचे इम्पोर्ट झाले आणि 1 डिसेंबर 1999 रोजी OpenBSD 2.6 सोबत OpenSSH 1.2.2 रिलीज झाले. हे फोर्क ओपन सोर्स परवाना अटी प्रत्यक्ष व्यवहारात का महत्त्वाच्या आहेत याचे एक उत्तम उदाहरण आहे, कारण आज जवळजवळ प्रत्येकजण जी SSH अंमलबजावणी वापरतो, ती त्याच एका आवृत्तीपासून विकसित झाली आहे ज्याचा परवाना अजूनही त्याला परवानगी देत होता.

एकदा SSH अस्तित्वात आल्यावर, फाइल ट्रान्सफर ही एक वेगळी समस्या राहिली नाही. एकाधिक चॅनेल वाहून नेणारा एक ऑथेंटिकेटेड आणि एनक्रिप्टेड प्रवाह जुन्या प्रोटोकॉलना स्वतःहून निर्माण कराव्या लागणाऱ्या गोष्टी आधीच प्रदान करतो: अखंडता (integrity), क्रमवारी (ordering) आणि दुसरा डेटा मार्ग ज्यासाठी दुसऱ्या 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 जून 1996 रोजी ऑस्ट्रेलियन नॅशनल युनिव्हर्सिटीमध्ये rsync ची घोषणा केली. त्यासोबतच "The rsync algorithm" हा तांत्रिक अहवाल TR-CS-96-05 देखील प्रकाशित केला.

यापूर्वीचे प्रत्येक प्रोटोकॉल फाईल न बिघडवता कशी हलवायची, याचा विचार करत होते. rsync ने असा प्रश्न विचारला की, समोरच्या बाजूकडे या फाईलचा किती भाग आधीच उपलब्ध आहे? हा अहवाल लक्ष्याला "कमी बँडविड्थ आणि जास्त लॅटन्सी असलेला द्विमार्गी दळणवळण दुवा" (low-bandwidth high-latency bi-directional communications link) म्हणून मांडतो. याचे ध्येय "मूळ फाईलमधील असे भाग शोधणे जे डेस्टिनेशन फाईलमधील भागांशी तंतोतंत जुळतात" हे आहे, जेणेकरून फक्त न जुळणारे भागच पाठवले जातील.

याची कार्यपद्धती समजून घेणे महत्त्वाचे आहे, कारण ती rsync चे वर्तन स्पष्ट करते. रिसीव्हर त्याच्याकडे असलेल्या फाईलच्या प्रतीचे ठराविक आकाराचे ब्लॉक्स करतो आणि प्रत्येक ब्लॉकसाठी दोन चेकसम (checksums) मोजतो; एक कमकुवत आणि स्वस्त, तर दुसरा मजबूत आणि महाग. तो ही यादी सेंडरला पाठवतो. सेंडर स्वतःच्या फाईलवर एक विंडो एका वेळी एक बाइट सरकवत नेतो आणि कमकुवत चेकसम टप्प्याटप्प्याने अपडेट करतो. यामुळेच बाइट-बाय-बाइट स्कॅन करणे परवडणारे ठरते. कमकुवत मॅच मिळाल्यावर ती मजबूत चेकसमद्वारे पडताळली जाते. पडताळलेले मॅचेस ब्लॉक रेफरन्स बनतात. बाकी सर्व काही लिटरल्स (literal bytes) म्हणून पाठवले जाते. रिसीव्हर आधीच असलेल्या ब्लॉक्सचे रेफरन्स आणि नुकतेच मिळालेले लिटरल्स वापरून फाईल पुन्हा तयार करतो.

एखाद्या मोठ्या फाईलच्या सुरुवातीला एक बाइट जोडल्यास, साधे डिफरन्स टूल पूर्ण फाईल पाठवेल, कारण प्रत्येक ऑफसेट बदललेला असतो. रोलिंग विंडो मात्र त्याच ब्लॉक्सना त्यांच्या नवीन ऑफसेटवर शोधून काढते, त्यामुळे rsync फक्त तो एक बाइट आणि काही अतिरिक्त माहिती पाठवते. याच गुणामुळे, ज्या डिरेक्टरीची तुम्ही एकापेक्षा जास्त वेळा कॉपी करणार आहात, त्यासाठी rsync हेच योग्य साधन आहे.

दोन प्रकारची वर्तने वापरकर्त्यांना नेहमी आश्चर्यचकित करतात आणि दोन्ही मॅन्युअलमध्ये दिलेली आहेत. पहिले म्हणजे, rsync फाईल्स तपासाव्यात की नाही हे ठरवण्यासाठी त्यांचा चेकसम काढत नाही. ते "डिफॉल्टनुसार 'quick check' अल्गोरिदम वापरून अशा फाईल्स शोधते ज्यांचा आकार किंवा शेवटचा बदलल्याचा वेळ (last-modified time) बदलला आहे". ज्या फाईलची सामग्री बदलली आहे पण आकार आणि टाइमस्टॅम्प सारखेच आहेत, ती फाईल वगळली जाते. --checksum हे वर्तन बदलते आणि दोन्ही बाजूंना प्रत्येक संभाव्य फाईल पूर्णपणे वाचण्यास भाग पाडते. दुसरे म्हणजे, जेव्हा दोन्ही पाथ (paths) स्थानिक असतात, तेव्हा डेल्टा अल्गोरिदम डिफॉल्टनुसार बंद असतो. कारण एकाच मशीनवर दोन प्रती वाचणे आणि त्यांचा चेकसम काढणे हे थेट बाइट्स कॉपी करण्यापेक्षा जास्त खर्चिक असते. जेव्हा नेटवर्क दुवा संथ असतो, तेव्हाच या बचतीचा फायदा होतो.

VPS वर तुम्ही प्रत्यक्षात कशाचा वापर करता आणि का

थोडक्यात सांगायचे तर: काही मोजक्या फाइल्ससाठी SFTP, आणि पुन्हा पुन्हा कॉपी करायच्या डिरेक्टरीसाठी SSH वरून rsync वापरा.

दोन्ही SSH चा वापर करतात, त्यामुळे कोणत्याही अतिरिक्त कॉन्फिगरेशनशिवाय त्यांना host key verification आणि encryption आपोआप मिळते. हे पन्नास वर्षांच्या कामाचे फलित आहे जे डीफॉल्ट स्वरूपात उपलब्ध आहे. Kermit च्या डिझाइनर्सना असे गृहीत धरावे लागले होते की नेटवर्क लाइन डेटा करप्ट करेल, म्हणून त्यांनी प्रोटोकॉलमध्येच checksums आणि retransmission ची सोय केली होती. आता TCP हे काम करते. Christensen आणि Forsberg यांना प्रत्येक बाइटसाठी पैसे मोजावे लागतील असे गृहीत धरावे लागले होते, म्हणून त्यांनी resume आणि streaming ची सुविधा तयार केली. आता rsync चे delta algorithm हे काम अधिक चांगल्या प्रकारे करते. FTP च्या लेखकांनी असे गृहीत धरले होते की नेटवर्कवरील सर्व होस्ट एकमेकांना सहकार्य करतील, आणि हे एकमेव गृहीतक चुकीचे ठरले आहे, ज्याची दुरुस्ती कोणत्याही प्रोटोकॉलच्या सुधारणेने होऊ शकत नाही.

चेकसम्स (checksums) आजही का उपयुक्त आहेत

इतिहासात "checksum" या शब्दाने तीन भिन्न कामे केली आहेत आणि ती एकमेकांना बदलून वापरता येत नाहीत.

Kermit आणि XMODEM चे प्रति-पॅकेट (per-packet) चेकसम्स वायरवरील डेटा करप्शन शोधत असत. आज TCP चेकसम आणि लिंक लेयरमधील एरर करेक्शन हे काम करतात, म्हणूनच कोणतेही आधुनिक ट्रान्सफर टूल तुम्हाला त्याबद्दल विचार करायला सांगत नाही.

rsync चे ब्लॉक चेकसम्स "हा डेटा बरोबर आहे का" याचे उत्तर देत नाहीत. ते "तुमच्याकडे हा ब्लॉक आधीच आहे का" याचे उत्तर देतात. तिथे एक मजबूत चेकसम ही एक लूकअप की (lookup key) असते, फाईल कुठून आली आहे याचे ते प्रमाणपत्र नसते.

तिसरे काम अजूनही तुमच्याकडेच शिल्लक आहे. रिलीज फाईलवर प्रकाशित केलेला चेकसम अशा प्रश्नाचे उत्तर देतो जे TLS देऊ शकत नाही. TLS हे सिद्ध करते की तुम्ही योग्य सर्व्हरशी संवाद साधला आहे. ते सर्व्हरवर योग्य फाईलच होती हे सिद्ध करत नाही आणि मिररवरून घेतलेल्या फाईलसाठी ते काहीही करत नाही. म्हणूनच रिलीज चेकसम्स आणि सिग्नेचर्ससाठी 30 सेकंद देणे आजही फायदेशीर आहे आणि ही सवय लावणे सोपे आहे: तुम्ही इन्स्टॉल करत असलेल्या प्रत्येक डाउनलोडचा चेकसम तपासा.

या कथेतील इतर सर्व गोष्टी खालच्या लेयरद्वारे सोडवल्या गेल्या आहेत. हे एक काम मात्र सुटले नाही, कारण ती कधीही नेटवर्कची समस्या नव्हतीच.

FAQ

VPS वर FTP वापरणे अजूनही सुरक्षित आहे का?

नाही. साधे FTP क्रेडेंशियल्स आणि फाईलची सामग्री 'प्लेन टेक्स्ट' (cleartext) स्वरूपात पाठवते, त्यामुळे मार्गातील कोणीही ते वाचू शकते. हे एका अशा फायरवॉलवर अवलंबून असते जी त्याचे कंट्रोल चॅनेल पार्स करते, आणि जेव्हा तुम्ही TLS वापरून कंट्रोल चॅनेल एनक्रिप्ट करता, तेव्हा हे शक्य राहत नाही. ब्राउझर्सनी आधीच याचा वापर बंद केला आहे: Firefox ने जुलै 2021 मध्ये व्हर्जन 90 मध्ये FTP सपोर्ट काढून टाकला, आणि Chrome ने ऑक्टोबर 2021 मध्ये व्हर्जन 95 मध्ये त्याचा कोड काढून टाकला. त्याऐवजी SSH वर आधारित SFTP वापरा, ज्याला फक्त एका पोर्टची गरज असते आणि कोणत्याही प्रोटोकॉल-अवेअर मिडलबॉक्सची आवश्यकता नसते.

FTP ला पॅसिव्ह मोडची गरज का असते?

कारण 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) ला लेगसी scp/rcp प्रोटोकॉलवरून डीफॉल्टनुसार SFTP प्रोटोकॉलवर बदलले आहे". OpenSSH 8.8 ने सप्टेंबर 2021 मध्ये या बदलाची घोषणा केली होती. यात दिसणारा फरक म्हणजे कोटिंग (quoting). जुना प्रोटोकॉल रिमोट वाइल्डकार्ड्सना रिमोट शेलकडे पाठवून एक्सपँड करायचा, तर SFTP-आधारित प्रोटोकॉल तसे करत नाही. त्यामुळे ज्या पाथ्सना त्या शेल एक्सपान्शनवर अवलंबून राहावे लागायचे, ते आता वेगळ्या प्रकारे वागतात.

VPS साठी scp पेक्षा rsync कधी चांगले असते?

जेव्हा तुम्हाला एकच ट्री (directory tree) एकापेक्षा जास्त वेळा कॉपी करायची असते. rsync फक्त त्या फाईल्सचे भाग पाठवते जे डेस्टिनेशनकडे आधीपासून नाहीत, त्यामुळे दुसरी कॉपी पहिल्या कॉपीपेक्षा खूप जलद होते. ज्या फाईलची डेस्टिनेशनला माहिती नाही अशा एकाच फाईलसाठी, scp आणि rsync साधारणपणे सारखेच बाइट्स हलवतात आणि scp वापरणे सोपे असते. लक्षात ठेवा की rsync डीफॉल्टनुसार फाईलचा आकार आणि बदलण्याची वेळ (modification time) पाहून निर्णय घेते, त्यामुळे जर एखाद्या फाईलची सामग्री बदलली असेल पण तिचा आकार आणि टाइमस्टॅम्प बदलला नसेल, तर rsync ला ती समजण्यासाठी --checksum ची गरज पडते.

Kermit ने फाईल्सना रॉ बाइट्स म्हणून पाठवण्याऐवजी प्रिंट करण्यायोग्य टेक्स्ट (printable text) म्हणून एनकोड का केले?

कारण ते ज्या कनेक्शनला लक्ष्य करत होते ती एक 'बाइट पाईप' नसून मेनफ्रेममधील 'टर्मिनल लाईन' होती. ते दुवे 7-बिट असू शकत होते आणि मेनफ्रेमचा टर्मिनल ड्रायव्हर कंट्रोल कॅरेक्टर्सना पास करण्याऐवजी त्यावर प्रक्रिया करायचा. Kermit ने कंट्रोल बाइट्स आणि हाय-बिट बाइट्सना प्रिंट करण्यायोग्य कॅरेक्टर्समध्ये एनकोड केले जेणेकरून मधल्या कोणत्याही गोष्टीने त्यावर प्रतिक्रिया देऊ नये. या एनकोडिंगमुळे बायनरी फाईल्स वायरवर मोठ्या होतात, परंतु ट्रान्सफर करप्ट होण्यापेक्षा हा एक योग्य पर्याय होता.