TCP flow control — sliding window আর receive window

১ · সমস্যা — দ্রুত প্রেরক, ধীর প্রাপক

পর্ব ৩০-এ (TCP-র নির্ভরযোগ্যতা) দেখেছেন, TCP প্রতিটি byte-এ নম্বর দেয়, ACK নেয় আর হারানো byte আবার পাঠায়। কিন্তু সব byte ঠিকঠাক পৌঁছালেও একটি সমস্যা থেকে যায়। ধরুন আপনার ফোনে একটি ভিডিও অ্যাপ সার্ভার থেকে ডেটা নামাচ্ছে। সার্ভার শক্তিশালী মেশিন, সেকেন্ডে কয়েকশো মেগাবিট ঠেলতে পারে। অথচ ফোনের অ্যাপটি তখন ব্যস্ত — ভিডিও decode করছে, বা ব্যবহারকারী অন্য অ্যাপে চলে গেছেন। অ্যাপ socket থেকে পড়ছে না।

তাহলে আসা byte-গুলো যায় কোথায়? Kernel প্রতিটি TCP সংযোগের জন্য একটি receive buffer রাখে — অ্যাপ recv() ডেকে না পড়া পর্যন্ত byte সেখানে জমে থাকে। Buffer-এর আকার সীমিত। প্রেরক থামার কোনো সংকেত না পেলে buffer ভরে যাবে, তারপর নতুন byte ফেলে দিতে হবে — আর ফেলে দেওয়া byte আবার পাঠাতে হবে, যা নিছক অপচয়। এই সমস্যার সমাধানকেই বলে flow control: প্রেরকের গতিকে প্রাপকের পড়ার গতির সাথে মেলানো।

Flow control বনাম congestion control — গুলিয়ে ফেলবেন না

দুটিই প্রেরককে ধীর করে, তাই নতুনরা প্রায়ই এক ভাবেন। কিন্তু দুটি সম্পূর্ণ ভিন্ন সমস্যার সমাধান:

পর্ব ১০-এ (Framing আর ARQ) link স্তরে flow control আর sliding window দেখেছেন — সেখানে window মাপা হতো frame-এর সংখ্যায়, প্রেরক আর প্রাপক একই link-এর দুই মাথা। TCP-র sliding window একই ধারণা, কিন্তু তিনটি বড় পার্থক্য: (১) window মাপা হয় byte-এ, segment-এ নয়; (২) window-এর আকার স্থির নয় — প্রাপক প্রতিটি segment-এ নতুন করে জানায়; (৩) দুই প্রান্তের মাঝে পুরো ইন্টারনেট, তাই ACK হারাতে পারে, দেরিতে আসতে পারে। Window-এর আকার বনাম efficiency-র হিসাব (W ≥ 1 + 2a) পর্ব ১০-এই আছে; এখানে আর পুনরাবৃত্তি করব না।

২ · প্রাপকের দিক — receive buffer আর rwnd

প্রাপকের buffer-কে একটি লম্বা তাক ভাবুন, যেখানে byte বাঁ থেকে ডানে সাজানো। দুটি নম্বর দিয়ে এর অবস্থা পুরোপুরি বোঝা যায় (Kurose-Ross-এর পাঠ্যবইয়ের নাম ব্যবহার করছি, বিশ্ববিদ্যালয়ের পরীক্ষায় এগুলোই বেশি আসে):

• LastByteRead — অ্যাপ recv() দিয়ে সর্বশেষ যে byte পর্যন্ত পড়ে নিয়েছে। এর আগের byte buffer থেকে বিদায় নিয়েছে।
• LastByteRcvd — নেটওয়ার্ক থেকে এসে buffer-এ বসা সর্বশেষ byte-এর নম্বর (ধরে নিচ্ছি সব ক্রম মেনে এসেছে)।

তাহলে buffer-এ জমে থাকা, অ্যাপের না-পড়া byte = LastByteRcvd − LastByteRead. Buffer উপচে না পড়ার শর্ত: LastByteRcvd − LastByteRead ≤ RcvBuffer. বাকি খালি জায়গাই প্রাপক ঘোষণা করে:

      অ্যাপ পড়ে নিয়েছে        buffer-এ জমা (না-পড়া)      খালি জায়গা
  ... ──────────────────┬──────────────────────────┬───────────────────┐
                        │▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│                   │
  ... ──────────────────┴──────────────────────────┴───────────────────┘
                  LastByteRead               LastByteRcvd
                        │◄──────────────── RcvBuffer ─────────────────►│
                                                   │◄────── rwnd ─────►│

এই rwnd প্রাপক বসায় তার পাঠানো প্রতিটি segment-এর TCP header-এর ১৬-bit Window ঘরে — আলাদা কোনো বার্তা লাগে না। ACK-এর সাথে window-ও যায়, আর দুই দিকে ডেটা চললে ডেটার segment-এই দুটি ভেসে যায়। Header-এর পুরো নকশা পর্ব ২৯-এ (TCP সংযোগ)। TCP full-duplex, তাই দুই প্রান্তেরই নিজস্ব receive buffer আর নিজস্ব rwnd আছে — প্রতিটি দিকের flow control আলাদা।

