Kako rade TCP handshake, teardown i flow control?

Question

IT Interview Practice · Accepted Answer

TCP uspostavlja vezu **3-way handshakeom**, zatvara je **4-way teardownom** i drži podatke da sigurno teku kroz **flow control** i **congestion control**. Handshake sinkronizira početni sequence number svake strane kako bi obje mogle pratiti i potvrditi (ACK) svaki bajt:

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

**Flow control** sprječava da brzi pošiljatelj preplavi sporog primatelja. Svaka strana oglašava **receive window** — koliko bajtova trenutno ima prostora u bufferu — u svakom ACK-u. Pošiljatelj smije imati najviše jedan prozor nepotvrđenih podataka u letu (**sliding window**); ako se prozor primatelja smanji na nulu, pošiljatelj pauzira. Ovo je ograničenje *koje vodi primatelj*.

**Congestion control** je nešto drugo: štiti *mrežu* (ne primatelja) od preopterećenja. TCP održava **congestion window** koji raste pri uspjehu i smanjuje se pri gubitku paketa (gubitak se tumači kao signal zagušenja). Algoritmi poput slow starta i CUBIC-a postupno se penju, pa se povlače kad se gubitak pojavi:

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

Stvarna količina koju TCP šalje je `min(receive window, congestion window)` — ograničena i primateljem i mrežom.

## Zašto je to važno

Ovo pitanje razdvaja kandidate koji su napamet naučili "SYN-SYN/ACK-ACK" od onih koji razumiju *zašto* je TCP pouzdan. Handshake, sequence numberi i ACK-ovi su mehanizam iza redoslijeda i retransmisije; flow i congestion control su razlog zašto jedna veza ne može utopiti sporog klijenta ili srušiti dijeljeni link. To izravno objašnjava ponašanje u stvarnom svijetu — latenciju uspostave veze (jedan obilazak prije ijednog podatka), zašto se throughput postupno penje umjesto da kreće punom brzinom i zašto gubitak na dalekom linku ruši performanse — a o svemu tome razmišljate kad podešavate ili otklanjate greške u mrežnim sustavima.

Zašto je to važno

Povezana pitanja