TCP-র নির্ভরযোগ্যতা — sequence, ACK, retransmission আর timeout

১ · অনির্ভরযোগ্য পথের ওপর নির্ভরযোগ্য সেবা

আপনি বড় একটি ফাইল ডাউনলোড করছেন। হাজার হাজার packet সাগরতলের cable আর কয়েকটি দেশের router পার হয়ে আসছে। কোনো router-এর buffer ভরে গেলে সে নতুন packet চুপচাপ ফেলে দেয়; কোনো packet অন্য পথে পরে পৌঁছায়। তবু শেষে ফাইলের প্রতিটি byte ঠিক জায়গায়। কাজটি করে TCP.

নিচের স্তরের IP একটি best effort সেবা — “চেষ্টা করব, কথা দিচ্ছি না।” IP-র পথে চার রকম বিপদ ঘটতে পারে:

পর্ব ১০-এ এক link-এর জন্য এই সমস্যার সমাধান দেখেছেন — ARQ: stop-and-wait, Go-Back-N আর Selective Repeat. TCP সেই ধারণাগুলোই ব্যবহার করে, কিন্তু তিনটি বড় পার্থক্য নিয়ে। প্রথমত TCP কাজ করে পুরো পথের দুই প্রান্তে — মাঝের router কিছুই জানে না। দ্বিতীয়ত পথের RTT জানা নেই, আর তা মুহূর্তে মুহূর্তে বদলায় — একই সংযোগে কখনো ২০ ms, কখনো ৪০০ ms. তৃতীয়ত TCP নম্বর দেয় byte-কে, frame-কে নয়।

নির্ভরযোগ্যতা কেন দুই প্রান্তে — end-to-end যুক্তি

প্রতিটি link নিখুঁত হলেও তা যথেষ্ট নয় — পর্ব ০৩-এর end-to-end principle. ডেটা নষ্ট হতে পারে router-এর মেমরিতে, যেখানে link-এর CRC নেই; router নিজেই packet ফেলে দিতে পারে। পুরো পথে সব ঠিক আছে কি না, নিশ্চিত হতে পারে শুধু দুই প্রান্ত। তাই link-এর ARQ (যেমন Wi-Fi-তে) গতি বাড়ানোর কৌশল, শেষ দায়িত্ব TCP-র। অংশ ৮-এ দেখবেন, যুক্তিটি আরও এক ধাপ ওপরে যায়।

২ · Byte-stream আর sequence নম্বর

TCP-র কাছে application-এর ডেটা কোনো “বার্তা” নয় — একটি অবিরাম byte-stream, যেন একটি লম্বা ফিতা। Application তিনবার send() করে ১০০, ২০০ আর ৩০০ byte লিখলে TCP সেগুলো একটি ৬০০ byte-এর segment-এ পাঠাতে পারে, বা অন্যভাবে ভাগ করতে পারে; প্রাপকের একটি recv()-এ আসতে পারে ৬০০, বা ৫০ — বার্তার সীমানা TCP রাখে না (পর্ব ৪১-এ socket প্রোগ্রামিংয়ে এটি খুব জরুরি)। ফিতার প্রতিটি byte-এর একটি নম্বর আছে।

MSS আর segmentation

ফিতা কেটে কেটে segment বানানোকে বলে segmentation. একটি segment-এ সর্বোচ্চ কত byte ডেটা যাবে, তা MSS ঠিক করে। IP packet যাতে link-এর MTU-তে আঁটে, সেজন্য Ethernet-এ (MTU ১৫০০) IPv4-এর ২০ byte আর TCP-র ২০ byte header বাদ দিয়ে MSS = ১৫০০ − ৪০ = ১৪৬০ byte; IPv6-এ (৪০ byte header) ১৪৪০. সংযোগ শুরুর সময় দুই পক্ষ SYN segment-এর option-এ নিজের MSS জানায় (পর্ব ২৯)। Option না এলে IPv4-এ ধরে নেওয়া হয় ৫৩৬ byte. আর প্রতিটি segment-এ timestamps-এর মতো option থাকলে আসল ডেটা আরও কমে — যেমন ১২ byte option থাকলে ১৪৪৮.

দুটি নম্বরের সংজ্ঞা — পরীক্ষার মূল কথা

শুরুর নম্বর শূন্য নয়। প্রতিটি সংযোগ একটি এলোমেলো initial sequence number (ISN) দিয়ে শুরু হয় — পুরোনো সংযোগের দেরিতে আসা segment যাতে নতুন সংযোগে মিশে না যায়, আর বাইরের কেউ যাতে নম্বর আন্দাজ করে নকল segment ঢোকাতে না পারে (RFC 6528). SYN নিজে একটি নম্বর খরচ করে, তাই ISN = x হলে প্রথম ডেটা byte-এর নম্বর x + 1; FIN-ও একটি নম্বর খরচ করে (পর্ব ২৯)। Wireshark তাই ডিফল্টভাবে ISN-কে ০ ধরে “relative” নম্বর দেখায়। নম্বর ৩২ bit-এর, ২^৩২-এর পর ঘুরে আবার ০ (অনুশীলন ৪)।

নিচের stepper-এ A (client) আর B (server)-এর সংযোগ ইতিমধ্যে তৈরি। A-র ISN 1000, তাই A-র প্রথম ডেটা byte 1001; B-র ISN 5000, তাই B-র প্রথম ডেটা byte 5001. A চারটি segment পাঠায় — ৫০০, ১০০০, ৩০০ আর ২০০ byte; মাঝে B-ও ২০০ byte উত্তর পাঠায়। প্রতিটি ধাপে seq আর ack নিজে হিসাব করে তারপর মিলিয়ে দেখুন।

৩ · ACK-এর কৌশল — cumulative, piggybacked আর delayed

Cumulative ACK-এর সুবিধা: একটি ACK হারালেও ক্ষতি নেই — “3001 চাই” মানে 3000 পর্যন্ত সব পৌঁছেছে। কিন্তু প্রতিটি segment-এর আলাদা ACK মানে উল্টো পথে অনেক ৪০ byte-এর প্রায় ফাঁকা packet. তাই TCP দুটি কৌশলে ACK কমায়।

Piggybacking

দুই দিকেই ডেটা চললে ACK আলাদা segment-এ না গিয়ে উল্টো দিকের ডেটার header-এ বসে যায় — উপরের stepper-এর ধাপ ৫. পর্ব ১০-এ এটিকে বলা হয়েছিল piggybacking. TCP-র প্রতিটি segment-এ (প্রথম SYN ছাড়া) ACK ঘর বৈধ থাকে, তাই piggybacking এখানে স্বাভাবিক নিয়ম।

Delayed ACK

উত্তর আসতে যদি একটু সময় লাগে? Delayed ACK-এ প্রাপক ACK পাঠাতে একটু অপেক্ষা করে — হয়তো এর মধ্যে আরেকটি segment আসবে (দুটির জন্য একটি ACK), বা application উত্তর লিখবে (ACK তার পিঠে যাবে)। নিয়মের সীমা RFC 1122 আর RFC 5681-এ:

• টানা পূর্ণ আকারের segment এলে অন্তত প্রতি দুটি segment-এ একটি ACK পাঠানো উচিত।
• প্রথম অস্বীকৃত segment আসার পর ACK ৫০০ ms-এর মধ্যে যেতেই হবে।
• ক্রমের বাইরের segment এলে, বা কোনো segment ফাঁক পূরণ করলে, ACK সঙ্গে সঙ্গে পাঠানো উচিত — দেরি নয়। (এই নিয়ম থেকেই duplicate ACK-এর জন্ম — নিচে।)

বাস্তবের মান OS আর সংস্করণভেদে আলাদা। Linux-এ timer সাধারণত ৪০ ms থেকে ট্রাফিক দেখে ২০০ ms পর্যন্ত ওঠানামা করে, আর সংযোগের শুরুতে “quick ACK” mode-এ ACK সঙ্গে সঙ্গে যায়। Windows-এ ডিফল্ট প্রচলিতভাবে ২০০ ms. সংখ্যা মুখস্থ না করে মাপা ভালো (অংশ ৮-এর C প্রোগ্রাম Linux-এ মানটি দেখায়)।

ক্রমের বাইরের segment আর duplicate ACK

ধরুন byte 1001–2000 হারাল, কিন্তু 2001–3000 পৌঁছাল। Go-Back-N-এর প্রাপক এটি ফেলে দিত। TCP-র প্রাপক সাধারণত ফেলে না — ক্রমের বাইরের (out-of-order) ডেটা নিজের receive buffer-এ রেখে দেয়, কিন্তু application-কে দেয় না (application শুধু ফাঁকহীন ধারাবাহিক byte পায়)। আর সঙ্গে সঙ্গে ACK পাঠায় — কিন্তু ACK নম্বর আটকে আছে 1001-এ, কারণ 1001 এখনো আসেনি। প্রেরক তাই আগের ACK-টিই আবার দেখে: একে বলে duplicate ACK (dup ACK). প্রতিটি dup ACK প্রেরককে বলে, “1001 এখনো পাইনি, কিন্তু পরের কিছু একটা পেয়েছি।” পথ খোলা আছে, শুধু একটি টুকরো নেই — অংশ ৬-এ এই সংকেত কাজে লাগবে।

৪ · Nagle আর delayed ACK — ছোট লেখার ফাঁদ

১৯৮০-র দশকে Telnet-এর মতো প্রোগ্রাম প্রতিটি কী-চাপ আলাদা segment-এ পাঠাত: ১ byte ডেটা, সাথে ৪০ byte header — ৪০০০% বাড়তি বোঝা। ধীর লাইনে এমন হাজার হাজার ক্ষুদ্র packet নেটওয়ার্ক অচল করে দিত। ১৯৮৪ সালে John Nagle RFC 896-এ সমাধান দেন, যা Nagle-এর algorithm নামে পরিচিত:

ফল: এক RTT-তে ছোট segment বড়জোর একটি; ধীর পথে অনেক কী-চাপ জমে এক segment-এ যায়। চমৎকার নিয়ম — যতক্ষণ না অপর প্রান্তে delayed ACK বসে থাকে।

বিখ্যাত ২০০ ms দেরি

একটি client request পাঠায় দুই ধাপে: আগে write()-এ ১০০ byte header, তারপর আরেকটি write()-এ ৫০ byte body. Server পুরো ১৫০ byte না পেলে উত্তর দেয় না। এবার দেখুন কী ঘটে:

1. প্রথম ১০০ byte সঙ্গে সঙ্গে যায় (পথে কিছু অস্বীকৃত নেই)।
2. দ্বিতীয় ৫০ byte ছোট, আর আগের ১০০ byte-এর ACK আসেনি — Nagle এটি আটকে রাখে।
3. Server ১০০ byte পেয়েছে, কিন্তু request অসম্পূর্ণ — উত্তর নেই, তাই piggyback-এর সুযোগও নেই। দুটি পূর্ণ segment-ও আসেনি। তাই সে delayed ACK-এর timer ফুরানো পর্যন্ত বসে থাকে।
4. দুজনেই অপরজনের অপেক্ষায় — একটি ছোটখাটো “অচলাবস্থা”, যা ভাঙে শুধু timer ফুরালে।

নিচের প্রোগ্রাম এই সময়রেখাটি হিসাব করে — LAN, এক দিকের delay ১ ms, চার রকম পরিস্থিতিতে:

// Client: write(100-byte header), write(50-byte body), then waits for the reply.
// Server: replies only after the whole 150-byte request has arrived. One-way delay 1 ms (LAN).
// Server uses delayed ACK; small segments never make "two full-sized segments",
// so its ACK leaves only when the timer fires or piggybacked on the reply.
function run(title, nagle, writes, delack) {
  const d = 1, need = 150, log = [], at = (ms, s) => log.push(String(ms).padStart(5) + " ms  " + s);
  let got = 0, arrive = 0, inFlight = false, held = 0;
  for (const w of writes) {
    if (nagle && inFlight) { held += w; at(0, `Nagle holds ${w} B (earlier data not yet ACKed)`); continue; }
    at(0, `client sends ${w} B`); arrive = d; got += w; inFlight = true;
  }
  if (got < need) {                          // server has half a request: no reply to piggyback on
    at(arrive, `server got ${got} B, waits for the rest; delayed-ACK timer starts`);
    const fire = arrive + delack;
    at(fire, "timer fires -> server sends a pure ACK");
    at(fire + d, `ACK reaches client -> Nagle releases ${held} B`);
    arrive = fire + 2 * d; got += held;
  }
  at(arrive, `server has all ${got} B -> sends reply (ACK piggybacked)`);
  at(arrive + d, "client gets the reply");
  console.log(`== ${title}: ${arrive + d} ms\n` + log.join("\n") + "\n");
}
run("Nagle on, two writes, 200 ms delayed ACK (Windows-like)", true, [100, 50], 200);
run("Nagle on, two writes, 40 ms delayed ACK (Linux minimum)", true, [100, 50], 40);
run("TCP_NODELAY, two writes", false, [100, 50], 200);
run("Nagle on, ONE write of 150 B (build the buffer, or writev)", true, [150], 200);

== Nagle on, two writes, 200 ms delayed ACK (Windows-like): 204 ms
    0 ms  client sends 100 B
    0 ms  Nagle holds 50 B (earlier data not yet ACKed)
    1 ms  server got 100 B, waits for the rest; delayed-ACK timer starts
  201 ms  timer fires -> server sends a pure ACK
  202 ms  ACK reaches client -> Nagle releases 50 B
  203 ms  server has all 150 B -> sends reply (ACK piggybacked)
  204 ms  client gets the reply

== Nagle on, two writes, 40 ms delayed ACK (Linux minimum): 44 ms
    0 ms  client sends 100 B
    0 ms  Nagle holds 50 B (earlier data not yet ACKed)
    1 ms  server got 100 B, waits for the rest; delayed-ACK timer starts
   41 ms  timer fires -> server sends a pure ACK
   42 ms  ACK reaches client -> Nagle releases 50 B
   43 ms  server has all 150 B -> sends reply (ACK piggybacked)
   44 ms  client gets the reply

== TCP_NODELAY, two writes: 2 ms
    0 ms  client sends 100 B
    0 ms  client sends 50 B
    1 ms  server has all 150 B -> sends reply (ACK piggybacked)
    2 ms  client gets the reply

== Nagle on, ONE write of 150 B (build the buffer, or writev): 2 ms
    0 ms  client sends 150 B
    1 ms  server has all 150 B -> sends reply (ACK piggybacked)
    2 ms  client gets the reply

সমাধান — কোনটি কখন

• একবারে লেখা: request পুরোটা একটি buffer-এ সাজিয়ে একটি send(), বা writev(). সবচেয়ে পরিষ্কার সমাধান — অতিরিক্ত ছোট packet-ও হয় না।
• TCP_NODELAY: setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &one, sizeof one) দিয়ে Nagle বন্ধ। Interactive আর request-response প্রোগ্রামে (RPC, ডেটাবেস client, গেম, SSH-এর মতো interactive session) খুব প্রচলিত; Go ভাষার standard library TCP সংযোগে এটি ডিফল্টভাবেই চালু রাখে। সাবধান: বন্ধ করলে প্রতিটি ছোট write() আলাদা ছোট packet হয়ে যেতে পারে — ঠিক যে সমস্যা Nagle ঠেকাত।
• Linux-এর বিশেষ option: TCP_CORK (জমিয়ে রেখে পরে একসাথে ছাড়া) আর TCP_QUICKACK (প্রাপকের দিকে delayed ACK সাময়িক বন্ধ) — দুটোই Linux-নির্দিষ্ট, অন্য OS-এ নাম বা আচরণ ভিন্ন।

৫ · Timeout কত হবে — RTT মেপে RTO

প্রতিটি অস্বীকৃত ডেটার জন্য প্রেরক একটি timer চালায়; সময়মতো ACK না এলে timeout, আর আবার পাঠানো। এই অপেক্ষার সময়কে বলে RTO (retransmission timeout). কঠিন প্রশ্নটি হলো — কত?

• খুব ছোট RTO: ACK পথে আছে, কিন্তু প্রেরক অধৈর্য হয়ে আবার পাঠাল — অকারণ retransmission, নেটওয়ার্কে বাড়তি বোঝা, আর পর্ব ৩২-এ দেখবেন, অকারণে গতি কমানো।
• খুব বড় RTO: segment সত্যিই হারিয়েছে, কিন্তু প্রেরক বসে আছে — ব্যবহারকারী দেখেন পাতা আটকে গেছে।

এক link-এ (পর্ব ১০) RTT প্রায় স্থির। ইন্টারনেটে একই সংযোগের RTT queue-র ভিড়ে মুহূর্তে বদলায় — ঢাকা থেকে সিঙ্গাপুরে হয়তো ৪০–৬০ ms, আমেরিকায় ২০০ ms-এর বেশি। তাই TCP প্রতিটি সংযোগে RTT মেপে RTO হিসাব করে।

নমুনা থেকে গড়: SRTT

একটি segment পাঠানোর সময় থেকে তার ACK আসা পর্যন্ত সময় একটি নমুনা — SampleRTT (RFC-তে R). একটি নমুনায় ভরসা করা যায় না, তাই TCP একটি চলমান গড় রাখে — EWMA (exponentially weighted moving average):

(Kurose-Ross-এর পাঠ্যবইয়ে নাম EstimatedRTT; RFC 6298-এ SRTT — একই জিনিস।) কেন “exponential”? সূত্রটি বারবার বসালে পাই: SRTT_n = α·R_n + α(1 − α)·R_n−1 + α(1 − α)²·R_n−2 + … অর্থাৎ k ধাপ পুরোনো নমুনার ওজন α(1 − α)^k — প্রতি ধাপে ⅞ গুণ কমে। সব ওজনের যোগফল ১ (একটি গুণোত্তর ধারা: α/(1 − (1 − α)) = 1). মোটামুটি শেষ ৮টি নমুনা (১/α) প্রভাব রাখে; পুরোনোগুলো ধীরে মুছে যায়। আর ৮ দিয়ে ভাগ মানে ৩ bit শিফট — পুরোনো যন্ত্রে দশমিক গুণ ছাড়াই হিসাব।

ওঠানামাও মাপা: RTTVAR

শুধু গড় দিয়ে RTO ঠিক করলে বিপদ: RTT বেশি ওঠানামা করলে অনেক নমুনাই গড়ের ওপরে যাবে, আর প্রতিবার ভুল timeout. তাই TCP গড় থেকে বিচ্যুতিরও চলমান গড় রাখে:

(পাঠ্যবইয়ে RTTVAR-এর নাম DevRTT.) কেন ৪ গুণ? RTO-কে প্রায় সব স্বাভাবিক RTT-র চেয়ে বড় রাখতে। RTT মোটামুটি normal বণ্টনের হলে mean deviation ≈ ০.৮σ, তাই 4·RTTVAR ≈ ৩.২σ — গড়ের এত ওপরে স্বাভাবিক নমুনা খুব কমই যায়। Standard deviation-এর বদলে mean deviation, কারণ বর্গমূল লাগে না। সূত্রটি ১৯৮৮ সালে Van Jacobson-এর প্রস্তাব (ভাবনার প্রশ্ন ২)।

বাস্তব আর মান এখানে আলাদা। Linux সর্বনিম্ন হিসেবে ২০০ ms ব্যবহার করে (আর ১ সেকেন্ডের নিয়ম মানে না), আর তার হিসাব মোটামুটি RTO ≈ SRTT + max(4·RTTVAR, ২০০ ms) — তাই কম RTT-র পথে Linux-এর RTO প্রায় RTT + ২০০ ms. সর্বোচ্চ সীমা Linux-এ ১২০ সেকেন্ড। অন্য OS-এর সর্বনিম্ন মান ভিন্ন হতে পারে; সংস্করণভেদে বদলায়ও। পরীক্ষায় RFC-র মান লিখুন, আর বলুন বাস্তবে OS-ভেদে আলাদা।

নিচের stepper RFC 6298 মেনে তিনটি নমুনা (৫০, ৬০, ৪০ ms) থেকে RTO বের করে — তারপর একটি আবার পাঠানো segment আর একটি timeout. প্রতিটি সংখ্যা ক্যালকুলেটরে নিজে মিলিয়ে নিন।

Karn-এর algorithm — দ্ব্যর্থক নমুনা বাদ

উপরের ধাপ ৫-এর সমস্যাটি গভীর। একটি segment পাঠানো হলো, timeout হলো, আবার পাঠানো হলো, তারপর ACK এলো। ACK-টি প্রথম কপির হলে আসল RTT লম্বা; দ্বিতীয়টির হলে খুব ছোট। ভুল ধরলে দুই দিকেই বিপদ — RTO অকারণে বাড়তে থাকে, অথবা এত কমে যে আরও ভুল timeout. ১৯৮৭ সালে Phil Karn আর Craig Partridge সমাধান দেন, যা Karn-এর algorithm নামে পরিচিত: (১) আবার পাঠানো segment-এর RTT নমুনা কখনো নেওয়া হবে না; (২) backoff করা RTO রেখে দেওয়া হবে, যতক্ষণ না একটি আবার-না-পাঠানো segment-এর বৈধ নমুনা আসে।

Exponential backoff

একই segment বারবার timeout হলে প্রতিবার RTO দ্বিগুণ — exponential backoff. বারবার হারানো মানে সম্ভবত প্রচণ্ড ভিড়; সবাই একই তালে আবার পাঠাতে থাকলে ভিড় কাটে না। কতবার চেষ্টার পর সংযোগ ছেড়ে দেওয়া হবে, তা OS-এর সেটিং — Linux-এ net.ipv4.tcp_retries2 (ডিফল্ট ১৫, যা kernel-এর নথি অনুযায়ী প্রায় ১৫ মিনিটের সমান)।

Timestamps option — প্রতিটি ACK থেকে নমুনা

পুরোনো পদ্ধতিতে প্রতি RTT-তে মোটামুটি একটি segment-এর সময় মাপা হতো। RFC 7323-এর timestamps option (প্রতি segment-এ ১০ byte: TSval আর TSecr) এটি বদলে দিয়েছে: প্রেরক নিজের ঘড়ির মান TSval-এ লেখে, প্রাপক ACK-এ সেটি TSecr-এ ফেরত দেয়। ACK আসামাত্র “এখন − TSecr” = RTT — প্রতিটি ACK থেকে নমুনা, আর ফেরত মান বলে দেয় কোন কপির ACK, তাই আবার পাঠানোর পরের দ্ব্যর্থতাও অনেকটা কাটে। এটি sequence নম্বর ঘুরে আসার বিপদও ঠেকায় (PAWS, অনুশীলন ৪)। Linux-এ timestamps ডিফল্টভাবে চালু; সব OS-এ নয়।

নিচের প্রোগ্রাম সাতটি নমুনা নিয়ে RFC 6298 চালায় — চতুর্থটি আবার পাঠানো segment-এর, তাই Karn-এর নিয়মে বাদ। পাশে তুলনার জন্য Linux-ধাঁচের হিসাব (সরলীকৃত), আর শেষে বারবার timeout হলে RTO-র দ্বিগুণ হওয়া:

