বব ক্যান এবং TCP/IP: অ্যাপগুলোর নিচে কাজ করা অদৃশ্য স্তর

কেন TCP/IP আধুনিক সফটওয়্যারের গোপন ভিত্তি

অধিকাংশ অ্যাপ „তৎক্ষণাৎ“ মনে হয়: আপনি একটি বোতাম ট্যাপ করলে ফিড রিফ্রেশ হয়, পেমেন্ট সম্পন্ন হয়, ভিডিও শুরু হয়। আপনি যা দেখতে পান না তা হলো নিচে যা কাজ চলছে—চমকানো ক্ষুদ্র ডেটা প্যাকেটগুলো Wi‑Fi, সেলুলার নেটওয়ার্ক, হোম রাউটার ও ডেটা সেন্টার জুড়ে পাঠানো হচ্ছে—প্রায়শই একাধিক দেশের মধ্য দিয়ে—এবং আপনাকে মাঝখানের গোলমেলে বিষয়গুলো নিয়ে চিন্তা করতে হয় না।

এই অদৃশ্যতা TCP/IP প্রদান করে। এটা কোনো একক প্রোডাক্ট বা ক্লাউড ফিচার নয়। এটা নিয়মগুলোর একটি সেট যা ডিভাইস ও সার্ভারদের এমনভাবে কথা বলার সুযোগ দেয় যে সাধারণত অভিজ্ঞতা মসৃণ ও নির্ভরযোগ্য মনে হয়, এমনকি যখন নেটওয়ার্ক গোলমেলে, কনজেস্টেড বা অংশত ব্যর্থ।

Bob Kahn সেই সম্ভবতায় গুরুত্বপূর্ণ ভূমিকা রেখেছেন। Vint Cerf-এর মতো সহকর্মীদের সাথে তিনি TCP/IP-কে রূপ দেওয়ার মূল ধারণাগুলি তৈরি করতে সাহায্য করেছেন: নেটওয়ার্কগুলোর জন্য একটি সাধারণ “ভাষা” এবং এমন একটি পদ্ধতি যাতে অ্যাপগুলো ডেটা বিশ্বস্তভাবে পেতে পারে। কোনো হাইপ নয়—এই কাজটি গুরুত্বপূর্ণ ছিল কারণ এটি অনির্ভরযোগ্য সংযোগকে এমন কিছুতে পরিণত করল যার উপরে সফটওয়্যার নির্ভর করে তৈরি করা যায়।

প্যাকেট নেটওয়ার্কিং, ব্যস্ত লোকের জন্য সহজভাবে

পুরো বার্তাটা একসঙ্গে পাঠানোর বদলে, প্যাকেট নেটওয়ার্কিং এটিকে ছোট ছোট টুকরো — প্যাকেট — এ ভেঙে দেয়। প্রতিটি প্যাকেট গন্তব্যে নিজের পথে যেতে পারে, ঠিক আলাদা খামে আলাদা পোস্ট অফিসের মতো।

আপনি এই আর্টিকেলে কী শিখবেন

আমরা ব্যাখ্যা করব কিভাবে TCP নির্ভরতার অনুভূতি তৈরি করে, কেন IP ইচ্ছাকৃতভাবে পরিপূর্ণতার নিশ্চয়তা দেয় না, এবং কিভাবে লেয়ারিং সিস্টেমটিকে বোধগম্য রাখে। শেষ পর্যন্ত আপনি কল্পনা করতে সক্ষম হবেন যখন একটি অ্যাপ একটি API কল করে—আর কেন এই দশক পুরানো ধারণাগুলো আজকের ক্লাউড সার্ভিসগুলোকেও চালায়।

TCP/IP যে সমস্যা সমাধান করল

আদিম কম্পিউটার নেটওয়ার্কগুলো “ইন্টারনেট” হিসেবে জন্মায়নি। সেগুলো নির্দিষ্ট গোষ্ঠীর জন্য নির্মিত হয়েছিল—একটি বিশ্ববিদ্যালয়ের নেটওয়ার্ক এখানে, একটি সামরিক নেটওয়ার্ক ওখানে, একটি গবেষণাগারের নেটওয়ার্ক অন্য কোথাও। প্রতিটি ভেতরে ভাল কাজ করতে পারে, কিন্তু প্রায়শই তারা ভিন্ন হার্ডওয়্যার, মেসেজ ফরম্যাট ও ডেটা যাত্রার নিয়ম ব্যবহার করত।

ফলাফল ছিল হতাশাজনক: দুইটি কম্পিউটার যদি নেটওয়ার্কেডও থাকে, তবুও তারা তথ্য বিনিময় করতে নাও পারে। এটা অনেক রেল সিস্টেমের মতো যেখানে ট্র্যাকের প্রস্থ ভিন্ন এবং সিগন্যালের মানে ভিন্ন—এক সিস্টেমের ভেতরে ট্রেন চলে, কিন্তু অন্য সিস্টেমে যাওয়া জটিল, ব্যয়বহুল বা অসম্ভব।

ইন্টারনেটওয়ার্কিং: কেবল কম্পিউটার সংযুক্ত করা নয়, নেটওয়ার্কগুলো সংযুক্ত করা

বব কানের মূল চ্যালেঞ্জ ছিল কেবল “কম্পিউটার A-কে কম্পিউটার B-র সাথে সংযুক্ত করা” নয়। সেটা ছিল: কিভাবে নেটওয়ার্কগুলোকে একে অপরের সাথে এমনভাবে সংযুক্ত করা যায় যাতে ট্রাফিক একাধিক স্বাধীন সিস্টেম পেরিয়ে যাওয়ার পরেও তারা একটি বড় সিস্টেমের মতো কাজ করে?

