নেটওয়ার্কিং ইন্টারভিউর প্রশ্ন — ধারণা থেকে বাস্তব সিস্টেম

উত্তর: বানিয়ে বলবেন না। সৎভাবে সীমা বলুন, তারপর যা জানেন তা থেকে যুক্তি দিন, আর কীভাবে খুঁজে বের করবেন বলুন: “BGP-র ঠিক কোন attribute আগে তুলনা হয় তা নিশ্চিত মনে নেই। যা জানি — local preference AS-এর ভেতরে বেরোনোর পথ ঠিক করে, AS path ছোট হলে পছন্দ… নিশ্চিত হতে vendor-এর ডকুমেন্টেশন আর RFC 4271 দেখতাম, আর lab-এ দুটি route দিয়ে পরীক্ষা করতাম।”

ফলো-আপ: “তাহলে আন্দাজ করুন।” → আন্দাজকে আন্দাজ বলেই দিন, আর যুক্তিটি বলুন — ইন্টারভিউয়ার আসলে আপনার চিন্তার ধরন দেখছেন।

আরও গভীর ফলো-আপ: “Production-এ এমন হলে?” → “কেউ জানে না” অবস্থায় runbook, ডকুমেন্টেশন আর অভিজ্ঞ সহকর্মীর কাছে escalation-ই পেশাদার পথ; আত্মবিশ্বাসী ভুল সিদ্ধান্ত outage বড় করে।

উত্তর: তিনটি জিনিস: মূল পার্থক্য, তার দাম, আর একটি করে উদাহরণ। “TCP সংযোগ বানিয়ে ক্রমমতো, নির্ভরযোগ্য byte stream দেয়, flow আর congestion control-সহ; দাম handshake-এর দেরি আর হারানো প্যাকেটে অপেক্ষা। UDP শুধু datagram পাঠায় — সংযোগ নেই, নিশ্চয়তা নেই, কিন্তু হালকা আর দেরি কম। ওয়েব আর ফাইল-স্থানান্তরে TCP; DNS-এর ছোট প্রশ্ন, VoIP আর গেমে UDP; আর QUIC UDP-র ওপর নিজের নির্ভরযোগ্যতা বানায়।”

ফলো-আপ: “UDP-তে কি কখনো নির্ভরযোগ্যতা লাগে?” → হ্যাঁ, তখন application বা QUIC নিজে sequence, ACK আর retransmission যোগ করে (প্র ২২)।

আরও গভীর ফলো-আপ: “DNS কি শুধু UDP?” → না; বড় উত্তর, zone transfer আর DNS-over-TLS-এ TCP লাগে, আর TCP সমর্থন DNS-এর বাধ্যতামূলক অংশ (RFC 7766).

উত্তর: বাস্তব ইন্টারনেট চলে TCP/IP মডেলে, কিন্তু OSI-র নম্বরগুলো আলোচনার সাধারণ ভাষা — “L2 সমস্যা”, “L7 load balancer” বললে সবাই বোঝে। Switch মূলত L2 (MAC দেখে frame পাঠায়), router L3 (IP দেখে), সাধারণ firewall L3/L4 (ঠিকানা, port, অবস্থা), আর load balancer L4 (TCP/UDP সংযোগ) বা L7 (HTTP-র path, header) — কোনটি তা নির্ভর করে সে কী দেখে সিদ্ধান্ত নেয় তার ওপর।

ফলো-আপ: “TLS কোন স্তরে?” → TCP আর HTTP-র মাঝে; OSI-র কোনো একটি ঘরে পরিষ্কার বসে না — এই প্রশ্নে “মডেল একটি মানচিত্র, ভূখণ্ড নয়” বলাই ভালো উত্তর।

আরও গভীর ফলো-আপ: “Layer 3 switch তাহলে কী?” → hardware-এ (ASIC) routing করে এমন switch — VLAN-এর মধ্যে routing করে; নাম মার্কেটিংয়ের, কাজটি router-এরই।

উত্তর: L2 পুরোটা নতুন হয়: পুরোনো Ethernet frame খুলে ফেলা হয় (decapsulation), আর পরের link-এর জন্য নতুন উৎস-MAC (router-এর বেরোনোর interface) আর গন্তব্য-MAC (next hop) দিয়ে নতুন frame বানানো হয় (encapsulation). IP header-এ TTL এক কমে, তাই IPv4 header checksum আবার হিসাব হয়। উৎস আর গন্তব্য IP একই থাকে।

ফলো-আপ: “কখন IP-ও বদলায়?” → NAT থাকলে (উৎস IP আর port, প্র ০৯)। আর MTU ছোট হলে IPv4-এ fragmentation (DF না থাকলে)।

আরও গভীর ফলো-আপ: “IPv6-এ কী আলাদা?” → header checksum নেই, তাই শুধু Hop Limit কমে; router fragment করে না — বড় প্যাকেটে ICMPv6 “Packet Too Big” ফেরত পাঠায়।

উত্তর: তিনটি তিন প্রশ্নের উত্তর দেয়: MAC — “এই link-এ কোন যন্ত্র?”, IP — “পৃথিবীর কোন নেটওয়ার্কের কোন host?”, port — “সেই host-এর কোন প্রোগ্রাম?”। MAC সমতল (flat) — নির্মাতা অনুযায়ী দেওয়া, অবস্থান বোঝায় না; তাই শুধু MAC দিয়ে routing করতে প্রতিটি router-কে পৃথিবীর সব যন্ত্রের তালিকা রাখতে হতো। IP-র prefix অবস্থান বোঝায়, তাই একটি route পুরো নেটওয়ার্ক ঢাকে।

ফলো-আপ: “ডাকঘরের উদাহরণে?” → জেলা-থানা-গলি (IP prefix), বাড়ির নম্বর (host), আর বাড়ির কোন সদস্য (port); পাশের বাড়ির হাতে চিঠি তুলে দেওয়া (MAC) শুধু শেষ ধাপে।

আরও গভীর ফলো-আপ: “ফোনের MAC বারবার বদলায় কেন?” → গোপনীয়তার জন্য অনেক OS Wi-Fi-তে এলোমেলো MAC ব্যবহার করে; তাই MAC দিয়ে যন্ত্র চেনা বা DHCP reservation এখন কম নির্ভরযোগ্য।

উত্তর: চার ধাপ — DORA: Discover (client broadcast), Offer (server ঠিকানা প্রস্তাব করে), Request (client একটি offer বেছে নেয়), Ack (server নিশ্চিত করে, সাথে mask, gateway, DNS আর lease-এর মেয়াদ)। Client-এর তখনো কোনো IP নেই, server-এর ঠিকানাও জানে না — তাই উৎস 0.0.0.0, গন্তব্য 255.255.255.255, UDP port 68 থেকে 67. ঠিকানা 169.254.x.x মানে কোনো server উত্তর দেয়নি, আর OS নিজে link-local ঠিকানা নিয়েছে (APIPA) — ইন্টারনেট চলবে না।

ফলো-আপ: “Server অন্য subnet-এ থাকলে broadcast পৌঁছাবে কীভাবে?” → router-এ DHCP relay (Cisco-তে ip helper-address) broadcast ধরে server-এ unicast করে, আর giaddr দেখে server ঠিক pool বাছে।

আরও গভীর ফলো-আপ: “অফিসে কেউ নিজের router লাগিয়ে দিল, সবার ঠিকানা ভুল আসছে।” → rogue DHCP server; প্রতিরক্ষা switch-এ DHCP snooping — শুধু uplink port-কে trusted রাখা।

উত্তর: অ্যাপ OS-এর stub resolver-কে জিজ্ঞেস করে (আগে /etc/hosts আর cache). Stub একটি recursive resolver-কে (ISP-এর, অফিসের বা public) recursive প্রশ্ন করে — “পুরো উত্তর এনে দিন”। Resolver cache-এ না পেলে iterative পথে হাঁটে: root server → .com-এর TLD server → example.com-এর authoritative server; প্রতিটি শুধু “পরের জনকে জিজ্ঞেস করুন” (referral) দেয়। শেষ উত্তর TTL পর্যন্ত cache-এ থাকে।

ফলো-আপ: “TTL কম রাখলে লাভ-ক্ষতি?” → পরিবর্তন দ্রুত ছড়ায়, কিন্তু resolver বেশি প্রশ্ন পাঠায় — দেরি আর authoritative-এর ভার বাড়ে (প্র ৪৯)।

আরও গভীর ফলো-আপ: “নাম না থাকলে সেই ‘নেই’ উত্তরও কি cache হয়?” → হ্যাঁ, negative caching — SOA রেকর্ড অনুযায়ী (RFC 2308). তাই নতুন রেকর্ড বানানোর আগে কেউ জিজ্ঞেস করে থাকলে কিছুক্ষণ NXDOMAIN-ই আসতে পারে।

উত্তর: A — IPv4 ঠিকানা; AAAA — IPv6; CNAME — “এই নামটি আসলে অন্য নামের ডাকনাম”; MX — মেইল কোন server নেবে (অগ্রাধিকারসহ); NS — zone-এর authoritative server কারা; TXT — মুক্ত লেখা, বাস্তবে SPF, DKIM, DMARC আর domain-মালিকানা যাচাইয়ে। CNAME থাকলে সেই নামে অন্য কোনো রেকর্ড রাখা যায় না; অথচ apex-এ (example.com) NS আর SOA বাধ্যতামূলক — তাই apex-এ CNAME নিষেধ।

ফলো-আপ: “CDN-এর নাম তাহলে apex-এ কীভাবে বসায়?” → অনেক DNS সেবা ALIAS/ANAME বা CNAME flattening দেয় — server নিজে লক্ষ্যটি resolve করে A/AAAA উত্তর দেয়; এটি মান নয়, সেবাদাতার বৈশিষ্ট্য।

আরও গভীর ফলো-আপ: “PTR কী কাজে লাগে?” → IP থেকে নাম (reverse DNS); মেইল server-এর সুনাম আর log পড়তে কাজে লাগে।

উত্তর: বাড়ি বা অফিসের router ভেতরের private ঠিকানা আর port বদলে নিজের public ঠিকানা আর একটি port বসায় (PAT/NAPT), আর একটি translation টেবিলে জোড়াটি লিখে রাখে; উত্তর এলে টেবিল দেখে উল্টো বদলায়। বাইরে থেকে নতুন সংযোগের জন্য টেবিলে কোনো রেকর্ড নেই, তাই router জানে না কাকে দেবে — port forwarding না থাকলে প্যাকেট ফেলে দেয়।

ফলো-আপ: “তাহলে NAT-ই তো firewall?” → না। NAT-এর উদ্দেশ্য ঠিকানা বাঁচানো; নিরাপত্তার মতো আচরণ পার্শ্বফল। নিরাপত্তা দেয় stateful firewall-এর “ভেতর থেকে শুরু হলে তবেই” নিয়ম — IPv6-এ NAT ছাড়াও ঠিক সেই নিয়ম রাখা হয়।

আরও গভীর ফলো-আপ: “Mobile operator-এর নেটওয়ার্কে game বা P2P কেন সমস্যা করে?” → CGNAT: operator নিজেও NAT করে, তাই ব্যবহারকারী দুই স্তরের NAT-এর পেছনে; port forwarding অসম্ভব, hole punching কঠিন — STUN/TURN আর relay লাগে (পর্ব ১৯)। Linux-এ NAT-এর অবস্থা থাকে conntrack টেবিলে।

