স্তরে স্তরে নেটওয়ার্ক — OSI, TCP/IP আর encapsulation

১ · কেন স্তর — কুরিয়ার সার্ভিসের শিক্ষা

আপনার মোবাইলে একটি WhatsApp বার্তা লিখে “Send” চাপলেন। সেই মুহূর্তে কী কী ঘটতে হবে, একবার ভাবুন। বার্তাটিকে বাইটে রূপ দিতে হবে। ঠিক কোন অ্যাপের কাছে যাবে, তা চিহ্নিত করতে হবে। কোনো অংশ হারালে আবার পাঠাতে হবে। হাজার মাইল দূরের সার্ভার পর্যন্ত পথ খুঁজতে হবে। Wi-Fi-র বাতাসে বা fiber-এর আলোয় বাইটগুলোকে সংকেতে রূপ দিতে হবে। এত কাজ একটিমাত্র বিশাল প্রোগ্রাম করলে কী হতো? Wi-Fi-র জায়গায় 4G এলেই পুরো প্রোগ্রাম নতুন করে লিখতে হতো।

প্রকৌশলীরা এই জটিলতা সামলান একটি পুরোনো কৌশলে — কাজকে স্তরে স্তরে ভাগ করা। একে বলে layering. প্রতিটি স্তর একটি নির্দিষ্ট দায়িত্ব নেয়, নিচের স্তরের দেওয়া সুবিধা ব্যবহার করে, আর ওপরের স্তরকে একটি পরিষ্কার সুবিধা দেয়। ভেতরে কীভাবে কাজ হচ্ছে, তা ওপরের স্তর জানে না, জানার দরকারও নেই।

এই উপমা থেকে layering-এর তিনটি সুবিধা পরিষ্কার হয়:

২ · Service, protocol আর interface — আর peer-to-peer কথোপকথন

স্তরের কথা বলতে গেলে তিনটি শব্দ বারবার আসে, আর পরীক্ষায় এদের পার্থক্য প্রায়ই জিজ্ঞেস করা হয়। শব্দগুলো আলাদা করে বুঝে নিই।

• Service (সেবা): একটি স্তর তার ওপরের স্তরকে কী করে দেয় — যেমন transport স্তরের TCP বলে “আমি আপনার বাইটগুলো ক্রম ঠিক রেখে, না হারিয়ে পৌঁছে দেব।” এটি একটি প্রতিশ্রুতি, কীভাবে রাখা হবে তা বলে না।
• Protocol (প্রোটোকল): দুই মেশিনের একই স্তর পরস্পরের সাথে যে নিয়মে কথা বলে — বার্তার ফর্ম্যাট (কোন বাইটের কী মানে), ক্রম আর কোন ঘটনায় কী করতে হবে। TCP-র header-এর গঠন, three-way handshake — এসব protocol.
• Interface (ইন্টারফেস): একই মেশিনে পাশাপাশি দুই স্তরের সংযোগস্থল — ওপরের স্তর কীভাবে নিচের স্তরের সেবা চায়। Application আর transport-এর মাঝের interface হলো socket API (socket(), send(), recv()) — পর্ব ৪১-এ আমরা এটি দিয়ে প্রোগ্রাম লিখব।

Peer-to-peer যোগাযোগ: “যেন সরাসরি” কথা বলা

এখানেই layering-এর সবচেয়ে সূক্ষ্ম ধারণাটি। প্রেরকের TCP যখন একটি header লেখে, সেটি কে পড়বে? প্রাপকের TCP — অন্য কেউ নয়। মাঝের router TCP header নিয়ে মাথা ঘামায় না (সাধারণত; ব্যতিক্রম অংশ ৯-এ)। তাই বলা হয়, প্রতিটি স্তর অন্য প্রান্তের একই স্তরের সাথে — তার peer-এর সাথে — protocol-এর মাধ্যমে যেন সরাসরি কথা বলে। একে বলে peer-to-peer (বা horizontal) যোগাযোগ।

