Cum funcționează TCP handshake, teardown și flow control?

Question

IT Interview Practice · Accepted Answer

TCP stabilește o conexiune cu un **3-way handshake**, o închide cu un **4-way teardown** și menține datele curgând în siguranță cu **flow control** și **congestion control**. Handshake-ul sincronizează numărul de secvență de start al fiecărei părți, astfel încât amândouă pot urmări și confirma (ACK) fiecare byte:

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

**Flow control** oprește un expeditor rapid de la a copleși un receptor lent. Fiecare parte anunță o **receive window** — câți bytes are momentan spațiu de buffer — în fiecare ACK. Expeditorul poate avea cel mult o fereastră de date neconfirmate în tranzit (o **sliding window**); dacă fereastra receptorului scade la zero, expeditorul se oprește. Aceasta este o limită *condusă de receptor*.

**Congestion control** este diferit: protejează *rețeaua* (nu receptorul) de suprasolicitare. TCP menține o **congestion window** care crește la succes și se micșorează la pierderea de pachete (pierderea este citită ca un semnal de congestie). Algoritmi precum slow start și CUBIC urcă treptat, apoi se retrag când apare pierderea:

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

Cantitatea reală pe care o trimite TCP este `min(receive window, congestion window)` — mărginită atât de receptor, cât și de rețea.

## De ce contează

Această întrebare separă candidații care au memorat „SYN-SYN/ACK-ACK” de cei care înțeleg *de ce* TCP este fiabil. Handshake-ul, numerele de secvență și ACK-urile sunt mecanismul din spatele ordonării și retransmisiei; flow control-ul și congestion control-ul sunt motivul pentru care o singură conexiune nu poate îneca un client lent sau prăbuși o legătură partajată. Aceasta explică direct comportamentul din lumea reală — latența de stabilire a conexiunii (un round trip înainte de orice date), de ce throughput-ul urcă treptat în loc să pornească la viteză maximă și de ce pierderea pe o legătură la distanță mare prăbușește performanța — toate lucruri despre care raționezi când reglezi sau depanezi sisteme de rețea.

De ce contează

Întrebări conexe