লিখিত ও মৌখিক (ভাইভা) প্রশ্ন — স্তর, protocol আর হিসাব

সংজ্ঞা: OSI মডেল হলো ISO-র সাত স্তরের ধারণাগত কাঠামো — কোন কাজ কোন স্তরে হবে তা ভাগ করে দেয়, নির্দিষ্ট protocol বাধ্য করে না। TCP/IP মডেল ইন্টারনেটের আসল protocol-গুলো (IP, TCP, UDP) ঘিরে গড়া চার স্তরের মডেল — link, internet, transport, application; অনেক বই link-কে physical আর data link-এ ভেঙে পাঁচ স্তরে পড়ায়।

      OSI (7)                 TCP/IP (4)            PDU
 +----------------+      +------------------+
 | 7 Application  |      |                  |
 | 6 Presentation |  --> |   Application    |   message / data
 | 5 Session      |      |                  |
 +----------------+      +------------------+
 | 4 Transport    |  --> |   Transport      |   segment (TCP) / datagram (UDP)
 +----------------+      +------------------+
 | 3 Network      |  --> |   Internet       |   packet (IP datagram)
 +----------------+      +------------------+
 | 2 Data link    |      |                  |   frame
 | 1 Physical     |  --> |   Link           |   bits
 +----------------+      +------------------+

স্তরের কাজ: Physical — বিট থেকে সংকেত; Data link — এক hop-এ frame, MAC; Network — routing, IP; Transport — port, নির্ভরযোগ্যতা; Session — সংলাপ; Presentation — ডেটার রূপ, encryption; Application — HTTP, DNS-এর মতো সেবা।

Encapsulation: পাঠানোর সময় প্রতিটি স্তর ওপরের স্তরের ডেটার সামনে নিজের header জোড়ে (data link শেষে trailer-ও, যেমন FCS) — চিঠি খামে, খাম বস্তায়, বস্তা ট্রাকে। গ্রহীতা নিচ থেকে ওপরে প্রতিটি header খুলে (decapsulation) ঠিক স্তরে তুলে দেয়। উদাহরণ: ব্রাউজারের HTTP request → TCP header (port 443) → IP header (গন্তব্য IP) → Ethernet header (পরের hop-এর MAC) → বিট।

সুবিধা ও সীমা: একটি স্তর বদলালে (Wi-Fi থেকে fiber) বাকিগুলো একই থাকে, সমস্যা খোঁজা সহজ; দাম — প্রতিটি header-এর overhead, আর কখনো স্তরের নিয়ম ভাঙা (NAT port বদলায়)।

নম্বর কোথায়: দুটির সংজ্ঞা (২), লেবেলসহ পাশাপাশি ছবি (২), তুলনার টেবিল (২), প্রতিটি স্তরের কাজ ও PDU (২), encapsulation-এর উদাহরণ (২)। পর্ব ০৩

সংজ্ঞা: Circuit switching-এ কথা শুরুর আগে পুরো পথে নির্দিষ্ট সম্পদ (একটি TDM slot বা frequency) সংরক্ষিত হয় — পুরোনো টেলিফোনের মতো। Packet switching-এ ডেটা ছোট packet-এ ভাগ হয়; প্রতিটি packet নিজের header নিয়ে link ভাগাভাগি করে যায়, router পুরো packet পেয়ে তবে পাঠায় (store-and-forward).

হিসাব: L = ১,৫০০ × ৮ = ১২,০০০ বিট। Transmission delay = L/R = ১২,০০০ / (১০ × ১০^৬) = ১.২ ms. Propagation delay = d/s = (২ × ১০^৬ m) / (২ × ১০^৮ m/s) = ১০ ms. এক link-এ মোট ১১.২ ms.

তিন link হলে: প্রতিটি router পুরো packet পেয়ে তবে পাঠায়, তাই transmission তিনবার: ৩ × ১.২ = ৩.৬ ms; propagation মোট দূরত্বে একই ১০ ms. মোট ১৩.৬ ms. সাধারণ সূত্র — N টি link, প্রতিটি R: N·L/R + মোট d/s.

নম্বর কোথায়: সংজ্ঞা (২), তুলনার টেবিল (২), দুই delay সূত্র ও একক (২), store-and-forward-এর তিনগুণ transmission (২)। পর্ব ০৪ · পর্ব ০৫

সংজ্ঞা: CSMA/CD (Carrier Sense Multiple Access with Collision Detection) একটি ভাগ করা তারে (bus বা hub) কে কখন পাঠাবে তার নিয়ম: পাঠানোর আগে শোনা (carrier sense), পাঠানোর সময়ও শোনা, ধাক্কা (collision) টের পেলে থামা আর এলোমেলো সময় পরে আবার চেষ্টা।

   [frame ready]  n = 0
         |
         v
   +-----------------+   busy
   | channel idle? --|--------+  (keep sensing: 1-persistent)
   +-----------------+        |
         | yes   ^------------+
         v
   [transmit, keep listening]
         |
   +-----------------+   no
   | collision?      |--------> [success, n = 0]
   +-----------------+
         | yes
         v
   [stop, send jam signal]  n = n + 1
         |
   +-----------------+   yes
   | n > 15 ?        |--------> [give up, report error]
   +-----------------+
         | no
         v
   [pick K from 0 .. 2^min(n,10) - 1, wait K x slot time] --> back to "channel idle?"

ব্যাখ্যা: (১) channel ফাঁকা হলে পাঠানো, ব্যস্ত হলে অপেক্ষা; (২) পাঠানোর সময় collision ধরা; (৩) ধরা পড়লে থেমে ছোট jam signal (Ethernet-এ ৩২ বিট), যাতে সবাই টের পায়; (৪) binary exponential backoff — n-তম collision-এর পর ০ থেকে ২^{min(n,১০)} − ১-এর মধ্যে এলোমেলো K, তারপর K × slot time অপেক্ষা (১০ Mbps-এ ৫১.২ µs); ১৬তম ব্যর্থ চেষ্টার পর হাল ছাড়া।

Minimum frame size-এর যুক্তি: সবচেয়ে খারাপ ক্ষেত্রে A-র সংকেত B-তে পৌঁছানোর ঠিক আগে B পাঠানো শুরু করে; B-র সংকেত ফিরে A-তে আসতে আরও এক T_p. তাই collision টের পেতে A-কে অন্তত ২T_p সময় ধরে পাঠাতে হয় — নইলে A ভাববে সফল। শর্ত T_t ≥ ২T_p, অর্থাৎ L/R ≥ ২d/v, তাই L_min = ২·d·R/v.

হিসাব: T_p = ১,০০০ / (২ × ১০^৮) = ৫ µs; ২T_p = ১০ µs; L_min = ১০ × ১০^−৬ × ১০০ × ১০^৬ = ১,০০০ বিট = ১২৫ বাইট.

Wi-Fi কেন নয়: বেতারে নিজের পাঠানো সংকেত অন্যের দুর্বল সংকেতকে ঢেকে দেয়, তাই পাঠাতে পাঠাতে শোনা কার্যত অসম্ভব; তার ওপর hidden terminal — দুটি station access point শুনতে পায় কিন্তু একে অন্যকে নয়। তাই Wi-Fi CSMA/CA নেয়: আগে থেকে এলোমেলো অপেক্ষা, ACK দিয়ে সাফল্য নিশ্চিত, দরকারে RTS/CTS.

সীমা ও বাস্তবতা: ভার বাড়লে collision বাড়ে; গতি বাড়লে minimum frame বড় হয়। আজকের switched full-duplex Ethernet-এ collision-ই হয় না, তাই CSMA/CD কার্যত বন্ধ।

নম্বর কোথায়: সংজ্ঞা (১), লেবেলসহ flowchart (৩), jam আর backoff-এর ব্যাখ্যা (২), minimum frame-এর যুক্তি ও হিসাব (২), Wi-Fi আর full-duplex-এর মন্তব্য (২)। পর্ব ১১ · পর্ব ১৪

SNR রূপান্তর: ৩০ dB = ১০ log_১০(SNR) ⇒ SNR = ১০^৩ = ১,০০০ (dB সরাসরি সূত্রে বসানো সবচেয়ে চেনা ভুল)।

Shannon: C = B log_২(১ + SNR) = ৩,০০০ × log_২(১,০০১) ≈ ৩,০০০ × ৯.৯৭ ≈ ২৯,৯০০ bps ≈ ২৯.৯ kbps.

Nyquist: শব্দহীন channel-এ সর্বোচ্চ হার = ২B log_২M = ২ × ৩,০০০ × ২ = ১২,০০০ bps.

পার্থক্য: Nyquist শব্দহীন channel-এ স্তর বাড়িয়ে হার বাড়ানোর সীমা দেয় — যত স্তর তত হার। Shannon শব্দ ধরে চূড়ান্ত সীমা দেয় — কোনো encoding-ই এর বেশি নির্ভুলভাবে পাঠাতে পারে না। Shannon-এর হার পেতে স্তর লাগত প্রায় ২^C/২B ≈ ৩২.

নম্বর কোথায়: dB রূপান্তর (১), Shannon হিসাব (২), Nyquist হিসাব (১), পার্থক্য (১)। পর্ব ০৭

ধাপ ১: Generator-এর বিট 10011 (degree r = ৪), তাই ডেটার শেষে চারটি শূন্য: 11010110110000.

ধাপ ২ — modulo-২ ভাগ (XOR, ধার নেই): যেখানে সামনের বিট ১, সেখানে 10011 দিয়ে XOR:

1101011011 0000
11010                 (bits 1-5)
10011  XOR -> 01001
 10011                (bits 2-6)
 10011 XOR -> 00000
      10110           (bits 7-11)
      10011 XOR -> 00101
        10100         (bits 9-13)
        10011 XOR -> 00111
remainder (last 4 bits) = 1110

ধাপ ৩: CRC = 1110; পাঠানো ধারা = ডেটা + CRC = 11010110111110.

গ্রহীতা: পুরো ১৪ বিট একই 10011 দিয়ে ভাগ করে; ভাগশেষ 0000 হলে error ধরা পড়েনি, শূন্য না হলে frame বাতিল। (যাচাই script-এ ভাগশেষ 0000 এসেছে।)

কী ধরে: x + 1 উৎপাদক থাকা generator-এ সব বিজোড়-সংখ্যক বিটের error; সব একক আর দুই-বিটের error (উপযুক্ত generator-এ); আর r বা তার কম দৈর্ঘ্যের সব burst error. CRC শুধু ধরে, ঠিক করে না, আর ইচ্ছাকৃত পরিবর্তন থেকে রক্ষা করে না।

নম্বর কোথায়: শূন্য যোগ (১), ভাগের ধাপ (২), CRC ও পাঠানো ধারা (১), গ্রহীতার যাচাই (১), কী ধরে (১)। পর্ব ০৯

সূত্র: এক frame পাঠাতে T_t, তারপর ACK ফিরে আসা পর্যন্ত ২T_p চুপ। এক চক্র = T_t + ২T_p, কাজের সময় T_t. তাই U = T_t / (T_t + ২T_p) = ১/(১ + ২a), যেখানে a = T_p/T_t.

হিসাব: T_t = ১,০০০ / ১০^৬ = ১ ms; a = ২০/১ = ২০; U = ১/৪১ ≈ ২.৪৪% — link প্রায় পুরো সময় অলস।

Sliding window: W টি frame একসাথে ভাসমান রাখলে U = min(১, W/(১ + ২a)); পূর্ণ ব্যবহারে W ≥ ১ + ২a = ৪১.

Sequence বিট: k বিটে ২^kটি নম্বর। Go-Back-N-এ W ≤ ২^k − ১ ⇒ ২^k ≥ ৪২ ⇒ k = ৬ (৬৩). Selective Repeat-এ W ≤ ২^k−১ ⇒ ২^k ≥ ৮২ ⇒ k = ৭ (window ৬৪ পর্যন্ত)।

SR-এ অর্ধেক কেন: সব ACK হারালে প্রেরক পুরোনো window আবার পাঠায়, অথচ গ্রহীতার window ততক্ষণে সামনে সরে গেছে। দুই window-এ একই নম্বর থাকলে গ্রহীতা পুরোনো frame-কে নতুন ভেবে নেবে। W ≤ ২^k−১ হলে দুই window কখনো মেশে না।

নম্বর কোথায়: সূত্রের যুক্তি (২), U-র হিসাব (২), W (১), দুই প্রোটোকলের বিট (২), SR-এর সীমার যুক্তি (১)। পর্ব ১০

গোনা: প্রতিটি switch port আর router interface একটি করে collision domain; hub-এর পুরো অংশ একটি। S1: ৪টি PC-port + R-এর দিকের link = ৫. S2: ৩টি PC-port + hub-এর port (hub আর তার ৩টি PC মিলে একটিই) + R-এর দিকের link = ৫. মোট ১০টি collision domain. Broadcast domain = router-এর interface-সংখ্যা = ২টি.

সীমা: full-duplex link-এ বাস্তবে collision হয় না, তবু পরীক্ষায় port ধরে গোনা প্রচলিত; VLAN থাকলে এক switch-এও একাধিক broadcast domain.

নম্বর কোথায়: টেবিল (৩), collision গোনা ও যুক্তি (২), broadcast (১)। পর্ব ১২ · পর্ব ১৩

সংজ্ঞা: VLSM মানে একই ব্লক থেকে ভিন্ন আকারের subnet — যার যতটুকু দরকার। নিয়ম: (১) প্রয়োজন বড় থেকে ছোট সাজানো; (২) ২^h − ২ ≥ host এমন সবচেয়ে ছোট h (network আর broadcast বাদ); (৩) prefix = ৩২ − h; (৪) পরের ফাঁকা ঠিকানা থেকে বসানো — বড় ব্লক আগে বলে প্রতিটি নিজের সীমানায় পড়ে।

আকার: A ১০০ → ১২৮ (h = ৭, /25); B ৫০ → ৬৪ (/26); C ২৫ → ৩২ (/27); D ১০ → ১৬ (/28); প্রতিটি WAN ২ → ৪ (/30).

বাকি: 192.168.10.248/29 — ৮টি ঠিকানা, ভবিষ্যতের আরেকটি ছোট link বা loopback-এর জন্য। মোট ব্যবহার ১২৮ + ৬৪ + ৩২ + ১৬ + ৪ + ৪ = ২৪৮.

FLSM-এ কেন নয়: সব subnet সমান হলে সবচেয়ে বড়টির মাপ (১২৮) সবাইকে দিতে হতো — /25-এ মাত্র দুটি subnet হয়, অথচ লাগবে ছয়টি। VLSM ছোট link-এ ছোট ব্লক দিয়ে জায়গা বাঁচায়।

হিসাবটি নিচের ছোট planner-এ মিলিয়ে নিন। প্রয়োজনের তালিকা ইচ্ছা করে এলোমেলো ক্রমে লেখা; প্রোগ্রাম নিজেই বড় থেকে ছোট সাজায়:

// VLSM: biggest need first; each block = smallest power of two >= hosts + 2.
const base = "192.168.10.0", prefix = 24;
const needs = [["LAN-C", 25], ["WAN-1", 2], ["LAN-A", 100], ["LAN-D", 10], ["LAN-B", 50], ["WAN-2", 2]];
const toInt = s => s.split(".").reduce((a, o) => a * 256 + Number(o), 0);
const toIp = n => [24, 16, 8, 0].map(sh => Math.floor(n / 2 ** sh) % 256).join(".");
let next = toInt(base);
const end = next + 2 ** (32 - prefix);
console.log("name   need  subnet             usable range                     broadcast       mask");
for (const [name, hosts] of [...needs].sort((a, b) => b[1] - a[1])) {
  let bits = 0;
  while (2 ** bits < hosts + 2) bits++;          // +2: network + broadcast address
  const size = 2 ** bits;
  if (next + size > end) { console.log(name, "does not fit!"); break; }
  console.log(name.padEnd(6), String(hosts).padStart(4), " " + (toIp(next) + "/" + (32 - bits)).padEnd(18),
    (toIp(next + 1) + " - " + toIp(next + size - 2)).padEnd(32), toIp(next + size - 1).padEnd(15),
    toIp(2 ** 32 - size));
  next += size;
}
console.log("still free:", toIp(next) + " onwards,", end - next, "addresses");

name   need  subnet             usable range                     broadcast       mask
LAN-A   100  192.168.10.0/25    192.168.10.1 - 192.168.10.126    192.168.10.127  255.255.255.128
LAN-B    50  192.168.10.128/26  192.168.10.129 - 192.168.10.190  192.168.10.191  255.255.255.192
LAN-C    25  192.168.10.192/27  192.168.10.193 - 192.168.10.222  192.168.10.223  255.255.255.224
LAN-D    10  192.168.10.224/28  192.168.10.225 - 192.168.10.238  192.168.10.239  255.255.255.240
WAN-1     2  192.168.10.240/30  192.168.10.241 - 192.168.10.242  192.168.10.243  255.255.255.252
WAN-2     2  192.168.10.244/30  192.168.10.245 - 192.168.10.246  192.168.10.247  255.255.255.252
still free: 192.168.10.248 onwards, 8 addresses

নম্বর কোথায়: নিয়ম আর সাজানোর কারণ (২), প্রতিটি আকার ও prefix (২), পূর্ণ টেবিল — network, range, broadcast, mask (৪), বাকি ঠিকানা (১), FLSM-এর তুলনা (১)। পর্ব ১৭

সংজ্ঞা: DHCP একটি যন্ত্রকে স্বয়ংক্রিয়ভাবে IP ঠিকানা, subnet mask, default gateway আর DNS সার্ভারের ঠিকানা ধার দেয় (lease, নির্দিষ্ট সময়ের জন্য)। ARP একই LAN-এ একটি IPv4 ঠিকানার MAC ঠিকানা খুঁজে দেয়। ধরি DHCP সার্ভার ও gateway 192.168.1.1, অফিসের LAN 192.168.1.0/24.

laptop (0.0.0.0, UDP 68)                     DHCP server 192.168.1.1 (UDP 67)
  |-- 1 DISCOVER  to 255.255.255.255 (broadcast) ------------>|
  |<------------- 2 OFFER  192.168.1.50, mask, gw, DNS, lease --|
  |-- 3 REQUEST  "I take .50 from 192.168.1.1" (broadcast) --->|
  |<------------- 4 ACK  lease confirmed ----------------------|
laptop now 192.168.1.50/24, gateway 192.168.1.1
  |-- 5 ARP request "who has 192.168.1.1?" to ff:ff:ff:ff:ff:ff -> all hosts
  |<- 6 ARP reply "192.168.1.1 is at <gateway MAC>" (unicast) --
  |-- 7 IP packet to 198.51.100.20 inside a frame to the gateway's MAC -->

DORA: (১) Discover — ঠিকানা নেই, তাই উৎস 0.0.0.0, গন্তব্য broadcast; (২) Offer — সার্ভারের প্রস্তাব (বাস্তবায়নভেদে unicast বা broadcast); (৩) Request — আবার broadcast, যাতে অন্য সার্ভার জানে তাদের প্রস্তাব নেওয়া হয়নি; (৪) Ack — lease নিশ্চিত। অন্য subnet-এ সার্ভার থাকলে router-এর DHCP relay লাগে। এই চার ধাপের নাম DORA.

ARP কার জন্য: ল্যাপটপ নিজের mask দিয়ে দেখে 198.51.100.20 নিজের subnet-এ নেই, তাই packet যাবে gateway-তে। ARP-এ খোঁজে gateway-এর MAC, দূরের সার্ভারের নয় — Ethernet frame শুধু এক hop যায়। Request broadcast, reply unicast; উত্তর ARP cache-এ কিছুক্ষণ থাকে। Frame-এ গন্তব্য MAC gateway-এর, কিন্তু ভেতরের IP header-এ গন্তব্য 198.51.100.20.

সীমা: দুটিতেই যাচাই নেই — নকল DHCP সার্ভার বা নকল ARP reply ট্রাফিক ঘোরাতে পারে; প্রতিরক্ষা DHCP snooping আর dynamic ARP inspection. IPv6-এ ARP-এর বদলে Neighbor Discovery.

নম্বর কোথায়: দুটির সংজ্ঞা (১), DORA-র চার বার্তা ঠিক উৎস-গন্তব্যসহ (৩), Request কেন broadcast (১), ARP-এ gateway-এর MAC আর তার যুক্তি (২), নিরাপত্তা বা IPv6-এর মন্তব্য (১)। পর্ব ১৮

সংজ্ঞা: NAT router পার হওয়ার সময় packet-এর private IP বদলে public IP বসায়। PAT (বা NAPT, Linux-এ masquerade) port-ও বদলায়, তাই একটি public IP-র পেছনে শত শত যন্ত্র চলে — বাড়ির রাউটারে এটিই হয়। Private পরিসর: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918).

ব্যাখ্যা: দুজনের source port একই, তাই router দ্বিতীয়টিকে আলাদা বাইরের port দেয়; উত্তর 203.0.113.5:40002-এ এলে টেবিল দেখে 192.168.1.11:51000-এ ফেরায়।

অসুবিধা: (১) বাইরে থেকে সংযোগ শুরু করা যায় না — port forwarding বা NAT traversal লাগে, P2P আর VoIP-এ ঝামেলা; (২) end-to-end নীতি ভাঙে — header বদলায়, checksum নতুন করে হিসাব, কিছু protocol (payload-এ IP লেখা) ভাঙে। NAT নিরাপত্তার যন্ত্র নয় — সুরক্ষা দেয় firewall-এর নিয়ম।

