Application layer — client-server, P2P আর protocol নকশা

১ · Application layer — যেখানে নেটওয়ার্ক মানুষের কাজে লাগে

এ পর্যন্ত পাঁচটি মডিউলে আমরা নিচ থেকে ওপরে উঠেছি: তারে সংকেত, frame, IP packet, routing, তারপর TCP আর UDP. কিন্তু কেউ “একটি TCP segment পাঠাতে” ইন্টারনেট ব্যবহার করেন না। মানুষ চান খবর পড়তে, বিকাশে টাকা পাঠাতে, ভিডিও কলে মায়ের সাথে কথা বলতে, অনলাইনে পরীক্ষার ফল দেখতে। এই কাজগুলো যে প্রোগ্রাম করে, তারা থাকে সবচেয়ে ওপরের স্তরে — application layer. পর্ব ০৩-এর TCP/IP মডেলে এটি পঞ্চম স্তর; OSI-র session, presentation আর application — তিনটির কাজই এখানে মিশে আছে।

একটা কথা শুরুতেই পরিষ্কার করা দরকার: application আর application-layer protocol এক জিনিস নয়। ওয়েব একটি application — এতে আছে ব্রাউজার, ওয়েব সার্ভার, HTML ফাইল, ছবি, আর তাদের মাঝে কথা বলার নিয়ম HTTP. ইমেইল একটি application — এতে আছে মেইল অ্যাপ, মেইল সার্ভার, mailbox, আর নিয়ম হিসেবে SMTP, IMAP. Protocol হলো পুরো ব্যবস্থার একটি অংশ — শুধু “তারে কী যাবে” সেই চুক্তি।

একটি protocol ঠিক কী কী ঠিক করে দেয়

পর্ব ০৩-এ দেখেছেন, protocol হলো দুই প্রান্তের একই স্তরের কথা বলার নিয়ম। Application স্তরে এই নিয়ম সাধারণত চারটি প্রশ্নের উত্তর দেয়:

খোলা বনাম মালিকানাধীন protocol

অনেক বড় protocol-এর পুরো নিয়ম প্রকাশ্যে লেখা থাকে RFC নামের দলিলে, যা প্রকাশ করে IETF: HTTP-র অর্থ RFC 9110-এ আর HTTP/1.1-এর বার্তার গঠন RFC 9112-এ, ইমেইল পাঠানোর SMTP RFC 5321-এ, DNS-এর মূল নিয়ম RFC 1034 আর 1035-এ। এগুলো খোলা (open) protocol — যে-কেউ পড়ে নিজের client বা সার্ভার বানাতে পারেন, আর তা অন্য সবার সাথে কাজ করবে; তাই Gmail থেকে একটি দেশি ISP-র মেইল সার্ভারে চিঠি যায়। অন্যদিকে অনেক মেসেজিং অ্যাপ বা অনলাইন গেমের নিয়ম শুধু সেই কোম্পানি জানে — মালিকানাধীন (proprietary) protocol. কোম্পানি দ্রুত বদলাতে পারে, কিন্তু অন্য কেউ যুক্ত হতে পারে না (ভাবনার প্রশ্ন ৫)।

অ্যাপ চলে শুধু প্রান্তে — আর সেটাই সবচেয়ে বড় সুবিধা

একটি নেটওয়ার্ক অ্যাপ লিখতে হয় শুধু end system-এর জন্য — ফোন, ল্যাপটপ, সার্ভার। পথের router-এ বা switch-এ কোনো অ্যাপ-কোড লিখতে হয় না; router তো network স্তরের ওপরে কিছু দেখেই না (পর্ব ১৫)। এর ফল বিশাল: কাউকে নতুন কোনো সেবা চালু করতে টেলিকম কোম্পানির অনুমতি বা নেটওয়ার্কের যন্ত্রপাতি বদলানোর অপেক্ষা করতে হয় না। দুটি কম্পিউটারে দুটি প্রোগ্রাম, মাঝে যেকোনো ইন্টারনেট — ব্যস। পর্ব ০৩-এর end-to-end নীতি-র সবচেয়ে বড় উপহার এটাই — ভাবনার প্রশ্ন ১-এ এর ইতিহাস।

২ · তিন রকম গঠন — client-server, peer-to-peer আর hybrid

পর্ব ০২-এ দুটি গঠনের মূল পার্থক্য দেখেছেন: client-server-এ একটি server সেবা দেয় আর অনেক client সেবা নেয়; peer-to-peer-এ সবাই একসাথে দেয় আর নেয়। এখানে দেখব অ্যাপ-নকশাকারীর চোখে — খরচ, ঝুঁকি আর বড় হলে কী ঘটে।

Client-server: সবসময় চালু সার্ভার

Client-server গঠনে সার্ভারের তিনটি বৈশিষ্ট্য: সে সবসময় চালু (always-on), তার স্থায়ী, পরিচিত ঠিকানা থাকে (একটি নাম, DNS দিয়ে IP), আর সে নিজে কারও কাছে যায় না — client আগে যোগাযোগ শুরু করে। ওয়েব, ইমেইল, ব্যাংকিং অ্যাপ, অনলাইন ভর্তি আবেদন — সবই এই গঠনের।

জনপ্রিয় সেবায় একটি সার্ভার যথেষ্ট নয়। তখন হাজার হাজার সার্ভার রাখা হয় বিশাল data center-এ, আর সামনে load balancer অনুরোধ ভাগ করে দেয় (পর্ব ৫২)। বিদ্যুৎ, ঠান্ডা রাখা আর bandwidth-এর পুরো খরচ সেবাদাতার।

Peer-to-peer: ব্যবহারকারীরাই সার্ভার

P2P গঠনে সবসময়-চালু সার্ভারের ওপর ভরসা কম বা একেবারেই নেই। সাধারণ ব্যবহারকারীর যন্ত্র — peer — সরাসরি একে অপরের সাথে কথা বলে। কেউ একটি ফাইল ডাউনলোড করার সময়ই অন্যদের সেই ফাইলের অংশ আপলোড করে। সবচেয়ে বড় সুবিধা self-scalability: নতুন peer এলে সে চাহিদা বাড়ায়, কিন্তু সাথে নিজের আপলোড-ক্ষমতাও নিয়ে আসে। অংশ ৩-এ এর গাণিতিক রূপ দেখবেন।