কিন্তু আসলে কোনো স্তরই সরাসরি কিছু পাঠায় না। আসল ডেটা যায় উল্লম্বভাবে: প্রেরকের ভেতরে ওপর থেকে নিচে, তারের ওপর দিয়ে, তারপর প্রাপকের ভেতরে নিচ থেকে ওপরে। শুধু সবচেয়ে নিচের physical স্তরেই সত্যিকারের সংযোগ। Peer-to-peer যোগাযোগ একটি যৌক্তিক (logical) ছবি; উল্লম্ব প্রবাহটি বাস্তব (physical) ছবি। দুটি একসাথে মাথায় রাখতে পারলেই নেটওয়ার্কের যেকোনো protocol বোঝা সহজ হয়ে যায়।

   প্রেরক                                     প্রাপক
 ┌────────────┐   application protocol    ┌────────────┐
 │ Application│ ◀ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ▶ │ Application│
 ├────────────┤   transport protocol      ├────────────┤
 │ Transport  │ ◀ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ▶ │ Transport  │
 ├────────────┤                           ├────────────┤
 │ Network    │ ◀ ─ ─ ─ ▶ [ Router ] ◀ ─ ▶ │ Network    │
 ├────────────┤                           ├────────────┤
 │ Link       │ ◀ ─ ─ ─ ▶ [ L2/L3  ] ◀ ─ ▶ │ Link       │
 ├────────────┤                           ├────────────┤
 │ Physical   │ ══════════ তার / বাতাস ════│ Physical   │
 └────────────┘                           └────────────┘
   ─ ─ ▶ যৌক্তিক (peer)     ═══ আসল সংযোগ     ডেটা চলে উল্লম্বভাবে

৩ · OSI-র সাত স্তর — পরীক্ষার ক্লাসিক টেবিল

নিচ থেকে ওপরে সাতটি স্তর। প্রতিটির জন্য চারটি প্রশ্ন মনে রাখুন: কী কাজ, ডেটার এককের নাম কী (PDU — protocol data unit), কোন protocol, আর কোন device এই স্তর পর্যন্ত দেখে।

টেবিলটি মুখস্থ করার আগে একটি প্যাটার্ন খেয়াল করুন: স্তর যত নিচে, তার “দৃষ্টি” তত ছোট। Physical স্তর শুধু এক তারের দুই প্রান্ত দেখে। Data link দেখে একটি link বা একটি LAN — পাশের যন্ত্র পর্যন্ত। Network স্তর দেখে পুরো ইন্টারনেট জুড়ে host থেকে host. Transport দেখে host-এর ভেতরের নির্দিষ্ট প্রোগ্রাম (port). এই কারণেই data link-এর MAC ঠিকানা প্রতিটি hop-এ বদলায়, কিন্তু IP ঠিকানা পুরো পথে একই থাকে (NAT না থাকলে) — অংশ ৫-এর stepper-এ নিজের চোখে দেখবেন।

Session আর presentation স্তর নিয়ে একটি সৎ কথা বলা দরকার: বাস্তবের ইন্টারনেটে এই দুটি স্তরের আলাদা, সর্বজনীন protocol প্রায় নেই। Encoding, compression, encryption, session — সবই সাধারণত application নিজেই করে, বা application-এর ব্যবহৃত library (যেমন TLS library). তাই অনেক পাঠ্যবই TLS-কে “application আর transport-এর মাঝে” রাখে, কেউ presentation-এ, কেউ session-এ। পরীক্ষায় প্রশ্নের প্রেক্ষাপট দেখে উত্তর দিন, আর লিখে দিন যে শ্রেণিবিভাগটি নিয়ে মতভেদ আছে — এটিই সবচেয়ে নির্ভুল উত্তর।

৪ · TCP/IP মডেল — যা আসলে চলে

OSI যখন কমিটিতে আলোচনা হচ্ছিল, তখন মার্কিন প্রতিরক্ষা গবেষণা সংস্থার অর্থায়নে ARPANET-এ আরেকটি কাজ এগোচ্ছিল। Vint Cerf আর Bob Kahn ১৯৭৪ সালে একটি প্রবন্ধে বিভিন্ন নেটওয়ার্ককে জোড়া লাগানোর (internetworking) একটি protocol-এর নকশা প্রকাশ করেন, যা পরে TCP আর IP — দুই ভাগে ভাগ হয়। ১৯৮১ সালে IP (RFC 791) আর TCP (RFC 793) প্রকাশিত হয়, আর ১ জানুয়ারি ১৯৮৩-তে ARPANET পুরোপুরি TCP/IP-তে চলে যায় — যে দিনটিকে অনেকে ইন্টারনেটের “জন্মদিন” বলেন।