এটিই “ইন্টারনেটওয়ার্কিং”—তথ্যকে একটি নেটওয়ার্ক থেকে অন্য নেটওয়ার্কে হপ করানোর পদ্ধতি তৈরি করা, এমনকি ঐ নেটওয়ার্কগুলো ভিন্নভাবে ডিজাইন ও পরিচালিত হলে ওগুলোকে একসাথে কাজ করানো।

কেন শেয়ারড রুলস (প্রটোকল) গুরুত্বপূর্ণ ছিল

ইন্টারনেটওয়ার্কিংকে স্কেলে কাজ করতে হলে সবাইকে একটি সাধারণ নিয়ম সেট দরকার ছিল—প্রটোকল—যা কোনো একক নেটওয়ার্কের অভ্যন্তরীণ ডিজাইনের উপর নির্ভর করে না। সেই নিয়মগুলো বাস্তব সীমাবদ্ধতাও প্রতিফলিত করতে হবে:

• নেটওয়ার্ক ভাঙতে পারে, ডেটা ড্রপ করতে পারে, বা আউট-অফ-অর্ডারে ডেলিভারি করতে পারে।
• কোনো সেন্ট্রাল অপারেটর প্রতিটি সংযোগ ম্যানেজ করতে পারবে না।
• নতুন নেটওয়ার্ক সময়ের সঙ্গে যুক্ত হতে থাকবে।

TCP/IP একটি বাস্তবসম্মত উত্তর হয়ে উঠল: একটি শেয়ার করা “চুক্তি” যা স্বাধীন নেটওয়ার্কগুলোকে ইন্টারকনেক্ট করে এবং বাস্তব অ্যাপলিকেশনের জন্য পর্যাপ্তভাবে নির্ভরযোগ্যভাবে ডেটা সরাতে দেয়।

বব কানের অবদান সাধারণ ভাষায়

বব ক্যান ইন্টারনেটের “রোড রুলস” তৈরি করার মূল স্থপতিদের একজন হিসেবে পরিচিত। 1970-এর দশকে DARPA-তে কাজ করার সময় তিনি নেটওয়ার্কিংকে একটি চতুর গবেষণামূলক পরীক্ষা থেকে এমন কিছুতে নিয়ে যাওয়ার উপর কাজ করেছিলেন যা বিভিন্ন ধরনের নেটওয়ার্ককে সংযুক্ত করতে পারে—ইতোমধ্যে সেগুলোকে একই হার্ডওয়্যার, তার বা অভ্যন্তরীণ ডিজাইনে বাধ্য না করে।

মূল ধারণা: নেটওয়ার্কগুলোকে একে অপরের সাথে যোগাযোগ করান

ARPANET দেখিয়েছে কম্পিউটার প্যাকেট-সুইচড লিঙ্কে যোগাযোগ করতে পারে। কিন্তু অন্যান্য নেটওয়ার্কগুলোও উঠে আসছিল—রেডিওভিত্তিক সিস্টেম, স্যাটেলাইট লিঙ্ক, এবং অন্যান্য পরীক্ষামূলক নেটওয়ার্ক—প্রতিটিই নিজের আচরণ নিয়ে। কানের ফোকাস ছিল ইন্টারঅপারেবিলিটি: একটি বার্তাকে একাধিক নেটওয়ার্ক জুড়ে একই নেটওয়ার্কের অংশ হিসেবে যাত্রা করানো।

একটি “পারফেক্ট” নেটওয়ার্ক গড়ার বদলে তিনি এমন একটি পদ্ধতি প্রয়োগের পক্ষে ছিলেন যেখানে:

• প্রতিটি স্থানীয় নেটওয়ার্ক তার নিজস্ব ডিজাইন রাখতে পারে।
• একটি সাধারণ প্রটোকল শীর্ষে বসে এবং নেটওয়ার্ক সীমানা পার হয়ে ডেটা সরায়।
• এই “গ্লু” সাধারণ পর্যাপ্ত যাতে ভবিষ্যতে উদ্ভাবিত নতুন নেটওয়ার্কগুলোর ওপরও কাজ করে।

Vint Cerf-এর সঙ্গে কাজ করে তিনি যা ডিজাইন করেছেন তা TCP/IP হিসেবে গড়ে উঠল। একটি স্থায়ী ফল হলো দায়িত্বগুলোর পরিষ্কার বিভাজন: IP ঠিকানা ও ফরওয়ার্ডিং হ্যান্ডেল করে, আর TCP যে অ্যাপ্লিকেশনগুলোকে দরকার তাদের জন্য নির্ভরযোগ্য ডেলিভারি দেয়।

কেন ডেভেলপাররা আজও উপকৃত হন

আপনি যদি কখনও একটি API কল করে থাকেন, একটি ওয়েব পেজ লোড করে থাকেন, বা কনটেইনার থেকে লগ মনিটরিং সার্ভিসে পাঠিয়ে থাকেন, আপনি কানের প্রচারিত ইন্টারনেটওয়ার্কিং মডেলের ওপর নির্ভর করছেন। আপনাকে চিন্তা করতে হয় না যে প্যাকেট কিভাবে Wi‑Fi, ফাইবার, LTE বা ক্লাউড ব্যাকবোন পার করছে। TCP/IP এগুলোকে একটি একক ধারাবাহিক সিস্টেমের মতো করে তোলে—ফলে সফটওয়্যার ফিচারে ফোকাস করতে পারে, তার তারপাটা নিয়ে না গিয়ে।

TCP/IP লেয়ারিং ধারণা: সোজা কিন্তু শক্তিশালী

TCP/IP-এর পেছনের সবচেয়ে স্মার্ট ধারণাগুলোর একটি হলো লেয়ারিং: একটি বিশাল “সবকিছুই করা” নেটওয়ার্ক সিস্টেম গড়ার বদলে আপনি ছোট ছোট স্তর স্ট্যাক করেন যেখানে প্রতি স্তর এক কাজ ভালভাবে করে।

এটি গুরুত্বপূর্ণ কারণ নেটওয়ার্কগুলো সব একরকম নয়। বিভিন্ন কেবল, রেডিও, রাউটার ও প্রদানকারী মিলেও ইন্টারঅপারেবল হতে পারে যখন তারা কয়েকটি পরিষ্কার দায়িত্বে সম্মত হয়।

IP: নেটওয়ার্কগুলোর মধ্যে ঠিকানা ও রাউটিং

IP (Internet Protocol) ভাবুন এমন অংশ হিসাবে যা বলে: এই ডেটা কোথায় যেতে হবে, এবং আমরা কিভাবে এটাকে কাছাকাছি নিয়ে যাব?

IP প্রদান করে ঠিকানা (যাতে মেশিনগুলো সনাক্ত হয়) এবং মৌলিক রাউটিং (প্যাকেটগুলো নেটওয়ার্ক থেকে নেটওয়ার্কে হপ করে)। গুরুত্বপূর্ণ ব্যাপার হলো, IP পরিপূর্ণ হওয়ার চেষ্টা করে না। এটি প্যাকেটগুলোকে এক ধাপ করে সামনে পাঠাতে ফোকাস করে, এমনকি যদি পথ বদলে যায়।

TCP: IP-এর উপরে নির্ভরযোগ্য ডেলিভারি

তারপর TCP (Transmission Control Protocol) IP-এর উপরে বসে এবং উত্তর দেয়: এটি কিভাবে নির্ভরযোগ্য সংযোগের মতো মনে করাবো?

TCP অ্যাপ্লিকেশনগুলো সাধারণত যা চায় তা করে: ডেটা সঠিক ক্রমে ডেলিভারি করা, হারিয়ে যাওয়া অংশ শনাক্ত করে পুনঃপ্রেরণ, এবং প্রেরককে ধীর করে দেয় যাতে রিসিভার বা নেটওয়ার্ক ওভারওয়েল্ম না হয়।

একটি সরল পোস্টাল উপমা (অতিরঞ্জন ছাড়া)

একটি উপকারী কল্পনা:

• IP ঠিকানা ও রাউটিং নেটওয়ার্কের মত—শহর ও পোস্ট অফিসগুলোর মধ্যে খামগুলো পাঠানো।
• TCP ট্র্যাকিং ও কনফার্মেশনের মত—যাতে বহু-ভাগ চালান সম্পূর্ণ ও সঠিক ক্রমে পৌঁছায়।

আপনি স্ট্রিট ঠিকানাকে প্যাকেজ এসে পৌঁছানোর নিশ্চয়তা দিতে বলবেন না; সেই নিশ্চয়তা আপনি উপরে গড়বেন।

কেন এই “সরল স্ট্যাক” শক্তিশালী থেকেছে

কারণ দায়িত্বগুলো আলাদা, আপনি একটি স্তর উন্নত করতে পারেন বাকি সবকিছু পুনর্নির্মাণ না করেই। নতুন ফিজিক্যাল নেটওয়ার্ক IP বহন করতে পারে, এবং অ্যাপ্লিকেশনগুলো TCP-এর আচরণে নির্ভর করতে পারে রাউটিং কিভাবে কাজ করে তা বুঝতে না হলেও। এই পরিষ্কার বিভাজন TCP/IP-কে প্রায় প্রতিটি অ্যাপ ও API-এর অব্যক্ত ভিত্তি করে তুলেছে।

প্যাকেট সুইচিং: গতি, নমনীয়তা, এবং বিশৃঙ্খলা

প্যাকেট সুইচিং সেই ধারণা যা বড় নেটওয়ার্কগুলোকে ব্যবহারিক করেছে: আপনার পুরো বার্তাটির জন্য একটি নির্ধারিত লাইন সংরক্ষণ করার বদলে, আপনি বার্তাটিকে ছোট টুকরো করে প্রতিটিকে স্বাধীনভাবে পাঠান।

একটি “প্যাকেট” কী (এবং কেন টুকরো জিতছে)

প্যাকেট হল ছোট ডেটার প্যাকেট যার একটি হেডার থাকে (কে পাঠিয়েছে, কে নেবে, এবং অন্যান্য রাউটিং তথ্য) ও কন্টেন্টের একটি অংশ।

ডেটা টুকরো করলে নেটওয়ার্ক করতে পারে:

• অনেক ব্যবহারকারীর মধ্যে লিংক শেয়ার করা (কেউ একা তার তার দখল করে না)
• ধীর বা ভাঙা নেটওয়ার্ক অংশকে এড়িয়ে রুট করা
• সমস্যা হলে কেবল হারানো অংশগুলোই পুনরায় পাঠানো, পুরো ফাইল নয়

বিভিন্ন পথে, মিশ্র ক্রমে

এখানেই “অরাজকতা” শুরু হয়। একই ডাউনলোড বা API কলের প্যাকেটগুলো নেটওয়ার্কে বিভিন্ন রুট নিতে পারে, যা ওই মুহূর্তে কী ব্যস্ত বা উপলব্ধ তার উপর নির্ভর করে। ফলে এগুলো আউট অফ অর্ডার পৌঁছাতে পারে—প্যাকেট #12 আসতে পারে #5-এর আগে।

প্যাকেট সুইচিং তা প্রতিহত করে না। দ্রুত প্যাকেট পাঠানোই অগ্রাধিকার দেয়, এমনকি আগমনের ক্রম অসংলগ্ন হলে ও।

কেন প্যাকেট হারায়

প্যাকেট লস বিরল নয় এবং সবসময় কারও দোষও নয়। সাধারণ কারণগুলোর মধ্যে:

