கோப்பு பரிமாற்ற நெறிமுறைகள்: Kermit முதல் rsync வரை

கோப்பு பரிமாற்ற நெறிமுறைகள் ஏன் தொடர்ந்து மாறின

ஒவ்வொரு கோப்பு பரிமாற்ற நெறிமுறையும் அந்தந்த தசாப்தத்தில் நிலவிய தோல்வி முறைகளை எதிர்கொள்ளும் வகையில் வடிவமைக்கப்பட்டன. 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 பதிப்பிற்குப் பிறகு, இதுவே முதல் non-beta வெளியீடாகும். இது செயல்படுத்தும் நெறிமுறை May 1981-ல் வடிவமைக்கப்பட்டது. நாற்பத்தைந்து ஆண்டுகள் என்பது ஒரு தொழில்நுட்ப வகை உருவாக்கப்பட்டு, தரப்படுத்தப்பட்டு, அது இயங்கிய நெட்வொர்க்கால் செயலிழக்கச் செய்யப்பட்டு, இறுதியில் SSH-க்குள் உள்வாங்கப்படுவதைக் காண போதுமான காலமாகும்.

Kermit, 1981: பைட்டுகளை விழுங்கும் இணைப்பிற்காக வடிவமைக்கப்பட்டது

Kermit, 1981-ம் ஆண்டு மே மாதம் Columbia University Computer Center-ல் Frank da Cruz மற்றும் Bill Catchings ஆகியோரால் உருவாக்கப்பட்டது. Kermit the Frog என்ற கதாபாத்திரத்தின் பெயரே இதற்கும் சூட்டப்பட்டது. குழுவினர் பெயருக்காக யோசித்துக் கொண்டிருந்தபோது சுவரில் இருந்த Muppets காலண்டரைப் பார்த்து இப்பெயரை வைத்ததாகவும், இது இவ்வளவு தூரம் பரவும் என்று யாரும் எதிர்பார்க்கவில்லை என்றும் Da Cruz குறிப்பிடுகிறார்.

Kermit தீர்த்த சிக்கல் வேகம் சார்ந்தது அல்ல. ஒரு terminal-க்கும் mainframe-க்கும் இடையிலான பாதை தன்னிச்சையான பைட்டுகளை (arbitrary bytes) அனுப்பும் குழாய் அல்ல. அது சில கட்டுப்பாடுகளைக் கொண்ட ஒரு character device. அது 7-bit ஆக இருக்கலாம். அது half duplex ஆக இருக்கலாம். அது control characters-ஐ விழுங்கலாம் அல்லது அவற்றில் ஒன்றை கட்டளையாகச் செயல்படுத்தலாம். ஒரு binary file-ஐ மாற்றமின்றி அதன் வழியாக அனுப்பினால் அது வேலை செய்யாது.

எனவே, இந்த வடிவமைப்பானது அந்த கட்டுப்பாடுகளை அப்படியே ஏற்றுக்கொண்டது. The Kermit Project-ன் வரலாற்றில் அவை பட்டியலிடப்பட்டுள்ளன:

• சிறிய packets: பெரும்பாலான mainframes, terminal-லிருந்து வரும் நீண்ட தரவுத் தொகுதிகளை ஏற்க முடியாது.
• half-duplex stop-and-wait: IBM mainframes full-duplex தொடர்பை ஆதரிக்கவில்லை.
• control characters மற்றும் 8-bit characters-க்கான printable encodings: இவை mainframe-ன் terminal driver வழியாகச் செல்ல முடியாது.
• ஒவ்வொரு packet-க்கும் ஒரு checksum: இதைப் பெறுபவர் உறுதிப்படுத்த வேண்டும், இதனால் சிதைந்த packet-க்கு முழு கோப்பையும் மீண்டும் அனுப்ப வேண்டியதில்லை, அந்த ஒரு packet-ஐ மட்டும் மீண்டும் அனுப்பினால் போதும்.

மூன்றாவது அம்சம் மிகவும் முக்கியமானது. Kermit கோப்பை அப்படியே அனுப்பாமல், text-safe encoding முறையில் அனுப்புகிறது. ஒரு control byte, ஒரு prefix character மற்றும் அதைத் தொடர்ந்து ஒரு printable character என மாற்றப்படுகிறது. 7-bit இணைப்பிற்காக, high bit set செய்யப்பட்ட ஒரு byte-ம் இதேபோல் encode செய்யப்படலாம். இடையில் உள்ள எந்தவொரு அமைப்பும் printable text-ஐ மட்டுமே புரிந்துகொள்ளும் என்பதால், அதற்கு இது வெறும் text-ஆகவே தெரியும். இதற்கான விலை கோப்பின் அளவு அதிகரிப்பதுதான்: ஒரு binary file அனுப்பப்படும்போது அதன் அளவு கூடுகிறது. தரவு பரிமாற்றத்தை முழுமையாகச் சிதைக்கும் mainframe front end-க்கு எதிராக, இது சரியான சமரசமாக இருந்தது.

Kermit-ன் மற்றொரு தனித்துவமான அம்சம் அதன் வரம்பு. XMODEM, கோப்பு என்றால் என்ன என்பதில் ஏற்கனவே உடன்பாடு கொண்ட இரண்டு இயந்திரங்களுக்கு இடையே கோப்புகளை நகர்த்தியது. Kermit, எந்த உடன்பாடும் இல்லாத, வெவ்வேறு character sets, வெவ்வேறு record structures மற்றும் text-ன் முடிவு எது என்பதில் வெவ்வேறு கருத்துகளைக் கொண்ட அமைப்புகளுக்கு இடையே ஒரு பொதுவான பாலமாக எழுதப்பட்டது. mainframe-லிருந்து cloud servers-க்கு மாறிய நீண்ட பயணம் என்ற கட்டுரையில் விவரிக்கப்பட்டுள்ள உலகம் இதுதான். network layer இந்த வேலைகளைச் செய்வதற்கு முன்பே, interoperability என்பது எப்படி இருந்தது என்பதற்கு Kermit ஒரு சான்று.

Columbia பல்கலைக்கழகம் 2011-ல் தனது ஆதரவை நிறுத்திவிட்டு, C-Kermit-ஐ திருத்தப்பட்ட 3-clause BSD உரிமத்தின் கீழ் வெளியிட்டது. Frank da Cruz 1981-ல் வடிவமைத்தது முதல் 2025 வரை, 44 ஆண்டுகள் இத்திட்டத்துடன் இருந்தார். 2026-ம் ஆண்டு வெளியீட்டை OpenKermit திட்டம் பராமரிக்கிறது. தற்போது இதைப் படிக்கும் பலரை விடவும் பழமையான C codebase-ஐ நவீனப்படுத்தும் பணியை John Goerzen செய்து வருகிறார்.

XMODEM மற்றும் ZMODEM: தொலைபேசி கட்டணம் வடிவமைப்பைத் தீர்மானித்தபோது

Ward Christensen 1977-ல் MODEM.ASM-ஐ எழுதினார், அது அறிமுகப்படுத்திய protocol-தான் XMODEM. 1978-ல் அவரும் Randy Suess-உம் இணைந்து முதல் பொது bulletin board system-ஆன CBBS-ஐ online-க்கு கொண்டு வந்தனர். Christensen 2024 அக்டோபர் 11 அன்று காலமானார்.

XMODEM என்பது மிகச்சிறிய protocol-களில் ஒன்றாகும். தரவு 128-byte தொகுதிகளாக (blocks) நகர்கிறது. ஒவ்வொரு தொகுதியும் ஒரு-byte checksum-ஐக் கொண்டுள்ளது, இது 128 தரவு bytes-களின் கூட்டுத்தொகையை 256-ஆல் வகுத்து வரும் மீதியாகும். பெறுநர் (receiver) ஒவ்வொரு தொகுதியையும் உறுதிப்படுத்துவார் (acknowledge) அல்லது மீண்டும் அனுப்பக் கோருவார். இந்த வடிவமைப்புக்குக் காரணம் பொருளாதாரம். Dial-up இணைப்பில் நீங்கள் நேரத்திற்குப் பணம் செலுத்துவதால், ஒரு பிழை ஏற்பட்டால் முழு பரிமாற்றமும் பாதிக்கப்படாமல், ஒரு தொகுதி மட்டும் பாதிக்கப்படுவது செலவைக் குறைக்கும்.

இதன் பலவீனம் அதே வாக்கியத்தில் உள்ளது. XMODEM ஒவ்வொரு 128 bytes-க்குப் பிறகும் ஒரு உறுதிப்படுத்தலுக்காகக் காத்திருக்கிறது. Chuck Forsberg இதை ZMODEM விவரக்குறிப்பில் தெளிவாகக் குறிப்பிட்டார்: "குறுகிய தொகுதி நீளம் காரணமாக, timesharing அமைப்புகள், packet switched networks மற்றும் satellite circuits-களில் பயன்படுத்தும்போது throughput குறைகிறது." Bandwidth அல்ல, latency-தான் stop-and-wait முறையை முடக்குகிறது. நீங்கள் பணம் செலுத்தும் இணைப்பில், ஒவ்வொரு round trip-ம் வீணான நேரமாகும்.

அடுத்து YMODEM வந்தது, 1985-ல் Ward Christensen இதற்குப் பெயரிட்டார். இதன் பங்களிப்பு batch transfer ஆகும். தரவை அனுப்பும் முன் அனுப்புநர் கோப்பின் பெயர் மற்றும் அளவைக் குறிப்பிடுவார், இதனால் ஒரே அமர்வில் பல கோப்புகளை அனுப்ப முடியும் மற்றும் ஒவ்வொரு கோப்பும் எங்கு முடிகிறது என்பது பெறுநருக்குத் தெரியும்.

ZMODEM என்பது Omen Technology-ல் Chuck Forsberg வழங்கிய தீர்வாகும். இதன் விவரக்குறிப்பு 1988 அக்டோபர் 14-ல் திருத்தப்பட்டது, அதில் "ZMODEM ஒரு Telenet ஒப்பந்தத்தின் கீழ் பொது களத்திற்காக (public domain) உருவாக்கப்பட்டது" என்று குறிப்பிடப்பட்டுள்ளது. Telenet ஒரு பொது packet-switched தரவு வலையமைப்பை இயக்கியது, அந்த ஒப்பந்தத்தின் தாக்கம் வடிவமைப்பில் தெரிகிறது. ZMODEM வலையமைப்பின் control characters-ஐத் தவிர்க்கிறது (escape), இதனால் இடையில் உள்ள packet network அவற்றைச் சிதைக்காது. இது அமைதியிலிருந்து frame எல்லைகளைக் கண்டறிவதற்குப் பதிலாக, ஒவ்வொரு frame-ன் தொடக்கத்தையும் ஒரு தனித்துவமான character sequence மூலம் குறிக்கிறது, எனவே timeout-க்காகக் காத்திருக்காமல் இரைச்சலிலிருந்து (noise) மீண்டு வருகிறது. இதில் கோப்பு பரிமாற்றம் பாதியில் நின்றால், நின்ற இடத்திலிருந்தே தொடரும் வசதியும் உள்ளது.

மிக முக்கியமாக, இது காத்திருப்பதை நிறுத்துகிறது. விவரக்குறிப்பின் விளக்கத்தின்படி, "ZMODEM முழு கோப்பையும் ஒரு window-ஆகப் பயன்படுத்துகிறது". அனுப்புநர் தரவை இடைவிடாது அனுப்புகிறார் (stream), பெறுநர் ஏதேனும் சிக்கலைத் தெரிவித்தால் மட்டுமே நிறுத்துகிறார். இது TCP தனது window-ல் பயன்படுத்தும் அதே நுட்பமாகும்; ஒரு modem சும்மா இருப்பதைப் பார்த்த ஒருவர், எதிர் திசையிலிருந்து கண்டறிந்த தீர்வாகும்.

FTP-ன் இரண்டு இணைப்புகள் ஏன் காலாவதியானது

FTP மற்ற அனைத்தையும் விட பழமையானது. RFC 114, "A File Transfer Protocol", ஏப்ரல் 16, 1971 தேதியிட்டது மற்றும் A. Bhushan என்பவரால் எழுதப்பட்டது.

இதில் கவனிக்க வேண்டிய முக்கியமான விஷயம் என்னவென்றால், RFC 114 இரண்டு-இணைப்பு வடிவமைப்பை பரிசீலித்து அதை நிராகரித்தது. "ஒன்று கட்டுப்பாட்டுத் தகவலுக்கும், மற்றொன்று தரவுக்கும் என இரண்டு full-duplex இணைப்புகளைப் பயன்படுத்துவது" குறித்து Bhushan ஆராய்ந்து, பின்வருமாறு முடிவெடுத்தார்: "தரவு மற்றும் கட்டுப்பாட்டுத் தகவல் இரண்டையும் பரிமாறிக்கொள்ள ஒரே ஒரு full-duplex இணைப்பைப் பயன்படுத்துவதைப் பரிந்துரைக்கிறோம்." இந்த இணைப்புப் பிரிப்பு பிற்காலத்தில் வந்தது. ஜூலை 8, 1972 தேதியிட்ட RFC 354, "தரவு மற்றும் கோப்புகள் தரவு இணைப்பு வழியாக மட்டுமே பரிமாற்றப்படுகின்றன" என்றும், கட்டளைகள் தனி Telnet இணைப்பு வழியாகச் செல்கின்றன என்றும் குறிப்பிடுகிறது. அக்டோபர் 1985-ல் Postel மற்றும் Reynolds எழுதிய RFC 959 தான், இன்றும் அனைவரும் செயல்படுத்தும் பதிப்பாகும்.

RFC 959 போர்ட்களையும் (ports) நிர்ணயித்தது. சர்வரின் இயல்புநிலை தரவு போர்ட் என்பது "கட்டுப்பாட்டு இணைப்பு போர்ட்டிற்கு அடுத்ததாக உள்ள போர்ட் (அதாவது, L-1)" ஆகும். கட்டுப்பாட்டு இணைப்பு போர்ட் 21 ஆக இருக்கும்போது, இது போர்ட் 20 ஆகும்.

இங்கேதான் சிக்கல் தொடங்கியது. FTP-ன் அசல் முறையில், சர்வர் தான் கிளைண்டிற்குத் தரவு இணைப்பைத் திரும்பத் திறக்கும். NAT (network address translation)-க்கு பின்னால் இருக்கும் ஒரு கிளைண்டிற்கு சர்வர் அணுகக்கூடிய முகவரி இருக்காது. மேலும், firewall-க்கு பின்னால் இருக்கும் கிளைண்ட் உள்வரும் இணைப்புகளை ஏற்காது. இதனால் தரவு இணைப்பு ஏற்படாது, கோப்புப் பட்டியல் அல்லது கோப்பைக் கோரியவுடன் பரிமாற்றம் நின்றுவிடும். இதற்குத் தீர்வாக PASV அறிமுகப்படுத்தப்பட்டது. RFC 959-ன் படி, இது சர்வரை "ஒரு தரவு போர்ட்டில் (அதன் இயல்புநிலை தரவு போர்ட் அல்லாதது) 'listen' செய்யச் சொல்வதற்கும், பரிமாற்றக் கட்டளையைப் பெற்றவுடன் இணைப்பைத் தொடங்குவதற்குப் பதிலாக, இணைப்பிற்காகக் காத்திருப்பதற்கும்" வரையறுக்கிறது. சர்வர் தான் இணைக்க வேண்டிய முகவரி மற்றும் போர்ட்டை இவ்வாறு பதிலளிக்கும்:

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

