TCP সংযোগ — three-way handshake, state আর বন্ধ করা

১ · TCP কী সেবা দেয় — দুই প্রান্তের মাঝে একটি নির্ভরযোগ্য নল

পর্ব ২৭-এ দেখেছেন, transport স্তর port নম্বর দিয়ে একটি কম্পিউটারের ভেতরের নির্দিষ্ট প্রোগ্রামের কাছে ডেটা পৌঁছায়। পর্ব ২৮-এর UDP সেখানে থেমে যায় — একটি datagram পাঠায়, পৌঁছাল কি না খোঁজ রাখে না। কিন্তু ব্যাংকের লেনদেন, ওয়েবপেজ, ইমেইল বা ফাইল ডাউনলোডে একটি বাইটও হারানো চলে না, ক্রমও উল্টানো চলে না। এই কাজের জন্য আছে TCP.

নিচের IP স্তর কোনো নিশ্চয়তা দেয় না: packet হারাতে পারে, দুবার পৌঁছাতে পারে, ক্রম উল্টে যেতে পারে। TCP এই অবিশ্বস্ত ভিত্তির ওপর দাঁড়িয়ে প্রোগ্রামকে একটি পরিষ্কার প্রতিশ্রুতি দেয়। TCP-র সেবার পাঁচটি বৈশিষ্ট্য মনে রাখুন:

এর সাথে আরও দুটি সেবা আছে, যা পরের পর্বগুলোর বিষয়: flow control (ধীর প্রাপককে ডুবিয়ে না দেওয়া, পর্ব ৩১) আর congestion control (নেটওয়ার্কের জ্যাম বুঝে গতি কমানো, পর্ব ৩২)।

একটি TCP সংযোগকে চেনা যায় চারটি মান দিয়ে: উৎস IP, উৎস port, গন্তব্য IP আর গন্তব্য port (protocol ধরলে 5-tuple). একটি ওয়েব সার্ভার port 443-এ হাজার হাজার client-এর সাথে একসাথে কথা বলে, কারণ প্রতিটি সংযোগের চার-মানের জোড়া আলাদা। কীভাবে OS আসা segment-কে ঠিক socket-এ পাঠায় (demultiplexing), তা পর্ব ২৭-এ দেখেছেন।

২ · TCP header — প্রতিটি ঘর, আর একটি আসল SYN পড়া

প্রতিটি TCP segment-এর সামনে থাকে কমপক্ষে ২০ বাইটের header. RFC-এর পরিচিত ছবিতে প্রতিটি সারি ৩২ bit (৪ বাইট):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌───────────────────────────────┬───────────────────────────────┐
│          Source Port          │       Destination Port        │
├───────────────────────────────┴───────────────────────────────┤
│                        Sequence Number                        │
├───────────────────────────────────────────────────────────────┤
│                     Acknowledgment Number                     │
├───────┬───────┬─┬─┬─┬─┬─┬─┬─┬─┬───────────────────────────────┤
│ Data  │ Rsrvd │C│E│U│A│P│R│S│F│                               │
│Offset │       │W│C│R│C│S│S│Y│I│            Window             │
│       │       │R│E│G│K│H│T│N│N│                               │
├───────┴───────┴─┴─┴─┴─┴─┴─┴─┴─┼───────────────────────────────┤
│           Checksum            │        Urgent Pointer         │
├───────────────────────────────┴───────────────────────────────┤
│              Options (0–40 বাইট) … + padding                  │
├───────────────────────────────────────────────────────────────┤
│                     ডেটা (payload)                            │
└───────────────────────────────────────────────────────────────┘

আটটি flag — প্রতিটি একটি করে bit

ছোট একটি হিসাব পরীক্ষায় প্রায়ই আসে: data offset ৪ bit, তাই সর্বোচ্চ মান ১৫, header সর্বোচ্চ ১৫ × ৪ = ৬০ বাইট; নির্দিষ্ট অংশ ২০ বাইট, তাই option-এর জায়গা সর্বোচ্চ ৪০ বাইট। Window ঘর ১৬ bit, তাই scaling ছাড়া সর্বোচ্চ window ৬৫,৫৩৫ বাইট।

একটি আসল SYN, বাইট ধরে ধরে

পর্ব ১৬-এ একটি container (10.0.2.100) থেকে ওয়েব সার্ভারে (192.0.2.80) যাওয়া প্রথম packet-এর IPv4 header পড়েছিলেন। তার Total Length ছিল ৬০ বাইট — ২০ বাইট IP, বাকি ৪০ বাইট TCP. এবার সেই ৪০ বাইট খুলে দেখা যাক। Linux-এর একটি সাধারণ SYN দেখতে এমন (প্রতি ঘর ৪ hex অঙ্ক = ২ বাইট):

b26e 01bb 9a3f 21c4 0000 0000 a002 faf0 6a36 0000
0204 05b4 0402 080a 0016 a3e1 0000 0000 0103 0307

এই চারটি option-এর প্রতিটি একটি সমস্যার সমাধান। MSS বলে “আমাকে এক segment-এ এর বেশি ডেটা পাঠাবেন না” — হিসাবটা সহজ: Ethernet-এর MTU ১৫০০ থেকে IPv4 header ২০ আর TCP header ২০ বাদ দিলে ১৪৬০ (IPv6-এ ৪০ বাইট header, তাই ১৪৪০)। খেয়াল করুন, MSS-এ option-এর বাইট ধরা হয় না; timestamp চালু থাকলে প্রতিটি segment-এ আসল ডেটা আরও ১২ বাইট কম যায়। Window scale দ্রুত, লম্বা পথের জন্য ৬৫,৫৩৫-এর সীমা ভাঙে। SACK হারানো খণ্ড ঠিকঠাক জানাতে দেয়, আর timestamp RTT মাপে আর পুরোনো segment চিনতে সাহায্য করে। এদের প্রায় সবই শুধু SYN-এ প্রস্তাব করা যায় — দুই পক্ষই প্রস্তাব দিলে তবেই চালু হয়। এই কারণে handshake শুধু “হ্যালো” নয়, একটি চুক্তিও।

