Toda vez que você abre um site, faz login em um servidor ou transfere um arquivo via SSH, o TCP executa um ritual de três passos antes de qualquer dado de aplicação trafegar.
Esse ritual chama TCP 3-Way Handshake.
É um dos tópicos mais cobrados no CCNA. É também um dos mais mal entendidos, porque a maioria das explicações fica no superficial: "SYN, SYN-ACK, ACK, pronto". Isso não resolve questão de prova. Não resolve troubleshooting real. E não explica por que o TCP funciona dessa forma.
Neste artigo, vou mostrar o que acontece em cada passo, quais números de sequência estão envolvidos, quais estados de socket cada lado assume e o que a Cisco cobra sobre isso.
Por que o TCP precisa de handshake
O TCP é um protocolo orientado à conexão. Antes de transmitir dados, os dois lados precisam concordar que estão prontos para se comunicar e sincronizar seus números de sequência.
Isso é diferente do UDP, que não faz handshake nenhum. O UDP envia e torce para chegar. O TCP garante entrega, ordem e retransmissão em caso de perda.
Daí a necessidade do handshake: sem ele, um lado poderia começar a enviar dados sem saber se o outro está ouvindo, qual é a janela de recepção disponível ou qual número de sequência usar para controlar o fluxo.
Na prática: o handshake sincroniza o ISN de cada lado e confirma que o canal de comunicação funciona nos dois sentidos.
O que é ISN
ISN significa Initial Sequence Number. É o número de sequência inicial escolhido por cada lado no início de uma conexão.
O ISN não começa em zero. É um número gerado de forma pseudo-aleatória pelo sistema operacional para evitar que pacotes de conexões anteriores sejam confundidos com pacotes da conexão atual.
Cada lado escolhe seu próprio ISN. O handshake serve para que cada lado comunique seu ISN ao outro e confirme que recebeu o do parceiro.
Os três passos
Passo 1 — SYN
O cliente inicia a conexão enviando um segmento com a flag SYN ativada.
Cliente → Servidor
Flags: SYN=1, ACK=0
SEQ = 1000 (ISN do cliente)
O cliente está dizendo: "Quero me conectar. Meu número de sequência inicial é 1000."
Estado do cliente: SYN_SENT
Estado do servidor: LISTEN
O segmento SYN não carrega dados de aplicação, mas consome um número de sequência. Fato importante para a prova: o SYN conta como um byte fictício no controle de sequência.
Passo 2 — SYN-ACK
O servidor responde com um segmento que tem as duas flags ativadas: SYN e ACK.
Servidor → Cliente
Flags: SYN=1, ACK=1
SEQ = 4000 (ISN do servidor)
ACK = 1001 (SEQ do cliente + 1)
O servidor está dizendo duas coisas ao mesmo tempo: "Recebi seu SYN. Meu número de sequência inicial é 4000. Agora me confirma."
O ACK=1001 significa que o servidor recebeu tudo até o byte 1000 e espera receber o byte 1001 a seguir.
Estado do cliente: SYN_SENT
Estado do servidor: SYN_RECEIVED
Passo 3 — ACK
O cliente confirma o SYN do servidor.
Cliente → Servidor
Flags: SYN=0, ACK=1
SEQ = 1001
ACK = 4001 (SEQ do servidor + 1)
O cliente está dizendo: "Recebi seu SYN. Confirmo tudo até o byte 4000. Estamos conectados."
Estado do cliente: ESTABLISHED
Estado do servidor: ESTABLISHED
A partir deste momento, os dois lados estão sincronizados e dados de aplicação podem fluir.
Visualização interativa
Estados de socket que a prova cobra
| Estado | Quem assume | Quando |
|---|---|---|
| LISTEN | Servidor | Aguardando conexões na porta |
| SYN_SENT | Cliente | Após enviar o SYN |
| SYN_RECEIVED | Servidor | Após receber o SYN e enviar SYN-ACK |
| ESTABLISHED | Ambos | Após o terceiro passo |
| TIME_WAIT | Quem iniciou o fechamento | Após o 4-Way Termination |
O estado TIME_WAIT não faz parte do handshake de abertura, mas cai na prova junto com esse tema. Dura 2 × MSL (Maximum Segment Lifetime), que o sistema operacional usa para garantir que pacotes atrasados da conexão anterior não contaminem uma nova conexão no mesmo par de portas.
Flags TCP que você precisa conhecer
| Flag | Função |
|---|---|
| SYN | Sincroniza números de sequência — usado na abertura |
| ACK | Confirma recebimento de dados |
| FIN | Encerra a conexão graciosamente |
| RST | Reseta a conexão abruptamente |
| PSH | Solicita entrega imediata à aplicação |
| URG | Dados urgentes — raramente usado |
Na prova CCNA, SYN, ACK, FIN e RST são as flags que aparecem com mais frequência. Questões de troubleshooting com Wireshark pedem que você identifique o estado da conexão pela combinação de flags ativas.
O que aparece no Wireshark
Se você capturar um handshake TCP com Wireshark, vai ver exatamente isso:
Frame 1: SYN
TCP: Flags: 0x002 (SYN)
Seq: 0 (relative), Raw: 1000
Frame 2: SYN-ACK
TCP: Flags: 0x012 (SYN, ACK)
Seq: 0 (relative), Raw: 4000
Ack: 1 (relative), Raw: 1001
Frame 3: ACK
TCP: Flags: 0x010 (ACK)
Seq: 1 (relative), Raw: 1001
Ack: 1 (relative), Raw: 4001
O Wireshark mostra números de sequência relativos por padrão (começando em 0) para facilitar a leitura. Os números absolutos estão disponíveis nas preferências. A prova CCNA pode usar qualquer um dos dois formatos.
Por que três passos e não dois
Dois passos não são suficientes porque a comunicação TCP é full-duplex. Cada direção precisa ser estabelecida e confirmada independentemente.
Com dois passos, o cliente saberia que o servidor recebeu o SYN, mas o servidor não teria confirmação de que o cliente recebeu o SYN-ACK. A terceira mensagem fecha esse gap: confirma que o canal servidor para cliente está funcionando.
Daí o nome three-way: três mensagens para estabelecer dois canais de comunicação independentes.
O que a prova CCNA cobra
As questões sobre TCP handshake no CCNA geralmente testam:
Identificação da sequência correta. Questões de múltipla escolha ou arrastar e soltar onde você ordena SYN, SYN-ACK e ACK.
Cálculo de ACK. Dado o SEQ de um lado, qual é o ACK esperado do outro? Regra: ACK = SEQ recebido + 1.
Estados de socket. Qual estado o servidor assume após receber o SYN? Qual estado indica conexão estabelecida?
Diferença entre TCP e UDP. Por que o TCP faz handshake e o UDP não? Qual o custo e qual o benefício.
Flags ativas em cada passo. No passo 2, quais flags estão ativas? SYN=1 e ACK=1.
Troubleshooting: quando o handshake falha
SYN enviado, sem resposta. O servidor não está ouvindo na porta, a porta está bloqueada no firewall ou o host de destino está inacessível. Verifique com telnet [IP] [porta] ou nc -zv [IP] [porta].
SYN-ACK recebido, mas a conexão não avança. O cliente não consegue entregar o ACK final. Pode ser problema de roteamento assimétrico ou firewall stateful descartando o retorno.
RST em resposta ao SYN. A porta está fechada no host de destino. O serviço não está rodando ou está ouvindo em outra porta.
Handshake completo, mas dados não fluem. O problema está na camada de aplicação, não no TCP. O canal está estabelecido, algo acima está falhando.
▌ Se TCP, UDP e os estados de conexão aparecem no seu diagnóstico CCNA como pontos fracos, o PacketPass identifica exatamente onde estão as lacunas. Diagnóstico gratuito, resultado por domínio, em 15 minutos.
Este artigo cobre o TCP 3-Way Handshake conforme o blueprint CCNA 200-301 atual, domínio Network Fundamentals.