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 ਨੂੰ ਸਮਕਾਲੀ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਦੋਵੇਂ ਹਰ 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** ਇੱਕ ਤੇਜ਼ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਇੱਕ ਹੌਲੀ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਹਾਵੀ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਹਰ ਪਾਸਾ ਹਰ ACK ਵਿੱਚ ਇੱਕ **receive window** ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ — ਇਸ ਵੇਲੇ ਇਸ ਕੋਲ ਕਿੰਨੇ byte ਲਈ buffer ਜਗ੍ਹਾ ਹੈ। ਭੇਜਣ ਵਾਲੇ ਕੋਲ ਵੱਧ ਤੋਂ ਵੱਧ ਇੱਕ window ਜਿੰਨਾ un-acknowledged data ਰਾਹ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ (ਇੱਕ **sliding window**); ਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਦਾ window ਸੁੰਗੜ ਕੇ ਸਿਫ਼ਰ ਹੋ ਜਾਵੇ, ਤਾਂ ਭੇਜਣ ਵਾਲਾ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਹ ਇੱਕ *receiver-driven* ਸੀਮਾ ਹੈ।

**Congestion control** ਵੱਖਰਾ ਹੈ: ਇਹ *ਨੈੱਟਵਰਕ* ਨੂੰ (ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੂੰ ਨਹੀਂ) ਓਵਰਲੋਡ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। TCP ਇੱਕ **congestion window** ਰੱਖਦਾ ਹੈ ਜੋ ਸਫ਼ਲਤਾ 'ਤੇ ਵਧਦਾ ਹੈ ਅਤੇ packet loss 'ਤੇ ਸੁੰਗੜਦਾ ਹੈ (loss ਨੂੰ congestion ਦੇ ਸੰਕੇਤ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ)। slow start ਅਤੇ CUBIC ਵਰਗੇ algorithm ਹੌਲੀ-ਹੌਲੀ ਵਧਦੇ ਹਨ, ਫਿਰ 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 ਇਹ ਕਾਰਨ ਹਨ ਕਿ ਇੱਕ ਇਕੱਲਾ connection ਇੱਕ ਹੌਲੀ client ਨੂੰ ਡੁਬੋ ਨਹੀਂ ਸਕਦਾ ਜਾਂ ਇੱਕ ਸਾਂਝੇ link ਨੂੰ ਢਾਹ ਨਹੀਂ ਸਕਦਾ। ਇਹ ਸਿੱਧਾ ਅਸਲ-ਦੁਨੀਆ ਦੇ ਵਿਹਾਰ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ — connection setup latency (ਕਿਸੇ ਵੀ data ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ round trip), ਕਿਉਂ throughput ਪੂਰੀ ਗਤੀ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਬਜਾਏ ਹੌਲੀ-ਹੌਲੀ ਵਧਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ ਲੰਬੀ-ਦੂਰੀ ਵਾਲੇ link 'ਤੇ loss ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਡੋਬ ਦਿੰਦਾ ਹੈ — ਇਹ ਸਭ ਉਹ ਹੈ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ networked system ਨੂੰ tune ਜਾਂ debug ਕਰਦੇ ਵੇਲੇ ਸੋਚਦੇ ਹੋ।

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