TCP/IP-এর স্তর ভাগ OSI-র মতো আগে থেকে কমিটিতে ঠিক করা নয়; protocol-গুলো আগে তৈরি হয়েছে, মডেল পরে লেখা হয়েছে। Host-এর জন্য প্রয়োজনীয়তা নিয়ে ১৯৮৯ সালের RFC 1122 চারটি স্তরের কথা বলে: application, transport, internet, link. অনেক পাঠ্যবই (যেমন Kurose ও Ross-এর বই, আর এই কোর্সও) link স্তরকে data link আর physical-এ ভেঙে একটি ৫ স্তরের মিশ্র মডেল ব্যবহার করে — কারণ শেখার সময় তারের সংকেত আর frame-এর নিয়ম আলাদা করে বোঝা সহজ।

দুই মডেলের মিল ধাপে ধাপে দেখুন:

কেন TCP/IP জিতল — “protocol wars”

১৯৮০-র দশক জুড়ে দুই পক্ষের মধ্যে যে প্রতিযোগিতা চলেছিল, তাকে ইতিহাসবিদেরা প্রায়ই “protocol wars” বলেন। কাগজে-কলমে OSI-র পক্ষে ছিল অনেক দেশের সরকার, টেলিকম কোম্পানি আর আন্তর্জাতিক মান সংস্থা — মার্কিন সরকারও একসময় GOSIP নামে নীতি দিয়ে সরকারি কেনাকাটায় OSI চেয়েছিল বলে জানা যায়। তবু ১৯৯০-এর দশকের মাঝামাঝি নাগাদ বাজার স্পষ্টভাবে TCP/IP-র দিকে চলে যায়। সাধারণত যে কারণগুলো বলা হয়:

• চালু কোড আগে ছিল: TCP/IP-এর কাজ করা implementation ছিল; বিশেষ করে বিনামূল্যের BSD Unix-এ (১৯৮০-র দশকের শুরুতে) TCP/IP যুক্ত হওয়ায় বিশ্ববিদ্যালয় আর গবেষণাগারে তা ছড়িয়ে পড়ে।
• সময়: OSI-র মান যখন চূড়ান্ত হচ্ছিল, ততদিনে TCP/IP অনেক জায়গায় চলছে। Andrew Tanenbaum তাঁর পাঠ্যবইয়ে OSI-র ব্যর্থতার কারণ হিসেবে খারাপ সময়, খারাপ প্রযুক্তি, খারাপ implementation আর খারাপ রাজনীতির কথা লিখেছেন।
• জটিলতা: OSI-র মান ছিল বিশাল আর বহু বিকল্পে ভরা; দুই implementation একই মান মেনেও প্রায়ই একে অপরের সাথে মিলত না।
• উন্মুক্ত দলিল: RFC বিনামূল্যে যে কেউ পড়তে পারত; ISO-র মান অনেক সময় কিনতে হতো।
• সংস্কৃতি: IETF-এর বিখ্যাত দর্শন — David Clark-এর ১৯৯২ সালের একটি বক্তৃতার উক্তি হিসেবে প্রচলিত — “আমরা রাজা, প্রেসিডেন্ট আর ভোট মানি না; আমরা মানি rough consensus আর running code.” অর্থাৎ মোটামুটি ঐকমত্য আর বাস্তবে চলে এমন কোড।

৫ · Encapsulation আর decapsulation — “Hi”-এর যাত্রা