৩ · Three-way handshake — কেন ঠিক তিনটি বার্তা

Three-way handshake-এর কাজ একটাই: দুই প্রান্তকে একে অপরের প্রথম sequence number-এ একমত করা, আর দুজনেই যেন জানে যে অন্যজন সেটা পেয়েছে। নিচের ডায়াগ্রামে client-এর ISN ১০০০, server-এর ৫০০০ ধরা হয়েছে (বাস্তবে এগুলো এলোমেলো বড় সংখ্যা, পরীক্ষায় হিসাব সহজ রাখতে ছোট নেওয়া হয়)। “পরে” চাপুন:

দুটি বার্তায় কেন হয় না

ধরুন handshake দুই ধাপের হতো: client SYN পাঠায়, server SYN+ACK দিয়েই ESTABLISHED. তাহলে server জানতেই পারত না তার নিজের ISN client-এর কাছে পৌঁছেছে কি না। আরও বড় বিপদ — পুরোনো নকল SYN. আগের কোনো সংযোগের একটি SYN নেটওয়ার্কে কোথাও আটকে ছিল, অনেক পরে server-এ পৌঁছাল। দুই ধাপের নিয়মে server সেটাকে নতুন সংযোগ ভেবে ESTABLISHED হয়ে বসে থাকত, এমনকি ডেটাও পাঠাতে শুরু করত — অথচ client-এর কোনো ধারণাই নেই।

তিন ধাপে এটি হয় না। Server-এর SYN+ACK পেয়ে client দেখে, ack নম্বরটি তার বর্তমান কোনো SYN-এর সাথে মেলে না। তখন সে ACK না দিয়ে RST পাঠায়, আর server সারিটি মুছে ফেলে। মূল নিয়মটি হলো: প্রতিটি দিকের ISN একবার পাঠাতে হয় আর একবার স্বীকার করাতে হয় — দুই দিক × দুই কাজ = চারটি কাজ। মাঝের দুটি (server-এর ACK আর server-এর SYN) একটি segment-এ জোড়া যায়, তাই তিনটি বার্তা।

ISN কেন এলোমেলো

প্রথম কারণ নির্ভরযোগ্যতা: একই চার-মানের (IP আর port) জোড়ায় পুরোনো সংযোগ বন্ধ হয়ে নতুন সংযোগ খুললে, পুরোনো সংযোগের দেরিতে আসা segment-এর নম্বর যেন নতুন সংযোগের বৈধ পরিসরে না পড়ে। RFC 793 এজন্য প্রায় প্রতি ৪ মাইক্রোসেকেন্ডে এক করে বাড়া একটি ঘড়ি থেকে ISN নেওয়ার কথা বলেছিল।

দ্বিতীয় কারণ নিরাপত্তা, যা পরে বোঝা গেছে। ISN অনুমান করা গেলে একজন আক্রমণকারী অন্যের IP ঠিকানা নকল করে (IP spoofing) উত্তর না দেখেও একটি TCP সংযোগ “জাল” করতে পারত, কারণ handshake-এর তৃতীয় ACK-এ কোন নম্বর বসাতে হবে তা সে আগেই জানত। তাই আধুনিক নিয়ম (RFC 6528, ২০১২): ISN = একটি ঘড়ি + চার-মানের জোড়া আর একটি গোপন চাবির cryptographic hash. এতে প্রতিটি জোড়ার নম্বর বাইরে থেকে অনুমান-অযোগ্য, অথচ একই জোড়ায় সময়ের সাথে বাড়তেই থাকে। Linux, Windows, macOS-সহ প্রধান OS-গুলো এই ধরনের কৌশল ব্যবহার করে বলে জানা যায়, যদিও প্রত্যেকের সূক্ষ্ম বিবরণ আলাদা।

Simultaneous open — বিরল, কিন্তু বৈধ

দুই প্রান্ত যদি ঠিক একই সময়ে একে অপরের পরিচিত port-এ connect() করে, দুটি SYN পথে একে অপরকে অতিক্রম করে। তখন দুজনেই SYN-SENT থেকে অন্যের SYN পেয়ে SYN-RECEIVED হয়, SYN+ACK পাঠায়, আর সেটি পেয়ে ESTABLISHED — মোট চারটি segment, কোনো LISTEN ছাড়াই। এটি simultaneous open. সাধারণ client-server জীবনে প্রায় দেখা যায় না, তবে দুই NAT-এর পেছনের যন্ত্র TCP hole punching করলে (পর্ব ১৯-এর ধারণা) এই পথই কাজে লাগে।

৪ · TCP-র state machine — এগারোটি অবস্থা

প্রতিটি TCP সংযোগ জীবনভর কয়েকটি নির্দিষ্ট অবস্থার মধ্যে ঘোরে। কোন অবস্থায় কোন ঘটনা (প্রোগ্রামের ডাক বা আসা segment) এলে কোথায় যেতে হবে, তা RFC-তে নির্দিষ্ট — একে বলে TCP state machine. প্রথমে এগারোটি অবস্থা:

পরীক্ষায় সাধারণত পুরো জীবনচক্রটি পাশাপাশি দুই পথে আঁকতে বলা হয় — client-এর “active” পথ আর server-এর “passive” পথ। সময় ওপর থেকে নিচে চলছে:

   Client (active open, active close)            Server (passive open)
   ──────────────────────────────────            ─────────────────────
   CLOSED                                        CLOSED
                                                   │ listen()
                                                 LISTEN
   connect() ─── SYN seq=x ──────────────────────▶ │
   SYN-SENT                                      SYN-RECEIVED
       │ ◀──────────── SYN+ACK seq=y ack=x+1 ─────┘
   ESTABLISHED ── ACK ack=y+1 ───────────────────▶ ESTABLISHED
       ⋮               (ডেটা দুই দিকে)                 ⋮
   close() ────── FIN seq=u ─────────────────────▶ │
   FIN-WAIT-1                                    CLOSE-WAIT
       │ ◀──────────── ACK ack=u+1 ───────────────┘   (server চাইলে আরও ডেটা পাঠায়)
   FIN-WAIT-2                                        │ close()
       │ ◀──────────── FIN seq=v ack=u+1 ─────────┘
   TIME-WAIT ──── ACK ack=v+1 ───────────────────▶ LAST-ACK → CLOSED
       │ (2·MSL অপেক্ষা)
   CLOSED

State machine চালিয়ে দেখা

নিচের সিমুলেটরে দুই প্রান্ত A আর B. প্রতিটি “app” ঘটনা প্রোগ্রামের ডাক (listen, connect, close, abort), আর “gets” মানে পথে থাকা segment পৌঁছাল। একটি ছোট table-এ “বর্তমান অবস্থা + ঘটনা → নতুন অবস্থা + পাঠানো segment” লেখা; চারটি গল্প চালানো হয়েছে: স্বাভাবিক, একসাথে বন্ধ, বন্ধ port-এ SYN, আর abort.

// TCP state machine (RFC 9293 simplified): app calls + arriving segments -> new state + reply.
const T = {
  'CLOSED listen': ['LISTEN'],               'CLOSED connect': ['SYN-SENT', 'SYN'],
  'CLOSED SYN': ['CLOSED', 'RST'],           'LISTEN SYN': ['SYN-RECEIVED', 'SYN+ACK'],
  'SYN-SENT SYN+ACK': ['ESTABLISHED', 'ACK'], 'SYN-SENT RST': ['CLOSED'],
  'SYN-RECEIVED ACK': ['ESTABLISHED'],       'ESTABLISHED close': ['FIN-WAIT-1', 'FIN'],
  'ESTABLISHED FIN': ['CLOSE-WAIT', 'ACK'],  'ESTABLISHED abort': ['CLOSED', 'RST'],
  'ESTABLISHED RST': ['CLOSED'],             'FIN-WAIT-1 ACK': ['FIN-WAIT-2'],
  'FIN-WAIT-1 FIN': ['CLOSING', 'ACK'],      'FIN-WAIT-2 FIN': ['TIME-WAIT', 'ACK'],
  'CLOSING ACK': ['TIME-WAIT'],              'CLOSE-WAIT close': ['LAST-ACK', 'FIN'],
  'LAST-ACK ACK': ['CLOSED'],                'TIME-WAIT 2MSL': ['CLOSED'],
};
function run(title, steps, start = 'CLOSED') {
  console.log('== ' + title);
  const st = { A: start, B: start }, net = [];   // net = segments in flight (FIFO)
  const fire = (side, ev, how) => {
    const r = T[st[side] + ' ' + ev];
    if (!r) { console.log(`  ${side} ${st[side]} ignores ${ev}`); return; }
    const line = `  ${side} ${st[side].padEnd(12)} --${how} ${ev}`.padEnd(38) + `-> ${r[0].padEnd(12)}`;
    console.log((line + (r[1] ? ` sends ${r[1]}` : '')).trimEnd());
    st[side] = r[0];
    if (r[1]) net.push([side === 'A' ? 'B' : 'A', r[1]]);
  };
  for (const s of steps) {
    if (s === '*') while (net.length) { const [to, seg] = net.shift(); fire(to, seg, 'gets'); }
    else fire(s[0], s.slice(2), s.endsWith('2MSL') ? 'timer' : 'app');
  }
}
run('normal: A = client, B = server', ['B listen', 'A connect', '*', 'A close', '*', 'B close', '*', 'A 2MSL']);
run('simultaneous close', ['A close', 'B close', '*', 'A 2MSL', 'B 2MSL'], 'ESTABLISHED');
run('RST 1: SYN to a closed port', ['A connect', '*']);
run('RST 2: abort instead of FIN', ['A abort', '*'], 'ESTABLISHED');

== normal: A = client, B = server
  B CLOSED       --app listen         -> LISTEN
  A CLOSED       --app connect        -> SYN-SENT     sends SYN
  B LISTEN       --gets SYN           -> SYN-RECEIVED sends SYN+ACK
  A SYN-SENT     --gets SYN+ACK       -> ESTABLISHED  sends ACK
  B SYN-RECEIVED --gets ACK           -> ESTABLISHED
  A ESTABLISHED  --app close          -> FIN-WAIT-1   sends FIN
  B ESTABLISHED  --gets FIN           -> CLOSE-WAIT   sends ACK
  A FIN-WAIT-1   --gets ACK           -> FIN-WAIT-2
  B CLOSE-WAIT   --app close          -> LAST-ACK     sends FIN
  A FIN-WAIT-2   --gets FIN           -> TIME-WAIT    sends ACK
  B LAST-ACK     --gets ACK           -> CLOSED
  A TIME-WAIT    --timer 2MSL         -> CLOSED
== simultaneous close
  A ESTABLISHED  --app close          -> FIN-WAIT-1   sends FIN
  B ESTABLISHED  --app close          -> FIN-WAIT-1   sends FIN
  B FIN-WAIT-1   --gets FIN           -> CLOSING      sends ACK
  A FIN-WAIT-1   --gets FIN           -> CLOSING      sends ACK
  A CLOSING      --gets ACK           -> TIME-WAIT
  B CLOSING      --gets ACK           -> TIME-WAIT
  A TIME-WAIT    --timer 2MSL         -> CLOSED
  B TIME-WAIT    --timer 2MSL         -> CLOSED