• কনজেশন: রাউটারগুলোর বাফার ভরে গেলে প্যাকেট ড্রপ হয়।
• নয়েজ/হস্তক্ষেপ: বিশেষ করে ওয়্যারলেস লিঙ্কে।
• আউটেজ ও রিরুটিং: কোনো লিংক মাঝপথে ফেল করলে কিছু প্যাকেট পৌঁছাতে পারে না।

অসম্পূর্ণতা একটি ফিচার, ত্রুটি নয়

মূল ডিজাইন পছন্দ হলো নেটওয়ার্ককে অসম্পূর্ণ হতে অনুমতি দেয়া। IP প্যাকেটগুলোকে এগোতে গুরুত্ব দেয়, ডেলিভারি বা অর্ডার প্রতিশ্রুতি না দিয়ে। সেই স্বাধীনতা নেটওয়ার্কগুলোকে স্কেল করতে দেয়—এবং এজন্য উচ্চতর লেয়ার (যেমন TCP) আছে যা বিশৃঙ্খলা মেটায়।

TCP কীভাবে অনির্ভরযোগ্য নেটওয়ার্ককে নির্ভরযোগ্য মনে করায়

IP প্যাকেটগুলোকে “সেরা প্রচেষ্টায়” ডেলিভারি করে: কিছু দেরিতে পৌঁছতে পারে, আউট অফ অর্ডার হতে পারে, ডুপ্লিকেট হতে পারে, বা একেবারেই না-ও আসতে পারে। TCP উপরে বসে এবং অ্যাপলিকেশনের জন্য এমন কিছু তৈরি করে যাকে তারা বিশ্বাস করতে পারে: একটি একক, অর্ডার্ড, সম্পূর্ণ বাইট স্ট্রিম—যেটি আপনি ফাইল আপলোড, ওয়েব পেজ লোড বা API কলের ক্ষেত্রে আশা করেন।

নির্ভরযোগ্যতা, সরল ভাষায়

যখন মানুষ বলে TCP “নির্ভরযোগ্য”, সাধারণত তারা বোঝায়:

• অর্ডার্ড: ডেটা অ্যাপএ সেই ক্রমেই ডেলিভার করা হয় যেই ক্রমে পাঠানো হয়।
• সম্পূর্ণ: মিসিং অংশ ধরা পড়ে এবং পুনরায় পাঠানো হয়।
• কোনও খাঁজ নেই: অ্যাপ একটি ধারাবাহিক স্ট্রিম পড়ে, ছড়িয়ে থাকা প্যাকেট নয়।

মূল মেকানিজম (এবং কেন এগুলো কাজ করে)

TCP আপনার ডেটা টুকরো করে এবং তাদের সিকোয়েন্স নম্বর দেয়। রিসিভার acknowledgment (ACK) পাঠায় যা কি পেয়েছে তা নিশ্চিত করে।

যদি প্রেরক নির্দিষ্ট সময়ের মধ্যে ACK না দেখে, এটি ধরে নেয় কিছু হারিয়েছে এবং রিট্রান্সমিশন করে। এটি হল মূলে সেই “ভ্রমের” ক্লূ: নেটওয়ার্ক প্যাকেট ড্রপ করলেও TCP প্রেরণ অব্যাহত রাখে যতক্ষণ না রিসিভার গ্রহণ নিশ্চিত করে।

ফ্লো কন্ট্রোল বনাম কনজেশন কন্ট্রোল

শুনতে মিলছে, কিন্তু আলাদা সমস্যা সমাধান করে:

• Flow control রিসিভারকে রক্ষা করে—“আমি ব্যস্ত, ধীরে পাঠাও।”
• Congestion control নেটওয়ার্ককে রক্ষা করে—“পথটা ভীড় করছে, একে কমিয়ে দাও।”

একসঙ্গে, এগুলো TCP-কে দ্রুত থাকতে দেয় বিনা লজ্জায়।

অ্যাডাপটিভ টাইমআউট

একটি স্থির টাইমআউট ধীর ও দ্রুত উভয় নেটওয়ার্কেই ব্যর্থ হত। TCP ধারাবাহিকভাবে তার টাইমআউট সামঞ্জস্য করে পরিমাপ করা রাউন্ড-ট্রিপ টাইমের উপর ভিত্তি করে। পরিস্থিতি খারাপ হলে বেশি অপেক্ষা করে পুনরায় পাঠ করে; যদি দ্রুত হয়, তা আরও প্রতিক্রিয়াশীল হয়। এই অভিযোজন TCP-কে Wi‑Fi, মোবাইল নেটওয়ার্ক ও দূরবর্তী লিঙ্ক জড়িয়েও কাজ করতে রাখে।

একটি এমন ডিজাইন যা স্কেল করেছে: এন্ড-টু-এন্ড চিন্তাভাবনা

TCP/IP-এর অন্যতম গুরুত্বপূর্ণ ধারণা হল এন্ড-টু-এন্ড নীতি: নেটওয়ার্কের “মধ্য” তুলনামূলকভাবে সহজ রাখো এবং “স্মার্টনেস” এন্ডপয়েন্টে রাখো।

এন্ডপয়েন্টগুলোতে বুদ্ধিমত্তা

সরলভাবে বলতে এন্ডপয়েন্টগুলো হলো ডিভাইস ও প্রোগ্রাম—আপনার ফোন, ল্যাপটপ, সার্ভার ও সেগুলোর OS এবং অ্যাপ। নেটওয়ার্ক কোর—রাউটার ও লিংক—মুলত প্যাকেট এগিয়ে নেওয়ার উপর ফোকাস করে।

রাউটারকে প্রতিটি অ্যাপের প্রয়োজন বুঝতে বলার বদলে TCP/IP ধরে নেয় যে মাঝখান গোলমেলে হবে এবং এন্ডপয়েন্টগুলোই প্রাসঙ্গিক অংশ হ্যান্ডেল করবে।