প্রেরকের দিক — একটি মাত্র অসমতা

প্রেরক দুটি নম্বর রাখে: LastByteSent (সর্বশেষ পাঠানো byte) আর LastByteAcked (যে পর্যন্ত cumulative ACK এসেছে)। এদের ব্যবধানই পথে থাকা, অস্বীকৃত byte — “bytes in flight”. নিয়ম:

কেন এটি buffer উপচানো ঠেকায় — ছোট প্রমাণ: ধরুন প্রাপক এক মুহূর্তে ACK পাঠাল, যখন তার অবস্থা LastByteRcvd = r, LastByteRead = p. ACK-এ থাকে “r পর্যন্ত পেয়েছি” আর rwnd = RcvBuffer − (r − p). প্রেরক এই ACK পেয়ে LastByteAcked = r ধরে, তাই সে সর্বোচ্চ LastByteSent = r + rwnd = RcvBuffer + p পর্যন্ত পাঠাতে পারে। এই সব byte পৌঁছালে buffer-এ জমা হবে LastByteSent − LastByteRead_তখন ≤ RcvBuffer + p − LastByteRead_তখন. অ্যাপ শুধু সামনে পড়ে, পেছনে যায় না, তাই LastByteRead_তখন ≥ p — ফলে জমা ≤ RcvBuffer. অর্থাৎ প্রাপক যত দেরিতেই পড়ুক, প্রেরক নিয়ম মানলে buffer কখনো উপচায় না। (শর্ত একটাই: প্রাপক আগে দেওয়া প্রতিশ্রুতি ফিরিয়ে নেবে না — অংশ ৩-এর সতর্কবার্তা দেখুন।)

৩ · প্রেরকের byte-স্রোতে sliding window

প্রেরকের দিক থেকে পাঠানোর অপেক্ষায় থাকা সব ডেটাকে একটি লম্বা byte-এর সারি ভাবুন। যেকোনো মুহূর্তে সারিটি চার ভাগে ভাগ হয়:

Window-এর বাঁ কিনারা = LastByteAcked + 1, ডান কিনারা = LastByteAcked + rwnd. নতুন ACK এলে বাঁ কিনারা ডানে সরে (window “বন্ধ হয়” বাঁ দিক থেকে)। প্রাপকের অ্যাপ পড়লে নতুন rwnd বড় হয়, তাই ডান কিনারা ডানে সরে (window “খোলে”)। নিচের stepper-এ ১,০০০ byte-এর একটি সারি, প্রতিটি ঘর ১০০ byte; প্রেরক ১০০ byte-এর segment পাঠায়।

৪ · Simulator — দ্রুত প্রেরক, ধীর অ্যাপ

এবার সূত্রগুলো একসাথে চালিয়ে দেখি। নিচের simulator-এ প্রাপকের buffer ৪,০০০ byte, প্রেরকের হাতে ৯,০০০ byte-এর একটি ফাইল। প্রতিটি ধাপ = একটি RTT: প্রেরক যতটা পারে পাঠায়, প্রাপক পায়, অ্যাপ appReads তালিকা অনুযায়ী কিছু পড়ে, তারপর প্রাপক ACK আর নতুন rwnd পাঠায়। ধাপ ৩–৪-এ অ্যাপ কিছুই পড়ে না (ব্যবহারকারী অন্য অ্যাপে), আর ধাপ ৫-এ অ্যাপ পড়লে প্রাপক যে window update পাঠায় সেটি পথে হারিয়ে যায় — ইচ্ছে করে বানানো ঘটনা, যাতে persist timer-এর কাজ দেখা যায়। সব কিছু নির্ধারিত, তাই প্রতিবার একই ফল।

// TCP flow control: fast sender, 4000-byte receive buffer, slow app. 1 step = 1 RTT.
// LB = LastByte (Sent / Acked by the sender; Read / Rcvd at the receiver)
const RcvBuffer = 4000, FILE = 9000;
const appReads = [1000, 1000, 0, 0, 2000, 0, 2000, 2000, 2000];  // bytes the app reads per step
let lastSent = 0, lastAcked = 0, rwnd = RcvBuffer;   // sender's view (rwnd = last advertised)
let lastRcvd = 0, lastRead = 0, probeAt = 0, backoff = 1;
const pad = (x, n) => String(x).padStart(n);
console.log("step sent LBSent inFlight LBAcked | read LBRead LBRcvd rwnd | note");
for (let t = 1; lastRead < FILE; t++) {
  let sent = 0, note = "", ackArrives = true;
  if (rwnd > 0) {                                     // rule: LastByteSent - LastByteAcked <= rwnd
    sent = Math.min(rwnd - (lastSent - lastAcked), FILE - lastSent);
    lastSent += sent; lastRcvd += sent;               // fits: the receiver promised this space
  } else if (t === probeAt) note = "persist timer fired: window probe ->";
  else { note = "zero window, sender waits"; ackArrives = false; }
  const inFlight = lastSent - lastAcked;
  const wasZero = lastRcvd - lastRead === RcvBuffer;
  const read = Math.min(appReads[t - 1], lastRcvd - lastRead);
  lastRead += read;
  const adv = RcvBuffer - (lastRcvd - lastRead);      // rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)
  if (wasZero && adv > 0 && rwnd === 0 && t !== probeAt) {
    note += "; window update rwnd=" + adv + " LOST"; ackArrives = false;
  }
  if (ackArrives) {
    lastAcked = lastRcvd; rwnd = adv;
    if (rwnd === 0) { probeAt = t + backoff; note += (note ? " " : "") + "rwnd=0, next probe at step " + probeAt; backoff *= 2; }
    else if (note) note += " reply rwnd=" + rwnd + ", resume";
  }
  console.log(`${pad(t, 3)} ${pad(sent, 5)} ${pad(lastSent, 6)} ${pad(inFlight, 8)} ${pad(lastAcked, 7)} | ${pad(read, 4)} ${pad(lastRead, 6)} ${pad(lastRcvd, 6)} ${pad(adv, 4)} | ${note}`);
}
console.log("Without the persist timer, a lost window update means deadlock:");
console.log("sender waits for rwnd > 0, receiver waits for data. Neither ever sends again.");

step sent LBSent inFlight LBAcked | read LBRead LBRcvd rwnd | note
  1  4000   4000     4000    4000 | 1000   1000   4000 1000 |
  2  1000   5000     1000    5000 | 1000   2000   5000 1000 |
  3  1000   6000     1000    6000 |    0   2000   6000    0 | rwnd=0, next probe at step 4
  4     0   6000        0    6000 |    0   2000   6000    0 | persist timer fired: window probe -> rwnd=0, next probe at step 6
  5     0   6000        0    6000 | 2000   4000   6000 2000 | zero window, sender waits; window update rwnd=2000 LOST
  6     0   6000        0    6000 |    0   4000   6000 2000 | persist timer fired: window probe -> reply rwnd=2000, resume
  7  2000   8000     2000    8000 | 2000   6000   8000 2000 |
  8  1000   9000     1000    9000 | 2000   8000   9000 3000 |
  9     0   9000        0    9000 | 1000   9000   9000 4000 |
Without the persist timer, a lost window update means deadlock:
sender waits for rwnd > 0, receiver waits for data. Neither ever sends again.

অ্যাপ ধীরে পড়লে window কেন ছোট হয়

উপরের ধাপ ২-এ একটি গুরুত্বপূর্ণ বাস্তব শিক্ষা লুকিয়ে আছে। Link ১ Gbps হোক বা ১০ Mbps, প্রতি RTT-তে প্রেরক পাঠাতে পারছে ঠিক ততটাই, যতটা অ্যাপ আগের RTT-তে পড়েছে। সার্ভার থেকে ফাইল নামানো ধীর লাগলে সমস্যা সবসময় নেটওয়ার্কে নয় — হতে পারে আপনার নিজের প্রোগ্রাম socket থেকে ছোট ছোট টুকরোয়, ধীরে পড়ছে (যেমন প্রতিটি টুকরো পড়ে ডিস্কে লিখে তারপর আবার পড়া, আর ডিস্ক ধীর)। এমন হলে প্যাকেট capture-এ দেখা যায় প্রাপকের ঘোষিত window ক্রমশ ছোট হচ্ছে, কখনো ০ — Wireshark এগুলোকে “TCP ZeroWindow” আর “TCP Window Full” নামে চিহ্নিত করে। একে বলে backpressure: ধীর ভোক্তার চাপ উল্টো দিকে প্রেরক পর্যন্ত পৌঁছায়। ভালো খবর হলো এটাই কাঙ্ক্ষিত আচরণ — নইলে প্রেরক প্রাপকের মেমরি ভরিয়ে ফেলত।

৫ · Zero window, persist timer আর window probe

rwnd = ০ হলে প্রেরক থামে — একে বলে zero window. এবার কল্পনা করুন অ্যাপ পড়ল, buffer-এ জায়গা হলো। প্রাপক একটি window update পাঠায় — ডেটাহীন একটি ACK, যার window ঘরে নতুন সংখ্যা। কিন্তু TCP ডেটাহীন ACK-এর কোনো ACK নেয় না, আর হারালে আবার পাঠায়ও না (পর্ব ৩০)। তাহলে এই update হারালে কী হবে?

