সরাসরি পর্বে যান
পর্ব ০১ · ৬২-এর মধ্যে · মডিউল ১

কম্পিউটার নেটওয়ার্ক কী আর কেন — ইন্টারনেট আসলে কী

What Is a Computer Network, Why We Need It, and What the Internet Really Is

Taught in Bangla, this lesson introduces computer networks as nodes, links and protocols, explains the Internet as a network of networks with hosts, access networks, ISPs and IXPs, walks through what happens when a website opens (DNS, TCP, HTTP), who writes the rules (IETF RFCs, IEEE 802, ITU, W3C), shows interfaces, loopback and localhost on your own machine, a short history from ARPANET, and the course roadmap.

এই পর্বে যা শিখবেন

  • নেটওয়ার্কের তিনটি মূল উপাদান, আর মানুষ কেন নেটওয়ার্ক বানায়
  • ইন্টারনেটের গঠন — host, access network, core, ISP আর IXP — এবং ফোন থেকে সার্ভার পর্যন্ত একটি request-এর পথ
  • Protocol মানে কী, packet কেন, আর নিয়মগুলো কারা লেখে (RFC, IEEE 802, ITU, W3C)
  • নিজের যন্ত্রে নেটওয়ার্ক interface, loopback আর localhost চোখে দেখা
  • ইন্টারনেটের সংক্ষিপ্ত ইতিহাস, বাংলাদেশের সংযোগের চিত্র, আর পুরো কোর্সের রোডম্যাপ

১ · নেটওয়ার্ক কী — node, link আর protocol

সকালে ঘুম ভেঙে আপনি ফোন হাতে নিলেন। Facebook-এ নতুন পোস্ট এলো, bKash-এ টাকা এলো, WhatsApp-এ মায়ের মেসেজ এলো। এর কোনোটিই আপনার ফোনের ভেতরে তৈরি হয়নি। এসেছে অন্য কোনো যন্ত্র থেকে, হয়তো হাজার কিলোমিটার দূর থেকে, এক সেকেন্ডেরও কম সময়ে। যে ব্যবস্থা এটা সম্ভব করে, তার নাম কম্পিউটার নেটওয়ার্ক।

সংজ্ঞাটি সহজ: কম্পিউটার নেটওয়ার্ক হলো দুই বা ততোধিক যন্ত্রের একটি ব্যবস্থা, যারা কোনো মাধ্যম দিয়ে যুক্ত এবং একই নিয়ম মেনে তথ্য আদান-প্রদান করে। এই এক বাক্যে তিনটি জিনিস লুকিয়ে আছে:

🖥️ Node (যন্ত্র)

নেটওয়ার্কে যুক্ত প্রতিটি যন্ত্র একটি node. ফোন, ল্যাপটপ, সার্ভার, প্রিন্টার, CCTV ক্যামেরা — আবার মাঝখানের router ও switch-ও node.

মহল্লার বাড়িগুলো

🔗 Link (সংযোগের পথ)

দুটি node-কে যে পথ জোড়ে, সেটি link. তামার তার, আলোর তার (fiber), বা বেতার — Wi-Fi আর মোবাইল টাওয়ারের রেডিও তরঙ্গ।

বাড়িগুলোর মাঝের গলি

📜 Protocol (নিয়ম)

কে কখন কথা বলবে, বার্তা দেখতে কেমন হবে, ভুল হলে কী হবে — এই চুক্তিই protocol. নিয়ম না মিললে তার থাকলেও কথা হয় না।

ঠিকানা লেখার নিয়ম

একটি মহল্লার কথা ভাবুন। বাড়িগুলো হলো node, বাড়ির মাঝের গলি হলো link. কিন্তু শুধু গলি থাকলেই চিঠি পৌঁছায় না। প্রতিটি বাড়ির একটি নম্বর লাগে, খামের ওপর ঠিকানা লেখার একটি নিয়ম লাগে, আর ডাকপিয়নকে জানতে হয় কোন গলি দিয়ে কোন বাড়িতে যেতে হয়। নেটওয়ার্কেও তাই: যন্ত্রের ঠিকানা লাগে (IP address), আর পথ খুঁজে দেওয়ার কাজ করে router.

মানুষ নেটওয়ার্ক বানায় কেন

প্রথম কম্পিউটারগুলো ছিল একা একা দাঁড়ানো বিশাল যন্ত্র। নেটওয়ার্ক বানানোর পেছনে মূলত তিনটি কারণ ছিল, আজও তা-ই আছে:

  • ভাগাভাগি (sharing): একটি অফিসে বিশজনের জন্য বিশটি প্রিন্টার কেনার দরকার নেই, একটি প্রিন্টার নেটওয়ার্কে রাখলেই চলে। একইভাবে একটি ইন্টারনেট সংযোগ, একটি ফাইল সার্ভার, একটি ডেটাবেস — সবাই মিলে ব্যবহার করা যায়। ১৯৬০-এর দশকে দামি কম্পিউটারের সময় ভাগ করে নেওয়াই ছিল নেটওয়ার্কের প্রথম বড় প্রেরণা।
  • যোগাযোগ (communication): ইমেইল, মেসেজ, ভিডিও কল, অনলাইন ক্লাস — মানুষে মানুষে কথা বলা। আজ এটিই নেটওয়ার্কের সবচেয়ে চোখে পড়া ব্যবহার।
  • মাপ বাড়ানো (scale): একটি কম্পিউটার যত শক্তিশালীই হোক, কোটি মানুষকে একসাথে সেবা দিতে পারে না। নেটওয়ার্কে হাজার হাজার সার্ভার একসাথে একটি সেবা চালায় — একটি নষ্ট হলে অন্যটি কাজ ধরে। সার্চ ইঞ্জিন, ক্লাউড, AI মডেলের প্রশিক্ষণ — সবই এই পথে চলে।
মূল ধারণা

নেটওয়ার্কের আসল জিনিস তার নয়, চুক্তি। একই তারে দুটি যন্ত্র যুক্ত থাকলেও, তারা যদি একই protocol না মানে, কোনো তথ্য আদান-প্রদান হবে না। এজন্যই এই কোর্সের বড় অংশ জুড়ে আমরা protocol পড়ব — কেমন করে লেখা হয়, কেন এভাবে নকশা করা, আর কোথায় ভাঙতে পারে।

২ · ইন্টারনেট — নেটওয়ার্কের নেটওয়ার্ক

অনেকে ভাবেন ইন্টারনেট একটি বিশাল যন্ত্র বা একটি কোম্পানির মালিকানাধীন একটি নেটওয়ার্ক। আসলে তা নয়। আপনার বাসার Wi-Fi একটি ছোট নেটওয়ার্ক। আপনার ISP-এর (Internet Service Provider — যে প্রতিষ্ঠান আপনাকে ইন্টারনেট সংযোগ দেয়) নিজস্ব নেটওয়ার্ক আছে। মোবাইল অপারেটরের আছে, বিশ্ববিদ্যালয়ের আছে, ব্যাংকের আছে, বিদেশের বড় ক্লাউড কোম্পানিরও আছে। এরা পরস্পরের সাথে চুক্তি করে যুক্ত হয়েছে। এই যুক্ত হওয়া সব নেটওয়ার্কের সমষ্টিই ইন্টারনেট — a network of networks.

গঠনটি বোঝার সবচেয়ে সহজ উপায় হলো তিনটি স্তরে ভাগ করে দেখা:

ইন্টারনেটের তিন অংশ

Network edge, access networks and the network core

  1. কিনারা (edge)host / end systemফোন, ল্যাপটপ, সার্ভার
  2. Access networkWi-Fi · 4G · fiberপ্রথম ধাপের সংযোগ
  3. Corerouter · ISP · IXPpacket এগিয়ে দেওয়া
ছবি ১.১ — কিনারার যন্ত্র access network দিয়ে core-এ ঢোকে; core বহু ISP-র router নিয়ে গঠিত।
  • কিনারা — host বা end system: যে যন্ত্রগুলো আসলে অ্যাপ চালায় — আপনার ফোন, ল্যাপটপ, স্মার্ট টিভি, আর অন্য প্রান্তের ওয়েব সার্ভার। এদের বলে host বা end system, কারণ তথ্যের যাত্রা এখানেই শুরু হয়, এখানেই শেষ হয়। যে host সেবা চায় সে client, যে সেবা দেয় সে server.
  • Access network — প্রথম ধাপের সংযোগ: host-কে প্রথম router-এর সাথে জোড়ে যে নেটওয়ার্ক, সেটিই access network. বাসায় Wi-Fi রাউটার, তার পেছনে ISP-র fiber বা তারের লাইন (যাকে আমরা “ব্রডব্যান্ড” বলি); রাস্তায় মোবাইল ডেটা — ফোন থেকে কাছের মোবাইল টাওয়ার; অফিসে Ethernet তার আর switch.
  • Core — মাঝখানের জাল: হাজার হাজার router, যারা একে অপরের সাথে উচ্চগতির link দিয়ে যুক্ত। এদের কাজ একটিই — আসা packet (তথ্যের ছোট টুকরো) দেখে ঠিক করা কোন দিকে পাঠাতে হবে। Core-এর মালিক বহু ISP; স্থানীয় ISP-রা বড় ISP-দের কাছ থেকে বাইরের সংযোগ কেনে, আর এক জায়গায় মিলিত হয়ে নিজেদের মধ্যে সরাসরি ট্রাফিক বদল করে — সেই মিলনস্থলের নাম IXP (Internet Exchange Point).

এবার পুরো পথটা গল্পের মতো দেখি। ধরুন আপনি বাসার Wi-Fi-তে বসে ফোনে abcltech.com খুললেন। নিচের ডায়াগ্রামে “পরে” চাপুন — প্রতিটি ধাপে কে কী দেখে, খেয়াল করুন। (ঠিকানাগুলো উদাহরণের জন্য বানানো; বিস্তারিত পরের পর্বগুলোতে।)

  1. আপনার ফোন192.168.0.105host · client
  2. বাসার রাউটারWi-Fiaccess network
  3. আপনার ISPfiber · routerDNS resolver এখানে
  4. IXP / upstreamBDIX · কেবলঅন্য নেটওয়ার্কে হস্তান্তর
  5. ওয়েব সার্ভার198.51.100.20host · server
ফোনের ভেতরেbrowser একটি request বানায়
চাই   : https://abcltech.com/
জানা  : নিজের ঠিকানা 192.168.0.105
অজানা : abcltech.com-এর IP ঠিকানা কত?
বাসার রাউটারঘরের নেটওয়ার্কের দরজা
ভেতরের ঠিকানা : 192.168.0.105 (private)
বাইরের ঠিকানা : 203.0.113.7 (ISP-র দেওয়া)
কাজ           : packet বাইরে পাঠানো, কে পাঠাল মনে রাখা
ISPপ্রথম বড় নেটওয়ার্ক
DNS resolver : abcltech.com → 198.51.100.20
router       : "198.51.100.20 কোন দিকে?"
সিদ্ধান্ত     : দেশের ভেতরে? → IXP · বাইরে? → upstream
IXP / upstreamএক নেটওয়ার্ক থেকে আরেক নেটওয়ার্কে
দেশের ভেতরের সার্ভার : IXP-তে সরাসরি অন্য ISP-কে
দেশের বাইরের সার্ভার : upstream → সাবমেরিন বা স্থল কেবল
প্রতিটি router         : শুধু পরের ধাপ ঠিক করে
ওয়েব সার্ভারঅন্য প্রান্তের host
পেল    : GET / (Host: abcltech.com)
বানাল  : HTML পাতা
উত্তর  : 200 OK + পাতা → 203.0.113.7-এর দিকে
ফেরার পথউত্তরও packet, উল্টো দিকে
সার্ভার → upstream/IXP → ISP → 203.0.113.7
রাউটার  : "এটা 192.168.0.105-এর" → Wi-Fi
যাওয়ার আর ফেরার পথ একই হবেই, এমন নয়
ফোনের স্ক্রিনbrowser পাতা আঁকে
HTML পড়ল → CSS, ছবি, script লাগবে
প্রতিটির জন্য আবার request (একই সংযোগে)
পুরো যাওয়া-আসা : এক সেকেন্ডেরও কম
  1. ধাপ ১ — ফোন request বানায়। আপনি ঠিকানা লিখে Enter চাপলেন। Browser জানে কী চাই, নিজের ঠিকানাও জানে, কিন্তু abcltech.com নামের যন্ত্রটির সংখ্যার ঠিকানা জানে না। নেটওয়ার্ক চলে সংখ্যার ঠিকানায়, নামে নয় — তাই প্রথম কাজ নাম থেকে ঠিকানা খোঁজা।
  2. ধাপ ২ — Wi-Fi রাউটার, ঘরের দরজা। ফোনের packet রেডিও তরঙ্গে বাসার রাউটারে গেল — এটুকুই access network. বাসার ভেতরের ঠিকানাগুলো private, বাইরে অচল; তাই রাউটার packet-এর গায়ে নিজের বাইরের ঠিকানা বসিয়ে দেয় আর মনে রাখে কে পাঠিয়েছিল। এই কৌশলের নাম NAT, বিস্তারিত পর্ব ১৯-এ।
  3. ধাপ ৩ — ISP: নাম থেকে ঠিকানা, তারপর দিক ঠিক করা। ISP-র DNS resolver (নাম থেকে ঠিকানা বের করার সেবা) জানিয়ে দিল abcltech.com = 198.51.100.20. এবার ISP-র router প্রতিটি packet-এর গন্তব্য দেখে ঠিক করে কোন link দিয়ে পাঠাবে — মোড়ের ট্রাফিক পুলিশের মতো, যিনি শুধু বলেন “বাঁয়ে যান”, পুরো রাস্তা নয়।
  4. ধাপ ৪ — IXP বা upstream: অন্যের নেটওয়ার্কে হস্তান্তর। সার্ভার যদি দেশের ভেতরে অন্য ISP-তে থাকে, packet দেশের IXP-তে (যেমন BDIX) সরাসরি সেই ISP-কে দেওয়া যায় — পথ ছোট, খরচ কম। সার্ভার বিদেশে হলে ISP তার upstream-এর মাধ্যমে সমুদ্রের তলার বা স্থলপথের কেবল দিয়ে বাইরে পাঠায়। কে কাকে ট্রাফিক দেবে, সেই চুক্তি চলে BGP দিয়ে — পর্ব ২৫।
  5. ধাপ ৫ — সার্ভার উত্তর বানায়। অনেকগুলো router পেরিয়ে packet পৌঁছাল অন্য প্রান্তের host-এ। সার্ভারের প্রোগ্রাম request পড়ে HTML পাতা বানাল এবং উত্তর দিল 200 OK — অর্থাৎ “পাওয়া গেছে, এই নিন।” উত্তরের গন্তব্য বাসার রাউটারের বাইরের ঠিকানা 203.0.113.7.
  6. ধাপ ৬ — ফেরার পথ। উত্তরও ছোট ছোট packet হয়ে উল্টো দিকে আসে। Core-এর প্রতিটি router আবার নিজে নিজে দিক ঠিক করে, তাই ফেরার পথ যাওয়ার পথের মতো হবেই এমন নয়। বাসার রাউটার নিজের মনে রাখা তালিকা দেখে বোঝে উত্তরটি 192.168.0.105-এর, আর Wi-Fi দিয়ে ফোনে পাঠায়।
  7. ধাপ ৭ — পাতা আঁকা। Browser HTML পড়ে দেখে আরও CSS, ছবি আর script লাগবে — প্রতিটির জন্য আবার request যায়, সাধারণত একই সংযোগে। পুরো যাওয়া-আসা সাধারণত এক সেকেন্ডেরও কম সময়ে শেষ হয়, অথচ এর মধ্যে কয়েকটি আলাদা মালিকের নেটওয়ার্ক মিলে কাজ করেছে। এটাই “নেটওয়ার্কের নেটওয়ার্ক”।

মোবাইল ডেটায় পথটা একটু আলাদা। বাসার Wi-Fi রাউটারের জায়গায় থাকে কাছের মোবাইল টাওয়ার (base station), আর তার পেছনে মোবাইল অপারেটরের নিজস্ব core নেটওয়ার্ক। আপনি হাঁটতে হাঁটতে এক টাওয়ার থেকে আরেক টাওয়ারে চলে গেলেও সংযোগ ধরে রাখার কৌশল (handover) পর্ব ৫১-এ দেখবেন। কিন্তু অপারেটরের নেটওয়ার্ক থেকে বেরিয়ে যাওয়ার পর বাকি পথ একই ইন্টারনেট।

৩ · একটি ওয়েবসাইট খুললে কী ঘটে — DNS → TCP → HTTP

আগের ডায়াগ্রামে আমরা দেখেছি packet কোন পথে যায়। এবার দেখি কী কথা হয়। একটি ওয়েবসাইট খোলার পেছনে সাধারণত তিনটি protocol পরপর কাজ করে (HTTPS হলে মাঝে আরেকটি):

ধাপProtocolপ্রশ্নটা কীবিস্তারিত
১DNS“abcltech.com-এর ঠিকানা কী?”পর্ব ৩৫
২TCP“আপনার সাথে একটি নির্ভরযোগ্য সংযোগ খুলতে পারি?”পর্ব ২৯–৩২
৩TLS“আমরা কি একটি গোপন চাবিতে একমত হতে পারি?”পর্ব ৪৮
৪HTTP“দয়া করে / পাতাটি দিন।”পর্ব ৩৬–৩৭

এই ধাপগুলোর প্রতিটিতে অন্তত একবার করে প্রশ্ন যায় আর উত্তর আসে। একবার যাওয়া-আসার সময়কে বলে round-trip time (RTT). নেটওয়ার্কে একটি বড় সত্য হলো — অনেক সময় পাতা দেরিতে খোলে ডেটার পরিমাণের জন্য নয়, round trip-এর সংখ্যার জন্য। নিচের ছোট সিমুলেটরে একটি কাল্পনিক হিসাব দেখুন। সংখ্যাগুলো উদাহরণ মাত্র — মাপা নয়; আসল মান আপনার সংযোগ, দূরত্ব আর সার্ভারের ওপর নির্ভর করে।

// Journey of a web request: an ILLUSTRATIVE time budget, not a measurement.
// Assumed: RTT phone<->server 40 ms, phone<->DNS resolver 10 ms.
const RTT = 40, RTT_DNS = 10, DNS_MISS = 30, SERVER_MS = 20;
const PAGE_KB = 200, MBPS = 20;          // page size and link speed

function journey(title, dnsCached, connReused) {
  const steps = [];
  if (dnsCached) steps.push(["DNS   : answer from the phone's cache", 0]);
  else steps.push(["DNS   : ask resolver, resolver asks others", RTT_DNS + DNS_MISS]);
  if (!connReused) {
    steps.push(["TCP   : 3-way handshake (SYN, SYN-ACK, ACK)", RTT]);
    steps.push(["TLS   : agree on keys (TLS 1.3, 1 round trip)", RTT]);
  }
  steps.push(["HTTP  : GET / -> server builds the page", RTT + SERVER_MS]);
  steps.push([`DATA  : ${PAGE_KB} KB at ${MBPS} Mbps`, PAGE_KB * 8 / MBPS]);

  console.log(`== ${title} ==`);
  let t = 0;
  for (const [what, ms] of steps) {
    t += ms;
    console.log(`${what.padEnd(48)} +${String(ms).padStart(3)} ms   t = ${String(t).padStart(3)} ms`);
  }
  console.log("");
  return t;
}

const first = journey("First visit: nothing cached", false, false);
const again = journey("Next click: DNS cached, connection reused", true, true);
console.log(`Total: ${first} ms vs ${again} ms (skipped: DNS, TCP, TLS)`);

আসল রানের আউটপুট:

== First visit: nothing cached ==
DNS   : ask resolver, resolver asks others       + 40 ms   t =  40 ms
TCP   : 3-way handshake (SYN, SYN-ACK, ACK)      + 40 ms   t =  80 ms
TLS   : agree on keys (TLS 1.3, 1 round trip)    + 40 ms   t = 120 ms
HTTP  : GET / -> server builds the page          + 60 ms   t = 180 ms
DATA  : 200 KB at 20 Mbps                        + 80 ms   t = 260 ms

== Next click: DNS cached, connection reused ==
DNS   : answer from the phone's cache            +  0 ms   t =   0 ms
HTTP  : GET / -> server builds the page          + 60 ms   t =  60 ms
DATA  : 200 KB at 20 Mbps                        + 80 ms   t = 140 ms

Total: 260 ms vs 140 ms (skipped: DNS, TCP, TLS)

প্রথমবারে DNS খুঁজতে ৪০ ms (resolver পর্যন্ত ১০ ms, resolver-কে অন্যদের জিজ্ঞেস করতে আরও ৩০ ms), তারপর TCP-র তিন বার্তার handshake আর TLS-এর চাবি ঠিক করা — প্রতিটিতে একটি পুরো RTT, অর্থাৎ ৪০ ms. HTTP request-এ আরেকটি RTT আর সার্ভারের ২০ ms কাজ, মোট ৬০ ms. শেষ লাইনে ২০০ KB = ১,৬০০ kilobit; ২০ Mbps গতিতে প্রতি millisecond-এ ২০ kilobit যায়, তাই ১,৬০০ ÷ ২০ = ৮০ ms. মোট ২৬০ ms-এর মধ্যে ১৮০ ms খরচ হয়েছে শুধু প্রশ্ন-উত্তরের অপেক্ষায়।

দ্বিতীয় ক্লিকে ফোনের cache-এ ঠিকানা আছে আর আগের সংযোগটিই আবার ব্যবহার হচ্ছে, তাই তিনটি ধাপ বাদ — সময় নামল ১৪০ ms-এ, অথচ ডেটা একই। এজন্যই browser সংযোগ খোলা রাখে, DNS উত্তর মনে রাখে, আর CDN সার্ভারকে ব্যবহারকারীর কাছে নিয়ে আসে (পর্ব ৩৮)। সতর্কতা: এখানে ডেটা পাঠানোর হিসাবটি খুব সরল; বাস্তবে TCP শুরুতে ধীরে গতি বাড়ায় (slow start, পর্ব ৩২), আর delay-এর পুরো হিসাব পর্ব ৫-এ।

৪ · Protocol — সবাই মিলে মানা নিয়ম

“Protocol” শব্দটি এসেছে কূটনীতি থেকে — রাষ্ট্রপ্রধানের সফরে কে আগে হাত মেলাবেন, কে কোথায় বসবেন, এসবের লিখিত নিয়ম। নেটওয়ার্কে protocol মানে দুই বা ততোধিক পক্ষের মধ্যে চুক্তি, যা তিনটি জিনিস ঠিক করে দেয়:

  • বার্তার গঠন (syntax): কোন অংশ কত বাইট, কোথায় ঠিকানা, কোথায় আসল তথ্য।
  • বার্তার অর্থ (semantics): এই সংখ্যা বা শব্দের মানে কী, পেলে কী করতে হবে।
  • সময় আর ক্রম (timing): কে আগে বলবে, উত্তর না এলে কতক্ষণ অপেক্ষা, তারপর কী।

মানুষের একটি ফোনকলের কথা ভাবুন। আপনি “হ্যালো” বলেন, অন্যপ্রান্ত “হ্যালো, বলুন” বলে — তারপরই আসল কথা। কথা শেষে “আচ্ছা, রাখি” — “আচ্ছা।” কেউ যদি ফোন ধরেই চুপ থাকে, আপনি কয়েক সেকেন্ড অপেক্ষা করে আবার “হ্যালো?” বলেন। এই অলিখিত নিয়মগুলোই মানুষের protocol. কম্পিউটারের পার্থক্য হলো — তারা অনুমান করতে পারে না, তাই প্রতিটি নিয়ম লিখে রাখতে হয়, একেবারে নিখুঁতভাবে।

নিচের ডায়াগ্রামে একটি সাধারণ protocol আলাপের চার অংশ দেখুন — শুভেচ্ছা, অনুরোধ, উত্তর, বিদায় — বাঁ পাশে বার্তার ক্রম, ডান পাশে ফোনকলের সাথে মিল:

1C → S : SYN            ; "hello?"2C ← S : SYN-ACK        ; "hello, go on"3C → S : ACK            ; "ok, talking"4C → S : GET / HTTP/1.1 ; Host: abcltech.com5C ← S : HTTP/1.1 200 OK + page6C → S : FIN            ; "bye"7C ← S : FIN, ACK       ; "bye"8C → S : "GIVE PAGE"    ; not HTTP
C = client (ফোন), S = server
পর্ব
ফোনকলে
সংযোগ
S-এর অবস্থা
  1. শুভেচ্ছা ১ — “হ্যালো?” Client প্রথমে TCP-র একটি SYN বার্তা পাঠায়: “আমি কথা বলতে চাই।” এখনো কোনো আসল তথ্য যায়নি। ঠিক যেমন ফোন ধরেই কেউ দাম জিজ্ঞেস করে না — আগে নিশ্চিত হয় অন্যপ্রান্তে কেউ আছে।
  2. শুভেচ্ছা ২ — “হ্যালো, বলুন।” Server রাজি থাকলে SYN-ACK ফেরত দেয়: “আপনার বার্তা পেয়েছি, আমিও প্রস্তুত।” সার্ভার বন্ধ থাকলে বা ওই নম্বরে (port) কেউ না শুনলে এখানেই প্রত্যাখ্যান আসত।
  3. শুভেচ্ছা ৩ — “জি, শুনছি।” Client-এর ACK-এ তিন বার্তার handshake শেষ, সংযোগ খোলা। তিনটি কেন, দুটি নয় কেন, আর প্রতিটি বার্তায় কোন সংখ্যা থাকে — পর্ব ২৯-এর বিষয়।
  4. অনুরোধ। এবার আসল কথা: GET / HTTP/1.1 আর Host: abcltech.com. এটি HTTP-র ভাষা — প্রথম শব্দটি কাজ (GET = দিন), তারপর কোন জিনিস (/ = মূল পাতা), তারপর protocol-এর version. গঠন হুবহু নিয়মমাফিক হতে হবে।
  5. উত্তর। Server বলে 200 OK — একটি সংখ্যা, যার অর্থ সবাই আগে থেকে জানে: ২০০ মানে সফল, ৪০৪ মানে পাওয়া যায়নি। সাথে আসে পাতার ধরন (text/html) আর পাতা নিজে। এটাই semantics — সংখ্যার মানে চুক্তিতে লেখা।
  6. বিদায় ১ — “আচ্ছা, রাখি।” কাজ শেষে একপক্ষ FIN পাঠায়: “আমার আর কিছু বলার নেই।” হঠাৎ ফোন কেটে দেওয়ার চেয়ে এভাবে বিদায় নেওয়া ভালো — অন্যপক্ষ জানে সব তথ্য এসে গেছে, আর কিছু হারায়নি।
  7. বিদায় ২ — “আচ্ছা।” অন্যপক্ষও FIN আর ACK দিয়ে সম্মতি জানায়, সংযোগ বন্ধ। (বাস্তবে বন্ধ করার ধাপ সাধারণত চারটি বার্তায় হয়, এখানে সংক্ষেপে দুটি দেখানো হলো — পর্ব ২৯।)
  8. নিয়মভঙ্গ হলে? ধরুন অন্য একটি সংযোগে client নিজের বানানো ভাষায় লিখল GIVE PAGE. সংযোগ খোলা, তার ঠিক আছে, তবু server বুঝল না — উত্তর 400 Bad Request. শিক্ষা: link থাকলেই যোগাযোগ হয় না; দুই পক্ষকে একই protocol মানতে হয়।

চিঠি, খাম আর ডাকঘর — packet কেন

নেটওয়ার্কে বড় তথ্য একবারে পাঠানো হয় না, ছোট ছোট packet-এ ভাগ করে পাঠানো হয়। প্রতিটি packet-এর গায়ে থাকে একটি header — খামের ওপরের ঠিকানার মতো। ডাকঘরের উপমায় পুরো ব্যাপারটা দেখুন:

ডাকঘর বনাম নেটওয়ার্ক — একই চিন্তা
ডাকঘরে
নেটওয়ার্কে
পথে আছে
পৌঁছেছে
  1. তথ্য তৈরি। আপনি একটি তিন পাতার চিঠি লিখলেন — নেটওয়ার্কে এটি অ্যাপের তৈরি ৩,০০০ বাইট তথ্য, যেমন একটি ছবির অংশ বা একটি মেসেজ।
  2. টুকরো করা। ডাকঘর একটি খামে কতটা ভারী জিনিস নেবে, তার সীমা আছে। নেটওয়ার্কেও একটি link একবারে কত বড় টুকরো নেবে তার সীমা আছে (Ethernet-এ সাধারণত ১,৫০০ বাইট)। তাই তথ্য তিনটি packet-এ ভাগ হলো। সংখ্যাগুলো বোঝার সুবিধার জন্য গোল করা।
  3. খামে ঠিকানা = header. প্রতিটি খামে প্রেরক আর প্রাপকের ঠিকানা, সাথে পাতা নম্বর। নেটওয়ার্কে এগুলোই header-এর ঘর: উৎস ঠিকানা (src), গন্তব্য ঠিকানা (dst), আর ক্রমিক নম্বর (seq). ভেতরের চিঠি ডাকপিয়ন পড়ে না, router-ও সাধারণত ভেতরের তথ্য দেখে না।
  4. Router = ডাকঘরের বাছাইকারী। স্থানীয় ডাকঘর পুরো ঠিকানা মুখস্থ রাখে না — শুধু জেলা দেখে ঠিক বস্তায় ফেলে। Router-ও শুধু গন্তব্য দেখে পরের link বেছে নেয়; পুরো পথ কেউ আগে থেকে ঠিক করে দেয় না। এভাবে প্রতিটি packet আলাদাভাবে এগোয় — একে বলে packet switching, পর্ব ৪-এ বিস্তারিত।
  5. ভিন্ন পথ, ভিন্ন সময়। খাম ২ অন্য ডাকগাড়িতে উঠেছে, জ্যামে পড়ে দেরি। নেটওয়ার্কে packet 2 অন্য পথে গেছে বা কোনো router-এর লাইনে অপেক্ষা করেছে। প্রাপকের কাছে এখন আছে শুধু ১ আর ৩ — ক্রম এলোমেলো।
  6. ক্রম মেলানো। প্রাপক পাতা নম্বর দেখে চিঠি সাজালেন। নেটওয়ার্কে এই কাজ করে প্রাপকের যন্ত্রের TCP — seq নম্বর দেখে ১, ২, ৩ ক্রমে সাজিয়ে তবেই অ্যাপকে দেয়। কোনো packet একেবারে হারালে প্রেরক আবার পাঠায় (পর্ব ৩০)।
  7. প্রাপ্তি স্বীকার। রেজিস্ট্রি চিঠির প্রাপ্তিস্বীকার কার্ডের মতো, প্রাপক ACK পাঠিয়ে জানায় “পেয়েছি”। ডাকঘরের সাথে একটি বড় পার্থক্য: নেটওয়ার্ক এই পুরো কাজ করে এক সেকেন্ডের ক্ষুদ্র ভগ্নাংশে, প্রতি সেকেন্ডে লাখো packet-এর জন্য।
মূল ধারণা

Packet-এ ভাগ করার তিনটি বড় সুবিধা: একটি link অনেক মানুষ একসাথে ভাগ করে নিতে পারে (প্রত্যেকের packet পালা করে যায়); একটি packet হারালে শুধু সেটিই আবার পাঠাতে হয়, পুরো ফাইল নয়; আর কোনো router নষ্ট হলে পরের packet অন্য পথ ধরতে পারে। দাম হলো — packet দেরিতে বা এলোমেলো ক্রমে আসতে পারে, তাই প্রাপককে সাজাতে হয়।

৫ · নিয়মগুলো কারা লেখে — IETF, RFC, IEEE 802, ITU, W3C

আপনার ফোন বানিয়েছে এক কোম্পানি, বাসার রাউটার আরেক কোম্পানি, ISP-র যন্ত্র তৃতীয় কোম্পানি, আর সার্ভারের সফটওয়্যার আরেক দল লিখেছে। তবু সবাই একে অপরকে বোঝে, কারণ সবাই একই লিখিত standard মানে। কয়েকটি প্রধান প্রতিষ্ঠান এই কাজ করে, প্রত্যেকের নিজস্ব এলাকা:

প্রতিষ্ঠানকী লেখেউদাহরণ
IETF (Internet Engineering Task Force)ইন্টারনেটের মূল protocol — IP, TCP, UDP, DNS, HTTP, TLS. দলিলের নাম RFCRFC 791 (IPv4), RFC 9293 (TCP), RFC 9110 (HTTP-র অর্থ)
IEEE 802 কমিটিস্থানীয় নেটওয়ার্কের তার আর বেতারের নিয়ম802.3 = Ethernet, 802.11 = Wi-Fi
ITU (International Telecommunication Union)জাতিসংঘের টেলিযোগাযোগ সংস্থা — রেডিও তরঙ্গের বণ্টন, টেলিফোন আর ট্রান্সমিশনের সুপারিশITU-T আর ITU-R-এর “Recommendation”; মোবাইলের প্রজন্মের শর্ত
3GPPমোবাইল নেটওয়ার্কের বিস্তারিত নির্দেশিকা4G LTE, 5G NR
W3C (World Wide Web Consortium)ওয়েবের প্রযুক্তি — CSS, accessibility-র নির্দেশিকা ইত্যাদিWCAG; (HTML-এর চলমান standard এখন WHATWG রাখে)
IANA / ICANN আর আঞ্চলিক রেজিস্ট্রিনম্বর আর নামের হিসাব — IP ঠিকানার ব্লক, port নম্বর, domain-এর শীর্ষ স্তরবাংলাদেশ পড়েছে APNIC অঞ্চলে