কেন একটি সরল কোর বৃদ্ধি সম্ভব করলো

কোরকে সহজ রাখলে ইন্টারনেট বাড়ানো সহজ হলো। নতুন নেটওয়ার্ক যোগ করতে কোর ডিভাইসগুলোকে প্রতিটি অ্যাপের প্রয়োজন বোঝাতে হবে না। রাউটারদের জানতে হয় না কোন প্যাকেট ভিডিও কলের, ফাইল ডাউনলোডের বা API অনুরোধের অংশ—তারা শুধু ফরওয়ার্ড করে।

কোথায় কী থাকা উচিত (উদাহরণসহ)

এন্ডপয়েন্টগুলোতে সাধারণত হ্যান্ডেল করা হয়:

• নির্ভরযোগ্যতা: রিট্রান্সমিশন, অর্ডারিং, ডেডুপ্লিকেশন (TCP).
• নিরাপত্তা: এনক্রিপশন ও পরিচয় (প্রায়শই TLS অ্যাপ/OS স্তরে).
• অ্যাপ আচরণ: টাইমআউট, রিট্রাই, ক্যাশিং, রেট লিমিট।

নেটওয়ার্কে সাধারণত হ্যান্ডেল করা হয়:

• ঠিকানা ও ফরওয়ার্ডিং (IP).
• মৌলিক প্যাকেট হ্যান্ডলিং ও কনজেশন সিগন্যাল।

ট্রেড-অফ

এন্ড-টু-এন্ড চিন্তা ভালো স্কেল করে, কিন্তু জটিলতা বাইরের দিকে ঠেলে দেয়। অপারেটিং সিস্টেম, লাইব্রেরি ও অ্যাপ্লিকেশনগুলোকে ‘এটি কাজ করবে’ করে তোলা কঠিন হতে পারে—বাগ, ভুল কনফিগার করা টাইমআউট বা অতিরিক্ত আক্রমণাত্মক রিট্রাই ব্যবহারকারীর সামনে সমস্যার সৃষ্টি করতে পারে।

কেন IP-এর “বেস্ট এফফোর্ট” মডেল একটি বৈশিষ্ট্য ছিল

IP একটি সহজ প্রতিশ্রুতি দেয়: এটি আপনার প্যাকেটগুলো গন্তব্যের দিকে পাঠানোর চেষ্টা করবে। কেবল তাই। কোনো গ্যারান্টি নেই যে প্যাকেট পৌঁছাবে, একবারই পৌঁছাবে, সঠিক ক্রমে পৌঁছাবে বা কোনো নির্দিষ্ট সময়ে পৌঁছাবে।

এটি ত্রুটি মনে হতে পারে—তবে ইন্টারনেট কী হওয়া দরকার ছিল তা দেখলে বোঝা যায় কেন এটা দরকার ছিল: একটি গ্লোবাল নেটওয়ার্ক যা অনেক ছোট নেটওয়ার্ক দিয়ে গঠিত, ভিন্ন সংস্থার মালিকানায় ও পরিবর্তিত হতে থাকবে।

রাউটাররা কী করে (এবং কী করে না)

রাউটার IP-র “ট্রাফিক ডিরেক্টর”। মূল কাজ হলো ফরওয়ার্ডিং: যখন একটি প্যাকেট আসে, রাউটার গন্তব্য ঠিকানা দেখে পরবর্তী হপ বেছে নেয় যা বর্তমানভাবে সেরা বলে মনে হয়।

রাউটার সাধারণত কনভারসেশন ট্র্যাক করে না যেমন ফোন অপারেটর করে। তারা সাধারণত আপনার জন্য ক্যাপাসিটি রিজার্ভ করে না এবং প্যাকেটটি পাস হলো কিনা নিশ্চিত করতে অপেক্ষা করে না। রাউটারগুলোকে ফরওয়ার্ডিং-এ ফোকাস করে কোরটি সিম্পল রাখা হয়—এবং এতে বিশাল সংখ্যক ডিভাইস ও সংযোগ স্কেল করতে পারে।

কেন “বেস্ট-এফফোর্ট” গ্লোবালি স্কেল করে

গ্যারান্টি ব্যয়বহুল। যদি IP প্রতিটি প্যাকেটের জন্য ডেলিভারি, অর্ডার ও সময়ের নিশ্চয়তা দেয়, তাহলে পৃথিবীর প্রতিটি নেটওয়ার্ককে কড়া সমন্বয় করতে হতো, প্রচুর স্টেট রাখা লাগতো এবং ব্যর্থতার সময় পুনরুদ্ধার কঠিন হতো। সেই সমন্বয়ের বোঝা বৃদ্ধি পেলে বৃদ্ধিও ধীর হতো এবং আউটেজ আরও গুরুতর হত।

বদলে IP গোলমেল সহ্য করে। যদি একটি লিংক ব্যর্থ হয়, একটি রাউটার প্যাকেটগুলো ভিন্ন রুটে পাঠাতে পারে। যদি একটি পথ কনজেস্টেড হয়, প্যাকেট বিলম্বিত বা ড্রপ হতে পারে, কিন্তু বিকল্প রুট দিয়ে ট্রাফিক প্রায়ই চালু রাখতে পারে। ফলাফল হলো টেকসইতা: ইন্টারনেট কাজ চালিয়ে যেতে পারে এমনকি অংশবিশেষ ভেঙে গেলেও—কারণ নেটওয়ার্ককে নিখুঁত হতে বাধ্য করা হয়নি।

অ্যাপ ও API থেকে প্যাকেট পর্যন্ত: আসলে কী হচ্ছে

