Kermit سے rsync تک فائل منتقلی کے پروٹوکول

فائل منتقلی کے پروٹوکول مسلسل کیوں تبدیل ہوتے رہے

فائل منتقلی کے ہر پروٹوکول کو اس کی دہائی کے مخصوص failure mode کے مقابلے کے لیے ڈیزائن کیا گیا تھا۔ Kermit نے فرض کیا کہ لائن آپ کے bytes کو خراب کر دے گی۔ XMODEM اور ZMODEM نے فرض کیا کہ connection سست ہے اور ہر منٹ کے استعمال کی قیمت ادا کرنی پڑتی ہے۔ FTP (file transfer protocol) نے فرض کیا کہ درمیان کا network تعاون کرے گا۔ SSH نے فرض کیا کہ network hostile ہے۔ آخری مفروضہ کامیاب رہا۔ اسی لیے آج ایک VPS آپ کو SSH کے ذریعے SFTP اور rsync فراہم کرتا ہے، اور اس کے علاوہ بہت کم اختیارات ہوتے ہیں۔

اب اس موضوع کا جائزہ لینے کی ایک وجہ موجود ہے۔ C-Kermit 11.0.506، 3 August 2026 کو release ہوا۔ یہ 20 August 2011 کو جاری ہونے والے C-Kermit 9.0.302 کے بعد پہلی non-beta release ہے، اور اس میں نافذ کیا گیا پروٹوکول May 1981 میں ڈیزائن ہوا تھا۔ پینتالیس سال اتنا طویل عرصہ ہے کہ اس دوران ایک مکمل category ایجاد ہو، standardise ہو، جس network پر وہ چل رہی ہو اسی سے متاثر ہو کر ناکام ہو، اور پھر SSH میں شامل ہو جائے۔

Kermit، 1981: ایسی لائن کے لیے بنایا گیا جو آپ کے bytes ضائع کر دیتی تھی

Kermit کو مئی 1981 میں Columbia University Computer Center میں Frank da Cruz اور Bill Catchings نے بنایا۔ اس کا نام Kermit the Frog سے لیا گیا ہے۔ Da Cruz کے مطابق، جب گروپ نام سوچنے کی کوشش کر رہا تھا تو دیوار پر Muppets کا calendar لگا ہوا تھا، اور کسی کو توقع نہیں تھی کہ یہ چیز اتنی پھیل جائے گی۔

Kermit نے جس مسئلے کو حل کیا، وہ رفتار کا مسئلہ نہیں تھا۔ terminal اور mainframe کے درمیان راستہ من مانے bytes کے لیے pipe نہیں تھا۔ یہ ایک ایسا character device تھا جس کے اپنے قواعد تھے۔ یہ 7-bit ہو سکتا تھا۔ یہ half duplex ہو سکتا تھا۔ یہ control characters کو ضائع کر سکتا تھا، یا ان میں سے کسی ایک کو command سمجھ کر اس پر عمل کر سکتا تھا۔ binary file کو بغیر تبدیلی کے اس کے ذریعے بھیجنا ممکن نہیں تھا۔

اس لیے design نے ان پابندیوں کو براہ راست بنیاد بنایا۔ Kermit Project کی اپنی history میں یہ نکات درج ہیں:

• مختصر packets، کیونکہ زیادہ تر mainframes terminal سے آنے والے data کے طویل bursts وصول نہیں کر سکتے تھے
• half-duplex stop-and-wait، کیونکہ IBM mainframes full-duplex communication کو support نہیں کرتے تھے
• control characters اور 8-bit characters کے لیے printable encodings، کیونکہ دونوں mainframe کے terminal driver سے گزر نہیں سکتے تھے
• ہر packet پر checksum، جس کا receiver جواب دیتا تھا، تاکہ corrupted 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 ہی دکھائی دیتا ہے۔ اس کی قیمت size ہے: binary file network پر بڑھ جاتی ہے۔ ایسے mainframe front end کے مقابلے میں جو ورنہ transfer کو مکمل طور پر خراب کر دیتا، یہ درست trade-off تھا۔

Kermit کی ایک اور غیر معمولی خصوصیت اس کا scope ہے۔ XMODEM دو ایسی machines کے درمیان file منتقل کرتا تھا جو پہلے ہی اس بات پر متفق تھیں کہ file کیا ہوتی ہے۔ Kermit کو ایسے systems کے درمیان least common denominator کے طور پر لکھا گیا تھا جو اس معاملے پر متفق نہیں تھے، اور جن کے character sets، record structures اور text line کے اختتام کے تصورات مختلف تھے۔ یہی وہ دنیا ہے جسے mainframes سے cloud servers تک کی طویل منتقلی میں بیان کیا گیا ہے، اور network layer کے یہ کام سنبھالنے سے پہلے interoperability اسی طرح دکھائی دیتی تھی۔

Columbia نے 2011 میں اپنی sponsorship ختم کی اور C-Kermit کو revised 3-clause BSD licence کے تحت جاری کیا۔ Frank da Cruz نے 1981 کے design سے 2025 تک 44 سال project کے ساتھ کام کیا۔ 2026 release کو OpenKermit project maintain کرتا ہے، اور John Goerzen ایسے C codebase کو جدید بنانے کا کام کر رہے ہیں جو اب اسے پڑھنے والے زیادہ تر لوگوں سے بھی پرانا ہے۔

XMODEM اور ZMODEM: جب phone bill نے design کی شکل متعین کی

Ward Christensen نے 1977 میں MODEM.ASM لکھا، اور اس میں متعارف کرایا گیا protocol XMODEM ہے۔ 1978 میں انہوں نے Randy Suess کے ساتھ CBBS کو online کیا، جو پہلا public bulletin board system تھا۔ Christensen کا انتقال 11 October 2024 کو ہوا۔

XMODEM تقریباً اتنا ہی مختصر ہے جتنا کوئی protocol ہو سکتا ہے۔ Data، 128-byte blocks میں منتقل ہوتا ہے۔ ہر block میں ایک-byte checksum شامل ہوتا ہے، جو 128 data bytes کے مجموعے کو modulo 256 کرنے سے حاصل ہوتا ہے۔ Receiver ہر block کو acknowledge کرتا ہے یا اسے دوبارہ بھیجنے کی درخواست کرتا ہے۔ اس ساخت کی وجہ معاشیات ہے۔ Dial-up line پر وقت کے حساب سے ادائیگی ہوتی ہے، اس لیے line error کی صورت میں پوری transfer کے بجائے صرف ایک block دوبارہ بھیجنا پڑے۔

کمزوری بھی اسی وضاحت میں موجود ہے۔ XMODEM ہر 128 bytes کے بعد acknowledgement کا انتظار کرتا ہے۔ Chuck Forsberg نے ZMODEM specification میں اسے واضح طور پر بیان کیا: "The short block length causes throughput to suffer when used with timesharing systems, packet switched networks, satellite circuits." Stop-and-wait کو bandwidth نہیں بلکہ latency متاثر کرتی ہے۔ ہر round trip ایسی line پر خاموش وقت ہوتا ہے جس کے لیے آپ ادائیگی کر رہے ہوتے ہیں۔

اس کے بعد YMODEM آیا، اور Ward Christensen نے 1985 میں یہ نام وضع کیا۔ اس کی اہم خصوصیت batch transfer تھی۔ Sender، data سے پہلے filename اور size بتاتا ہے، اس لیے ایک ہی session میں کئی files منتقل کی جا سکتی ہیں اور receiver کو معلوم رہتا ہے کہ ہر file کہاں ختم ہوتی ہے۔

ZMODEM، Chuck Forsberg کا جواب ہے، جسے انہوں نے Omen Technology میں لکھا۔ Specification کی revision date 14 October 1988 ہے، اور اس میں بیان کیا گیا ہے کہ "ZMODEM was developed for the public domain under a Telenet contract". Telenet ایک public packet-switched data network چلاتا تھا، اور اس contract کا اثر design میں نظر آتا ہے۔ ZMODEM network control characters کو escape کرتا ہے تاکہ درمیان میں موجود packet network انہیں consume نہ کرے۔ یہ ہر frame کے آغاز کو silence سے frame boundaries اخذ کرنے کے بجائے character sequence سے واضح کرتا ہے، اس لیے timeout مکمل ہونے کا انتظار کیے بغیر noise سے recover کر لیتا ہے۔ اس میں explicit resume بھی موجود ہے، اس لیے interrupted transfer وہیں سے دوبارہ شروع ہوتی ہے جہاں رکی تھی۔