அந்தப் பதில், host 203.0.113.10, போர்ட் 195 பெருக்கல் 256 கூட்டல் 80, அதாவது 50000 என்பதைக் குறிக்கிறது. இதை மீண்டும் கவனித்தால், இதில் உள்ள கட்டமைப்புச் சிக்கல் புரியும். இரண்டாவது இணைப்பின் endpoint, முதல் இணைப்பின் payload-க்குள் அறிவிக்கப்படுகிறது. ஒரு NAT பெட்டி அல்லது firewall, கட்டுப்பாட்டு சேனலை (control channel) ஆய்வு செய்து அதில் உள்ள போர்ட்டைத் திறந்தால் ஒழிய, அந்த இணைப்பை அனுமதிக்க முடியாது. Linux-ல் இதைச் சரியாகச் செய்யும் connection tracking helper உள்ளது. கட்டுப்பாட்டு இணைப்பு cleartext-ல் இருக்கும்போது மட்டுமே இந்த helper வேலை செய்யும். எனவே, FTP-ஐ TLS (transport layer security)-ல் மறைக்கும்போது, FTP-ஐப் பயன்படுத்தக்கூடியதாக மாற்றிய middlebox-ன் செயல்பாடு முடக்கப்படுகிறது.

இதுதான் FTP-ன் பாடம். இது நெட்வொர்க்கை அந்த புரோட்டோகாலின் ஒரு பங்கேற்பாளராக மாற்றியது. நெட்வொர்க் புரிந்துகொள்ள வேண்டிய ஒரு புரோட்டோகால், நெட்வொர்க் அதை நம்ப மறுக்கும்போது நிலைத்து நிற்க முடியாது.

இதன் முடிவு பதிவாகியுள்ளது. Firefox ஜூலை 2021-ல் அதன் 90-வது பதிப்பில் FTP ஆதரவை நீக்கியது. Chrome அக்டோபர் 2021-ல் Chrome 95-ல் FTP குறியீட்டை நீக்கியது.

rcp மற்றும் r-commands: hostname மூலம் நம்பகத்தன்மை

1983-ல் DARPA நிதியுதவியுடன் Berkeley வெளியிட்ட 4.2BSD, rcp, rsh மற்றும் rlogin ஆகியவற்றை அறிமுகப்படுத்தியது. இவை ஒரே network-ல் இருந்த Unix கணினிகளுக்காக உருவாக்கப்பட்டவை; இவற்றின் authentication முறை இதைத் தெளிவாகக் காட்டுகிறது. ஒரு host, எந்த பயனர் தன்னை அணுகுகிறார் என்பதைத் தெரிவிக்கும். /etc/hosts.equiv அல்லது பயனரின் ~/.rhosts கோப்பில் அந்த host நம்பகமானது என்று குறிப்பிடப்பட்டிருந்தால், அந்தத் தகவல் ஏற்றுக்கொள்ளப்பட்டு கடவுச்சொல் கேட்கப்படாது.

இந்தக் கட்டளைகள் ஏன் பயன்பாட்டில் இல்லை என்பதற்கான காரணத்தை இதன் செயல்பாட்டு முறை விளக்குகிறது. நம்பகத்தன்மை என்பது ஒரு முகவரி மற்றும் ஒரு கோரிக்கையை மட்டுமே அடிப்படையாகக் கொண்டது. இவை இரண்டும் network வழியாக cleartext-ஆகச் செல்வதால், பாதையில் உள்ள எவரும் இதைப் படிக்கவோ அல்லது போலியாக உருவாக்கவோ முடியும். Unix-லிருந்து Linux-க்கான பயணம் பகுதியில் விவரிக்கப்பட்ட சூழலில், அதாவது ஒரு கட்டிடத்திற்குள் இருந்த network-ல் இந்த முறை பொருத்தமாக இருந்தது. ஆனால், network என்பது internet-ஆக மாறிய தருணத்தில் இது பயனற்றதாகிவிட்டது.

rcp சரியாகச் செய்தது அதன் interface-ஐத்தான். source, destination, அவ்வளவுதான். session-ஐத் திறக்க வேண்டியதில்லை, transfer mode-ஐ முடிவு செய்ய வேண்டியதில்லை, இரண்டாவது connection-ஐ ஏற்படுத்த வேண்டிய அவசியமில்லை. இது பாதையில் ஒரு colon-ஐக் கொண்ட cp போலவே செயல்படுகிறது. அந்த interface, அதன் protocol-ஐ விட நான்கு தசாப்தங்கள் மேலாக நிலைத்து நின்றது.

SSH முழு வகையையும் உள்வாங்கிக்கொள்கிறது

1995-ல் ஹெல்சின்கி தொழில்நுட்ப பல்கலைக்கழகத்தின் ஆராய்ச்சியாளராக இருந்த Tatu Ylonen, பல்கலைக்கழக நெட்வொர்க்கில் நடந்த password-sniffing தாக்குதலுக்குப் பதிலாக SSH-ஐ உருவாக்கினார். ஜூலை 1995-ல் அவர் இதை source code-உடன் கூடிய free software-ஆக வெளியிட்டார். அந்த ஆண்டின் இறுதியில் 50 நாடுகளில் சுமார் 20,000 பயனர்கள் இதைப் பயன்படுத்தினர். டிசம்பர் 1995-ல், இதன் மேம்பாட்டிற்காக அவர் SSH Communications Security நிறுவனத்தைத் தொடங்கினார்.