== RST 1: SYN to a closed port
  A CLOSED       --app connect        -> SYN-SENT     sends SYN
  B CLOSED       --gets SYN           -> CLOSED       sends RST
  A SYN-SENT     --gets RST           -> CLOSED
== RST 2: abort instead of FIN
  A ESTABLISHED  --app abort          -> CLOSED       sends RST
  B ESTABLISHED  --gets RST           -> CLOSED

৫ · সংযোগ বন্ধ করা — FIN, half-close আর TIME-WAIT

TCP full-duplex, তাই দুই দিকের প্রবাহ আলাদা করে বন্ধ করতে হয়। যে দিকে আর ডেটা যাবে না, সেই দিকের প্রেরক FIN পাঠায়, অন্যজন ACK দেয়। দুই দিক × (FIN + ACK) = চারটি segment — একে প্রায়ই “four-way” বন্ধ বলা হয়। মাঝের ACK আর FIN কখনো কখনো একসাথে যায়, তখন তিনটি segment-এই কাজ শেষ। আগের উদাহরণের সংযোগটিই চলুক: client ৩০০ বাইট পাঠিয়েছে (পরের বাইট ১৩০১), server ৩০০ বাইট (পরের বাইট ৫৩০১)। এবার client বন্ধ করছে:

সংখ্যা মিলিয়ে দেখা — পরীক্ষার মতো seq/ack হিসাব

পরীক্ষায় প্রায়ই দেওয়া থাকে দুই ISN আর কে কত বাইট পাঠাল; লিখতে হয় প্রতিটি segment-এর seq আর ack. নিয়ম মাত্র তিনটি: (১) segment-এর seq = প্রেরকের পরের বাইটের নম্বর; (২) ack = প্রাপক পরের যে বাইট চায়; (৩) ডেটা len বাইট খরচ করে, SYN আর FIN একটি করে, খালি ACK কিছুই না। নিচের হিসাবযন্ত্র ঠিক এটুকুই করে, আর নম্বর ২^৩২-এ ঘুরে আসে (modulo):

// Exam-style TCP seq/ack calculator: handshake, data, four-way close (no loss, in order).
const M = 2 ** 32;                                   // sequence numbers wrap at 2^32
function trace(title, isnC, isnS, events) {
  console.log(`== ${title}  (ISN client=${isnC}, ISN server=${isnS})`);
  const s = { C: { nxt: isnC, rcv: null }, S: { nxt: isnS, rcv: null } };
  let n = 0;
  const send = (who, flags, len) => {
    const me = s[who], peer = s[who === 'C' ? 'S' : 'C'];
    const seq = me.nxt, ack = flags.includes('ACK') ? String(me.rcv) : '-';
    const used = len + (/SYN|FIN/.test(flags) ? 1 : 0);   // SYN and FIN each use 1 number
    me.nxt = (me.nxt + used) % M;
    peer.rcv = me.nxt;                               // receiver now expects this byte next
    console.log(`${String(++n).padStart(2)}. ${who === 'C' ? 'C->S' : 'S->C'} ${flags.padEnd(8)}` +
      ` seq=${String(seq).padEnd(10)} ack=${ack.padEnd(10)} len=${String(len).padEnd(4)} uses ${used}`);
  };
  send('C', 'SYN', 0); send('S', 'SYN+ACK', 0); send('C', 'ACK', 0);
  for (const e of events) {
    const [who, what] = e.split(' ');
    if (what === 'FIN') send(who, 'FIN+ACK', 0);
    else if (what === 'ACK') send(who, 'ACK', 0);
    else send(who, 'PSH+ACK', Number(what));
  }
  console.log(`   next byte: client ${s.C.nxt}, server ${s.S.nxt}`);
}
trace('exam question', 1000, 5000,
  ['C 100', 'C 200', 'S ACK', 'S 300', 'C ACK', 'C FIN', 'S ACK', 'S FIN', 'C ACK']);
trace('wrap-around', M - 100, 7000, ['C 150', 'S ACK']);

== exam question  (ISN client=1000, ISN server=5000)
 1. C->S SYN      seq=1000       ack=-          len=0    uses 1
 2. S->C SYN+ACK  seq=5000       ack=1001       len=0    uses 1
 3. C->S ACK      seq=1001       ack=5001       len=0    uses 0
 4. C->S PSH+ACK  seq=1001       ack=5001       len=100  uses 100
 5. C->S PSH+ACK  seq=1101       ack=5001       len=200  uses 200
 6. S->C ACK      seq=5001       ack=1301       len=0    uses 0
 7. S->C PSH+ACK  seq=5001       ack=1301       len=300  uses 300
 8. C->S ACK      seq=1301       ack=5301       len=0    uses 0
 9. C->S FIN+ACK  seq=1301       ack=5301       len=0    uses 1
10. S->C ACK      seq=5301       ack=1302       len=0    uses 0
11. S->C FIN+ACK  seq=5301       ack=1302       len=0    uses 1
12. C->S ACK      seq=1302       ack=5302       len=0    uses 0
   next byte: client 1302, server 5302
== wrap-around  (ISN client=4294967196, ISN server=7000)
 1. C->S SYN      seq=4294967196 ack=-          len=0    uses 1
 2. S->C SYN+ACK  seq=7000       ack=4294967197 len=0    uses 1
 3. C->S ACK      seq=4294967197 ack=7001       len=0    uses 0
 4. C->S PSH+ACK  seq=4294967197 ack=7001       len=150  uses 150
 5. S->C ACK      seq=7001       ack=51         len=0    uses 0
   next byte: client 51, server 7001

Half-close — এক দিক বন্ধ, অন্য দিক খোলা