سب سے اہم بات یہ ہے کہ یہ انتظار ختم کر دیتا ہے۔ Specification کی اپنی وضاحت کے مطابق، "ZMODEM in effect uses the entire file as a window". Sender data stream کرتا ہے اور صرف اس وقت رکتا ہے جب receiver کسی مسئلے کی اطلاع دے۔ یہی insight TCP اپنے window میں encode کرتا ہے، لیکن اس تک دوسری سمت سے پہنچا گیا: ایک ایسے شخص نے جو modem کو idle بیٹھا دیکھ رہا تھا۔

FTP کے دو connections اتنے ناقابلِ عمل کیوں ہو گئے

FTP ان سب سے پرانا ہے۔ RFC 114، جس کا عنوان "A File Transfer Protocol" ہے، 16 April 1971 کی تاریخ رکھتا ہے اور اسے A. Bhushan نے تحریر کیا تھا۔

قابلِ توجہ بات یہ ہے کہ RFC 114 نے دو connections کے design پر غور کیا اور اسے مسترد کر دیا۔ Bhushan نے "using two full-duplex links, one for control information, the other for data" کا جائزہ لیا، پھر نتیجہ اخذ کیا: "We recommend using a single full-duplex connection for the exchange of both data and control information." یہ تقسیم بعد میں شامل ہوئی۔ 8 July 1972 کے RFC 354 میں کہا گیا ہے کہ "data and files are transferred only via the data connection"، جبکہ commands الگ Telnet connection پر بھیجی جاتی ہیں۔ Postel اور Reynolds کا October 1985 کا RFC 959 وہ version ہے جسے آج بھی سب implement کرتے ہیں۔

RFC 959 نے ports بھی مقرر کر دیے۔ Server کا default data port "the port adjacent to the control connection port (i.e., L-1)" ہے، یعنی جب control connection port 21 ہو تو data port 20 ہے۔

اصل مسئلہ یہ تھا کہ FTP کے ابتدائی mode میں server client کی طرف data connection کھولتا ہے۔ NAT (network address translation) کے پیچھے موجود client کا ایسا address نہیں ہوتا جس تک server پہنچ سکے۔ Firewall کے پیچھے موجود client inbound connections قبول نہیں کرتا۔ اس لیے data connection کبھی نہیں پہنچتی، اور جیسے ہی listing یا file طلب کی جاتی ہے، transfer رک جاتا ہے۔ اس کا حل PASV تھا۔ RFC 959 میں PASV کو ایسی درخواست کے طور پر بیان کیا گیا ہے جس میں server سے کہا جاتا ہے کہ وہ "listen" کرے ایک data port پر، جو اس کا default data port نہیں ہوتا، اور transfer command ملنے پر خود connection شروع کرنے کے بجائے connection کا انتظار کرے۔ Server اس port سے connect کرنے کے لیے address اور port بھیجتا ہے:

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

اس reply کا مطلب ہے host 203.0.113.10، اور port 195 کو 256 سے ضرب دے کر اس میں 80 جمع کیا جائے، تو نتیجہ 50000 آتا ہے۔ اسے دوبارہ پڑھیں تو ساختی مسئلہ واضح ہو جاتا ہے۔ دوسری connection کا endpoint پہلی connection کے payload کے اندر بتایا جاتا ہے۔ NAT box یا firewall اس connection کو اسی وقت آگے بھیج سکتا ہے جب وہ control channel کو parse کرے اور اس میں موجود port کھولے۔ Linux ایک connection tracking helper فراہم کرتا ہے جو بالکل یہی کام کرتا ہے۔ یہ helper صرف اس وقت کام کرتا ہے جب control connection cleartext میں ہو۔ اس لیے FTP کو TLS (transport layer security) میں wrap کرنے سے وہ middlebox اندھا ہو جاتا ہے جو FTP کو قابلِ استعمال بنا رہا تھا۔

FTP کا سبق ایک جملے میں یہ ہے: اس نے network کو protocol کا حصہ بنا دیا۔ جس protocol کو سمجھنے کے لیے network کی ضرورت ہو، وہ ایسے network میں قائم نہیں رہ سکتا جو اس protocol پر اعتماد کرنا چھوڑ دے۔

اختتام ریکارڈ پر موجود ہے۔ Firefox نے July 2021 میں version 90 کے ساتھ FTP support ہٹا دی۔ Chrome نے October 2021 میں Chrome 95 کے ساتھ FTP code ہٹا دیا۔

rcp اور r-commands: hostname کے ذریعے اعتماد

4.2BSD، جسے Berkeley نے DARPA کی مالی معاونت سے 1983 میں جاری کیا، rcp، rsh اور rlogin لے کر آیا۔ یہ ایک ہی network پر موجود Unix مشینوں کے campus کے لیے بنائے گئے تھے، اور authentication model سے یہ بات واضح ہوتی ہے۔ ایک host یہ دعویٰ کرتا تھا کہ کون سا user درخواست کر رہا ہے۔ اگر /etc/hosts.equiv یا کسی user کا ~/.rhosts یہ کہتا کہ مذکورہ host قابلِ اعتماد ہے، تو اس دعوے کو قبول کر لیا جاتا تھا اور password نہیں مانگا جاتا تھا۔

اس mechanism کو واضح طور پر سمجھیں، کیونکہ یہی وجہ ہے کہ یہ commands اب استعمال نہیں ہوتیں۔ اعتماد ایک address اور ایک دعوے پر مبنی تھا۔ دونوں network پر cleartext میں منتقل ہوتے تھے، اس لیے راستے میں موجود کوئی بھی شخص انہیں پڑھ سکتا تھا، اور وہیں موجود کوئی بھی شخص انہیں جعل سازی سے بنا سکتا تھا۔ Unix سے Linux تک کا راستہ میں بیان کردہ environment میں یہ model قابلِ فہم تھا، کیونکہ network ایک عمارت تک محدود تھا۔ جیسے ہی network internet بنا، یہ model ناقابلِ عمل ہو گیا۔

rcp کی درست بات اس کا interface تھا۔ source، destination، اور کام مکمل۔ کوئی session کھولنے کی ضرورت نہیں، transfer mode negotiate کرنے کی ضرورت نہیں، اور دوسری connection قائم کرنے کی ضرورت نہیں۔ یہ cp کی طرح کام کرتا ہے، بس path میں colon شامل ہوتا ہے۔ یہ interface اپنے protocol سے چار دہائیاں زیادہ عرصے تک برقرار رہا۔

SSH نے پورے زمرے کو سمیٹ لیا

1995 میں Helsinki University of Technology کے محقق Tatu Ylonen نے یونیورسٹی کے network پر password-sniffing حملے کے جواب میں SSH لکھا۔ انہوں نے اسے source code سمیت free software کے طور پر July 1995 میں جاری کیا۔ اسی سال کے اختتام تک اندازاً 50 ممالک میں تقریباً 20,000 users تھے، اور December 1995 میں انہوں نے اسے مزید develop کرنے کے لیے SSH Communications Security قائم کی۔

بعد کے versions کے ساتھ licence کی شرائط سخت ہو گئیں، اس لیے OpenBSD developers نے آخری آزاد licence والی release، ssh 1.2.12، کا fork بنایا۔ ابتدائی import 26 September 1999 کو ہوا، اور OpenSSH 1.2.2، OpenBSD 2.6 کے ساتھ 1 December 1999 کو جاری کیا گیا۔ یہ fork اس بات کا مختصر عملی جائزہ ہے کہ open source licensing terms عملی طور پر کیوں اہم ہوتی ہیں، کیونکہ آج تقریباً ہر جگہ استعمال ہونے والی SSH implementation اسی ایک version سے نکلی ہے جس کی licence نے اب بھی اس کی اجازت دی تھی۔