RFC মানে “Request for Comments” — নামটি বিনয়ী, কারণ ১৯৬৯ সালে ARPANET-এর তরুণ গবেষকেরা চাননি তাঁদের নোট কর্তৃত্বপূর্ণ আদেশের মতো শোনাক। প্রথম RFC লেখেন Steve Crocker, ১৯৬৯ সালের এপ্রিলে। আজ কয়েক হাজার RFC আছে, সবই বিনামূল্যে পড়া যায়। সব RFC কিন্তু standard নয় — কিছু তথ্যমূলক, কিছু পরীক্ষামূলক, আর প্রতি বছর ১ এপ্রিল কয়েকটি মজার RFC-ও বের হয় (যেমন RFC 1149, কবুতর দিয়ে IP packet পাঠানো!)। একটি RFC একবার প্রকাশ হলে আর বদলায় না; সংশোধন লাগলে নতুন নম্বরে নতুন RFC আসে, আর পুরোনোটি “obsoleted” হয় — যেমন ১৯৮১ সালের TCP-র RFC 793-কে ২০২২ সালে প্রতিস্থাপন করেছে RFC 9293.

AI বা ইন্টারনেটের লেখায় প্রায়ই ভুল RFC নম্বর দেখা যায় — কখনো একেবারে বানানো নম্বর। কোনো দাবি যাচাই করতে rfc-editor.org-এ নম্বরটি খুলুন, শিরোনাম মিলিয়ে দেখুন, আর দেখুন সেটি পরে অন্য RFC দিয়ে প্রতিস্থাপিত হয়েছে কি না।

৬ · নিজের যন্ত্রে নেটওয়ার্ক দেখা — interface, loopback আর localhost

এতক্ষণ ছিল গল্প। এবার একটি আসল Linux পরিবেশে নেটওয়ার্ক কেমন দেখায়, চোখে দেখি। নিচের কোডগুলো চলে একটি অনলাইন compiler-এর container-এ (একটি আলাদা করা ছোট Linux পরিবেশ, যেখান থেকে বাইরের ইন্টারনেটে যোগাযোগ করা আমাদের উদ্দেশ্য নয়, আর অনুমতিও সীমিত)। তাই এখানে আমরা শুধু যন্ত্রের নিজের দিকটা দেখব — যা নিরাপদ, আর যা কারও ক্ষতি করে না।

প্রতিটি যন্ত্রে নেটওয়ার্কের সাথে যুক্ত হওয়ার এক বা একাধিক “দরজা” থাকে — একে বলে network interface. ল্যাপটপে সাধারণত একটি Wi-Fi interface, একটি Ethernet interface, আর একটি বিশেষ interface থাকে যার নাম loopback (lo). Linux সব interface-এর তালিকা রাখে /sys/class/net-এ, আর প্রতিটির গোনা বাইট আর packet রাখে /proc/net/dev ফাইলে:

echo "== interfaces: ls /sys/class/net =="
ls /sys/class/net
echo "== loopback lo =="
echo "state=$(cat /sys/class/net/lo/operstate) mtu=$(cat /sys/class/net/lo/mtu)"
echo "== counters: /proc/net/dev =="
cat /proc/net/dev
echo "== name table: /etc/hosts (standard lines) =="
grep -E '^(127\.0\.0\.1|::1|ff02::)' /etc/hosts
echo "== ip -br addr =="
command -v ip >/dev/null && ip -br addr || echo "ip: not installed here"

আসল রানের আউটপুট:

== interfaces: ls /sys/class/net ==
lo
tap0
== loopback lo ==
state=unknown mtu=65536
== counters: /proc/net/dev ==
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  tap0:     110       1    0    0    0     0          0         0      250       3   0    0    0     0       0          0
== name table: /etc/hosts (standard lines) ==
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
== ip -br addr ==
lo               UNKNOWN        127.0.0.1/8 ::1/128
tap0             UNKNOWN        10.0.2.100/24 fd00::d4cc:38ff:fe73:4b4/64 fe80::d4cc:38ff:fe73:4b4/64

এই container-এ দুটি interface: lo (loopback) আর tap0 — একটি virtual interface, যা container-কে তার host মেশিনের সাথে জোড়ে; সাধারণ ল্যাপটপে এর জায়গায় থাকত wlan0 বা eth0-এর মতো আসল Wi-Fi বা Ethernet. Loopback-এর state=unknown অস্বাভাবিক নয়: এর পেছনে কোনো তার নেই, তাই “তার লাগানো আছে কি না” প্রশ্নের উত্তরও নেই; আর mtu=65536 মানে এক টুকরোয় ৬৪ KiB পর্যন্ত — আসল Ethernet-এর সাধারণ ১,৫০০ বাইটের চেয়ে অনেক বড়, কারণ কোনো তার পেরোতে হয় না। /proc/net/dev-এ প্রতিটি interface-এর গ্রহণ (Receive) আর প্রেরণের (Transmit) বাইট ও packet গোনা থাকে: এই রানে tap0 ১১০ বাইটে ১টি packet পেয়েছে, ২৫০ বাইটে ৩টি পাঠিয়েছে (container চালু করার সময়ের সামান্য আদান-প্রদান; প্রতিবার সংখ্যাগুলো একটু আলাদা হতে পারে), আর lo-তে এখনো শূন্য — এই container-এ কেউ নিজের সাথে কথা বলেনি। /etc/hosts হলো DNS-এর আগের যুগের সরল নাম-তালিকা, যা আজও সবার আগে দেখা হয়: এখানেই লেখা localhost = 127.0.0.1 আর ::1. grep দিয়ে শুধু সব Linux-এ থাকা সাধারণ লাইনগুলো দেখানো হয়েছে; আসল ফাইলে যন্ত্রের নিজের নাম আর container ব্যবস্থার যোগ করা কিছু লাইনও থাকে, যা প্রতিবার বদলায়। শেষে ip -br addr সংক্ষেপে ঠিকানা দেখাল: lo-তে 127.0.0.1/8 আর ::1/128; tap0-তে private ঠিকানা 10.0.2.100/24, সাথে দুটি IPv6 ঠিকানা (fe80:: দিয়ে শুরু হওয়াটি link-local). এই /8, /24 চিহ্নের মানে পর্ব ১৬–১৭-এ, আর এই টুলগুলোর পূর্ণ ব্যবহার পর্ব ৬-এ। আপনার নিজের Linux মেশিনে একই স্ক্রিপ্ট চালালে interface-এর নাম, ঠিকানা আর সংখ্যা আলাদা হবে; Windows-এ এর কাছাকাছি কাজ করে PowerShell-এর Get-NetAdapter আর Get-NetIPAddress.

Loopback — নিজের সাথে নিজের কথা

Loopback এমন একটি interface, যার পেছনে কোনো তার বা রেডিও নেই। এতে পাঠানো packet বাইরে কোথাও যায় না — operating system-এর ভেতরেই ঘুরে নিজের কাছে ফিরে আসে। IPv4-এ পুরো 127.0.0.0/8 ব্লকটি এর জন্য রাখা, আর সবচেয়ে পরিচিত ঠিকানা 127.0.0.1; IPv6-এ loopback ঠিকানা একটিই — ::1. আর এই ঠিকানার নাম localhost.

অফিসের রিসেপশনে একটি অভ্যন্তরীণ ফোন লাইনের কথা ভাবুন: এক্সটেনশন ১০১ থেকে ১০২-এ ফোন করলে কল বাইরের টেলিফোন এক্সচেঞ্জে যায় না, অফিসের ভেতরেই ঘোরে। Loopback ঠিক তেমন — একই যন্ত্রের দুটি প্রোগ্রাম (যেমন আপনার ওয়েব সার্ভার আর browser) নেটওয়ার্কের পুরো নিয়ম মেনে কথা বলে, কিন্তু একটি packet-ও যন্ত্র ছেড়ে যায় না। ডেভেলপাররা এজন্যই নিজের কম্পিউটারে http://localhost:8000 খুলে কাজ পরীক্ষা করেন।

একটি প্রোগ্রাম কীভাবে “localhost” নাম থেকে ঠিকানা পায়? C-তে এর জন্য আছে getaddrinfo() — নাম থেকে ঠিকানার তালিকা বের করার standard ফাংশন। এটি /etc/hosts ফাইল, DNS আর সিস্টেমের নিয়ম মিলিয়ে উত্তর দেয়। নিচের প্রোগ্রাম যা পায়, তা-ই ছাপে:

#define _POSIX_C_SOURCE 200112L
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>

int main(void) {
    struct addrinfo hints, *res, *p;
    memset(&hints, 0, sizeof hints);
    hints.ai_family = AF_UNSPEC;        /* IPv4 or IPv6, whatever exists */
    hints.ai_socktype = SOCK_STREAM;    /* one answer per address (TCP) */

    int rc = getaddrinfo("localhost", "80", &hints, &res);
    if (rc != 0) { printf("getaddrinfo: %s\n", gai_strerror(rc)); return 1; }

    for (p = res; p != NULL; p = p->ai_next) {
        char ip[INET6_ADDRSTRLEN];
        const void *a;
        if (p->ai_family == AF_INET)
            a = &((struct sockaddr_in *)(void *)p->ai_addr)->sin_addr;
        else
            a = &((struct sockaddr_in6 *)(void *)p->ai_addr)->sin6_addr;
        inet_ntop(p->ai_family, a, ip, sizeof ip);
        printf("%-4s %s\n", p->ai_family == AF_INET ? "IPv4" : "IPv6", ip);
    }
    freeaddrinfo(res);
    return 0;
}

আসল রানের আউটপুট:

IPv6 ::1
IPv4 127.0.0.1

“localhost” নামের জন্য দুটি ঠিকানা এলো — IPv6-এর ::1 আর IPv4-এর 127.0.0.1, দুটোই loopback. AF_UNSPEC দিয়ে আমরা বলেছিলাম “যে ধরনের ঠিকানা আছে, সব দাও”, তাই দুটিই পেলাম; আর SOCK_STREAM বলায় প্রতিটি ঠিকানা একবার করেই এসেছে। ক্রমটি খেয়াল করুন: ::1 আগে। glibc ফলগুলো RFC 6724-এর ঠিকানা বাছাইয়ের নিয়মে সাজায় (Linux-এ /etc/gai.conf দিয়ে বদলানো যায়), আর সাধারণ নিয়মে IPv6 loopback আগে আসে। একটি ভালো client প্রোগ্রাম তাই তালিকার প্রথম ঠিকানায় সংযোগ চেষ্টা করে, না পারলে পরেরটিতে যায়। যে মেশিনে IPv6 বন্ধ বা /etc/hosts-এ ::1 লাইন নেই, সেখানে শুধু IPv4 127.0.0.1 আসতে পারে — তাই output অনুমান না করে চালিয়ে দেখাই নিয়ম। getaddrinfo এখানে বাইরের কোনো DNS সার্ভারে যায়নি; উত্তর এসেছে /etc/hosts থেকে। DNS আসলে কীভাবে উত্তর খোঁজে, তা পর্ব ৩৫-এ, আর এই ঠিকানায় সত্যিকারের TCP সংযোগ খোলা পর্ব ৪১-এ।

আরও গভীরে: Linux-এ loopback-এ পাঠানো packet network card-এর driver পর্যন্ত যায় না; kernel-এর loopback driver সেটিকে সরাসরি গ্রহণের সারিতে ফিরিয়ে দেয়, তাই এর গতি মূলত CPU আর মেমরির ওপর নির্ভর করে। “localhost” নামটি RFC 6761-এ বিশেষ নাম হিসেবে সংরক্ষিত, আর IPv6-এর ::1 এসেছে RFC 4291 থেকে। Container-এর ভেতরে যে আলাদা interface তালিকা দেখলেন, তা Linux-এর network namespace-এর ফল — প্রতিটি namespace নিজের interface, routing table আর loopback পায় (পর্ব ৫৪)।

