TCP handshake, teardown और flow control कैसे काम करते हैं?

Question

IT Interview Practice · Accepted Answer

TCP एक **3-way handshake** से connection स्थापित करता है, एक **4-way teardown** से उसे बंद करता है, और **flow control** तथा **congestion control** से data को सुरक्षित रूप से बहता रखता है। Handshake हर पक्ष के शुरुआती sequence number को synchronize करता है ताकि दोनों हर byte को track और 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** एक तेज़ sender को धीमे receiver पर हावी होने से रोकता है। हर पक्ष हर ACK में एक **receive window** की घोषणा करता है — उसके पास अभी कितने bytes के लिए buffer जगह है। Sender के पास बिना ACK वाले data की अधिकतम एक window ही रास्ते में हो सकती है (एक **sliding window**); अगर receiver की window शून्य पर सिकुड़ जाए, तो sender रुक जाता है। यह एक *receiver-चालित* सीमा है।

**Congestion control** अलग है: यह *network* को (receiver को नहीं) अधिभार से बचाता है। TCP एक **congestion window** बनाए रखता है जो सफलता पर बढ़ती है और packet loss पर सिकुड़ती है (loss को congestion संकेत के रूप में पढ़ा जाता है)। slow start और CUBIC जैसे algorithms धीरे-धीरे बढ़ते हैं, फिर loss दिखने पर पीछे हटते हैं:

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

TCP असल में जितना भेजता है वह `min(receive window, congestion window)` है — receiver और network दोनों से सीमित।

## यह क्यों महत्वपूर्ण है

यह सवाल उन उम्मीदवारों को अलग करता है जिन्होंने "SYN-SYN/ACK-ACK" रटा है उनसे जो समझते हैं कि TCP *क्यों* विश्वसनीय है। Handshake, sequence numbers और ACKs क्रम तथा retransmission के पीछे की क्रियाविधि हैं; flow और congestion control ही कारण हैं कि एक अकेला connection किसी धीमे client को डुबा नहीं सकता या किसी साझा link को ढहा नहीं सकता। यह सीधे वास्तविक-दुनिया के व्यवहार को समझाता है — connection setup latency (किसी data से पहले एक round trip), throughput पूरी गति से शुरू होने के बजाय क्यों धीरे-धीरे बढ़ता है, और लंबी-दूरी की link पर loss प्रदर्शन को क्यों गिरा देता है — जिन सबके बारे में आप networked सिस्टमों को tune या debug करते समय तर्क करते हैं।

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न