// RTO estimation the RFC 6298 way (alpha = 1/8, beta = 1/4, K = 4). Times in ms.
// RFC 6298: RTO >= 1 s. Linux-like: SRTT + max(4*RTTVAR, 200 ms) (simplified).
// Each sample: [measured RTT, was this segment retransmitted?]
const samples = [[50, false], [60, false], [40, false], [180, true],
                 [64, false], [48, false], [52, false]];
const a = 1 / 8, b = 1 / 4, K = 4;
let srtt = null, rttvar = null;
const f = x => x.toFixed(1).padStart(7);
console.log(" # Sample |   SRTT  RTTVAR |  raw RTO  RFC 6298  Linux-like");
samples.forEach(([r, retx], i) => {
  const n = String(i + 1).padStart(2) + String(r).padStart(7) + " | ";
  if (retx) { console.log(n + "skipped: retransmitted segment (Karn's rule)"); return; }
  if (srtt === null) { srtt = r; rttvar = r / 2; }          // first measurement
  else {
    rttvar = (1 - b) * rttvar + b * Math.abs(srtt - r);       // uses the OLD srtt
    srtt = (1 - a) * srtt + a * r;
  }
  const rto = srtt + K * rttvar;
  console.log(n + f(srtt) + f(rttvar) + " | " + f(rto) +
              f(Math.max(rto, 1000)).padStart(10) + f(srtt + Math.max(K * rttvar, 200)).padStart(12));
});
// The same segment times out again and again: RTO doubles each time (exponential backoff).
let rto = Math.max(srtt + K * rttvar, 1000);
const steps = [];
for (let k = 1; k <= 6; k++) { steps.push(rto); rto = Math.min(2 * rto, 60000); }
console.log("\nBackoff (RFC, cap 60 s): " + steps.map(x => (x / 1000).toFixed(2) + " s").join(" -> "));
console.log("Total waiting in these 6 timeouts: " + (steps.reduce((s, x) => s + x, 0) / 1000).toFixed(2) + " s");

 # Sample |   SRTT  RTTVAR |  raw RTO  RFC 6298  Linux-like
 1     50 |    50.0   25.0 |   150.0    1000.0       250.0
 2     60 |    51.3   21.3 |   136.3    1000.0       251.3
 3     40 |    49.8   18.8 |   124.8    1000.0       249.8
 4    180 | skipped: retransmitted segment (Karn's rule)
 5     64 |    51.6   17.6 |   122.0    1000.0       251.6
 6     48 |    51.2   14.1 |   107.6    1000.0       251.2
 7     52 |    51.3   10.8 |    94.4    1000.0       251.3

Backoff (RFC, cap 60 s): 1.00 s -> 2.00 s -> 4.00 s -> 8.00 s -> 16.00 s -> 32.00 s
Total waiting in these 6 timeouts: 63.00 s

৬ · Fast retransmit — timeout-এর আগেই হারানো ধরা

অংশ ৫-এর হিসাব দেখাল, RTO প্রায়ই RTT-র কয়েক গুণ — RFC মানলে অন্তত ১ সেকেন্ড। প্রতিটি loss-এ এতক্ষণ বসে থাকা মানে বিশাল অপচয়। কিন্তু প্রেরকের হাতে একটি আগাম সংকেত আছে: duplicate ACK. প্রাপক ক্রমের বাইরের প্রতিটি segment পেয়ে একই ACK নম্বর আবার পাঠায়। একই নম্বর বারবার আসা মানে — পরের segment-গুলো পৌঁছাচ্ছে, শুধু একটি নেই।

কেন ঠিক ৩? Duplicate ACK-এর একটি নিরীহ কারণও আছে — reordering: দুটি segment জায়গা বদল করে এলে একটি dup ACK যায়, তারপর “হারানো” segment এসে পড়ে। ১–২টি dup ACK প্রায়ই এমন ক্রম-বদল; ৩টি হলে loss-এর সম্ভাবনা বেশি। সংখ্যাটি প্রমাণ নয়, ১৯৮০-র দশকের শেষে BSD Unix-এর TCP-তে চালু হওয়া একটি পরীক্ষিত আপস। দুর্বলতাও আছে: loss-এর পরে অন্তত তিনটি segment পাঠানো না থাকলে dup ACK আসেই না — যেমন ছোট transfer-এর শেষ segment হারালে। তখন timeout ছাড়া উপায় নেই (অংশ ৮-এ আধুনিক সমাধান)।

Loss ধরা পড়লে প্রেরক কতটা গতি কমাবে — congestion window-এর প্রতিক্রিয়া, fast recovery — সেটি পর্ব ৩২-এর বিষয়। এখানে শুধু loss শনাক্তের দিকটি। নিচের stepper-এ ৬টি segment (MSS ১০০০ byte, relative seq 1 থেকে), এক দিকের delay ২ একক, আর byte 1001–2000-এর segment হারায় (অংশ ৭-এর simulator-এর প্রথম রান হুবহু):

৭ · SACK — cumulative ACK-এর অন্ধত্ব দূর করা

Cumulative ACK একটি কথাই বলতে পারে: “এই byte পর্যন্ত ফাঁকহীন পেয়েছি।” ফাঁকের পরে কী পৌঁছেছে, বলতে পারে না। একটি window-তে দুটি segment হারালে প্রেরক fast retransmit-এ প্রথমটি পাঠায়; ACK লাফ দিয়ে দ্বিতীয় ফাঁকে থামে (partial ACK) — দ্বিতীয় loss জানা গেল এক RTT পরে। পুরোনো Reno TCP এমন অবস্থায় প্রায়ই timeout-এ পড়ত; NewReno (RFC 6582) partial ACK দেখে পরের ফাঁকটি পাঠায় — তবু প্রতি RTT-তে একটি করে।

সমাধান SACK (selective acknowledgement), RFC 2018 (১৯৯৬)। সংযোগের শুরুতে দুই পক্ষ SYN-এ “SACK-permitted” option দিয়ে সম্মতি জানায়। তারপর প্রাপক ACK-এর সাথে option-এ কয়েকটি block পাঠায় — প্রতিটি block-এ দুটি ৩২ bit নম্বর: left edge (block-এর প্রথম byte) আর right edge (block-এর শেষ byte-এর পরের নম্বর, ACK নম্বরের মতোই)। “ACK 1001, SACK 4001-6001, 2001-3001” মানে: ১০০০ পর্যন্ত ফাঁকহীন, তারপর 2001–3000 আর 4001–6000 আছে; অর্থাৎ ফাঁক 1001–2000 আর 3001–4000.

• জায়গার সীমা: TCP option-এর জায়গা মোট ৪০ byte; SACK option-এ ২ byte + প্রতি block ৮ byte, তাই সর্বোচ্চ ৪টি block. Timestamps option (১০ byte + ২ byte padding) থাকলে ৩টি.
• ক্রম: প্রথম block-এ থাকে সবচেয়ে সাম্প্রতিক পৌঁছানো segment, যাতে কিছু ACK হারালেও তথ্য না হারায়; একই block কয়েকটি ACK-এ পুনরাবৃত্তি হয়।
• শুধু পরামর্শ: SACK করা ডেটাও প্রাপক চাইলে (মেমরির চাপে) ফেলে দিতে পারে — একে বলে reneging. তাই প্রেরক cumulative ACK না আসা পর্যন্ত ডেটা নিজের buffer থেকে মোছে না।

নিচের simulator দুই প্রান্তকে byte নম্বরসহ চালায়: প্রাপক ক্রমের বাইরের ডেটা buffer-এ রেখে প্রতিটি segment-এ ACK (আর SACK block) পাঠায়; প্রেরক তৃতীয় dup ACK-এ fast retransmit করে, partial ACK-এ পরের ফাঁক পাঠায় (NewReno-র মতো), আর SACK থাকলে জানা সব ফাঁক একসাথে। এতে timeout নেই, তাই শেষ segment হারানোর নকশা দেবেন না।

function run(title, lost, useSack) {  // 6 segments x MSS 1000 (seq 1..6000), delay 2, 1 send/unit
  const MSS = 1000, END = 6001, D = 2, ev = [], q = [1, 1001, 2001, 3001, 4001, 5001];
  const buf = new Set(), done = new Set(), lossLeft = new Set(lost), sacked = new Set();
  let una = 1, dup = 0, recover = 0, rcvNxt = 1, sndMax = 1, tx = 0, t = 0;
  for (console.log("== " + title); una < END; t++) {
    for (const e of ev.filter(e => e.t === t)) {
      if (e.seq) {                                   // segment reaches the receiver
        if (e.seq === rcvNxt) for (rcvNxt += MSS; buf.delete(rcvNxt); ) rcvNxt += MSS;
        else if (e.seq > rcvNxt) buf.add(e.seq);     // out of order: buffer it
        const blk = [], has = (b, x) => b[0] <= x && x < b[1];   // SACK blocks
        [...buf].sort((x, y) => x - y).forEach(x => blk.length && blk[0][1] === x ? blk[0][1] += MSS : blk.unshift([x, x + MSS]));
        blk.sort((p, r) => has(r, e.seq) - has(p, e.seq));      // newest block first
        const sk = useSack && blk.length ? "  SACK " + blk.map(b => b.join("-")).join(", ") : "";
        console.log(`t=${t}  rcv seq=${e.seq} -> ACK ${rcvNxt}${sk}`);
        ev.push({ t: t + D, ack: rcvNxt, blk: useSack ? blk : [] });
      } else {                                       // ACK reaches the sender
        e.blk.forEach(([l, r]) => { for (let x = l; x < r; x += MSS) sacked.add(x); });
        if (e.ack > una) { una = e.ack; dup = 0;
          if (una < recover && !done.has(una)) { q.unshift(una); done.add(una);
            console.log(`t=${t}  partial ACK ${una} -> retransmit ${una}`); }
        } else if (++dup === 3) {                    // third duplicate ACK
          recover = sndMax; const holes = [], top = useSack ? Math.max(...sacked) : una + 1;
          for (let x = una; x < top; x += MSS) if (!sacked.has(x) && !done.has(x)) holes.push(x);
          holes.forEach(x => done.add(x)); q.unshift(...holes);
          console.log(`t=${t}  3rd dup ACK ${una} -> fast retransmit ${holes.join(", ")}`);
        }
      }
    }
    const s = q.shift(); if (s === undefined) continue; sndMax = Math.max(sndMax, s + MSS); tx++;
    if (lossLeft.delete(s)) console.log(`t=${t}  send seq=${s} LOST`); else ev.push({ t: t + D, seq: s });
  }
  console.log(`   ACK ${END} reaches sender at t=${t - 1}, ${tx} transmissions\n`);
}
[["lose 1001, no SACK", [1001], false], ["lose 1001 and 3001, no SACK", [1001, 3001], false],
 ["lose 1001 and 3001, with SACK", [1001, 3001], true]].forEach(a => run(...a));

== lose 1001, no SACK
t=1  send seq=1001 LOST
t=2  rcv seq=1 -> ACK 1001
t=4  rcv seq=2001 -> ACK 1001
t=5  rcv seq=3001 -> ACK 1001
t=6  rcv seq=4001 -> ACK 1001
t=7  rcv seq=5001 -> ACK 1001
t=8  3rd dup ACK 1001 -> fast retransmit 1001
t=10  rcv seq=1001 -> ACK 6001
   ACK 6001 reaches sender at t=12, 7 transmissions

== lose 1001 and 3001, no SACK
t=1  send seq=1001 LOST
t=2  rcv seq=1 -> ACK 1001
t=3  send seq=3001 LOST
t=4  rcv seq=2001 -> ACK 1001
t=6  rcv seq=4001 -> ACK 1001
t=7  rcv seq=5001 -> ACK 1001
t=9  3rd dup ACK 1001 -> fast retransmit 1001
t=11  rcv seq=1001 -> ACK 3001
t=13  partial ACK 3001 -> retransmit 3001
t=15  rcv seq=3001 -> ACK 6001
   ACK 6001 reaches sender at t=17, 8 transmissions

== lose 1001 and 3001, with SACK
t=1  send seq=1001 LOST
t=2  rcv seq=1 -> ACK 1001
t=3  send seq=3001 LOST
t=4  rcv seq=2001 -> ACK 1001  SACK 2001-3001
t=6  rcv seq=4001 -> ACK 1001  SACK 4001-5001, 2001-3001
t=7  rcv seq=5001 -> ACK 1001  SACK 4001-6001, 2001-3001
t=9  3rd dup ACK 1001 -> fast retransmit 1001, 3001
t=11  rcv seq=1001 -> ACK 3001  SACK 4001-6001
t=12  rcv seq=3001 -> ACK 6001
   ACK 6001 reaches sender at t=14, 8 transmissions

TCP — Go-Back-N আর Selective Repeat-এর মিশ্রণ

পর্ব ১০-এর দুই ARQ-এর সাথে মিলিয়ে দেখলে TCP কোনো একটির হুবহু রূপ নয়:

৮ · বাস্তবের জটিলতা — অকারণ retransmission, দুর্বল checksum আর application-এর ACK

অকারণ retransmission

“হারানো” ভেবে আবার পাঠানো segment সবসময় হারায় না। মোবাইল নেটওয়ার্কে handover-এ কয়েকশো ms-এর delay-লাফ এলে RTO ফুরিয়ে যায়, অথচ segment পথেই ছিল; reordering ৩ ঘরের বেশি হলে fast retransmit ভুল সংকেত পায়। একে বলে spurious retransmission — বাড়তি ডেটা, আর অকারণে গতি কমানো (পর্ব ৩২)। শনাক্তের মানসম্মত কৌশল:

• DSACK (RFC 2883): একই ডেটা দুবার পৌঁছালে প্রাপক প্রথম SACK block-এ সেই নকল অংশটি জানায়। প্রেরক বোঝে, “আবার পাঠানোর দরকার ছিল না।”
• F-RTO (RFC 5682): timeout-এর পর আবার পাঠিয়ে প্রেরক কিছু নতুন ডেটা পাঠায়; ফিরতি ACK যদি দেখায় যে মূল segment-গুলোও পৌঁছেছিল, timeout-টি অকারণ ছিল।
• Eifel (RFC 3522): timestamps দেখে বোঝা যায় ACK-টি মূল কপির না আবার পাঠানোর।
• RACK-TLP (RFC 8985, ২০২১): dup ACK গোনার বদলে সময় দেখে loss ধরে — “পরে পাঠানো segment পৌঁছে গেছে, অথচ এটি একটি reordering-সময় পেরিয়েও আসেনি”। সাথে tail loss probe শেষ segment হারালে timeout-এর আগে একটি probe পাঠায়। সাম্প্রতিক Linux kernel-এ এটি ব্যবহৃত হয়।

TCP checksum কতটা ভরসার

TCP-র ১৬ bit checksum (পর্ব ০৯-এর internet checksum) segment-এর header, ডেটা আর IP ঠিকানাসহ একটি “pseudo-header”-এর ওপর হিসাব হয়। এটি সব একক-bit ত্রুটি ধরে, কিন্তু দুর্বলতা স্পষ্ট: দুটি ১৬ bit শব্দ জায়গা বদল করলে যোগফল একই থাকে; এক শব্দে +x আর আরেকটিতে −x ত্রুটি একে অপরকে কাটিয়ে দেয়; 0x0000 আর 0xFFFF ones' complement-এ সমান। CRC-র তুলনায় অনেক দুর্বল। ২০০০ সালে Stone আর Partridge-এর গবেষণায় আসল ট্রাফিকে এমন ত্রুটি পাওয়া যায় যা link-এর CRC পার হয়ে (router বা host-এর মেমরিতে নষ্ট হয়ে) আসে আর TCP checksum-ও ধরে না — হার কম, কিন্তু বিপুল ট্রাফিকে উপেক্ষার মতো নয়। তাই গুরুত্বপূর্ণ ডেটায় ওপরের স্তরে শক্ত যাচাই লাগে: TLS (পর্ব ৪৮), বা ফাইলের SHA-256 মেলানো।

একটি ব্যবহারিক টীকা: আধুনিক NIC নিজেই checksum হিসাব করে (checksum offload). তাই প্রেরকের নিজের যন্ত্রে tcpdump বা Wireshark-এ বাইরে যাওয়া segment-এ “incorrect checksum” দেখা যেতে পারে — capture হয়েছে NIC হিসাব বসানোর আগে। এটি সাধারণত ত্রুটি নয় (পর্ব ৫৫)।

TCP-র ACK মানে “application পেয়েছে” নয়

TCP-র ACK বলে, ডেটা প্রাপকের TCP buffer-এ পৌঁছেছে। প্রাপকের application সেটি পড়েছে, প্রক্রিয়া করেছে, ডিস্কে লিখেছে — এর কিছুই ACK জানায় না। আরও সূক্ষ্ম: প্রেরকের send() সফল হওয়া মানে শুধু ডেটা নিজের kernel-এর buffer-এ কপি হয়েছে — তখনো এক byte-ও হয়তো তার ছাড়েনি। ধরুন একটি পেমেন্ট সার্ভার অনুরোধ পেল, TCP ACK গেল, তারপর ডেটাবেসে লেখার আগেই সার্ভার বন্ধ হয়ে গেল। TCP-র দৃষ্টিতে সব ঠিক, অথচ টাকার হিসাব হারাল। এটিই end-to-end যুক্তির শেষ ধাপ: সত্যিকারের নিশ্চয়তা দিতে পারে শুধু application নিজে — HTTP response-এর মতো application-স্তরের উত্তর, message queue-র “প্রক্রিয়া শেষে ack”, আর আবার পাঠানো অনুরোধ যাতে দুবার কাটা না হয় সেজন্য idempotency key.

আসল সংযোগের ভেতরে উঁকি — TCP_INFO

Linux প্রতিটি TCP socket-এর ভেতরের অবস্থা getsockopt(..., TCP_INFO, ...) দিয়ে দেয় — struct tcp_info-এ RTT, RTO, MSS, retransmission-এর গণনা আর অনেক কিছু (ss -ti কমান্ড একই তথ্য দেখায়)। নিচের প্রোগ্রাম 127.0.0.1-এ একটি সংযোগ বানায়, client-এ TCP_NODELAY চালু করে, ১০০ byte-এর ৫০টি request-reply আদান-প্রদান করে, তারপর client socket-এর tcp_info পড়ে। Kernel-এর সংস্করণভেদে struct-এর আকার আলাদা হতে পারে, তাই প্রতিটি ঘর ছাপার আগে HAS() দেখে নেয় kernel ততদূর পর্যন্ত ভরেছে কি না (socket প্রোগ্রামিং বিস্তারিত পর্ব ৪১-এ)।

#include <stdio.h>
#include <stddef.h>
#include <string.h>
#include <arpa/inet.h>
#include <netinet/tcp.h>
#include <sys/socket.h>
/* field f is usable only if the kernel filled at least that many bytes */
#define HAS(f) (tl >= offsetof(struct tcp_info, f) + sizeof ti.f)

int main(void) {
    struct sockaddr_in a = {0}; socklen_t len = sizeof a;
    a.sin_family = AF_INET;
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);            /* 127.0.0.1, port 0 */
    int ls = socket(AF_INET, SOCK_STREAM, 0), one = 1, c, s;
    if (bind(ls, (struct sockaddr *)&a, sizeof a) || listen(ls, 1) ||
        getsockname(ls, (struct sockaddr *)&a, &len)) { perror("listen"); return 1; }
    c = socket(AF_INET, SOCK_STREAM, 0);
    if (connect(c, (struct sockaddr *)&a, sizeof a) || (s = accept(ls, NULL, NULL)) < 0) return 1;
    setsockopt(c, IPPROTO_TCP, TCP_NODELAY, &one, sizeof one);    /* Nagle off */
    char buf[4096]; memset(buf, 'x', sizeof buf);
    for (int i = 0; i < 50; i++)                               /* 50 small request/replies */
        if (send(c, buf, 100, 0) != 100 || recv(s, buf, sizeof buf, 0) <= 0 ||
            send(s, buf, 100, 0) != 100 || recv(c, buf, sizeof buf, 0) <= 0) return 1;
    struct tcp_info ti = {0}; socklen_t tl = sizeof ti; int nd = 0; socklen_t nl = sizeof nd;
    if (getsockopt(c, IPPROTO_TCP, TCP_INFO, &ti, &tl)) { perror("TCP_INFO"); return 1; }
    getsockopt(c, IPPROTO_TCP, TCP_NODELAY, &nd, &nl);
    printf("TCP_NODELAY=%d  tcp_info bytes filled=%u\n", nd, (unsigned)tl);
    if (HAS(tcpi_advmss)) printf("pmtu=%u  advmss=%u  snd_mss=%u  rcv_mss=%u (bytes)\n",
        ti.tcpi_pmtu, ti.tcpi_advmss, ti.tcpi_snd_mss, ti.tcpi_rcv_mss);
    if (HAS(tcpi_rttvar)) printf("rtt=%u us  rttvar=%u us\n", ti.tcpi_rtt, ti.tcpi_rttvar);
    if (HAS(tcpi_ato)) printf("rto=%u us  ato (delayed-ACK timeout)=%u us\n", ti.tcpi_rto, ti.tcpi_ato);
    if (HAS(tcpi_total_retrans)) printf("retransmits now=%u  total=%u\n",
        (unsigned)ti.tcpi_retransmits, ti.tcpi_total_retrans);
    return 0;
}

