TCP e UDP

Depois que o DNS fornece um endereço IP, seu dispositivo pode enviar pacotes para o destino correto. Mas o IP apenas move pacotes independentes pelas redes — ele não acompanha se eles chegam, se chegam na ordem correta ou se a rede está congestionada.

Se você dividir uma página da web em muitos pacotes, alguns podem chegar fora de ordem, alguns podem atrasar e alguns podem ser perdidos completamente. Sem coordenação adicional, a aplicação receptora não teria uma forma confiável de reconstruir os dados originais corretamente.

Os protocolos de transporte resolvem quatro problemas fundamentais: ordenação (reconstruir os dados corretamente), confiabilidade (detectar e retransmitir dados perdidos), multiplexação (permitir que várias aplicações compartilhem um único endereço IP) e controle de congestionamento (evitar que a rede fique sobrecarregada).

Em resumo, o IP responde “Para onde este pacote deve ir?”
Os protocolos de transporte respondem “Como esta conversa deve se comportar?”

Quando os dados chegam ao endereço IP de um servidor, o sistema operacional ainda precisa decidir qual programa deve tratá-los. Uma única máquina pode executar um servidor web, um servidor de banco de dados, um serviço SSH e muitas outras aplicações ao mesmo tempo.

É aqui que entram os números de porta. Uma porta é um ponto final lógico de comunicação usado por protocolos de transporte como TCP e UDP. Ela permite que o sistema faça a demultiplexação do tráfego de entrada e o entregue ao processo de aplicação correto.

Por exemplo, a porta 80 é normalmente usada para HTTP, a porta 443 para HTTPS e a porta 22 para SSH. Quando você acessa um site seguro, seu navegador se conecta ao endereço IP do servidor na porta 443, indicando que quer se comunicar usando HTTPS.

Sem portas, uma máquina só poderia executar uma aplicação de rede por vez. As portas permitem que milhares de conversas simultâneas ocorram em um único endereço IP.

O Transmission Control Protocol (TCP) foi projetado para aplicações que exigem entrega completa e precisa de dados. Diferente do IP bruto, o TCP trata a comunicação como um fluxo contínuo de bytes, em vez de pacotes independentes.

Cada segmento de dados recebe um sequence number. O receptor usa esses números para reordenar os dados corretamente antes de passá-los para a aplicação. Se um segmento estiver faltando, o TCP detecta a lacuna e solicita a retransmissão.

O TCP também inclui flow control, que impede que um remetente rápido sobrecarregue um receptor mais lento. Ele faz isso usando um mecanismo de janela deslizante que limita quanto dado não reconhecido pode estar em trânsito.

Por fim, o TCP implementa congestion control. Ele monitora as condições da rede e ajusta a velocidade de transmissão para evitar sobrecarregar os roteadores. Isso protege a estabilidade geral da rede e, ao mesmo tempo, maximiza a taxa de transferência quando as condições permitem.

TCP é orientado à conexão, o que significa que ambos os lados precisam concordar em se comunicar antes que a transferência de dados comece. Esse processo garante que tanto o cliente quanto o servidor estejam prontos e aptos a trocar dados.

Primeiro, o cliente envia um pacote SYN (synchronize). Esse pacote propõe um número de sequência inicial e sinaliza o desejo de abrir uma conexão.

Segundo, o servidor responde com um SYN-ACK. Isso reconhece a solicitação do cliente e fornece o próprio número de sequência inicial do servidor.

Por fim, o cliente envia um ACK para confirmar o recebimento do número de sequência do servidor. Nesse ponto, ambos os lados têm números de sequência sincronizados e a conexão está oficialmente estabelecida.

Somente depois que esse handshake é concluído o TCP começa a transferir os dados da aplicação.

O TCP atribui um número de sequência a cada byte no fluxo de dados. Isso permite que o receptor detecte segmentos ausentes ou fora de ordem e reconstrua corretamente a mensagem original.

O receptor envia de volta números de ACK (acknowledgment) indicando o próximo byte esperado. Se o remetente não receber um ACK dentro de um certo tempo, ele assume que o segmento foi perdido.

Quando uma perda é detectada, o TCP realiza uma retransmissão, enviando os dados ausentes novamente. Esse mecanismo garante confiabilidade mesmo quando pacotes são descartados devido a congestionamento ou instabilidade da rede.

O TCP também usa uma janela deslizante para controle de fluxo. Em vez de esperar um ACK após cada pacote, o remetente pode transmitir vários segmentos dentro de um tamanho de janela permitido. Isso melhora a eficiência enquanto mantém garantias rígidas de entrega.

Protocolo de Datagrama do Usuário (UDP) é sem conexão. Diferente do TCP, ele não realiza um aperto de mão antes de enviar dados. Um remetente simplesmente transmite pacotes para o IP e a porta de destino.

UDP não rastreia números de sequência para confiabilidade, não espera por confirmações e não retransmite pacotes perdidos. Se um pacote for descartado, ele se perde.

Como o UDP remove esses mecanismos de coordenação, ele tem overhead e latência significativamente menores. Isso o torna adequado para casos de uso em que a velocidade importa mais do que a entrega perfeita, como streaming ao vivo, jogos online ou consultas DNS.

Em resumo, o UDP prioriza desempenho e simplicidade em vez de confiabilidade.

TCP é ideal para aplicações em que dados ausentes ou corrompidos quebrariam a funcionalidade. Páginas web, APIs, downloads de arquivos e e-mail exigem dados completos e corretamente ordenados. Até mesmo um único byte ausente poderia corromper o resultado.

UDP é mais adequado para aplicações em que a perda ocasional de pacotes é aceitável. Vídeo em tempo real, chamadas de voz, jogos e pequenas consultas sem estado, como DNS, priorizam velocidade em vez de perfeição. Esperar por retransmissões criaria um atraso perceptível.

A decisão principal é esta:
Se precisão e completude forem obrigatórias, use TCP.
Se responsividade e baixa latência forem críticas, UDP pode ser a melhor opção.

Se uma porta de destino estiver fechada ou bloqueada por um firewall, o servidor pode responder imediatamente com uma mensagem de connection refused. Isso significa que a máquina está acessível, mas nenhuma aplicação está escutando nessa porta.

Se um cliente envia um SYN, mas nunca recebe um SYN-ACK, a tentativa de conexão eventualmente vai timeout. Isso geralmente indica que o servidor está fora do ar, inacessível ou filtrado por um firewall no caminho.

Quando a perda de pacotes é alta, o TCP detecta confirmações ausentes e realiza retransmissions. Embora a confiabilidade seja preservada, o desempenho piora significativamente.

Sob forte congestionamento, o TCP reduz sua taxa de envio por meio de algoritmos de controle de congestionamento. A conexão continua ativa, mas a vazão diminui e a latência aumenta.