Seu navegador não oferece leitura em voz alta. Você pode ler o guia normalmente.
TCP e UDP são os dois protocolos de transporte que dividem a prova de Redes: um confiável, orientado a conexão; o outro simples, sem conexão. O que realmente faz diferença na hora da questão é conhecer o procedimento de abertura da conexão (o handshake em três vias), saber ler os campos do cabeçalho e calcular o número de confirmação. Este guia usa como fonte o RFC 9293, do IETF, que especifica o TCP, e o RFC 768, que especifica o UDP, ambos lidos em texto integral. Não há lei sobre o tema; a referência é a documentação aberta.
Onde o transporte se encaixa
A camada de transporte do modelo TCP/IP recebe dados da aplicação e entrega ao destino certo usando portas (campos de 16 bits no cabeçalho, tanto de origem quanto de destino). Veja a visão geral em OSI e TCP/IP. A unidade de dados do TCP é o segmento; a do UDP é o datagrama.
UDP em poucas linhas
O RFC 768 define o UDP como um protocolo de datagramas com “o mínimo de mecanismo de protocolo”. Ele é orientado a transação e a entrega e a proteção contra duplicação não são garantidas. O cabeçalho tem apenas quatro campos de 16 bits: porta de origem, porta de destino, comprimento e soma de verificação (checksum). O campo de comprimento conta o cabeçalho e os dados, então o valor mínimo é 8 octetos. O próprio RFC recomenda que aplicações que precisem de entrega ordenada e confiável de fluxos de dados usem o TCP.
TCP: o que ele oferece
O TCP é orientado a conexão e entrega um fluxo de octetos de forma ordenada e confiável, com controle de fluxo. O cabeçalho inclui porta de origem e de destino (16 bits cada), número de sequência (32 bits), número de confirmação (32 bits), janela (16 bits), soma de verificação (16 bits) e as flags de controle. As flags atualmente atribuídas, segundo o RFC 9293, são CWR, ECE, URG, ACK, PSH, RST, SYN e FIN.
Flags mais cobradas
| Flag | Significado no RFC |
|---|---|
| SYN | Sincronizar números de sequência (abertura) |
| ACK | O campo de confirmação é significativo |
| FIN | Não há mais dados do remetente (encerramento) |
| RST | Reiniciar (derrubar) a conexão |
| PSH | Função de empurrar dados (push) |
| URG | O ponteiro de urgência é significativo |
O handshake em três vias
O RFC 9293 chama de “three-way handshake” o procedimento normal para estabelecer conexão. O exemplo a seguir segue o esquema da própria especificação.
- A envia SYN com número de sequência 100 (o número inicial de sequência, ISN, de A). A passa ao estado SYN-SENT.
- B responde SYN+ACK com sequência 300 e confirmação 101. O 101 indica que B espera ouvir a partir de 101, pois o SYN de A ocupou o número 100.
- A responde ACK com sequência 101 e confirmação 301. Agora os dois estão no estado ESTABLISHED, e A pode enviar dados.
A regra para memorizar: o SYN consome um número de sequência, então a confirmação é sempre o valor do SYN recebido mais 1. Já o ACK puro não ocupa número de sequência; por isso, no exemplo do RFC, o segmento de dados que A envia em seguida repete a sequência 101.
Exemplo de cálculo
Se o primeiro SYN de A tivesse sequência 5000, o SYN+ACK de B traria confirmação 5001. Se B usasse sequência 800 no seu SYN, o ACK de A traria confirmação 801. Se A então enviasse 10 octetos de dados, com sequência 5001, B confirmaria com número 5011, o próximo octeto esperado.
A confirmação do TCP é “cumulativa” no sentido de indicar o próximo número de sequência que o receptor espera.
Por que três vias e não duas
O RFC explica que o principal motivo do handshake em três vias é evitar que segmentos antigos e duplicados de pedidos de conexão causem confusão. A terceira mensagem permite a cada lado verificar que o número inicial do outro é atual. Também reduz a possibilidade de conexões falsas.
Encerramento da conexão
O fechamento é feito com segmentos FIN. O RFC explica que o CLOSE é tratado de modo simplex: quem fecha informa que não tem mais dados a enviar, mas pode continuar a receber até que o par também feche. Por isso o encerramento costuma envolver quatro segmentos (FIN de um lado, ACK, FIN do outro, ACK), e não três. O lado que inicia passa pelos estados FIN-WAIT-1 e FIN-WAIT-2 e, ao final, por TIME-WAIT, em que espera tempo suficiente para ter certeza de que o par recebeu a confirmação.
Comparação direta
| Aspecto | TCP | UDP |
|---|---|---|
| Conexão | Orientado a conexão (handshake) | Sem conexão |
| Entrega | Ordenada e confiável | Não garantida |
| Duplicação | Controlada | Sem proteção |
| Cabeçalho | Maior, com sequência, confirmação, janela e flags | Quatro campos de 16 bits |
| Unidade de dados | Segmento | Datagrama |
| Uso típico | Transferência confiável de dados | Aplicações em que a simplicidade e a latência pesam mais |
Para aplicações que toleram perda de alguns dados e valorizam baixo atraso, o UDP costuma ser escolhido. Protocolos como o DNS usam consultas curtas, e o guia DNS, DHCP e NAT mostra o contexto.
Pegadinhas de prova
- Dizer que o UDP faz handshake. Não faz.
- Dizer que o UDP garante ordem de entrega. O RFC diz que a entrega não é garantida.
- Esquecer que o SYN ocupa um número de sequência.
- Achar que o ACK puro consome número de sequência.
- Confundir a flag RST (derrubar) com FIN (encerramento ordenado).
- Atribuir ao TCP a camada de rede: ele é de transporte.
Roteiro de estudo
- Desenhe o handshake com números e refaça os cálculos.
- Memorize as flags e o campo de 16 bits das portas.
- Compare o cabeçalho de TCP e UDP.
- Revise os estados ESTABLISHED, FIN-WAIT e TIME-WAIT.
Próximos passos
Leia redes e internet, HTTP, métodos e status e endereçamento IPv4 e CIDR.
Fontes e atualização
Não há norma jurídica sobre o tema. Fontes técnicas lidas: RFC 9293 (Transmission Control Protocol), em especial o formato do cabeçalho e as seções 3.5 e 3.6, e RFC 768 (User Datagram Protocol), ambos do IETF. Confira no edital a bibliografia da banca e veja a metodologia do site.