SSH کے وجود میں آنے کے بعد file transfer الگ مسئلہ نہیں رہا۔ ایک authenticated، encrypted stream، جس میں متعدد channels ہوں، پہلے کے protocols کی مطلوبہ سہولتیں پہلے ہی فراہم کرتی ہے: integrity، ordering، اور دوسرا data path جس کے لیے دوسری TCP connection درکار نہیں ہوتی۔ اگر یہ طریقۂ کار آپ کے لیے نیا ہے تو آگے بڑھنے سے پہلے سمجھیں کہ SSH اصل میں کیا ہے۔

اس سے دو tools سامنے آئے۔ scp، SSH session کے اندر چلنے والا rcp کا wire protocol تھا، اسی لیے اس نے rcp کی command line بعینہٖ برقرار رکھی۔ SFTP ایک مختلف design ہے: یہ 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 کو implement کرتا ہے۔ دنیا میں سب سے زیادہ استعمال ہونے والا secure file transfer protocol ایک abandoned draft کی numbered revision ہے، اور یہ کام کرتا ہے۔

legacy scp protocol بھی اب retire ہو چکا ہے۔ 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-quote کرنے کی عادت سیکھی۔ 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 کا اعلان کیا۔ اس کے ساتھ تکنیکی رپورٹ TR-CS-96-05، "The rsync algorithm"، بھی جاری کی گئی۔

اس سے پہلے ہر protocol یہ پوچھتا تھا کہ فائل کو خراب کیے بغیر کیسے منتقل کیا جائے۔ rsync نے یہ پوچھا کہ دوسری جانب اس فائل کا کتنا حصہ پہلے سے موجود ہے۔ رپورٹ میں ہدف کو "a low-bandwidth high-latency bi-directional communications link" کے طور پر بیان کیا گیا ہے۔ مقصد یہ تھا کہ "parts of the source file which are identical to some part of the destination file" کی شناخت کی جائے، تاکہ صرف غیر مماثل حصے بھیجے جائیں۔

اس طریقۂ کار کو سمجھنا مفید ہے، کیونکہ اس سے rsync کا رویہ واضح ہوتا ہے۔ وصول کنندہ اپنی موجودہ copy کو مقررہ سائز کے blocks میں تقسیم کرتا ہے اور ہر block کے لیے دو checksums بناتا ہے: ایک کمزور اور تیز، دوسرا مضبوط اور نسبتاً سست۔ وہ یہ فہرست بھیجنے والے کو بھیج دیتا ہے۔ بھیجنے والا اپنی فائل پر ایک window کو ایک وقت میں ایک byte کے حساب سے آگے بڑھاتا ہے اور weak checksum کو incremental طریقے سے update کرتا ہے۔ اسی وجہ سے byte-by-byte scan قابلِ عمل رہتا ہے۔ weak match کی پھر strong checksum سے تصدیق کی جاتی ہے۔ تصدیق شدہ matches، block references بن جاتے ہیں۔ باقی تمام مواد literal bytes کے طور پر بھیجا جاتا ہے۔ وصول کنندہ پہلے سے موجود blocks کے references اور ابھی موصول ہونے والے literals کو ملا کر فائل دوبارہ بناتا ہے۔

اگر بڑی فائل کے آغاز میں ایک byte شامل کر دیا جائے تو ایک سادہ difference tool کو پوری فائل بھیجنی پڑتی ہے، کیونکہ ہر offset بدل جاتا ہے۔ rolling window نئے offsets پر وہی blocks تلاش کر لیتا ہے۔ اس لیے rsync صرف ایک byte اور متعلقہ bookkeeping بھیجتا ہے۔ اسی خصوصیت کی وجہ سے rsync آج بھی ایسی directory کے لیے موزوں ہے جسے آپ ایک سے زیادہ مرتبہ copy کریں گے۔