কিন্তু P2P-র কঠিন দিকও আছে। Peer-রা আসে-যায় (কারও লোডশেডিং, কেউ ল্যাপটপ বন্ধ করলেন), IP বদলায়, অনেকে NAT-এর পেছনে (পর্ব ১৯)। বাসার ইন্টারনেটে আপলোড গতি প্রায়ই ডাউনলোডের চেয়ে কম। আর নিরাপত্তা: অচেনা peer-এর দেওয়া ডেটা বিশ্বাস করা যায় কি না — তাই BitTorrent প্রতিটি chunk-এর hash মিলিয়ে নেয়।

Hybrid: খোঁজার কাজ কেন্দ্রে, ভারী কাজ প্রান্তে

বাস্তবের অনেক ব্যবস্থাই মিশ্র। ভিডিও কলের অ্যাপে কে অনলাইন আছেন, কার ঠিকানা কী — এসব থাকে কেন্দ্রীয় সার্ভারে; কিন্তু সম্ভব হলে কণ্ঠ আর ভিডিও সরাসরি দুই ফোনের মধ্যে যায় (WebRTC-এর মতো প্রযুক্তি, পর্ব ৪০)। পুরোনো Napster (১৯৯৯) গানের তালিকা রাখত কেন্দ্রীয় সার্ভারে, কিন্তু ফাইল আসত ব্যবহারকারীদের কম্পিউটার থেকে। আর CDN (পর্ব ৩৮) উল্টো দিক থেকে মিশ্রণ: সার্ভারই, কিন্তু ব্যবহারকারীর কাছাকাছি হাজার জায়গায় ছড়ানো।

একটি সূক্ষ্ম কথা: P2P অ্যাপেও প্রতিটি যোগাযোগের মুহূর্তে একটি পক্ষ client আর অন্যটি server. যে peer অনুরোধ পাঠাল, সে ওই আলাপে client; যে উত্তর দিল, সে server. তাই “client” আর “server” শব্দ দুটি দুই অর্থে চলে — পুরো অ্যাপের গঠন বোঝাতে, আর একটি নির্দিষ্ট আলাপে কে শুরু করল তা বোঝাতে।

৩ · P2P কেন বড় হয় — ফাইল বিতরণের সময়ের হিসাব

ধরুন একটি বড় ফাইল — একটি Linux ইনস্টলেশন ইমেজ বা একটি সফটওয়্যার আপডেট — N জন মানুষের কাছে পৌঁছাতে হবে। সবাই পুরো ফাইল পেলে কাজ শেষ। এই সময়কে বলে distribution time. প্রশ্ন: client-server আর P2P-তে এই সময়ের সর্বনিম্ন মান কত? বিশ্ববিদ্যালয় আর চাকরির পরীক্ষায় এটি খুব প্রচলিত হিসাব।

মডেল আর চিহ্ন

• F — ফাইলের আকার (bit)
• N — কতজন peer ফাইলটি চায়
• u_s — সার্ভারের আপলোড গতি; u_i — i-তম peer-এর আপলোড গতি
• d_i — i-তম peer-এর ডাউনলোড গতি; d_min — সবচেয়ে ধীর peer-এর ডাউনলোড গতি

ধরে নেওয়া হয় ইন্টারনেটের মাঝখানে কোনো ভিড় নেই — বাধা শুধু প্রান্তের link-এ (access link), আর ডেটাকে পানির মতো যত সূক্ষ্মভাবে খুশি ভাগ করা যায় — একে বলে fluid model.

Client-server: দুটি নিচের সীমা

(ক) সার্ভারের আপলোড: N জনের প্রত্যেককে আলাদা একটি পূর্ণ কপি পাঠাতে হবে, অর্থাৎ সার্ভারকে মোট NF bit তুলতে হবে। গতি u_s, তাই কমপক্ষে NF/u_s সময়। (খ) সবচেয়ে ধীর client: তাকে F bit নামাতে হবে, তার গতি d_min, তাই কমপক্ষে F/d_min সময়। দুটি শর্তই মানতে হবে, তাই সময় অন্তত দুটির বড়টি। আর সার্ভার যদি সব client-কে min(u_s/N, d_min) হারে একসাথে পাঠায়, ঠিক এই সময়েই কাজ শেষ হয় — তাই এটিই সর্বনিম্ন:

D_cs  = max( N·F / u_s ,  F / d_min )

D_P2P = max( F / u_s ,  F / d_min ,  N·F / (u_s + Σ u_i) )

P2P: তিনটি নিচের সীমা

(ক) শুরুতে ফাইলটি শুধু সার্ভারের কাছে, তাই অন্তত একটি পূর্ণ কপি সার্ভারকে তুলতেই হবে: F/u_s. (খ) সবচেয়ে ধীর peer-কে F bit নামাতে হবে: F/d_min. (গ) মোট N জনের কাছে মোট NF bit পৌঁছাতে হবে, আর পুরো ব্যবস্থার মোট আপলোড-ক্ষমতা সার্ভার আর সব peer মিলিয়ে u_s + Σu_i — তাই কমপক্ষে NF/(u_s + Σu_i). এই তিনটির বড়টিই নিচের সীমা। Fluid model-এ একটি চতুর বণ্টন (সার্ভার প্রতিটি peer-কে আলাদা অংশ দেয়, আর প্রতিটি peer নিজের অংশ বাকি সবাইকে পাঠায়) দিয়ে দেখানো যায় যে এই সীমাতেও পৌঁছানো সম্ভব — তাই বাস্তব বিশ্লেষণে এটিকেই সর্বনিম্ন সময় ধরা হয়।

সবচেয়ে জরুরি পর্যবেক্ষণ — N বাড়লে কী হয়

D_cs-এর প্রথম পদ NF/u_s — N-এর সাথে সরলরেখায় বাড়ে; হাজার জন হলে হাজার গুণ। D_P2P-এর তৃতীয় পদে সব peer-এর আপলোড গতি সমান u ধরলে NF/(u_s + Nu). N বড় হলে এটি এগিয়ে যায় F/u-এর দিকে, কিন্তু কখনো পেরোয় না — ব্যবহারকারী যতই বাড়ুক, P2P-র সময় একটি ছাদের নিচে থাকে। এটিই self-scalability-র গাণিতিক রূপ: প্রতিটি নতুন peer চাহিদা আনে F, ক্ষমতাও আনে u.

একটি পুরো numerical (পরীক্ষার ধাঁচে)

একটি ১ GB ফাইল, মানে F = ৮,০০০ Mbit (১ GB = ৮,০০০ Mbit ধরে, দশমিক একক)। সার্ভারের আপলোড u_s = ১০০ Mbps, সবচেয়ে ধীর peer-এর ডাউনলোড d_min = ২০ Mbps, প্রতিটি peer-এর আপলোড u = ৫ Mbps, আর N = ১০০.

• Client-server: NF/u_s = ১০০ × ৮,০০০ / ১০০ = ৮,০০০ সেকেন্ড; F/d_min = ৮,০০০ / ২০ = ৪০০ সেকেন্ড। D_cs = max(৮,০০০, ৪০০) = ৮,০০০ সেকেন্ড ≈ ১৩৩.৩ মিনিট.
• P2P: F/u_s = ৮০ সেকেন্ড; F/d_min = ৪০০ সেকেন্ড; NF/(u_s + Nu) = ৮,০০,০০০ / (১০০ + ৫০০) = ৮,০০,০০০ / ৬০০ ≈ ১,৩৩৩.৩ সেকেন্ড। D_P2P = ≈ ১,৩৩৩.৩ সেকেন্ড ≈ ২২.২ মিনিট.
• তুলনা: P2P প্রায় ৬ গুণ দ্রুত। আর N যত বাড়বে, পার্থক্য তত বাড়বে — P2P-র সময়ের ছাদ F/u = ৮,০০০/৫ = ১,৬০০ সেকেন্ড ≈ ২৬.৭ মিনিট.

নিচের ছবিতে দুটি অক্ষই logarithmic (প্রতিটি দাগে ১০ গুণ), N ১০ থেকে ১,০০০. Client-server-এর রেখা সোজা ওপরে উঠছে; P2P-র রেখাগুলো চ্যাপ্টা হয়ে নিজ নিজ ছাদের দিকে যাচ্ছে।

নিজে চালিয়ে দেখুন: বিতরণ-সময়ের calculator

নিচের প্রোগ্রাম এই দুই সূত্রে কয়েকটি N আর তিন রকম peer-আপলোড গতির (১, ৫, ২০ Mbps) জন্য সময় ছাপে, তারপর client-server কোথা থেকে পিছিয়ে পড়ে আর P2P-র ছাদ কোথায় তা দেখায়।

// Minimum distribution time: client-server vs P2P (fluid model, rates in Mbit/s).
const F = 8000;        // file size: 1 GB = 8000 Mbit
const us = 100;        // server upload rate
const dmin = 20;       // slowest peer's download rate
const Dcs = N => Math.max(N * F / us, F / dmin);
const Dp2p = (N, u) => Math.max(F / us, F / dmin, N * F / (us + N * u));
const t = s => (s / 60).toFixed(1).padStart(9) + " min";

console.log("N".padStart(5) + ["D_cs", "D_P2P u=1", "D_P2P u=5", "D_P2P u=20"]
  .map(h => h.padStart(13)).join(""));
for (const N of [1, 5, 10, 50, 100, 200, 500, 1000]) {
  console.log(String(N).padStart(5) + t(Dcs(N)) + t(Dp2p(N, 1)) + t(Dp2p(N, 5)) + t(Dp2p(N, 20)));
}
// Crossover: the first N where client-server becomes slower than P2P (u = 5)
let N = 1;
while (Dcs(N) <= Dp2p(N, 5)) N++;
console.log(`\nu=5: client-server is slower from N = ${N}` +
  ` (D_cs ${Dcs(N)} s vs D_P2P ${Dp2p(N, 5).toFixed(0)} s)`);
console.log(`client-server grows without limit: +${F / us} s per extra peer`);
for (const u of [1, 5, 20])
  console.log(`P2P limit as N grows (u=${u}): F/u = ${F / u} s = ${t(F / u).trim()}`);

    N         D_cs    D_P2P u=1    D_P2P u=5   D_P2P u=20
    1      6.7 min      6.7 min      6.7 min      6.7 min
    5      6.7 min      6.7 min      6.7 min      6.7 min
   10     13.3 min     12.1 min      8.9 min      6.7 min
   50     66.7 min     44.4 min     19.0 min      6.7 min
  100    133.3 min     66.7 min     22.2 min      6.7 min
  200    266.7 min     88.9 min     24.2 min      6.7 min
  500    666.7 min    111.1 min     25.6 min      6.7 min
 1000   1333.3 min    121.2 min     26.1 min      6.7 min

u=5: client-server is slower from N = 6 (D_cs 480 s vs D_P2P 400 s)
client-server grows without limit: +80 s per extra peer
P2P limit as N grows (u=1): F/u = 8000 s = 133.3 min
P2P limit as N grows (u=5): F/u = 1600 s = 26.7 min
P2P limit as N grows (u=20): F/u = 400 s = 6.7 min

৪ · BitTorrent — torrent, tracker, chunk আর ভাগাভাগির নিয়ম

অংশ ৩-এর হিসাব বাস্তবে সবচেয়ে সফলভাবে কাজে লাগিয়েছে BitTorrent — Bram Cohen ২০০১ সালে এর নকশা করেন। আজও Linux distribution-এর ইমেজ আর Internet Archive-এর মতো সংগ্রহশালার বড় ফাইল বিতরণে এটি বৈধভাবে ব্যবহৃত হয়। (যে ফাইল বিতরণের অধিকার আপনার নেই, তা যেকোনো পদ্ধতিতেই শেয়ার করা বেআইনি — protocol নিরপেক্ষ, দায় ব্যবহারকারীর।)

মূল উপাদানগুলো

• Torrent আর swarm: একটি নির্দিষ্ট ফাইল (বা ফাইলগুচ্ছ) বিনিময়ে অংশ নেওয়া সব peer মিলে একটি swarm. যার কাছে পুরো ফাইল আছে, তাকে বলে seeder; যে এখনো নামাচ্ছে, সে leecher.
• .torrent ফাইল বা magnet link: এতে থাকে ফাইলের নাম, আকার, chunk-এর মাপ, প্রতিটি chunk-এর hash, আর কোথায় peer খুঁজতে হবে। ফাইলের মূল পরিচয় একটি hash — “info hash”.
• Chunk (piece): ফাইল সমান মাপের টুকরোয় ভাগ — মাপ সাধারণত কয়েকশো KiB থেকে কয়েক MiB. প্রতিটি chunk পেয়ে peer hash মিলিয়ে দেখে — নষ্ট বা নকল হলে বাদ।
• Tracker: একটি সার্ভার, যে শুধু জানে কোন torrent-এ এখন কারা আছে। নতুন peer tracker-কে জানায় “আমি এলাম”, আর বদলে কিছু peer-এর IP:port-এর তালিকা পায়। Tracker ফাইলের কোনো অংশ রাখে না।
• DHT: tracker ছাড়াও peer খোঁজা যায় distributed hash table দিয়ে — লাখো peer মিলে “কে কোন torrent-এ আছে” তালিকাটি ভাগ করে রাখে। Hash table-এর ধারণা DSA কোর্সের hash table পর্বে দেখতে পারেন।

কোন chunk আগে চাইবেন — rarest first

একজন peer-এর হাতে কিছু chunk আছে, বাকিগুলো নেই। প্রতিবেশীদের কাছে কোনটি কতজনের আছে, তা সে জানে (peer-রা নিজেদের মধ্যে “আমার কাছে কোন কোন chunk আছে” বিনিময় করে)। নিয়ম: যে chunk swarm-এ সবচেয়ে কম কপিতে আছে, সেটি আগে চাওয়া — rarest first. কারণ: বিরল chunk-এর মালিক চলে গেলে সেটি swarm থেকে হারিয়ে যেতে পারে, তখন কেউ ফাইল শেষ করতে পারবে না। আগে বিরলগুলো ছড়িয়ে দিলে সব chunk-এর কপি দ্রুত সমান হয়, আর প্রত্যেক peer অন্যদের দেওয়ার মতো কিছু হাতে পায়।

কাকে দেবেন — tit-for-tat

প্রত্যেক peer-এর আপলোড-ক্ষমতা সীমিত, তাই সে সবাইকে একসাথে দেয় না। BitTorrent-এর মূল নকশায় একজন peer মোটামুটি প্রতি ১০ সেকেন্ডে মেপে দেখে কে তাকে সবচেয়ে দ্রুত দিচ্ছে, আর সেরা চারজনকে পাঠায় — তাদের “unchoke” করে, বাকিদের আপাতত “choke” করে রাখে। এর নাম tit-for-tat — যে দেয়, তাকেই আগে দেওয়া। আর প্রতি ৩০ সেকেন্ডে একজন এলোমেলো peer-কে বিনা শর্তে দেওয়া হয় — optimistic unchoke — যাতে নতুন peer শুরু করতে পারে আর হয়তো আরও ভালো সঙ্গী খুঁজে পাওয়া যায়। ফলে যারা শুধু নেয়, দেয় না (free-rider), তারা ধীরে ধীরে কম পায়। (সংখ্যাগুলো মূল client-এর; আধুনিক client-ভেদে কিছুটা আলাদা হতে পারে।)

নিচের stepper আর simulator একটি ছোট swarm দেখায়: seeder S-এর কাছে পাঁচটি chunk (০–৪) সবই আছে; চারজন peer A, B, C, D-র কাছে কিছু কিছু। প্রতি রাউন্ডে প্রত্যেকে সর্বোচ্চ একটি chunk আপলোড আর একটি ডাউনলোড করতে পারে, আর S রাউন্ড ২-এর পর চলে যায়। Bit-স্ট্রিং “10100” মানে chunk ০ আর ২ আছে।

// Swarm: seed S (all 5 chunks) + peers A-D. Every round each node UPLOADS at
// most one chunk and each peer DOWNLOADS at most one. S LEAVES after round 2.
// A peer tries its missing chunks in order of preference and takes the first one
// that some free node can give (other peers first, the seed last).
function run(rarestFirst) {
  const have = { S: "11111", A: "10100", B: "00110", C: "11000", D: "11000" };
  const peers = ["A", "B", "C", "D"], ids = [0, 1, 2, 3, 4];
  for (let round = 1; round <= 5; round++) {
    const copies = ids.map(c => peers.filter(p => have[p][c] === "1").length);
    const busy = new Set(round > 2 ? ["S"] : []), got = [];
    for (const p of peers) {
      const want = ids.filter(c => have[p][c] === "0")
        .sort((x, y) => rarestFirst ? copies[x] - copies[y] || x - y : x - y);
      for (const c of want) {
        const from = [...peers.filter(q => q !== p), "S"]
          .find(q => have[q][c] === "1" && !busy.has(q));
        if (from) { busy.add(from); got.push(`${p}<-${c}(${from})`); break; }
      }
    }
    for (const g of got) {                      // all transfers of a round end together
      const p = g[0], c = +g[3];
      have[p] = have[p].slice(0, c) + "1" + have[p].slice(c + 1);
    }
    console.log(`round ${round}: ${got.join(" ").padEnd(36)}| ` +
      peers.map(p => p + ":" + have[p]).join(" "));
    if (peers.every(p => !have[p].includes("0"))) return console.log("  -> everyone complete");
  }
  console.log("  -> stuck: chunk 4 left with the seed, no peer can finish");
}
console.log("== rarest first =="); run(true);
console.log("== in order (lowest chunk first) =="); run(false);

== rarest first ==
round 1: A<-4(S) B<-1(C) C<-3(B) D<-2(A)     | A:10101 B:01110 C:11010 D:11100
round 2: A<-3(B) B<-4(A) C<-4(S) D<-3(C)     | A:10111 B:01111 C:11011 D:11110
round 3: A<-1(B) B<-0(A) C<-2(D) D<-4(C)     | A:11111 B:11111 C:11111 D:11111
  -> everyone complete
== in order (lowest chunk first) ==
round 1: A<-1(C) B<-0(A) C<-2(B) D<-2(S)     | A:11100 B:10110 C:11100 D:11100
round 2: A<-3(B) B<-1(A) C<-3(S)             | A:11110 B:11110 C:11110 D:11100
round 3: D<-3(A)                             | A:11110 B:11110 C:11110 D:11110
round 4:                                     | A:11110 B:11110 C:11110 D:11110
round 5:                                     | A:11110 B:11110 C:11110 D:11110
  -> stuck: chunk 4 left with the seed, no peer can finish

৫ · Process, socket আর ঠিকানা — অ্যাপ কীভাবে transport-কে ডাকে

নেটওয়ার্কে আসলে কথা বলে দুটি process — চলমান প্রোগ্রাম (process কী, তা অপারেটিং সিস্টেম কোর্সের process পর্বে আছে)। আলাদা কম্পিউটারের দুই process কথা বলে নেটওয়ার্কে বার্তা আদান-প্রদান করে। যে process যোগাযোগ শুরু করে সে client process, যে অপেক্ষা করে সে server process.

Process আর নেটওয়ার্কের মাঝের দরজা হলো socket — পর্ব ২৭-এ বিস্তারিত দেখেছেন। দরজার এপাশ অ্যাপের হাতে — কী লিখবেন, কখন লিখবেন; ওপাশ kernel-এর হাতে — retransmission, congestion control. অ্যাপের নিয়ন্ত্রণ তাই মূলত কোন transport বাছবেন আর কিছু প্যারামিটার, যেমন buffer-এর মাপ। Socket API-র পুরো প্রোগ্রামিং মডিউল ৭-এ (পর্ব ৪১–৪৫)।

Process-এর ঠিকানা: IP + port

চিঠি পাঠাতে লাগে বাড়ির ঠিকানা আর প্রাপকের নাম। একটি process-কে বার্তা পাঠাতেও দুটি জিনিস লাগে: যে host-এ সে চলছে তার IP ঠিকানা, আর সেই host-এর ভেতরে তার socket-এর port নম্বর। ওয়েব সার্ভার সাধারণত TCP 443 (HTTPS) বা 80 (HTTP)-এ, মেইল সার্ভার 25-এ, DNS সার্ভার 53-এ শোনে — পরিচিত port-এর তালিকা পর্ব ২৭-এ। শুধু IP যথেষ্ট নয়, কারণ একই host-এ একসাথে অনেক process নেটওয়ার্ক ব্যবহার করে।

অ্যাপ নেটওয়ার্কের কাছে কী চায় — আর কোন protocol কী বাছে

পর্ব ২৭-এ চারটি চাহিদা দেখেছেন: ডেটার নির্ভুলতা (data integrity), throughput, সময় (timing) আর নিরাপত্তা। এখানে বাস্তব অ্যাপগুলোকে এই চার চাহিদার মাপকাঠিতে সাজাই — application-layer নকশার প্রথম সিদ্ধান্ত এখান থেকেই আসে:

আর নিরাপত্তা? আজ প্রায় প্রতিটি সারিতে একই উত্তর: encryption আর সার্ভার যাচাই লাগবে। TCP বা UDP নিজে তা দেয় না; অ্যাপ সেটি পায় TCP-র ওপর TLS বসিয়ে (HTTPS, IMAPS, SMTP-এর STARTTLS), বা QUIC ব্যবহার করে, যার ভেতরেই TLS 1.3 আছে (পর্ব ৩৩)। TLS-কে কখনো কখনো “স্তর ৪.৫” বলা হয় — প্রযুক্তিগতভাবে এটি application-এর অংশ হিসেবে চলে, অ্যাপের লাইব্রেরিতে, OS-এর transport-এ নয়। বিস্তারিত পর্ব ৪৮-এ।

৬ · Protocol নকশার বড় সিদ্ধান্তগুলো

নতুন protocol বানাতে বা চেনা protocol বুঝতে কয়েকটি মৌলিক প্রশ্নের উত্তর লাগে — পরের ছয়টি পর্বের প্রতিটি protocol-কে এই মাপকাঠিতে চিনতে পারবেন।

Text বনাম binary

Text protocol-এ বার্তা মানুষের পড়ার মতো লেখা — সাধারণত ASCII অক্ষরে, প্রতিটি লাইন শেষে CRLF — carriage return আর line feed, দুটি বাইট। HTTP/1.1, SMTP, POP3, IMAP, FTP, SIP — সব text. সুবিধা: একটি সাধারণ টার্মিনাল দিয়েই কথা বলা যায়, ভুল খোঁজা সহজ, নতুন header যোগ করা সহজ। অসুবিধা: আকার বড়, আর parse করতে বেশি কাজ — সংখ্যাকে অক্ষর থেকে রূপান্তর, লাইন কোথায় শেষ খোঁজা, বাড়তি space বা ছোট-বড় হাতের অক্ষরের মতো অস্পষ্টতা সামলানো।

Binary protocol-এ প্রতিটি ঘর নির্দিষ্ট বাইটে, নির্দিষ্ট মাপে: DNS-এর ১২ বাইটের header, HTTP/2-এর ৯ বাইটের frame header, QUIC, TLS, MQTT. সুবিধা: ছোট, দ্রুত, অস্পষ্টতা কম, আর একটি সংযোগে অনেক স্রোত পাশাপাশি চালানোর মতো কাজ (HTTP/2-এর multiplexing) সহজে করা যায়। অসুবিধা: পড়তে Wireshark-এর মতো টুল লাগে। HTTP/2 কেন text ছেড়ে binary হলো, তা পর্ব ৩৭-এ।

