Hvordan fungerer TCP-handshake, teardown og flow control?

Question

IT Interview Practice · Accepted Answer

TCP etablerer en forbindelse med et **3-way handshake**, lukker den med en **4-way teardown** og holder data flydende sikkert med **flow control** og **congestion control**. Handshaket synkroniserer hver sides start-sequence-number, så begge kan spore og bekræfte 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** forhindrer en hurtig afsender i at overvælde en langsom modtager. Hver side annoncerer et **receive window** — hvor mange bytes den aktuelt har bufferplads til — i hver ACK. Afsenderen må højst have ét vindue af ubekræftet data undervejs (et **sliding window**); hvis modtagerens vindue skrumper til nul, holder afsenderen pause. Dette er en *modtager-drevet* grænse.

**Congestion control** er anderledes: den beskytter *netværket* (ikke modtageren) mod overbelastning. TCP vedligeholder et **congestion window**, der vokser ved succes og skrumper ved pakketab (tab tolkes som et congestion-signal). Algoritmer som slow start og CUBIC ramper gradvist op og trækker sig så tilbage, når tab dukker op:

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

Den faktiske mængde, TCP sender, er `min(receive window, congestion window)` — begrænset af både modtageren og netværket.

## Hvorfor det betyder noget

Dette spørgsmål adskiller kandidater, der har lært "SYN-SYN/ACK-ACK" udenad, fra dem, der forstår *hvorfor* TCP er pålidelig. Handshaket, sequence numbers og ACKs er mekanismen bag rækkefølge og retransmission; flow og congestion control er grunden til, at en enkelt forbindelse ikke kan drukne en langsom klient eller kollapse et delt link. Dette forklarer direkte adfærd fra den virkelige verden — latency ved opsætning af forbindelse (ét round trip før nogen data), hvorfor throughput ramper op frem for at starte ved fuld hastighed, og hvorfor tab på et langdistance-link ødelægger performance — alt sammen noget, du ræsonnerer om, når du tuner eller fejlfinder netværkssystemer.

Hvorfor det betyder noget

Relaterede spørgsmål