close() দুই দিকই ছেড়ে দেয়: প্রোগ্রাম আর পড়তেও পারে না, লিখতেও না। কিন্তু অনেক সময় দরকার শুধু “আমার পাঠানো শেষ” জানানো, উত্তর তখনো আসবে। যেমন client একটি ফাইল পাঠিয়ে বলবে “শেষ”, আর server পুরো ফাইল পেয়ে তবে হিসাব করে উত্তর দেবে। এর জন্য shutdown(fd, SHUT_WR) — এটি FIN পাঠায় কিন্তু পড়ার দিক খোলা রাখে। একে বলে half-close. নিচের C প্রোগ্রামে fork() দিয়ে একই প্রোগ্রামে server আর client চলে, loopback-এ (127.0.0.1). Server parent, client child; সব লাইন ঠিক ক্রমে আসে, কারণ client কিছু ছাপে শুধু server-এর উত্তর পাওয়ার পরে।

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <arpa/inet.h>
#include <sys/socket.h>

int main(void) {
    setvbuf(stdout, NULL, _IONBF, 0);              /* no buffering: lines appear in real order */
    struct sockaddr_in a = {0};
    a.sin_family = AF_INET; a.sin_port = htons(47290);
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);    /* 127.0.0.1 */
    int ls = socket(AF_INET, SOCK_STREAM, 0);      /* SOCK_STREAM = TCP */
    if (bind(ls, (struct sockaddr *)&a, sizeof a) < 0 || listen(ls, 8) < 0) { perror("listen"); return 1; }
    char buf[64]; ssize_t n;  printf("server: listen() on 127.0.0.1:47290      -> LISTEN\n");
    if (fork() == 0) {                             /* child process = client */
        int c = socket(AF_INET, SOCK_STREAM, 0);
        if (connect(c, (struct sockaddr *)&a, sizeof a) < 0) { perror("connect"); _exit(1); }
        if (write(c, "hello", 5) != 5) _exit(1);
        shutdown(c, SHUT_WR);                      /* half-close: send FIN, keep reading */
        n = read(c, buf, sizeof buf - 1); buf[n > 0 ? n : 0] = '\0';
        printf("client: connect, write 5, shutdown(SHUT_WR) -> FIN-WAIT-2\n");
        printf("client: still reading after half-close: \"%s\"\n", buf);
        printf("client: read() = %zd, server FIN arrived   -> TIME-WAIT\n", read(c, buf, sizeof buf));
        close(c); _exit(0);
    }
    int s = accept(ls, NULL, NULL);                /* handshake was already done by the kernel */
    printf("server: accept() gave a new socket       -> ESTABLISHED\n");
    n = read(s, buf, sizeof buf - 1); buf[n > 0 ? n : 0] = '\0';
    printf("server: read() = %zd bytes \"%s\"\n", n, buf);
    printf("server: read() = %zd, EOF (client FIN)    -> CLOSE-WAIT\n", read(s, buf, sizeof buf));
    if (write(s, "bye from server", 15) != 15) return 1;   /* half-closed peer can still receive */
    close(s); wait(NULL);                          /* our FIN -> LAST-ACK; client -> TIME-WAIT */
    printf("server: wrote 15 bytes, close()          -> LAST-ACK, CLOSED\n");
    close(ls); return 0;
}

server: listen() on 127.0.0.1:47290      -> LISTEN
server: accept() gave a new socket       -> ESTABLISHED
server: read() = 5 bytes "hello"
server: read() = 0, EOF (client FIN)    -> CLOSE-WAIT
client: connect, write 5, shutdown(SHUT_WR) -> FIN-WAIT-2
client: still reading after half-close: "bye from server"
client: read() = 0, server FIN arrived   -> TIME-WAIT
server: wrote 15 bytes, close()          -> LAST-ACK, CLOSED

TIME-WAIT কেন আছে — দুটি কারণ

1. শেষ ACK হারালে: server LAST-ACK-এ বসে থেকে আবার FIN পাঠাবে। Client যদি ততক্ষণে সব ভুলে যেত, সে এই অচেনা FIN-এর উত্তরে RST পাঠাত, আর server-এর প্রোগ্রাম একটি সফল সংযোগের শেষে অকারণে error দেখত। TIME-WAIT-এ থাকা client FIN চিনে আবার ACK দেয়।
2. দেরিতে আসা পুরোনো segment: একই চার-মানের জোড়ায় সঙ্গে সঙ্গে নতুন সংযোগ খুললে, পুরোনো সংযোগের কোনো দেরি-হওয়া segment (কোথাও router-এর queue-তে আটকে ছিল) নতুন সংযোগের ডেটা হিসেবে ঢুকে যেতে পারত। ২·MSL অপেক্ষা মানে এক দিকে যাওয়া আর উত্তর ফেরার সর্বোচ্চ আয়ু — এর মধ্যে সব পুরোনো segment মরে যায়।

খেয়াল করুন, TIME-WAIT-এর বোঝা বহন করে active close করা পক্ষ — যে আগে FIN দেয়। RFC-র উদাহরণ MSL ২ মিনিট, ফলে TIME-WAIT ৪ মিনিট হতো; বাস্তব OS-গুলো ছোট মান নেয়। Linux-এ TIME-WAIT kernel-এ বাঁধা ৬০ সেকেন্ড (TCP_TIMEWAIT_LEN), sysctl দিয়ে বদলানো যায় না বলেই জানা যায়; Windows-এ ডিফল্ট সাধারণত ১২০ সেকেন্ড বলে উল্লেখ আছে, registry দিয়ে বদলানো যায়। একটি প্রচলিত ভুল ধারণা: Linux-এর tcp_fin_timeout TIME-WAIT-এর দৈর্ঘ্য নয় — এটি মূলত FIN-WAIT-2-এ অনাথ (orphan) সংযোগ কতক্ষণ থাকবে তা ঠিক করে।

ব্যস্ত client-এ হাজার হাজার TIME-WAIT — ঠিক আর ভুল সমাধান