பிற்கால பதிப்புகளில் உரிமக் கட்டுப்பாடுகள் கடுமையாக்கப்பட்டதால், OpenBSD உருவாக்குநர்கள் சுதந்திரமான உரிமம் கொண்ட கடைசி பதிப்பான ssh 1.2.12-ஐ fork செய்தனர். இதன் ஆரம்பகட்ட import 26 செப்டம்பர் 1999 அன்று நடந்தது. OpenSSH 1.2.2 பதிப்பு, 1 டிசம்பர் 1999 அன்று OpenBSD 2.6-உடன் வெளியானது. அந்த fork, திறந்தநிலை மென்பொருள் உரிம விதிமுறைகள் நடைமுறையில் ஏன் முக்கியம் என்பதற்கு ஒரு சிறந்த எடுத்துக்காட்டாகும். ஏனெனில், இன்று அனைவரும் பயன்படுத்தும் SSH implementation, உரிமம் அனுமதித்த அந்த ஒரே பதிப்பிலிருந்து உருவானதே.

SSH பயன்பாட்டிற்கு வந்தவுடன், கோப்பு பரிமாற்றம் (file transfer) ஒரு தனிப் பிரச்சினையாக இருக்கவில்லை. அங்கீகரிக்கப்பட்ட, குறியாக்கம் செய்யப்பட்ட (encrypted) stream பல சேனல்களைக் கொண்டுள்ளதால், பழைய protocols தாங்களாகவே உருவாக்க வேண்டிய integrity, ordering மற்றும் இரண்டாவது TCP connection தேவையில்லாத தரவுப் பாதை ஆகியவற்றை இது வழங்குகிறது. இந்த நுட்பங்கள் உங்களுக்குப் புதியவை என்றால், மேலும் செல்வதற்கு முன் SSH என்றால் என்ன என்பதை முதலில் தெரிந்துகொள்ளுங்கள்.

இதிலிருந்து இரண்டு கருவிகள் உருவாயின. scp என்பது SSH session-க்குள் இயங்கும் rcp-ன் wire protocol ஆகும்; அதனால்தான் இது rcp-ன் command line-ஐ அப்படியே பெற்றுள்ளது. SFTP ஒரு மாறுபட்ட வடிவமைப்பு: இது directory listing, file attributes மற்றும் random access வசதிகளைக் கொண்ட ஒரு உண்மையான file protocol ஆகும், இது SSH சேனலில் இயங்குகிறது. SFTP ஒருபோதும் RFC ஆகவில்லை. IETF draft, draft-ietf-secsh-filexfer, 18 ஜூலை 2006 அன்று 13-வது பதிப்பை எட்டியது, பின்னர் காலாவதியானது. OpenSSH அந்த draft-ன் 3-வது பதிப்பைச் செயல்படுத்துகிறது. உலகில் அதிகம் பயன்படுத்தப்படும் secure file transfer protocol என்பது கைவிடப்பட்ட ஒரு draft-ன் எண்ணிடப்பட்ட பதிப்புதான், அது சிறப்பாகச் செயல்படுகிறது.

பழைய scp protocol-ம் இப்போது பயன்பாட்டிலிருந்து நீக்கப்பட்டுவிட்டது. 26 செப்டம்பர் 2021 அன்று வெளியான OpenSSH 8.8, "எதிர்காலத்தில் வெளியாகும் OpenSSH பதிப்புகள் scp(1)-ல் பழைய scp/rcp protocol-க்கு பதிலாக SFTP-ஐ இயல்பாகப் பயன்படுத்தும்" என்று எச்சரித்தது. 8 ஏப்ரல் 2022 அன்று வெளியான OpenSSH 9.0 இதைச் செய்தது: "இந்த வெளியீடு scp(1)-ல் பழைய scp/rcp protocol-க்கு பதிலாக SFTP protocol-ஐ இயல்பாகப் பயன்படுத்துகிறது."

இதற்கான காரணம் ஒரு பழைய தொழில்நுட்பக் கதையை விளக்குகிறது. பழைய scp protocol, remote filename wildcards-ஐ remote shell-க்கு அனுப்பி விரிவுபடுத்தியது; அதனால்தான் remote path-ல் உள்ள ஒவ்வொரு metacharacter-ஐயும் double-quote செய்ய மக்கள் பழகினர். 8.8 பதிப்பின் குறிப்புகள், SFTP வழியாகச் செயல்படும் scp "இனி இத்தகைய சிக்கலான மற்றும் உடையக்கூடிய quoting-ஐக் கோருவதில்லை" என்று கூறுகின்றன. எனவே, தற்போதைய server-ல் scp என்பது rcp-ன் command line-ஐப் பயன்படுத்தும் ஒரு SFTP client ஆகும். 1983-ன் interface நீடித்தது, ஆனால் 1983-ன் wire protocol நீடிக்கவில்லை.

rsync, 1996: முழு கோப்பையும் அனுப்பாமல், மாற்றங்களை மட்டும் அனுப்புதல்

Andrew Tridgell மற்றும் Paul Mackerras ஆகியோர் 19 June 1996 அன்று Australian National University-ல் rsync-ஐ அறிமுகப்படுத்தினர். இதனுடன் "The rsync algorithm" என்ற TR-CS-96-05 தொழில்நுட்ப அறிக்கையும் வெளியிடப்பட்டது.

இதற்கு முந்தைய அனைத்து protocol-களும் ஒரு கோப்பை சிதையாமல் எப்படி நகர்த்துவது என்றே கவலைப்பட்டன. ஆனால், rsync, "எதிர்தரப்பில் ஏற்கனவே இந்த கோப்பின் எவ்வளவு பகுதி உள்ளது?" என்று கேட்டது. இந்த அறிக்கை, இலக்கை "குறைந்த அலைவரிசை மற்றும் அதிக தாமதம் கொண்ட இருவழித் தொடர்பு இணைப்பு" என்று வரையறுக்கிறது. "மூலக் கோப்பின் எந்தெந்த பகுதிகள் இலக்குக் கோப்பின் பகுதிகளுடன் ஒத்துப்போகின்றன" என்பதைக் கண்டறிந்து, பொருந்தாத பகுதிகளை மட்டும் அனுப்புவதே இதன் நோக்கம்.

இதன் செயல்பாட்டு முறையைப் புரிந்துகொள்வது அவசியம், ஏனெனில் இதுவே rsync-ன் நடத்தையை விளக்குகிறது. பெறுநர் (receiver) தனது வசம் உள்ள கோப்பை நிலையான அளவுள்ள தொகுதிகளாகப் (blocks) பிரித்து, ஒவ்வொரு தொகுதிக்கும் இரண்டு checksum-களைக் கணக்கிடுகிறது: ஒன்று பலவீனமானது மற்றும் மலிவானது, மற்றொன்று வலிமையானது மற்றும் அதிக செலவு பிடிப்பது. இந்த பட்டியலை அது அனுப்புநருக்கு (sender) அனுப்புகிறது. அனுப்புநர் தனது கோப்பின் மீது ஒரு window-வை ஒரு byte வீதம் நகர்த்தி, பலவீனமான checksum-ஐ படிப்படியாகப் புதுப்பிக்கிறது; இதுவே byte-க்கு-byte ஸ்கேன் செய்வதைச் சாத்தியமாக்குகிறது. பலவீனமான பொருத்தம் கண்டறியப்பட்டால், அது வலிமையான checksum மூலம் உறுதிப்படுத்தப்படுகிறது. உறுதிப்படுத்தப்பட்ட பொருத்தங்கள் தொகுதி குறிப்புகளாக (block references) மாறுகின்றன. மற்ற அனைத்தும் literal bytes-ஆக அனுப்பப்படுகின்றன. பெறுநர், ஏற்கனவே தன்னிடம் உள்ள தொகுதிகள் மற்றும் புதிதாகப் பெற்ற literal-களைக் கொண்டு கோப்பை மீண்டும் உருவாக்குகிறது.

ஒரு பெரிய கோப்பின் தொடக்கத்தில் ஒரே ஒரு byte-ஐச் சேர்த்தால், சாதாரண difference tool முழு கோப்பையும் அனுப்ப வேண்டியிருக்கும், ஏனெனில் அனைத்து offset-களும் மாறிவிடும். ஆனால், rolling window புதிய offset-களில் அதே தொகுதிகளைக் கண்டறிவதால், rsync அந்த ஒரு byte-ஐயும் சில மேலாண்மைத் தரவுகளையும் மட்டுமே அனுப்புகிறது. ஒரு கோப்பகத்தை ஒன்றுக்கும் மேற்பட்ட முறை நகர்த்த வேண்டியிருக்கும் போது, rsync சிறந்த கருவியாக இருப்பதற்கு இந்த பண்பே காரணம்.

இரண்டு செயல்பாடுகள் பயனர்களை அடிக்கடி ஆச்சரியப்படுத்துகின்றன, இவை இரண்டும் manual-ல் குறிப்பிடப்பட்டுள்ளன. முதலாவதாக, rsync கோப்புகளைப் பரிசோதிக்க checksum-ஐப் பயன்படுத்துவதில்லை. இது "இயல்பாகவே 'quick check' algorithm-ஐப் பயன்படுத்தி, கோப்பின் அளவு அல்லது கடைசியாக மாற்றப்பட்ட நேரம் மாறியுள்ளதா என்று பார்த்து, மாற்றப்பட வேண்டிய கோப்புகளைக் கண்டறிகிறது". கோப்பின் உள்ளடக்கம் மாறியிருந்தாலும், அதன் அளவும் timestamp-ம் மாறாமல் இருந்தால், அது தவிர்க்கப்படும். --checksum இந்த நிலையை மாற்றுகிறது, மேலும் இது இருபுறமும் உள்ள அனைத்து கோப்புகளையும் முழுமையாக வாசிக்கச் செய்கிறது. இரண்டாவதாக, இரு பாதைகளும் local-ஆக இருக்கும்போது delta algorithm இயல்பாகவே முடக்கப்பட்டிருக்கும். ஏனெனில், ஒரே கணினியில் இரண்டு பிரதிகளை வாசித்து checksum செய்வது, அந்த bytes-ஐ நகர்த்துவதை விட அதிக செலவு பிடிக்கும். இணைப்பு மெதுவாக இருக்கும்போது மட்டுமே இந்த சேமிப்பு பயனுள்ளதாக இருக்கும்.

VPS-ல் நீங்கள் உண்மையில் எவற்றைப் பயன்படுத்துவீர்கள், ஏன்

சுருக்கமாகச் சொன்னால்: சில கோப்புகளுக்கு SFTP, மீண்டும் மீண்டும் நகலெடுக்க வேண்டிய கோப்பகங்களுக்கு (directory) SSH வழியாக rsync.

இவை இரண்டுமே SSH-ஐப் பயன்படுத்துவதால், கூடுதல் கட்டமைப்பு ஏதுமின்றி host key சரிபார்ப்பு மற்றும் குறியாக்க (encryption) வசதிகளைப் பெறுகின்றன. ஐம்பது ஆண்டுகால தொழில்நுட்ப உழைப்பு, இயல்பான அமைப்பிலேயே (default) இதில் அடங்கியுள்ளது. Kermit-ன் வடிவமைப்பாளர்கள், தரவு பரிமாற்றத்தின் போது சிதைவு ஏற்படும் என்று கருதியதால், நெறிமுறையிலேயே (protocol) checksum மற்றும் மறு-அனுப்புதல் (retransmission) வசதிகளை உருவாக்கினர். இப்போது TCP அந்த வேலையைச் செய்கிறது. Christensen மற்றும் Forsberg ஒவ்வொரு பைட்டும் (byte) செலவு மிக்கது என்று கருதியதால், கோப்பு பரிமாற்றத்தை மீண்டும் தொடரும் (resume) மற்றும் ஸ்ட்ரீமிங் வசதிகளை உருவாக்கினர். இப்போது rsync-ன் டெல்டா அல்காரிதம் (delta algorithm) அதைச் சிறப்பாகச் செய்கிறது. FTP-ன் ஆசிரியர்கள், நெட்வொர்க்கில் உள்ள அனைத்து கணினிகளும் ஒத்துழைப்புடன் செயல்படும் என்று கருதினர். அந்த ஒரு அனுமானம் மட்டுமே, எந்தவொரு நெறிமுறை மாற்றத்தாலும் சரிசெய்ய முடியாத வகையில் தவறானது என்று நிரூபணமானது.

Checksum-கள் இன்னும் எதற்காகப் பயன்படுகின்றன

வரலாறு முழுவதும் "checksum" என்ற சொல் மூன்று வெவ்வேறு பணிகளைச் செய்துள்ளது, அவற்றை ஒன்றிற்குப் பதிலாக மற்றொன்றைப் பயன்படுத்த முடியாது.

Kermit மற்றும் XMODEM ஆகியவற்றின் per-packet checksum-கள், தரவு பரிமாற்றத்தின் போது ஏற்படும் சிதைவைக் கண்டறிந்தன. இன்று TCP checksum மற்றும் link layer-ல் உள்ள error correction ஆகியவையே அந்தப் பணியைச் செய்கின்றன, அதனால்தான் எந்தவொரு நவீன பரிமாற்றக் கருவியும் (transfer tool) இதைப் பற்றி நீங்கள் கவலைப்பட வேண்டியதில்லை என்று கூறுகிறது.

rsync-ன் block checksum-கள் "இந்தத் தரவு சரியானதா" என்ற கேள்விக்கு விடையளிப்பதில்லை. மாறாக, "இந்த block உங்களிடம் ஏற்கனவே உள்ளதா" என்ற கேள்விக்கே விடையளிக்கின்றன. அங்குள்ள ஒரு வலுவான checksum என்பது ஒரு lookup key மட்டுமே, அது கோப்பு எங்கிருந்து வந்தது என்பதற்கான சான்று அல்ல.

மூன்றாவது பணிதான் இன்னும் உங்களிடம் எஞ்சியுள்ளது. ஒரு release கோப்பில் வெளியிடப்படும் checksum, TLS-ஆல் விடையளிக்க முடியாத ஒரு கேள்விக்கு விடையளிக்கிறது. நீங்கள் சரியான server-உடன் தொடர்பு கொள்கிறீர்கள் என்பதை TLS உறுதிப்படுத்துகிறது. ஆனால், அந்த server-ல் சரியான கோப்புதான் இருந்தது என்பதை அது உறுதிப்படுத்தாது; மேலும், ஒரு mirror-லிருந்து நீங்கள் பதிவிறக்கும் கோப்பிற்கு அது எந்த உதவியும் செய்யாது. இதனால்தான் release checksum-களும் கையொப்பங்களும் (signatures) இன்னும் முப்பது வினாடிகள் செலவிடத் தகுதியானவை, மேலும் இந்த வழக்கத்தை உருவாக்குவது எளிது: நீங்கள் நிறுவும் ஒவ்வொரு பதிவிறக்கத்திலும் checksum-ஐ சரிபார்க்கவும்.

இந்தக் கதையில் உள்ள மற்ற அனைத்தும் கீழ்மட்ட அடுக்குகளால் (layer underneath) தீர்க்கப்பட்டுவிட்டன. ஆனால், இது ஒரு network சிக்கலாக இல்லாததால், அந்த ஒரு சிக்கல் மட்டும் இன்னும் தீர்க்கப்படாமல் உள்ளது.

FAQ

VPS-ல் FTP-ஐப் பயன்படுத்துவது இன்னும் பாதுகாப்பானதா?

