Hvordan fungerer TCP-handshake, teardown og flow control?

Question

IT Interview Practice · Accepted Answer

TCP oppretter en tilkobling med et **3-way handshake**, lukker den med en **4-way teardown**, og holder dataflyten trygg med **flow control** og **congestion control**. Handshaket synkroniserer hver sides start-sekvensnummer slik at begge kan spore og bekrefte (ACK) hver 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** hindrer at en rask avsender oversvømmer en treg mottaker. Hver side annonserer et **receive window** — hvor mange byte den for øyeblikket har bufferplass til — i hver ACK. Avsenderen kan ha høyst ett vindu med ubekreftet data underveis (et **sliding window**); hvis mottakerens vindu krymper til null, stopper avsenderen. Dette er en grense *styrt av mottakeren*.

**Congestion control** er noe annet: den beskytter *nettverket* (ikke mottakeren) mot overbelastning. TCP holder et **congestion window** som vokser ved suksess og krymper ved pakketap (tap tolkes som et signal om overbelastning). Algoritmer som slow start og CUBIC øker gradvis, og trekker seg deretter tilbake når tap dukker opp:

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

Mengden TCP faktisk sender er `min(receive window, congestion window)` — begrenset av både mottakeren og nettverket.

## Hvorfor det er viktig

Dette spørsmålet skiller kandidater som pugget «SYN-SYN/ACK-ACK» fra dem som forstår *hvorfor* TCP er pålitelig. Handshaket, sekvensnumrene og ACK-ene er mekanismen bak rekkefølge og retransmisjon; flow control og congestion control er grunnen til at én enkelt tilkobling ikke kan drukne en treg klient eller kollapse en delt lenke. Dette forklarer direkte reell atferd — latency ved oppsett av tilkobling (én round trip før noen data), hvorfor throughput bygger seg opp gradvis i stedet for å starte på full fart, og hvorfor tap på en lang lenke ødelegger ytelsen — alt sammen noe du resonnerer om når du tuner eller feilsøker nettverkssystemer.

Hvorfor det er viktig

Relaterte spørsmål