Kermit থেকে rsync: ফাইল স্থানান্তর প্রোটোকলের ইতিহাস

ফাইল স্থানান্তর প্রোটোকলগুলো কেন বারবার পরিবর্তিত হয়েছে

প্রতিটি ফাইল স্থানান্তর প্রোটোকল তার নিজ দশকের নির্দিষ্ট ব্যর্থতার ধরন মোকাবিলার জন্য তৈরি হয়েছিল। Kermit ধরে নিয়েছিল, সংযোগের লাইন আপনার byte নষ্ট করবে। XMODEM এবং ZMODEM ধরে নিয়েছিল, সংযোগ ধীর হবে এবং প্রতি মিনিটের জন্য আপনাকে অর্থ দিতে হবে। 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 release হওয়ার পর এটি প্রথম non-beta release। এটি যে protocol বাস্তবায়ন করে, সেটি May 1981-এ নকশা করা হয়েছিল। Forty-five বছর যথেষ্ট দীর্ঘ সময়। এই সময়ে একটি সম্পূর্ণ category তৈরি হতে, standardised হতে, যে network-এ এটি চলত তার কারণে অকার্যকর হতে এবং পরে SSH-এর মধ্যে অন্তর্ভুক্ত হতে দেখা যায়।

Kermit, 1981: আপনার byte গিলে ফেলা line-এর জন্য তৈরি

Kermit 1981 সালের May মাসে Columbia University Computer Center-এ Frank da Cruz এবং Bill Catchings তৈরি করেন। নামটি এসেছে Kermit the Frog থেকে। Da Cruz-এর বর্ণনা অনুযায়ী, দলটি নাম নিয়ে ভাবার সময় দেয়ালে একটি Muppets calendar ঝোলানো ছিল, এবং কেউই আশা করেনি যে এই জিনিসটি এত ব্যাপকভাবে ছড়িয়ে পড়বে।

Kermit যে সমস্যার সমাধান করেছিল, সেটি speed-এর সমস্যা ছিল না। একটি terminal ও mainframe-এর মধ্যকার path নির্বিচারে byte পাঠানোর pipe ছিল না। এটি ছিল নিজস্ব নিয়মযুক্ত একটি character device। এটি 7-bit হতে পারত। এটি half duplex হতে পারত। এটি control character গিলে ফেলতে পারত, অথবা কোনো একটি control character-কে command হিসেবে কার্যকর করতে পারত। কোনো binary file অপরিবর্তিত অবস্থায় এর মধ্য দিয়ে পাঠালে কাজ করত না।

তাই নকশায় এই সীমাবদ্ধতাগুলো সরাসরি বিবেচনা করা হয়েছিল। Kermit Project-এর নিজস্ব ইতিহাসে এগুলো এভাবে দেওয়া আছে:

• ছোট packet, কারণ অধিকাংশ mainframe terminal থেকে আসা দীর্ঘ incoming data burst গ্রহণ করতে পারত না
• half-duplex stop-and-wait, কারণ IBM mainframe full-duplex communication সমর্থন করত না
• control character এবং 8-bit character-এর জন্য printable encoding, কারণ কোনোটিই mainframe-এর terminal driver-এর মধ্য দিয়ে যেতে পারত না
• প্রতিটি packet-এ checksum, যার জবাব receiver দিত, যাতে corrupted packet-এর জন্য পুরো file নয়, শুধু একটি retransmission প্রয়োজন হয়

তৃতীয় বিষয়টি বিশেষভাবে গুরুত্বপূর্ণ। Kermit file-টি সরাসরি পাঠায় না; এর text-safe encoding পাঠায়। একটি control byte prefix character-এর পরে একটি printable character হিসেবে রূপান্তরিত হয়, এবং high bit set থাকা byte-ও 7-bit link-এর জন্য একইভাবে encode করা যায়। মাঝপথের কোনো system যদি শুধু printable text বোঝে, তাহলেও সেটি printable text-ই দেখতে পায়। এর খরচ হলো size: wire-এর ওপর binary file বড় হয়ে যায়। যে mainframe front end অন্যথায় transfer সম্পূর্ণভাবে বিকৃত করে ফেলত, তার ক্ষেত্রে এটি ছিল সঠিক trade-off।

Kermit-এর আরেকটি অস্বাভাবিক বৈশিষ্ট্য হলো এর scope। XMODEM এমন দুটি machine-এর মধ্যে file স্থানান্তর করত, যারা file বলতে কী বোঝায় সে বিষয়ে আগে থেকেই একমত ছিল। Kermit এমন system-গুলোর মধ্যে least common denominator হিসেবে লেখা হয়েছিল, যাদের character set, record structure এবং text line কোথায় শেষ হয়—এসব বিষয়ে মত এক ছিল না। এই জগতের বর্ণনা আছে mainframe থেকে cloud server-এ দীর্ঘ স্থানান্তরের ইতিহাসে, এবং network layer আপনার হয়ে interoperability পরিচালনা করার আগে Kermit-ই ছিল interoperability-এর বাস্তব রূপ।

Columbia 2011 সালে sponsorship শেষ করে এবং revised 3-clause BSD licence-এর অধীনে C-Kermit প্রকাশ করে। 1981 সালের design থেকে 2025 সাল পর্যন্ত 44 বছর Frank da Cruz এই project-এর সঙ্গে ছিলেন। 2026 release OpenKermit project রক্ষণাবেক্ষণ করছে; John Goerzen এমন একটি C codebase আধুনিক করার কাজ করছেন, যা এখন এটি পড়া অধিকাংশ মানুষের চেয়েও পুরোনো।

XMODEM ও ZMODEM: ফোন বিল কীভাবে নকশাকে প্রভাবিত করেছিল

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 block-এ স্থানান্তরিত হয়। প্রতিটি block-এ একটি one-byte checksum থাকে। এটি 128টি data byte-এর যোগফল, modulo 256। Receiver প্রতিটি block-এর acknowledgement পাঠায় অথবা blockটি আবার পাঠানোর অনুরোধ করে। এই নকশার কারণ অর্থনীতি। Dial-up line-এ সময় অনুযায়ী খরচ হয়। তাই line error হলে পুরো transfer নয়, একটি block পুনরায় পাঠালেই খরচ হয়।

একই বাক্যেই এর দুর্বলতাও আছে। XMODEM প্রতি 128 byte-এর পরে 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-কে ধ্বংস করে latency, bandwidth নয়। প্রতিটি round trip এমন একটি line-এ নিষ্ক্রিয় সময় তৈরি করে, যার জন্য আপনাকে খরচ দিতে হচ্ছে।

এরপর YMODEM আসে। Ward Christensen 1985 সালে এই নামটি তৈরি করেন। এর অবদান ছিল batch transfer। Data পাঠানোর আগে sender filename এবং size জানায়। ফলে একটি session-এ একাধিক file স্থানান্তর করা যায় এবং receiver প্রতিটি file কোথায় শেষ হয়েছে তা বুঝতে পারে।

ZMODEM হলো Omen Technology-এ লেখা Chuck Forsberg-এর উত্তর। Specificationটির revision date 14 October 1988। এতে বলা হয়েছে, "ZMODEM was developed for the public domain under a Telenet contract". Telenet একটি public packet-switched data network পরিচালনা করত। সেই contract-এর প্রভাব নকশায় দেখা যায়। ZMODEM network control character-গুলো escape করে, যাতে মাঝখানের packet network সেগুলো গ্রাস না করে। নীরবতা দেখে frame boundary অনুমান না করে প্রতিটি frame-এর শুরুতে একটি unique character sequence চিহ্নিত করে। ফলে timeout শেষ হওয়ার জন্য অপেক্ষা না করেই noise থেকে recovery করা যায়। এতে explicit resume-ও আছে। তাই interrupted transfer যেখানে থেমেছিল, সেখান থেকেই পুনরায় শুরু হয়।

সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো, এটি অপেক্ষা করা বন্ধ করে। Specification-এর নিজস্ব বর্ণনা হলো, "ZMODEM in effect uses the entire file as a window". Sender data stream করে এবং receiver সমস্যা জানালেই কেবল থামে। TCP তার window-এ একই ধারণা প্রয়োগ করে, তবে বিপরীত দিক থেকে এই ধারণায় পৌঁছানো হয়েছিল—একজন দেখেছিলেন, modem কীভাবে idle অবস্থায় পড়ে থাকে।

FTP-এর দুটি connection কেন এত দ্রুত অচল হয়ে পড়েছিল

FTP অন্য সবগুলোর চেয়ে পুরোনো। RFC 114, “A File Transfer Protocol”, 16 April 1971 তারিখের এবং এটি A. Bhushan লিখেছিলেন।

জানার মতো গুরুত্বপূর্ণ বিষয় হলো, RFC 114-এ দুটি connection-এর নকশা বিবেচনা করে তা প্রত্যাখ্যান করা হয়েছিল। Bhushan “একটি control information-এর জন্য এবং অন্যটি data-এর জন্য দুটি full-duplex link ব্যবহার” করার বিষয়টি পর্যালোচনা করে শেষে বলেন: “data এবং control information উভয় আদান-প্রদানের জন্য একটি single full-duplex connection ব্যবহার করার পরামর্শ দিই।” এই বিভাজন পরে আসে। 8 July 1972 তারিখের RFC 354-এ বলা হয়, “data এবং files কেবল data connection-এর মাধ্যমেই স্থানান্তরিত হয়”, আর commands আলাদা Telnet connection দিয়ে যায়। Postel এবং Reynolds-এর লেখা October 1985-এর RFC 959 হলো সেই version, যা এখনো সবাই implement করে।

RFC 959 port-গুলোও নির্ধারণ করে। Server-এর default data port হলো “control connection port-এর সংলগ্ন port (অর্থাৎ L-1)”, তাই control connection port 21 হলে data port হলো port 20।

তবে এই নকশার একটি অংশ টেকেনি। FTP-এর মূল mode-এ server client-এর দিকে ফিরে data connection খোলে। NAT (network address translation)-এর পেছনে থাকা client-এর এমন কোনো address থাকে না, যেটিতে server পৌঁছাতে পারে। Firewall-এর পেছনে থাকা client inbound connection গ্রহণ করে না। ফলে data connection আসে না এবং listing বা file চাওয়ার সঙ্গে সঙ্গেই transfer আটকে যায়। সমাধান ছিল PASV। RFC 959-এ PASV-কে এমন একটি request হিসেবে সংজ্ঞায়িত করা হয়েছে, যার মাধ্যমে server-কে “একটি data port-এ (যা তার default data port নয়) ‘listen’ করতে এবং transfer command পাওয়ার পর connection শুরু না করে connection-এর জন্য অপেক্ষা করতে” বলা হয়। Server যে address এবং port-এ connect করতে হবে, তা জানিয়ে reply দেয়:

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

এই reply-এর অর্থ হলো host 203.0.113.10 এবং port 195 times 256 plus 80, অর্থাৎ 50000। আবার পড়লে কাঠামোগত সমস্যাটি স্পষ্ট হয়। দ্বিতীয় connection-এর endpoint প্রথম connection-এর payload-এর ভেতরে জানানো হয়। NAT box বা firewall-কে সেই connection পার করতে হলে control channel parse করে সেখানে দেখা port খুলতে হয়। Linux এমন একটি connection tracking helper সরবরাহ করে, যা ঠিক এই কাজ করে। Control connection cleartext অবস্থায় থাকলেই helper কাজ করে। তাই FTP-কে TLS (transport layer security) দিয়ে মুড়ে দিলে যে middlebox FTP-কে ব্যবহারযোগ্য করছিল, সেটি control channel পড়তে পারে না।

এক বাক্যে 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-ভিত্তিক trust

1983 সালে DARPA-এর অর্থায়নে Berkeley প্রকাশিত 4.2BSD-এর সঙ্গে rcp, rsh এবং rlogin যুক্ত হয়। এগুলো একই network-এ থাকা Unix machine-সমৃদ্ধ একটি campus-এর জন্য তৈরি করা হয়েছিল, এবং authentication model-এ তার ছাপ স্পষ্ট। একটি host জানাত কোন user অনুরোধ করছে। /etc/hosts.equiv অথবা কোনো user-এর ~/.rhosts যদি জানাত যে ওই host trusted, তাহলে সেই দাবিই গ্রহণ করা হতো এবং password চাওয়া হতো না।

এই mechanism-টি সরাসরি বোঝা জরুরি, কারণ এই কারণেই commands-গুলো এখন আর ব্যবহৃত হয় না। Trust নির্ভর করত একটি address এবং একটি দাবির ওপর। উভয়ই network-এর মাধ্যমে cleartext-এ পাঠানো হতো। তাই পথের যেকেউ সেগুলো পড়তে এবং জাল করতে পারত। Unix থেকে Linux-এ যাওয়ার পথ-এ বর্ণিত পরিবেশে এই model কার্যকর ছিল, কারণ network-টি একটি building-এর মধ্যে সীমাবদ্ধ ছিল। network Internet হওয়ার সঙ্গে সঙ্গেই এই model আর গ্রহণযোগ্য থাকেনি।

rcp-এর interface-টি কার্যকর ছিল। Source, destination, কাজ শেষ। কোনো session খুলতে হয় না, transfer mode নিয়ে negotiation করতে হয় না, এবং দ্বিতীয় connection তৈরির প্রয়োজন হয় না। এটি path-এ colon-সহ cp-এর মতো কাজ করে। এই interface তার protocol-এর চেয়ে চার দশক বেশি টিকে আছে।

SSH পুরো শ্রেণিটিই দখল করে নেয়

1995 সালে Helsinki University of Technology-এর গবেষক Tatu Ylonen বিশ্ববিদ্যালয়ের নেটওয়ার্কে password-sniffing আক্রমণের প্রতিক্রিয়ায় SSH লিখেছিলেন। 1995 সালের July মাসে তিনি source code-সহ এটিকে free software হিসেবে প্রকাশ করেন। সেই বছরের শেষ নাগাদ 50টি দেশে ব্যবহারকারীর সংখ্যা আনুমানিক 20,000-এ পৌঁছায়। 1995 সালের December মাসে তিনি এর উন্নয়ন চালিয়ে যাওয়ার জন্য SSH Communications Security প্রতিষ্ঠা করেন।

পরবর্তী version-গুলোতে licence-এর শর্ত কঠোর হওয়ায় OpenBSD developers সর্বশেষ freely licensed 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 আর আলাদা সমস্যা থাকল না। একাধিক channel বহনকারী একটি authenticated, encrypted stream পুরোনো protocol-গুলোর নিজেদের তৈরি করতে হওয়া বৈশিষ্ট্যগুলো আগেই দেয়: integrity, ordering এবং দ্বিতীয় TCP connection ছাড়াই ব্যবহারের উপযোগী একটি দ্বিতীয় data path। এই প্রক্রিয়াগুলো আপনার কাছে নতুন হলে, এগিয়ে যাওয়ার আগে SSH আসলে কী, তা দিয়ে শুরু করুন।

এ থেকে দুটি tool তৈরি হয়। scp ছিল SSH session-এর ভিতরে চালানো rcp-এর wire protocol। তাই এটি rcp-এর command line হুবহু উত্তরাধিকারসূত্রে পায়। 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 implement করে। বিশ্বের সবচেয়ে বেশি ব্যবহৃত secure file transfer protocol হলো একটি পরিত্যক্ত 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)-এর default protocol হিসেবে legacy scp/rcp protocol-এর বদলে SFTP protocol ব্যবহার করে।"

এর কারণ একটি প্রচলিত ধারণার ব্যাখ্যা দেয়। পুরোনো scp protocol remote filename wildcard-গুলো 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 ঘোষণা করেন। একই সময়ে তারা "The rsync algorithm" শিরোনামের technical report TR-CS-96-05 প্রকাশ করেন।

rsync-এর আগে প্রতিটি protocol-এর মূল প্রশ্ন ছিল, কোনো file নষ্ট না করে সেটি কীভাবে স্থানান্তর করা যায়। rsync জিজ্ঞাসা করল, এই file-এর কতটা অংশ অপর প্রান্তে আগে থেকেই আছে। report-এ লক্ষ্য হিসেবে "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-এর আচরণ পরিষ্কার হয়। receiver তার কাছে থাকা copy-কে নির্দিষ্ট আকারের block-এ ভাগ করে। প্রতিটি block-এর জন্য দুটি checksum হিসাব করে: একটি দুর্বল ও দ্রুত, অন্যটি শক্তিশালী ও ধীর। এরপর receiver সেই তালিকা sender-কে পাঠায়। sender নিজের file-এর ওপর এক byte করে window সরায় এবং দুর্বল checksum ক্রমাগত আপডেট করে। এ কারণেই byte-by-byte scan বাস্তবসম্মত গতিতে করা যায়। দুর্বল match পাওয়ার পর শক্তিশালী checksum দিয়ে তা নিশ্চিত করা হয়। নিশ্চিত match-গুলো block reference-এ পরিণত হয়। বাকি সব literal byte হিসেবে পাঠানো হয়। receiver আগে থেকেই থাকা block-এর reference এবং সদ্য পাওয়া literal byte মিলিয়ে file পুনর্গঠন করে।

বড় কোনো file-এর শুরুতে একটি byte যোগ করলে naive difference tool-কে পুরো file পাঠাতে হয়, কারণ প্রতিটি offset বদলে যায়। Rolling window নতুন offset-এ একই block-গুলো খুঁজে পায়। ফলে rsync শুধু একটি byte এবং প্রয়োজনীয় bookkeeping পাঠায়। এই বৈশিষ্ট্যের কারণেই কোনো directory একাধিকবার copy করার ক্ষেত্রে rsync এখনও সঠিক tool।

দুটি আচরণ নিয়মিতভাবে ব্যবহারকারীদের অবাক করে। দুটিই manual-এ উল্লেখ আছে। প্রথমত, কোন file পরীক্ষা করতে হবে তা নির্ধারণের জন্য rsync file-এর 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"। কোনো file-এর content বদলালেও তার size এবং timestamp অপরিবর্তিত থাকলে সেটি বাদ পড়ে। --checksum এই আচরণ পরিবর্তন করে এবং উভয় প্রান্তকে প্রতিটি সম্ভাব্য file সম্পূর্ণ পড়তে বাধ্য করে। দ্বিতীয়ত, উভয় path local হলে delta algorithm ডিফল্টভাবে বন্ধ থাকে। কারণ একই machine-এ দুটি copy পড়ে checksum গণনা করার খরচ byte copy করার চেয়ে বেশি। এই সাশ্রয় কেবল তখনই পাওয়া যায়, যখন link-ই ধীর অংশ।

VPS-এ আপনি বাস্তবে কোন পদ্ধতি ব্যবহার করবেন এবং কেন

সংক্ষেপে: কয়েকটি ফাইলের জন্য SFTP, আর এমন কোনো directory আবার copy করতে হলে SSH-এর ওপর rsync ব্যবহার করুন।

উভয়ই SSH-এর মাধ্যমে চলে। তাই অতিরিক্ত configuration ছাড়াই উভয় পদ্ধতিতে host key verification এবং encryption পাওয়া যায়। একটি default-এর মধ্যে পঞ্চাশ বছরের কাজ সংক্ষিপ্ত হয়ে আছে। Kermit-এর নকশাকারদের ধরে নিতে হয়েছিল যে সংযোগে data নষ্ট হতে পারে। তাই তারা protocol-এর মধ্যে checksum এবং retransmission তৈরি করেছিলেন। এখন TCP সেই কাজ করে। Christensen এবং Forsberg-কে ধরে নিতে হয়েছিল যে প্রতিটি byte-এর জন্য অর্থ দিতে হবে। তাই তারা resume এবং streaming তৈরি করেছিলেন। এখন rsync-এর delta algorithm সেই কাজ করে এবং আরও ভালোভাবে করে। FTP-এর লেখকেরা ধরে নিয়েছিলেন যে network-এ পরস্পর সহযোগিতাকারী host থাকবে। এই অনুমানটিই একমাত্র ভুল প্রমাণিত হয়েছিল এমনভাবে, যা কোনো পরিমাণ protocol উন্নয়ন দিয়ে ঠিক করা সম্ভব ছিল না।