আপনি যখন fetch() এ একটি API কল করেন, “Save” এ ক্লিক করেন বা একটি websocket খুলেন, আপনি একসঙ্গে সার্ভারের সাথে এক মসৃণ স্ট্রিমে কথা বলছেন না। আপনার অ্যাপ OS-কে ডেটা সমর্পণ করে, যা এটিকে প্যাকেটগুলোতে ভাগ করে এবং সেগুলোকে বহু পৃথক নেটওয়ার্কে পাঠায়—প্রতিটি হপ নিজস্ব সিদ্ধান্ত নেয়।

একটি সরল ম্যাপিং: ডেভেলপার অ্যাকশন → TCP/IP আচরণ

• HTTP অনুরোধ / API কল: আপনার অ্যাপ বাইট লিখে (একটি HTTP অনুরোধ)। TCP সেই বাইট স্ট্রিমকে সেগমেন্টে ভাঙে, নম্বর দেয় এবং ACK আশা করে। IP প্রতিটি সেগমেন্টকে একটি প্যাকেটে র‌্যাপ করে এবং রাউট করে।
• কনেকশন খোলা: একটি TCP হ্যান্ডশেক শেয়ার্ড স্টেট সেট করে (সিকোয়েন্স নম্বর, উইন্ডো সাইজ)। এটা বিনামূল্যের নয়—এটি প্রথম কার্যকর বাইটের আগে সময় যোগ করে।
• ফাইল আপলোড: TCP-র পক্ষে প্রচুর থ্রুপুট থাকতে পারে, কিন্তু পারফরম্যান্স ধীর অনুভূত হতে পারে যদি ল্যাটেন্সি বেশি হয়।

ল্যাটেন্সি বনাম থ্রুপুট (এবং কেন আপনার অ্যাপ ধীর মনে হয়)

• Latency হল একটি বার্তা туда-ব-ফিরে যেতে যাওয়া সময় (round trip)। উচ্চ ল্যাটেন্সি চ্যাটি প্যাটার্নকে খাটায়: অনেক ছোট অনুরোধ, বার বার কল।
• Throughput হল প্রতি সেকেন্ডে কত ডেটা ডেলিভার করা যায়। কম থ্রুপুট বড় ট্রান্সফারগুলোকে কষ্ট দেয়: ইমেজ, ব্যাকআপ, ভিডিও।

একটি সাধারণ বিস্ময়: আপনার কাছে দুর্দান্ত থ্রুপুট থাকতে পারে এবং তবুও UI ধীর মনে হতে পারে কারণ প্রতিটি অনুরোধ রাউন্ড-ট্রিপের জন্য অপেক্ষা করে।

রিট্রাই ও টাইমআউট: কেন অ্যাপগুলো TCP-এর উপরে আবার চেষ্টা করে

TCP হারানো প্যাকেট পুনরায় পাঠায়, কিন্তু এটি আপনার ব্যবহারকারীর জন্য “একটু বেশি সময়” কী তা জানে না। এজন্য অ্যাপ্লিকেশনগুলো যোগ করে:

• Timeouts: “যদি 2 সেকেন্ডে কোনও প্রতিক্রিয়া না পেলে ত্রুটি দেখাও।”
• Retries: “একবার আবার চেষ্টা কর।” ট্রানজিয়েন্ট ড্রপের জন্য কাজে লাগে, কিন্তু পেমেন্টের মতো অপারেশনের জন্য বিপজ্জনক হতে পারে যদি অনুরোধ আইডেমপোটেন্ট না হয়।

কখন “বাগ” আসলে নেটওয়ার্ক বাস্তবতা

প্যাকেট দেরিতে আসতে পারে, পুনরায় সাজানো, ডুপ্লিকেট বা ড্রপ হতে পারে। কনজেশন ল্যাটেন্সি বাড়ায়। সার্ভার উত্তর দিলেও প্রতিক্রিয়া আপনার কাছে পৌঁছাতে নাও পারে। এগুলো ফ্ল্যাকি টেস্ট, র্যান্ডম 504 বা “আমার মেশিনে চলে”র মত ফলাফল দেয়। প্রায়শই কোড ঠিকই থাকে—দুটি মেশিনের মধ্যে পথটাই সমস্যা।

ক্লাউডে TCP/IP: একই নিয়ম, বড় স্কেলে

ক্লাউড প্ল্যাটফর্মগুলো একটি পুরো নতুন ধরনের কম্পিউটিং মনে হতে পারে—ম্যানেজড ডেটাবেস, সার্ভারলেস ফাংশন, “অনন্ত” স্কেলিং। নিচে আপনার অনুরোধগুলো তখনও একই TCP/IP ভিত্তিতে চলেই: IP প্যাকেটগুলো নেটওয়ার্ক জুড়ে নিয়ে যায়, এবং TCP (বা কখনো UDP) অ্যাপগুলোকে নেটওয়ার্ক অনুভবে কেমন লাগে তা নির্ধারণ করে।

ক্লাউডে কী পরিবর্তিত হয় (প্রধানত প্যাকেজিং)

ভার্চুয়ালাইজেশন ও কনটেইনার বদলে দেয় কোথায় সফটওয়্যার চলে এবং কিভাবে প্যাকেজ করা হয়:

• একটি “সার্ভার” হতে পারে একটি ভার্চুয়াল মেশিন, একটি কনটেইনার বা এককালীন ফাংশন।
• নেটওয়ার্ক প্রায়শই সফটওয়্যার-পরিচালিত, প্রদানকারীর দ্বারা জোড়া দেওয়া হয়।

কিন্তু এগুলো ডিপ্লয়মেন্টের বিবরণ; প্যাকেটগুলো এখনও IP ঠিকানা ও রাউটিং ব্যবহার করে এবং অনেক সংযোগ এখনও TCP-র ওপর নির্ভর করে।