এবার মূল প্রক্রিয়া। পাঠানোর সময় প্রতিটি স্তর ওপর থেকে পাওয়া ডেটাকে নিজের payload হিসেবে ধরে, তার সামনে নিজের header জুড়ে দেয় (data link স্তর পেছনে একটি trailer-ও যোগ করে)। একে বলে encapsulation. প্রাপকের দিকে প্রতিটি স্তর নিজের header পড়ে, যাচাই করে, সরিয়ে বাকিটা ওপরে দেয় — একে বলে decapsulation. Header-এর ভেতরে থাকে সেই স্তরের protocol-এর তথ্য: ঠিকানা, ক্রম নম্বর, দৈর্ঘ্য, ত্রুটি-যাচাইয়ের সংখ্যা, আর সবচেয়ে গুরুত্বপূর্ণ — ওপরের স্তরে কে আছে (Ethernet-এর EtherType, IP-র protocol নম্বর, TCP/UDP-র port).

ধরুন আপনার ল্যাপটপের (192.168.1.10) ব্রাউজারে একটি ছোট chat পাতা থেকে “Hi” পাঠালেন একটি ওয়েব সার্ভারে (203.0.113.5, port 80). সরলতার জন্য ধরে নিচ্ছি application নিজে কোনো header যোগ করেনি — বাস্তবে HTTP বা WebSocket কয়েক থেকে কয়েকশো বাইট যোগ করে, আর HTTPS হলে TLS-ও। “পরে” চেপে প্রতিটি স্তর দেখুন:

এই যাত্রা থেকে PDU-র নামগুলো এক জায়গায় লিখে রাখুন — পরীক্ষায় প্রায় নিশ্চিত প্রশ্ন:

৬ · Header-এর খরচ — overhead আর efficiency-র হিসাব

প্রতিটি header বাড়তি বাইট, আর বাড়তি বাইট মানে তারে বাড়তি সময়। কাজের ডেটার (payload) সাথে মোট পাঠানো বাইটের অনুপাতকে বলে efficiency বা কার্যকারিতা, আর বাকিটা overhead:

পূর্ণ সমাধান করা উদাহরণ

প্রশ্ন: একটি application ১০০০ বাইট ডেটা TCP দিয়ে IPv4-এর ওপর Ethernet-এ পাঠাচ্ছে। TCP আর IP header-এ কোনো option নেই। (ক) Frame-এর আকার কত? (খ) Frame-এর হিসাবে efficiency কত? (গ) তারের সময়ের হিসাবে (preamble আর inter-frame gap ধরে) efficiency কত?

সমাধান:

• TCP segment = ১০০০ + ২০ = ১০২০ বাইট।
• IP packet = ১০২০ + ২০ = ১০৪০ বাইট। এটি ১৫০০-র কম, তাই একটি frame-এই যাবে (Ethernet-এর MTU ১৫০০); আবার ৪৬-এর বেশি, তাই padding লাগবে না।
• (ক) Frame = ১০৪০ + ১৪ (header) + ৪ (FCS) = ১০৫৮ বাইট।
• (খ) Efficiency = ১০০০ ÷ ১০৫৮ ≈ ০.৯৪৫২ = ৯৪.৫২%; overhead ≈ ৫.৪৮%.
• (গ) তারে প্রতি frame-এর জন্য আরও ৮ (preamble + SFD) + ১২ (gap) = ২০ বাইটের সময় লাগে: ১০০০ ÷ ১০৭৮ ≈ ৯২.৭৬%.

অর্থাৎ ১ Gbit/s লিংকে এই আকারের frame দিয়ে application সর্বোচ্চ প্রায় ৯২৭.৬ Mbit/s কাজের ডেটা পাবে — বাকিটা header আর ফাঁকের দাম। (Delay আর throughput-এর পূর্ণ হিসাব পর্ব ০৫-এ।) Header যোগ হওয়ার সাথে সাথে efficiency কীভাবে কমে, ধাপে ধাপে দেখুন:

হাতে করা হিসাব যন্ত্র দিয়ে মেলানো ভালো অভ্যাস। নিচের simulator তিনটি ভিন্ন আকারের ডেটার জন্য পুরো frame-এর গঠন আর efficiency ছাপে — Run চাপুন:

// Encapsulation: wrap application data in TCP, IPv4 and Ethernet.
const TCP = 20, IP = 20, ETH_HDR = 14, FCS = 4;   // header sizes in bytes (no options)
const MIN_PAYLOAD = 46;                          // Ethernet payload must be >= 46 bytes
const WIRE_EXTRA = 8 + 12;                       // preamble+SFD and inter-frame gap

function encapsulate(data) {
  const segment = TCP + data;                    // transport adds its header
  const packet = IP + segment;                   // network adds its header
  const pad = Math.max(0, MIN_PAYLOAD - packet); // tiny packets are padded
  const frame = ETH_HDR + packet + pad + FCS;    // link adds header + trailer
  return { segment, packet, pad, frame, wire: frame + WIRE_EXTRA };
}

for (const data of [1, 100, 1460]) {
  const r = encapsulate(data);
  console.log(`--- application data = ${data} bytes ---`);
  console.log(`[ETH 14 [IP 20 [TCP 20 [DATA ${data}]]]` +
              (r.pad ? ` PAD ${r.pad}` : "") + " FCS 4]");
  console.log(`segment=${r.segment}  packet=${r.packet}  frame=${r.frame}  on wire=${r.wire}`);
  const eff = (100 * data / r.frame).toFixed(2);
  const effWire = (100 * data / r.wire).toFixed(2);
  console.log(`efficiency: ${eff}% of frame, ${effWire}% of wire time`);
}

--- application data = 1 bytes ---
[ETH 14 [IP 20 [TCP 20 [DATA 1]]] PAD 5 FCS 4]
segment=21  packet=41  frame=64  on wire=84
efficiency: 1.56% of frame, 1.19% of wire time
--- application data = 100 bytes ---
[ETH 14 [IP 20 [TCP 20 [DATA 100]]] FCS 4]
segment=120  packet=140  frame=158  on wire=178
efficiency: 63.29% of frame, 56.18% of wire time
--- application data = 1460 bytes ---
[ETH 14 [IP 20 [TCP 20 [DATA 1460]]] FCS 4]
segment=1480  packet=1500  frame=1518  on wire=1538
efficiency: 96.18% of frame, 94.93% of wire time

৭ · ভেতরে উঁকি — hex থেকে স্তর আলাদা করা

Wireshark বা tcpdump (পর্ব ৫৫) একটি frame ধরলে আসলে পায় কিছু বাইট — আর কিছু না। সেই বাইট থেকে স্তরগুলো আলাদা করা যায় ঠিক এই কারণে যে প্রতিটি header-এর একটি ঘর বলে দেয় পরের অংশে কী আছে: EtherType বলে IP, IP-র protocol ঘর বলে UDP, UDP-র length বলে ডেটা কতটুকু। নিচে একটি ছোট LAN-এ (192.168.1.10 থেকে 192.168.1.20) UDP-তে “Hi” পাঠানোর একটি frame-এর hex আছে (FCS ধরা হয়নি, যেমন capture-এ সাধারণত দেখা যায়)। Decoder প্রতিটি স্তরের ঘর ছাপে আর IPv4 header-এর checksum যাচাই করে:

// Decode one captured frame: Ethernet II + IPv4 + UDP (FCS not captured).
const hex = "020000000002 020000000001 0800" +                 // Ethernet
  "4500 001e 1c46 4000 4011 9b1a c0a8010a c0a80114" +          // IPv4
  "c350 2328 000a 4d89" + "4869";                              // UDP + data
const b = hex.replace(/ /g, "").match(/../g).map(x => parseInt(x, 16));
const u16 = i => (b[i] << 8) | b[i + 1];
const mac = i => b.slice(i, i + 6).map(x => x.toString(16).padStart(2, "0")).join(":");
const ip = i => b.slice(i, i + 4).join(".");
const h4 = n => "0x" + n.toString(16).padStart(4, "0");

console.log(`frame length: ${b.length} bytes`);
console.log(`L2 Ethernet: dst=${mac(0)} src=${mac(6)} type=${h4(u16(12))} (IPv4)`);
const p = 14, ihl = (b[p] & 15) * 4;                           // IP header starts at 14
console.log(`L3 IPv4: version=${b[p] >> 4} header=${ihl}B total=${u16(p + 2)}B ` +
            `ttl=${b[p + 8]} proto=${b[p + 9]} (UDP)`);
console.log(`         src=${ip(p + 12)} dst=${ip(p + 16)} checksum=${h4(u16(p + 10))}`);
let sum = 0;                                                    // one's-complement sum
for (let i = p; i < p + ihl; i += 2) sum += u16(i);
while (sum > 0xffff) sum = (sum & 0xffff) + (sum >> 16);
console.log(`         checksum check: sum of all 10 words = ${h4(sum)} ` +
            (sum === 0xffff ? "-> OK" : "-> CORRUPT"));
const t = p + ihl;                                              // UDP starts after IP
console.log(`L4 UDP: src port=${u16(t)} dst port=${u16(t + 2)} length=${u16(t + 4)}B`);
const data = b.slice(t + 8, t + u16(t + 4));
console.log(`L7 data: "${String.fromCharCode(...data)}" (${data.length} bytes)`);
console.log(`lengths agree: ${b.length - 14 === u16(p + 2) && u16(p + 2) - ihl === u16(t + 4)}`);

frame length: 44 bytes
L2 Ethernet: dst=02:00:00:00:00:02 src=02:00:00:00:00:01 type=0x0800 (IPv4)
L3 IPv4: version=4 header=20B total=30B ttl=64 proto=17 (UDP)
         src=192.168.1.10 dst=192.168.1.20 checksum=0x9b1a
         checksum check: sum of all 10 words = 0xffff -> OK
L4 UDP: src port=50000 dst port=9000 length=10B
L7 data: "Hi" (2 bytes)
lengths agree: true

একই frame এবার C-তে বানিয়ে দেখি। প্রতিটি header একটি struct, ঘরগুলো নির্দিষ্ট আকারের (uint8_t, uint16_t, uint32_t) যাতে কোনো মেশিনে আকার না বদলায়। বহু-বাইটের সংখ্যা নেটওয়ার্কে যায় big-endian ক্রমে (“network byte order”), তাই htons/htonl. Buffer-এ সবচেয়ে বাইরের header আগে, ডেটা সবশেষে:

#include <stdio.h>
#include <stdint.h>
#include <stddef.h>
#include <string.h>
#include <arpa/inet.h>   /* htons, htonl: host order -> network (big-endian) order */
struct eth  { uint8_t dst[6], src[6]; uint16_t type; };                  /* L2 */
struct ipv4 { uint8_t ver_ihl, tos; uint16_t len, id, frag;
              uint8_t ttl, proto; uint16_t csum; uint32_t src, dst; };     /* L3 */
struct udp  { uint16_t sport, dport, len, csum; };                         /* L4 */
static uint16_t csum16(const uint8_t *b, size_t n) {   /* one's-complement sum */
    uint32_t s = 0;
    for (size_t k = 0; k + 1 < n; k += 2) s += (uint32_t)(b[k] << 8 | b[k + 1]);
    while (s >> 16) s = (s & 0xffff) + (s >> 16);
    return (uint16_t)~s;
}
int main(void) {
    const char msg[] = "Hi";                       /* L7 data, 2 bytes */
    struct eth e = { {2, 0, 0, 0, 0, 2}, {2, 0, 0, 0, 0, 1}, htons(0x0800) };
    struct ipv4 i = { 0x45, 0, htons(20 + 8 + 2), htons(0x1c46), htons(0x4000),
                      64, 17, 0, htonl(0xc0a8010a), htonl(0xc0a80114) };
    struct udp u = { htons(50000), htons(9000), htons(8 + 2), htons(0x4d89) };
    i.csum = htons(csum16((const uint8_t *)&i, sizeof i));
    uint8_t buf[64]; size_t off = 0;               /* outermost header first */
    memcpy(buf + off, &e, sizeof e); off += sizeof e;
    memcpy(buf + off, &i, sizeof i); off += sizeof i;
    memcpy(buf + off, &u, sizeof u); off += sizeof u;
    memcpy(buf + off, msg, 2);       off += 2;
    printf("sizeof eth=%zu ip=%zu udp=%zu\n", sizeof e, sizeof i, sizeof u);
    printf("offsets: eth=0 ip=%zu udp=%zu data=%zu total=%zu\n",
           sizeof e, sizeof e + sizeof i, off - 2, off);
    printf("ip.src at byte %zu of IP header, checksum=0x%04x\n",
           offsetof(struct ipv4, src), ntohs(i.csum));
    for (size_t k = 0; k < off; k++) printf("%s%02x", k == 0 ? "" : k % 16 ? " " : "\n", buf[k]);
    printf("\n"); return 0;
}

sizeof eth=14 ip=20 udp=8
offsets: eth=0 ip=14 udp=34 data=42 total=44
ip.src at byte 12 of IP header, checksum=0x9b1a
02 00 00 00 00 02 02 00 00 00 00 01 08 00 45 00
00 1e 1c 46 40 00 40 11 9b 1a c0 a8 01 0a c0 a8
01 14 c3 50 23 28 00 0a 4d 89 48 69

৮ · OS-এর ভেতরে স্তরগুলো কোথায় থাকে

স্তর শুধু কাগজের ছবি নয় — আপনার কম্পিউটারে এগুলো আলাদা আলাদা জায়গায় থাকে, আলাদা মানুষের লেখা কোডে। একটি সাধারণ Linux, Windows বা macOS মেশিনে:

অর্থাৎ ব্রাউজার যখন send() ডাকে, তখন একটি system call হয়: CPU user mode থেকে kernel mode-এ যায়, kernel ডেটা কপি করে নিজের buffer-এ রাখে, TCP আর IP header জোড়ে, driver-কে দেয়, আর driver NIC-কে জানায় কোন মেমরি থেকে frame নিয়ে পাঠাতে হবে (DMA আর interrupt-এর বিস্তারিত — I/O systems). প্রাপকের দিকে NIC interrupt দেয়, driver frame তুলে kernel stack-এ দেয়, আর শেষে অপেক্ষারত প্রোগ্রামের recv() ফিরে আসে। একই মেশিনের দুই প্রোগ্রাম 127.0.0.1-এ কথা বললে NIC পর্যন্ত যেতেই হয় না — kernel-এর loopback device-ই frame ফিরিয়ে দেয়; আর socket-কে IPC হিসেবে ব্যবহারের তুলনা আছে IPC পর্বে।

৯ · স্তরের নিয়ম ভাঙা — layer violation আর সমালোচনা

এ পর্যন্ত স্তরকে প্রায় পবিত্র নিয়মের মতো দেখিয়েছি। বাস্তবের ইন্টারনেট এতটা পরিপাটি নয়। অনেক যন্ত্র আর প্রোটোকল ইচ্ছে করেই অন্য স্তরের header দেখে বা বদলায় — একে বলে layer violation. কয়েকটি গুরুত্বপূর্ণ উদাহরণ:

• NAT: বাড়ির router একটি network স্তরের যন্ত্র, কিন্তু অনেক ডিভাইসকে একটি public IP দিয়ে চালাতে সে TCP/UDP-র port নম্বর বদলায় (transport স্তর!) আর তাই TCP/UDP checksum-ও নতুন করে লেখে। FTP-র মতো protocol, যার application ডেটার ভেতরে IP ঠিকানা লেখা থাকে, NAT-এর পেছনে ঠিকমতো চলাতে router-কে application স্তরও খুলে দেখতে হয় (ALG). বিস্তারিত পর্ব ১৯-এ।
• Firewall আর DPI: “port 443 খোলা, বাকি বন্ধ” — এটি L3 যন্ত্রের L4 সিদ্ধান্ত। Deep packet inspection আরও ভেতরে application ডেটা পর্যন্ত দেখে।
• Load balancer আর proxy: L7 load balancer HTTP-র URL বা cookie দেখে কোন সার্ভারে পাঠাবে ঠিক করে — মাঝপথে বসে দুই প্রান্তের কথোপকথনে অংশ নেয়।
• MSS clamping: PPPoE বা VPN-এর মতো লিংকে MTU ছোট হলে router TCP handshake-এর MSS option বদলে দেয়, যাতে বড় packet আটকে না যায় — network যন্ত্র transport header লিখছে।

