Como funcionam o TCP handshake, o teardown e o flow control?

Question

IT Interview Practice · Accepted Answer

O TCP estabelece uma conexão com um **3-way handshake**, a fecha com um **4-way teardown**, e mantém os dados fluindo com segurança com **flow control** e **congestion control**. O handshake sincroniza o sequence number inicial de cada lado para que ambos possam rastrear e confirmar (ACK) cada byte:

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

O **flow control** impede que um remetente rápido sobrecarregue um receptor lento. Cada lado anuncia uma **receive window** — quantos bytes ele tem atualmente espaço de buffer — em cada ACK. O remetente pode ter no máximo uma window de dados não confirmados em trânsito (uma **sliding window**); se a window do receptor encolhe até zero, o remetente pausa. Este é um limite *dirigido pelo receptor*.

O **congestion control** é diferente: ele protege a *rede* (não o receptor) de sobrecarga. O TCP mantém uma **congestion window** que cresce em caso de sucesso e encolhe em caso de perda de pacotes (a perda é lida como um sinal de congestão). Algoritmos como slow start e CUBIC sobem gradualmente, depois recuam quando surge perda:

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

A quantidade real que o TCP envia é `min(receive window, congestion window)` — limitada tanto pelo receptor quanto pela rede.

## Por que isso importa

Esta pergunta separa os candidatos que memorizaram "SYN-SYN/ACK-ACK" daqueles que entendem *por que* o TCP é confiável. O handshake, os sequence numbers e os ACKs são o mecanismo por trás da ordenação e da retransmissão; flow control e congestion control são o motivo pelo qual uma única conexão não pode afogar um cliente lento nem colapsar um link compartilhado. Isso explica diretamente comportamentos do mundo real — a latência de setup da conexão (uma ida e volta antes de qualquer dado), por que a throughput sobe gradualmente em vez de começar na velocidade máxima, e por que a perda num link de longa distância derruba a performance — tudo sobre o qual você raciocina ao tunar ou debugar sistemas em rede.

Por que isso importa

Perguntas relacionadas