Kermit నుంచి rsync వరకు ఫైల్ బదిలీ ప్రోటోకాల్‌ల చరిత్ర

ఫైల్ బదిలీ ప్రోటోకాల్‌లు మారుతూ రావడానికి కారణం

ప్రతి ఫైల్ బదిలీ ప్రోటోకాల్ తన కాలానికి సంబంధించిన వైఫల్య పరిస్థితిని దృష్టిలో పెట్టుకుని రూపొందించబడింది. Kermit మీ bytes ను transmission line దెబ్బతీస్తుందని భావించింది. XMODEM మరియు ZMODEM connection నెమ్మదిగా ఉంటుందని, ప్రతి నిమిషానికి చెల్లించాల్సి వస్తుందని భావించాయి. FTP (file transfer protocol) మధ్యలో ఉన్న network సహకరిస్తుందని భావించింది. SSH మాత్రం అది hostile గా ఉంటుందని భావించింది. చివరి అంచనానే గెలిచింది. అందుకే నేడు VPSలో SFTP మరియు rsync over SSH మాత్రమే సాధారణంగా లభిస్తాయి; మిగతావి చాలా తక్కువ.

ఇప్పుడు దీన్ని పరిశీలించడానికి ఒక కారణం ఉంది. C-Kermit 11.0.506 3 August 2026న విడుదలైంది. ఇది 20 August 2011న వచ్చిన C-Kermit 9.0.302 తర్వాత వచ్చిన మొదటి non-beta release. ఇది అమలు చేసే protocolను May 1981లో రూపొందించారు. నలభై ఐదు సంవత్సరాలు అంటే ఒక పూర్తి వర్గం పుట్టుకొచ్చి, standardise అయి, అది నడిచిన network వల్ల విఫలమై, చివరకు SSHలో కలిసిపోయేంత కాలం.

Kermit, 1981: మీ bytes ను మార్చివేసే line కోసం రూపొందించబడింది

Kermit ను 1981 మేలో Columbia University Computer Centerలో Frank da Cruz మరియు Bill Catchings రూపొందించారు. ఈ పేరు Kermit the Frog నుంచి వచ్చింది. బృందం పేరును ఆలోచిస్తున్న సమయంలో గోడపై Muppets calendar ఉందని Da Cruz వివరించారు. ఈ ప్రాజెక్ట్ ఇంతగా విస్తరిస్తుందని ఎవ్వరూ ఊహించలేదు.

Kermit పరిష్కరించిన సమస్య వేగం కాదు. terminal మరియు mainframe మధ్య ఉన్న మార్గం arbitrary bytes కోసం pipe కాదు. అది స్వంత పరిమితులు ఉన్న character device. అది 7-bit కావచ్చు. అది half duplex కావచ్చు. అది control characters ను మింగివేయవచ్చు లేదా వాటిలో ఒకదాన్ని command గా అమలు చేయవచ్చు. binary file ను ఎలాంటి మార్పు లేకుండా దాని ద్వారా పంపడం సాధ్యం కాదు.

అందువల్ల design ఈ పరిమితులను యథాతథంగా పరిగణించింది. Kermit Project చరిత్రలో ఈ అంశాలు ఉన్నాయి:

• short packets, ఎందుకంటే చాలా mainframes terminal నుంచి వచ్చే పొడవైన data bursts ను స్వీకరించలేకపోయేవి
• half-duplex stop-and-wait, ఎందుకంటే IBM mainframes full-duplex communication కు మద్దతు ఇవ్వలేదు
• control characters మరియు 8-bit characters కోసం printable encodings, ఎందుకంటే ఇవి రెండూ mainframe యొక్క terminal driver ద్వారా వెళ్లలేకపోయేవి
• ప్రతి packet పై checksum, దానికి receiver సమాధానం ఇస్తుంది; అందువల్ల పాడైన packet వల్ల ఒక retransmission మాత్రమే అవసరమవుతుంది, మొత్తం file ను మళ్లీ పంపాల్సిన పని ఉండదు

మూడవ అంశమే ఆసక్తికరమైనది. Kermit మీ file ను నేరుగా పంపదు; దాని బదులుగా text-safe encoding ను పంపుతుంది. ఒక control byte, prefix character తరువాత వచ్చే printable character గా మారుతుంది. high bit set అయిన byte ను కూడా 7-bit link కోసం ఇదే విధంగా encode చేయవచ్చు. మధ్యలో ఉన్న వ్యవస్థ printable text ను మాత్రమే అర్థం చేసుకున్నా, దానికి printable text‌నే కనిపిస్తుంది. దీని ఖర్చు పరిమాణం: binary file network link పై పెద్దదవుతుంది. లేకపోతే transfer ను పూర్తిగా మార్చివేసే mainframe front end తో పోలిస్తే, ఇది సరైన trade-off.

Kermit యొక్క మరో అసాధారణ లక్షణం దాని పరిధి. XMODEM, file అంటే ఏమిటో ఇప్పటికే పరస్పరం అంగీకరించిన రెండు machines మధ్య file ను తరలించేది. పరస్పరం అంగీకరించని systems మధ్య least common denominator గా Kermit రూపొందించబడింది. వాటికి వేర్వేరు character sets, వేర్వేరు record structures, అలాగే text line ఎక్కడ ముగుస్తుందనే విషయంపై వేర్వేరు విధానాలు ఉండేవి. mainframes నుంచి cloud servers వరకు జరిగిన దీర్ఘ మార్పు వివరించే ప్రపంచం ఇదే. network layer ఆ పని మీ కోసం నిర్వహించే ముందు interoperability ఇలా ఉండేది.

Columbia తన sponsorship ను 2011లో ముగించి, C-Kermit ను revised 3-clause BSD licence కింద విడుదల చేసింది. 1981 design నుంచి 2025 వరకు 44 సంవత్సరాల పాటు Frank da Cruz ఈ project తో కొనసాగారు. 2026 release ను OpenKermit project నిర్వహిస్తోంది. ప్రస్తుతం దీనిని చదువుతున్న చాలా మంది కంటే పాతదైన C codebase ను ఆధునికీకరించే పనిని John Goerzen చేస్తున్నారు.

XMODEM మరియు ZMODEM: ఫోన్ బిల్లు డిజైన్‌ను ఎలా ప్రభావితం చేసింది

Ward Christensen 1977లో MODEM.ASM రాశారు. అది పరిచయం చేసిన ప్రోటోకాల్ XMODEM. 1978లో ఆయన మరియు Randy Suess కలిసి CBBS ను onlineలోకి తీసుకువచ్చారు. అది మొదటి public bulletin board system. Christensen 11 October 2024న మరణించారు.

XMODEM ప్రోటోకాల్‌లలో అత్యంత చిన్నవాటిలో ఒకటి. డేటా 128-byte blocks గా తరలుతుంది. ప్రతి blockలో ఒక-byte checksum ఉంటుంది. ఇది 128 data bytes మొత్తాన్ని 256తో భాగించినప్పుడు వచ్చే remainder. Receiver ప్రతి blockను acknowledge చేస్తుంది లేదా దాన్ని మళ్లీ పంపమని అడుగుతుంది. ఈ నిర్మాణానికి కారణం ఆర్థిక అంశం. Dial-up lineలో సమయానికి చెల్లించాలి. అందువల్ల line error వచ్చినప్పుడు మొత్తం transfer కాకుండా ఒక block మాత్రమే మళ్లీ పంపాల్సి ఉంటుంది.

అదే వాక్యంలో దీని బలహీనత కూడా ఉంది. ప్రతి 128 bytes తర్వాత XMODEM acknowledgement కోసం వేచి ఉంటుంది. Chuck Forsberg ZMODEM specificationలో దీనిని స్పష్టంగా పేర్కొన్నారు: "timesharing systems, packet switched networks, satellite circuitsతో ఉపయోగించినప్పుడు చిన్న block length వల్ల throughput తగ్గుతుంది." Stop-and-waitను దెబ్బతీసేది bandwidth కాదు, latency. మీరు సమయానికి చెల్లిస్తున్న lineలో ప్రతి round trip సమయంలో డేటా ఏదీ ప్రవహించదు.

తర్వాత YMODEM వచ్చింది. Ward Christensen 1985లో ఆ పేరును రూపొందించారు. దీని ప్రధాన మార్పు batch transfer. Dataకి ముందు sender filename మరియు sizeను తెలియజేస్తుంది. అందువల్ల ఒకే sessionలో అనేక filesను తరలించవచ్చు. ప్రతి file ఎక్కడ ముగుస్తుందో receiverకు తెలుస్తుంది.

ZMODEM అనేది Omen Technologyలో Chuck Forsberg రూపొందించిన పరిష్కారం. Specification revision 14 October 1988 నాటిది. అందులో "Telenet contract కింద public domain కోసం ZMODEM అభివృద్ధి చేయబడింది" అని పేర్కొంది. Telenet ఒక public packet-switched data networkను నిర్వహించింది. ఆ contract ప్రభావం designలో కనిపిస్తుంది. Network control charactersను ZMODEM escape చేస్తుంది. అందువల్ల మధ్యలో ఉన్న packet network వాటిని వినియోగించదు. Silence ఆధారంగా frame boundariesను ఊహించకుండా, ప్రతి frame ప్రారంభాన్ని ప్రత్యేకమైన character sequenceతో గుర్తిస్తుంది. అందువల్ల timeout కోసం వేచి ఉండకుండానే noise నుంచి recovery చేయగలదు. అంతరాయం కలిగిన transfer ఆగిన స్థానంనుంచి మళ్లీ ప్రారంభమయ్యేలా explicit resume కూడా ఉంది.

అన్నింటికంటే ముఖ్యంగా, ఇది వేచి ఉండడాన్ని ఆపుతుంది. Specificationలోనే "ZMODEM వాస్తవానికి మొత్తం fileను ఒక windowగా ఉపయోగిస్తుంది" అని వివరించారు. Sender నిరంతరం stream చేస్తుంది. Receiver సమస్యను నివేదించినప్పుడు మాత్రమే అది ఆగుతుంది. ఇదే ఆలోచనను TCP తన windowలో అమలు చేస్తుంది. అయితే ఈ ఆలోచన మరో దిశ నుంచి వచ్చింది: modem idleగా ఉండటాన్ని గమనించిన వ్యక్తి దాన్ని రూపొందించారు.

FTP యొక్క రెండు కనెక్షన్లు ఎందుకు త్వరగా సమస్యాత్మకంగా మారాయి

FTP ఇవన్నింటికంటే పాతది. “A File Transfer Protocol” అనే RFC 114, 16 April 1971 తేదీతో A. Bhushan రచించారు.

తెలుసుకోవాల్సిన ముఖ్యమైన విషయం ఏమిటంటే, RFC 114 రెండు కనెక్షన్ల రూపకల్పనను పరిశీలించి తిరస్కరించింది. “ఒకటి control information కోసం, మరొకటి data కోసం రెండు full-duplex links ఉపయోగించడం” గురించి Bhushan పరిశీలించారు. తరువాత ఇలా నిర్ణయించారు: “data మరియు control information రెండింటి మార్పిడికి ఒకే full-duplex connection ఉపయోగించాలని మేము సిఫారసు చేస్తున్నాము.” విభజన తరువాత వచ్చింది. 8 July 1972 తేదీతో ఉన్న RFC 354 లో, “data మరియు files కేవలం data connection ద్వారా మాత్రమే బదిలీ అవుతాయి” అని ఉంది. Commands ప్రత్యేక Telnet connection ద్వారా పంపబడతాయి. Postel మరియు Reynolds రచించిన October 1985 నాటి RFC 959నే ఇప్పటికీ అందరూ అమలు చేస్తున్నారు.

RFC 959 ports ను కూడా స్థిరపరిచింది. Server యొక్క default data port, “control connection port కు పక్కనే ఉన్న port (అంటే L-1)” అని నిర్వచించబడింది. Control connection port 21 అయితే అది port 20.

ఇక్కడ నిలవని భాగం ఇదే. FTP యొక్క అసలు mode లో server client కు తిరిగి data connection ను ప్రారంభిస్తుంది. NAT (network address translation) వెనుక ఉన్న client ను server చేరుకోగల address ఉండదు. Firewall వెనుక ఉన్న client inbound connections ను అంగీకరించదు. అందువల్ల data connection ఎప్పటికీ రాదు. Listing లేదా file కోరిన వెంటనే transfer నిలిచిపోతుంది. దీనికి పరిష్కారం PASV. RFC 959 ప్రకారం, ఇది server కు “data port పై (దాని default data port కానిది) ‘listen’ చేసి, transfer command అందినప్పుడు connection ప్రారంభించకుండా, connection కోసం వేచి ఉండమని” కోరుతుంది. Connect కావాల్సిన address మరియు port ను server ఇలా పంపుతుంది:

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

ఆ reply లో host 203.0.113.10 అని, port 195 times 256 plus 80 అని ఉంది. అంటే port 50000. దీన్ని మరోసారి చదివితే నిర్మాణాత్మక సమస్య స్పష్టమవుతుంది. రెండవ connection యొక్క endpoint, మొదటి connection payload లో ప్రకటించబడుతుంది. NAT box లేదా firewall control channel ను parse చేసి, అందులో కనిపించే port ను తెరవకపోతే ఆ connection ను pass చేయలేవు. Linux లో దీనినే చేసే connection tracking helper ఉంది. Control connection cleartext లో ఉన్నంతవరకే ఆ helper పనిచేస్తుంది. అందువల్ల FTP ను TLS (transport layer security) తో wrap చేస్తే, FTP పనిచేయడానికి సహాయపడుతున్న middlebox కు అవసరమైన సమాచారం కనిపించదు.

FTP నుంచి ఒక వాక్యంలో చెప్పగల పాఠం ఇదే. అది network ను protocol లోని భాగస్వామిగా మార్చింది. Network దానిని అర్థం చేసుకోవాల్సిన protocol, network దానిపై నమ్మకం ఉంచడం ఆపినప్పుడు నిలవదు.

ముగింపు అధికారిక రికార్డులో ఉంది. Firefox version 90లో July 2021లో FTP support ను తొలగించింది. Chrome, October 2021లో Chrome 95లో FTP code ను తొలగించింది.

rcp మరియు r-commands: hostname ఆధారిత trust

1983లో Berkeley, DARPA నిధులతో విడుదల చేసిన 4.2BSDలో rcp, rsh మరియు rlogin వచ్చాయి. ఇవి ఒకే networkలోని Unix మెషీన్లు ఉన్న campus కోసం రూపొందించబడ్డాయి. వాటి authentication model దీనినే చూపిస్తుంది. ఏ user call చేస్తున్నాడో ఒక host ప్రకటించేది. /etc/hosts.equiv లేదా user యొక్క ~/.rhosts ఆ hostను trusted అని తెలిపితే, ఆ ప్రకటనను అంగీకరించి password అడగకుండా ముందుకు వెళ్లేది.

ఈ mechanismను స్పష్టంగా చెప్పాలి. ఈ commands ఎందుకు కనుమరుగయ్యాయో దానికి ఇదే కారణం. Trust ఒక address మరియు ఒక claimపై ఆధారపడేది. రెండూ networkలో cleartextగా ప్రయాణించేవి. అందువల్ల మార్గంలో ఉన్న ఎవరైనా వాటిని చదవగలరు. అదే విధంగా వాటిని ఎవరైనా forge చేయగలరు. Unix నుంచి Linux వరకు వచ్చిన మార్గంలో వివరించిన environmentలో ఈ model సమంజసంగా ఉండేది. అప్పుడు network ఒక building పరిధిలో ఉండేది. Network internetగా మారిన వెంటనే ఈ modelకు అర్థం లేకుండా పోయింది.

rcp సరిగ్గా రూపొందించిన అంశం దాని interface. Source, destination, done. తెరవాల్సిన session లేదు. చర్చించాల్సిన transfer mode లేదు. ఏర్పాటు చేయాల్సిన రెండో connection లేదు. Pathలో colon ఉన్న cpలా ఇది పనిచేస్తుంది. ఆ interface దాని protocolను నాలుగు దశాబ్దాలపాటు మించి కొనసాగింది.

SSH మొత్తం వర్గాన్నే భర్తీ చేస్తుంది

1995లో Helsinki University of Technologyలో పరిశోధకుడిగా ఉన్న Tatu Ylonen, విశ్వవిద్యాలయ networkపై జరిగిన password-sniffing దాడికి ప్రతిస్పందనగా SSHను రాశారు. 1995 జూలైలో source codeతో పాటు దాన్ని free softwareగా విడుదల చేశారు. అదే సంవత్సరం చివరికి 50 దేశాల్లో సుమారు 20,000 మంది users ఉన్నారని అంచనా వేశారు. 1995 డిసెంబరులో దాని అభివృద్ధిని కొనసాగించేందుకు SSH Communications Securityని స్థాపించారు.

తరువాతి versionsలో licence నిబంధనలు కఠినమయ్యాయి. అందువల్ల OpenBSD developers చివరిగా freely licensedగా ఉన్న release, ssh 1.2.12ను fork చేశారు. Initial import 26 September 1999న జరిగింది. OpenSSH 1.2.2, OpenBSD 2.6తో కలిసి 1 December 1999న విడుదలైంది. open source licensing terms ఆచరణలో ఎందుకు ముఖ్యమో చెప్పే సంక్షిప్త ఉదాహరణగా ఈ fork నిలుస్తుంది. ప్రస్తుతం దాదాపు అందరూ ఉపయోగించే SSH implementation, licence ఇంకా అనుమతించిన ఆ version నుంచే ఉద్భవించింది.

SSH వచ్చిన తరువాత file transfer ప్రత్యేక సమస్యగా మిగలలేదు. ఇప్పటికే authenticated, encrypted streamలో అనేక channels ఉంటాయి. అందువల్ల పాత protocols స్వయంగా నిర్మించాల్సిన integrity, ordering, అలాగే రెండో TCP connection అవసరం లేని ప్రత్యేక data path అందులోనే ఉన్నాయి. ఈ విధానం మీకు కొత్తైతే, ముందుకు వెళ్లే ముందు SSH వాస్తవంగా ఏమిటో తెలుసుకోవడం నుంచి ప్రారంభించండి.

దీనివల్ల రెండు tools వచ్చాయి. scp అనేది SSH sessionలో నడిచే rcp wire protocol. అందుకే దాని command line rcpదానిలాగే ఉంది. SFTP వేరే రూపకల్పన. ఇది directory listing, file attributes, random access కలిగిన నిజమైన file protocol. ఇది SSH channelపై ప్రసారం అవుతుంది. SFTP ఎప్పుడూ RFC కాలేదు. IETF draft, draft-ietf-secsh-filexfer, 18 July 2006న version 13కు చేరి తరువాత expire అయింది. OpenSSH ఆ draftలోని version 3ను అమలు చేస్తుంది. ప్రపంచంలో విస్తృతంగా ఉపయోగించే secure file transfer protocol, abandon అయిన draftలోని numbered revision. అయినప్పటికీ అది పనిచేస్తుంది.

పాత scp protocol కూడా ఇప్పుడు నిలిపివేయబడింది. 26 September 2021న విడుదలైన OpenSSH 8.8, "OpenSSH యొక్క సమీప భవిష్యత్ releaseలో scp(1), legacy scp/rcp protocolను ఉపయోగించడం నుంచి మారి, defaultగా SFTPను ఉపయోగిస్తుంది" అని హెచ్చరించింది. 8 April 2022న విడుదలైన OpenSSH 9.0లో అది అమలైంది: "ఈ releaseలో scp(1), legacy scp/rcp protocolను ఉపయోగించడం నుంచి మారి, defaultగా SFTP protocolను ఉపయోగిస్తుంది."