কী অপরিবর্তিত থাকে (আপনি চিনতে পারবেন এমন প্যাটার্ন)

প্রচলিত ক্লাউড আর্কিটেকচারে পরিচিত নেটওয়ার্কিং বিল্ডিং ব্লকগুলো দেখা যায়:

• লোড ব্যালান্সার ক্লায়েন্ট TCP (প্রচুর সময় HTTPS) সংযোগ গ্রহণ করে এবং ব্যাকএন্ড সার্ভিসে ট্রাফিক বিতরণ করে।
• সার্ভিস-টু-সার্ভিস কল ক্লাস্টারের ভেতরেও নেটওয়ার্ক কল—HTTP/gRPC প্রায়ই TCP-র ওপর চলে—শুধু প্রাইভেট IP-গুলোর মধ্যে।
• ডাটাবেস ও ক্যাশ (ম্যানেজড বা স্ব-হোস্টেড) মানক প্রটোকল ব্যবহার করে TCP-র ওপর পৌঁছায় (উদাহরণ: ডাটাবেস ড্রাইভার একটি TCP সেশন বজায় রাখে)।

আপনি IP ঠিকানা কখনো দেখেন না, প্ল্যাটফর্ম সেগুলো বরাদ্দ করছে, রুট করছে এবং কানেকশন ট্র্যাক করছে পেছনে।

নির্ভরযোগ্যতা এখনও একটি শেয়ার করা কাজ

TCP ড্রপ করা প্যাকেট পুনরুদ্ধার করতে পারে, ডেলিভারি পুনরায় সাজাতে পারে এবং কনজেশন অনুযায়ী মানিয়ে নিতে পারে—কিন্তু এটি অসম্ভব তথ্য প্রতিশ্রুতি দিতে পারে না। ক্লাউড সিস্টেমগুলোতে নির্ভরযোগ্যতা একটি টিমের কাজ:

• নেটওয়ার্ক: রাউটিং, ক্যাপাসিটি, প্যাকেট লস, ট্রানজিয়েন্ট ব্যর্থতা।
• OS/runtime: সোকেট বাফার, টাইমআউট, DNS ক্যাশিং, কনেকশন পুনঃব্যবহার।
• অ্যাপ্লিকেশন: ব্যাকঅফ সহ রিট্রাই, আইডেমপোটেন্সি, যুক্তিসংগত টাইমআউট, graceful degradation।

এই কারণেই এমন প্ল্যাটফর্মগুলো (যেগুলো পূর্ণ-স্ট্যাক অ্যাপ জেনারেট ও ডেপ্লয় করে) একই মৌলিক তত্ত্বে নির্ভরশীল। উদাহরণস্বরূপ, Koder.ai আপনাকে দ্রুত React ও Go ব্যাকএন্ড সহ একটি অ্যাপ বানাতে সাহায্য করতে পারে, কিন্তু যখন সেই অ্যাপ কোনো API, ডাটাবেস বা মোবাইল ক্লায়েন্টের সাথে কথা বলে, তখন আপনি আবার TCP/IP-র জমানায় ঢুকবেন—কানেকশন, টাইমআউট, রিট্রাই সবই আছে।

TCP বনাম UDP এবং আজ ডেভেলপাররা কী বেছে নেয়

যখন ডেভেলপাররা “নেটওয়ার্ক” বলেন, তারা প্রায়শই দুইটি কাজের ঘোড়ার মধ্যে বেছে নিচ্ছেন: TCP ও UDP। উভয়ই IP-এর ওপর বসে, কিন্তু তারা খুব ভিন্ন ট্রেড-অফ করে।

TCP: নির্ভরযোগ্য স্ট্রিম (এবং এর গোপন খরচ)

TCP তখন উপযুক্ত যখন আপনাকে ডেটা সঠিক ক্রমে, বিনা গ্যাপে চাই এবং অপেক্ষা করা ভালো—উদাহরণ: ওয়েব পেজ, API কল, ফাইল ট্রান্সফার, ডাটাবেস কানেকশন।

এই কারণেই দৈনন্দিন ইন্টারনেটের বড় অংশ TCP-র ওপর চলে—HTTPS TCP-র ওপর চলে (TLS ব্যবহারের মাধ্যমে), এবং অনেক রিকোয়েস্ট/রেসপন্স সফটওয়্যার TCP-এর আচরণ ধরে নিয়েই ডিজাইন করা।

কিন্তু খরচ আছে: TCP-র নির্ভরযোগ্যতা ল্যাটেন্সি যোগ করতে পারে। যদি একটি প্যাকেট হারায়, পরবর্তী প্যাকেটগুলোকে gap-পুরণ না হওয়া পর্যন্ত ধরে রাখা হতে পারে ("head-of-line blocking")। ইন্টারঅ্যাকটিভ অভিজ্ঞতার জন্য সেই অপেক্ষা মাঝে মাঝে একটি অগত্যা ত্রুটি থেকে খারাপ অনুভূতি তৈরি করে।

UDP: সোজা, দ্রুত, ও অ্যাপ-নিয়ন্ত্রিত

UDP হল ’মেসেজ পাঠাও এবং আশা করো এটি পৌঁছাবে’ রকম—এখানে বিল্ট-ইন অর্ডারিং, রিট্রান্সমিশন বা কনজেশন হ্যান্ডল নেই।

ডেভেলপাররা UDP তখন বেছে নেন যখন টাইমিং পারফেকশনের চেয়ে বেশি গুরুত্বপূর্ণ, যেমন লাইভ অডিও/ভিডিও, গেমিং বা রিয়েল-টাইম টেলিমেট্রি। এসব অ্যাপ প্রায়ই নিজেদের হালকা নির্ভরযোগ্যতা লেয়ার বানায় (বা একেবারেই বানায় না) যা ব্যবহারকারীরা লক্ষ্য করেন।