இல்லை. சாதாரண FTP, credentials மற்றும் கோப்புகளின் உள்ளடக்கங்களை cleartext வடிவில் அனுப்புகிறது. எனவே, அந்தப் பாதையில் இருக்கும் எவரும் அவற்றைப் படிக்க முடியும். மேலும், இது அதன் control channel-ஐப் பகுப்பாய்வு செய்யும் firewall-ஐச் சார்ந்துள்ளது. நீங்கள் TLS மூலம் control channel-ஐ encrypt செய்தவுடன், அந்தப் பகுப்பாய்வு சாத்தியமற்றதாகிவிடும். உலாவிகள் ஏற்கனவே FTP-ஐக் கைவிட்டுவிட்டன: Firefox ஜூலை 2021-ல் பதிப்பு 90-ல் FTP ஆதரவை நீக்கியது, Chrome அக்டோபர் 2021-ல் பதிப்பு 95-ல் அதன் குறியீட்டை நீக்கியது. SSH வழியாக SFTP-ஐப் பயன்படுத்துங்கள்; இதற்கு ஒரே ஒரு port மட்டுமே தேவை, மேலும் protocol-ஐப் புரிந்துகொள்ளும் middlebox தேவையில்லை.

FTP-க்கு ஏன் passive mode தேவைப்படுகிறது?

FTP-ன் அசல் முறையில், server மீண்டும் client-க்கு data connection-ஐத் திறக்கும். RFC 959, server-ன் default data port-ஐ "control connection port-க்கு அடுத்ததாக (அதாவது L-1)" என்று வரையறுக்கிறது; எனவே control port 21 ஆக இருக்கும்போது, data port 20 ஆக இருக்கும். NAT (network address translation)-க்கு பின்னால் இருக்கும் client-க்கு, server-ஆல் அடையக்கூடிய முகவரி எதுவும் இருக்காது. இதனால் அந்த connection ஒருபோதும் கிடைக்காது, பரிமாற்றம் தடைபடும். PASV இந்தத் திசையை மாற்றுகிறது: server-தான் listen செய்கிறது, மேலும் client இணைக்க வேண்டிய முகவரி மற்றும் port-ஐ 227 Entering Passive Mode பதில் மூலம் வழங்குகிறது.

scp இன்னும் அதன் சொந்த protocol-ஐப் பயன்படுத்துகிறதா?

இல்லை. ஏப்ரல் 8, 2022 அன்று வெளியிடப்பட்ட OpenSSH 9.0-க்குப் பிறகு, "scp(1) அதன் பழைய scp/rcp protocol-லிருந்து default-ஆக SFTP protocol-க்கு மாறியுள்ளது". OpenSSH 8.8, செப்டம்பர் 2021-ல் இந்த மாற்றத்தை அறிவித்தது. இதில் தெரியும் வித்தியாசம் quoting-ல் உள்ளது. பழைய protocol, remote wildcards-ஐ remote shell-க்கு அனுப்பி விரிவுபடுத்தியது. SFTP-அடிப்படையிலான protocol அவ்வாறு செய்வதில்லை. எனவே, அந்த shell expansion-ஐச் சார்ந்திருந்த பாதைகள் இப்போது வித்தியாசமாகச் செயல்படுகின்றன.

VPS-க்கு scp-ஐ விட rsync எப்போது சிறந்தது?

ஒரே கோப்புத் தொகுப்பை ஒன்றுக்கு மேற்பட்ட முறை நகலெடுக்கும்போது rsync சிறந்தது. rsync, destination-ல் இல்லாத கோப்பின் பகுதிகளை மட்டுமே அனுப்புகிறது. எனவே, இரண்டாவது நகல் எடுப்பது முதல் முறையை விட மிக வேகமானது. destination-ல் இதுவரை இல்லாத ஒரு கோப்பிற்கு, scp மற்றும் rsync இரண்டும் ஏறக்குறைய ஒரே அளவு தரவைத்தான் நகர்த்துகின்றன, மேலும் scp பயன்படுத்துவது எளிது. rsync இயல்பாகவே கோப்பின் அளவு மற்றும் மாற்றப்பட்ட நேரத்தை (modification time) வைத்துத்தான் எதைப் பார்க்க வேண்டும் என்று தீர்மானிக்கிறது என்பதை நினைவில் கொள்ளுங்கள். எனவே, கோப்பின் அளவு மற்றும் timestamp மாறாமல் அதன் உள்ளடக்கம் மட்டும் மாறியிருந்தால், rsync அதைக் கண்டறிய --checksum தேவைப்படும்.

Kermit ஏன் கோப்புகளை raw bytes-ஆக அனுப்பாமல் printable text-ஆக encode செய்தது?

ஏனெனில் அது இலக்காகக் கொண்டிருந்த இணைப்பு, byte pipe-ஆக இல்லாமல் mainframe-க்கான terminal line-ஆக இருந்தது. அந்த இணைப்புகள் 7-bit ஆக இருக்கலாம், மேலும் mainframe-ன் terminal driver, control characters-ஐ அப்படியே கடத்தாமல் அவற்றின் மீது செயல்படும். Kermit, control bytes மற்றும் high-bit bytes-ஐ printable characters-ஆக மாற்றியது, இதனால் இடையில் இருக்கும் எதுவும் அவற்றைக் கண்டு எதிர்வினை ஆற்றாது. இந்த encoding, binary கோப்புகளை network-ல் பெரியதாக மாற்றுகிறது. ஆனால், தரவு சிதைந்து போவதைத் தவிர்க்க இதுவே சரியான தீர்வாக இருந்தது.