దీనికి కారణం ఒక ప్రాచుర్యంలో ఉన్న భావనను వివరిస్తుంది. పాత scp protocol remote filename wildcardsను remote shellకు అప్పగించి expand చేసేది. అందుకే remote pathలోని ప్రతి metacharacterను double quotesలో ఉంచాలని users నేర్చుకున్నారు. 8.8 notes ప్రకారం, 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 మాత్రం, ఈ ఫైల్‌లో ఎంత భాగం అవతలి వైపు ఇప్పటికే ఉందో అడిగింది. లక్ష్యం "తక్కువ bandwidth, అధిక latency కలిగిన ద్విదిశా communications link" అని నివేదిక పేర్కొంది. అలాగే, "source fileలోని ఏ భాగాలు destination fileలోని ఏదైనా భాగంతో ఒకేలా ఉన్నాయో" గుర్తించి, సరిపోని భాగాలను మాత్రమే పంపడం లక్ష్యంగా వివరించింది.

ఈ విధానం అర్థం చేసుకోవడం ఉపయోగకరం. ఇది rsync ప్రవర్తనను వివరిస్తుంది. Receiver తన వద్ద ఉన్న కాపీని స్థిర పరిమాణం గల blocksగా విభజిస్తుంది. ప్రతి blockకు రెండు checksums లెక్కిస్తుంది: ఒకటి బలహీనమైనది మరియు త్వరగా లెక్కించగలిగేది; మరొకటి బలమైనది మరియు ఎక్కువ ఖర్చుతో లెక్కించేది. ఆ జాబితాను senderకు పంపుతుంది. Sender తన ఫైల్‌పై ఒక byte చొప్పున windowను కదిలిస్తూ weak checksumను incrementalగా update చేస్తుంది. అందువల్ల byte-by-byte scan చేయడం సాధ్యమవుతుంది. Weak matchను strong checksumతో నిర్ధారిస్తుంది. నిర్ధారించబడిన matches block referencesగా మారతాయి. మిగిలిన ప్రతిదీ literal bytesగా పంపబడుతుంది. Receiver, తన వద్ద ఇప్పటికే ఉన్న blocksకు సంబంధించిన referencesను, ఇప్పుడే అందుకున్న literalsతో కలిపి ఫైల్‌ను మళ్లీ నిర్మిస్తుంది.

పెద్ద ఫైల్ ప్రారంభంలో ఒక byte చొప్పిస్తే, naive difference tool మొత్తం ఫైల్‌ను పంపాలి. కారణం ప్రతి offset మారుతుంది. Rolling window కొత్త offsets వద్ద ఉన్న అదే blocksను గుర్తిస్తుంది. అందువల్ల rsync ఒక byteతో పాటు కొంత bookkeeping మాత్రమే పంపుతుంది. మీరు ఒక directoryని ఒకసారి కంటే ఎక్కువసార్లు copy చేయబోతే, rsync ఇప్పటికీ సరైన toolగా ఉండటానికి ఇదే కారణం.

రెండు ప్రవర్తనలు తరచుగా వినియోగదారులను ఆశ్చర్యపరుస్తాయి. రెండూ manualలో ఉన్నాయి. మొదటిది, ఏ filesను పరిశీలించాలో నిర్ణయించడానికి rsync filesపై checksumను లెక్కించదు. అది "డిఫాల్ట్‌గా 'quick check' algorithmను ఉపయోగించి, size లేదా last-modified time మారిన filesను గుర్తించి transfer చేయాల్సిన filesను కనుగొంటుంది". File contents మారినా size మరియు timestamp ఒకేలా ఉంటే ఆ fileను skip చేస్తుంది. --checksum ఈ ప్రవర్తనను మార్చుతుంది. అప్పుడు రెండు వైపులా ప్రతి candidate fileను పూర్తిగా చదువుతాయి. రెండవది, రెండు paths localగా ఉన్నప్పుడు delta algorithm defaultగా off ఉంటుంది. ఒకే machineలో రెండు copiesను చదివి checksums లెక్కించడం కంటే bytesను copy చేయడానికి తక్కువ ఖర్చవుతుంది. Link నెమ్మదిగా ఉన్నప్పుడు మాత్రమే ఈ ఆదా ఉంటుంది.

VPSలో మీరు వాస్తవంగా ఏ సాధనాన్ని ఎందుకు ఉపయోగిస్తారు

సంక్షిప్తంగా: కొన్ని ఫైళ్ల కోసం SFTP, మళ్లీ కాపీ చేయాల్సిన directory కోసం SSHపై rsync.

రెండూ SSHపై పనిచేస్తాయి. అందువల్ల అదనపు configuration లేకుండానే host key verification మరియు encryption రెండింటినీ పొందుతాయి. ఇది దశాబ్దాల పనిని ఒక defaultలో సమీకరించినట్లే. Kermit రూపకర్తలు network line dataను పాడుచేయవచ్చని భావించాలి. అందుకే వారు protocolలో checksums మరియు retransmissionను నిర్మించారు. ఇప్పుడు ఆ పనిని TCP చేస్తుంది. Christensen మరియు Forsberg ప్రతి byteకు ఖర్చు ఉంటుందని భావించాలి. అందుకే వారు resume మరియు streamingను నిర్మించారు. ఇప్పుడు rsync యొక్క delta algorithm అదే పని చేస్తుంది, ఇంకా మెరుగ్గా చేస్తుంది. FTP రూపకర్తలు పరస్పరం సహకరించే hosts ఉన్న networkను ఊహించారు. Protocolను ఎంత అభివృద్ధి చేసినా సరిచేయలేని విధంగా తప్పుగా తేలినది ఆ ఊహ ఒక్కటే.

ఏ checksums ఇప్పటికీ ఉపయోగపడతాయి

ఈ చరిత్రలో "checksum" అనే పదం మూడు వేర్వేరు పనులకు ఉపయోగించబడింది. అవి పరస్పరం మార్పిడి చేయలేనివి.

Kermit మరియు XMODEM లోని ప్రతి packet checksumలు network మార్గంలో జరిగిన data corruption ను గుర్తించేవి. ప్రస్తుతం TCP checksum మరియు link layer లోని error correction ఆ పనిని నిర్వహిస్తున్నాయి. అందుకే ఆధునిక transfer tool ఏదీ దాని గురించి మీరు ఆలోచించమని అడగదు.

rsync యొక్క block checksumలు "ఈ data సరైనదేనా" అనే ప్రశ్నకు సమాధానం ఇవ్వవు. "ఈ block మీ వద్ద ఇప్పటికే ఉందా" అనే ప్రశ్నకు సమాధానం ఇస్తాయి. అక్కడ strong checksum ఒక lookup key మాత్రమే. ఆ file ఎక్కడి నుంచి వచ్చిందో తెలిపే ఆధారం కాదు.

మూడవ పని మాత్రం ఇప్పటికీ మీ బాధ్యత. release file పై ప్రచురించిన checksum, TLS సమాధానం ఇవ్వలేని ప్రశ్నకు సమాధానం ఇస్తుంది. మీరు సరైన server తోనే మాట్లాడుతున్నారని TLS నిర్ధారిస్తుంది. కానీ ఆ server పై సరైన file ఉందని అది నిర్ధారించదు. mirror నుంచి తీసుకున్న file కు కూడా అది ఏమీ చేయదు. అందుకే release checksums మరియు signatures కోసం ముప్పై seconds కేటాయించడం ఇప్పటికీ విలువైనదే. ఈ అలవాటును ఏర్పరచుకోవడం కూడా సులభమే: మీరు install చేసే ప్రతి download యొక్క checksum ను తనిఖీ చేయండి.

ఈ వివరణలోని మిగతా సమస్యలన్నీ దిగువ layer ద్వారా పరిష్కరించబడ్డాయి. ఈ ఒక్క సమస్య మాత్రం పరిష్కరించబడలేదు. ఎందుకంటే ఇది ఎప్పుడూ network సమస్య కాదు.

FAQ

VPS లో FTP ఉపయోగించడం ఇప్పటికీ సురక్షితమేనా?