এসব যন্ত্রকে একসাথে বলে middlebox. এগুলো বাস্তব সমস্যার সমাধান করে, কিন্তু দাম আছে: ইন্টারনেট “জমে” যায় (ossification). একটি middlebox যদি শুধু চেনা TCP option-ই পাস করতে দেয়, তাহলে TCP-তে নতুন বৈশিষ্ট্য যোগ করা কার্যত অসম্ভব হয়ে পড়ে — যদিও দুই প্রান্ত দুটিই নতুন সংস্করণ বোঝে। SCTP-র মতো নতুন transport protocol বহু বছর পরেও সাধারণ ইন্টারনেটে প্রায় চলে না, কারণ অনেক NAT আর firewall শুধু TCP আর UDP চেনে। QUIC-এর নকশাকারীরা এজন্যই UDP-র ওপর বানিয়েছেন আর header-এর প্রায় সবটা encrypt করেছেন — যাতে মাঝপথের কেউ দেখে “অভ্যস্ত” হয়ে যেতে না পারে (পর্ব ৩৩)।

Layering কি সবসময় ভালো?

২০০২ সালের RFC 3439-এ একটি অংশের শিরোনামই “Layering Considered Harmful” — যুক্তি হলো, কঠোর স্তরভাগ কখনো কখনো একই কাজ একাধিক স্তরে বারবার করায় (যেমন একাধিক স্তরে ত্রুটি-যাচাই আর retransmission) আর তথ্য লুকিয়ে রেখে ভালো সিদ্ধান্ত নিতে দেয় না। বেতার নেটওয়ার্ক এর সবচেয়ে পরিচিত উদাহরণ: TCP ধরে নেয় packet হারানো মানে রাস্তায় জ্যাম (congestion), তাই গতি কমায়। কিন্তু মোবাইলের দুর্বল সিগন্যালে packet হারায় রেডিওর ত্রুটিতে — তখন গতি কমানো ভুল ওষুধ। এজন্য Wi-Fi আর মোবাইল নেটওয়ার্ক link স্তরেই দ্রুত retransmission করে, আর গবেষকেরা বহু “cross-layer” নকশা প্রস্তাব করেছেন, যেখানে এক স্তর আরেক স্তরকে ইঙ্গিত দেয়।

১০ · AI-এর যুগে স্তর-চিন্তা

“OSI model কী?” — এই প্রশ্নে যেকোনো AI চোখের পলকে একটি সুন্দর টেবিল দেবে। সমস্যা হলো, সেই টেবিলে প্রায়ই সূক্ষ্ম ভুল থাকে, আর আত্মবিশ্বাসী ভঙ্গিতে লেখা বলে চোখ এড়িয়ে যায়। স্তরের ধারণা পরিষ্কার থাকলে আপনি সেগুলো ধরতে পারবেন। নেটওয়ার্কিং বিষয়ে AI-এর সাধারণ ভুল:

AI-এর দেওয়া নেটওয়ার্ক-উত্তর গ্রহণের আগে — চেকলিস্ট

• প্রতিটি protocol আর device-কে সঠিক স্তরে বসানো হয়েছে কি না নিজে মিলিয়েছি (switch → MAC, router → IP, port → transport)
• সংখ্যার হিসাব (header আকার, efficiency, subnet) হাতে বা ক্যালকুলেটরে আবার করেছি
• কমান্ডগুলো আমার OS-এর জন্য কি না আর আধুনিক কি না (ip/ss বনাম ifconfig/netstat) man page দেখে নিশ্চিত হয়েছি
• উল্লেখ করা RFC নম্বর আর শিরোনাম rfc-editor.org-এ খুঁজে পেয়েছি
• Firewall বা নিরাপত্তা-সংক্রান্ত পরামর্শে “সব খুলে দিন” জাতীয় কিছু নেই; ন্যূনতম অনুমতি মানা হয়েছে
• সম্ভব হলে নিজের ল্যাব বা VM-এ চালিয়ে packet capture করে দেখেছি — দাবিটি সত্যিই ঘটে কি না