دو رویے اکثر لوگوں کو حیران کرتے ہیں، اور دونوں manual میں درج ہیں۔ اول، rsync یہ فیصلہ کرنے کے لیے files کا checksum نہیں بناتا کہ ان کا جائزہ لینا ہے یا نہیں۔ یہ "finds files that need to be transferred using a 'quick check' algorithm (by default) that looks for files that have changed in size or in last-modified time"۔ اگر فائل کے contents بدل جائیں، لیکن اس کا size اور timestamp یکساں رہیں، تو اسے skip کر دیا جاتا ہے۔ --checksum اس رویے کو بدل دیتا ہے اور دونوں sides کو ہر candidate file مکمل طور پر پڑھنے پر مجبور کرتا ہے۔ دوم، جب دونوں paths local ہوں تو delta algorithm default طور پر بند ہوتا ہے، کیونکہ ایک ہی machine پر دو copies کو پڑھنا اور ان کا checksum بنانا bytes copy کرنے سے زیادہ مہنگا ہوتا ہے۔ بچت صرف اس وقت ہوتی ہے جب link سب سے سست حصہ ہو۔

VPS پر آپ حقیقتاً کس چیز کے لیے رجوع کرتے ہیں، اور کیوں

مختصر جواب: چند فائلوں کے لیے SFTP، اور ایسی directory کے لیے SSH کے ذریعے rsync جسے آپ دوبارہ copy کریں گے۔

دونوں SSH پر چلتے ہیں، اس لیے اضافی configuration کے بغیر دونوں host key verification اور encryption کی خصوصیات حاصل کرتے ہیں۔ یہ پچاس سالہ کام کا ایک default میں سمٹ جانا ہے۔ Kermit کے ڈیزائنرز کو فرض کرنا پڑتا تھا کہ لائن data خراب کر دے گی، اس لیے انہوں نے protocol میں checksums اور retransmission شامل کیے۔ اب TCP یہی کام کرتا ہے۔ Christensen اور Forsberg کو فرض کرنا پڑتا تھا کہ ہر byte کی قیمت ادا کرنا ہوگی، اس لیے انہوں نے resume اور streaming شامل کی۔ اب rsync کا delta algorithm یہی کام کرتا ہے، اور بہتر طور پر کرتا ہے۔ FTP کے مصنفین نے تعاون کرنے والے hosts کے network کو مفروضہ بنایا تھا، اور ان مفروضوں میں صرف یہی مفروضہ ایسا نکلا جو غلط ثابت ہونے کے بعد protocol پر کی جانے والی کسی بھی مقدار کی محنت سے درست نہیں کیا جا سکا۔

اب بھی checksums کس کام آتے ہیں

اس پوری تاریخ میں "checksum" نے تین مختلف کام کیے ہیں، اور یہ کام ایک دوسرے کا متبادل نہیں ہیں۔

Kermit's اور XMODEM کے فی-packet checksums نے wire پر ہونے والی خرابی کا سراغ لگایا۔ آج TCP checksum اور link layer کی error correction یہ کام انجام دیتے ہیں، اسی لیے کوئی جدید transfer tool آپ سے اس بارے میں سوچنے کو نہیں کہتا۔

rsync کے block checksums اس سوال کا جواب نہیں دیتے کہ "کیا یہ data درست ہے"۔ وہ یہ بتاتے ہیں کہ "کیا آپ کے پاس یہ block پہلے سے موجود ہے"۔ یہاں strong checksum ایک lookup key ہوتا ہے، یہ اس بات کا بیان نہیں ہوتا کہ file کہاں سے آئی ہے۔

تیسرا کام اب بھی آپ کو خود کرنا ہے۔ کسی release file پر شائع کیا گیا checksum ایسے سوال کا جواب دیتا ہے جس کا TLS جواب نہیں دے سکتا۔ TLS یہ ثابت کرتا ہے کہ آپ نے درست server سے رابطہ کیا۔ یہ ثابت نہیں کرتا کہ درست file اسی server پر موجود تھی، اور mirror سے حاصل کی گئی file کے لیے یہ کچھ بھی نہیں کرتا۔ اسی لیے release checksums اور signatures پر تیس seconds صرف کرنا اب بھی مفید ہے، اور یہ عادت بنانا آسان ہے: ہر install کی جانے والی download کا checksum چیک کریں۔