TCP_NODELAY=1  tcp_info bytes filled=104
pmtu=65535  advmss=65483  snd_mss=22016  rcv_mss=536 (bytes)
rtt=18 us  rttvar=4 us
rto=201000 us  ato (delayed-ACK timeout)=40000 us
retransmits now=0  total=0

৯ · AI-এর যুগে TCP-র অঙ্ক আর টিউনিং

“seq/ack বের করুন” বা “RTO হিসাব করুন” — AI-এর উত্তর আসে মুহূর্তে, সুন্দর টেবিলসহ। কিন্তু ভুলের ধরন চেনা: off-by-one, ভুল ক্রম, একটি OS-এর মানকে standard বলে চালানো, আর টিউনিংয়ে পুরো সার্ভারের kernel সেটিং বদলানোর পরামর্শ।

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

• প্রতিটি seq আর ack নিজে হিসাব করে মিলিয়েছি — বিশেষ করে off-by-one (শেষ byte বনাম পরের byte)
• RTO-র অঙ্কে কোন ক্রম (RFC বনাম পাঠ্যবই) আর কোন ন্যূনতম মান ধরা হয়েছে, তা স্পষ্ট
• উল্লেখ করা প্রতিটি RFC নম্বর খুলে শিরোনাম মিলিয়েছি
• কোনো kernel বা registry সেটিং বদলানোর আগে ss -ti, tcpdump বা Wireshark দিয়ে সমস্যাটি মেপেছি, আর পরিবর্তনের পর আবার মেপেছি
• সেটিংটি পুরো সিস্টেমের (sysctl) না একটি socket-এর (setsockopt) — জেনে তবেই বদলেছি, আর আগের মান লিখে রেখেছি