নম্বর কোথায়: সংজ্ঞা ও PAT (২), টেবিল (২), অসুবিধা (১)। পর্ব ১৯

Fragmentation-এর হিসাব: ডেটা = ৪,০০০ − ২০ = ৩,৯৮০ বাইট। প্রতিটি fragment-এ ডেটা সর্বোচ্চ ১,৫০০ − ২০ = ১,৪৮০ বাইট — ৮-এর গুণিতক, কারণ offset গোনা হয় ৮ বাইটের এককে।

তিনটিরই Identification একই; জোড়া লাগে শুধু শেষ গন্তব্যে। একটি fragment হারালে পুরো datagram বাতিল — fragmentation-এর বড় দাম।

IPv6-এ: পথের router fragment করত না; packet ফেলে দিয়ে উৎসকে ICMPv6 “Packet Too Big” পাঠাত, আর উৎস ছোট করে পাঠাত (দরকারে নিজেই Fragment extension header দিয়ে)। প্রতিটি IPv6 link-এর MTU অন্তত ১,২৮০ বাইট।

নম্বর কোথায়: পার্থক্যের টেবিল (৩), fragment-এর টেবিল (৩), ৮-বাইট এককের কারণ (১), IPv6-এর আচরণ (১)। পর্ব ১৬ · পর্ব ২১

সংজ্ঞা: Distance vector-এ প্রতিটি router শুধু প্রতিবেশীদের সাথে নিজের দূরত্ব-তালিকা ভাগ করে, আর Bellman-Ford সমীকরণ D_x(y) = min_v{c(x,v) + D_v(y)} দিয়ে নিজের তালিকা হালনাগাদ করে — “গুজব শুনে পথ চেনা”। Link state-এ প্রতিটি router নিজের link-এর তথ্য পুরো নেটওয়ার্কে flood করে; সবার হাতে একই মানচিত্র, আর প্রত্যেকে নিজে Dijkstra চালায় — “মানচিত্র দেখে পথ চেনা”।

Dijkstra-র টেবিল (খালি ঘর = নোডটি ইতিমধ্যে N′-এ; ধাপ ২-এ v আর y দুটিরই দূরত্ব ২, বর্ণানুক্রমে v আগে):

Forwarding table (u): v → সরাসরি v (খরচ ২); x → x (১); y → x (২); w → x (৩, পথ u-x-y-w); z → x (৪, পথ u-x-y-z). প্রতিটি গন্তব্যের প্রথম hop পেতে p(·) ধরে পেছনে হাঁটুন যতক্ষণ না u-র প্রতিবেশী আসে।

// Dijkstra from u, printed as the exam table: N' and D(n),p(n). Tie -> alphabetical.
const edges = [["u","v",2], ["u","w",5], ["u","x",1], ["v","x",2], ["v","w",3],
               ["x","w",3], ["x","y",1], ["w","y",1], ["w","z",5], ["y","z",2]];
const G = {};
for (const [a, b, c] of edges) { (G[a] ??= {})[b] = c; (G[b] ??= {})[a] = c; }
const nodes = Object.keys(G).sort(), others = nodes.filter(n => n !== "u");
const D = {}, P = {}, done = [];
for (const n of nodes) { D[n] = Infinity; P[n] = "-"; }
D.u = 0;
console.log("step N'      " + others.map(n => ("D(" + n + "),p(" + n + ")").padEnd(12)).join(""));
for (let step = 0; done.length < nodes.length; step++) {
  const n = nodes.filter(x => !done.includes(x))
                 .sort((a, b) => D[a] - D[b] || (a < b ? -1 : 1))[0];
  done.push(n);
  for (const [m, c] of Object.entries(G[n]))
    if (!done.includes(m) && D[n] + c < D[m]) { D[m] = D[n] + c; P[m] = n; }
  const cells = others.map(x => (done.includes(x) ? "" :
                  D[x] === Infinity ? "inf" : D[x] + "," + P[x]).padEnd(12));
  console.log(String(step).padEnd(5) + done.join("").padEnd(8) + cells.join(""));
}
// forwarding table at u: walk each path back to the first hop
const first = n => (P[n] === "u" ? n : first(P[n]));
console.log("\nforwarding table at u:");
for (const n of others) console.log("  to " + n + ": next hop " + first(n) + ", cost " + D[n]);

step N'      D(v),p(v)   D(w),p(w)   D(x),p(x)   D(y),p(y)   D(z),p(z)
0    u       2,u         5,u         1,u         inf         inf
1    ux      2,u         4,x                     2,x         inf
2    uxv                 4,x                     2,x         inf
3    uxvy                3,y                                 4,y
4    uxvyw                                                   4,y
5    uxvywz

forwarding table at u:
  to v: next hop v, cost 2
  to w: next hop x, cost 3
  to x: next hop x, cost 1
  to y: next hop x, cost 2
  to z: next hop x, cost 4

নম্বর কোথায়: দুটির সংজ্ঞা ও সমীকরণ (২), তুলনার টেবিল (৩), Dijkstra-র পূর্ণ টেবিল (৩), forwarding table (১), tie-নিয়ম বা অঋণাত্মক cost-এর মন্তব্য (১)। পর্ব ২৩ · পর্ব ২৪

উদাহরণ: সারি A — B — C, প্রতিটি cost ১; B-র কাছে C ১, A-র কাছে ২ (B হয়ে)। B–C ভাঙল। B দেখে A বলছে “C আমার থেকে ২” — জানে না পথটি B হয়েই — তাই B লেখে ৩ (A হয়ে), A লেখে ৪, B ৫, A ৬… মাঝে packet A আর B-র মাঝে loop-এ ঘোরে। RIP-এ ১৬ = অসীম বলে একসময় থামে।

Split horizon: যে প্রতিবেশী হয়ে কোনো গন্তব্যে যাই, তাকে সেই গন্তব্যের পথ জানাই না। Poison reverse: জানাই, কিন্তু দূরত্ব অসীম বলে — এখানে A, B-কে বলত “C আমার থেকে ∞”, ফলে B সঙ্গে সঙ্গে বুঝত C অগম্য।

সীমা: দুটি নোডের loop এগুলো ঠেকায়, কিন্তু তিন বা বেশি router-এর বৃত্তে (A→B→C→A) পথের খবর ঘুরপথে ফিরে আসে, তখন count-to-infinity আবার হয়। বাড়তি উপায় — triggered update, hold-down timer, বা path vector.

নম্বর কোথায়: উদাহরণে অন্তত তিন ধাপের মান (২), দুই কৌশলের সংজ্ঞা (২), সীমা (১)। পর্ব ২৩

সংজ্ঞা: ইন্টারনেট হাজার হাজার autonomous system-এর (AS — একটি প্রশাসনের অধীনের নেটওয়ার্ক, যেমন একটি ISP) জোড়া। প্রতিটি AS-এর ভেতরে OSPF বা IS-IS-এর মতো IGP; AS-গুলোর মাঝে একটিই মানক — BGP, একটি path-vector protocol, যা TCP port 179-এ চলে।

eBGP বনাম iBGP: eBGP দুই ভিন্ন AS-এর router-এর মাঝে — বাইরের পথ শেখা আর জানানো; iBGP একই AS-এর ভেতরের BGP router-গুলোর মাঝে — বাইরে থেকে শেখা পথ ভেতরে ছড়ানো।

নীতি কেন: AS-গুলো ব্যবসা — কে কাকে transit দেবে, কার ট্রাফিক বিনা পয়সায় (peering) আর কার জন্য টাকা (customer–provider), তা চুক্তির বিষয়। তাই সিদ্ধান্তে আগে local preference (নিজের নীতি), তারপর ছোট AS-path, তারপর অন্যান্য মাপকাঠি। পূর্ণ AS-path থাকায় loop ধরা সহজ — নিজের AS-নম্বর পথে দেখলে বাতিল।

নম্বর কোথায়: AS আর BGP-র সংজ্ঞা (২), eBGP/iBGP (২), নীতির যুক্তি (১)। পর্ব ২৫

   client                                        server
 SYN_SENT    -- SYN  seq=1000 ------------------->          LISTEN
             <-- SYN+ACK  seq=5000 ack=1001 ----  SYN_RCVD
 ESTABLISHED -- ACK  seq=1001 ack=5001 ---------->  ESTABLISHED
             -- data seq=1001 (200 bytes) ack=5001 ->
             <-- ACK  ack=1201 ------------------
 FIN_WAIT_1  -- FIN  seq=1201 ------------------->  CLOSE_WAIT
 FIN_WAIT_2  <-- ACK  ack=1202 ------------------
             <-- FIN  seq=5001 ------------------  LAST_ACK
 TIME_WAIT   -- ACK  ack=5002 ------------------->  CLOSED
 (waits 2 x MSL, then CLOSED)

ব্যাখ্যা: SYN আর FIN প্রতিটি একটি sequence নম্বর খায়, তাই SYN-এর পর ack 1001, FIN-এর পর ack 1202. ২০০ বাইট ১০০১ থেকে ১২০০ পর্যন্ত, তাই ACK ১২০১ — “পরের যে বাইট চাই”। Handshake-এর তৃতীয় ACK-এ ডেটা না থাকলে seq নম্বর খরচ হয় না, তাই ডেটাও seq 1001 থেকে শুরু।

দুই ধাপে কেন নয়: (১) দুই দিকেরই ISN জানাতে আর নিশ্চিত হতে হবে — client-এর ACK ছাড়া server জানে না তার ISN পৌঁছেছে কি না; (২) নেটওয়ার্কে আটকে থাকা পুরোনো SYN দেরিতে এলে দুই ধাপে server ভুয়া সংযোগ খুলে বসত; তৃতীয় ধাপে client “আমি এটি চাইনি” (RST) বলে বাতিল করতে পারে।

TIME_WAIT: শেষ ACK হারালে server আবার FIN পাঠাবে — তখন উত্তর দেওয়ার জন্য client কিছুক্ষণ থাকে; আর পুরোনো সংযোগের দেরিতে আসা segment যেন একই port-জোড়ার নতুন সংযোগে ঢুকে না পড়ে। সময় ২ × MSL (বাস্তবায়নভেদে আলাদা; Linux-এ ৬০ সেকেন্ড)।

নম্বর কোথায়: তুলনার টেবিল (২), লেবেলসহ সময়রেখা ও state (৩), seq/ack-এর যুক্তি (২), তিন ধাপের কারণ (২), TIME_WAIT (১)। পর্ব ২৯ · পর্ব ৩০