উত্তর: 127.0.0.1-এ bind করা server শুধু loopback interface-এ শোনে — একই মেশিনের ভেতর থেকে আসা সংযোগই পায়; বাইরের যন্ত্রের SYN-এর উত্তরে kernel RST পাঠায়, তাই “refused”. 0.0.0.0 মানে “এই মেশিনের সব IPv4 ঠিকানায়”। ss -ltn-এ Local Address কলামে এটি সরাসরি দেখা যায় (অংশ ৮)।

ফলো-আপ: “Docker container-এ অ্যাপ 127.0.0.1-এ শুনলে?” → container-এর নিজের loopback, তাই port publish করেও বাইরে থেকে পৌঁছানো যায় না — container-এ অ্যাপকে 0.0.0.0-এ শুনতে হয়।

আরও গভীর ফলো-আপ: “Refused না এসে timeout হলে?” → মাঝে firewall প্যাকেট নিঃশব্দে ফেলছে (DROP), বা route নেই — প্র ২৩ আর তার নিচের দুটি C উদাহরণ।

উত্তর: MTU হলো একটি link-এ সবচেয়ে বড় IP প্যাকেট (Ethernet-এ সাধারণত ১৫০০ বাইট); MSS হলো TCP-র ডেটা-অংশের সর্বোচ্চ (১৫০০ − ২০ IP − ২০ TCP = ১৪৬০)। Path MTU Discovery-তে প্রেরক DF বসিয়ে পাঠায়; পথে ছোট MTU পেলে router ICMP “Fragmentation Needed” ফেরত দেয়। কোনো firewall যদি সব ICMP আটকে রাখে, প্রেরক কখনো জানে না — handshake আর ছোট উত্তর চলে, বড় প্যাকেট নিঃশব্দে হারায়: PMTUD black hole.

ফলো-আপ: “সমাধান?” → প্রয়োজনীয় ICMP (type 3 code 4; IPv6-এ Packet Too Big) চলতে দেওয়া, আর tunnel বা PPPoE-র সীমানায় MSS clamping.

আরও গভীর ফলো-আপ: “ICMP ছাড়া PMTU খোঁজা যায়?” → হ্যাঁ, PLPMTUD (RFC 4821) — transport নিজে বিভিন্ন আকারের probe পাঠিয়ে দেখে কোনটি পৌঁছায়; QUIC এমন কৌশল ব্যবহার করতে পারে।

উত্তর: (১) ঠিকানা ১২৮ বিট, তাই NAT ছাড়াই প্রতিটি যন্ত্রের global ঠিকানা সম্ভব; (২) broadcast নেই — ARP-এর জায়গায় multicast-ভিত্তিক NDP, আর router advertisement দেখে যন্ত্র নিজে ঠিকানা বানায় (SLAAC) বা DHCPv6 নেয়; (৩) সরল fixed header, router fragment করে না, checksum নেই। একটি interface-এ একসাথে link-local আর একাধিক global ঠিকানা থাকা স্বাভাবিক।

ফলো-আপ: “Dual-stack-এ ব্রাউজার কোনটি আগে নেয়?” → Happy Eyeballs (RFC 8305): IPv6 আগে চেষ্টা, অল্প দেরিতে IPv4-ও শুরু, যেটি আগে সংযুক্ত হয় সেটি।

আরও গভীর ফলো-আপ: “IPv6-এ কি ICMP আটকানো যায়?” → ICMPv6 ছাড়া NDP আর PMTUD ভাঙে; তাই ঢালাও block নয়, RFC 4890-এর মতো নির্দেশিকা মেনে বাছাই।

উত্তর: দুই পক্ষকেই নিজের শুরুর sequence number (ISN) জানাতে হবে, আর অপরজন সেটি পেয়েছে তা নিশ্চিত হতে হবে। SYN (client-এর ISN) → SYN-ACK (server-এর ISN + client-এর ISN-এর ack) → ACK (server-এর ISN-এর ack) — চারটি কাজ তিন বার্তায়, কারণ মাঝের দুটি একসাথে যায়। দুই ধাপে server জানত না তার ISN client পেয়েছে কি না, আর নেটওয়ার্কে আটকে থাকা পুরোনো SYN এলে server অকারণে সংযোগ খুলে বসত।

ফলো-আপ: “ISN শূন্য থেকে শুরু হয় না কেন?” → পুরোনো সংযোগের দেরিতে আসা segment যেন নতুনটির সাথে না মেশে, আর বাইরের কেউ যেন sequence আন্দাজ করে নকল segment ঢোকাতে না পারে — তাই ISN সময়-নির্ভর আর অনুমান-অযোগ্য (RFC 6528).

আরও গভীর ফলো-আপ: “Handshake-এর দেরি কমানোর উপায়?” → connection reuse (keep-alive, pool), TCP Fast Open (প্রচলন সীমিত), আর QUIC-এ transport ও TLS-এর handshake একসাথে — নতুন সংযোগে ১ RTT, আগের সেশনে ০-RTT.

উত্তর: যে পক্ষ আগে বন্ধ করে (active close), শেষ ACK পাঠানোর পর সে TIME-WAIT-এ থাকে — মান অনুযায়ী 2×MSL; Linux-এ নির্দিষ্ট ৬০ সেকেন্ড। দুই কারণ: শেষ ACK হারালে অপর পক্ষ FIN আবার পাঠাবে, তখন উত্তর দিতে হবে; আর একই চার-ঠিকানার নতুন সংযোগে পুরোনো সংযোগের দেরিতে আসা segment যেন না ঢোকে।

ফলো-আপ: “ক্ষতি কী?” → সাধারণত সামান্য — প্রতিটি অল্প মেমরি নেয়। আসল সমস্যা হয় client-পক্ষে: একই গন্তব্যে প্রতি অনুরোধে নতুন সংযোগ খুললে ephemeral port ফুরায় (নিচের হিসাবে প্রায় ৪৭১/সেকেন্ড)। সমাধান সংযোগ পুনর্ব্যবহার — keep-alive আর connection pool; net.ipv4.tcp_tw_reuse (শুধু outgoing-এ) সহায়ক।

আরও গভীর ফলো-আপ: “tcp_fin_timeout কমালে TIME-WAIT কমবে?” → না — ওটি FIN-WAIT-2-এর সময়; Linux-এ TIME-WAIT-এর ৬০ সেকেন্ড kernel-এ স্থির। আর tcp_tw_recycle NAT-এর পেছনের client ভাঙত বলে Linux 4.12-এ সরানো হয়েছে।

উত্তর: CLOSE-WAIT মানে অপর পক্ষ FIN পাঠিয়েছে, kernel ACK দিয়েছে, কিন্তু আপনার অ্যাপ এখনো close() ডাকেনি। এটি প্রায় সবসময় অ্যাপের বাগ — সংযোগ বন্ধ না করা, error-পথে socket ভুলে যাওয়া, বা থ্রেড আটকে থাকা। Kernel নিজে থেকে এ অবস্থা ছাড়ে না, তাই সংখ্যা বাড়তেই থাকে, শেষে fd ফুরায় (EMFILE).

ফলো-আপ: “কীভাবে নিশ্চিত হবেন?” → ss -tanp state close-wait কোন process আর কোন peer দেখায়; peer সাধারণত একটি নির্দিষ্ট upstream — সেই client-কোডের error-handling দেখুন।

আরও গভীর ফলো-আপ: “TIME-WAIT আর CLOSE-WAIT-এর তুলনায় কোনটি বেশি চিন্তার?” → CLOSE-WAIT; TIME-WAIT নিজে মিলিয়ে যায়, CLOSE-WAIT জমা মানে leak.

উত্তর: দুই পথে। (১) Timeout: ACK না এলে RTO শেষে আবার পাঠানো; RTO মাপা RTT থেকে — SRTT আর RTTVAR-এর EWMA (α = ১/৮, β = ১/৪), RTO = SRTT + ৪·RTTVAR (RFC 6298, শুরুর মান ১ সেকেন্ড; Linux-এর নিম্নসীমা ২০০ ms). প্রতিবার timeout-এ RTO দ্বিগুণ। (২) Fast retransmit: পরপর তিনটি duplicate ACK এলে timeout-এর অপেক্ষা না করেই আবার পাঠানো — একটি segment হারিয়েছে, পরেরগুলো পৌঁছাচ্ছে।

ফলো-আপ: “কোনটি বেশি খারাপ লক্ষণ?” → timeout; মানে পাইপ প্রায় খালি বা বড় ক্ষতি — congestion window ১-এ নেমে যায়, আর latency-তে স্পষ্ট লাফ দেখা যায়।

আরও গভীর ফলো-আপ: “আবার পাঠানো segment-এর ACK দিয়ে RTT মাপা হয় না কেন?” → ACK কোন কপির তা বোঝা যায় না — Karn-এর algorithm; timestamp option থাকলে এই অস্পষ্টতা মেটে। আধুনিক Linux SACK আর RACK দিয়ে আরও সূক্ষ্মভাবে ক্ষতি ধরে।

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

ফলো-আপ: “rwnd শূন্য হলে?” → প্রেরক থামে, আর মাঝে মাঝে window probe পাঠায়, যাতে window খোলার খবর হারালেও deadlock না হয় (persist timer).

আরও গভীর ফলো-আপ: “আন্তঃমহাদেশীয় link-এ বড় ফাইল ধীর, অথচ link ফাঁকা।” → একটি সংযোগের সর্বোচ্চ ≈ window ÷ RTT; window scaling বন্ধ থাকলে ৬৪ KiB ÷ ২০০ ms ≈ ২.৬২ Mbit/s. প্রয়োজন BDP-র সমান window (নিচের হিসাব, পর্ব ৩১ আর ৫৬)।

উত্তর: Slow start-এ প্রতি RTT-তে cwnd প্রায় দ্বিগুণ হয়, ssthresh পর্যন্ত; তারপর congestion avoidance-এ প্রতি RTT-তে ১ MSS যোগ, ক্ষতিতে অর্ধেক — AIMD (Reno). CUBIC (Linux-এর ডিফল্ট, RFC 9438) ক্ষতির পর সময়ের cubic ফাংশনে বাড়ে — বড় BDP-র পথে দ্রুত আগের মাত্রায় ফেরে। BBR ক্ষতিকে মূল সংকেত ধরে না; bottleneck bandwidth আর ন্যূনতম RTT মেপে সেই হারে pacing করে পাঠায়।

ফলো-আপ: “Wi-Fi বা মোবাইলে ক্ষতি-ভিত্তিক algorithm কেন সমস্যায় পড়ে?” → বেতারে কিছু ক্ষতি congestion নয়, তবু Reno/CUBIC গতি কমায়; BBR এমন পথে অনেক সময় ভালো throughput পায়।

আরও গভীর ফলো-আপ: “BBR-এর সমালোচনা?” → প্রথম সংস্করণ (v1) CUBIC-এর সাথে একই bottleneck-এ ন্যায্য ভাগ না দেওয়া আর গভীর buffer-এ বেশি retransmission নিয়ে সমালোচিত হয়েছিল; পরের সংস্করণগুলো ক্ষতিও বিবেচনায় নেয়। Linux-এ বদলানো যায় net.ipv4.tcp_congestion_control দিয়ে, প্রতি-socket-এ TCP_CONGESTION.

উত্তর: Nagle (RFC 896): আগের ছোট segment-এর ACK না আসা পর্যন্ত নতুন ছোট ডেটা জমিয়ে রাখে। Delayed ACK: গ্রাহক ACK একটু দেরিতে দেয়, যাতে উত্তরের সাথে বা দুই segment একসাথে ack করা যায় (মান অনুযায়ী ৫০০ ms-এর কম; Linux-এ সাধারণত কয়েক দশ ms, ন্যূনতম প্রায় ৪০ ms). অ্যাপ যদি একটি request দুই write-এ পাঠায় (header, তারপর body), দ্বিতীয়টি Nagle-এ আটকে থাকে ACK-এর জন্য, আর ACK আটকে থাকে delayed-ACK timer-এ — দুই পক্ষ পরস্পরের অপেক্ষায়।

ফলো-আপ: “সমাধান?” → সবচেয়ে ভালো: পুরো বার্তা একবারে লেখা (buffer করে বা writev). Latency-সংবেদনশীল protocol-এ TCP_NODELAY; অনেক RPC লাইব্রেরি এটি ডিফল্টে দেয়।

আরও গভীর ফলো-আপ: “TCP_NODELAY সবসময় দিলে ক্ষতি?” → অনেক ক্ষুদ্র write-এ অনেক ক্ষুদ্র প্যাকেট — header-এর অপচয় বাড়ে; Linux-এ TCP_CORK উল্টো কাজ করে: জমিয়ে পূর্ণ segment পাঠায়।

উত্তর: Head-of-line blocking মানে সামনের একটি আটকে থাকা জিনিস পেছনের সবাইকে আটকায়। HTTP/1.1-এ একটি সংযোগে উত্তর আসে ক্রমমতো — একটি ধীর উত্তর পরেরগুলো আটকায়; তাই ব্রাউজার একাধিক সংযোগ খোলে। HTTP/2 একটি সংযোগে অনেক stream মিশিয়ে application-স্তরের HOL মেটায়, কিন্তু নিচের TCP একটিই ক্রমমতো byte stream — একটি segment হারালে সব stream-এর পরের ডেটা kernel-এ আটকে থাকে: transport-স্তরের HOL.

ফলো-আপ: “তাহলে ক্ষতিপূর্ণ নেটওয়ার্কে HTTP/2 কি HTTP/1.1-এর চেয়েও খারাপ হতে পারে?” → হ্যাঁ, উচ্চ ক্ষতির পথে একটি সংযোগের একটি ক্ষতি সবাইকে থামায়, যেখানে ছয়টি আলাদা সংযোগে ক্ষতি ভাগ হয়ে যেত।

আরও গভীর ফলো-আপ: “QUIC কীভাবে মেটায়?” → প্রতিটি stream-এর নিজস্ব ক্রম; একটি stream-এর হারানো প্যাকেট শুধু সেই stream আটকায়। Switch-এর ভেতরেও HOL হয় — input queue-তে; সমাধান virtual output queue (পর্ব ১৫)।

উত্তর: মূল কারণ ossification: ইন্টারনেটের অসংখ্য firewall আর NAT শুধু TCP আর UDP চেনে; নতুন protocol নম্বর অনেক জায়গায় আটকে যেত। আর TCP বদলাতে হলে বিশ্বের সব OS-এর kernel হালনাগাদ করতে হয় — বছরের পর বছর। UDP-র ওপর QUIC user space-এর লাইব্রেরিতে থাকে, তাই অ্যাপের সাথে দ্রুত হালনাগাদ হয়; প্রায় পুরো header এনক্রিপ্ট বলে middlebox ভেতরে হাত দিতে পারে না, ফলে ভবিষ্যতেও ossify হয় কম। QUIC-এর মান RFC 9000 (২০২১), তার ওপর HTTP/3 — RFC 9114 (২০২২)।

ফলো-আপ: “QUIC কী দেয় যা TCP+TLS দেয় না?” → TLS 1.3 handshake-এর সাথে মিলিয়ে ১-RTT সংযোগ (আগের সেশনে ০-RTT), stream-ভিত্তিক ক্ষতি-সামলানো, আর connection ID দিয়ে Wi-Fi থেকে মোবাইল ডেটায় গেলেও সংযোগ টিকে থাকা (connection migration).

আরও গভীর ফলো-আপ: “০-RTT-এর ঝুঁকি?” → প্রথম ফ্লাইটের ডেটা replay করা যায়, তাই শুধু idempotent অনুরোধে (যেমন GET) ব্যবহার করা উচিত। আর দাম: user space-এ এনক্রিপশন আর প্রতিটি প্যাকেট আলাদা syscall-এ CPU খরচ বেশি; UDP GSO-র মতো কৌশলে কমানো হয়। কোথাও UDP আটকানো থাকলে ব্রাউজার TCP-তে ফেরে।

উত্তর: সাধারণত UDP (বা তার ওপর RTP/WebRTC, QUIC). কারণ পুরোনো তথ্য দেরিতে পৌঁছানোর চেয়ে বাদ পড়া ভালো — ৩০০ ms আগের খেলোয়াড়ের অবস্থান বা ভিডিও-ফ্রেম এখন অর্থহীন; TCP হারানো segment-এর জন্য পরের সব আটকে রাখে, ফলে ঝাঁকুনি বাড়ে। দরকারি অংশে (চ্যাট, কেনাকাটা) অ্যাপ নিজে বাছাই করে নির্ভরযোগ্যতা যোগ করে — sequence নম্বর, ACK, শুধু জরুরি বার্তা আবার পাঠানো।

ফলো-আপ: “UDP-তে congestion control না থাকলে?” → অ্যাপকেই দায়িত্ব নিতে হয়; নইলে নেটওয়ার্ক ভরিয়ে নিজের আর অন্যের ক্ষতি। WebRTC-র মতো stack নিজস্ব congestion control চালায়।

আরও গভীর ফলো-আপ: “UDP সার্ভিসে নিরাপত্তার বিশেষ ঝুঁকি?” → উৎস-ঠিকানা জাল করা সহজ, তাই ছোট প্রশ্নে বড় উত্তর দেওয়া সার্ভিস amplification-এ অপব্যবহৃত হতে পারে; তাই rate limiting আর অচেনা ঠিকানায় বড় উত্তর না দেওয়া (QUIC-এ ৩ গুণের anti-amplification সীমা)।

উত্তর: Refused (ECONNREFUSED): গন্তব্য host জীবিত আর পৌঁছানো যায়, কিন্তু সেই port-এ কেউ শুনছে না — kernel SYN-এর উত্তরে RST দিয়েছে (বা firewall REJECT করেছে)। দ্রুত আসে। Timed out: SYN-এর কোনো উত্তরই আসেনি — firewall নিঃশব্দে DROP করছে, route নেই, host বন্ধ, বা server-এর accept queue ভরা; kernel কয়েকবার SYN আবার পাঠিয়ে হাল ছাড়ে (Linux-এ ডিফল্টে প্রায় দুই মিনিট)। Reset by peer: সংযোগ তৈরি হয়েছিল, পরে অপর পক্ষ (বা মাঝের LB/firewall) RST পাঠিয়েছে — process মরেছে, idle timeout, বা না-পড়া ডেটা রেখে close.

ফলো-আপ: “Read timeout আবার কী?” → সংযোগ ঠিক আছে, কিন্তু নির্দিষ্ট সময়ে উত্তরের বাইট আসেনি — server ধীর বা আটকে আছে। নিচের দুটি C উদাহরণ refused, read timeout আর connect timeout — তিনটিই loopback-এ দেখায়।

আরও গভীর ফলো-আপ: “Firewall-এ REJECT না DROP?” → ভেতরের নেটওয়ার্কে REJECT দ্রুত ব্যর্থতা দেয় (client অপেক্ষায় ঝোলে না, ডিবাগ সহজ); ইন্টারনেট-মুখী প্রান্তে অনেকে DROP রাখেন — অপ্রয়োজনীয় উত্তর না দিতে। দুটোরই যুক্তি আছে।

উত্তর: Linux-এ দুটি সারি: SYN queue (অর্ধেক-খোলা, SYN-ACK পাঠানো হয়েছে) আর accept queue (handshake শেষ, অ্যাপের accept-এর অপেক্ষায়)। listen(fd, backlog)-এর backlog accept queue-র সীমা, যা net.core.somaxconn দিয়ে কাটা হয়। অ্যাপ যথেষ্ট দ্রুত accept না করলে queue ভরে, তখন Linux নতুন SYN বা শেষ ACK ফেলে দেয় — client দেখে connect timeout বা দীর্ঘ দেরি, refused নয়।

ফলো-আপ: “SYN flood কী, আর SYN cookie কীভাবে বাঁচায়?” → আক্রমণকারী জাল উৎস থেকে অসংখ্য SYN পাঠিয়ে SYN queue ভরায় (ধারণাগতভাবে)। SYN cookie-এ server কোনো অবস্থা না রেখে প্রয়োজনীয় তথ্য ISN-এর ভেতরে এনকোড করে পাঠায়; সত্যিকারের client-এর ACK এলে তবেই সংযোগ বানায়।

আরও গভীর ফলো-আপ: “Queue overflow কীভাবে ধরবেন?” → ss -ltn-এ LISTEN সারির Recv-Q (বর্তমান accept queue) আর Send-Q (সীমা), আর nstat-এ ListenOverflows/ListenDrops গণক। নিচের উদাহরণে backlog ১ দিয়ে ঠিক এই অবস্থা তৈরি করা হয়েছে।

উত্তর: তিনটিই সাধারণত proxy বা load balancer-এর কথা, অ্যাপের নয়। 502 Bad Gateway: upstream থেকে বৈধ উত্তর পায়নি — সংযোগ refused বা reset, বা ভাঙা উত্তর; অ্যাপ মরেছে বা ভুল port. 503 Service Unavailable: সেবা এখন নিতে পারছে না — কোনো সুস্থ backend নেই, ভারে চাপা, বা রক্ষণাবেক্ষণ; Retry-After থাকতে পারে। 504 Gateway Timeout: upstream সময়মতো উত্তর দেয়নি — অ্যাপ বা তার পেছনের DB ধীর।

ফলো-আপ: “401 আর 403? 429?” → 401 — আপনি কে তা প্রমাণ হয়নি (লগইন লাগবে); 403 — চিনেছি, কিন্তু অনুমতি নেই; 429 — অনেক বেশি অনুরোধ, rate limit. 301/308 স্থায়ী আর 302/307 অস্থায়ী redirect; 307/308 method বদলাতে দেয় না।

আরও গভীর ফলো-আপ: “মাঝে মাঝে বিক্ষিপ্ত 502, অ্যাপের log-এ কোনো ত্রুটি নেই।” → প্রায়ই keep-alive-এর সময়সীমার অমিল — LB পুরোনো সংযোগে অনুরোধ পাঠানোর মুহূর্তেই backend সেটি বন্ধ করেছে (প্র ৪৬)। দৃশ্যটির পুরো তদন্ত পর্ব ৬২-এ।

উত্তর: অর্থ (method, header, status) একই — বদলেছে তারের ওপরের রূপ। HTTP/2: binary frame, একটি TCP সংযোগে বহু stream, HPACK header compression; TLS-এর ভেতরে ALPN দিয়ে “h2” ঠিক হয়। HTTP/3: একই ধারণা QUIC-এর ওপর — stream-ভিত্তিক ক্ষতি-সামলানো, দ্রুত handshake, connection migration, আর QPACK. Server প্রথমবার HTTP/3 সমর্থনের খবর দেয় Alt-Svc header বা DNS-এর HTTPS রেকর্ডে।

ফলো-আপ: “Server push-এর কী হলো?” → বাস্তবে সুবিধা কম পাওয়া গেছে; প্রধান ব্রাউজারগুলো সমর্থন তুলে নিয়েছে, বিকল্প হিসেবে 103 Early Hints.

আরও গভীর ফলো-আপ: “কোন অবস্থায় HTTP/3-এর সুবিধা সবচেয়ে বেশি?” → উচ্চ ক্ষতি আর উচ্চ RTT-এর মোবাইল নেটওয়ার্কে আর ঘন ঘন নেটওয়ার্ক বদলানো যন্ত্রে; কম-ক্ষতির data center-এ পার্থক্য সামান্য, আর UDP-তে CPU খরচ কিছু বেশি।

উত্তর: ClientHello-তে client সমর্থিত cipher suite, একটি (EC)DHE public key-share আর SNI (কোন সাইট) পাঠায়। ServerHello-তে server নিজের key-share দেয় — দুই পক্ষ এখন একই গোপন চাবি বানাতে পারে। এরপর server-এর certificate, CertificateVerify (নিজের private key দিয়ে সই — প্রমাণ যে certificate-এর মালিক সে-ই) আর Finished — সব এনক্রিপ্ট হয়ে যায়। Client Finished পাঠিয়েই HTTP অনুরোধ পাঠাতে পারে — মোট ১ RTT (TLS 1.2-তে ২ RTT). RFC 8446 (২০১৮)।

ফলো-আপ: “নেটওয়ার্কের পর্যবেক্ষক কী দেখে?” → IP ঠিকানা, port, সময় আর আকার, আর সাধারণত SNI-তে সাইটের নাম; TLS 1.3-এ certificate আর দেখা যায় না। ECH SNI-ও লুকায়, তবে প্রচলন এখনো বাড়ছে।

আরও গভীর ফলো-আপ: “Forward secrecy কেন বাধ্যতামূলক?” → প্রতিটি সেশনের চাবি ক্ষণস্থায়ী DH থেকে; পরে server-এর private key চুরি হলেও আগে রেকর্ড করা ট্রাফিক খোলা যায় না। TLS 1.3 তাই RSA key transport বাদ দিয়েছে।

উত্তর: Client server-এর leaf certificate থেকে intermediate হয়ে নিজের trust store-এর কোনো root পর্যন্ত সইয়ের শিকল মেলায়; সাথে দেখে মেয়াদ, hostname (Subject Alternative Name-এ), ব্যবহারের অনুমতি, আর সম্ভব হলে revocation. সাধারণ ভুল: server শুধু leaf পাঠাচ্ছে, intermediate পাঠাচ্ছে না। ব্রাউজার অনেক সময় আগে দেখা intermediate cache থেকে বা নিজে ডাউনলোড করে শিকল পূর্ণ করে নেয়; curl, Java বা মোবাইল অ্যাপ তা করে না — তাই ব্যর্থ।

ফলো-আপ: “কীভাবে যাচাই করবেন?” → openssl s_client -connect example.com:443 -servername example.com -showcerts server আসলে কোন certificate-গুলো পাঠাচ্ছে দেখায়; সমাধান full chain (leaf + intermediate) পাঠানো।

আরও গভীর ফলো-আপ: “Revocation বাস্তবে কতটা কাজ করে?” → CRL বড় আর OCSP-তে গোপনীয়তা ও দেরির সমস্যা, তাই OCSP stapling, আর ছোট মেয়াদের certificate (ACME দিয়ে স্বয়ংক্রিয় নবায়ন) ঝুঁকি কমানোর বাস্তব পথ। ব্রাউজার public certificate-এ Certificate Transparency log-এর প্রমাণও চায়।

উত্তর: ব্রাউজারের same-origin policy এক origin-এর (scheme + host + port) পাতার JavaScript-কে অন্য origin-এর উত্তর পড়তে দেয় না — যাতে ক্ষতিকর সাইট আপনার লগইন-করা ব্যাংকের উত্তর পড়তে না পারে। CORS হলো server-এর পক্ষ থেকে সেই নিয়ম শিথিল করার উপায়: Access-Control-Allow-Origin header-এ কোন origin অনুমোদিত। এটি ব্রাউজার প্রয়োগ করে; curl বা Postman এই নিয়ম মানে না, তাই সেখানে চলে।

ফলো-আপ: “Preflight কী?” → সাধারণ নয় এমন অনুরোধে (যেমন PUT, Content-Type: application/json, নিজস্ব header) ব্রাউজার আগে OPTIONS পাঠিয়ে অনুমতি নেয়; server ঠিক উত্তর না দিলে আসল অনুরোধ যায়ই না।

আরও গভীর ফলো-আপ: “CORS কি API-র নিরাপত্তা?” → না; এটি ব্রাউজার-ব্যবহারকারীকে রক্ষা করে, server-কে নয়। API-র রক্ষা authentication আর authorization. Cookie-সহ অনুরোধে * চলে না — নির্দিষ্ট origin আর Access-Control-Allow-Credentials: true; আর অনুরোধের Origin অন্ধভাবে ফেরত লিখে দেওয়া বিপজ্জনক ভুল।

উত্তর: Secure — cookie শুধু HTTPS-এ যায়, তাই খোলা Wi-Fi-তে পড়া যায় না। HttpOnly — JavaScript (document.cookie) পড়তে পারে না, তাই XSS হলেও session চুরি কঠিন। SameSite — অন্য সাইট থেকে শুরু হওয়া অনুরোধে cookie যাবে কি না: Strict কখনো না, Lax শুধু উপরের-স্তরের সাধারণ navigation-এ, None সবসময় (তখন Secure বাধ্যতামূলক) — এটি CSRF কমায়।

ফলো-আপ: “SameSite না দিলে?” → অনেক আধুনিক ব্রাউজার এখন ডিফল্টে Lax ধরে; তবু স্পষ্ট লিখে দেওয়াই নিরাপদ।

আরও গভীর ফলো-আপ: “Cookie না token (Authorization header)?” → header-এ token স্বয়ংক্রিয়ভাবে যায় না, তাই CSRF-এর ঝুঁকি কম, কিন্তু JavaScript-এ রাখলে XSS-এ চুরি সহজ; cookie-তে উল্টো। দুই পথেই XSS প্রতিরোধ (output encoding, CSP) মূল কাজ।

উত্তর: Cache-Control বলে কতক্ষণ “তাজা”: max-age=3600 (সবার জন্য), s-maxage (শুধু CDN-এর মতো shared cache), no-cache (রাখা যাবে, তবে প্রতিবার যাচাই করে), no-store (রাখাই যাবে না), private (শুধু ব্রাউজারে)। মেয়াদ শেষে cache If-None-Match: <ETag> দিয়ে জিজ্ঞেস করে; না বদলালে server শুধু 304 Not Modified দেয় — body ছাড়াই।

ফলো-আপ: “Deploy-এর পর ব্যবহারকারী পুরোনো JS পাচ্ছে।” → file-নামে content hash (app.3f9a1c.js) দিয়ে লম্বা max-age আর immutable, কিন্তু HTML-এ ছোট বা no-cache; দরকারে CDN purge.

আরও গভীর ফলো-আপ: “CDN-এ ব্যবহারকারীর ব্যক্তিগত পাতা অন্যজন দেখে ফেলল — কীভাবে?” → cache key-এ cookie বা ব্যবহারকারী-পরিচয় নেই, অথচ উত্তরটি ব্যক্তিগত ছিল আর private/no-store বসানো হয়নি; Vary আর সঠিক header জরুরি (পর্ব ৩৮)।

উত্তর: L4 LB শুধু IP আর port দেখে প্রতিটি TCP/UDP সংযোগ একটি backend-এ দেয় — দ্রুত, protocol-নিরপেক্ষ, TLS না খুলেই; কিন্তু একটি দীর্ঘ সংযোগের ভেতরের অনুরোধগুলো ভাগ করতে পারে না। L7 LB HTTP পড়ে — path বা header দেখে routing (/api এক দলে, /static আরেক দলে), retry, header যোগ, TLS termination, প্রতি অনুরোধে ভাগ; দাম বেশি CPU আর জটিলতা।

ফলো-আপ: “gRPC (HTTP/2) সার্ভিসে L4 LB দিলে কী সমস্যা?” → একটি দীর্ঘ HTTP/2 সংযোগে সব অনুরোধ — সব একটি backend-এ যায়, নতুন pod অলস বসে থাকে; L7 (অনুরোধ-স্তরের) LB বা client-side balancing লাগে।

আরও গভীর ফলো-আপ: “Backend কীভাবে client-এর আসল IP জানবে?” → L7-এ X-Forwarded-For বা Forwarded header (শুধু বিশ্বস্ত proxy-র দেওয়াটা মানা); L4-এ PROXY protocol বা direct server return. Health check আর connection draining দুই ধরনেই লাগে।

উত্তর: VLAN একটি switch-কে কয়েকটি আলাদা broadcast domain-এ ভাগ করে — হিসাব বিভাগ, অতিথি Wi-Fi আর CCTV একই তারে থেকেও আলাদা নেটওয়ার্ক। Access port একটি VLAN-এর, যন্ত্র tag ছাড়া frame পাঠায়। Trunk port (switch-switch বা switch-router) অনেক VLAN বহন করে — প্রতিটি frame-এ ৪ বাইটের 802.1Q tag, যার ১২ বিটের VLAN ID (১–৪০৯৪ ব্যবহারযোগ্য)। Native VLAN-এর frame trunk-এ tag ছাড়া যায়।

ফলো-আপ: “দুই VLAN-এর যন্ত্র কথা বলবে কীভাবে?” → router বা L3 switch দিয়ে — inter-VLAN routing (router-on-a-stick বা SVI); মাঝখানে ACL বা firewall বসিয়ে নিয়ন্ত্রণ।

আরও গভীর ফলো-আপ: “Native VLAN-এর নিরাপত্তা-ঝুঁকি?” → দুই প্রান্তে native VLAN না মিললে ট্রাফিক ভুল VLAN-এ মেশে, আর double-tagging-এর মতো VLAN hopping-এর ধারণাগত ঝুঁকি; প্রতিরক্ষা: native VLAN-কে অব্যবহৃত VLAN-এ সরানো, ব্যবহারকারীর port-এ trunk-আলোচনা (DTP) বন্ধ।

উত্তর: Redundancy-র জন্য switch-গুলোর মাঝে একাধিক পথ রাখলে L2-তে loop হয়; Ethernet frame-এ TTL নেই, তাই একটি broadcast অনন্তকাল ঘোরে আর গুণিত হয় — broadcast storm, MAC table টালমাটাল, কয়েক সেকেন্ডে নেটওয়ার্ক অচল। STP (802.1D) কিছু port block করে loop-মুক্ত একটি গাছ বানায়। Root bridge: সবচেয়ে ছোট bridge ID (priority, ডিফল্ট ৩২৭৬৮, তারপর MAC).

ফলো-আপ: “ডিফল্টে রাখলে সমস্যা কী?” → সবচেয়ে পুরোনো (ছোট MAC-এর) switch root হয়ে যেতে পারে — হয়তো কোণের একটি দুর্বল switch; তাই core switch-এ priority কমিয়ে root ঠিক করে দেওয়া হয়।