కాదు. సాధారణ FTP credentials మరియు ఫైల్ కంటెంట్‌ను cleartext గా పంపుతుంది. అందువల్ల మార్గంలో ఉన్న ఎవరైనా రెండింటినీ చదవగలరు. FTP తన control channel ను parse చేసే firewall పై కూడా ఆధారపడుతుంది. మీరు control channel ను TLSతో encrypt చేసిన వెంటనే అది సాధ్యం కాదు. Browsers ఇప్పటికే FTPను తొలగించాయి: Firefox 2021 Julyలో version 90లో FTP support ను తొలగించింది. Chrome 2021 Octoberలో version 95లో ఆ codeను తొలగించింది. బదులుగా SSHపై SFTP ఉపయోగించండి. దీనికి ఒక port మాత్రమే అవసరం. Protocol-aware middlebox అవసరం లేదు.

FTPకు passive mode ఎందుకు అవసరం?

FTP యొక్క అసలు modeలో server data connection ను client వైపు తిరిగి తెరుస్తుంది. RFC 959 ప్రకారం server యొక్క default data port, control connection portకు పక్కన ఉన్న port అయి ఉంటుంది: “the port adjacent to the control connection port (i.e., L-1)”. అందువల్ల control port 21 అయితే data port 20 అవుతుంది. NAT (network address translation) వెనుక ఉన్న clientను server చేరుకోగల address కలిగి ఉండదు. కాబట్టి ఆ connection ఎప్పటికీ చేరదు, transfer నిలిచిపోతుంది. PASV దిశను మార్చుతుంది. Server బదులుగా listen చేస్తుంది. Client connect కావడానికి address మరియు portను 227 Entering Passive Mode replyలో పంపుతుంది.

scp ఇప్పటికీ తన స్వంత protocolను ఉపయోగిస్తుందా?

OpenSSH 9.0 నుంచి కాదు. ఇది 8 April 2022న విడుదలైంది. ఆ version “switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default”. OpenSSH 8.8 ఈ మార్పును September 2021లో ప్రకటించింది. కనిపించే ప్రధాన తేడా quotingలో ఉంటుంది. పాత protocol remote wildcardsను remote shellకు పంపి expand చేసేది. SFTP ఆధారిత protocol అలా చేయదు. అందువల్ల ఆ shell expansionపై ఆధారపడిన paths ఇప్పుడు భిన్నంగా పనిచేస్తాయి.

VPS కోసం scp కంటే rsync ఎప్పుడు మెరుగైనది?

మీరు అదే treeను ఒకసారి కంటే ఎక్కువసార్లు copy చేయాల్సి ఉన్నప్పుడు. Destination వద్ద ఇప్పటికే లేని ప్రతి file భాగాలను మాత్రమే rsync పంపుతుంది. అందువల్ల రెండవ copy మొదటి copy కంటే చాలా తక్కువ ఖర్చుతో పూర్తవుతుంది. Destination ఇంతకు ముందు చూడని ఒకే file కోసం scp మరియు rsync దాదాపు సమానమైన bytesను పంపుతాయి. అలాంటి సందర్భంలో scp సరళమైనది. Defaultగా rsync ఏది పరిశీలించాలో size మరియు modification time ఆధారంగా నిర్ణయిస్తుంది. కాబట్టి file content మారినా size మరియు timestamp మారకపోతే, rsync దానిని గుర్తించే ముందు --checksum అవసరం.

Kermit filesను raw bytesగా పంపకుండా printable textగా ఎందుకు encode చేసింది?

ఎందుకంటే అది ఉపయోగించిన connection byte pipe కాదు. అది mainframeకు వెళ్లే terminal line. ఆ links 7-bitగా ఉండవచ్చు. Mainframe యొక్క terminal driver control charactersను pass through చేయకుండా వాటిపై చర్య తీసుకునేది. మధ్యలో ఉన్న ఏ భాగమూ వాటిపై స్పందించకుండా ఉండేందుకు Kermit control bytes మరియు high-bit bytesను printable charactersగా encode చేసింది. దీనివల్ల networkపై binary files పెద్దవిగా మారాయి. అయితే లేకపోతే transfer corruptedగా చేరే ప్రమాదంతో పోలిస్తే ఇది సరైన trade-off.