সংজ্ঞা: Congestion control হলো নেটওয়ার্কের ভিড় বুঝে প্রেরকের গতি নিয়ন্ত্রণ। প্রেরক একটি congestion window (cwnd) রাখে; ভাসমান ডেটা ≤ min(cwnd, rwnd), তাই গতি মোটামুটি cwnd/RTT.

• Slow start: cwnd = ১ MSS থেকে শুরু, প্রতিটি ACK-এ +১ MSS — ফলে প্রতি RTT-তে দ্বিগুণ, যতক্ষণ না ssthresh ছোঁয়।
• Congestion avoidance: ssthresh-এর পর প্রতি RTT-তে মাত্র +১ MSS — additive increase.
• Fast retransmit: তিনটি duplicate ACK মানে একটি segment হারিয়েছে কিন্তু পরেরগুলো পৌঁছাচ্ছে — timeout-এর অপেক্ষা না করে সঙ্গে সঙ্গে আবার পাঠানো।
• Fast recovery (Reno): ssthresh = cwnd/২, cwnd প্রায় ssthresh — অর্ধেক গতিতে চলা অব্যাহত। Timeout-এ ssthresh = cwnd/২, cwnd = ১, আবার slow start; Tahoe দুই ক্ষেত্রেই cwnd = ১.

উত্তর: slow start — round ১–৫ আর ১৬–১৯; congestion avoidance — ৬–১০, ১১–১৫ আর ২০ (ssthresh ছোঁয়ার round বইভেদে যেকোনো পর্যায়ে — যেটি ধরবেন লিখে দিন)। ১০০তম segment round ১০-এ। কিছু বই fast recovery-র পর ssthresh + ৩ দেখায় (round ১১-তে ১১)।

নম্বর কোথায়: চার পর্যায়ের সংজ্ঞা (৪), লেবেলসহ গ্রাফ (৩), loss-এর ধরন অনুযায়ী প্রতিক্রিয়া ও ssthresh (২), segment গোনা বা AIMD-র মন্তব্য (১)। পর্ব ৩২

পার্থক্য: Flow control গ্রহীতাকে রক্ষা করে — গ্রহীতা নিজের buffer-এর ফাঁকা জায়গা receive window (rwnd) হিসেবে প্রতিটি ACK-এ জানায়। Congestion control নেটওয়ার্ককে রক্ষা করে — প্রেরক loss বা delay দেখে নিজে cwnd অনুমান করে। প্রেরক পাঠায় min(rwnd, cwnd) পর্যন্ত।

BDP: ১০০ × ১০^৬ × ০.০৫ = ৫ × ১০^৬ বিট = ৬,২৫,০০০ বাইট — পাইপ ভরে রাখতে এতটা ডেটা একসাথে ভাসমান থাকা দরকার।

Window scaling ছাড়া: throughput ≤ window/RTT = ৬৫,৫৩৫ × ৮ / ০.০৫ ≈ ১০.৫ Mbps — ১০০ Mbps-এর লাইনেও মাত্র এক-দশমাংশ। ৬,২৫,০০০ / ৬৫,৫৩৫ ≈ ৯.৫৪, তাই window scale shift অন্তত ৪ (×১৬) লাগবে।

RTO (RFC 6298, RTTVAR আগে, পুরোনো SRTT দিয়ে): RTTVAR = ০.৭৫ × ২০ + ০.২৫ × |১০০ − ১৪০| = ১৫ + ১০ = ২৫ ms; SRTT = ০.৮৭৫ × ১০০ + ০.১২৫ × ১৪০ = ১০৫ ms; RTO = ১০৫ + ৪ × ২৫ = ২০৫ ms. (যে বই নতুন SRTT দিয়ে DevRTT হিসাব করে, সেখানে ২৩.৭৫ ms আর RTO ২০০ ms আসে — পদ্ধতি লিখে দিন।) RFC 6298 RTO-র সর্বনিম্ন ১ সেকেন্ড সুপারিশ করে; Linux-এর সর্বনিম্ন ২০০ ms.

নম্বর কোথায়: পার্থক্য (২), BDP ও throughput (২), RTO-র ধাপ (২)। পর্ব ৩১ · পর্ব ৩০ · পর্ব ৫৬

সংজ্ঞা: DNS একটি বিতরণকৃত, স্তরভিত্তিক নামের ডেটাবেস — ডোমেইন নাম থেকে IP ঠিকানা (এবং আরও রেকর্ড) দেয়; সাধারণত UDP port 53, বড় উত্তর বা zone transfer-এ TCP 53.

 stub resolver        recursive resolver           root server
 (your PC)            (ISP / office / public)      ("." zone)
     |--1 A? www.example.com -->|                      |
     |                          |--2 A? www.example.com-->|
     |                          |<-3 ask .com TLD servers-|   (referral, NS + glue)
     |                          |            .com TLD server
     |                          |--4 A? www.example.com -->|
     |                          |<-5 ask example.com NS ---|   (referral)
     |                          |            example.com authoritative server
     |                          |--6 A? www.example.com -->|
     |                          |<-7 A = 203.0.113.80, TTL 3600
     |<-8 A = 203.0.113.80 -----|   (cached for up to 3600 s)

ব্যাখ্যা: (১) Stub resolver নিজের cache-এ না পেলে recursive resolver-কে recursive query পাঠায় — “পুরো উত্তর এনে দিন”। (২–৩) Root server শুধু .com-এর TLD সার্ভার দেখিয়ে দেয় (referral). (৪–৫) TLD দেখায় example.com-এর authoritative server. (৬–৮) Authoritative সার্ভার A রেকর্ড দেয়; resolver তা ফেরায় আর cache-এ রাখে।

Recursive বনাম iterative: stub → resolver পর্যায়টি recursive (প্রশ্নকারী শুধু শেষ উত্তর চায়); resolver → root/TLD/authoritative পর্যায়টি iterative (প্রতিটি সার্ভার “আমি জানি না, ওকে জিজ্ঞেস করুন” বলে)। এতে root আর TLD সার্ভারের ওপর চাপ কম থাকে।

Caching ও TTL: প্রতিটি রেকর্ডের TTL বলে কত সেকেন্ড cache-এ রাখা যাবে। ফলে বেশিরভাগ query root পর্যন্ত যায়ই না — .com-এর NS রেকর্ড প্রায় সব সময় cache-এ থাকে। দাম: ঠিকানা বদলালে পুরোনো উত্তর TTL শেষ না হওয়া পর্যন্ত থেকে যায় — তাই সার্ভার বদলের আগে TTL ছোট করে রাখা হয়।

নম্বর কোথায়: সংজ্ঞা ও port (১), লেবেলসহ ছবি (৩), প্রতিটি ধাপের ব্যাখ্যা (২), recursive বনাম iterative (১), cache ও TTL (১)। পর্ব ৩৫

Method: GET (পড়া), POST (নতুন কিছু পাঠানো বা তৈরি), PUT (পুরোটা বদলানো), PATCH (আংশিক বদল), DELETE (মোছা), HEAD (শুধু header). GET, HEAD নিরাপদ (safe); GET, PUT, DELETE idempotent — একবার আর দশবার পাঠানোর ফল একই; POST নয়।

Status code: 1xx তথ্য, 2xx সফল (200 OK, 201 Created), 3xx অন্যত্র যান (301 স্থায়ী, 302 সাময়িক, 304 Not Modified — cache-এর কপিই চলবে), 4xx client-এর ভুল (400, 401, 403, 404), 5xx সার্ভারের ভুল (500, 502, 503).

State কীভাবে: HTTP নিজে আগের request মনে রাখে না। লগইনের পর সার্ভার Set-Cookie header-এ একটি session ID পাঠায়; ব্রাউজার পরের প্রতিটি request-এ Cookie header-এ তা ফেরত দেয়, আর সার্ভার ID দেখে ব্যবহারকারী চেনে। নিরাপত্তায় cookie-তে Secure, HttpOnly, SameSite.

সময়ের হিসাব (N = ১০, প্রতিটি নতুন TCP সংযোগে handshake-এ ১ RTT, request–response-এ ১ RTT):

• Non-persistent, একটি একটি করে: (N + ১) × ২ RTT = ১১ × ২০০ = ২,২০০ ms.
• Persistent, pipelining ছাড়া: base-এ ২ RTT, তারপর প্রতিটি ছবিতে ১ RTT — ২০০ + ১০ × ১০০ = ১,২০০ ms.
• Persistent, pipelining-সহ: base-এ ২ RTT, তারপর সব ছবির request একসাথে — ১ RTT; মোট ৩০০ ms.

নম্বর কোথায়: method ও idempotent (১), status-এর শ্রেণি (১), cookie-র প্রবাহ (১), তিন সময় সূত্রসহ (৩)। পর্ব ৩৬ · পর্ব ৩৭

সংজ্ঞা: HTTPS = HTTP + TLS. TLS তিনটি জিনিস দেয়: গোপনীয়তা (confidentiality — মাঝের কেউ পড়তে পারে না), অখণ্ডতা (integrity — বদলালে ধরা পড়ে) আর সার্ভারের পরিচয় নিশ্চিত করা (authentication — certificate দিয়ে)।

  client (browser)                                   server (example.com)
   |-- ClientHello: TLS versions, cipher suites,           |
   |   key_share (ECDHE public value), SNI=example.com --> |
   |<-- ServerHello: chosen suite, key_share --------------|
   |    both sides now compute the shared secret (ECDHE)   |
   |<-- {EncryptedExtensions} {Certificate}                |
   |    {CertificateVerify: signature with server key}     |
   |    {Finished: MAC over the whole handshake} ----------|
   |-- {Finished} ---------------------------------------->|
   |== HTTP request/response, encrypted (AEAD) ===========|
   ({ } = already encrypted; 1 RTT before application data)

ধাপের ব্যাখ্যা: (১) ClientHello-তে সংস্করণ, cipher suite আর একটি ephemeral ECDHE public মান। (২) ServerHello-তে সার্ভারের মান — দুই পক্ষ একই গোপন মান হিসাব করে, যা পথে যায়নি; তা থেকে session key. (৩) সার্ভার certificate পাঠায় আর CertificateVerify-তে private key দিয়ে handshake-এ স্বাক্ষর করে। (৪) Finished — পুরো handshake-এর ওপর MAC, মাঝপথের বদল ধরা পড়ে।

Certificate যাচাই: নাম (SAN-এ example.com), মেয়াদ, বিশ্বাসের শিকল — leaf → intermediate → trust store-এর root CA, প্রতিটি স্বাক্ষর — আর বাতিলের অবস্থা (OCSP বা CRL).

Forward secrecy: session key আসে প্রতিবার নতুন ephemeral key থেকে, সার্ভারের দীর্ঘমেয়াদি private key থেকে নয়। তাই পরে সেই private key চুরি হলেও আগে রেকর্ড করা ট্রাফিক খোলা যায় না। TLS 1.3-এ সব key exchange ephemeral — পুরোনো RSA key transport বাদ।