৭ · সংক্ষিপ্ত ইতিহাস — ARPANET থেকে পকেটের ইন্টারনেট

১৯৬০-এর দশক — packet-এর চিন্তা। যুক্তরাষ্ট্রের RAND-এ Paul Baran আর যুক্তরাজ্যের NPL-এ Donald Davies আলাদাভাবে প্রস্তাব করেন: বার্তাকে ছোট ছোট টুকরো করে পাঠানো হোক, প্রতিটি টুকরো নিজে নিজে পথ খুঁজুক। “packet” শব্দটি Davies-এর দেওয়া।

১৯৬৯ — ARPANET. যুক্তরাষ্ট্রের প্রতিরক্ষা গবেষণা সংস্থা ARPA-র অর্থায়নে চারটি বিশ্ববিদ্যালয় ও গবেষণা প্রতিষ্ঠানের কম্পিউটার জুড়ে প্রথম বড় packet-switched নেটওয়ার্ক চালু হয়। ২৯ অক্টোবর ১৯৬৯ সালে UCLA থেকে SRI-তে প্রথম বার্তা যায় — “LOGIN” লিখতে গিয়ে মাত্র “LO” পৌঁছানোর পর সিস্টেম থেমে যায়।

১৯৭৪ থেকে ১৯৮৩ — TCP/IP. Vint Cerf আর Bob Kahn ১৯৭৪ সালে ভিন্ন ভিন্ন নেটওয়ার্ক জোড়ার একটি protocol-এর নকশা প্রকাশ করেন; সেটিই পরে TCP আর IP-তে ভাগ হয়। ১ জানুয়ারি ১৯৮৩ ARPANET পুরোনো NCP protocol ছেড়ে TCP/IP-তে চলে যায় — অনেকে এই দিনটিকেই আজকের ইন্টারনেটের জন্মদিন বলেন। একই বছর DNS-এর প্রথম নকশাও প্রকাশিত হয়।

১৯৮৯ থেকে ১৯৯১ — ওয়েব. CERN-এ কাজ করার সময় Tim Berners-Lee ১৯৮৯ সালে তথ্য ভাগাভাগির একটি ব্যবস্থার প্রস্তাব দেন; ১৯৯০ সালের শেষ দিকে প্রথম ওয়েব সার্ভার আর browser চালু হয়, আর ১৯৯১ সালে ওয়েব সবার জন্য খুলে দেওয়া হয়। HTML, URL আর HTTP — তিনটিই সেই সময়ের আবিষ্কার।

২০০০-এর দশক থেকে — মোবাইল ইন্টারনেট. 3G-র পর smartphone আর 4G ইন্টারনেটকে টেবিলের কম্পিউটার থেকে মানুষের পকেটে নিয়ে আসে। আজ বিশ্বের বহু মানুষের — বাংলাদেশেরও — প্রথম এবং প্রধান ইন্টারনেট যন্ত্র একটি মোবাইল ফোন।

একটি প্রচলিত ভুল ধারণা: “ARPANET বানানো হয়েছিল পারমাণবিক যুদ্ধে টিকে থাকার জন্য।” Baran-এর গবেষণার প্রেরণা সত্যিই ছিল যুদ্ধের মধ্যে টিকে থাকা যোগাযোগ ব্যবস্থা, কিন্তু ARPANET-এর প্রত্যক্ষ উদ্দেশ্য ছিল গবেষকদের মধ্যে দামি কম্পিউটার আর তথ্য ভাগাভাগি। পরীক্ষায় লিখলে এই পার্থক্যটি মনে রাখুন।

বাংলাদেশে ইন্টারনেট — সমুদ্রের তলা থেকে পকেট পর্যন্ত

বাংলাদেশের ইন্টারনেট বাইরের বিশ্বের সাথে যুক্ত হয় মূলত দুই পথে। প্রথমত, সাবমেরিন কেবল — সমুদ্রের তলা দিয়ে যাওয়া আলোর তার। ২০০০-এর দশকের মাঝামাঝি SEA-ME-WE 4 কেবলের মাধ্যমে কক্সবাজার হয়ে দেশ প্রথম সাবমেরিন কেবলে যুক্ত হয়; পরে কুয়াকাটায় SEA-ME-WE 5 যুক্ত হয়। এগুলোর ব্যবস্থাপনায় আছে রাষ্ট্রায়ত্ত প্রতিষ্ঠান। দ্বিতীয়ত, স্থলপথে প্রতিবেশী দেশের মধ্য দিয়ে আসা কেবল (ITC নামে পরিচিত লাইসেন্সধারীরা)। বাইরের ব্যান্ডউইথ দেশে প্রবেশ করে গেটওয়ে প্রতিষ্ঠানের (IIG) মাধ্যমে, তারপর ছড়িয়ে পড়ে ISP আর মোবাইল অপারেটরদের হাতে। নিয়ন্ত্রক সংস্থা BTRC. সংখ্যা আর লাইসেন্সের খুঁটিনাটি সময়ের সাথে বদলায়, তাই নির্দিষ্ট পরিসংখ্যান লাগলে BTRC-র সাম্প্রতিক প্রকাশনা দেখুন।

দেশের ভেতরের ট্রাফিকের জন্য আছে BDIX (Bangladesh Internet Exchange) — একটি IXP, যেখানে দেশের ISP-রা মিলিত হয়ে নিজেদের মধ্যে সরাসরি ট্রাফিক বদল করে। ফলে ঢাকার এক ISP-র গ্রাহক রাজশাহীর আরেক ISP-র সার্ভারে গেলে packet-কে বিদেশ ঘুরে আসতে হয় না। আপনি হয়তো দেখেছেন, কিছু ISP “BDIX স্পিড”-এ নির্দিষ্ট সার্ভার (যেমন দেশি FTP বা মিডিয়া সার্ভার) খুব দ্রুত দেখায় — এর কারণ এটাই। আর ব্যবহারের ধরন হলো মোবাইল-প্রধান: দেশের অনেক মানুষ ইন্টারনেট প্রথম পেয়েছেন মোবাইল ডেটায়, কম্পিউটারে নয়। তাই এ দেশে অ্যাপ বা ওয়েবসাইট বানাতে গেলে ধীর বা অস্থির মোবাইল সংযোগের কথা মাথায় রাখা বিশেষ জরুরি।

৮ · দুই চোখে ইন্টারনেট — সেবা বনাম অবকাঠামো, আর AI-ক্লাউডের যুগে কেন জরুরি

ইন্টারনেটকে দুইভাবে দেখা যায়, আর দুটোই সত্য:

🧩 সেবার চোখে (services view)

ইন্টারনেট একটি প্ল্যাটফর্ম, যা অ্যাপগুলোকে একে অপরের কাছে তথ্য পৌঁছে দেওয়ার সেবা দেয়। অ্যাপ বানানো মানুষ জানতে চান: “আমি socket-এ লিখলে তথ্য কি পৌঁছাবে? ক্রম ঠিক থাকবে?” এই চোখে নেটওয়ার্ক হলো একটি API.

ডেভেলপারের দৃষ্টি

🏗️ অবকাঠামোর চোখে (infrastructure view)

ইন্টারনেট হলো তার, fiber, টাওয়ার, router, switch আর এগুলো চালানোর সফটওয়্যারের এক বিশাল জাল — যার নকশা, খরচ, বিদ্যুৎ, রক্ষণাবেক্ষণ আছে। এই চোখে প্রশ্ন: “কোন link কতটা ভরা? কোথায় নষ্ট হলে কতজন বিচ্ছিন্ন?”

নেটওয়ার্ক ইঞ্জিনিয়ারের দৃষ্টি

ভালো ইঞ্জিনিয়ার দুই চোখেই দেখতে পারেন। একটি অ্যাপ ধীর হলে ডেভেলপার যদি শুধু কোড দেখেন, আর নেটওয়ার্ক ইঞ্জিনিয়ার যদি শুধু link দেখেন, সমস্যা প্রায়ই দুইয়ের মাঝখানে থেকে যায় — যেমন অ্যাপটি প্রতিটি ছোট কাজের জন্য নতুন সংযোগ খুলছে (আগের সিমুলেটরের তিনটি বাড়তি round trip!)।

AI আর ক্লাউডের যুগে নেটওয়ার্কের জ্ঞান কেন আরও জরুরি

  • সবকিছুই এখন কোনো না কোনো সার্ভারে: একটি AI চ্যাট অ্যাপ আসলে আপনার ফোন থেকে দূরের সার্ভারে HTTPS request. উত্তর দেরিতে এলে দোষ মডেলের, নাকি DNS, TLS বা দূরত্বের — নেটওয়ার্ক না বুঝলে আলাদা করা যায় না।
  • ক্লাউড মানে অন্যের ডেটা সেন্টারে ভাড়া করা নেটওয়ার্ক: সেখানে আপনাকে নিজে ঠিক করতে হয় subnet, firewall-এর নিয়ম, load balancer, private আর public ঠিকানা (পর্ব ১৭, ৪৯, ৫২, ৫৪)। একটি ভুল নিয়ম মানে পুরো ডেটাবেস ইন্টারনেটে খোলা।
  • বড় AI মডেলের প্রশিক্ষণ নিজেই একটি নেটওয়ার্ক সমস্যা: হাজার হাজার GPU-কে প্রতি মুহূর্তে একে অপরের সাথে বিপুল তথ্য বদল করতে হয়। ডেটা সেন্টারের ভেতরের নেটওয়ার্কের গতি আর delay সেখানে প্রায়ই মূল বাধা।
  • নিরাপত্তা: প্রায় প্রতিটি সাইবার আক্রমণ নেটওয়ার্ক দিয়েই আসে। প্রতিরক্ষা বুঝতে হলে আগে বুঝতে হয় স্বাভাবিক ট্রাফিক দেখতে কেমন (মডিউল ৮)।
  • চাকরির বাজার: backend, DevOps, cloud, SRE বা নেটওয়ার্ক ইঞ্জিনিয়ার — প্রায় প্রতিটি ইন্টারভিউতে নেটওয়ার্কের প্রশ্ন আসে, আর দেশের বিভিন্ন নিয়োগ পরীক্ষার কম্পিউটার অংশেও।

৯ · এই কোর্সের রোডম্যাপ — ১০টি মডিউল, ৬২টি পর্ব

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

মডিউলবিষয়পর্বযা পাবেন
১নেটওয়ার্কের ভিত্তি০১–০৬ইন্টারনেটের গঠন, স্তর (OSI, TCP/IP), packet switching, delay-এর হিসাব, Linux-এর টুল
২Physical আর data link স্তর০৭–১৪সংকেত, Nyquist-Shannon, fiber ও বেতার, CRC ও Hamming, ARQ, Ethernet, switch, VLAN, Wi-Fi
৩Network স্তর১৫–২১IPv4, subnetting ধাপে ধাপে, DHCP, ARP, NAT, ICMP, IPv6
৪Routing২২–২৬routing table, Bellman-Ford, Dijkstra, OSPF, BGP, IXP, multicast, QoS
৫Transport স্তর২৭–৩৩port, UDP, TCP-র handshake, নির্ভরযোগ্যতা, flow ও congestion control, QUIC
৬Application স্তর৩৪–৪০DNS, HTTP, HTTP/2-3, CDN, ইমেইল, streaming
৭Socket প্রোগ্রামিং৪১–৪৫C-তে TCP/UDP client-server, একসাথে অনেক client, epoll, নিজের HTTP সার্ভার
৮নেটওয়ার্ক নিরাপত্তা৪৬–৫০cryptography-র ভিত্তি, TLS, firewall, VPN, আক্রমণ আর প্রতিরক্ষা
৯আধুনিক নেটওয়ার্ক ও ক্যাপস্টোন৫১–৫৭মোবাইল, ডেটা সেন্টার, SDN, ক্লাউড ও container, সমস্যা খোঁজা, পারফরম্যান্স, পুরো নেটওয়ার্ক নকশা
১০পরীক্ষা ও ইন্টারভিউ প্রস্তুতি৫৮–৬২numerical, MCQ, লিখিত ও ভাইভা, ইন্টারভিউর প্রশ্ন, “google.com লিখে Enter চাপলে”