একটি সার্ভিস প্রতি অনুরোধে ডেটাবেস বা অন্য API-তে নতুন TCP সংযোগ খুলে আবার বন্ধ করলে, প্রতিটি সংযোগ ৬০ সেকেন্ড TIME-WAIT-এ পড়ে থাকে। একই গন্তব্য (IP, port)-এ নতুন সংযোগের জন্য আলাদা উৎস port লাগে, আর Linux-এর ephemeral পরিসর 32768–60999 মানে ২৮,২৩২টি port. তাই একই গন্তব্যে টানা হারে সর্বোচ্চ প্রায় ২৮২৩২ ÷ ৬০ ≈ ৪৭০টি নতুন সংযোগ প্রতি সেকেন্ডে — এর বেশি হলে connect() EADDRNOTAVAIL দিতে শুরু করে। এটাই ephemeral port exhaustion.

SO_REUSEADDR-এর অর্থ নিয়ে বিভ্রান্তি খুব সাধারণ। Linux-এ এটি দিলে একটি listening socket সেই port-এ bind() করতে পারে, যদিও আগের চালানোর সংযোগগুলো TIME-WAIT-এ পড়ে আছে — না দিলে restart-এর পর এক মিনিট Address already in use. এটি TIME-WAIT মোছে না, পুরোনো segment-এর সুরক্ষাও নষ্ট করে না, কারণ চার-মানের জোড়া নতুন client-দের ক্ষেত্রে আলাদা। BSD/macOS আর Windows-এ এই option-এর সূক্ষ্ম আচরণ আলাদা (Windows-এ এর অর্থ আরও বিপজ্জনকভাবে ঢিলা, তাই সেখানে SO_EXCLUSIVEADDRUSE সুপারিশ করা হয়) — তাই অন্য OS-এ কোড নেওয়ার আগে তার নথি দেখে নিন।

৬ · নিজের চোখে state দেখা, আর RST — হঠাৎ বন্ধ

Linux-এ প্রতিটি TCP socket-এর বর্তমান অবস্থা দেখায় ss -tan (t = TCP, a = সব, n = নাম নয় সংখ্যা)। পুরোনো netstat -tan-ও একই কাজ করত, কিন্তু অনেক নতুন distribution-এ সেটি আর ডিফল্টে থাকে না। নিচের প্রোগ্রাম একটি process-এর ভেতরেই loopback-এ server (port 47291) আর client (port 47292) খোলে, তিনটি মুহূর্তে ss চালায় — ss না থাকলে /proc/net/tcp থেকে কাঁচা সারি দেখায় — আর শেষে এমন একটি port-এ connect() করে যেখানে কেউ শুনছে না।

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

static struct sockaddr_in at(unsigned short port) {
    struct sockaddr_in a = {0};
    a.sin_family = AF_INET; a.sin_port = htons(port);
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    return a;
}
static void show(const char *when) {               /* ss if present, else raw /proc/net/tcp */
    printf("--- %s\n", when); fflush(stdout);
    if (system("command -v ss >/dev/null && ss -tan | awk 'NR==1 || /:4729[12]/' "
               "|| grep -i ':B8B[BC] ' /proc/net/tcp") != 0) printf("(no output)\n");
}
int main(void) {
    struct sockaddr_in srv = at(47291), cli = at(47292), off = at(47299);
    int ls = socket(AF_INET, SOCK_STREAM, 0), c = socket(AF_INET, SOCK_STREAM, 0);
    bind(ls, (struct sockaddr *)&srv, sizeof srv); listen(ls, 8);
    bind(c, (struct sockaddr *)&cli, sizeof cli);  /* fixed client port, easy to spot */
    if (connect(c, (struct sockaddr *)&srv, sizeof srv) < 0) { perror("connect"); return 1; }
    int s = accept(ls, NULL, NULL);
    show("after connect + accept");
    close(c);  show("client closed first (active close)");
    close(s);  show("server closed too");
    int z = socket(AF_INET, SOCK_STREAM, 0);
    if (connect(z, (struct sockaddr *)&off, sizeof off) < 0)
        printf("--- connect to 127.0.0.1:47299 (nobody listening): %s (errno %d)\n", strerror(errno), errno);
    return 0;
}

--- after connect + accept
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      8          127.0.0.1:47291      0.0.0.0:*
ESTAB  0      0          127.0.0.1:47291    127.0.0.1:47292
ESTAB  0      0          127.0.0.1:47292    127.0.0.1:47291
--- client closed first (active close)
State      Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN     0      8          127.0.0.1:47291      0.0.0.0:*
CLOSE-WAIT 1      0          127.0.0.1:47291    127.0.0.1:47292
FIN-WAIT-2 0      0          127.0.0.1:47292    127.0.0.1:47291
--- server closed too
State     Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN    0      8          127.0.0.1:47291      0.0.0.0:*
TIME-WAIT 0      0          127.0.0.1:47292    127.0.0.1:47291
--- connect to 127.0.0.1:47299 (nobody listening): Connection refused (errno 111)

RST কখন আসে

FIN হলো ভদ্রভাবে বিদায় — “আমার কথা শেষ, আপনার শেষ হলে জানাবেন”, কোনো ডেটা হারায় না। RST হলো ফোন কেটে দেওয়া — সংযোগ এখনই শেষ, পথে বা buffer-এ থাকা ডেটা বাতিল, কোনো TIME-WAIT নেই, আর অন্য পক্ষের প্রোগ্রাম সাধারণত error পায়। RST পাঠানোর প্রধান পরিস্থিতি:

• বন্ধ port-এ SYN: কেউ শুনছে না — উত্তরে RST, client পায় Connection refused. (Firewall থাকলে প্রায়ই কোনো উত্তরই আসে না; তখন client বারবার SYN পাঠিয়ে শেষে timeout পায় — “refused” আর “timed out”-এর পার্থক্য সমস্যা খুঁজতে খুব কাজের।)
• Abort: প্রোগ্রাম SO_LINGER শূন্য দিয়ে বন্ধ করলে, অথবা Linux-এ এখনো না-পড়া ডেটা receive buffer-এ রেখে close() করলে kernel FIN-এর বদলে RST পাঠায়। অন্য পক্ষ দেখে Connection reset by peer (ECONNRESET).
• Half-open সংযোগ ধরা পড়া: এক পক্ষ crash বা reboot করে সব ভুলে গেছে, অন্য পক্ষ জানে না। পুরোনো পক্ষ ডেটা পাঠালে নতুন-জাগা পক্ষ অচেনা segment দেখে RST দেয় — তখন সংযোগটি পরিষ্কার হয়।
• অচেনা বা অবৈধ segment: যেমন handshake-এ ভুল ack নম্বরের SYN+ACK (পুরোনো নকল SYN-এর গল্প)।

RST যেহেতু এক segment-এই সংযোগ শেষ করে, কেউ RST জাল করতে পারলে অন্যের সংযোগ ভেঙে দিতে পারত। তাই আধুনিক TCP (RFC 5961) RST গ্রহণ করে কেবল তখনই, যখন তার seq ঠিক প্রত্যাশিত নম্বরের সাথে মেলে; window-এর ভেতরে কিন্তু ঠিক না মিললে একটি “challenge ACK” পাঠিয়ে যাচাই করে। ISN এলোমেলো রাখার মতোই, এটিও অনুমান-অযোগ্যতার ওপর দাঁড়ানো প্রতিরক্ষা।

৭ · Listen backlog, SYN flood আর SYN cookie

Server-এর kernel প্রতিটি listening socket-এর জন্য দুটি queue রাখে:

• SYN queue: SYN এসেছে, SYN+ACK গেছে, শেষ ACK-এর অপেক্ষা — SYN-RECEIVED অবস্থার অর্ধেক-তৈরি সংযোগ। প্রতিটির জন্য একটি ছোট সারি (ঠিকানা, ISN, option) রাখতে হয়। Linux-এ এর আকারের সাথে tcp_max_syn_backlog জড়িত (আমাদের চালানোর পরিবেশে মান 128 দেখা গেছে; যন্ত্রভেদে আলাদা)।
• Accept queue: Handshake শেষ, ESTABLISHED, কিন্তু প্রোগ্রাম এখনো accept() দিয়ে তোলেনি। আকার listen()-এর backlog, যা net.core.somaxconn দিয়ে সীমিত (নতুন Linux-এ ডিফল্ট 4096, পুরোনোগুলোতে 128).

SYN flood — রিসেপশনের খাতা ভরিয়ে দেওয়া

এখন ভাবুন, কেউ হাজার হাজার ভুয়া নামে দর্শনার্থী পাঠাল, যারা নাম লিখিয়েই চলে যায়, কখনো পরিচয়পত্র দেখায় না। খাতা ভরে যাবে, আসল দর্শনার্থী আর নাম লেখাতে পারবেন না। এটাই SYN flood: আক্রমণকারী প্রচুর SYN পাঠায়, প্রায়ই নকল উৎস ঠিকানা দিয়ে, তাই SYN+ACK এমন ঠিকানায় যায় যারা কখনো ACK দেবে না। প্রতিটি অর্ধেক-সংযোগ server-এর SYN queue-তে জায়গা দখল করে কয়েক দফা পুনঃপ্রেরণ পর্যন্ত বসে থাকে। এটি একটি denial-of-service আক্রমণ — server-এর CPU বা bandwidth নয়, ফুরায় তার অর্ধেক-সংযোগের খাতা। এখানে শুধু ধারণা আর প্রতিরক্ষা; বড় আকারের DDoS-এর প্রতিরক্ষা পর্ব ৫০-এ।

প্রতিরক্ষার কয়েকটি স্তর আছে: ISP-র ingress filtering নকল উৎস ঠিকানা কমায়; বড় SYN queue আর কম পুনঃপ্রেরণ দিয়ে প্রতিটি অর্ধেক-সংযোগের আয়ু কমানো যায়; বড় সেবাগুলো scrubbing center বা CDN-এর পেছনে থাকে। কিন্তু সবচেয়ে চমৎকার কৌশলটি server-এর নিজের ভেতরে — SYN cookie, যা ১৯৯৬ সালে Daniel J. Bernstein আর Eric Schenk-এর কাজ থেকে এসেছে।

SYN cookie — অবস্থা না রেখে ISN-এ লুকানো তথ্য

মূল চিন্তা: queue ভরে গেলে server SYN-এর জন্য কোনো সারিই রাখবে না। বরং দরকারি তথ্যগুলো ঢুকিয়ে দেবে নিজের ISN-এর ৩২ bit-এ — যা SYN+ACK-এ client-এর কাছে যায় আর client-কে ACK-এ ack = ISN + 1 হিসেবে ফেরত দিতেই হয়। Bernstein-এর মূল নকশা (ধারণাগতভাবে):

ISN(server) = [ t : 5 bit ][ m : 3 bit ][ s : 24 bit ]
 t = ধীরে বাড়া একটি সময়-গণক (মোটামুটি প্রতি ৬৪ সেকেন্ডে ১), mod 32
 m = client-এর MSS-এর কাছাকাছি একটি মানক মানের সূচক (৮টির মধ্যে একটি)
 s = গোপন চাবি + client IP, client port, server IP, server port + t -এর hash (২৪ bit)

নিচের উদাহরণে client 198.51.100.7:52000 থেকে server 203.0.113.10:443-এ আসছে, client-এর ISN ৭০০০, আর hash-এর মানটি বোঝানোর জন্য বানানো একটি সংখ্যা।

দাম কী? মাত্র ৩২ bit-এ সব তথ্য আঁটে না। মূল নকশায় MSS শুধু ৮টি মানের একটিতে নামিয়ে আনা যায়, আর window scale, SACK-এর মতো option হারিয়ে যায় — ফলে cookie দিয়ে তৈরি সংযোগ কিছুটা দুর্বল চলে। Linux-এর আসল সূত্র এই মূল নকশা থেকে কিছুটা আলাদা, আর timestamp চালু থাকলে কিছু option-এর তথ্য timestamp-এর কয়েকটি bit-এ লুকিয়ে বাঁচানো হয়। এজন্য Linux ডিফল্টে (tcp_syncookies = 1) cookie ব্যবহার করে কেবল SYN queue ভরে গেলে, সবসময় নয়।

৮ · Keepalive, TCP Fast Open আর handshake-এর খরচ

TCP keepalive — নীরব সংযোগ বেঁচে আছে তো?

TCP নিজে থেকে নীরব সংযোগে কিছু পাঠায় না। দুই পক্ষ এক ঘণ্টা চুপ থাকলে সংযোগ এক ঘণ্টা ESTABLISHED-ই থাকে — এমনকি অন্য পক্ষ বিদ্যুৎ চলে গিয়ে বন্ধ হয়ে গেলেও। TCP keepalive এর সমাধান: socket-এ SO_KEEPALIVE চালু থাকলে, নির্দিষ্ট সময় নীরবতার পর kernel একটি ছোট probe (ডেটাহীন ACK) পাঠায়; উত্তর না এলে কয়েকবার চেষ্টা করে সংযোগ বাতিল ঘোষণা করে। Linux-এর ডিফল্ট মান অনেক বড়: ৭২০০ সেকেন্ড (২ ঘণ্টা) নীরবতা, তারপর ৭৫ সেকেন্ড পরপর ৯টি probe. তাই বাস্তবে প্রোগ্রাম প্রতি socket-এ ছোট মান বসায় (TCP_KEEPIDLE ইত্যাদি), অথবা application নিজের “ping” বার্তা পাঠায় (যেমন HTTP/2 বা WebSocket-এর ping). আরেকটি বাস্তব কারণ: পথের NAT বা firewall নীরব সংযোগের conntrack সারি কিছুক্ষণ পরে মুছে দেয় (পর্ব ১৯) — তাই অনেক মোবাইল অ্যাপ কয়েক মিনিট পরপর ছোট keepalive পাঠায়।

TCP Fast Open — SYN-এর সাথেই ডেটা

Handshake-এর এক RTT অপেক্ষা ছোট অনুরোধের জন্য বড় খরচ। TCP Fast Open (RFC 7413, ২০১৪, experimental) প্রথম সংযোগে server থেকে একটি cookie নিয়ে রাখে; পরের বার client SYN-এর সাথেই ডেটা আর cookie পাঠায়, আর server cookie যাচাই করে handshake শেষ হওয়ার আগেই ডেটা প্রোগ্রামের হাতে দেয়। এতে পুনঃসংযোগে এক RTT বাঁচে। কিন্তু দুটি সমস্যা: SYN-এর ডেটা পথে নকল হয়ে দুবার পৌঁছাতে পারে, তাই শুধু বারবার চালালেও ক্ষতি নেই এমন (idempotent) অনুরোধে নিরাপদ; আর পথের অনেক middlebox অপরিচিত option বা ডেটাওয়ালা SYN ফেলে দেয়। Linux-এ client দিকে এটি চালু করা যায় (tcp_fastopen), কিন্তু browser আর বড় নেটওয়ার্কে এর ব্যবহার শেষ পর্যন্ত সীমিতই থেকেছে বলে জানা যায়। একই লক্ষ্য QUIC-এর 0-RTT অনেক বেশি সফলভাবে পূরণ করছে (পর্ব ৩৩)।

মোট খরচের হিসাব

এই সারণির পরে উত্তরের জন্য আরও একটি RTT লাগে, সবার ক্ষেত্রেই। সংখ্যাগুলো দেখায় কেন persistent connection, CDN আর QUIC এত গুরুত্বপূর্ণ: প্রতিটি RTT বাঁচানো ব্যবহারকারীর চোখে পেজ দ্রুত খোলা।

৯ · AI-এর যুগে TCP সংযোগ নিয়ে সমস্যা খোঁজা

“আমার সার্ভারে হাজার হাজার TIME-WAIT, কী করব?” — AI-কে জিজ্ঞেস করলে কয়েক সেকেন্ডে একগাদা sysctl পাবেন। কিন্তু AI আপনার যন্ত্রের kernel version, কে আগে বন্ধ করে, বা সমস্যাটা আসলেই TIME-WAIT কি না — কিছুই দেখতে পায় না। চেনা ভুলগুলো:

AI-এর TCP পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• ss -tan দিয়ে নিজে দেখেছি কোন state-এ কতগুলো সংযোগ, আর কোন প্রান্তে (local না peer port) জমছে
• CLOSE-WAIT বেশি হলে আগে নিজের কোডে close() না-ডাকার বাগ খুঁজেছি — sysctl দিয়ে বাগ ঢাকিনি
• প্রস্তাবিত sysctl আমার kernel-এ আছে কি না আর তার মানে কী, kernel-এর নথি বা man 7 tcp থেকে মিলিয়েছি
• seq/ack-এর কোনো হিসাব হাতে বা হিসাবযন্ত্রে আবার করেছি (SYN আর FIN একটি করে নম্বর)
• পরিবর্তন আগে একটি পরীক্ষাগার যন্ত্র বা VM-এ চালিয়ে, প্রয়োজনে নিজের নেটওয়ার্কে tcpdump দিয়ে আসল segment দেখে, তারপর production-এ নিয়েছি