আরও গভীর ফলো-আপ: “Classic STP ধীর কেন, বিকল্প?” → port listening/learning পেরোতে ৩০–৫০ সেকেন্ড; RSTP (802.1w) সাধারণত কয়েক সেকেন্ড বা তারও কমে মেলে। Data center-এ আজ প্রায়ই L3 leaf-spine আর ECMP — L2 loop-এর সুযোগই কমানো হয়। Access port-এ PortFast + BPDU Guard.

উত্তর: OSPF একটি IGP — এক প্রতিষ্ঠানের ভেতরে, link-state: প্রত্যেক router পুরো মানচিত্র জানে আর Dijkstra-য় সবচেয়ে কম cost-এর পথ বের করে; দ্রুত মেলে, লক্ষ্য গতি। BGP একটি EGP — autonomous system-গুলোর মাঝে, path vector: প্রতিটি route-এর সাথে AS-এর তালিকা; সিদ্ধান্ত নেয় policy দিয়ে (কাকে কী বিজ্ঞাপন দেব, কার route পছন্দ), সবচেয়ে ছোট পথ সবসময় নয়; TCP port 179-এ চলে।

ফলো-আপ: “দুটো একসাথে কেন?” → OSPF ভেতরের যন্ত্রগুলো আর loopback-এ পৌঁছানোর পথ দেয়; BGP দুই ISP বা upstream-এর সাথে বাইরের route বিনিময় করে। iBGP-র next-hop-এ পৌঁছাতে নিচে IGP লাগে।

আরও গভীর ফলো-আপ: “OSPF-এ area কেন?” → বড় নেটওয়ার্কে প্রতিটি পরিবর্তনে সবার SPF চালানো আর LSDB-র আকার কমাতে; area 0 backbone, অন্য area-গুলো ABR দিয়ে যুক্ত, আর area-র সীমায় summarization.

উত্তর: সাধারণ ক্রমের মূল ধাপগুলো: বেশি local preference (নিজের AS-এর নীতি, বেরোনোর পথ ঠিক করে), তারপর ছোট AS path, তারপর origin, কম MED (প্রতিবেশী AS-এর ইঙ্গিত, ঢোকার পথ), eBGP-কে iBGP-র আগে, next-hop-এর কাছের IGP cost, শেষে টাই-ভাঙার নিয়ম। Vendor-ভেদে বাড়তি ধাপ আছে (যেমন Cisco-র weight) — এটি স্পষ্ট বলা ভালো।

ফলো-আপ: “Leak আর hijack?” → Route leak: কেউ এক provider থেকে শেখা route ভুল করে আরেক provider-কে বিজ্ঞাপন দেয় — ট্রাফিক ভুল পথে ঘোরে। Prefix hijack: কেউ অন্যের prefix (বা তার চেয়ে নির্দিষ্ট অংশ) নিজের বলে বিজ্ঞাপন দেয়; longest prefix match-এর কারণে আরও নির্দিষ্টটি জেতে।

আরও গভীর ফলো-আপ: “প্রতিরক্ষা?” → প্রতিটি customer session-এ prefix filter (IRR-ভিত্তিক), max-prefix সীমা, RPKI-র ROA দিয়ে origin যাচাই (ROV), আর নিজের prefix নজরদারি। RPKI origin যাচাই করে, পুরো পথ নয় — সেই সীমাও বলুন।

উত্তর: Routing table-এ গন্তব্যের সাথে মেলে এমন কয়েকটি prefix থাকলে সবচেয়ে লম্বা (সবচেয়ে নির্দিষ্ট) prefix জেতে — longest prefix match; 0.0.0.0/0 default route সবার সাথে মেলে, তাই শেষ ভরসা। Administrative distance (Cisco-র ডিফল্টে connected ০, static ১, eBGP ২০, OSPF ১১০) কাজে লাগে শুধু তখন, যখন একই prefix বিভিন্ন উৎস থেকে আসে। তাই OSPF-এর /24 আর static-এর /16 থাকলে /24-এর মধ্যের গন্তব্যে OSPF-ই জেতে।

ফলো-আপ: “একই prefix, একই উৎস, একই cost-এর দুটি পথ?” → ECMP — দুটোই ব্যবহার হয়, প্রতিটি flow hash দিয়ে একটি পথে।

আরও গভীর ফলো-আপ: “ECMP প্রতি প্যাকেটে না করে প্রতি flow-এ কেন?” → এক flow-এর প্যাকেট দুই পথে গেলে ভিন্ন দেরিতে ক্রম উল্টে যায়, TCP সেটিকে ক্ষতি ভেবে গতি কমায়। দাম: কয়েকটি বড় flow (elephant) একই পথে পড়লে ভার অসম। Hardware-এ LPM-এর জন্য TCAM বা trie (পর্ব ২২)।

উত্তর: Block size পদ্ধতি (পর্ব ১৭): /26 মানে শেষ octet-এ ২ বিট network, mask 255.255.255.192, block size = ২৫৬ − ১৯২ = ৬৪. ৭৭-এর নিচের ৬৪-এর গুণিতক ৬৪ — network 192.168.10.64, পরের block ১২৮, তাই broadcast 192.168.10.127; host .65 থেকে .126 — ২^৬ − ২ = ৬২টি।

ফলো-আপ: “10.20.30.200/21?” → /21 তৃতীয় octet-এ কাটে, block ৮; ৩০-এর নিচের ৮-এর গুণিতক ২৪ — network 10.20.24.0, broadcast 10.20.31.255, host ২^১১ − ২ = ২০৪৬টি।

আরও গভীর ফলো-আপ: “/31 আর /32?” → /31-এ (RFC 3021) point-to-point link-এর দুই প্রান্তে দুটি ঠিকানাই ব্যবহারযোগ্য — network বা broadcast নেই; /32 একটি মাত্র host (loopback, host route). নিচের checker দিয়ে নিজের উত্তর মেলান।

উত্তর: বড় থেকে ছোট বরাদ্দ: ১২০ জনে লাগে ১২৮-এর block (/25, ১২৬ host) → 192.168.50.0/25 (.1–.126); ৫০ জনে ৬৪-এর block (/26, ৬২ host) → 192.168.50.128/26 (.129–.190); দুটি link-এ /30 (২ host) → 192.168.50.192/30 আর 192.168.50.196/30. বাকি 192.168.50.200–.255 ভবিষ্যতের জন্য ফাঁকা।

ফলো-আপ: “বড় থেকে শুরু কেন?” → ছোট block আগে বসালে বড় block-এর সীমা (alignment) মেলাতে মাঝে ফাঁক নষ্ট হয়।

আরও গভীর ফলো-আপ: “১২০ জনের তলায় /25 দেওয়া কি বুদ্ধিমানের?” → মাত্র ৬টি বাড়তি ঠিকানা — বৃদ্ধি, printer, AP আর IoT-এর জন্য কম; বাস্তবে প্রায়ই প্রতিটি VLAN-এ /24 দিয়ে সহজ আর বৃদ্ধিযোগ্য নকশা রাখা হয়, private ঠিকানার অভাব নেই বলে। ইন্টারভিউতে এই trade-off বলাই অভিজ্ঞতার চিহ্ন।

উত্তর: Server: socket → bind (ঠিকানা আর port) → listen (accept queue) → লুপে accept (প্রতিটি client-এর জন্য নতুন connected socket) → recv/send → close. Client: socket → connect. Blocking socket-এ recv ডেটা না আসা পর্যন্ত থ্রেড ঘুমায়; non-blocking-এ সঙ্গে সঙ্গে ফেরে — ডেটা না থাকলে EAGAIN, তখন অ্যাপ অন্য কাজ করে আর পরে আবার দেখে।

ফলো-আপ: “send সফল মানে কি অপর পক্ষ পেয়েছে?” → না; শুধু kernel-এর send buffer-এ কপি হয়েছে। অপর অ্যাপ পড়েছে কি না জানতে application-স্তরের উত্তর লাগে।

আরও গভীর ফলো-আপ: “Restart-এর পর bind ব্যর্থ: Address already in use — কেন?” → পুরোনো সংযোগ TIME-WAIT-এ সেই port ধরে আছে; server-এ bind-এর আগে SO_REUSEADDR. একাধিক process-এ একই port-এ শুনে kernel-কে ভার ভাগ করাতে SO_REUSEPORT.

উত্তর: তিনটিই এক থ্রেডে অনেক socket নজরে রাখে। select-এ fd-সংখ্যার সীমা (সাধারণত ১০২৪) আর প্রতিবার পুরো তালিকা kernel-এ কপি ও স্ক্যান; poll-এ সীমা নেই, কিন্তু খরচ এখনো O(মোট fd). epoll-এ আগ্রহের তালিকা kernel-এ একবার নিবন্ধিত, আর epoll_wait শুধু প্রস্তুত fd ফেরত দেয় — খরচ O(প্রস্তুত)। C10K — এক server-এ একসাথে দশ হাজার client — ১৯৯৯ সালে Dan Kegel-এর লেখায় আলোচিত; উত্তর এসেছে epoll/kqueue আর event-driven নকশায়।

ফলো-আপ: “Level-triggered আর edge-triggered?” → level: ডেটা থাকা পর্যন্ত বারবার জানায়; edge: নতুন ডেটা এলে একবার — তখন EAGAIN না পাওয়া পর্যন্ত পড়তেই হবে, নইলে ডেটা পড়ে থাকে আর আর কোনো খবর আসে না।

আরও গভীর ফলো-আপ: “আজ দশ লাখ সংযোগে সীমা কোথায়?” → fd-সীমা, প্রতি socket-এর buffer-মেমরি, conntrack টেবিল, আর client-পক্ষে ephemeral port; Windows-এ IOCP আর Linux-এ io_uring completion-ভিত্তিক বিকল্প।

উত্তর: প্রতিটি অনুরোধে DB বা অন্য সার্ভিসে নতুন সংযোগ মানে TCP handshake, প্রায়ই TLS, আর DB-তে authentication — কয়েক ms থেকে বহু ms; সাথে TIME-WAIT আর port-খরচ। Connection pool কিছু খোলা সংযোগ রেখে বারবার ব্যবহার করে। আকার শুরু করুন Little-এর সূত্রে: L = λ × W — ২০০০ অনুরোধ/সেকেন্ড × ১৫ ms = গড়ে ৩০টি ব্যস্ত সংযোগ (ওপরের হিসাব), তারপর চূড়া আর মাপা p99 দেখে সমন্বয়।

ফলো-আপ: “Pool যত বড় তত ভালো?” → না; DB-র নিজস্ব সীমা আছে, আর ৫০টি অ্যাপ-instance × ১০০ করে = ৫০০০ সংযোগ DB-কে ডুবিয়ে দিতে পারে। প্রায়ই ছোট pool আর অপেক্ষার সারি ভালো ফল দেয়; দরকারে মাঝখানে PgBouncer-এর মতো pooler.

আরও গভীর ফলো-আপ: “Pool থেকে নেওয়া সংযোগ মৃত হলে?” → firewall বা LB-এর idle timeout অলস সংযোগ নিঃশব্দে কেটে দেয়; pool-এ max idle time সেই timeout-এর চেয়ে কম রাখা, ব্যবহারের আগে বা পেছনে যাচাই, আর TCP keepalive.

উত্তর: অন্তত তিনটি: connect timeout (সংযোগ তৈরি — সাধারণত ছোট, যেমন কয়েকশো ms থেকে কয়েক সেকেন্ড), read/idle timeout (দুই বাইটের মাঝে সর্বোচ্চ নীরবতা), আর পুরো অনুরোধের deadline. অনেক লাইব্রেরির ডিফল্ট “চিরকাল অপেক্ষা” বা খুব লম্বা — একটি ধীর upstream তখন আপনার সব থ্রেড বা সংযোগ আটকে রাখে, আর সমস্যা উজানে ছড়ায় (cascading failure).

ফলো-আপ: “Timeout-এর মান কীভাবে বাছবেন?” → upstream-এর মাপা p99 latency-র চেয়ে কিছু বেশি, আর ব্যবহারকারীর ধৈর্যের বাজেটের ভেতরে; অনুমানে নয়, মেট্রিক দেখে।

আরও গভীর ফলো-আপ: “Deadline propagation কী?” → উজানের অনুরোধে ৮০০ ms বাকি থাকলে ভাটির প্রতিটি কল সেই বাকি সময়টুকুই পায় — নইলে উজান হাল ছেড়ে দেওয়ার পরও ভাটিতে অর্থহীন কাজ চলতে থাকে (gRPC deadline এভাবেই কাজ করে)।

উত্তর: শুধু অস্থায়ী ত্রুটিতে retry (timeout, সংযোগ ব্যর্থ, 503, 429 — Retry-After মেনে), স্থায়ী ত্রুটিতে নয় (400, 401, 404). প্রতিবার অপেক্ষা দ্বিগুণ (exponential backoff), একটি সর্বোচ্চ সীমাসহ; আর অপেক্ষা এলোমেলো করা (jitter) — নইলে একসাথে ব্যর্থ হাজারো client একই মুহূর্তে আবার আঘাত করে, সেবা উঠতেই আবার পড়ে যায় (thundering herd). সর্বোচ্চ চেষ্টার সংখ্যা সীমিত রাখুন।

ফলো-আপ: “Full jitter মানে?” → প্রতিবার অপেক্ষা ০ থেকে বর্তমান সীমার মধ্যে সম্পূর্ণ এলোমেলো; গড়ে অপেক্ষা কমে, আর চাপ সময়ে ছড়িয়ে যায়। নিচের কোডে তিনটি পরীক্ষাসহ দেখুন।

আরও গভীর ফলো-আপ: “Retry কোথায় করবেন — প্রতিটি স্তরে?” → না, একটি স্তরে (সাধারণত সবচেয়ে উজানে বা নির্দিষ্ট client-এ); প্রতিটি স্তরে করলে গুণিত হয় (প্র ৪৫)।

উত্তর: একটি কাজ idempotent যদি একবার আর কয়েকবার করার ফল একই হয়। HTTP-তে GET, PUT, DELETE সংজ্ঞায় idempotent; POST নয়। Timeout হলে আপনি জানেন না অনুরোধটি server-এ পৌঁছে কাজ হয়েছিল কি না — POST “৳৫০০ পাঠান” আবার পাঠালে দুবার টাকা কাটতে পারে। সমাধান: client প্রতিটি কাজের জন্য একটি অনন্য idempotency key পাঠায়, server key দেখে আগের ফল ফেরত দেয়, আবার করে না।

ফলো-আপ: “Retry storm?” → upstream ধীর হলে প্রতিটি স্তর retry করে ভার গুণিত করে — তিন স্তরে ৩ বার করে = ২৭ গুণ (ওপরের হিসাব); ভার বাড়ায় আরও ধীর, আরও retry. প্রতিরক্ষা: এক স্তরে retry, retry-বাজেট (যেমন মোট অনুরোধের ১০%-এর বেশি নয়), আর circuit breaker.

আরও গভীর ফলো-আপ: “Circuit breaker কীভাবে কাজ করে?” → ব্যর্থতার হার একটি সীমা ছাড়ালে “খোলা” অবস্থায় যায় — কিছুক্ষণ upstream-এ কল না পাঠিয়ে সঙ্গে সঙ্গে ব্যর্থ বা fallback দেয়; তারপর “আধা-খোলা” অবস্থায় অল্প কিছু পরীক্ষামূলক কল, সফল হলে আবার “বন্ধ”। ক্ষতিগ্রস্ত সেবাকে সেরে ওঠার সময় দেয়।

উত্তর: LB আর backend-এর মাঝে সংযোগ পুনর্ব্যবহৃত হয়। যদি backend-এর keep-alive timeout LB-এর idle timeout-এর চেয়ে ছোট হয়, backend একটি অলস সংযোগ বন্ধ করার ঠিক মুহূর্তে LB সেটিতে নতুন অনুরোধ পাঠাতে পারে — অনুরোধ RST খায়, ব্যবহারকারী পায় বিক্ষিপ্ত 502. নিয়ম: যে পক্ষ সংযোগ পুনর্ব্যবহার করে (LB), অলস সংযোগ আগে সে-ই বন্ধ করুক — backend-এর timeout LB-এর চেয়ে বড় রাখুন।

ফলো-আপ: “বাস্তব উদাহরণ?” → অনেক cloud LB-র idle timeout ডিফল্টে প্রায় ৬০ সেকেন্ড, আর কিছু অ্যাপ-framework-এর server keep-alive ডিফল্ট মাত্র কয়েক সেকেন্ড (যেমন Node.js-এর http server-এ ৫ সেকেন্ড) — এই জুটিতে সমস্যাটি পরিচিত। নিজের সংস্করণের ডকুমেন্টেশনে মান মিলিয়ে নিন।

আরও গভীর ফলো-আপ: “TCP keepalive আর HTTP keep-alive কি একই?” → না। TCP keepalive অলস সংযোগে ছোট probe পাঠিয়ে দেখে অপর পক্ষ বেঁচে আছে কি না (Linux-এ ডিফল্টে দুই ঘণ্টা পরে শুরু, তাই প্রায় সবসময় কমিয়ে নিতে হয়); HTTP keep-alive মানে একই সংযোগে একাধিক অনুরোধ।

উত্তর: Instance-গুলো ওঠে-নামে, ঠিকানা বদলায় — তাই “orders সার্ভিস এখন কোথায়?” প্রশ্নের স্বয়ংক্রিয় উত্তর লাগে: service discovery. Server-side: client একটি স্থির নাম বা VIP-এ পাঠায়, LB বা proxy ঠিক instance বাছে (Kubernetes Service, cloud LB). Client-side: client একটি registry (DNS, Consul, etcd) থেকে instance-তালিকা নিয়ে নিজেই বাছে আর balance করে (অনেক gRPC client). সাথে health check জরুরি — মৃত instance তালিকা থেকে সরানো।

ফলো-আপ: “শুধু DNS দিয়ে discovery-র সমস্যা?” → TTL আর cache-এর কারণে পরিবর্তন দেরিতে পৌঁছায়, আর অনেক client প্রথম ঠিকানাটিই ধরে বসে থাকে (প্র ৪৯)।

আরও গভীর ফলো-আপ: “Service mesh কী যোগ করে?” → প্রতিটি pod-এর পাশে একটি sidecar proxy (বা node-স্তরের proxy) discovery, retry, timeout, mTLS আর মেট্রিক সামলায় — কোড না বদলে নীতি এক জায়গায়; দাম বাড়তি hop, latency আর পরিচালনার জটিলতা।

উত্তর: নামটি CoreDNS resolve করে Service-এর ClusterIP-তে — একটি virtual IP; iptables mode-এ এটি কোনো interface-এ বসানো নেই আর ping-এ সাড়া দেয় না (IPVS mode-এ একটি dummy interface-এ বসানো থাকে)। প্রতিটি node-এ kube-proxy (iptables, IPVS বা nftables mode-এ) নিয়ম বসিয়ে রাখে: ClusterIP:port-এ যাওয়া প্যাকেট DNAT হয়ে একটি সুস্থ pod-এর IP:port-এ যায়; conntrack মনে রাখে, তাই উত্তর ফেরার পথে উল্টো অনুবাদ হয়। নিচের stepper ধাপে ধাপে দেখায়।

ফলো-আপ: “Pod তালিকা কোথা থেকে আসে?” → Service-এর selector-এর সাথে মেলা আর readiness probe-এ উত্তীর্ণ pod-গুলো EndpointSlice-এ; kube-proxy সেটি দেখে নিয়ম হালনাগাদ করে।

আরও গভীর ফলো-আপ: “নতুন pod যোগ হলেও পুরোনো pod-এ ভার — কেন?” → balancing হয় সংযোগ-স্তরে; দীর্ঘস্থায়ী সংযোগ (HTTP/2, gRPC, DB pool) শুরুতেই একটি pod-এ বাঁধা পড়ে। সমাধান: L7 balancing, client-side balancing (headless Service), বা সংযোগের সর্বোচ্চ বয়স। কিছু CNI (যেমন Cilium) kube-proxy-র কাজ eBPF দিয়ে করে।

উত্তর: কয়েকটি কারণ একসাথে: (১) TTL কমানোর আগে পুরোনো বড় TTL-এ cache হওয়া উত্তর সেই পুরোনো মেয়াদ পর্যন্ত টেকে — তাই পরিবর্তনের অন্তত এক পুরোনো-TTL আগে TTL কমাতে হয়; (২) কিছু resolver বা অ্যাপ নিজের নিয়মে বেশি সময় cache রাখে (কিছু JVM-সেটিংয়ে দীর্ঘ বা স্থায়ী cache — নিজের সংস্করণের networkaddress.cache.ttl দেখুন); (৩) সবচেয়ে বড় কারণ — খোলা সংযোগ DNS মানে না: connection pool বা keep-alive সংযোগ পুরোনো IP-তেই থাকে, যতক্ষণ না বন্ধ হয়।

ফলো-আপ: “তাহলে নিরাপদ migration?” → আগে TTL কমানো, দুই server একসাথে চালু রাখা, পুরোনোটিতে ট্রাফিক শূন্যে না নামা পর্যন্ত drain, আর client-এ সংযোগের সর্বোচ্চ বয়স।

আরও গভীর ফলো-আপ: “TTL খুব কম (১–৫ সেকেন্ড) রাখলে ক্ষতি?” → প্রায় প্রতিটি অনুরোধে resolver-প্রশ্ন — latency বাড়ে, DNS-ভার বাড়ে, আর DNS সেবা বিঘ্নিত হলে প্রভাব সঙ্গে সঙ্গে সর্বত্র; cache-এর রক্ষাকবচ হারায়। Negative caching-ও মনে রাখুন (প্র ০৭)।

উত্তর: Stateless firewall প্রতিটি প্যাকেট আলাদাভাবে দেখে — ফেরত ট্রাফিকের জন্যও আলাদা নিয়ম লাগে (যেমন cloud-এর network ACL). Stateful firewall সংযোগের অবস্থা মনে রাখে (Linux-এ conntrack) — ভেতর থেকে শুরু হওয়া সংযোগের উত্তর আপনিই চলতে দেয়। ন্যূনতম নিয়ম: ডিফল্ট নীতি drop (implicit deny); established/related অনুমতি; loopback অনুমতি; 80/443 সবার জন্য; SSH শুধু ব্যবস্থাপনা-নেটওয়ার্ক বা VPN থেকে; প্রয়োজনীয় ICMP; আর বাকি সব বন্ধ।

ফলো-আপ: “নিয়মের ক্রম কেন গুরুত্বপূর্ণ?” → বেশিরভাগ firewall প্রথম মেলা নিয়ম মানে; একটি চওড়া accept আগে বসলে পরের নির্দিষ্ট drop কখনো কাজ করে না।

আরও গভীর ফলো-আপ: “Egress filtering কেন?” → ভেতরের কোনো যন্ত্র আক্রান্ত হলে বাইরে ডেটা পাঠানো বা আক্রমণকারীর server-এ যোগাযোগ কঠিন হয়; server-এর বেরোনোর পথও শুধু দরকারি গন্তব্যে খোলা রাখা (egress filtering).

উত্তর: পুরোনো দুর্গ-মডেলে প্রাচীর পেরোলেই সবকিছুতে প্রবেশ — একটি আক্রান্ত ল্যাপটপ বা চুরি যাওয়া VPN-পাসওয়ার্ড থেকে আক্রমণকারী ভেতরে পাশে পাশে ছড়াতে পারে (lateral movement). Zero trust-এ নেটওয়ার্কের অবস্থান বিশ্বাসের ভিত্তি নয়: প্রতিটি অনুরোধে পরিচয় (MFA-সহ), যন্ত্রের অবস্থা আর নীতি যাচাই হয়, আর প্রতিটি অ্যাপে আলাদা, ন্যূনতম প্রবেশাধিকার।

ফলো-আপ: “VPN কি তাহলে বাদ?” → না; site-to-site সংযোগে VPN এখনো স্বাভাবিক। কিন্তু ব্যবহারকারীর প্রবেশে “পুরো নেটওয়ার্কে ঢোকানো” VPN-এর বদলে প্রতিটি অ্যাপের সামনে পরিচয়-সচেতন proxy (ZTNA)-র দিকে প্রবণতা।

আরও গভীর ফলো-আপ: “সার্ভিস-থেকে-সার্ভিসে?” → mTLS: দুই পক্ষই certificate দেখায়, তাই ভেতরের নেটওয়ার্কেও এনক্রিপশন আর পরিচয় দুটোই থাকে; service mesh এটি স্বয়ংক্রিয় করে। Zero trust একটি পণ্য নয়, ধাপে ধাপে বাস্তবায়নের নীতি — এই কথাটি বলা ভালো।

উত্তর: তিন ধরন। (১) Volumetric: link ভরিয়ে দেওয়া (প্রায়ই reflection/amplification-এ) — নিজের সার্ভারে কিছু করার নেই, link-ই ভরা; প্রতিরক্ষা upstream-এ: anycast-ভিত্তিক CDN বা scrubbing সেবা, ISP-এর সাথে RTBH/FlowSpec. (২) Protocol বা state-exhaustion: SYN flood-এ সংযোগ-টেবিল ভরানো — SYN cookie, conntrack আর LB-এর সীমা। (৩) Application-layer: বৈধ দেখতে দামি HTTP অনুরোধ — rate limiting, caching, WAF, challenge আর অটোস্কেলিং-এর সীমা।

ফলো-আপ: “আক্রমণ চলাকালে প্রথম কাজ?” → প্রকৃতি চেনা (bps না pps না rps, কোন port/path), upstream বা DDoS-সেবাকে জানানো, আর আগে থেকে তৈরি runbook মানা — চলার সময় নকশা করার সময় থাকে না।

আরও গভীর ফলো-আপ: “নিজের নেটওয়ার্ক যেন অন্যের ক্ষতির হাতিয়ার না হয়?” → উৎস-ঠিকানা যাচাই (ingress filtering, BCP 38), খোলা resolver বা অপ্রয়োজনীয় UDP সেবা বন্ধ রাখা — reflection-এর উপকরণ না হওয়া।

উত্তর: DB থাকবে private subnet-এ, public IP ছাড়া। তার security group-এ ঢোকার অনুমতি শুধু অ্যাপ-সার্ভারের security group থেকে, শুধু DB-র port-এ — 0.0.0.0/0 কখনো নয়। ব্যবস্থাপনার প্রবেশ bastion, VPN বা cloud-এর session-সেবা দিয়ে, MFA-সহ আর log-সহ। DB-র নিজের user-ও ন্যূনতম অধিকারের (least privilege).

ফলো-আপ: “Security group আর network ACL একসাথে কেন?” → একটি stateful, instance-স্তরের; অন্যটি stateless, subnet-স্তরের — দুই স্তরের রক্ষা (defense in depth).

আরও গভীর ফলো-আপ: “Kubernetes-এ একই নীতি?” → ডিফল্টে সব pod সব pod-এর সাথে কথা বলতে পারে; NetworkPolicy দিয়ে default-deny আর প্রয়োজনীয় পথ খোলা — তবে CNI সেটি প্রয়োগ করলে তবেই কার্যকর।

উত্তর: সঠিকভাবে যাচাই করা TLS-এ মাঝের কেউ (খোলা Wi-Fi, ARP spoofing) ট্রাফিক পড়তে বা বদলাতে পারে না, কারণ তার কাছে সাইটের বৈধ certificate-এর private key নেই। সুরক্ষা ভাঙে মানুষের বা কোডের ভুলে: কোডে certificate যাচাই বন্ধ করা (verify=False, -k, “trust all” — production-এ কখনো নয়), প্রথম অনুরোধ HTTP-তে যাওয়া (তখন HTTPS-এ ওঠার আগেই নামানো যায়), আর ব্যবহারকারীর সতর্কবার্তা উপেক্ষা করে এগোনো।

ফলো-আপ: “প্রথম HTTP অনুরোধের ফাঁক কীভাবে বন্ধ?” → HSTS header — ব্রাউজার পরের বার থেকে সবসময় HTTPS; preload তালিকায় থাকলে প্রথমবার থেকেই।

আরও গভীর ফলো-আপ: “প্রতিষ্ঠানের firewall যে HTTPS খুলে দেখে, সেটি কীভাবে সম্ভব?” → যন্ত্রগুলোতে প্রতিষ্ঠানের নিজস্ব root CA বসানো থাকে (TLS interception); তাই আইনগত ও নীতিগত স্বচ্ছতা, ব্যতিক্রম-তালিকা (ব্যাংক, স্বাস্থ্য) আর proxy-র নিজের নিরাপত্তা জরুরি।

উত্তর: IDS ট্রাফিকের কপি দেখে সতর্ক করে — পথে বসে না, ভুল হলে ক্ষতি কম। IPS পথের মাঝে বসে সন্দেহজনক ট্রাফিক আটকায় — কার্যকর, কিন্তু false positive-এ বৈধ ট্রাফিকও কাটে। শনাক্তের দুই পথ: signature (পরিচিত ধরন — নির্ভুল, নতুনে অন্ধ) আর anomaly (স্বাভাবিক থেকে বিচ্যুতি — নতুন ধরে, ভুল সতর্কতা বেশি)।

ফলো-আপ: “Alert fatigue কমাবেন কীভাবে?” → সম্পদের গুরুত্ব আর প্রেক্ষাপট (কোন server, কোন ব্যবহারকারী) যোগ করা, ভুল সতর্কতা নিয়মিত ছাঁটা, একই ঘটনার alert একসাথে করা, আর প্রতিটি alert-এর সাথে কী করতে হবে তার runbook.

আরও গভীর ফলো-আপ: “Port scan-এর অনেক alert দেখলে?” → ইন্টারনেট-মুখী ঠিকানায় scan প্রায় অবিরাম পটভূমি-শব্দ; আসল প্রশ্ন — কোন খোলা সেবা উন্মুক্ত আর হালনাগাদ কি না, আর scan-এর পর সফল লগইন বা অস্বাভাবিক বেরোনো ট্রাফিক আছে কি না। নিজের প্রতিষ্ঠানের অনুমোদন ছাড়া অন্যের নেটওয়ার্কে scan নয়।

উত্তর: ss -ti প্রতিটি TCP সংযোগের ভেতরের অবস্থা দেখায় — congestion algorithm, rtt, rto, cwnd, retransmission. উদাহরণ:

$ ss -tin dst 192.0.2.10        # উদাহরণ
State  Recv-Q Send-Q   Local Address:Port    Peer Address:Port
ESTAB  0      0        198.51.100.20:51514     192.0.2.10:443
	 cubic wscale:7,7 rto:236 rtt:36.2/4.1 mss:1448 pmtu:1500 cwnd:10 bytes_acked:1891
	 bytes_received:5120 send 3.2Mbps pacing_rate 6.4Mbps minrtt:35.9

rtt:36.2/4.1 — গড় RTT আর তার বিচ্যুতি (ms); rto:236 — Linux-এ RTO-র নিম্নসীমা ২০০ ms-এর কারণে এত বড়; mss:1448 — ১৪৬০ থেকে timestamp option-এর ১২ বাইট বাদ; cwnd:10 আর send 3.2Mbps ≈ ১০ × ১৪৪৮ × ৮ ÷ ০.০৩৬২ — window-সীমিত হার। retrans ঘর দেখা গেলে বা বাড়তে থাকলে ক্ষতি হচ্ছে।

ফলো-আপ: “ESTAB সারিতে Recv-Q বড় হতে থাকলে?” → kernel ডেটা পেয়েছে, অ্যাপ পড়ছে না — অ্যাপ ধীর বা আটকে; Send-Q বড় মানে অপর পক্ষ বা নেটওয়ার্ক নিচ্ছে না।

আরও গভীর ফলো-আপ: “সারা সিস্টেমের retransmission-হার?” → nstat -az TcpRetransSegs বা /proc/net/snmp; সময়ের সাথে হার দেখুন, মোট সংখ্যা নয়।

উত্তর: উদাহরণ:

$ dig example.com A            # উদাহরণ
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41270
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.		287	IN	A	192.0.2.10

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

status — NOERROR (ঠিক আছে), NXDOMAIN (নামটি নেই — নিশ্চিত উত্তর), SERVFAIL (resolver উত্তর বের করতে পারেনি — authoritative অচল, DNSSEC যাচাই ব্যর্থ ইত্যাদি)। flags-এ aa থাকলে উত্তর সরাসরি authoritative server থেকে; না থাকলে এসেছে recursive resolver-এর মাধ্যমে (তার cache থেকে বা নতুন খুঁজে)। TTL ২৮৭ — cache-এ বাকি সময়; আবার চালালে কমতে দেখবেন। SERVER বলে কাকে জিজ্ঞেস করা হলো — এখানে systemd-resolved-এর স্থানীয় stub.

ফলো-আপ: “Resolver-এর cache এড়িয়ে আসল উত্তর দেখতে?” → dig @ns1.example.com example.com (authoritative-কে সরাসরি), বা dig +trace — root থেকে ধাপে ধাপে।

আরও গভীর ফলো-আপ: “dig কাজ করে, অথচ অ্যাপ নাম পায় না — কেন?” → dig সরাসরি DNS প্রশ্ন করে; অ্যাপ getaddrinfo দিয়ে /etc/nsswitch.conf মেনে চলে (/etc/hosts, search domain, IPv6-অগ্রাধিকার)। তাই অ্যাপের দৃষ্টিভঙ্গি দেখতে getent hosts example.com.

উত্তর: -w-এর timing ভ্যারিয়েবল প্রতিটি ধাপের শেষ-মুহূর্ত (শুরু থেকে, ক্রমযোগী) দেয়:

$ curl -s -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' https://example.com/   # উদাহরণ
dns=0.012 tcp=0.048 tls=0.086 ttfb=0.388 total=0.402 code=200

বিয়োগ করে পড়ুন: DNS ১২ ms; TCP handshake ৪৮ − ১২ = ৩৬ ms (≈১ RTT); TLS ৮৬ − ৪৮ = ৩৮ ms (≈১ RTT — TLS 1.3-এর সাথে মেলে); তারপর প্রথম বাইট পর্যন্ত ৩৮৮ − ৮৬ = ৩০২ ms — নেটওয়ার্ক নয়, server-এর প্রক্রিয়াকরণই ধীর। -v দেখায় কোন IP-তে গেল, TLS সংস্করণ, ALPN (h2), certificate আর header.

ফলো-আপ: “LB-এর পেছনের একটি নির্দিষ্ট backend পরীক্ষা করতে, DNS না বদলে?” → curl --resolve example.com:443:192.0.2.11 https://example.com/ — নাম, SNI আর Host header ঠিক থাকে, শুধু IP বদলায়।

আরও গভীর ফলো-আপ: “-k দিয়ে চালালে চলে, ছাড়া চলে না।” → certificate যাচাই ব্যর্থ — শিকল অসম্পূর্ণ, মেয়াদ শেষ বা নাম মেলে না (প্র ২৮); -k সমাধান নয়, শুধু রোগনির্ণয়ের ইঙ্গিত।

উত্তর: নিজের অনুমোদিত সিস্টেমে, ছোট filter দিয়ে:

$ sudo tcpdump -ni eth0 -c 5 'tcp port 443 and host 192.0.2.10'     # উদাহরণ
10:15:01.100000 IP 198.51.100.20.51514 > 192.0.2.10.443: Flags [S], seq 1250000000, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
10:15:01.136000 IP 192.0.2.10.443 > 198.51.100.20.51514: Flags [S.], seq 3800000000, ack 1250000001, win 65160, options [mss 1460,sackOK,TS val 9 ecr 1,nop,wscale 7], length 0
10:15:01.136100 IP 198.51.100.20.51514 > 192.0.2.10.443: Flags [.], ack 1, win 502, length 0
10:15:01.136500 IP 198.51.100.20.51514 > 192.0.2.10.443: Flags [P.], seq 1:518, ack 1, win 502, length 517
10:15:01.172600 IP 192.0.2.10.443 > 198.51.100.20.51514: Flags [.], ack 518, win 507, length 0

[S] SYN, [S.] SYN-ACK (বিন্দু মানে ACK), [.] শুধু ACK, [P.] ডেটা (PUSH), [F.] FIN, [R] RST. SYN থেকে SYN-ACK ৩৬ ms — এটিই RTT. Handshake-এর পর tcpdump আপেক্ষিক sequence দেখায় (ack 1); ৫১৭ বাইটের প্রথম ডেটা হলো TLS ClientHello. win 502 × ২^৭ (wscale 7) ≈ ৬৪ KB.

ফলো-আপ: “SYN যাচ্ছে, উত্তর আসছে না — আর SYN-এর উত্তরে R আসছে — পার্থক্য?” → প্রথমটি DROP বা পথের সমস্যা (timeout), দ্বিতীয়টি port বন্ধ বা REJECT (refused) — প্র ২৩।

আরও গভীর ফলো-আপ: “ব্যস্ত server-এ নিরাপদে capture?” → সংকীর্ণ filter, -c বা -G/-W-এ সীমা, -s-এ snaplen ছোট, -w দিয়ে ফাইলে লিখে পরে Wireshark-এ; capture-এ ব্যক্তিগত তথ্য থাকতে পারে — অনুমতি আর সংরক্ষণ-নীতি মানা।

উত্তর: সম্ভবত কোথাও নয়। উদাহরণ:

$ mtr -rwc 100 example.net      # উদাহরণ
HOST: laptop                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                0.0%   100    1.2   1.5   0.9   4.1   0.4
  2.|-- 10.20.0.1                  0.0%   100    4.8   5.3   3.9  12.0   1.1
  3.|-- 203.0.113.33              42.0%   100   18.1  19.0  17.2  25.3   1.3
  4.|-- 198.51.100.65              0.0%   100   21.4  21.9  20.8  30.2   1.6
  5.|-- 192.0.2.80                 0.0%   100   22.0  22.3  21.1  29.9   1.5

mtr প্রতিটি hop-কে TTL-শেষের ICMP উত্তর দিতে বাধ্য করে। Router-এর কাছে এই উত্তর তৈরি control plane-এর নিম্ন-অগ্রাধিকারের কাজ, প্রায়ই rate-limited; তাই hop ৩ অনেক উত্তর দেয়নি, কিন্তু তার ভেতর দিয়ে forwarding ঠিক চলছে — পরের hop আর গন্তব্যে ০%. আসল ক্ষতি হলে সেই hop থেকে শেষ পর্যন্ত সব hop-এ loss থাকে।

ফলো-আপ: “তাহলে আসল সমস্যা কীভাবে প্রমাণ করবেন?” → শেষ hop-এর loss আর latency দেখা, দুই দিক থেকেই mtr (পথ অপ্রতিসম হতে পারে), আর TCP-ভিত্তিক পরীক্ষা (mtr --tcp -P 443), কারণ কিছু নেটওয়ার্ক ICMP আর TCP আলাদাভাবে আচরণ করে।

আরও গভীর ফলো-আপ: “ISP-কে টিকেট দিতে কী জমা দেবেন?” → সময়-চিহ্নসহ কয়েকবারের mtr রিপোর্ট দুই দিক থেকে, আক্রান্ত উৎস-গন্তব্য, আর প্রভাব (কতজন, কী সেবা) — NOC-এর দৈনন্দিন কাজ।

উত্তর: উদাহরণ:

$ sudo nft list ruleset         # উদাহরণ
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		ct state invalid drop
		iif "lo" accept
		ip protocol icmp accept
		meta l4proto ipv6-icmp accept
		tcp dport 22 ip saddr 10.10.0.0/24 accept
		tcp dport { 80, 443 } accept
	}
}

inet table IPv4 আর IPv6 দুটোই ধরে; input chain-এর নীতি drop — কোনো নিয়মে না মিললে বাদ। 10.10.0.5 থেকে নতুন SSH: tcp dport 22 ip saddr 10.10.0.0/24-এ মেলে — চলবে। বাইরের অন্য ঠিকানা থেকে SSH: কোনো নিয়মে মেলে না, নীতি drop — client timeout দেখবে, refused নয়। 80/443 সবার জন্য খোলা। IPv6-এ SSH-এর কোনো accept নেই, তাই IPv6-এ SSH বন্ধ — ইচ্ছাকৃত কি না জিজ্ঞেস করা ভালো প্রশ্ন।

ফলো-আপ: “Remote server-এ firewall বদলাতে গিয়ে নিজেকে আটকে ফেললে?” → আগে থেকে সাবধানতা: console বা out-of-band প্রবেশ হাতে রাখা, আর পরিবর্তনের সাথে স্বয়ংক্রিয় ফেরত (যেমন কয়েক মিনিট পরে পুরোনো ruleset ফিরিয়ে আনার একটি নির্ধারিত কাজ, নিশ্চিত হলে বাতিল)।

আরও গভীর ফলো-আপ: “Docker চালানো host-এ নিজের নিয়ম কাজ না করার কারণ?” → Docker নিজের NAT আর forward নিয়ম যোগ করে; publish করা port forward পথে যায়, host-এর input chain পেরোয় না — Docker-এর নির্দিষ্ট chain-এ নিয়ম দিতে হয়।

উত্তর: STAR কাঠামো, কারিগরি বিবরণসহ: Situation — কী সিস্টেম, কী প্রভাব (“অফিসের অর্ধেক মানুষ ৪০ মিনিট ইন্টারনেট পাননি”)। Task — আপনার ভূমিকা। Action — কীভাবে শনাক্ত, কী অনুমান করলেন, কোন কমান্ডে প্রমাণ পেলেন, প্রথমে কীভাবে প্রভাব কমালেন (mitigation), পরে মূল কারণ কীভাবে ঠিক করলেন। Result — সংখ্যায় ফল আর কী শিখলেন, কী বদলালেন যাতে আর না ঘটে।

ফলো-আপ: “আপনি কী ভুল করেছিলেন?” → সৎভাবে নিজের অংশ বলুন, অন্যকে দোষ দেবেন না; কী শিখে প্রক্রিয়া বদলেছেন তা-ই আসল উত্তর।

আরও গভীর ফলো-আপ: “Mitigation আর root cause fix আলাদা কেন?” → আগে রক্তপাত থামানো (rollback, ট্রাফিক সরানো), তারপর শান্ত মাথায় মূল কারণ — চাপের মধ্যে “আসল সমাধান” খুঁজতে গিয়ে outage লম্বা করা সাধারণ ভুল। কাল্পনিক ঘটনা বানাবেন না; ছোট হলেও নিজের সত্যিকারের অভিজ্ঞতা (ল্যাব বা প্রজেক্টও চলে) ভালো।

উত্তর: ঘটনার পর লিখিত পর্যালোচনা (postmortem), যার লক্ষ্য ব্যবস্থা উন্নত করা, ব্যক্তিকে শাস্তি নয় — কারণ মানুষ ভুল করবেই; প্রশ্ন হলো ব্যবস্থা কেন সেই ভুলকে outage হতে দিল। থাকে: সারাংশ আর প্রভাব (কতক্ষণ, কতজন), সময়রেখা, শনাক্তের পথ, মূল কারণ আর সহায়ক কারণ, কী ভালো কাজ করেছে, আর মালিক ও সময়সীমাসহ পদক্ষেপ।

ফলো-আপ: “Blameless কেন জরুরি?” → দোষারোপের সংস্কৃতিতে মানুষ তথ্য লুকায়, আর আসল দুর্বলতা অজানা থাকে।

আরও গভীর ফলো-আপ: “ভালো action item কেমন?” → নির্দিষ্ট আর যাচাইযোগ্য (“firewall পরিবর্তনে স্বয়ংক্রিয় rollback যোগ, দায়িত্বে X, দুই সপ্তাহে”), “সবাই আরও সাবধান হবে” নয়।

উত্তর: পরিকল্পনা লিখিত: কী বদলাবে, কেন, কী ঝুঁকি, কীভাবে যাচাই, আর rollback-এর ধাপ — পরিবর্তনের আগে। ল্যাব বা একটি ছোট অংশে আগে পরীক্ষা, অনুমোদিত সময়ে (change window), out-of-band প্রবেশ হাতে রেখে, monitoring খোলা রেখে; ধাপে ধাপে, প্রতিটি ধাপের পর যাচাই। আগে-পরে অবস্থা রেকর্ড (routing table, BGP prefix-সংখ্যা, interface error).

ফলো-আপ: “Rollback-এর সিদ্ধান্ত কখন?” → আগে থেকে ঠিক করা মাপকাঠিতে (যেমন prefix-সংখ্যা প্রত্যাশার বাইরে, বা ১০ মিনিটে যাচাই সম্পূর্ণ না হলে) — তর্ক না করে ফেরা।

আরও গভীর ফলো-আপ: “স্বয়ংক্রিয়করণ কীভাবে সাহায্য করে?” → কনফিগারেশন version control-এ, পর্যালোচনা, স্বয়ংক্রিয় পরীক্ষা আর একই পদ্ধতিতে প্রয়োগ (network automation) — হাতে টাইপের ভুল কমে; কিছু vendor-এর “commit confirmed” ধরনের বৈশিষ্ট্য নিশ্চিত না করলে নিজেই আগের অবস্থায় ফেরে।