TCP handshake، teardown اور flow control کیسے کام کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

TCP ایک کنکشن **3-way handshake** سے قائم کرتا ہے، اسے **4-way teardown** سے بند کرتا ہے، اور **flow control** اور **congestion control** کے ذریعے ڈیٹا کو محفوظ طریقے سے بہتا رکھتا ہے۔ Handshake ہر فریق کے ابتدائی sequence number کو ہم آہنگ کرتا ہے تاکہ دونوں ہر byte کو ٹریک اور acknowledge (ACK) کر سکیں:

```text
   3-WAY HANDSHAKE (open)                4-WAY TEARDOWN (close)
 Client            Server              Client            Server
   │──── SYN ───────▶│                   │──── FIN ───────▶│
   │◀── SYN, ACK ────│                   │◀──── ACK ───────│
   │──── ACK ───────▶│                   │◀──── FIN ───────│
   │   connected     │                   │──── ACK ───────▶│
```

**Flow control** ایک تیز بھیجنے والے کو ایک سست وصول کنندہ پر چھا جانے سے روکتا ہے۔ ہر فریق ہر ACK میں ایک **receive window** کا اعلان کرتا ہے — یعنی اس کے پاس اس وقت کتنے bytes کے لیے buffer کی جگہ ہے۔ بھیجنے والا زیادہ سے زیادہ ایک window جتنا غیر-ACK شدہ ڈیٹا راستے میں رکھ سکتا ہے (ایک **sliding window**)؛ اگر وصول کنندہ کا window سکڑ کر صفر ہو جائے، تو بھیجنے والا رُک جاتا ہے۔ یہ ایک *وصول کنندہ کے زیرِ کنٹرول* حد ہے۔

**Congestion control** مختلف ہے: یہ *نیٹ ورک* کو (وصول کنندہ کو نہیں) اوورلوڈ سے بچاتا ہے۔ TCP ایک **congestion window** برقرار رکھتا ہے جو کامیابی پر بڑھتا ہے اور packet کے ضیاع پر سکڑتا ہے (ضیاع کو congestion کے اشارے کے طور پر پڑھا جاتا ہے)۔ slow start اور CUBIC جیسے الگورتھم بتدریج بڑھتے ہیں، پھر جب ضیاع نظر آتا ہے تو پیچھے ہٹتے ہیں:

```text
cwnd
 │        /\        /\
 │       /  \      /  ...   loss → halve/back off, then probe up again
 │      /    \    /
 │  ___/      \__/
 └───────────────────────▶ time
```

TCP جتنا ڈیٹا حقیقتاً بھیجتا ہے وہ `min(receive window, congestion window)` ہے — یعنی وصول کنندہ اور نیٹ ورک دونوں سے محدود۔

## یہ کیوں اہم ہے

یہ سوال اُن امیدواروں کو الگ کرتا ہے جنہوں نے "SYN-SYN/ACK-ACK" رٹ لیا ہے اُن سے جو سمجھتے ہیں کہ TCP *کیوں* قابلِ اعتماد ہے۔ Handshake، sequence numbers اور ACKs ترتیب اور retransmission کے پیچھے کا طریقہ کار ہیں؛ flow اور congestion control وہ وجہ ہیں کہ ایک اکیلا کنکشن نہ کسی سست client کو ڈبو سکتا ہے اور نہ کسی مشترکہ link کو گرا سکتا ہے۔ یہ براہِ راست حقیقی دنیا کے رویّے کی وضاحت کرتا ہے — کنکشن قائم کرنے کی latency (کسی بھی ڈیٹا سے پہلے ایک round trip)، کیوں throughput پوری رفتار سے شروع ہونے کے بجائے بتدریج بڑھتا ہے، اور کیوں کسی طویل فاصلے والے link پر ضیاع کارکردگی کو گرا دیتا ہے — یہ سب وہ چیزیں ہیں جن پر آپ نیٹ ورک شدہ نظاموں کو ٹیون یا debug کرتے وقت غور کرتے ہیں۔

یہ کیوں اہم ہے

متعلقہ سوالات