চেকসাম এখনো যে সুরক্ষা দেয়

এই ইতিহাসে “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 দিতে পারে না। TLS প্রমাণ করে যে আপনি সঠিক server-এর সঙ্গে যোগাযোগ করেছেন। কিন্তু server-এ সঠিক file-টি রাখা ছিল কি না, TLS তা প্রমাণ করে না। Mirror থেকে নেওয়া file-এর ক্ষেত্রেও TLS কোনো সুরক্ষা দেয় না। তাই release checksum এবং signature যাচাই করতে ত্রিশ সেকেন্ড ব্যয় করা এখনো সার্থক। এই অভ্যাস তৈরি করাও সহজ: ইনস্টল করা প্রতিটি download-এর checksum যাচাই করুন।

এই আলোচনার অন্য সব সমস্যা নিচের layer সমাধান করেছে। এই সমস্যাটি সমাধান করেনি, কারণ এটি কখনো network সমস্যা ছিল না।

FAQ

FTP কি এখনও VPS-এ ব্যবহার করা নিরাপদ?

না। Plain FTP credentials এবং file contents cleartext-এ পাঠায়, তাই network path-এ থাকা যে কেউ দুটিই পড়তে পারে। এটি এমন একটি firewall-এর ওপরও নির্ভর করে, যা তার control channel parse করে। TLS দিয়ে control channel encrypt করার সঙ্গে সঙ্গেই সেই কাজ আর সম্ভব হয় না। Browser-গুলোও 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-এর original 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 direction উল্টে দেয়: server listen করে এবং client-এর connect করার জন্য একটি address ও port 227 Entering Passive Mode reply-এর মধ্যে পাঠায়।

scp কি এখনও নিজস্ব protocol ব্যবহার করে?

OpenSSH 9.0 থেকে আর করে না। এই version 8 April 2022-এ released হয় এবং "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 wildcard-গুলো remote shell-এ পাঠিয়ে expand করত। SFTP-based protocol তা করে না। তাই shell expansion-এর ওপর নির্ভর করা path এখন ভিন্নভাবে কাজ করে।

VPS-এর জন্য scp-এর চেয়ে rsync কখন ভালো?

যখন একই tree একাধিকবার copy করবেন। rsync প্রতিটি file-এর শুধু সেই অংশগুলো পাঠায়, যেগুলো destination-এ আগে থেকেই নেই। তাই দ্বিতীয় copy প্রথমটির চেয়ে অনেক কম খরচে সম্পন্ন হয়। এমন একটি single file-এর ক্ষেত্রে, যেটি destination আগে কখনও দেখেনি, scp এবং rsync প্রায় একই পরিমাণ byte স্থানান্তর করে এবং scp সহজ। মনে রাখবেন, rsync default-ভাবে size ও modification time দেখে কী পরীক্ষা করবে তা নির্ধারণ করে। তাই কোনো file-এর contents পরিবর্তিত হলেও তার size ও timestamp অপরিবর্তিত থাকলে rsync সেটি বুঝতে পারার আগে --checksum প্রয়োজন।

Kermit raw byte পাঠানোর বদলে file-কে printable text হিসেবে encode করত কেন?

কারণ এটি যে connection-এর জন্য তৈরি হয়েছিল, সেটি byte pipe নয়, বরং mainframe-এর দিকে যাওয়া একটি terminal line ছিল। সেই link 7-bit হতে পারত এবং mainframe-এর terminal driver control character-এর ওপর কাজ করত, সেগুলো pass through করত না। Kermit control byte এবং high-bit byte-কে printable character-এ encode করত, যাতে মাঝখানের কোনো অংশ সেগুলোর ওপর প্রতিক্রিয়া না দেখায়। এই encoding-এর ফলে wire-এ binary file বড় হয়। তবে transfer corrupt হয়ে পৌঁছানোর ঝুঁকির তুলনায় এটি ছিল সঠিক সমঝোতা।