Text (SMTP, উদাহরণ)                    Binary (DNS header-এর প্রথম ৪ বাইট, hex)
C: MAIL FROM:<rahim@example.com>       1a 2b 01 00
S: 250 OK                              └─ ID=0x1a2b, flags=0x0100 (প্রশ্ন, recursion চাই)

Stateless বনাম stateful

একটি stateless protocol-এ সার্ভার আগের অনুরোধ মনে রাখে না — প্রতিটি অনুরোধ নিজেই সম্পূর্ণ। HTTP এমন: সার্ভারের কাছে আপনার দ্বিতীয় অনুরোধ প্রথমটির সাথে protocol-এর দিক থেকে সম্পর্কহীন। DNS query-ও তাই। সুবিধা: যেকোনো সার্ভার যেকোনো অনুরোধের উত্তর দিতে পারে, তাই হাজার সার্ভারে ভাগ করা সহজ। “লগইন করা আছি” মনে রাখতে HTTP-র ওপর cookie বসিয়ে অ্যাপ নিজে অবস্থা রাখে (পর্ব ৩৬)।

Stateful protocol-এ সংযোগ বা session-এর একটি অবস্থা থাকে, আর একই command-এর মানে সেই অবস্থার ওপর নির্ভর করে। SMTP-তে DATA পাঠানো যায় শুধু MAIL FROM আর RCPT TO-এর পরে; IMAP-এ আগে একটি mailbox SELECT করলে তবেই তার চিঠি পড়া যায়; FTP মনে রাখে আপনি কোন ফোল্ডারে আছেন। খরচ: সার্ভারকে প্রতিটি client-এর অবস্থা রাখতে হয়।

একটি ফাঁদ: “stateless” মানে protocol-এর কথা, সার্ভারের নয়। নিচের KV/1 protocol-এ প্রতিটি অনুরোধের syntax স্বাধীন, কিন্তু সার্ভার একটি ডেটার ভান্ডার রাখে — তার অ্যাপের অবস্থা আছে। ডেটাবেস সার্ভার অবস্থা না রাখলে তো কোনো কাজেরই নয়!

Push বনাম pull

যে পক্ষ ডেটার মালিক, সে নিজে পাঠালে push; যে চায়, সে গিয়ে আনলে pull. HTTP মূলত pull — ব্রাউজার চায়, সার্ভার দেয়। ইমেইলে দুটোই: আপনার মেইল সার্ভার প্রাপকের মেইল সার্ভারে SMTP দিয়ে চিঠি push করে, আর প্রাপক নিজের মেইল অ্যাপে IMAP দিয়ে তা pull করেন (পর্ব ৩৯)। মোবাইলের notification-এ সার্ভার push করে — এজন্য ফোন একটি দীর্ঘস্থায়ী সংযোগ খুলে রাখে, কারণ NAT-এর পেছনের ফোনে বাইরে থেকে সংযোগ খোলা যায় না।

যোগাযোগের তিন ধাঁচ

Publish-subscribe-এর সবচেয়ে পরিচিত উদাহরণ MQTT — IoT-র জন্য বানানো হালকা binary protocol, সাধারণত TCP port 1883-এ চলে, TLS-সহ 8883-এ। ধরুন একটি মাছের খামারে পুকুরের পানির তাপমাত্রা আর অক্সিজেন মাপার সেন্সর: সেন্সরটি প্রতি মিনিটে farm/pond1/oxygen topic-এ একটি ছোট বার্তা publish করে। খামারির ফোনের অ্যাপ, একটি সতর্কবার্তা পাঠানোর সার্ভিস আর একটি ডেটাবেস — তিনজনই এই topic-এ subscribe করে আছে। সেন্সরকে তাদের কারও ঠিকানা জানতে হয় না; নতুন একজন subscriber যোগ করতে সেন্সরের কোড বদলাতে হয় না। দুর্বল সংযোগের কথা ভেবে MQTT-তে ছোট header আর বার্তা পৌঁছানোর তিনটি নিশ্চয়তা-স্তর আছে।

HTTP-র ওপর API-র চার ধাঁচ — এক নজরে

আজকের অ্যাপের বেশিরভাগ যোগাযোগ চলে API দিয়ে — এক প্রোগ্রাম আরেক প্রোগ্রামকে ডাকে। বেশিরভাগই HTTP-র ওপরে বসানো, কিন্তু ধাঁচ আলাদা:

একটি বড় অ্যাপ প্রায়ই সবগুলোই ব্যবহার করে — বাইরে REST বা GraphQL, ভেতরে gRPC, লাইভ আপডেটে WebSocket.

৭ · একটি protocol নিজে পড়া, parse করা আর চালানো

RFC পড়ার কৌশল — MUST, SHOULD, MAY

RFC-র ভাষা প্রথমে শুকনো লাগে, কিন্তু কয়েকটি শব্দ চিনলে পড়া অনেক সহজ। RFC 2119 (১৯৯৭) কিছু শব্দের নির্দিষ্ট মানে ঠিক করে দেয়, আর RFC 8174 (২০১৭) স্পষ্ট করে যে এই বিশেষ মানে শুধু তখনই, যখন শব্দগুলো বড় হাতের অক্ষরে লেখা:

• MUST / REQUIRED / SHALL — বাধ্যতামূলক। না মানলে আপনার implementation এই protocol-এর নয়। (MUST NOT — কোনো অবস্থাতেই নয়।)
• SHOULD / RECOMMENDED — জোরালো সুপারিশ; বিশেষ, ভালোভাবে বোঝা কারণ থাকলে না মানা যায়, কিন্তু ফল বুঝে। (SHOULD NOT একই রকম।)
• MAY / OPTIONAL — সত্যিই ঐচ্ছিক। অন্য পক্ষকে এমনভাবে লিখতে হবে যাতে আপনি করলেও, না করলেও কাজ চলে।