• প্রেরক ভাবছে rwnd = ০ — সে অপেক্ষা করছে প্রাপকের খবরের জন্য।
• প্রাপক ভাবছে সে জায়গা ঘোষণা করে দিয়েছে — সে অপেক্ষা করছে ডেটার জন্য।

দুই পক্ষই অন্যের অপেক্ষায়, কেউ আর কিছু পাঠাবে না — এক চিরস্থায়ী deadlock. অপারেটিং সিস্টেমের deadlock-এর মতোই, চক্রাকার অপেক্ষা। সমাধান প্রেরকের দায়িত্বে: zero window দেখলেই প্রেরক একটি persist timer চালু করে। Timer ফুরালে সে একটি window probe পাঠায় — একটি ছোট segment যা প্রাপককে উত্তর দিতে বাধ্য করে, আর সেই উত্তরে থাকে বর্তমান rwnd. উত্তর এলেও window ০ থাকলে timer আবার চলে, প্রতিবার ব্যবধান দ্বিগুণ করে (exponential backoff), একটি সর্বোচ্চ সীমা পর্যন্ত। অর্থাৎ হারানো update-এর ক্ষতি সর্বোচ্চ একটি probe-ব্যবধান দেরি — চিরস্থায়ী নয়।

Probe দেখতে কেমন

RFC 793 থেকেই নিয়ম ছিল, window ০ হলেও প্রেরককে মাঝে মাঝে অন্তত এক byte নতুন ডেটা পাঠানোর চেষ্টা করতে হবে; RFC 1122 (১৯৮৯) zero-window probing-কে বাধ্যতামূলক (MUST) করে, আর বর্তমান TCP মানদণ্ড RFC 9293 (২০২২) একই কথা বলে। অনেক পাঠ্যবই আর পুরোনো implementation probe হিসেবে ১ byte ডেটা পাঠায় — প্রাপকের জায়গা না থাকলে সে byte-টি ফেলে দিয়ে ACK দেয়, আর ACK-এ থাকে window. আমাদের জানামতে Linux সাধারণত ডেটা ছাড়া, ইচ্ছে করে একটি পুরোনো sequence নম্বরসহ segment পাঠায়, যা প্রাপককে “ডুপ্লিকেট” দেখে সাথে সাথে ACK দিতে বাধ্য করে। ফল একই: উত্তরে বর্তমান rwnd. RFC 1122 আরও বলে, probe-এর উত্তর আসতে থাকলে প্রাপক যত দিন খুশি window বন্ধ রাখতে পারে, আর প্রেরক সংযোগ ভাঙবে না — এর নিরাপত্তা-দিক ভাবনার প্রশ্ন ২-এ।

৬ · Silly window syndrome — ছোট window, ছোট segment

Flow control-এর একটি অদ্ভুত পার্শ্বপ্রতিক্রিয়া আছে। ধরুন প্রাপকের buffer ভরা, আর অ্যাপ প্রতিবার মাত্র ২০ byte পড়ে। সরল নিয়মে প্রাপক সাথে সাথে ঘোষণা করে “rwnd = ২০”। প্রেরকের হাতে প্রচুর ডেটা, সে সেই ২০ byte-এর জায়গা ভরাতে একটি ২০ byte-এর segment পাঠায় — যার সাথে অন্তত ৪০ byte-এর TCP আর IPv4 header (২০ + ২০)। Buffer আবার ভরা, অ্যাপ আবার ২০ পড়ে, আবার ২০ byte-এর segment… প্রতি ৬০ byte-এ কাজের ডেটা মাত্র ২০ — তারে যাওয়া byte-এর দুই-তৃতীয়াংশই header! David Clark ১৯৮২ সালে RFC 813-এ এই অবস্থার নাম দেন silly window syndrome (SWS).

প্রাপকের দিকের প্রতিকার — Clark-এর নিয়ম

প্রাপক ছোট window ঘোষণা করবে না। Clark-এর সমাধান অনুযায়ী (RFC 1122-এ মানদণ্ড হিসেবে লেখা): window ০ থেকে বাড়ানোর খবর তখনই দেওয়া হবে, যখন খালি জায়গা অন্তত min(MSS, RcvBuffer ÷ ২) হয়। তার আগ পর্যন্ত প্রাপক window ০-ই দেখাতে থাকে (এবং ডান কিনারা পিছিয়ে না নিয়ে)। RFC 1122 এখানে অনুপাত হিসেবে ১/২ সুপারিশ করে।

প্রেরকের দিকের প্রতিকার — Nagle আর “পুরো segment-এর অপেক্ষা”

