როგორ მუშაობს 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-ს, რომ ორივემ თითოეული ბაიტი აკონტროლოს და დაადასტუროს (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-ს** — ამჟამად რამდენი ბაიტის ბუფერული ადგილი აქვს. გამგზავნს შეიძლება ჰქონდეს არაუმეტეს ერთი ფანჯარა დაუდასტურებელი მონაცემისა გზაში (**sliding window**); თუ მიმღების ფანჯარა ნულამდე იკუმშება, გამგზავნი ჩერდება. ეს *მიმღების მიერ მართული* ლიმიტია.

**Congestion control** განსხვავებულია: ის იცავს *ქსელს* (და არა მიმღებს) გადატვირთვისგან. TCP ინახავს **congestion window-ს**, რომელიც წარმატებაზე იზრდება და პაკეტის დაკარგვაზე იკუმშება (დაკარგვა გადატვირთვის სიგნალად იკითხება). ისეთი ალგორითმები, როგორიც 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 number-ები და ACK-ები არის მექანიზმი რიგისა და retransmission-ის უკან; flow და congestion control არის ის, თუ რატომ არ შეუძლია ერთ კავშირს ნელი კლიენტის დახრჩობა ან გაზიარებული არხის ჩამონგრევა. ეს პირდაპირ ხსნის რეალურ ქცევას — კავშირის დამყარების latency-ს (ერთი round trip სანამ რაიმე მონაცემი იქნება), რატომ იზრდება throughput თანდათან და არ იწყება სრული სიჩქარით და რატომ ანგრევს დაკარგვა შორ მანძილზე წარმადობას — ყველაფერს, რაზეც მსჯელობთ, როცა ქსელურ სისტემებს გამართავთ ან debug-ს უკეთებთ.

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები