০২ এপ্রি, ২০২৫·8 মিনিট
বব ক্যান এবং TCP/IP: অ্যাপগুলোর নিচে কাজ করা অদৃশ্য স্তর
জানুন কিভাবে Bob Kahn TCP/IP গঠন করতে সহায়ক ছিলেন, কেন নির্ভরযোগ্য প্যাকেট নেটওয়ার্কিং জরুরি, এবং কীভাবে এর ডিজাইন আজও অ্যাপ, API ও ক্লাউড সার্ভিসগুলো চালায়।
জানুন কিভাবে Bob Kahn TCP/IP গঠন করতে সহায়ক ছিলেন, কেন নির্ভরযোগ্য প্যাকেট নেটওয়ার্কিং জরুরি, এবং কীভাবে এর ডিজাইন আজও অ্যাপ, API ও ক্লাউড সার্ভিসগুলো চালায়।
অধিকাংশ অ্যাপ „তৎক্ষণাৎ“ মনে হয়: আপনি একটি বোতাম ট্যাপ করলে ফিড রিফ্রেশ হয়, পেমেন্ট সম্পন্ন হয়, ভিডিও শুরু হয়। আপনি যা দেখতে পান না তা হলো নিচে যা কাজ চলছে—চমকানো ক্ষুদ্র ডেটা প্যাকেটগুলো Wi‑Fi, সেলুলার নেটওয়ার্ক, হোম রাউটার ও ডেটা সেন্টার জুড়ে পাঠানো হচ্ছে—প্রায়শই একাধিক দেশের মধ্য দিয়ে—এবং আপনাকে মাঝখানের গোলমেলে বিষয়গুলো নিয়ে চিন্তা করতে হয় না।
এই অদৃশ্যতা TCP/IP প্রদান করে। এটা কোনো একক প্রোডাক্ট বা ক্লাউড ফিচার নয়। এটা নিয়মগুলোর একটি সেট যা ডিভাইস ও সার্ভারদের এমনভাবে কথা বলার সুযোগ দেয় যে সাধারণত অভিজ্ঞতা মসৃণ ও নির্ভরযোগ্য মনে হয়, এমনকি যখন নেটওয়ার্ক গোলমেলে, কনজেস্টেড বা অংশত ব্যর্থ।
Bob Kahn সেই সম্ভবতায় গুরুত্বপূর্ণ ভূমিকা রেখেছেন। Vint Cerf-এর মতো সহকর্মীদের সাথে তিনি TCP/IP-কে রূপ দেওয়ার মূল ধারণাগুলি তৈরি করতে সাহায্য করেছেন: নেটওয়ার্কগুলোর জন্য একটি সাধারণ “ভাষা” এবং এমন একটি পদ্ধতি যাতে অ্যাপগুলো ডেটা বিশ্বস্তভাবে পেতে পারে। কোনো হাইপ নয়—এই কাজটি গুরুত্বপূর্ণ ছিল কারণ এটি অনির্ভরযোগ্য সংযোগকে এমন কিছুতে পরিণত করল যার উপরে সফটওয়্যার নির্ভর করে তৈরি করা যায়।
পুরো বার্তাটা একসঙ্গে পাঠানোর বদলে, প্যাকেট নেটওয়ার্কিং এটিকে ছোট ছোট টুকরো — প্যাকেট — এ ভেঙে দেয়। প্রতিটি প্যাকেট গন্তব্যে নিজের পথে যেতে পারে, ঠিক আলাদা খামে আলাদা পোস্ট অফিসের মতো।
আমরা ব্যাখ্যা করব কিভাবে TCP নির্ভরতার অনুভূতি তৈরি করে, কেন IP ইচ্ছাকৃতভাবে পরিপূর্ণতার নিশ্চয়তা দেয় না, এবং কিভাবে লেয়ারিং সিস্টেমটিকে বোধগম্য রাখে। শেষ পর্যন্ত আপনি কল্পনা করতে সক্ষম হবেন যখন একটি অ্যাপ একটি API কল করে—আর কেন এই দশক পুরানো ধারণাগুলো আজকের ক্লাউড সার্ভিসগুলোকেও চালায়।
আদিম কম্পিউটার নেটওয়ার্কগুলো “ইন্টারনেট” হিসেবে জন্মায়নি। সেগুলো নির্দিষ্ট গোষ্ঠীর জন্য নির্মিত হয়েছিল—একটি বিশ্ববিদ্যালয়ের নেটওয়ার্ক এখানে, একটি সামরিক নেটওয়ার্ক ওখানে, একটি গবেষণাগারের নেটওয়ার্ক অন্য কোথাও। প্রতিটি ভেতরে ভাল কাজ করতে পারে, কিন্তু প্রায়শই তারা ভিন্ন হার্ডওয়্যার, মেসেজ ফরম্যাট ও ডেটা যাত্রার নিয়ম ব্যবহার করত।
ফলাফল ছিল হতাশাজনক: দুইটি কম্পিউটার যদি নেটওয়ার্কেডও থাকে, তবুও তারা তথ্য বিনিময় করতে নাও পারে। এটা অনেক রেল সিস্টেমের মতো যেখানে ট্র্যাকের প্রস্থ ভিন্ন এবং সিগন্যালের মানে ভিন্ন—এক সিস্টেমের ভেতরে ট্রেন চলে, কিন্তু অন্য সিস্টেমে যাওয়া জটিল, ব্যয়বহুল বা অসম্ভব।
বব কানের মূল চ্যালেঞ্জ ছিল কেবল “কম্পিউটার A-কে কম্পিউটার B-র সাথে সংযুক্ত করা” নয়। সেটা ছিল: কিভাবে নেটওয়ার্কগুলোকে একে অপরের সাথে এমনভাবে সংযুক্ত করা যায় যাতে ট্রাফিক একাধিক স্বাধীন সিস্টেম পেরিয়ে যাওয়ার পরেও তারা একটি বড় সিস্টেমের মতো কাজ করে?
এটিই “ইন্টারনেটওয়ার্কিং”—তথ্যকে একটি নেটওয়ার্ক থেকে অন্য নেটওয়ার্কে হপ করানোর পদ্ধতি তৈরি করা, এমনকি ঐ নেটওয়ার্কগুলো ভিন্নভাবে ডিজাইন ও পরিচালিত হলে ওগুলোকে একসাথে কাজ করানো।
ইন্টারনেটওয়ার্কিংকে স্কেলে কাজ করতে হলে সবাইকে একটি সাধারণ নিয়ম সেট দরকার ছিল—প্রটোকল—যা কোনো একক নেটওয়ার্কের অভ্যন্তরীণ ডিজাইনের উপর নির্ভর করে না। সেই নিয়মগুলো বাস্তব সীমাবদ্ধতাও প্রতিফলিত করতে হবে:
TCP/IP একটি বাস্তবসম্মত উত্তর হয়ে উঠল: একটি শেয়ার করা “চুক্তি” যা স্বাধীন নেটওয়ার্কগুলোকে ইন্টারকনেক্ট করে এবং বাস্তব অ্যাপলিকেশনের জন্য পর্যাপ্তভাবে নির্ভরযোগ্যভাবে ডেটা সরাতে দেয়।
বব ক্যান ইন্টারনেটের “রোড রুলস” তৈরি করার মূল স্থপতিদের একজন হিসেবে পরিচিত। 1970-এর দশকে DARPA-তে কাজ করার সময় তিনি নেটওয়ার্কিংকে একটি চতুর গবেষণামূলক পরীক্ষা থেকে এমন কিছুতে নিয়ে যাওয়ার উপর কাজ করেছিলেন যা বিভিন্ন ধরনের নেটওয়ার্ককে সংযুক্ত করতে পারে—ইতোমধ্যে সেগুলোকে একই হার্ডওয়্যার, তার বা অভ্যন্তরীণ ডিজাইনে বাধ্য না করে।
ARPANET দেখিয়েছে কম্পিউটার প্যাকেট-সুইচড লিঙ্কে যোগাযোগ করতে পারে। কিন্তু অন্যান্য নেটওয়ার্কগুলোও উঠে আসছিল—রেডিওভিত্তিক সিস্টেম, স্যাটেলাইট লিঙ্ক, এবং অন্যান্য পরীক্ষামূলক নেটওয়ার্ক—প্রতিটিই নিজের আচরণ নিয়ে। কানের ফোকাস ছিল ইন্টারঅপারেবিলিটি: একটি বার্তাকে একাধিক নেটওয়ার্ক জুড়ে একই নেটওয়ার্কের অংশ হিসেবে যাত্রা করানো।
একটি “পারফেক্ট” নেটওয়ার্ক গড়ার বদলে তিনি এমন একটি পদ্ধতি প্রয়োগের পক্ষে ছিলেন যেখানে:
Vint Cerf-এর সঙ্গে কাজ করে তিনি যা ডিজাইন করেছেন তা TCP/IP হিসেবে গড়ে উঠল। একটি স্থায়ী ফল হলো দায়িত্বগুলোর পরিষ্কার বিভাজন: IP ঠিকানা ও ফরওয়ার্ডিং হ্যান্ডেল করে, আর TCP যে অ্যাপ্লিকেশনগুলোকে দরকার তাদের জন্য নির্ভরযোগ্য ডেলিভারি দেয়।
আপনি যদি কখনও একটি API কল করে থাকেন, একটি ওয়েব পেজ লোড করে থাকেন, বা কনটেইনার থেকে লগ মনিটরিং সার্ভিসে পাঠিয়ে থাকেন, আপনি কানের প্রচারিত ইন্টারনেটওয়ার্কিং মডেলের ওপর নির্ভর করছেন। আপনাকে চিন্তা করতে হয় না যে প্যাকেট কিভাবে Wi‑Fi, ফাইবার, LTE বা ক্লাউড ব্যাকবোন পার করছে। TCP/IP এগুলোকে একটি একক ধারাবাহিক সিস্টেমের মতো করে তোলে—ফলে সফটওয়্যার ফিচারে ফোকাস করতে পারে, তার তারপাটা নিয়ে না গিয়ে।
TCP/IP-এর পেছনের সবচেয়ে স্মার্ট ধারণাগুলোর একটি হলো লেয়ারিং: একটি বিশাল “সবকিছুই করা” নেটওয়ার্ক সিস্টেম গড়ার বদলে আপনি ছোট ছোট স্তর স্ট্যাক করেন যেখানে প্রতি স্তর এক কাজ ভালভাবে করে।
এটি গুরুত্বপূর্ণ কারণ নেটওয়ার্কগুলো সব একরকম নয়। বিভিন্ন কেবল, রেডিও, রাউটার ও প্রদানকারী মিলেও ইন্টারঅপারেবল হতে পারে যখন তারা কয়েকটি পরিষ্কার দায়িত্বে সম্মত হয়।
IP (Internet Protocol) ভাবুন এমন অংশ হিসাবে যা বলে: এই ডেটা কোথায় যেতে হবে, এবং আমরা কিভাবে এটাকে কাছাকাছি নিয়ে যাব?
IP প্রদান করে ঠিকানা (যাতে মেশিনগুলো সনাক্ত হয়) এবং মৌলিক রাউটিং (প্যাকেটগুলো নেটওয়ার্ক থেকে নেটওয়ার্কে হপ করে)। গুরুত্বপূর্ণ ব্যাপার হলো, IP পরিপূর্ণ হওয়ার চেষ্টা করে না। এটি প্যাকেটগুলোকে এক ধাপ করে সামনে পাঠাতে ফোকাস করে, এমনকি যদি পথ বদলে যায়।
তারপর TCP (Transmission Control Protocol) IP-এর উপরে বসে এবং উত্তর দেয়: এটি কিভাবে নির্ভরযোগ্য সংযোগের মতো মনে করাবো?
TCP অ্যাপ্লিকেশনগুলো সাধারণত যা চায় তা করে: ডেটা সঠিক ক্রমে ডেলিভারি করা, হারিয়ে যাওয়া অংশ শনাক্ত করে পুনঃপ্রেরণ, এবং প্রেরককে ধীর করে দেয় যাতে রিসিভার বা নেটওয়ার্ক ওভারওয়েল্ম না হয়।
একটি উপকারী কল্পনা:
আপনি স্ট্রিট ঠিকানাকে প্যাকেজ এসে পৌঁছানোর নিশ্চয়তা দিতে বলবেন না; সেই নিশ্চয়তা আপনি উপরে গড়বেন।
কারণ দায়িত্বগুলো আলাদা, আপনি একটি স্তর উন্নত করতে পারেন বাকি সবকিছু পুনর্নির্মাণ না করেই। নতুন ফিজিক্যাল নেটওয়ার্ক IP বহন করতে পারে, এবং অ্যাপ্লিকেশনগুলো TCP-এর আচরণে নির্ভর করতে পারে রাউটিং কিভাবে কাজ করে তা বুঝতে না হলেও। এই পরিষ্কার বিভাজন TCP/IP-কে প্রায় প্রতিটি অ্যাপ ও API-এর অব্যক্ত ভিত্তি করে তুলেছে।
প্যাকেট সুইচিং সেই ধারণা যা বড় নেটওয়ার্কগুলোকে ব্যবহারিক করেছে: আপনার পুরো বার্তাটির জন্য একটি নির্ধারিত লাইন সংরক্ষণ করার বদলে, আপনি বার্তাটিকে ছোট টুকরো করে প্রতিটিকে স্বাধীনভাবে পাঠান।
প্যাকেট হল ছোট ডেটার প্যাকেট যার একটি হেডার থাকে (কে পাঠিয়েছে, কে নেবে, এবং অন্যান্য রাউটিং তথ্য) ও কন্টেন্টের একটি অংশ।
ডেটা টুকরো করলে নেটওয়ার্ক করতে পারে:
এখানেই “অরাজকতা” শুরু হয়। একই ডাউনলোড বা API কলের প্যাকেটগুলো নেটওয়ার্কে বিভিন্ন রুট নিতে পারে, যা ওই মুহূর্তে কী ব্যস্ত বা উপলব্ধ তার উপর নির্ভর করে। ফলে এগুলো আউট অফ অর্ডার পৌঁছাতে পারে—প্যাকেট #12 আসতে পারে #5-এর আগে।
প্যাকেট সুইচিং তা প্রতিহত করে না। দ্রুত প্যাকেট পাঠানোই অগ্রাধিকার দেয়, এমনকি আগমনের ক্রম অসংলগ্ন হলে ও।
প্যাকেট লস বিরল নয় এবং সবসময় কারও দোষও নয়। সাধারণ কারণগুলোর মধ্যে:
মূল ডিজাইন পছন্দ হলো নেটওয়ার্ককে অসম্পূর্ণ হতে অনুমতি দেয়া। IP প্যাকেটগুলোকে এগোতে গুরুত্ব দেয়, ডেলিভারি বা অর্ডার প্রতিশ্রুতি না দিয়ে। সেই স্বাধীনতা নেটওয়ার্কগুলোকে স্কেল করতে দেয়—এবং এজন্য উচ্চতর লেয়ার (যেমন TCP) আছে যা বিশৃঙ্খলা মেটায়।
IP প্যাকেটগুলোকে “সেরা প্রচেষ্টায়” ডেলিভারি করে: কিছু দেরিতে পৌঁছতে পারে, আউট অফ অর্ডার হতে পারে, ডুপ্লিকেট হতে পারে, বা একেবারেই না-ও আসতে পারে। TCP উপরে বসে এবং অ্যাপলিকেশনের জন্য এমন কিছু তৈরি করে যাকে তারা বিশ্বাস করতে পারে: একটি একক, অর্ডার্ড, সম্পূর্ণ বাইট স্ট্রিম—যেটি আপনি ফাইল আপলোড, ওয়েব পেজ লোড বা API কলের ক্ষেত্রে আশা করেন।
যখন মানুষ বলে TCP “নির্ভরযোগ্য”, সাধারণত তারা বোঝায়:
TCP আপনার ডেটা টুকরো করে এবং তাদের সিকোয়েন্স নম্বর দেয়। রিসিভার acknowledgment (ACK) পাঠায় যা কি পেয়েছে তা নিশ্চিত করে।
যদি প্রেরক নির্দিষ্ট সময়ের মধ্যে ACK না দেখে, এটি ধরে নেয় কিছু হারিয়েছে এবং রিট্রান্সমিশন করে। এটি হল মূলে সেই “ভ্রমের” ক্লূ: নেটওয়ার্ক প্যাকেট ড্রপ করলেও TCP প্রেরণ অব্যাহত রাখে যতক্ষণ না রিসিভার গ্রহণ নিশ্চিত করে।
শুনতে মিলছে, কিন্তু আলাদা সমস্যা সমাধান করে:
একসঙ্গে, এগুলো TCP-কে দ্রুত থাকতে দেয় বিনা লজ্জায়।
একটি স্থির টাইমআউট ধীর ও দ্রুত উভয় নেটওয়ার্কেই ব্যর্থ হত। TCP ধারাবাহিকভাবে তার টাইমআউট সামঞ্জস্য করে পরিমাপ করা রাউন্ড-ট্রিপ টাইমের উপর ভিত্তি করে। পরিস্থিতি খারাপ হলে বেশি অপেক্ষা করে পুনরায় পাঠ করে; যদি দ্রুত হয়, তা আরও প্রতিক্রিয়াশীল হয়। এই অভিযোজন TCP-কে Wi‑Fi, মোবাইল নেটওয়ার্ক ও দূরবর্তী লিঙ্ক জড়িয়েও কাজ করতে রাখে।
TCP/IP-এর অন্যতম গুরুত্বপূর্ণ ধারণা হল এন্ড-টু-এন্ড নীতি: নেটওয়ার্কের “মধ্য” তুলনামূলকভাবে সহজ রাখো এবং “স্মার্টনেস” এন্ডপয়েন্টে রাখো।
সরলভাবে বলতে এন্ডপয়েন্টগুলো হলো ডিভাইস ও প্রোগ্রাম—আপনার ফোন, ল্যাপটপ, সার্ভার ও সেগুলোর OS এবং অ্যাপ। নেটওয়ার্ক কোর—রাউটার ও লিংক—মুলত প্যাকেট এগিয়ে নেওয়ার উপর ফোকাস করে।
রাউটারকে প্রতিটি অ্যাপের প্রয়োজন বুঝতে বলার বদলে TCP/IP ধরে নেয় যে মাঝখান গোলমেলে হবে এবং এন্ডপয়েন্টগুলোই প্রাসঙ্গিক অংশ হ্যান্ডেল করবে।
কোরকে সহজ রাখলে ইন্টারনেট বাড়ানো সহজ হলো। নতুন নেটওয়ার্ক যোগ করতে কোর ডিভাইসগুলোকে প্রতিটি অ্যাপের প্রয়োজন বোঝাতে হবে না। রাউটারদের জানতে হয় না কোন প্যাকেট ভিডিও কলের, ফাইল ডাউনলোডের বা API অনুরোধের অংশ—তারা শুধু ফরওয়ার্ড করে।
এন্ডপয়েন্টগুলোতে সাধারণত হ্যান্ডেল করা হয়:
নেটওয়ার্কে সাধারণত হ্যান্ডেল করা হয়:
এন্ড-টু-এন্ড চিন্তা ভালো স্কেল করে, কিন্তু জটিলতা বাইরের দিকে ঠেলে দেয়। অপারেটিং সিস্টেম, লাইব্রেরি ও অ্যাপ্লিকেশনগুলোকে ‘এটি কাজ করবে’ করে তোলা কঠিন হতে পারে—বাগ, ভুল কনফিগার করা টাইমআউট বা অতিরিক্ত আক্রমণাত্মক রিট্রাই ব্যবহারকারীর সামনে সমস্যার সৃষ্টি করতে পারে।
IP একটি সহজ প্রতিশ্রুতি দেয়: এটি আপনার প্যাকেটগুলো গন্তব্যের দিকে পাঠানোর চেষ্টা করবে। কেবল তাই। কোনো গ্যারান্টি নেই যে প্যাকেট পৌঁছাবে, একবারই পৌঁছাবে, সঠিক ক্রমে পৌঁছাবে বা কোনো নির্দিষ্ট সময়ে পৌঁছাবে।
এটি ত্রুটি মনে হতে পারে—তবে ইন্টারনেট কী হওয়া দরকার ছিল তা দেখলে বোঝা যায় কেন এটা দরকার ছিল: একটি গ্লোবাল নেটওয়ার্ক যা অনেক ছোট নেটওয়ার্ক দিয়ে গঠিত, ভিন্ন সংস্থার মালিকানায় ও পরিবর্তিত হতে থাকবে।
রাউটার IP-র “ট্রাফিক ডিরেক্টর”। মূল কাজ হলো ফরওয়ার্ডিং: যখন একটি প্যাকেট আসে, রাউটার গন্তব্য ঠিকানা দেখে পরবর্তী হপ বেছে নেয় যা বর্তমানভাবে সেরা বলে মনে হয়।
রাউটার সাধারণত কনভারসেশন ট্র্যাক করে না যেমন ফোন অপারেটর করে। তারা সাধারণত আপনার জন্য ক্যাপাসিটি রিজার্ভ করে না এবং প্যাকেটটি পাস হলো কিনা নিশ্চিত করতে অপেক্ষা করে না। রাউটারগুলোকে ফরওয়ার্ডিং-এ ফোকাস করে কোরটি সিম্পল রাখা হয়—এবং এতে বিশাল সংখ্যক ডিভাইস ও সংযোগ স্কেল করতে পারে।
গ্যারান্টি ব্যয়বহুল। যদি IP প্রতিটি প্যাকেটের জন্য ডেলিভারি, অর্ডার ও সময়ের নিশ্চয়তা দেয়, তাহলে পৃথিবীর প্রতিটি নেটওয়ার্ককে কড়া সমন্বয় করতে হতো, প্রচুর স্টেট রাখা লাগতো এবং ব্যর্থতার সময় পুনরুদ্ধার কঠিন হতো। সেই সমন্বয়ের বোঝা বৃদ্ধি পেলে বৃদ্ধিও ধীর হতো এবং আউটেজ আরও গুরুতর হত।
বদলে IP গোলমেল সহ্য করে। যদি একটি লিংক ব্যর্থ হয়, একটি রাউটার প্যাকেটগুলো ভিন্ন রুটে পাঠাতে পারে। যদি একটি পথ কনজেস্টেড হয়, প্যাকেট বিলম্বিত বা ড্রপ হতে পারে, কিন্তু বিকল্প রুট দিয়ে ট্রাফিক প্রায়ই চালু রাখতে পারে। ফলাফল হলো টেকসইতা: ইন্টারনেট কাজ চালিয়ে যেতে পারে এমনকি অংশবিশেষ ভেঙে গেলেও—কারণ নেটওয়ার্ককে নিখুঁত হতে বাধ্য করা হয়নি।
আপনি যখন fetch() এ একটি API কল করেন, “Save” এ ক্লিক করেন বা একটি websocket খুলেন, আপনি একসঙ্গে সার্ভারের সাথে এক মসৃণ স্ট্রিমে কথা বলছেন না। আপনার অ্যাপ OS-কে ডেটা সমর্পণ করে, যা এটিকে প্যাকেটগুলোতে ভাগ করে এবং সেগুলোকে বহু পৃথক নেটওয়ার্কে পাঠায়—প্রতিটি হপ নিজস্ব সিদ্ধান্ত নেয়।
একটি সাধারণ বিস্ময়: আপনার কাছে দুর্দান্ত থ্রুপুট থাকতে পারে এবং তবুও UI ধীর মনে হতে পারে কারণ প্রতিটি অনুরোধ রাউন্ড-ট্রিপের জন্য অপেক্ষা করে।
TCP হারানো প্যাকেট পুনরায় পাঠায়, কিন্তু এটি আপনার ব্যবহারকারীর জন্য “একটু বেশি সময়” কী তা জানে না। এজন্য অ্যাপ্লিকেশনগুলো যোগ করে:
প্যাকেট দেরিতে আসতে পারে, পুনরায় সাজানো, ডুপ্লিকেট বা ড্রপ হতে পারে। কনজেশন ল্যাটেন্সি বাড়ায়। সার্ভার উত্তর দিলেও প্রতিক্রিয়া আপনার কাছে পৌঁছাতে নাও পারে। এগুলো ফ্ল্যাকি টেস্ট, র্যান্ডম 504 বা “আমার মেশিনে চলে”র মত ফলাফল দেয়। প্রায়শই কোড ঠিকই থাকে—দুটি মেশিনের মধ্যে পথটাই সমস্যা।
ক্লাউড প্ল্যাটফর্মগুলো একটি পুরো নতুন ধরনের কম্পিউটিং মনে হতে পারে—ম্যানেজড ডেটাবেস, সার্ভারলেস ফাংশন, “অনন্ত” স্কেলিং। নিচে আপনার অনুরোধগুলো তখনও একই TCP/IP ভিত্তিতে চলেই: IP প্যাকেটগুলো নেটওয়ার্ক জুড়ে নিয়ে যায়, এবং TCP (বা কখনো UDP) অ্যাপগুলোকে নেটওয়ার্ক অনুভবে কেমন লাগে তা নির্ধারণ করে।
ভার্চুয়ালাইজেশন ও কনটেইনার বদলে দেয় কোথায় সফটওয়্যার চলে এবং কিভাবে প্যাকেজ করা হয়:
কিন্তু এগুলো ডিপ্লয়মেন্টের বিবরণ; প্যাকেটগুলো এখনও IP ঠিকানা ও রাউটিং ব্যবহার করে এবং অনেক সংযোগ এখনও TCP-র ওপর নির্ভর করে।
প্রচলিত ক্লাউড আর্কিটেকচারে পরিচিত নেটওয়ার্কিং বিল্ডিং ব্লকগুলো দেখা যায়:
আপনি IP ঠিকানা কখনো দেখেন না, প্ল্যাটফর্ম সেগুলো বরাদ্দ করছে, রুট করছে এবং কানেকশন ট্র্যাক করছে পেছনে।
TCP ড্রপ করা প্যাকেট পুনরুদ্ধার করতে পারে, ডেলিভারি পুনরায় সাজাতে পারে এবং কনজেশন অনুযায়ী মানিয়ে নিতে পারে—কিন্তু এটি অসম্ভব তথ্য প্রতিশ্রুতি দিতে পারে না। ক্লাউড সিস্টেমগুলোতে নির্ভরযোগ্যতা একটি টিমের কাজ:
এই কারণেই এমন প্ল্যাটফর্মগুলো (যেগুলো পূর্ণ-স্ট্যাক অ্যাপ জেনারেট ও ডেপ্লয় করে) একই মৌলিক তত্ত্বে নির্ভরশীল। উদাহরণস্বরূপ, Koder.ai আপনাকে দ্রুত React ও Go ব্যাকএন্ড সহ একটি অ্যাপ বানাতে সাহায্য করতে পারে, কিন্তু যখন সেই অ্যাপ কোনো API, ডাটাবেস বা মোবাইল ক্লায়েন্টের সাথে কথা বলে, তখন আপনি আবার TCP/IP-র জমানায় ঢুকবেন—কানেকশন, টাইমআউট, রিট্রাই সবই আছে।
যখন ডেভেলপাররা “নেটওয়ার্ক” বলেন, তারা প্রায়শই দুইটি কাজের ঘোড়ার মধ্যে বেছে নিচ্ছেন: TCP ও UDP। উভয়ই IP-এর ওপর বসে, কিন্তু তারা খুব ভিন্ন ট্রেড-অফ করে।
TCP তখন উপযুক্ত যখন আপনাকে ডেটা সঠিক ক্রমে, বিনা গ্যাপে চাই এবং অপেক্ষা করা ভালো—উদাহরণ: ওয়েব পেজ, API কল, ফাইল ট্রান্সফার, ডাটাবেস কানেকশন।
এই কারণেই দৈনন্দিন ইন্টারনেটের বড় অংশ TCP-র ওপর চলে—HTTPS TCP-র ওপর চলে (TLS ব্যবহারের মাধ্যমে), এবং অনেক রিকোয়েস্ট/রেসপন্স সফটওয়্যার TCP-এর আচরণ ধরে নিয়েই ডিজাইন করা।
কিন্তু খরচ আছে: TCP-র নির্ভরযোগ্যতা ল্যাটেন্সি যোগ করতে পারে। যদি একটি প্যাকেট হারায়, পরবর্তী প্যাকেটগুলোকে gap-পুরণ না হওয়া পর্যন্ত ধরে রাখা হতে পারে ("head-of-line blocking")। ইন্টারঅ্যাকটিভ অভিজ্ঞতার জন্য সেই অপেক্ষা মাঝে মাঝে একটি অগত্যা ত্রুটি থেকে খারাপ অনুভূতি তৈরি করে।
UDP হল ’মেসেজ পাঠাও এবং আশা করো এটি পৌঁছাবে’ রকম—এখানে বিল্ট-ইন অর্ডারিং, রিট্রান্সমিশন বা কনজেশন হ্যান্ডল নেই।
ডেভেলপাররা UDP তখন বেছে নেন যখন টাইমিং পারফেকশনের চেয়ে বেশি গুরুত্বপূর্ণ, যেমন লাইভ অডিও/ভিডিও, গেমিং বা রিয়েল-টাইম টেলিমেট্রি। এসব অ্যাপ প্রায়ই নিজেদের হালকা নির্ভরযোগ্যতা লেয়ার বানায় (বা একেবারেই বানায় না) যা ব্যবহারকারীরা লক্ষ্য করেন।
আধুনিক একটি বড় উদাহরণ: QUIC UDP-র ওপর চলে, যা অ্যাপগুলোকে দ্রুত সংযোগ সেটআপ দেয় এবং কিছু TCP বটলনেক এড়াতে সাহায্য করে—বিনা IP-নেটওয়ার্ক পরিবর্তনের প্রয়োজন।
নির্বাচন করুন:
TCP প্রায়শই "নির্ভরযোগ্য" বলা হয়, কিন্তু এর মানে আপনার অ্যাপ সবসময় নির্ভরযোগ্য মনে হবে না। TCP অনেক নেটওয়ার্ক সমস্যার থেকে পুনরুদ্ধার করতে পারে, তবুও এটি নিম্ন বিলম্ব, সুষম থ্রুপুট বা অ্যাপ-রিলেটেড ভাল UX নিশ্চিত করতে পারে না যখন পথ অস্থিতিশীল।
প্যাকেট লস TCP-কে রিট্রান্সমিট করতে বাধ্য করে। নির্ভরযোগ্যতা রক্ষা পায়, কিন্তু পারফরম্যান্স ভেঙে যেতে পারে।
উচ্চ ল্যাটেন্সি (দীর্ঘ RTT) প্রতিটি অনুরোধ/প্রতিক্রিয়া সাইকেলকে ধীর করে, এমনকি কোন প্যাকেট হারায় না।
Bufferbloat তখন ঘটে যখন রাউটার বা OS কিউগুলোতে খুব বেশি ডেটা জমে। TCP কম লস দেখলেও ব্যবহারকারীরা বিশাল দেরি ও ল্যাগ অনুভব করে।
ভুল কনফিগার করা MTU ফ্র্যাগমেন্টেশন বা ব্ল্যাকহোলিং সৃষ্টি করতে পারে (বড় প্যাকেটগুলো হারিয়ে যায়), এমন জটিল ব্যর্থতা যা র্যান্ডম টাইমআউটের মতো প্রতীয়মান হয়।
স্বচ্ছ "নেটওয়ার্ক ত্রুটি" দেখার বদলে আপনি প্রায়শই দেখতে পাবেন:
এসব লক্ষণ বাস্তব, কিন্তু সবসময় আপনার কোডের ভুল নয়। প্রায়ই TCP তার কাজ করছে—রিট্রান্সমিট, ব্যাক অফ, অপেক্ষা—আর আপনার অ্যাপের টাইমার গননা করে।
শুরু করুন: সমস্যা মূলত লোস, ল্যাটেন্সি, না পাথ চেঞ্জ—এর মধ্যে কোনটা তা ক্লাসিফাই করে।
আপনি দ্রুত ডেভেলপ করলে (যেমন Koder.ai-তে একটি সার্ভিস প্রোটোটাইপ করে ডেপ্লয় করা), নেটওয়ার্ক অবজারভেবিলিটি বেসিকগুলো প্রাথমিক পরিকল্পনার অংশ হওয়া উচিত—কারণ নেটওয়ার্ক ব্যর্থতা প্রথমে টাইমআউট ও রিট্রাই হিসেবে দেখা দেয়, কিসেরওরূপ পরিষ্কার এক্সসেপশন নয়।
নে অংশ খারাপ হবে এটা ধরে নিন। টাইমআউট ব্যবহার করুন, এক্সপোনেনশিয়াল ব্যাকঅফ সহ রিট্রাই রাখুন, এবং অপারেশনগুলোকে আইডেমপোটেন্ট রাখুন যাতে রিট্রাই দ্বিগুণ চার্জ বা দ্বিগুণ সৃষ্টি না করে।
TCP/IP হল একটি শেয়ার করা নেটওয়ার্কিং নিয়মাবলী যার মাধ্যমে বিভিন্ন নেটওয়ার্ক একে অপরের সাথে সংযুক্ত হয়ে নির্দিষ্টভাবে ডেটা স্থানান্তর করতে পারে।
এটি গুরুত্বপূর্ণ কারণ এটি অনির্ভরযোগ্য ও অসমান নেটওয়ার্ক (Wi‑Fi, LTE, ফাইবার, স্যাটেলাইট) ব্যবহারযোগ্য করে তোলে—ফলে অ্যাপগুলো পার física নেটওয়ার্কের বিবরণ না জানলেও বাইড ata পাঠাতে ও প্রতিক্রিয়া পেতে পারে।
বব কান ‘ইন্টারনেটওয়ার্কিং’ ধারণার যুগান্তকারী কাজ করায় পরিচিত: কিভাবে নেটওয়ার্কগুলোকে একে অপরের সাথে যুক্ত করা যায় যাতে তারা এক বড় সিস্টেমের মতো ট্রাফিক পাস করতে পারে, তা ছাড়া প্রতিটি নেটওয়ার্ককে একই হার্ডওয়্যার বা অভ্যন্তরীণ ডিজাইনে বাধ্য করা না হয়।
তিনি (Vint Cerf সহ) এমন একটি বিভাজন গড়েছেন যেখানে IP ঠিকানা ও রুটিংয়ের দায়িত্ব নেয় এবং TCP অ্যাপলিকেশনের জন্য নির্ভরযোগ্য ডেলিভারি নিশ্চিত করে।
প্যাকেট সুইচিং মানে একটি বার্তা ছোট ছোট প্যাকেট এ ভাগ করা যাতে প্রতিটি প্যাকেট স্বাধীনভাবে যাত্রা করতে পারে।
ফায়দা:
IP একটি কাজ করে: প্যাকেটগুলোকে গন্তব্য ঠিকানার দিকে ফরওয়ার্ড করা। এটি ডেলিভারি, অর্ডার বা নির্দিষ্ট টাইমিং নিশ্চয়তা দেয় না।
এই “বেস্ট-এফফোর্ট” মডেলটি গ্লোবালি স্কেল করতে সাহায্য করে কারণ রাউটারগুলো সহজ ও দ্রুত থাকে, নেটওয়ার্কগুলো পরিবর্তিত হলেও ইন্টারকানেকশন বজায় থাকে।
TCP IP-এর বেস্ট-এফফোর্ট প্যাকেটগুলোকে অ্যাপলিকেশনের উপযোগী অর্ডার্ড বাইট স্ট্রিম-এ রূপান্তর করে।
এর জন্য এটি করে:
Flow control এবং congestion control আলাদা সমস্যা সমাধান করে:
ভালো পারফরম্যান্সের জন্য দুইটাই দরকার: দ্রুত সেন্ডারকে রিসিভার ও নেটওয়ার্ক উভয়ের সীমা মানতে হয়।
লেয়ারিং দায়িত্বগুলো আলাদা করে দেয়, ফলে প্রতিটি অংশ স্বাধীনভাবে পরিবর্তন ও উন্নত করা যায়:
ডেভেলপারদের জন্য ফলাফল: আপনার API ডিজাইন সব নেটওয়ার্ক টাইপের জন্য পুনর্নির্মাণ করতে হবে না।
এন্ড-টু-এন্ড প্রিন্সিপল মানে নেটওয়ার্কের কোর (রাউটার) তুলনামূলকভাবে সিম্পল রাখো এবং ‘স্মার্টনেস’ এন্ডপয়েন্টগুলোতে রাখো।
ব্যবহারিক অর্থ: অ্যাপ ও OS গুলোই নির্ভরযোগ্যতা, টাইমআউট, রিট্রাই, এনক্রিপশন (প্রায়শই TLS) ইত্যাদি হ্যান্ডেল করে—কারণ কোর প্রতিটি অ্যাপের চাহিদা ধরে রাখতে পারে না।
Latency হল রাউন্ড-ট্রিপ সময়; এটি চ্যাটি প্যাটার্নকে ধকল দেয় (অনেক ছোট রিকোয়েস্ট, রিডাইরেক্ট)।
Throughput হল প্রতি সেকেন্ডে পাঠানো বাইট; বড় ট্রান্সফার (ইমেজ, ব্যাকআপ, ভিডিও) এ এটি গুরুত্বপূর্ণ।
প্রায়োগিক টিপস:
নিয়ম অনুযায়ী:
নিয়ম: যদি আপনার অ্যাপ অনুরোধ/প্রতিক্রিয়া এবং সঠিকতা-প্রথম হয়, TCP (বা HTTP/3-এর মাধ্যমে QUIC) সাধারণত শুরু করার স্থান।