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 করতে পারে:

```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** ঘোষণা করে — বর্তমানে তার কত byte-এর জন্য buffer জায়গা আছে। প্রেরক সর্বোচ্চ এক window পরিমাণ acknowledge-না-হওয়া ডেটা পথে রাখতে পারে (একটি **sliding window**); গ্রহীতার window শূন্যে নেমে গেলে প্রেরক থেমে যায়। এটি একটি *গ্রহীতা-চালিত* সীমা।

**Congestion control** ভিন্ন: এটি *নেটওয়ার্ক*-কে (গ্রহীতাকে নয়) অতিরিক্ত ভার থেকে রক্ষা করে। TCP একটি **congestion window** রক্ষণাবেক্ষণ করে যা সাফল্যে বাড়ে এবং packet loss-এ কমে (loss-কে congestion সংকেত হিসেবে পড়া হয়)। slow start ও CUBIC-এর মতো অ্যালগরিদম ধীরে ধীরে বাড়ায়, তারপর loss দেখা দিলে পিছিয়ে যায়:

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

TCP আসলে যে পরিমাণ পাঠায় তা হলো `min(receive window, congestion window)` — গ্রহীতা ও নেটওয়ার্ক উভয় দ্বারা সীমাবদ্ধ।

## এটি কেন গুরুত্বপূর্ণ

এই প্রশ্নটি সেই প্রার্থীদের আলাদা করে যারা "SYN-SYN/ACK-ACK" মুখস্থ করেছে তাদের থেকে যারা বোঝে TCP *কেন* নির্ভরযোগ্য। Handshake, sequence number, এবং ACK হলো ক্রম ও retransmission-এর পেছনের প্রক্রিয়া; flow ও congestion control-ই কারণ যে একটিমাত্র কানেকশন একটি ধীর client-কে ডুবিয়ে দিতে বা একটি শেয়ার্ড link ধসিয়ে দিতে পারে না। এটি সরাসরি বাস্তব-জগতের আচরণ ব্যাখ্যা করে — কানেকশন সেটআপ latency (যেকোনো ডেটার আগে একটি round trip), throughput কেন পূর্ণ গতিতে শুরু না হয়ে ধীরে ধীরে বাড়ে, এবং কেন দূরপাল্লার link-এ loss কর্মক্ষমতা ধসিয়ে দেয় — এসব কিছুই আপনি নেটওয়ার্কড সিস্টেম টিউন বা debug করার সময় যুক্তি করেন।

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন