Hogyan működik a TCP handshake, a teardown és a flow control?

Question

IT Interview Practice · Accepted Answer

A TCP egy **3-way handshake**-kel épít kapcsolatot, egy **4-way teardown**-nal zárja, és **flow control**-lal meg **congestion control**-lal tartja biztonságosan áramlásban az adatot. A handshake szinkronizálja mindkét oldal kezdő sequence number-ét, hogy mindkettő nyomon követhessen és nyugtázhasson (acknowledge) minden byte-ot:

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

A **flow control** megakadályozza, hogy egy gyors küldő elárassza a lassú fogadót. Mindkét fél minden ACK-ben hirdet egy **receive window**-t — hány byte-nyi buffer-helye van éppen. A küldőnek legfeljebb egy ablaknyi nem nyugtázott adata lehet úton (egy **sliding window**); ha a fogadó ablaka nullára zsugorodik, a küldő megáll. Ez egy *fogadó által vezérelt* korlát.

A **congestion control** más: a *hálózatot* (nem a fogadót) védi a túlterheléstől. A TCP fenntart egy **congestion window**-t, amely siker esetén nő, csomagvesztés esetén zsugorodik (a vesztés torlódási jelként értelmeződik). Az olyan algoritmusok, mint a slow start és a CUBIC, fokozatosan növelik, majd visszavesznek, amikor vesztés jelenik meg:

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

A ténylegesen küldött mennyiség `min(receive window, congestion window)` — mind a fogadó, mind a hálózat korlátozza.

## Miért fontos

Ez a kérdés elválasztja azokat a jelölteket, akik bemagolták a "SYN-SYN/ACK-ACK"-et, azoktól, akik értik, *miért* megbízható a TCP. A handshake, a sequence number-ök és az ACK-ek a sorrendezés és a retransmission mögötti mechanizmus; a flow és a congestion control az oka annak, hogy egyetlen kapcsolat nem tud megfojtani egy lassú klienst vagy összeomlasztani egy megosztott linket. Ez közvetlenül megmagyaráz valós viselkedést — a kapcsolat felépítésének latency-jét (egy round trip bármilyen adat előtt), hogy a throughput miért kúszik felfelé, ahelyett hogy azonnal teljes sebességen indulna, és hogy egy nagy távolságú linken a vesztés miért veri le a teljesítményt —, amikről mind gondolkodsz, amikor hálózati rendszereket hangolsz vagy debugolsz.

Miért fontos

Kapcsolódó kérdések