পড়ার অভ্যাস: আগে Abstract আর “Terminology”; বার্তার গঠন থাকে ABNF ব্যাকরণে বা বাক্স-আঁকা diagram-এ; “Security Considerations” বাদ নয়; আর rfc-editor.org-এ দেখে নিন RFC-টি “Obsoleted by” কি না।

একটি খেলনা protocol: KV/1

অনুশীলনের জন্য এই পর্বে একটি ছোট key-value protocol বানাই — Redis-এর মতো ডেটাবেসের সরল “inline” command-এর ধাঁচে। নিচে তার “RFC” — মাত্র কয়েক লাইন, কিন্তু ঠিক বাস্তবের মতো ভাষায়:

KV/1 — a toy key-value protocol over TCP (for learning only)
1. A request is one line of ASCII text. Every line MUST end with CRLF (0x0D 0x0A).
2. Words MUST be separated by exactly one SP (0x20).
3. Commands: SET key value | GET key | DEL key | QUIT
   Servers MUST accept command names in any letter case. Keys are case-sensitive.
4. A key MUST match [A-Za-z0-9_]{1,15}. A value MUST NOT contain SP or CRLF.
5. The server MUST send exactly one reply line per request, in order:
   SET -> OK | GET -> VALUE v or NOT_FOUND | DEL -> DELETED or NOT_FOUND
   QUIT -> BYE, then the server closes the connection | anything else -> ERR reason
6. A client SHOULD send QUIT before closing. A server MAY close an idle connection.

অংশ ১-এর চারটি উপাদানই এখানে আছে: বার্তার ধরন (চারটি command), syntax (লাইন, CRLF, একটি space), semantics (NOT_FOUND মানে “এই key নেই”) আর নিয়ম (প্রতিটি অনুরোধে ঠিক একটি উত্তর, ক্রমমতো)। আর আছে অবস্থা — সার্ভারের ভান্ডার।

Byte-স্রোত থেকে বার্তা — framing

অনেকে প্রথমবার এখানে ভুল করেন: TCP দেয় byte-স্রোত, বার্তা নয় (পর্ব ২৭)। Client দুবার write() করলে সার্ভার একবারে দুটো লাইন পেতে পারে, বা একটি লাইনের অর্ধেক। তাই protocol-কেই বলে দিতে হয় একটি বার্তা কোথায় শেষ — একে বলে framing. KV/1-এ framing হলো CRLF; HTTP/1.1-এ header-এর শেষে একটি ফাঁকা লাইন আর body-র দৈর্ঘ্য Content-Length-এ; binary protocol-এ সাধারণত শুরুতে একটি দৈর্ঘ্যের ঘর। নিচের parser বাইটগুলো ইচ্ছা করে এলোমেলো টুকরোয় পায়।

// KV/1 - a toy line-based text protocol (like a tiny Redis "inline" format).
// Syntax: COMMAND SP key [SP value] CRLF.  Semantics + state: a server-side store.
const store = new Map();                 // the server's STATE survives between requests
const ARITY = { SET: 3, GET: 2, DEL: 2, QUIT: 1 };
function handle(line) {
  const words = line.split(" ");
  const cmd = words[0].toUpperCase();    // spec: command names are case-insensitive
  if (!(cmd in ARITY)) return "ERR unknown command";              // syntax: bad verb
  if (words.length !== ARITY[cmd]) return "ERR wrong number of arguments";
  const [, key, value] = words;
  if (!/^[A-Za-z0-9_]{1,15}$/.test(key ?? "x")) return "ERR bad key";
  if (cmd === "SET") { store.set(key, value); return "OK"; }       // semantics
  if (cmd === "GET") return store.has(key) ? "VALUE " + store.get(key) : "NOT_FOUND";
  if (cmd === "DEL") return store.delete(key) ? "DELETED" : "NOT_FOUND";
  return "BYE";
}
// Bytes arrive from a TCP byte stream in arbitrary pieces: frame them by CRLF.
const chunks = ["SET city Dhaka\r\nGE", "T city\r\nget city\r\nSET  x 1\r\n",
  "PUT x 1\r\nDEL city\r\nGET city\r\nSET roll 42", "\r\nQUIT\r\n"];
let buf = "";
chunks.forEach((c, i) => {
  buf += c;
  console.log(`-- chunk ${i + 1} arrives (${c.length} bytes)`);
  let at;
  while ((at = buf.indexOf("\r\n")) >= 0) {         // one complete line = one request
    const line = buf.slice(0, at); buf = buf.slice(at + 2);
    console.log(`C: ${line.padEnd(16)} S: ${handle(line)}`);
  }
  if (buf) console.log(`   (waiting: "${buf}" has no CRLF yet)`);
});
console.log("final state:", JSON.stringify(Object.fromEntries(store)));

-- chunk 1 arrives (18 bytes)
C: SET city Dhaka   S: OK
   (waiting: "GE" has no CRLF yet)
-- chunk 2 arrives (28 bytes)
C: GET city         S: VALUE Dhaka
C: get city         S: VALUE Dhaka
C: SET  x 1         S: ERR wrong number of arguments
-- chunk 3 arrives (40 bytes)
C: PUT x 1          S: ERR unknown command
C: DEL city         S: DELETED
C: GET city         S: NOT_FOUND
   (waiting: "SET roll 42" has no CRLF yet)
-- chunk 4 arrives (8 bytes)
C: SET roll 42      S: OK
C: QUIT             S: BYE
final state: {"roll":"42"}

এবার একই protocol-এ একটি পুরো আলাপ ধাপে ধাপে — বাঁ দিকে তারে যাওয়া বাইট, ডান দিকে সার্ভারের ভান্ডার। নিচের C প্রোগ্রাম ঠিক এই আলাপটিই চালাবে।

আসল TCP-তে: fork করা client আর server, loopback-এ

নিচের C প্রোগ্রাম 127.0.0.1-এ একটি TCP socket খোলে (port 0 মানে kernel নিজেই একটি খালি port বেছে দেবে), তারপর fork() করে: child process হয় KV/1 সার্ভার, parent হয় client. Client আটটি অনুরোধ পাঠায়, প্রতিটির পর এক লাইনের উত্তর পড়ে, আর পুরো আলাপ ছাপে। ছাপার কাজ শুধু parent করে, তাই আউটপুটের ক্রম প্রতিবার একই। (Socket ফাংশনের বিস্তারিত মডিউল ৭-এ।)