SWS প্রেরকের দিক থেকেও আসতে পারে: অ্যাপ নিজেই একটি একটি byte লেখে (যেমন পুরোনো telnet-এ প্রতিটি কী-চাপ)। এর প্রতিকার Nagle-এর algorithm (RFC 896, ১৯৮৪): অস্বীকৃত ডেটা পথে থাকলে ছোট segment না পাঠিয়ে জমিয়ে রাখা — বিস্তারিত আর delayed ACK-এর সাথে তার বিরোধ পর্ব ৩০-এ। RFC 1122 প্রেরকের জন্য আরও একটি নিয়ম দেয়: ছোট window দেওয়া হলেও প্রেরক পাঠাবে কেবল যদি পুরো একটি MSS পাঠানো যায়, বা প্রাপকের দেখা সর্বোচ্চ window-এর অন্তত অর্ধেক পাঠানো যায়, বা পাঠানোর সব ডেটাই পাঠানো যায় আর কিছু অস্বীকৃত নেই।

একই হিসাব প্রোগ্রামে — প্রেরক এখানে ইচ্ছে করে “বোকা”: যত ছোট window-ই দেওয়া হোক, সাথে সাথে ভরিয়ে দেয় (প্রেরকের দিকের প্রতিকার বন্ধ), যাতে শুধু প্রাপকের নিয়মের প্রভাব দেখা যায়।

// Silly window syndrome: full 4000-byte buffer, app reads only 20 bytes per tick,
// sender always has data and sends whatever window it is offered. 40 bytes of TCP+IP header.
const BUF = 4000, MSS = 1000, HDR = 40, READ = 20, TICKS = 200;
function run(clark) {
  let used = BUF, segs = 0, data = 0;
  const log = [];
  for (let t = 1; t <= TICKS; t++) {
    used -= READ;                                    // the app reads a little
    const free = BUF - used;
    // Clark (RFC 813/1122): keep advertising 0 until free >= min(MSS, BUF/2)
    const adv = clark && free < Math.min(MSS, BUF / 2) ? 0 : free;
    if (adv > 0) {                          // window update -> sender fills it at once
      segs++; data += adv; used += adv;
      if (log.length < 3) log.push(`t=${t}: rwnd=${adv} -> ${adv}-byte segment`);
    }
  }
  const wire = data + segs * HDR;
  console.log((clark ? "WITH Clark's rule" : "WITHOUT Clark's rule") + ": " + log.join(", "));
  console.log(`   ${segs} segments, ${data} data bytes, ${segs * HDR} header bytes,` +
              ` efficiency ${(100 * data / wire).toFixed(1)}% (plus ${segs} ACKs back)`);
}
run(false);
run(true);

WITHOUT Clark's rule: t=1: rwnd=20 -> 20-byte segment, t=2: rwnd=20 -> 20-byte segment, t=3: rwnd=20 -> 20-byte segment
   200 segments, 4000 data bytes, 8000 header bytes, efficiency 33.3% (plus 200 ACKs back)
WITH Clark's rule: t=50: rwnd=1000 -> 1000-byte segment, t=100: rwnd=1000 -> 1000-byte segment, t=150: rwnd=1000 -> 1000-byte segment
   4 segments, 4000 data bytes, 160 header bytes, efficiency 96.2% (plus 4 ACKs back)

৭ · Window scaling আর throughput ≤ window ÷ RTT

TCP header-এর Window ঘর ১৬ bit, তাই সর্বোচ্চ মান 2¹⁶ − 1 = ৬৫,৫৩৫ byte (প্রায় ৬৪ KiB). ১৯৮১ সালে, যখন সবচেয়ে দ্রুত দূরপাল্লার link ছিল কিলোবিটের ঘরে, এটি বিশাল মনে হতো। আজ এই সংখ্যাই হয়ে দাঁড়ায় throughput-এর ছাদ। কেন, তা একটি সরল যুক্তিতে:

প্রমাণ: প্রেরক ACK ছাড়া সর্বোচ্চ W byte পথে রাখতে পারে। কোনো byte পাঠানোর পর তার ACK ফিরতে অন্তত এক RTT লাগে, আর ACK না আসা পর্যন্ত window সামনে সরে না। তাই যেকোনো এক RTT সময়ের মধ্যে প্রেরক W-এর বেশি নতুন byte পাঠাতে পারে না — rate ≤ W ÷ RTT. আবার link-এর নিজের rate R-এর বেশিও সম্ভব নয়। ফলে

R × RTT হলো পর্ব ০৫-এর bandwidth-delay product (Delay, loss আর throughput) — পথে একসাথে কত byte “ভাসতে” পারে। Window তার চেয়ে ছোট হলে প্রেরক window ভরিয়ে বসে থাকে, পাইপের বাকিটা খালি যায়। পর্ব ১০-এর W ≥ 1 + 2a শর্তটিও আসলে একই কথা, frame-এর এককে।

Window scale option (RFC 7323)

সমাধান window scaling: header-এ ১৬ bit-ই থাকবে, কিন্তু দুই প্রান্ত সংযোগের শুরুতে একমত হবে যে সংখ্যাটিকে 2^S দিয়ে গুণ করে পড়তে হবে (বাঁয়ে S bit shift). প্রস্তাবটি এসেছিল ১৯৮৮ সালে RFC 1072-এ, প্রচলিত হয় RFC 1323 (১৯৯২) দিয়ে, আর বর্তমান মানদণ্ড RFC 7323 (২০১৪)। মূল নিয়মগুলো:

• Option-টি (kind 3, দৈর্ঘ্য ৩ byte, এক byte-এ shift count S) শুধু SYN আর SYN-ACK-এ যায় — অর্থাৎ পর্ব ২৯-এর handshake-এর সময়েই ঠিক হয়। দুই পক্ষই পাঠালে তবেই চালু; একজন না পাঠালে কেউই scaling ব্যবহার করে না।
• প্রতিটি দিকের S আলাদা — প্রতিটি প্রান্ত নিজের receive buffer অনুযায়ী নিজের S ঘোষণা করে।
• S সর্বোচ্চ ১৪. সর্বোচ্চ window = ৬৫,৫৩৫ × 2¹⁴ = ১,০৭,৩৭,২৫,৪৪০ byte ≈ ১ GiB. সীমার কারণ: ৩২-bit sequence নম্বরের চক্রে পুরোনো আর নতুন byte আলাদা রাখতে window-কে 2³⁰-এর নিচে থাকতে হয়।
• SYN segment-এর নিজের window ঘর কখনো scale হয় না। আর scaling-এর দাম: window এখন 2^S-এর গুণিতকে মাপা, তাই সূক্ষ্মতা কমে।

উদাহরণ: S = ৭ আর header-এ Window = ৫১২ হলে আসল rwnd = ৫১২ × ১২৮ = ৬৫,৫৩৬ byte. উল্টো দিকে, উপরের ১০০ Mbps × ১০০ ms পথে লাগবে ১২,৫০,০০০ ÷ ৬৫,৫৩৫ ≈ ১৯.১ গুণ, তাই S = ৫ (2⁵ = ৩২ ≥ ১৯.১)।

যে পথে R আর RTT দুটোই বড় — মহাদেশ পেরোনো ১০ Gbps fiber, উপগ্রহ — তাকে RFC 7323-এর ভাষায় বলে long fat network (LFN, উচ্চারণ “elephant”). নিচের calculator কয়েকটি পরিস্থিতিতে window-সীমা, link-সীমা, BDP আর প্রয়োজনীয় S হিসাব করে:

// Max TCP throughput = min(bandwidth, window / RTT); BDP = bandwidth x RTT; window-scale needed.
const cases = [  // [name, bandwidth in bit/s, RTT in s, window in bytes]
  ["no scaling, 100 ms path",  100e6, 0.100, 65535],
  ["no scaling, 10 ms path",   1e9,   0.010, 65535],
  ["home link, 256 KiB",       20e6,  0.050, 256 * 1024],
  ["GEO satellite, 64 KiB",    50e6,  0.600, 65535],
  ["10G long fat network",     10e9,  0.100, 16 * 1024 * 1024],
];
const mbps = b => (b / 1e6).toFixed(2).padStart(9) + " Mbps";
const kb = B => (B / 1024).toFixed(0).padStart(7) + " KiB";
function scaleNeeded(bytes) {            // smallest shift s with 65535 * 2^s >= bytes (max 14)
  let s = 0;
  while (65535 * 2 ** s < bytes && s < 14) s++;
  return 65535 * 2 ** s >= bytes ? String(s) : "more than 14";
}
console.log(`${"case".padEnd(24)} ${"window/RTT".padStart(14)} ${"link".padStart(14)} ${"max".padStart(14)} ${"BDP".padStart(11)}  scale`);
for (const [name, bw, rtt, win] of cases) {
  const wr = win * 8 / rtt, tput = Math.min(bw, wr), bdp = bw * rtt / 8;
  const who = wr < bw ? "window-limited" : "link-limited";
  console.log(`${name.padEnd(24)} ${mbps(wr)} ${mbps(bw)} ${mbps(tput)} ${kb(bdp)}  ${scaleNeeded(bdp).padStart(2)}  ${who}`);
}
console.log("largest window with scale 14 = " + 65535 * 2 ** 14 + " bytes (about 1 GiB)");

case                         window/RTT           link            max         BDP  scale
no scaling, 100 ms path       5.24 Mbps    100.00 Mbps      5.24 Mbps    1221 KiB   5  window-limited
no scaling, 10 ms path       52.43 Mbps   1000.00 Mbps     52.43 Mbps    1221 KiB   5  window-limited
home link, 256 KiB           41.94 Mbps     20.00 Mbps     20.00 Mbps     122 KiB   1  link-limited
GEO satellite, 64 KiB         0.87 Mbps     50.00 Mbps      0.87 Mbps    3662 KiB   6  window-limited
10G long fat network       1342.18 Mbps  10000.00 Mbps   1342.18 Mbps  122070 KiB  11  window-limited
largest window with scale 14 = 1073725440 bytes (about 1 GiB)

৮ · Linux-এ বাস্তবে — buffer, autotuning আর SO_RCVBUF

আধুনিক Linux প্রতিটি সংযোগের receive buffer নিজে থেকেই বাড়ায়-কমায় — একে বলে receive-buffer autotuning. Kernel প্রতি RTT-তে অ্যাপ কতটা পড়ছে তা মেপে buffer প্রয়োজনমতো বড় করে, একটি সীমা পর্যন্ত। সীমাগুলো থাকে তিনটি sysctl মানে:

• net.ipv4.tcp_rmem = min default max — receive buffer-এর সর্বনিম্ন, শুরুর আর autotuning-এর সর্বোচ্চ মান (byte).
• net.ipv4.tcp_wmem — send buffer-এর জন্য একই তিনটি মান।
• net.ipv4.tcp_window_scaling — ১ হলে SYN-এ window scale option যায় (প্রায় সব সিস্টেমে ডিফল্ট ১)।

ডিফল্ট মান kernel সংস্করণ আর distribution-ভেদে আলাদা; অনেক সাধারণ সিস্টেমে tcp_rmem-এর সর্বোচ্চ কয়েক MiB. অ্যাপ নিজে SO_RCVBUF / SO_SNDBUF socket option দিয়ে আকার ঠিক করে দিতে পারে, কিন্তু Linux-এ দুটি চমক আছে: kernel চাওয়া মানকে দ্বিগুণ করে রাখে (হিসাবরক্ষণের বাড়তি জায়গার জন্য — man 7 socket-এ লেখা আছে), আর চাওয়া মান net.core.rmem_max দিয়ে সীমিত। এছাড়া নিজে SO_RCVBUF ঠিক করলে সাধারণত সেই socket-এর autotuning বন্ধ হয়ে যায় — তাই না বুঝে ছোট মান বসানো উল্টো ফল দিতে পারে।

নিচের C প্রোগ্রাম loopback-এ পুরো ঘটনাটি দেখায়: /proc থেকে তিনটি মান পড়ে, buffer-এর আকার চেয়ে ফেরত পড়ে, তারপর একটি সংযোগ বানায় যার সার্ভার কখনো recv() ডাকে না। Client socket-কে non-blocking করে ১,০০০ byte করে send() চলতে থাকে, যতক্ষণ না kernel আর নিতে অস্বীকার করে। শেষে TCP_INFO দিয়ে kernel-এর ভেতরের হিসাব পড়া হয় — glibc-র struct-এ tcpi_snd_wnd ঘরটি নেই, তাই kernel-এর <linux/tcp.h> ব্যবহার করা হয়েছে, আর ঘরটি kernel আসলে ফেরত দিল কি না দৈর্ঘ্য দেখে যাচাই করা হয়েছে।

#include <stdio.h>
#include <stddef.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <arpa/inet.h>
#include <linux/tcp.h>          /* kernel's struct tcp_info: has tcpi_snd_wnd */
static void show(const char *f) { char b[96] = "not readable\n"; FILE *p = fopen(f, "r");
    if (p) { if (!fgets(b, sizeof b, p)) strcpy(b, "?\n"); fclose(p); } printf("%-19s %s", f + 19, b); }
static int opt(int s, int o) { int v = 0; socklen_t n = sizeof v; getsockopt(s, SOL_SOCKET, o, &v, &n); return v; }
int main(void) {
    show("/proc/sys/net/ipv4/tcp_rmem"); show("/proc/sys/net/ipv4/tcp_wmem"); show("/proc/sys/net/ipv4/tcp_window_scaling");
    int L = socket(AF_INET, SOCK_STREAM, 0), C = socket(AF_INET, SOCK_STREAM, 0), big = 1000000, v = 16384;
    setsockopt(C, SOL_SOCKET, SO_RCVBUF, &big, sizeof big);  printf("SO_RCVBUF 1000000 -> %d\n", opt(C, SO_RCVBUF));
    setsockopt(L, SOL_SOCKET, SO_RCVBUF, &v, sizeof v);      /* before listen(): accepted socket inherits it */
    setsockopt(C, SOL_SOCKET, SO_SNDBUF, &v, sizeof v);
    printf("SO_RCVBUF 16384 -> %d (server), SO_SNDBUF 16384 -> %d (client)\n", opt(L, SO_RCVBUF), opt(C, SO_SNDBUF));
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) }; socklen_t al = sizeof a;
    bind(L, (struct sockaddr *)&a, sizeof a); listen(L, 1); getsockname(L, (struct sockaddr *)&a, &al);
    if (connect(C, (struct sockaddr *)&a, sizeof a) < 0) { perror("connect"); return 1; }
    int S = accept(L, NULL, NULL);                          /* the server never calls recv() */
    fcntl(C, F_SETFL, O_NONBLOCK); char buf[1000] = {0}; long total = 0; ssize_t n;
    while ((n = send(C, buf, sizeof buf, 0)) > 0) total += n;
    printf("send() stopped: %s\n", strerror(errno));
    usleep(300000); int inq = 0, outq = 0; ioctl(S, FIONREAD, &inq); ioctl(C, TIOCOUTQ, &outq);
    printf("accepted %ld bytes = %d in server's receive queue + %d still in client\n", total, inq, outq);
    struct tcp_info ts, tc; socklen_t ls = sizeof ts, lc = sizeof tc;
    if (getsockopt(S, IPPROTO_TCP, TCP_INFO, &ts, &ls) == 0)
        printf("server: rcv_space=%u rcv_wscale=%u, client's wscale=%u\n", ts.tcpi_rcv_space, ts.tcpi_rcv_wscale, ts.tcpi_snd_wscale);
    if (getsockopt(C, IPPROTO_TCP, TCP_INFO, &tc, &lc) == 0 && lc >= offsetof(struct tcp_info, tcpi_snd_wnd) + 4)
        printf("client: snd_wnd=%u snd_mss=%u unacked=%u\n", tc.tcpi_snd_wnd, tc.tcpi_snd_mss, tc.tcpi_unacked);
    else printf("client: this kernel does not report tcpi_snd_wnd\n");
    return 0;
}

tcp_rmem            4096	87380	33554432
tcp_wmem            4096	87380	33554432
tcp_window_scaling  1
SO_RCVBUF 1000000 -> 425984
SO_RCVBUF 16384 -> 32768 (server), SO_SNDBUF 16384 -> 32768 (client)
send() stopped: Resource temporarily unavailable
accepted 50768 bytes = 29192 in server's receive queue + 21576 still in client
server: rcv_space=16384 rcv_wscale=0, client's wscale=2
client: snd_wnd=0 snd_mss=8192 unacked=0

নিজের Linux মেশিনে চলমান সংযোগের window আর buffer দেখতে এই কমান্ডগুলো কাজে লাগে (চালানোর আগে নিজের মেশিনের man ss দেখে নিন):

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_window_scaling
ss -tmi state established     # প্রতিটি সংযোগে wscale, rcv_space, snd_wnd, skmem(r,rb,t,tb)
cat /proc/sys/net/core/rmem_max

Windows-এ autotuning-এর নাম “Receive Window Auto-Tuning”, Windows Vista থেকে ডিফল্ট চালু; অবস্থা দেখা যায় এভাবে (প্রশাসক হিসেবে বদলানো যায়, তবে কারণ ছাড়া বদলানো উচিত নয়):

netsh interface tcp show global

৯ · অন্য স্তরেও flow control

“ধীর প্রাপক দ্রুত প্রেরককে থামাবে” — এই সমস্যা নেটওয়ার্কের প্রায় প্রতিটি স্তরে আছে, আর সমাধানের ধরনও প্রায় এক: হয় স্পষ্ট থামার সংকেত, নয়তো credit বা window.

HTTP/2 আর QUIC-কে আলাদা flow control রাখতে হয় কারণ TCP-র rwnd পুরো সংযোগের — একটি সংযোগে দশটি ফাইল একসাথে চললে, একটি ধীর ভোক্তা (ধরুন বড় একটি download যা অ্যাপ ধীরে লিখছে) পুরো সংযোগের window আটকে বাকি নয়টিকেও থামিয়ে দিত। Stream-ভিত্তিক window প্রতিটি stream-কে আলাদা করে থামাতে দেয়। বিস্তারিত পর্ব ৩৩ আর ৩৭-এ।

১০ · AI-এর যুগে TCP window-এর হিসাব আর tuning

“Linux-এ TCP throughput বাড়াব কীভাবে?” — AI-কে জিজ্ঞেস করলে প্রায়ই একগাদা sysctl লাইন আসে, যার কিছু অপ্রয়োজনীয়, কিছু পুরোনো, কিছু ক্ষতিকর। Window-এর অঙ্কেও AI-এর ভুলগুলোর ধরন চেনা:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• rwnd = RcvBuffer − (LastByteRcvd − LastByteRead) আর min(rwnd, cwnd) — সূত্র দুটি ঠিক জায়গায় বসেছে কি না দেখেছি
• W ÷ RTT-এর হিসাবে byte থেকে bit-এ ৮ দিয়ে গুণ হয়েছে কি না, আর scale shift ≤ ১৪ কি না মিলিয়েছি
• অন্তত একটি সংখ্যা উপরের calculator বা হাতের ক্যালকুলেটরে নিজে আবার হিসাব করেছি
• প্রতিটি sysctl আর socket option নিজের মেশিনে sysctl, man 7 tcp, man 7 socket দিয়ে যাচাই করেছি; বদল আগে নিজের VM-এ পরীক্ষা করেছি
• সার্ভারে বদলের আগে-পরে ss -tmi বা packet capture দিয়ে window আসলে বদলেছে কি না মেপেছি — অনুমানে নয়