اس پوری کہانی میں باقی تمام مسائل نیچے والی layer نے حل کر دیے۔ یہ مسئلہ حل نہیں ہوا، کیونکہ یہ کبھی network کا مسئلہ تھا ہی نہیں۔

FAQ

کیا VPS پر FTP اب بھی محفوظ ہے؟

نہیں۔ Plain FTP credentials اور file contents کو cleartext میں بھیجتا ہے، اس لیے راستے میں موجود کوئی بھی شخص دونوں پڑھ سکتا ہے۔ یہ ایسے firewall پر بھی منحصر ہے جو اس کے control channel کو parse کرے، لیکن control channel کو TLS سے encrypt کرتے ہی یہ ممکن نہیں رہتا۔ Browsers نے بھی FTP support ختم کر دی ہے: Firefox نے July 2021 میں version 90 کے ساتھ FTP support ہٹا دی، اور Chrome نے October 2021 میں version 95 کے ساتھ code ہٹا دیا۔ SSH پر SFTP استعمال کریں۔ اسے صرف ایک port درکار ہوتا ہے اور protocol-aware middlebox کی ضرورت نہیں ہوتی۔

FTP کو passive mode کی ضرورت کیوں پیش آتی ہے؟

کیونکہ FTP کے اصل mode میں server، client کی طرف data connection کھولتا ہے۔ 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 کا ایسا address نہیں ہوتا جس تک server پہنچ سکے۔ اس لیے connection کبھی نہیں پہنچتا اور transfer رک جاتا ہے۔ PASV سمت کو الٹ دیتا ہے: server خود listening کرتا ہے، پھر ایک 227 Entering Passive Mode reply میں address اور port بھیجتا ہے تاکہ client اس سے connect ہو سکے۔

کیا scp اب بھی اپنا الگ protocol استعمال کرتا ہے؟

OpenSSH 9.0 کے بعد سے نہیں۔ یہ version 8 April 2022 کو release ہوا اور اس میں "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 ایسا نہیں کرتا۔ اس لیے ایسے paths جو shell expansion پر منحصر تھے، اب مختلف انداز میں کام کرتے ہیں۔

VPS کے لیے rsync، scp سے بہتر کب ہوتا ہے؟

جب آپ ایک ہی tree کو ایک سے زیادہ مرتبہ copy کریں۔ rsync ہر file کے صرف وہ حصے بھیجتا ہے جو destination پر پہلے سے موجود نہیں ہوتے، اس لیے دوسری copy پہلی کے مقابلے میں بہت کم data منتقل کرتی ہے۔ اگر destination نے کسی single file کو پہلے کبھی نہیں دیکھا، تو scp اور rsync تقریباً یکساں bytes منتقل کرتے ہیں اور scp زیادہ سادہ ہے۔ یاد رکھیں کہ rsync بطور default size اور modification time کی بنیاد پر فیصلہ کرتا ہے کہ کس چیز کا جائزہ لینا ہے۔ اس لیے اگر file کے contents تبدیل ہو جائیں، لیکن size اور timestamp تبدیل نہ ہوں، تو rsync کے اسے محسوس کرنے سے پہلے --checksum درکار ہے۔

Kermit نے files کو raw bytes بھیجنے کے بجائے printable text میں encode کیوں کیا؟

کیونکہ یہ ایسے terminal line connection کے لیے بنایا گیا تھا جو mainframe تک جاتا تھا، نہ کہ byte pipe کے لیے۔ یہ links 7-bit ہو سکتے تھے، اور mainframe کا terminal driver control characters پر عمل کرتا تھا، انہیں آگے منتقل نہیں کرتا تھا۔ Kermit نے control bytes اور high-bit bytes کو printable characters میں encode کیا تاکہ درمیان میں موجود کوئی چیز ان پر عمل نہ کرے۔ اس encoding سے network پر binary files بڑی ہو جاتی ہیں، لیکن یہ اس transfer کے مقابلے میں درست سمجھوتا تھا جو بصورت دیگر خراب حالت میں پہنچتا۔