কীভাবে পড়বেন: একদম নতুন হলে প্রতিটি পর্বের উপমা, ছবি আর ধাপে ধাপে ডায়াগ্রাম আগে দেখুন; “আরও গভীরে” বাক্সগুলো প্রথমবার বাদ দিলেও কিছু হারাবে না। বিশ্ববিদ্যালয়ের কোর্স বা চাকরির পরীক্ষার প্রস্তুতি নিলে প্রতিটি পর্বের numerical আর “পরীক্ষা ও ইন্টারভিউতে” অংশ যত্ন নিয়ে করুন। আর পেশাদার হলে কোডগুলো চালান, তারপর নিজের Linux মেশিনে একই কাজ করে মিলিয়ে দেখুন।

১০ · AI-এর যুগে নেটওয়ার্কিং শেখা

AI নেটওয়ার্ক শেখায় দারুণ সাহায্যকারী — একটি ধারণা পাঁচভাবে বুঝিয়ে দিতে পারে, একটি কনফিগারেশন ব্যাখ্যা করতে পারে। কিন্তু নেটওয়ার্কিংয়ে AI-এর ভুলগুলো খুব নির্দিষ্ট ধরনের, আর সেগুলো আত্মবিশ্বাসী সুরে আসে:

AI-এর সাধারণ ভুলউদাহরণযাচাইয়ের উপায়
Subnet-এর ভুল হিসাব/26-এ usable host ৬৪টি বলা (আসলে ৬২টি)হাতে বা calculator-এ আবার হিসাব (পর্ব ১৭)
পুরোনো কমান্ডifconfig, netstat, route — নতুন Linux-এ প্রায়ই ইনস্টল থাকে নাip, ss; man ip দেখা (পর্ব ৬)
একটি vendor-এর কনফিগকে সার্বজনীন বলাCisco-র কমান্ড অন্য কোম্পানির router-এ চালাতে বলানিজের যন্ত্রের ডকুমেন্টেশন
অনিরাপদ firewall পরামর্শ“কাজ না করলে সব port খুলে দিন”, 0.0.0.0/0 থেকে ডেটাবেসে প্রবেশশুধু দরকারি port, শুধু দরকারি উৎস (পর্ব ৪৯)
বানানো RFC নম্বর বা ভুল সালঅস্তিত্বহীন RFC-র উদ্ধৃতিrfc-editor.org-এ খুলে দেখা

নতুন কোনো ধারণা AI দিয়ে বুঝতে চাইলে প্রশ্নটি এমনভাবে করুন, যাতে উত্তরে যাচাইযোগ্য জিনিস থাকে — সূত্র, পরিবেশ আর হাতে পরীক্ষা করার উপায়:

আমি কম্পিউটার নেটওয়ার্ক শিখছি। "ইন্টারনেট হলো নেটওয়ার্কের নেটওয়ার্ক" — কথাটি সহজ বাংলায় বোঝাও, একটি বাংলাদেশি উদাহরণ দিয়ে (বাসার Wi-Fi → ISP → IXP → বিদেশের সার্ভার)। শর্ত: ১. যেকোনো protocol-এর কথা বললে তার মূল RFC নম্বর দাও, আর নিশ্চিত না হলে স্পষ্ট বলো "নিশ্চিত নই"। ২. কমান্ড দিলে বলো কোন OS-এর জন্য (Linux না Windows), আর আধুনিক Linux-এ ip/ss ব্যবহার করো। ৩. শেষে এমন দুটি পরীক্ষা দাও, যা আমি নিজের ল্যাপটপে নিরাপদে চালিয়ে তোমার কথা যাচাই করতে পারি।

AI-এর নেটওয়ার্কিং উত্তর পেলে — যাচাইয়ের চেকলিস্ট

পরীক্ষা ও ইন্টারভিউতে এই বিষয়ে প্রায়ই যা জিজ্ঞেস করা হয়:

  • কম্পিউটার নেটওয়ার্ক কী? এর উপাদান? — যুক্ত যন্ত্রের ব্যবস্থা যারা protocol মেনে তথ্য বদল করে; উপাদান node, link, protocol (সাথে ঠিকানা ও মাধ্যম)।
  • Internet আর World Wide Web কি এক? — না; internet হলো নেটওয়ার্কের অবকাঠামো, web তার ওপর চলা একটি সেবা (HTTP, HTML, URL), যেমন ইমেইলও আরেকটি সেবা।
  • Protocol-এর তিন মূল উপাদান? — syntax (গঠন), semantics (অর্থ), timing (সময় ও ক্রম)।
  • RFC কী, কে প্রকাশ করে? — ইন্টারনেটের protocol আর নীতির দলিল; IETF-এর কাজ RFC Editor-এর মাধ্যমে প্রকাশিত হয়।
  • Browser-এ একটি URL লিখে Enter চাপলে কী হয়? — সংক্ষেপে DNS-এ ঠিকানা, TCP সংযোগ, (HTTPS হলে) TLS, HTTP request-response, তারপর পাতা আঁকা; বিস্তারিত পর্ব ৬২।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিয়ে নিজে কিছুক্ষণ ভাবুন — তারপর “→ উত্তর” চাপুন।

প্র ০১ইন্টারনেটের core-এর router-গুলো এত “বোকা” কেন — শুধু packet এগিয়ে দেয়, পৌঁছাল কি না দেখে না? এটা কি নকশার দুর্বলতা?

এটি দুর্বলতা নয়, ইন্টারনেটের সবচেয়ে সচেতন নকশা-সিদ্ধান্তগুলোর একটি। তুলনা করুন পুরোনো টেলিফোন ব্যবস্থার সাথে: সেখানে নেটওয়ার্ক ছিল “বুদ্ধিমান” — কল শুরুর আগে পুরো পথ সংরক্ষণ করা হতো, প্রতিটি এক্সচেঞ্জ প্রতিটি কলের হিসাব রাখত, আর প্রান্তের টেলিফোন সেটটি ছিল প্রায় বোকা যন্ত্র। নতুন সেবা আনতে হলে পুরো নেটওয়ার্ক বদলাতে হতো।

ইন্টারনেট উল্টো পথ ধরেছে। ১৯৮৪ সালে Jerome Saltzer, David Reed আর David Clark তাঁদের বিখ্যাত প্রবন্ধ “End-to-End Arguments in System Design”-এ যুক্তিটি গুছিয়ে বলেন: কোনো কাজ (যেমন তথ্য নির্ভুলভাবে পৌঁছানো নিশ্চিত করা) যদি শেষ পর্যন্ত দুই প্রান্তের অ্যাপকেই করতে হয়, তাহলে মাঝখানের নেটওয়ার্কে সেটি পুরোপুরি করার চেষ্টা বাড়তি খরচ — বড়জোর গতি বাড়ানোর জন্য আংশিক সাহায্য করা যায়। কারণ মাঝের প্রতিটি link নিখুঁত হলেও প্রাপকের যন্ত্রের ডিস্কে লেখার সময় ভুল হতে পারে; তাই শেষ যাচাই প্রান্তেই লাগবে।

এই নীতির ফল বিশাল। Core-এর router-কে শুধু একটি কাজ ভালোভাবে করতে হয় — গন্তব্য দেখে packet এগিয়ে দেওয়া, যাকে বলে “best effort”. নির্ভরযোগ্যতা, ক্রম মেলানো, গতি নিয়ন্ত্রণ — এসব থাকে প্রান্তের TCP-তে। ফলে ১৯৯১ সালে ওয়েব আনতে, পরে ভিডিও কল বা QUIC আনতে core বদলাতে হয়নি; শুধু প্রান্তে নতুন সফটওয়্যার লাগল। এজন্যই বলা হয়, ইন্টারনেট “অনুমতি ছাড়াই উদ্ভাবন” (permissionless innovation) সম্ভব করেছে।

তবে বাস্তব পুরোপুরি এত পরিষ্কার নয়। আজ পথে আছে NAT, firewall, load balancer, CDN — যারা packet-এর ভেতরে তাকায় এবং বদলায়ও। এদের বলে middlebox. এরা কাজের, কিন্তু নতুন protocol চালু করা কঠিন করে তুলেছে — কারণ অচেনা packet দেখলে অনেক middlebox ফেলে দেয়। QUIC যে UDP-র ওপর এবং প্রায় পুরোটা encrypted করে বানানো, তার একটি বড় কারণ এটাই (পর্ব ৩৩)।

মূল উপলব্ধি: সরল core আর বুদ্ধিমান প্রান্ত — এই ভাগাভাগিই ইন্টারনেটকে বাড়তে ও বদলাতে দিয়েছে। কোনো সিস্টেম নকশা করার সময় জিজ্ঞেস করুন: কোন কাজ কোথায় করলে সবচেয়ে কম জায়গা বদলে ভবিষ্যতে নতুন জিনিস আনা যাবে?

প্র ০২বিশ্বের সরকারগুলো OSI নামের একটি আন্তর্জাতিক standard সমর্থন করেছিল — তবু TCP/IP জিতল কেন?

১৯৭০-এর শেষ আর ১৯৮০-এর দশকে আন্তর্জাতিক standard সংস্থা ISO নেটওয়ার্কের একটি পূর্ণাঙ্গ কাঠামো তৈরি করছিল — Open Systems Interconnection, বা OSI. এর সাত স্তরের মডেলটি আজও পাঠ্যবইয়ে পড়ানো হয় (পর্ব ৩)। বিভিন্ন দেশের সরকার, বিশেষ করে ইউরোপে, OSI-কে ভবিষ্যৎ ধরে নিয়েছিল; যুক্তরাষ্ট্র সরকারও একসময় সরকারি কেনাকাটায় OSI সমর্থনের শর্ত (GOSIP) দিয়েছিল। কাগজে OSI ছিল বেশি গোছানো, বেশি “আনুষ্ঠানিক”।

তবু বাস্তবে জিতল TCP/IP. কয়েকটি কারণ:

  • আগে চলমান কোড: ১৯৮৩ সালেই ARPANET TCP/IP-তে চলছিল, আর University of California, Berkeley-র BSD Unix-এ TCP/IP বিনামূল্যে যুক্ত হয়ে বিশ্ববিদ্যালয়গুলোতে ছড়িয়ে পড়ে। OSI-র অনেক অংশ তখনো কমিটির টেবিলে।
  • কাজ করার সংস্কৃতি: IETF-এর একটি বিখ্যাত বাক্য David Clark-এর (১৯৯২): “We reject kings, presidents and voting. We believe in rough consensus and running code.” অর্থাৎ ভোট বা পদ নয়, মোটামুটি সর্বসম্মতি আর বাস্তবে চলা কোড দিয়ে সিদ্ধান্ত।
  • খোলা ও বিনামূল্যের দলিল: RFC যে কেউ পড়তে পারত; অনেক standard দলিল তখন কিনে পড়তে হতো।
  • সরলতা: TCP/IP অনেক কম জিনিস নির্ধারণ করত, ফলে বাস্তবায়ন সহজ ছিল।