যা থেকে রক্ষা করে না: সার্ভার নিজেই ক্ষতিকর হলে (phishing সাইটও বৈধ certificate নিতে পারে); ক্লায়েন্ট বা সার্ভারের কম্পিউটারে malware; অ্যাপের বাগ (SQL injection, XSS). মেটাডেটাও (IP, SNI) দেখা যায়।

নম্বর কোথায়: তিন নিরাপত্তা-সেবা (১), লেবেলসহ handshake (৩), ধাপের ব্যাখ্যা (২), certificate chain (২), forward secrecy (১), সীমা (১)। পর্ব ৪৭ · পর্ব ৪৮

VPN: অবিশ্বস্ত নেটওয়ার্কের (ইন্টারনেট) ওপর দিয়ে এনক্রিপ্টেড tunnel — দুই প্রান্ত যেন একই ব্যক্তিগত নেটওয়ার্কে। Site-to-site: ঢাকার হেড অফিস আর চট্টগ্রাম শাখার router-এর মাঝে স্থায়ী tunnel (IPsec বা WireGuard), কর্মীদের কিছু করতে হয় না। Remote-access: বাসা থেকে একজন কর্মী ল্যাপটপের client দিয়ে অফিসের নেটওয়ার্কে যুক্ত হন।

সীমা: VPN শুধু পথ রক্ষা করে, ক্ষতিগ্রস্ত ল্যাপটপকে নয়; এনক্রিপ্টেড ট্রাফিকের ভেতর IDS দেখে না।

নম্বর কোথায়: চারটির পার্থক্য (৪), VPN ও দুটি উদাহরণ (২)। পর্ব ৪৯ · পর্ব ৫০

(ক) SDN: প্রচলিত router-এ সিদ্ধান্ত (control plane) আর packet পাঠানো (data plane) একই যন্ত্রে। SDN দুটি আলাদা করে — একটি কেন্দ্রীয় controller পুরো নেটওয়ার্ক দেখে নিয়ম বানায়, আর switch শুধু টেবিল মেনে পাঠায়। Controller → switch কথা হয় southbound API-তে (যেমন OpenFlow), অ্যাপ → controller northbound API-তে। সুবিধা: প্রোগ্রাম দিয়ে নীতি, দ্রুত পরিবর্তন; ঝুঁকি: controller-ই single point of failure হয়ে উঠতে পারে, তাই cluster লাগে।

(খ) Leaf-spine: প্রতিটি leaf (rack-এর ওপরের switch) প্রতিটি spine-এর সাথে যুক্ত; তাই যেকোনো দুই সার্ভারের মাঝে পথ leaf → spine → leaf — সবসময় সমান দৈর্ঘ্য। সমান খরচের অনেক পথে ECMP ট্রাফিক ভাগ করে। east-west ট্রাফিক বেশি বলেই এই নকশা।

(গ) 5G: eMBB — খুব বেশি গতি (ভিডিও, ফিক্সড ওয়্যারলেস); URLLC — খুব কম latency আর উচ্চ নির্ভরযোগ্যতা (শিল্প-নিয়ন্ত্রণ); mMTC — বিপুল সংখ্যক কম-শক্তির IoT যন্ত্র। নেটওয়ার্ক slicing একই অবকাঠামোয় এদের আলাদা “টুকরো” দেয়। চলন্ত অবস্থায় এক cell থেকে আরেকে যাওয়ার নাম handover.

নম্বর কোথায়: প্রতিটিতে সংজ্ঞা, কেন দরকার, একটি উদাহরণ বা সীমা (৩ × ২)। পর্ব ৫১ · পর্ব ৫২ · পর্ব ৫৩

পদ্ধতি: নিচ থেকে ওপরে (bottom-up), প্রতিটি ধাপে একটি অনুমান যাচাই — আন্দাজে সেটিং বদল নয়। প্রথমে প্রশ্ন: একজনের সমস্যা না সবার? সব সাইট না একটি?

1. Link: তার বা Wi-Fi যুক্ত? — Linux ip link; Windows ipconfig.
2. ঠিকানা: বৈধ IP, mask, gateway পেয়েছে? 169.254.x.x (APIPA) মানে DHCP পায়নি — ip addr, ip route; ipconfig /all.
3. Gateway: ping দিয়ে gateway-এ পৌঁছায়? (ICMP বন্ধ থাকলে উত্তর না-ও আসতে পারে — মনে রাখুন।)
4. বাইরের পথ: একটি জানা বাইরের IP-তে ping বা traceroute/tracert — কোথায় থামে?
5. DNS: নাম থেকে ঠিকানা আসে? — dig example.com; nslookup example.com. IP দিয়ে চলে কিন্তু নাম দিয়ে নয় — DNS সমস্যা।
6. Transport ও application: port খোলা আর সার্ভার উত্তর দেয়? — curl -v https://example.com; PowerShell-এ Test-NetConnection example.com -Port 443. Certificate-এর ত্রুটি, proxy বা firewall এখানে ধরা পড়ে।

শেষে: দরকারে tcpdump; কারণ আর সমাধান লিখে রাখা।

নম্বর কোথায়: স্তরভিত্তিক ক্রম (২), প্রতিটি ধাপে সঠিক কমান্ড (২), ফলাফলের ব্যাখ্যা (১)। পর্ব ০৬ · পর্ব ৫৫

দুই পক্ষের যোগাযোগের নিয়মের সেট — বার্তার গঠন, প্রতিটি অংশের মানে আর কখন কী পাঠাতে হবে। যেমন HTTP: client GET পাঠায়, server status code আর body ফেরায়। নিয়ম না মানলে বার্তা বোঝা যায় না, যেমন ভিন্ন ভাষায় চিঠি।
পরের প্রশ্ন: protocol আর standard কি এক? — না; standard হলো প্রকাশিত, স্বীকৃত protocol-এর বিবরণ (যেমন IETF-এর RFC, IEEE 802.3). পর্ব ০১

জটিল কাজকে ছোট, আলাদা দায়িত্বে ভাগ করতে — প্রতিটি স্তর শুধু নিচের স্তরের সেবা নেয় আর ওপরের স্তরকে সেবা দেয়। তাই একটি স্তর বদলালে (তার থেকে Wi-Fi) বাকিগুলো বদলাতে হয় না, আর সমস্যা খোঁজা সহজ। অসুবিধা — প্রতিটি স্তরের header-এর overhead আর কখনো কখনো একই কাজ দুই স্তরে (যেমন error check).
পরের প্রশ্ন: স্তরের নিয়ম ভাঙার উদাহরণ? — NAT transport-এর port বদলায়। পর্ব ০৩

না। Internet হলো বিশ্বজুড়ে নেটওয়ার্কের নেটওয়ার্ক — IP দিয়ে জোড়া অবকাঠামো। Web সেই অবকাঠামোর ওপর চলা একটি সেবা — HTTP দিয়ে আনা, লিংকে জোড়া পেজ। ইমেইল, ভিডিও কল, অনলাইন গেমও Internet-এ চলে, কিন্তু Web নয়।
পরের প্রশ্ন: Web কে বানিয়েছিলেন? — Tim Berners-Lee, CERN-এ, ১৯৮৯–৯১ সালে। পর্ব ০১

Link-এর ক্ষমতা কাউকে আগে থেকে ভাগ করে দেওয়া হয় না; যার যখন ডেটা আছে সে তখন ব্যবহার করে। বেশিরভাগ ব্যবহারকারী বেশিরভাগ সময় চুপ, তাই একই link-এ circuit switching-এর চেয়ে অনেক বেশি ব্যবহারকারী চলে। দাম — একসাথে অনেকে পাঠালে queue আর loss.
পরের প্রশ্ন: কখন circuit ভালো? — স্থির হারের, কঠোর delay-চাহিদার ট্রাফিকে। পর্ব ০৪

Processing (header দেখা, সিদ্ধান্ত), queuing (সারিতে অপেক্ষা), transmission (L/R — বিটগুলো তারে ঠেলে দেওয়া) আর propagation (d/s — সংকেতের ভ্রমণ)। আকারের ওপর নির্ভর করে transmission; দূরত্বের ওপর propagation; ভিড়ের ওপর queuing.
পরের প্রশ্ন: traffic intensity La/R ১-এর কাছে গেলে? — গড় queuing delay খুব দ্রুত বাড়ে; ১-এর বেশি হলে queue সীমাহীন বাড়ত। পর্ব ০৫

ip addr (ঠিকানা), ip route (routing table, default gateway), ss -tulpn (শোনা TCP/UDP port আর প্রসেস)। পুরোনো ifconfig আর netstat (net-tools) অনেক distribution-এ আর ডিফল্ট থাকে না। Windows-এ ipconfig, route print, netstat -ano.
পরের প্রশ্ন: ping কী মাপে? — ICMP echo-র round-trip time আর loss. পর্ব ০৬

Nyquist (শব্দহীন): সর্বোচ্চ হার ২B log_২M — সংকেত-স্তর M বাড়ালে হার বাড়ে। Shannon (শব্দসহ): C = B log_২(১ + SNR) — কোনো encoding-ই এর বেশি নির্ভুল হার দেয় না। বাস্তব সীমা দুটির ছোটটি।
পরের প্রশ্ন: SNR dB-তে দিলে? — আগে ১০^dB/১০ দিয়ে অনুপাতে রূপান্তর। পর্ব ০৭

একক parity bit জোড়-সংখ্যক বিট উল্টালে ধরতে পারে না — parity একই থাকে। CRC বহুপদী ভাগের ভাগশেষ; r বিটের CRC r বা কম দৈর্ঘ্যের সব burst error আর (উপযুক্ত generator-এ) সব বিজোড়-সংখ্যক error ধরে, হিসাবও হার্ডওয়্যারে দ্রুত।
পরের প্রশ্ন: CRC কি error ঠিক করে? — না, শুধু ধরে; ঠিক করতে Hamming বা FEC. পর্ব ০৯

সর্বনিম্ন Hamming distance d হলে d − ১টি পর্যন্ত error নিশ্চিত ধরে, আর ⌊(d − ১)/২⌋টি পর্যন্ত ঠিক করে। যেমন d = ৩ (Hamming(7,4)) — ২টি ধরে, ১টি ঠিক করে। কারণ: ১টি error-এ পাওয়া শব্দ মূল codeword-এর সবচেয়ে কাছে থাকে, অন্যটির নয়।
পরের প্রশ্ন: m ডেটা বিটে একক error ঠিক করতে কত parity বিট? — ২^r ≥ m + r + ১-এর সবচেয়ে ছোট r. পর্ব ০৯

GBN-এ গ্রহীতা শুধু ক্রমে আসা frame নেয়; একটি হারালে প্রেরক সেখান থেকে পুরো window আবার পাঠায় — সহজ, কিন্তু অপচয়। SR-এ ক্রমের বাইরেরটিও buffer-এ থাকে, শুধু হারানোটি আবার যায় — দক্ষ, কিন্তু buffer আর প্রতিটি frame-এর timer লাগে। Window: GBN ≤ ২^k − ১, SR ≤ ২^k−১.
পরের প্রশ্ন: TCP কোনটির কাছাকাছি? — মিশ্র: cumulative ACK, কিন্তু ক্রমের বাইরের ডেটা রাখে আর SACK আছে। পর্ব ১০

Pure ALOHA-তে একটি frame নিরাপদ থাকতে দুই frame-সময়ের (vulnerable period) মধ্যে আর কেউ পাঠাতে পারবে না, তাই S = G·e^−২G, সর্বোচ্চ G = ০.৫-এ ১/(২e) ≈ ১৮.৪%. Slotted-এ পাঠানো শুধু slot-এর শুরুতে, vulnerable period অর্ধেক: S = G·e^−G, সর্বোচ্চ G = ১-এ ১/e ≈ ৩৬.৮%.
পরের প্রশ্ন: সর্বোচ্চ বিন্দু কীভাবে? — dS/dG = ০ বসিয়ে। পর্ব ১১

বিকল্প পথের জন্য switch-গুলো loop করে যুক্ত থাকে, কিন্তু Ethernet frame-এ TTL নেই — একটি broadcast চিরকাল ঘুরে নেটওয়ার্ক অচল করে (broadcast storm), আর MAC table অস্থির হয়। STP একটি root bridge বেছে কিছু port বন্ধ (blocking) রেখে loop-মুক্ত গাছ বানায়; একটি link ভাঙলে বন্ধ port খোলে। আধুনিক রূপ RSTP দ্রুত converge করে।
পরের প্রশ্ন: root bridge কীভাবে বাছা হয়? — সবচেয়ে ছোট bridge ID (priority, তারপর MAC). পর্ব ১২

VLAN একটি switch-এর port-গুলোকে যুক্তিগতভাবে আলাদা LAN-এ ভাগ করে — প্রতিটি আলাদা broadcast domain, সাধারণত আলাদা subnet; যেমন finance আর guest একই switch-এ কিন্তু আলাদা। Trunk-এ একাধিক VLAN-এর frame যায়, প্রতিটিতে ৪ বাইটের 802.1Q tag-এ ১২ বিটের VLAN ID (১–৪০৯৪ ব্যবহারযোগ্য)।
পরের প্রশ্ন: native VLAN? — trunk-এ যে VLAN-এর frame tag ছাড়া যায়; ডিফল্ট রাখা নিরাপত্তার ঝুঁকি। পর্ব ১৩

MAC (৪৮ বিট) — একই link-এ পরের hop; প্রতিটি hop-এ বদলায়। IP — শেষ গন্তব্য যন্ত্র; NAT ছাড়া বদলায় না। Port (১৬ বিট) — সেই যন্ত্রের কোন প্রসেস। উপমা: MAC পরের ডাকঘর, IP বাড়ির ঠিকানা, port বাড়ির মানুষ।
পরের প্রশ্ন: MAC কি স্থায়ী? — না; ফোন privacy-র জন্য এলোমেলো MAC নেয়। পর্ব ০৩ · পর্ব ১২

Forwarding — একটি router-এর ভেতরে, একটি packet কোন port দিয়ে বের হবে তা টেবিল দেখে ঠিক করা; nanosecond–microsecond-এর কাজ, data plane. Routing — পুরো নেটওয়ার্কে পথ হিসাব করে সেই টেবিল বানানো; সেকেন্ডের কাজ, control plane (OSPF, BGP).
পরের প্রশ্ন: SDN এখানে কী বদলায়? — control plane যন্ত্র থেকে সরিয়ে controller-এ নেয়। পর্ব ১৫

একটি বড় ঠিকানা-ব্লককে ছোট নেটওয়ার্কে ভাগ করতে — broadcast domain ছোট হয়, বিভাগ আলাদা করে নিরাপত্তার নিয়ম বসানো যায়, ঠিকানা নষ্ট কম হয়, আর routing table-এ সারাংশ (summarisation) সহজ।
পরের প্রশ্ন: /26-এ কতটি host? — ৬টি host বিট, ২^৬ − ২ = ৬২. পর্ব ১৭

/27-এ mask 255.255.255.224, block size ২৫৬ − ২২৪ = ৩২. ৭৭ পড়ে ৬৪–৯৫ ব্লকে: network 192.168.5.64, broadcast 192.168.5.95, usable .65–.94.
পরের প্রশ্ন: একই হিসাব binary-তে? — শেষ octet ৭৭ = 01001101; mask 11100000; AND = 01000000 = ৬৪. পর্ব ১৭

নিজের IP আর গন্তব্য IP দুটিকেই নিজের subnet mask দিয়ে AND করে; ফল সমান হলে একই subnet — সরাসরি ARP করে পাঠায়। না হলে packet যায় default gateway-তে — LAN-এর সেই router interface, যা বাইরের পথ জানে।
পরের প্রশ্ন: gateway ভুল সেট করা থাকলে? — LAN-এর ভেতরে সব চলবে, বাইরে কিছুই নয়। পর্ব ২২

Host broadcast-এ জিজ্ঞেস করে “IP X কার?”, মালিক unicast-এ নিজের MAC জানায়; উত্তর ARP cache-এ কিছুক্ষণ থাকে। Gratuitous ARP — কেউ না চাইতেই নিজের IP–MAC ঘোষণা; নতুন যন্ত্রে ঠিকানার দ্বন্দ্ব ধরতে বা failover-এর পর সবার cache হালনাগাদে।
পরের প্রশ্ন: ARP spoofing ঠেকাবেন কীভাবে? — switch-এ dynamic ARP inspection (DHCP snooping-এর টেবিল ধরে), আর উপরের স্তরে TLS. পর্ব ১৮

Discover (client broadcast), Offer (সার্ভারের প্রস্তাব), Request (client নির্দিষ্ট প্রস্তাব চায়), Ack (সার্ভার নিশ্চিত করে)। Request broadcast, যাতে একাধিক সার্ভার থাকলে বাকিরা জানে তাদের প্রস্তাব নেওয়া হয়নি আর ঠিকানাটি ফেরত নেয়। DHCP UDP-তে চলে — সার্ভার port 67, client 68.
পরের প্রশ্ন: সার্ভার অন্য subnet-এ হলে? — router-এ DHCP relay. পর্ব ১৮

Router-এ private ঠিকানা আর port-কে public ঠিকানা আর port-এ বদলানো (PAT), টেবিলে মনে রেখে উত্তর ফেরত পাঠানো। বাইরে থেকে অনাহূত সংযোগ ঢুকতে পারে না — এটি পার্শ্বফল, নিরাপত্তার নকশা নয়; নিয়ন্ত্রণ আর লগের জন্য আসল firewall লাগে।
পরের প্রশ্ন: CGNAT কী? — ISP-র স্তরে NAT, অনেক গ্রাহক একটি public IP ভাগ করে। পর্ব ১৯

ICMP হলো IP-র সহকারী বার্তা — ত্রুটি (destination unreachable, time exceeded) আর অনুসন্ধান (echo). Ping echo request পাঠিয়ে echo reply-র সময় মাপে। Traceroute TTL ১, ২, ৩… দিয়ে packet পাঠায়; প্রতিটি router TTL শূন্য হলে “time exceeded” ফেরত দেয়, ফলে প্রতিটি hop-এর ঠিকানা আর সময় জানা যায়।
পরের প্রশ্ন: Linux আর Windows-এর traceroute-এ পার্থক্য? — Linux ডিফল্টে UDP probe, Windows-এর tracert ICMP echo. পর্ব ২০

ঠিকানা ১২৮ বিট (৩২-এর বদলে) — NAT ছাড়াই প্রচুর ঠিকানা; স্থির ৪০ বাইটের সরল header, checksum নেই, router fragment করে না; broadcast নেই — multicast, আর ARP-এর বদলে Neighbor Discovery; SLAAC-এ যন্ত্র নিজেই ঠিকানা বানাতে পারে।
পরের প্রশ্ন: fe80:: দিয়ে শুরু ঠিকানা কী? — link-local, প্রতিটি interface-এ থাকে, router পার হয় না। পর্ব ২১

Routing table-এ একাধিক entry মিললে সবচেয়ে লম্বা prefix-এর (সবচেয়ে নির্দিষ্ট) route জেতে। টেবিলে 10.0.0.0/8 → A আর 10.1.2.0/24 → B থাকলে 10.1.2.9 যায় B-তে, 10.9.9.9 যায় A-তে; কিছু না মিললে 0.0.0.0/0 (default route).
পরের প্রশ্ন: হার্ডওয়্যারে এত দ্রুত কীভাবে? — TCAM বা trie-ভিত্তিক lookup. পর্ব ২২

RIP — distance vector, metric শুধু hop count (১৫ পর্যন্ত, ১৬ = অসীম), প্রতিবেশীকে পুরো টেবিল পাঠায়, ধীর convergence. OSPF — link state, link-এর cost (সাধারণত bandwidth থেকে), পুরো মানচিত্রে Dijkstra, দ্রুত convergence আর area দিয়ে বড় নেটওয়ার্ক।
পরের প্রশ্ন: OSPF কোন transport নেয়? — কোনোটিই না; সরাসরি IP-র ওপর, protocol নম্বর 89. পর্ব ২৩ · পর্ব ২৪

পুরো বড় নেটওয়ার্কের প্রতিটি link-এর খবর সবাইকে flood করলে LSDB বিশাল হয় আর প্রতিটি পরিবর্তনে সবাই Dijkstra চালায়। Area-তে ভাগ করলে বিস্তারিত তথ্য area-র ভেতরে থাকে, বাইরে যায় সারাংশ; সব area যুক্ত থাকে backbone area 0-এর সাথে, সংযোগস্থলে ABR.
পরের প্রশ্ন: DR কেন? — broadcast LAN-এ সবার সাথে সবার adjacency-র বদলে একজন প্রতিনিধি, flooding কম। পর্ব ২৪

BGP শুধু দূরত্ব নয়, গন্তব্য পর্যন্ত পুরো AS-এর তালিকা (AS_PATH) পাঠায়। এতে loop সহজে ধরা যায় — নিজের AS নম্বর পথে দেখলে বাতিল — আর নীতি অনুযায়ী পথ বাছা যায়। BGP TCP port 179-এ চলে।
পরের প্রশ্ন: route hijack কী? — কেউ অন্যের prefix নিজের বলে ঘোষণা করা; প্রতিরক্ষা RPKI-ভিত্তিক origin যাচাই আর prefix filter. পর্ব ২৫

Unicast — এক থেকে এক; broadcast — এক থেকে LAN-এর সবাই; multicast — এক থেকে যারা একটি দলে যোগ দিয়েছে (IPTV); anycast — একই ঠিকানা অনেক জায়গায়, packet যায় কাছেরটিতে (DNS root, CDN). QoS-এ VoIP packet-কে DSCP EF চিহ্ন দিয়ে আলাদা, অগ্রাধিকারের queue-তে রাখা হয়, যাতে বড় download-এর ভিড়েও delay আর jitter কম থাকে।
পরের প্রশ্ন: multicast group-এ যোগ দেয় কীভাবে? — IPv4-এ IGMP, IPv6-এ MLD. পর্ব ২৬

Port একটি ১৬ বিটের সংখ্যা; socket হলো প্রসেসের হাতে থাকা যোগাযোগের প্রান্ত (OS-এর একটি object). একটি TCP সংযোগ চেনা যায় চারটি মানে — source IP, source port, destination IP, destination port; তাই একই সার্ভার port 443-এ হাজার সংযোগ আলাদা থাকে।
পরের প্রশ্ন: well-known port কোনগুলো? — ০–১০২৩; যেমন 22 SSH, 53 DNS, 80 HTTP, 443 HTTPS. পর্ব ২৭

দুই দিকেরই ISN জানাতে আর নিশ্চিত হতে হয় — client-এর ACK ছাড়া server জানে না তার SYN পৌঁছেছে। তা ছাড়া দেরিতে আসা পুরোনো SYN-এ দুই ধাপে server ভুয়া সংযোগ খুলত; তৃতীয় ধাপে client তা বাতিল করতে পারে।
পরের প্রশ্ন: ISN এলোমেলো কেন? — পুরোনো সংযোগের segment গুলিয়ে যাওয়া আর অনুমান করে নকল segment ঢোকানো ঠেকাতে। পর্ব ২৯

না। Flow control গ্রহীতাকে বাঁচায় — গ্রহীতা rwnd-এ জানায় কতটা নিতে পারবে। Congestion control নেটওয়ার্ককে বাঁচায় — প্রেরক loss বা delay থেকে cwnd অনুমান করে। প্রেরক পাঠায় min(rwnd, cwnd).
পরের প্রশ্ন: rwnd শূন্য হলে? — প্রেরক থামে আর persist timer দিয়ে মাঝে মাঝে window probe পাঠায়। পর্ব ৩১

না — প্রতি RTT-তে cwnd দ্বিগুণ, অর্থাৎ exponential বৃদ্ধি। “Slow” কারণ শুরু ১ (আজকের Linux-এ সাধারণত ১০) segment থেকে, পুরো window একবারে ছেড়ে দেওয়ার বদলে। ssthresh ছুঁলে বৃদ্ধি রৈখিক হয়।
পরের প্রশ্ন: initial window বড় করা হলো কেন? — ছোট ওয়েব-অনুরোধ যেন কম RTT-তে শেষ হয়। পর্ব ৩২

Duplicate ACK আসা মানে পরের segment-গুলো পৌঁছাচ্ছে — একটি হারিয়েছে, কিন্তু পথ চলছে; তাই ssthresh = cwnd/২ আর cwnd অর্ধেক (fast recovery). Timeout মানে কিছুই আসছে না — হয়তো গুরুতর জ্যাম; তাই cwnd = ১, আবার slow start.
পরের প্রশ্ন: তিনটিই কেন, একটি নয়? — একটি-দুটি duplicate ACK শুধু ক্রম উল্টানোতেও আসে। পর্ব ৩২

RTT পথ আর ভিড়ভেদে অনেক বদলায় — স্থির RTO ছোট হলে অকারণ retransmission, বড় হলে দীর্ঘ অপেক্ষা। তাই RTO = SRTT + ৪ × RTTVAR, চলমান গড় থেকে। Karn: retransmit করা segment-এর RTT নমুনা নেওয়া হয় না, আর timeout-এ RTO দ্বিগুণ।
পরের প্রশ্ন: timestamps option-এর সুবিধা? — retransmit-এর পরেও RTT মাপা যায়। পর্ব ৩০

নতুন transport সরাসরি IP-র ওপর বানালে পথের firewall আর NAT চিনত না, আর TCP OS-এর kernel-এ — বদলাতে বছরের পর বছর। UDP সব জায়গায় পার হয়, আর QUIC user space-এ দ্রুত হালনাগাদ হয়। QUIC নিজেই নির্ভরযোগ্যতা, congestion control আর TLS 1.3 দেয়; প্রতিটি stream আলাদা বলে একটি হারানো packet শুধু তার stream আটকায় — TCP-র head-of-line blocking নেই।
পরের প্রশ্ন: connection migration? — Wi-Fi থেকে মোবাইল ডেটায় গেলে IP বদলালেও connection ID দিয়ে সংযোগ চলে। পর্ব ৩৩

দুটিই, port 53. সাধারণ query UDP-তে — এক প্রশ্ন, এক উত্তর, handshake-এর খরচ নেই। উত্তর বড় হলে (truncated flag) আবার TCP-তে, আর zone transfer TCP-তে। DNS over TLS port 853, DNS over HTTPS port 443.
পরের প্রশ্ন: EDNS কী করে? — UDP-তে ৫১২ বাইটের পুরোনো সীমার চেয়ে বড় উত্তর পাঠানোর ব্যবস্থা। পর্ব ৩৫

সার্ভার Set-Cookie-এ একটি session ID দেয়, ব্রাউজার পরের প্রতিটি request-এ Cookie-তে ফেরত পাঠায়; সার্ভার ID দেখে নিজের ডেটাবেসে cart খোঁজে। বিকল্প — token (যেমন Authorization header-এ)।
পরের প্রশ্ন: HttpOnly কেন? — JavaScript cookie পড়তে পারে না, তাই XSS-এ session চুরি কঠিন হয়। পর্ব ৩৬

GET তথ্য চায়, নিরাপদ আর idempotent, cache হতে পারে, প্যারামিটার URL-এ; POST কিছু পাঠায় বা বদলায়, idempotent নয়, ডেটা body-তে। 301 — স্থায়ীভাবে অন্য ঠিকানায়; 304 — বদলায়নি, cache-এর কপি চালান; 404 — নেই; 503 — সার্ভার সাময়িকভাবে সেবা দিতে পারছে না।
পরের প্রশ্ন: POST কি GET-এর চেয়ে নিরাপদ? — শুধু URL আর log-এ কম দেখা যায়; গোপনীয়তা দেয় HTTPS. পর্ব ৩৬

HTTP/1.1 — লেখা (text) বার্তা, একটি সংযোগে একসাথে একটি অনুরোধ, তাই ব্রাউজার কয়েকটি সংযোগ খোলে। HTTP/2 — binary frame, একটি TCP সংযোগে অনেক stream একসাথে, header compression (HPACK); কিন্তু TCP-র একটি loss সব stream আটকায়। HTTP/3 — একই ধারণা QUIC-এর ওপর (UDP), header compression QPACK, stream-ভিত্তিক loss-সামলানো।
পরের প্রশ্ন: HTTP/2-এ domain sharding কেন অপ্রয়োজনীয়? — এক সংযোগেই multiplexing. পর্ব ৩৭

কনটেন্টের কপি ব্যবহারকারীর কাছের অনেক edge সার্ভারে রাখার নেটওয়ার্ক। RTT ছোট হয়, মূল সার্ভারে চাপ কমে, আর DDoS-এর ধাক্কা অনেক জায়গায় ভাগ হয়। ব্যবহারকারীকে কাছের edge-এ পাঠানো হয় DNS বা anycast দিয়ে।
পরের প্রশ্ন: কনটেন্ট বদলালে? — TTL শেষ হওয়া, purge, বা ফাইলের নামে version (cache busting). পর্ব ৩৮

SMTP মেইল পাঠায় — client থেকে সার্ভারে আর সার্ভার থেকে সার্ভারে (push). IMAP দিয়ে মেইল সার্ভারে রেখেই পড়া, ফোল্ডার আর একাধিক যন্ত্রে মিল। POP3 সাধারণত মেইল নামিয়ে নেয়, পুরোনো ধাঁচ।
পরের প্রশ্ন: SPF, DKIM, DMARC কী? — কোন সার্ভার পাঠাতে পারে (SPF), বার্তায় ডোমেইনের স্বাক্ষর (DKIM), আর দুটি ব্যর্থ হলে গ্রাহক কী করবে তার নীতি (DMARC) — নকল প্রেরক ঠেকাতে। পর্ব ৩৯

Jitter — packet-গুলোর delay-এর ওঠানামা। গ্রহীতা কিছুক্ষণ জমিয়ে (playout delay) তারপর সমান ফাঁকে বাজায় — buffer বড় হলে কম কাটা কাটা কিন্তু বেশি দেরি। একমুখী delay প্রায় ১৫০ ms-এর নিচে হলে কথা স্বাভাবিক লাগে বলে ধরা হয়।
পরের প্রশ্ন: হারানো packet আবার চাওয়া হয় না কেন? — দেরিতে এলে কাজে লাগে না; তাই UDP/RTP আর loss concealment. পর্ব ৪০

socket → bind (IP, port) → listen → accept (নতুন সংযুক্ত socket ফেরত দেয়) → recv/send → close. Client: socket → connect → send/recv → close.
পরের প্রশ্ন: সার্ভার আবার চালু করলে “Address already in use”? — আগের সংযোগের TIME_WAIT; SO_REUSEADDR দিয়ে bind করা যায়। পর্ব ৪১

নিশ্চিত নয় — TCP byte stream, বার্তার সীমা রাখে না; recv কম বা একাধিক send মিলিয়ে বেশি দিতে পারে। তাই অ্যাপকে নিজে framing করতে হয় — দৈর্ঘ্যের prefix বা delimiter (যেমন HTTP-তে CRLF আর Content-Length), আর লুপে পড়া। UDP-তে প্রতিটি recvfrom একটি পুরো datagram দেয়।
পরের প্রশ্ন: recv 0 ফেরত দিলে? — অপর পক্ষ সংযোগ বন্ধ করেছে (FIN). পর্ব ৪১ · পর্ব ৪২

তিনটিই এক থ্রেডে অনেক socket-এর প্রস্তুতি দেখে। select — fd-এর একটি নির্দিষ্ট আকারের সেট (প্রায়ই ১০২৪ সীমা), প্রতিবার পুরো সেট kernel-এ কপি আর স্ক্যান। poll — সীমা নেই, কিন্তু তবু প্রতিবার পুরো তালিকা স্ক্যান, O(n). epoll (Linux) — আগ্রহের তালিকা kernel-এ একবার, প্রস্তুত হলে শুধু প্রস্তুতগুলো ফেরত — হাজার সংযোগে দক্ষ।
পরের প্রশ্ন: অন্য OS-এ? — BSD/macOS-এ kqueue, Windows-এ IOCP. পর্ব ৪৪

fork-per-client — সরল, বিচ্ছিন্ন, কিন্তু প্রতিটি প্রসেস ভারী। Thread pool — নির্দিষ্ট থ্রেডে কাজ ভাগ, CPU-ভারী কাজে ভালো, shared ডেটায় lock লাগে। Event loop (epoll) — এক থ্রেডে হাজার নিষ্ক্রিয় সংযোগ, I/O-ভারী কাজে সেরা, কিন্তু একটি আটকানো কাজ সবাইকে আটকায়। nginx: কয়েকটি worker, প্রতিটিতে event loop.
পরের প্রশ্ন: C10K কী? — এক সার্ভারে দশ হাজার একসাথে সংযোগের চ্যালেঞ্জ। পর্ব ৪৩ · পর্ব ৪৪

Confidentiality — অনুমতি ছাড়া কেউ পড়তে পারবে না (TLS-এ এনক্রিপশন); Integrity — অনুমতি ছাড়া বদলানো যাবে না বা বদলালে ধরা পড়বে (MAC, স্বাক্ষর); Availability — দরকারের সময় সেবা পাওয়া যাবে (DDoS প্রতিরক্ষা, redundant link).
পরের প্রশ্ন: authentication কোথায়? — CIA-র বাইরে কিন্তু সমান জরুরি — কে কথা বলছে তার প্রমাণ। পর্ব ৪৬

Symmetric (যেমন AES) — একই key দুই পাশে, খুব দ্রুত, কিন্তু key আগে নিরাপদে ভাগ করার সমস্যা। Asymmetric (RSA, elliptic curve) — public আর private key-র জোড়া, key ভাগের সমস্যা মেটায় আর স্বাক্ষর দেয়, কিন্তু ধীর। তাই hybrid: asymmetric দিয়ে key exchange আর পরিচয়, তারপর symmetric দিয়ে আসল ডেটা — TLS ঠিক এটিই করে।
পরের প্রশ্ন: Diffie-Hellman কী দেয়? — খোলা পথে কথা বলেও দুই পক্ষের একটি গোপন মান, যা পথে কখনো যায় না। পর্ব ৪৭

Encryption উল্টানো যায় (key থাকলে); cryptographic hash একমুখী, স্থির দৈর্ঘ্যের “আঙুলের ছাপ” — ফেরানো যায় না। Signature: বার্তার hash প্রেরক নিজের private key দিয়ে স্বাক্ষর করে; যে কেউ public key দিয়ে যাচাই করে — বার্তা বদলায়নি আর প্রেরক private key-র মালিক।
পরের প্রশ্ন: পাসওয়ার্ড শুধু SHA-256-এ রাখা কেন খারাপ? — দ্রুত hash-এ অনুমান-আক্রমণ সহজ; salt-সহ ধীর password hash (bcrypt, Argon2) লাগে। পর্ব ৪৭

Firewall নিয়ম অনুযায়ী (IP, port, অবস্থা) ট্রাফিক ঢুকতে বা বেরোতে দেয় বা আটকায়। IDS ট্রাফিকের কপি দেখে সন্দেহজনক কিছু পেলে শুধু সতর্ক করে। IPS পথের মাঝে বসে নিজেই আটকায় — দ্রুত প্রতিরক্ষা, কিন্তু ভুল ইতিবাচকে বৈধ ট্রাফিকও আটকাতে পারে।
পরের প্রশ্ন: signature-based আর anomaly-based? — চেনা আক্রমণের ছাপ মেলানো বনাম স্বাভাবিক আচরণ থেকে বিচ্যুতি ধরা। পর্ব ৪৯ · পর্ব ৫০

যা স্পষ্টভাবে অনুমোদিত নয় তা আটকানো — শেষ নিয়ম “বাকি সব drop”; উল্টোটি (সব খোলা, কিছু বন্ধ) ভুলে যাওয়া port খোলা রেখে দেয়। DMZ — বাইরের জন্য খোলা সার্ভারগুলোর (ওয়েব, মেইল) আলাদা অঞ্চল; সেখানে কেউ ঢুকে পড়লেও ভেতরের নেটওয়ার্কে সরাসরি যেতে পারে না।
পরের প্রশ্ন: stateful firewall ফেরত ট্রাফিক কীভাবে চেনে? — connection tracking table. পর্ব ৪৯

অবিশ্বস্ত নেটওয়ার্কের ওপর এনক্রিপ্টেড tunnel, যাতে দূরের যন্ত্র বা শাখা যেন একই ব্যক্তিগত নেটওয়ার্কে। IPsec — network স্তরে, পুরোনো ও বহুল প্রচলিত মানক, IKE দিয়ে key বিনিময়, অনেক বিকল্প বলে কনফিগারেশন জটিল। WireGuard — ছোট কোডবেস, নির্দিষ্ট আধুনিক cryptography, UDP-তে চলে, Linux kernel-এ অন্তর্ভুক্ত।
পরের প্রশ্ন: split tunnelling? — শুধু অফিসের ট্রাফিক tunnel-এ, বাকিটা সরাসরি ইন্টারনেটে। পর্ব ৪৯

আক্রমণকারী (প্রায়ই নকল উৎস-ঠিকানায়) অনেক SYN পাঠায়, handshake শেষ করে না; অর্ধেক-খোলা সংযোগের সারি ভরে বৈধ client আটকায়। প্রতিরক্ষা: SYN cookie (state না রেখে তথ্য ISN-এ), rate limiting, বড় আক্রমণে upstream scrubbing বা CDN.
পরের প্রশ্ন: ingress filtering? — ISP নকল উৎস-ঠিকানার packet বেরোতে দেয় না। পর্ব ৫০

এলাকা ছোট ছোট cell-এ ভাগ, প্রতিটিতে একটি base station; একই frequency দূরের cell-এ আবার ব্যবহার হয়। চলন্ত ফোন সংকেত মেপে এক cell থেকে আরেকে চলে যায় — handover, কথা না কেটে। 5G-তে নতুন radio (NR, বেশি bandwidth, mmWave পর্যন্ত), service-based core, আর তিন ব্যবহার-শ্রেণি — eMBB, URLLC, mMTC; network slicing.
পরের প্রশ্ন: NSA আর SA 5G? — NSA-তে 4G core-এর ওপর 5G radio; SA-তে নিজস্ব 5G core. পর্ব ৫১

Data center-এ সার্ভারে-সার্ভারে (east-west) ট্রাফিক বেশি। Leaf-spine-এ প্রতিটি leaf সব spine-এর সাথে যুক্ত, তাই যেকোনো দুই rack-এর মাঝে পথ সমান (leaf-spine-leaf), ECMP-তে অনেক পথে ভার ভাগ, আর spine যোগ করে ক্ষমতা বাড়ানো যায়। একটি spine পড়লে ক্ষমতা কিছুটা কমে, সংযোগ থাকে।
পরের প্রশ্ন: oversubscription? — leaf-এর সার্ভার-দিকের মোট bandwidth আর spine-দিকের মোট bandwidth-এর অনুপাত, যেমন ৩:১. পর্ব ৫২

না। SDN control plane-কে switch থেকে সরিয়ে কেন্দ্রীয় controller-এ নেয় — নেটওয়ার্ক প্রোগ্রাম করা যায়। NFV নেটওয়ার্কের কাজকে (firewall, load balancer, mobile core) বিশেষ হার্ডওয়্যার থেকে সাধারণ সার্ভারের virtual machine বা container-এ আনে। দুটি একসাথে চলে, কিন্তু একটি অন্যটি ছাড়াও সম্ভব।
পরের প্রশ্ন: OpenFlow-এ switch অজানা packet পেলে? — table-miss নিয়ম অনুযায়ী, প্রায়ই controller-কে packet-in পাঠায়। পর্ব ৫৩

VPC — cloud-এর ভেতরে নিজের যুক্তিগত নেটওয়ার্ক, নিজের ঠিকানা-পরিসর, subnet আর route table; security group — প্রতিটি instance-এর stateful firewall নিয়ম। Docker-এর ডিফল্ট bridge-এ container পায় একটি private ঠিকানা; বাইরে যেতে host NAT (masquerade) করে, আর বাইরে থেকে আসতে port publish (-p 8080:80).
পরের প্রশ্ন: Kubernetes Service কী সমস্যা মেটায়? — pod-এর ঠিকানা বদলায়; Service একটি স্থির ঠিকানা আর load balancing দেয়। পর্ব ৫৪

লক্ষণ স্পষ্ট করা (কে, কবে থেকে, কী বদলেছে), তারপর স্তর ধরে — bottom-up (link → IP → gateway → বাইরের পথ → DNS → port → application), বা মাঝখান থেকে (ping দিয়ে) ভাগ করে খোঁজা (divide and conquer). প্রতিটি ধাপে একটি অনুমান, একটি যাচাই; একবারে একটি পরিবর্তন; শেষে কারণ লিখে রাখা।
পরের প্রশ্ন: ping হয় কিন্তু ওয়েবসাইট খোলে না? — DNS, port, firewall বা application স্তর দেখুন: dig, curl -v. পর্ব ৫৫

পথের অন্য কোথাও bottleneck (ISP, সার্ভার নিজে); RTT বড় অথচ window ছোট — throughput ≈ window/RTT; packet loss — Mathis সূত্র অনুযায়ী loss বাড়লে TCP-র throughput মোটামুটি ১/√p অনুপাতে কমে; অথবা সার্ভারের ডিস্ক বা CPU. যাচাই: iperf3 দিয়ে মাপা, ss -ti-তে cwnd, rtt আর retransmit দেখা, ভিন্ন সার্ভারে তুলনা।
পরের প্রশ্ন: একাধিক সমান্তরাল সংযোগে দ্রুত হলে কী বোঝায়? — এক সংযোগের window বা loss-ই সীমা। পর্ব ৩২ · পর্ব ৫৬

যন্ত্র কেনা বা subnet ভাগ নয় — প্রয়োজন সংগ্রহ: কতজন মানুষ ও যন্ত্র, কোন অ্যাপ, কত বৃদ্ধি, কতক্ষণ বন্ধ থাকা চলে, নিরাপত্তার চাহিদা, বাজেট। তারপর VLAN ও zone, VLSM-এ ঠিকানা, redundancy, firewall নীতি, monitoring আর লিখিত নথি।
পরের প্রশ্ন: single point of failure কীভাবে খুঁজবেন? — নকশার প্রতিটি যন্ত্র আর link একে একে “বন্ধ” ধরে দেখা কী থামে। পর্ব ৫৭