#include <stdio.h>
#include <string.h>
#include <strings.h>
#include <unistd.h>
#include <sys/wait.h>
#include <arpa/inet.h>
#define IS(x) (!strcasecmp(cmd, x))                /* command names: any letter case */
static void serve(int c) {                         /* KV/1 server: the store is its STATE */
    char k[8][16], v[8][32], line[128], cmd[8], a[16], b[32]; int n = 0; FILE *in = fdopen(c, "r");
    while (fgets(line, sizeof line, in)) {               /* one line = one request */
        cmd[0] = 0; int f = sscanf(line, "%7s %15s %31s", cmd, a, b), i = 0;
        while (f > 1 && i < n && strcmp(k[i], a)) i++;      /* look the key up */
        if (IS("SET") && f == 3 && i < 8) { n += (i == n); strcpy(k[i], a); strcpy(v[i], b); dprintf(c, "OK\r\n"); }
        else if (IS("GET") && f == 2 && i < n) dprintf(c, "VALUE %s\r\n", v[i]);
        else if (IS("DEL") && f == 2 && i < n) {      /* move the last entry into the hole */
            if (i < --n) { strcpy(k[i], k[n]); strcpy(v[i], v[n]); } dprintf(c, "DELETED\r\n"); }
        else if ((IS("GET") || IS("DEL")) && f == 2) dprintf(c, "NOT_FOUND\r\n");
        else if (IS("QUIT") && f == 1) { dprintf(c, "BYE\r\n"); break; }
        else dprintf(c, "ERR bad request\r\n");
    }
}
int main(void) {
    const char *req[] = {"SET city Dhaka", "GET city", "SET city Khulna", "GET city",
                         "DEL city", "GET city", "PUT x 1", "QUIT"};
    struct sockaddr_in sa = {.sin_family = AF_INET}; socklen_t len = sizeof sa; char line[128];
    sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK);          /* 127.0.0.1, port 0 = any */
    int ls = socket(AF_INET, SOCK_STREAM, 0); bind(ls, (struct sockaddr *)&sa, sizeof sa); listen(ls, 1);
    getsockname(ls, (struct sockaddr *)&sa, &len); fflush(stdout);   /* learn the free port */
    if (fork() == 0) { serve(accept(ls, NULL, NULL)); _exit(0); }  /* child = server */
    int s = socket(AF_INET, SOCK_STREAM, 0);                         /* parent = client */
    connect(s, (struct sockaddr *)&sa, sizeof sa); FILE *in = fdopen(s, "r");
    for (int i = 0; i < 8 && dprintf(s, "%s\r\n", req[i]) > 0 && fgets(line, sizeof line, in); i++) {
        line[strcspn(line, "\r\n")] = 0; printf("C: %-16s S: %s\n", req[i], line); }   /* one reply each */
    wait(NULL); return 0;
}

C: SET city Dhaka   S: OK
C: GET city         S: VALUE Dhaka
C: SET city Khulna  S: OK
C: GET city         S: VALUE Khulna
C: DEL city         S: DELETED
C: GET city         S: NOT_FOUND
C: PUT x 1          S: ERR bad request
C: QUIT             S: BYE

৮ · একটি ক্লিকের পেছনে — URL লিখে Enter চাপলে কী হয়

নেটওয়ার্কিং ইন্টারভিউর সবচেয়ে বিখ্যাত প্রশ্ন: “ব্রাউজারে একটি ঠিকানা লিখে Enter চাপলে কী কী ঘটে?” এই মডিউলের প্রতিটি পর্ব তার একেকটি ধাপ; এখানে শুধু মানচিত্র। ধরা যাক আপনি লিখলেন https://www.example.com/news, আর হিসাবের সুবিধার জন্য ধরি: resolver পর্যন্ত DNS-এর উত্তর আসতে ২০ ms, আর সার্ভার পর্যন্ত RTT ৩০ ms, সার্ভারের নিজের কাজে ১০ ms.

লক্ষ করুন, এই ১২০ ms-এর বেশিরভাগই RTT-র গুণিতক — ব্যান্ডউইথ নয়, দূরত্ব আর ধাপের সংখ্যা। তাই আধুনিক protocol ধাপ কমায় (TLS 1.3, QUIC, DNS cache), আর CDN দূরত্ব কমায়। ইন্টারভিউতে ভালো উত্তর মানে ঠিক এই stepper-এর তিনটি সারি: ধাপের ক্রম, প্রতিটিতে কোন protocol, আর কোথায় সময় যায়। পূর্ণ ইন্টারভিউ-রূপ পর্ব ৬২-এ।

৯ · AI-এর যুগে application protocol নকশা

REST না gRPC, P2P-র অঙ্ক, একটি chat protocol-এর নকশা — AI এসবে দ্রুত, গোছানো উত্তর দেয়, কিন্তু কিছু চেনা ভুলও করে:

AI-এর protocol পরামর্শ মানার আগে — চেকলিস্ট

• বিতরণ-সময় বা throughput-এর হিসাব নিজে আবার করেছি, একক (bit বনাম byte, M বনাম Mi) মিলিয়েছি
• উল্লিখিত প্রতিটি RFC rfc-editor.org-এ খুঁজে শিরোনাম আর “Obsoleted by” দেখেছি
• Parser-কে ভাঙা আর জোড়া লাগা টুকরো, ভুল syntax আর অচেনা command দিয়ে পরীক্ষা করেছি
• নিজের ল্যাপটপ বা VM-এর loopback-এ চালিয়ে দেখেছি, আর নিজের ল্যাবের packet capture (পর্ব ৫৫) দিয়ে তারে কী যাচ্ছে মিলিয়েছি
• শুরু থেকেই TLS রেখেছি, আর firewall-এ শুধু দরকারি port খুলেছি