আধুনিক একটি বড় উদাহরণ: QUIC UDP-র ওপর চলে, যা অ্যাপগুলোকে দ্রুত সংযোগ সেটআপ দেয় এবং কিছু TCP বটলনেক এড়াতে সাহায্য করে—বিনা IP-নেটওয়ার্ক পরিবর্তনের প্রয়োজন।

প্রায়োগিক নির্দেশিকা

নির্বাচন করুন:

• নির্ভরযোগ্যতার চাহিদা: প্রতিটি বাইট কি সঠিক ক্রমে আসাটা আবশ্যক? তাহলে TCP।
• ল্যাটেন্সি সংবেদনশীলতা: "এখন" কি "সম্পূর্ণতায়" বেশি গুরুত্বপূর্ণ? UDP বিবেচনা করুন।
• নিয়ন্ত্রণ: আপনি কি অ্যাপ স্তরে সিদ্ধান্ত নিতে চান কী রিট্রাই করা হবে এবং কী বাদ দেওয়া হবে? UDP (বা QUIC) এতে বেশি স্বাধীনতা দেয়।

কি "নির্ভরযোগ্য" আজও গ্যারান্টি করতে পারে না: বাস্তবজগতের ফাঁক

TCP প্রায়শই "নির্ভরযোগ্য" বলা হয়, কিন্তু এর মানে আপনার অ্যাপ সবসময় নির্ভরযোগ্য মনে হবে না। TCP অনেক নেটওয়ার্ক সমস্যার থেকে পুনরুদ্ধার করতে পারে, তবুও এটি নিম্ন বিলম্ব, সুষম থ্রুপুট বা অ্যাপ-রিলেটেড ভাল UX নিশ্চিত করতে পারে না যখন পথ অস্থিতিশীল।

আপনি যা এখনও দেখবেন এমন সাধারণ নেটওয়ার্ক সমস্যা

প্যাকেট লস TCP-কে রিট্রান্সমিট করতে বাধ্য করে। নির্ভরযোগ্যতা রক্ষা পায়, কিন্তু পারফরম্যান্স ভেঙে যেতে পারে।

উচ্চ ল্যাটেন্সি (দীর্ঘ RTT) প্রতিটি অনুরোধ/প্রতিক্রিয়া সাইকেলকে ধীর করে, এমনকি কোন প্যাকেট হারায় না।

Bufferbloat তখন ঘটে যখন রাউটার বা OS কিউগুলোতে খুব বেশি ডেটা জমে। TCP কম লস দেখলেও ব্যবহারকারীরা বিশাল দেরি ও ল্যাগ অনুভব করে।

ভুল কনফিগার করা MTU ফ্র্যাগমেন্টেশন বা ব্ল্যাকহোলিং সৃষ্টি করতে পারে (বড় প্যাকেটগুলো হারিয়ে যায়), এমন জটিল ব্যর্থতা যা র্যান্ডম টাইমআউটের মতো প্রতীয়মান হয়।

অ্যাপের ভেতরে এটা কেমন দেখায়

স্বচ্ছ "নেটওয়ার্ক ত্রুটি" দেখার বদলে আপনি প্রায়শই দেখতে পাবেন:

• সাধারণত কাজ করা API কলের টাইমআউট।
• দ্রুত শুরু হয়ে তারপর ক্রল করা আপলোড/ডাউনলোড।
• ফ্ল্যাকি কানেকশন: পুনরায় সংযোগ, স্টল হওয়া স্ট্রীম, বা আংশিক পেজ লোড।

এসব লক্ষণ বাস্তব, কিন্তু সবসময় আপনার কোডের ভুল নয়। প্রায়ই TCP তার কাজ করছে—রিট্রান্সমিট, ব্যাক অফ, অপেক্ষা—আর আপনার অ্যাপের টাইমার গননা করে।

বাস্তবসম্মত ডিবাগিং শুরু মনিটরিং পয়েন্টস

শুরু করুন: সমস্যা মূলত লোস, ল্যাটেন্সি, না পাথ চেঞ্জ—এর মধ্যে কোনটা তা ক্লাসিফাই করে।

• Ping-শৈলীর চেক ল্যাটেন্সি ও লস নিয়ে ধারনা দেয় (যদিও ICMP কখনো ব্লক করা হয়)।
• Traceroute-স্টাইল চিন্তা সাহায্য করে কোথায় দেরি বা ড্রপ শুরু হচ্ছে তা নির্ণয় করতে।
• লগ ও মেট্রিক্স যোগ করুন: অনুরোধের সময়, টাইমআউট গণনা, রিট্রাই কount, কিউ/ব্যাকপ্রেশার সিগন্যাল।

আপনি দ্রুত ডেভেলপ করলে (যেমন Koder.ai-তে একটি সার্ভিস প্রোটোটাইপ করে ডেপ্লয় করা), নেটওয়ার্ক অবজারভেবিলিটি বেসিকগুলো প্রাথমিক পরিকল্পনার অংশ হওয়া উচিত—কারণ নেটওয়ার্ক ব্যর্থতা প্রথমে টাইমআউট ও রিট্রাই হিসেবে দেখা দেয়, কিসেরওরূপ পরিষ্কার এক্সসেপশন নয়।

ব্যর্থতা মাথায় রেখে ডিজাইন করুন

নে অংশ খারাপ হবে এটা ধরে নিন। টাইমআউট ব্যবহার করুন, এক্সপোনেনশিয়াল ব্যাকঅফ সহ রিট্রাই রাখুন, এবং অপারেশনগুলোকে আইডেমপোটেন্ট রাখুন যাতে রিট্রাই দ্বিগুণ চার্জ বা দ্বিগুণ সৃষ্টি না করে।