তবে OSI পুরোপুরি হারিয়ে যায়নি। এর সাত স্তরের ভাষা — “layer 2 switch”, “layer 7 load balancer” — আজও ইঞ্জিনিয়াররা প্রতিদিন বলেন, আর OSI পরিবারের IS-IS routing protocol বড় ISP-দের নেটওয়ার্কে এখনো চলে।

মূল উপলব্ধি: প্রযুক্তিতে “সবচেয়ে নিখুঁত নকশা” সবসময় জেতে না; জেতে যেটি আগে কাজ করে, সহজে পাওয়া যায়, আর ধাপে ধাপে উন্নত হতে পারে। নিজের প্রজেক্টেও আগে চলমান সরল রূপ, তারপর উন্নতি।

প্র ০৩ইন্টারনেটের মালিক কে? কেউ কি চাইলে পুরো ইন্টারনেট “বন্ধ” করতে পারে?

ইন্টারনেটের কোনো একক মালিক নেই — এটিই “নেটওয়ার্কের নেটওয়ার্ক” কথাটির গভীর অর্থ। প্রতিটি অংশের মালিক আলাদা: আপনার বাসার রাউটার আপনার, ISP-র যন্ত্র ISP-র, সাবমেরিন কেবল সাধারণত বহু দেশের অপারেটরদের যৌথ মালিকানায় (consortium), ক্লাউড কোম্পানির নেটওয়ার্ক তাদের নিজেদের। এরা পরস্পরের সাথে চুক্তি করে যুক্ত — কেউ টাকা দিয়ে বাইরের সংযোগ কেনে (transit), কেউ সমানে সমানে বিনামূল্যে ট্রাফিক বদল করে (peering). এই চুক্তিগুলো বাস্তবায়িত হয় BGP দিয়ে (পর্ব ২৫)।

তবে কিছু জিনিসের সমন্বয় লাগে, নইলে সংঘাত হবে: দুজন একই IP ঠিকানা ব্যবহার করলে, বা দুজন একই domain নাম দাবি করলে। এই কাজ করে IANA (এখন ICANN-এর অধীনে একটি কাজ), যা ঠিকানার বড় ব্লক আঞ্চলিক রেজিস্ট্রিগুলোকে দেয় — যেমন এশিয়া-প্রশান্ত অঞ্চলের জন্য APNIC — আর DNS-এর শীর্ষ স্তর (root zone) সমন্বয় করে। Protocol লেখে IETF, কিন্তু IETF কাউকে মানতে বাধ্য করতে পারে না; মানুষ মানে কারণ না মানলে অন্যদের সাথে কথা বলা যায় না।

পুরো ইন্টারনেট একসাথে বন্ধ করা তাই প্রায় অসম্ভব — কোনো একটি সুইচ নেই। কিন্তু একটি দেশের ভেতরে বা একটি অঞ্চলে সংযোগ বিচ্ছিন্ন করা সম্ভব, কারণ সেখানে বাইরের সংযোগের পথ সীমিত — কয়েকটি গেটওয়ে, কয়েকটি কেবল। বিভিন্ন দেশে বিভিন্ন সময়ে সরকারি নির্দেশে মোবাইল ডেটা বা পুরো ইন্টারনেট বন্ধের ঘটনা ঘটেছে। আবার দুর্ঘটনাও বড় এলাকা বিচ্ছিন্ন করতে পারে: একটি বড় ISP ভুল BGP ঘোষণা দিলে বিশ্বের অন্য প্রান্তের সেবাও ঘণ্টাখানেক অচল হয়েছে — এমন ঘটনা ইতিহাসে বহুবার ঘটেছে।

এখান থেকে প্রকৌশলের শিক্ষা হলো “একক ব্যর্থতার বিন্দু” (single point of failure) খোঁজা। একটি দেশ বা প্রতিষ্ঠান যত বেশি স্বাধীন পথে যুক্ত, তত বেশি সহনশীল। এজন্যই নতুন কেবল, একাধিক upstream আর দেশীয় IXP — শুধু গতির জন্য নয়, টিকে থাকার জন্যও জরুরি।

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

প্র ০৪ব্যান্ডউইথ যত বাড়ুক, বিদেশের সার্ভার কেন সবসময় দেশের সার্ভারের চেয়ে “ধীর” লাগে? BDIX-এর মতো IXP এখানে কী বদলায়?

কারণটি পদার্থবিজ্ঞানে। আলো fiber-এর কাচের ভেতরে শূন্য মাধ্যমের চেয়ে ধীরে চলে — মোটামুটি প্রতি সেকেন্ডে ২ লাখ কিলোমিটার, অর্থাৎ প্রতি millisecond-এ প্রায় ২০০ কিলোমিটার। ধরা যাক কোনো সার্ভার পর্যন্ত কেবলের পথ ৫,০০০ কিলোমিটার (কেবল কখনো সোজা পথে যায় না, উপকূল ধরে ঘোরে)। তাহলে শুধু যেতে লাগবে ৫,০০০ ÷ ২০০ = ২৫ ms, যাওয়া-আসায় ৫০ ms — এর চেয়ে কম কোনোভাবেই সম্ভব নয়, ব্যান্ডউইথ যত বাড়ানো হোক। ব্যান্ডউইথ হলো রাস্তা কত চওড়া; দূরত্ব হলো রাস্তা কত লম্বা। চওড়া রাস্তায় একসাথে বেশি গাড়ি যায়, কিন্তু ঢাকা থেকে চট্টগ্রাম যেতে সময় কমে না।

আগের সিমুলেটরে দেখেছেন, একটি পাতা খুলতে কয়েকটি round trip লাগে। RTT ৫ ms হলে তিনটি round trip মাত্র ১৫ ms; RTT ১৫০ ms হলে সেটাই ৪৫০ ms — পার্থক্য চোখে পড়ার মতো। এজন্যই বড় কোম্পানিগুলো ব্যবহারকারীর কাছাকাছি সার্ভার বসায় (CDN, পর্ব ৩৮), আর ভিডিও বা গেমের সার্ভার দেশের ভেতরে থাকলে অভিজ্ঞতা অনেক ভালো হয়।

এবার IXP-র ভূমিকা। ধরুন দেশে কোনো IXP নেই, আর ISP-ক আর ISP-খ শুধু নিজের নিজের বিদেশি upstream-এর সাথে যুক্ত। তাহলে ঢাকায় পাশাপাশি দুই বাড়ির দুই গ্রাহকের packet-ও হয়তো বিদেশের কোনো শহর ঘুরে আসবে — যাকে বলা হয় “tromboning”. এতে delay বাড়ে, আর দুই ISP-কেই দামি আন্তর্জাতিক ব্যান্ডউইথের জন্য টাকা দিতে হয়, যদিও ট্রাফিক আসলে দেশের ভেতরের। একটি দেশীয় IXP — বাংলাদেশে BDIX — এই দুই সমস্যাই কমায়: দেশের ভেতরের ট্রাফিক দেশেই থাকে, পথ ছোট, খরচ কম। সাথে আরেকটি সুবিধা: বাইরের কেবলে সমস্যা হলেও দেশের ভেতরের অনেক সেবা চালু থাকতে পারে।

তবে IXP সব সমাধান করে না। যে সেবার সার্ভার শুধু বিদেশে, তার জন্য IXP কিছু করতে পারে না — যদি না সেই কোম্পানি দেশে cache বা সার্ভার বসায়। তাই বড় কনটেন্ট কোম্পানিগুলোর cache সার্ভার দেশের ভেতরে থাকা, আর একাধিক স্বাধীন আন্তর্জাতিক কেবল থাকা — দুটোই সমান জরুরি।

মূল উপলব্ধি: নেটওয়ার্কের গতির দুই আলাদা মাপ — ব্যান্ডউইথ (কত তথ্য প্রতি সেকেন্ডে) আর latency (কত দেরিতে)। আলোর গতি latency-র নিচের সীমা বেঁধে দেয়; তাকে হারানোর একমাত্র উপায় তথ্যকে কাছে নিয়ে আসা।

প্র ০৫AI এখন কোড লেখে, কনফিগও বানায় — তাহলে একজন ডেভেলপার বা IT কর্মীর নেটওয়ার্কের ভেতরের কাজ শেখার দরকার কী?

দরকার আগের চেয়েও বেশি, তিনটি কারণে।

প্রথম কারণ — সমস্যা খোঁজা AI-এর পক্ষে অন্ধ কাজ। “অ্যাপ মাঝে মাঝে ধীর” — এই অভিযোগের পেছনে থাকতে পারে DNS-এর ধীর উত্তর, প্রতিবার নতুন TLS সংযোগ, একটি ভরা link-এ packet হারানো, Wi-Fi-র দুর্বল সংকেত, বা সার্ভারের দূরত্ব। AI আপনার নেটওয়ার্ক দেখতে পায় না; সে সম্ভাব্য কারণের তালিকা দিতে পারে, কিন্তু কোনটি সত্য তা বের করতে হয় মেপে — ping, traceroute, ss, packet capture দিয়ে (পর্ব ৬, ২০, ৫৫)। কী মাপতে হবে, কী ফল স্বাভাবিক — সেটা জানতে হয় নিজেকে।

দ্বিতীয় কারণ — ভুল কনফিগের দাম অনেক। ক্লাউডে একটি ভুল firewall নিয়মে ডেটাবেস ইন্টারনেটে খোলা থাকতে পারে; একটি ভুল route-এ পুরো অফিস বিচ্ছিন্ন হতে পারে। বড় বড় সেবার অনেক বিভ্রাটের পেছনে কোনো হ্যাকার নয়, ছিল একটি সাধারণ কনফিগারেশন পরিবর্তন — এমন ঘটনা প্রকাশ্য ঘটনা-প্রতিবেদনে বহুবার এসেছে। AI-এর দেওয়া কনফিগ চালানোর আগে আপনাকে বুঝতে হবে প্রতিটি লাইন কী করে।

তৃতীয় কারণ — AI নিজেই একটি নেটওয়ার্ক-নির্ভর সিস্টেম। বড় ভাষা মডেলের প্রশিক্ষণে হাজার হাজার GPU একসাথে কাজ করে, আর প্রতিটি ধাপে তাদের হিসাবের ফল একে অপরের সাথে মেলাতে হয়। সেখানে ডেটা সেন্টারের ভেতরের নেটওয়ার্ক — উচ্চগতির link, কম delay, packet না হারানো — সরাসরি ঠিক করে প্রশিক্ষণ কত দ্রুত হবে। এজন্য AI অবকাঠামোর কোম্পানিগুলো বিশেষ নেটওয়ার্ক প্রযুক্তি আর নকশায় বিপুল বিনিয়োগ করছে (ডেটা সেন্টার নেটওয়ার্ক, পর্ব ৫২)। আবার ব্যবহারকারীর দিকে, প্রতিটি AI উত্তর আসে streaming সংযোগে, টুকরো টুকরো করে (পর্ব ৪০)।

আরেকটি সূক্ষ্ম কথা: AI সবচেয়ে বেশি শিখেছে ইন্টারনেটে প্রচলিত লেখা থেকে, আর নেটওয়ার্কিংয়ে প্রচলিত লেখার একটি বড় অংশ পুরোনো — ifconfig-এর যুগের, বা একটি নির্দিষ্ট vendor-এর। ভিত্তি জানা মানুষ এক নজরে বুঝতে পারেন উত্তরটি কোন যুগের, কোন যন্ত্রের।

মূল উপলব্ধি: AI উত্তর দ্রুত দেয়, কিন্তু সেই উত্তর আপনার নেটওয়ার্কে সত্য কি না, তা যাচাই করার ক্ষমতা আসে ভিত্তি জানা থেকে। যিনি packet-এর যাত্রা বোঝেন, AI তাঁর হাতে সবচেয়ে শক্তিশালী।

অনুশীলন

হাতে হিসাব, চোখে দেখা আর ভাবা — এগুলোই আসল কাজ।

  1. সময়ের হিসাব (হাতে): ধরুন ফোন থেকে সার্ভারের RTT = ৬০ ms, ফোন থেকে DNS resolver পর্যন্ত যাওয়া-আসায় ১৫ ms (resolver-এর cache-এ উত্তর আছে), সার্ভার পাতা বানাতে নেয় ৩০ ms, পাতার আকার ৫০০ KB, আর লিংকের গতি ১০ Mbps. HTTPS-এ (TCP + TLS 1.3) প্রথমবার পাতা খুলতে মোট কত সময়? উপরের সিমুলেটরের সরল মডেল ব্যবহার করুন।

    DNS = ১৫ ms (cache-এ আছে, তাই শুধু resolver পর্যন্ত যাওয়া-আসা)। TCP handshake = ১ RTT = ৬০ ms. TLS 1.3 = ১ RTT = ৬০ ms. HTTP = ১ RTT + সার্ভার = ৬০ + ৩০ = ৯০ ms. ডেটা: ৫০০ KB = ৪,০০০ kilobit; ১০ Mbps = প্রতি ms-এ ১০ kilobit, তাই ৪,০০০ ÷ ১০ = ৪০০ ms.

    মোট = ১৫ + ৬০ + ৬০ + ৯০ + ৪০০ = ৬২৫ ms. এখানে বড় অংশ ডেটা পাঠানো, কারণ পাতা বড় আর লিংক ধীর। পাতা ৫০ KB হলে ডেটার সময় হতো ৪০ ms, মোট ২৬৫ ms — তখন round trip-ই প্রধান। শিক্ষা: কোনটি বাধা, তা নির্ভর করে সংখ্যার ওপর; অনুমান নয়, হিসাব করুন।

  2. Output অনুমান করুন: একটি Linux মেশিনের /etc/hosts-এ শুধু একটি লাইন আছে: 127.0.0.1 localhost (কোনো ::1 লাইন নেই), আর সিস্টেমে কোনো IPv6 ঠিকানা কনফিগার করা নেই। উপরের resolve_localhost.c চালালে কী ছাপা হবে বলে মনে করেন? ai_socktype = SOCK_STREAM লাইনটি মুছে দিলে কী বদলাবে?

    সম্ভাব্য output একটিমাত্র লাইন: IPv4 127.0.0.1. Glibc প্রথমে /etc/hosts দেখে (সাধারণ nsswitch.conf নিয়মে), সেখানে শুধু IPv4 লাইন আছে। (সিস্টেমভেদে ব্যতিক্রম হতে পারে — কিছু resolver “localhost” নামকে নিজে থেকেই loopback ধরে নেয়; তাই চূড়ান্ত উত্তর পেতে চালিয়ে দেখাই নিয়ম।)

    SOCK_STREAM মুছলে hints-এ socket-এর ধরন শূন্য, অর্থাৎ “যেকোনো ধরন”। তখন glibc প্রতিটি ঠিকানার জন্য সাধারণত তিনটি ফল দেয় — TCP (stream), UDP (datagram) আর raw — তাই একই 127.0.0.1 লাইন তিনবার ছাপা হবে। এটা ভুল নয়: getaddrinfo ঠিকানা নয়, “সংযোগের উপায়”-এর তালিকা দেয়।

  3. নিজের যন্ত্রে দেখুন: নিজের কম্পিউটারে interface-এর তালিকা দেখুন — Linux-এ ip -br addr, Windows-এ PowerShell-এ Get-NetIPAddress বা Command Prompt-এ ipconfig, macOS-এ ifconfig. কয়টি interface পেলেন? কোনটি loopback? Wi-Fi-র ঠিকানাটি কোন পরিসরের?

    সাধারণত পাবেন: একটি loopback (Linux-এ lo, macOS-এ lo0; Windows-এ “Loopback Pseudo-Interface 1”) যার ঠিকানা 127.0.0.1 আর ::1; একটি Wi-Fi interface (Linux-এ প্রায়ই wlan0 বা wlp2s0-এর মতো নাম) যার ঠিকানা বাসার রাউটার দিয়েছে, প্রায়ই 192.168.x.x বা 10.x.x.x — এগুলো private ঠিকানা, ইন্টারনেটে সরাসরি অচল (পর্ব ১৯)। VPN, Docker বা virtual machine থাকলে আরও কয়েকটি virtual interface দেখবেন (যেমন docker0). প্রায়ই একটি fe80:: দিয়ে শুরু হওয়া IPv6 ঠিকানাও থাকে — এটি link-local, শুধু ওই link-এর ভেতরে চলে (পর্ব ২১)।

  4. শ্রেণিবিভাগ করুন: নিচের প্রতিটি জিনিস ইন্টারনেটের কোন অংশে পড়ে — edge (host), access network, নাকি core? (ক) আপনার ল্যাপটপ (খ) বাসার Wi-Fi রাউটার থেকে ISP পর্যন্ত fiber লাইন (গ) BDIX-এ যুক্ত একটি ISP-র বড় router (ঘ) একটি ব্যাংকের ওয়েব সার্ভার (ঙ) পাড়ার মোবাইল টাওয়ার।

    (ক) edge — অ্যাপ চালায়, host. (খ) access network — host-কে প্রথম ISP router-এর সাথে জোড়ে। (গ) core — অন্য নেটওয়ার্কের সাথে packet বদল করে। (ঘ) edge — সার্ভারও host, শুধু ভূমিকা server; সে যত বড় ডেটা সেন্টারেই থাকুক, packet-এর যাত্রার শেষ বিন্দু। (ঙ) access network — মোবাইল ফোনের প্রথম ধাপের সংযোগ; তবে টাওয়ারের পেছনের অপারেটরের নেটওয়ার্ক core-এর অংশ। খেয়াল করুন, সীমারেখা “যন্ত্রের আকার” দিয়ে নয়, “ভূমিকা” দিয়ে ঠিক হয়।

নিজেকে যাচাই করুন

ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।

ক্রমপ্রথমবার একটি HTTPS ওয়েবসাইট খোলার ধাপগুলো সঠিক ক্রমে সাজান (▲▼ চেপে সরান)

  1. 📶 ফোন Wi-Fi বা মোবাইল ডেটায় নেটওয়ার্কে যুক্ত
  2. 📖 DNS দিয়ে নাম থেকে IP ঠিকানা বের করা
  3. 🤝 TCP-র three-way handshake
  4. 🔐 TLS দিয়ে গোপন চাবিতে একমত হওয়া
  5. 📨 HTTP GET পাঠিয়ে 200 OK আর পাতা পাওয়া
  6. 🎨 Browser পাতা আঁকে, বাকি ফাইল চায়

“ইন্টারনেট হলো নেটওয়ার্কের নেটওয়ার্ক” — কথাটির সবচেয়ে সঠিক অর্থ কোনটি?

  • একটি বড় কোম্পানির মালিকানাধীন বিশ্বব্যাপী নেটওয়ার্ক
  • আলাদা মালিকের বহু স্বাধীন নেটওয়ার্ক পরস্পরের সাথে যুক্ত হয়ে তৈরি একটি ব্যবস্থা
  • World Wide Web-এর আরেক নাম
  • শুধু router-গুলোর একটি জাল, যেখানে কোনো host নেই

একটি protocol সাধারণত কোন তিনটি বিষয় নির্ধারণ করে?

  • তারের রং, দৈর্ঘ্য আর দাম
  • LAN, MAN আর WAN
  • Syntax, semantics আর timing
  • Router, switch আর hub

একটি প্রোগ্রাম 127.0.0.1 ঠিকানায় একটি packet পাঠাল। Packet-টি কোথায় যাবে?

  • একই যন্ত্রের loopback interface-এ — যন্ত্র ছেড়ে কোথাও যাবে না
  • বাসার Wi-Fi রাউটারে
  • ISP-র DNS সার্ভারে
  • ইন্টারনেটের প্রথম সার্ভারে

কোন প্রতিষ্ঠান আর দলিলের জোড়া সঠিক?

  • W3C — Wi-Fi-র 802.11 standard
  • IEEE — TCP-র RFC
  • ITU — Ethernet-এর 802.3
  • IETF — IP আর TCP-র RFC

ARPANET পুরোনো NCP ছেড়ে কবে TCP/IP-তে চলে যায়?

  • ২৯ অক্টোবর ১৯৬৯
  • ১ জানুয়ারি ১৯৮৩
  • মার্চ ১৯৮৯
  • আগস্ট ১৯৯১

ঢাকার ISP-ক-এর একজন গ্রাহক ঢাকার ISP-খ-এর একটি সার্ভার খুলছেন। দুই ISP-ই একটি দেশীয় IXP-তে যুক্ত। IXP-র প্রধান সুবিধা কী?

  • IXP নাম থেকে IP ঠিকানা বের করে দেয়
  • IXP সব ট্রাফিক encrypt করে নিরাপদ করে
  • দেশের ভেতরের ট্রাফিক দেশেই থাকে — পথ ছোট, delay ও খরচ কম
  • গ্রাহকের Wi-Fi-র গতি দ্বিগুণ হয়ে যায়

শব্দকোষ

লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব নতুন শব্দ এখানে একসাথে:

মনে রাখুন

  1. নেটওয়ার্ক = node + link + protocol; কারণ তিনটি — ভাগাভাগি, যোগাযোগ আর মাপ বাড়ানো।
  2. ইন্টারনেট নেটওয়ার্কের নেটওয়ার্ক: edge-এর host, access network (Wi-Fi, মোবাইল, fiber), আর ISP ও IXP-র router-এ গড়া core.
  3. ওয়েবসাইট খোলা = DNS → TCP → (TLS) → HTTP; সময়ের বড় অংশ প্রায়ই round trip-এ যায়।
  4. তথ্য যায় packet-এ, প্রতিটির গায়ে header; protocol ঠিক করে syntax, semantics, timing; নিয়ম লেখা আছে RFC, IEEE 802, ITU, W3C-এর দলিলে।
  5. Loopback (127.0.0.1, ::1, localhost) যন্ত্রের ভেতরেই ঘোরে; AI-এর নেটওয়ার্কিং উত্তর সবসময় হিসাব, man page, RFC আর ল্যাবে যাচাই করুন।

পরের পর্বে: আজ ইন্টারনেটকে দূর থেকে দেখলেন। এবার কাছ থেকে — LAN, WAN কী, যন্ত্রগুলো কোন আকারে সাজানো যায় (bus, star, ring, mesh), আর ISP-দের স্তরবিন্যাস দিয়ে ইন্টারনেটের গঠন।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

এই পর্বটি শেয়ার করুন:
এই পর্বে ভুল পেয়েছেন? জানান