05 - Datagrama

O Serviço de Datagrama é um modelo de comunicação da Camada de Transporte caracterizado pela ausência de conexão lógica entre o remetente e o receptor. É o serviço "despojado" e fundamental da camada, tipicamente implementado pelo protocolo UDP (User Datagram Protocol), definido na RFC 768.

Neste modelo, a unidade de transferência é tratada como uma entidade autônoma e independente. O serviço de datagrama oferece o mínimo de garantias, focando-se na eficiência e na simplicidade, delegando todas as responsabilidades de controle de erros e fluxo para as camadas superiores (a aplicação). Em essência, o serviço de datagrama na Camada de Transporte é um mero invólucro em torno do serviço de datagrama da Camada de Rede (IP), adicionando apenas a funcionalidade de endereçamento de processos (Portas).

1. Natureza Sem Conexão (Connectionless)

A característica definidora do serviço de datagrama é que ele é sem conexão. Não existe um ciclo de estabelecimento de link antes da transferência de dados, nem uma fase de encerramento formal.

• Ausência de Handshake: O processo remetente envia dados para o processo receptor sem realizar qualquer "aperto de mão" prévio para verificar se o receptor está pronto, disposto ou mesmo existe. O ato de enviar é independente do estado do destino.
• Autonomia dos Mensagens: Cada mensagem (datagrama) enviada é tratada como uma transação isolada. Se uma aplicação enviar 5 mensagens seguidas para o mesmo destino, a rede não sabe que elas estão relacionadas. Elas são roteadas e entregues como se fossem 5 eventos desconexos.
• Analogia Postal: Este modelo é análogo ao serviço de correio tradicional. Você escreve uma carta (datagrama), coloca no envelope com o endereço (IP e Porta) e joga na caixa de correio. Você não liga para o destinatário avisando que a carta está vindo. Se a carta não chegar, ninguém te avisa.

2. Entrega Não Garantida (Unreliable)

O termo "não confiável" (unreliable) descreve a filosofia de "melhor esforço" (best-effort). O serviço de datagrama não oferece qualquer garantia de sucesso na entrega.

• Sem Confirmações (ACKs): O remetente envia o datagrama e prossegue com suas atividades. Não há um mecanismo automático de feedback onde o receptor avisa "recebido o pacote número 1".
• Sem Recuperação de Erros: Se um datagrama for perdido, descartado por um roteador (devido a congestionamento ou TTL expirado), ou corrompido em trânsito, o serviço de transporte nada faz para consertar o problema. O pacote simplesmente desaparece.
• Responsabilidade da Aplicação: Se a aplicação exige confiabilidade (ex: garantir que um arquivo chegue inteiro), ela mesma deve implementar mecanismos de confirmação, temporizadores e retransmissão. O serviço de transporte não ajuda nisso.

3. Independência e Ordem de Pacotes

Devido à natureza sem conexão e ao roteamento dinâmico da rede IP, o serviço de datagrama não impõe nenhuma ordem de chegada aos pacotes.

• Chegada Desordenada: Como cada datagrama pode tomar uma rota diferente na rede, um datagrama enviado depois pode chegar antes de um datagrama enviado antes. O serviço de transporte entrega os dados na ordem exata em que chegam do IP, sem tentar reordená-los.
• Possibilidade de Duplicação: O protocolo IP pode ocasionalmente duplicar pacotes. Como o serviço de datagrama não mantém histórico, o receptor pode receber o mesmo datagrama duas vezes. Cabe à aplicação filtrar duplicatas, se necessário.
• Limites de Mensagens: O serviço de datagrama preserva as fronteiras das mensagens. Se a aplicação envia uma mensagem de 100 bytes e outra de 200 bytes, o receptor receberá exatamente um datagrama de 100 bytes e outro de 200 bytes (ou nada). Eles nunca serão mesclados em um único bloco de 300 bytes, ao contrário do modelo de fluxo de bytes do TCP.

4. Baixa Sobrecarga (Overhead) e Eficiência

A principal vantagem do serviço de datagrama é a sua leveza e eficiência de processamento.

• Cabeçalho Pequeno: Por não precisar de campos para controle de janela, números de sequência, flags de conexão ou checksums complexos, o cabeçalho de um serviço de datagrama (como o UDP) é muito pequeno (apenas 8 bytes no UDP) comparado aos 20+ bytes mínimos do TCP.
• Processamento Rápido: Como não há estado de conexão para manter, os roteadores e os sistemas finais processam os datagramas com menos instruções de CPU. Não há memória alocada para buffers de conexão ou tabelas de estado de janela deslizante.
• Baixa Latência: A ausência de estabelecimento de conexão (handshake) antes da transmissão e a falta de atraso de processamento tornam o serviço de datagrama ideal para aplicações onde a velocidade é mais crítica que a perfeição.

Estrutura do Cabeçalho UDP (8 bytes fixos)

 0      7 8     15 16    23 24    31
+--------+--------+--------+--------+
|  Source Port   |   Dest. Port   |   4 bytes
+--------+--------+--------+--------+
|     Length      |    Checksum    |   4 bytes
+--------+--------+--------+--------+
|           dados (payload)         |   variável
+-----------------------------------+

Comparado ao cabeçalho mínimo de 20 bytes do TCP, o UDP economiza 12 bytes por pacote — em uma transferência de 1 milhão de pacotes pequenos, são 12 MB de banda economizada.

5. Quando o Serviço de Datagrama é Ideal

Apesar de suas "limitações", o serviço de datagrama é a escolha obrigatória para certas classes de aplicações:

• Aplicações em Tempo Real (Real-Time): Voz sobre IP (VoIP), streaming de vídeo e jogos online. Nestes casos, a retransmissão de um pacote perdido é inútil (ele chegaria atrasado demais para ser útil). É melhor perder um quadro de vídeo do que pausar o vídeo inteiro para pedir o quadro de volta. (Protocolos: RTP sobre UDP.)
• Consultas Simples (Request-Response): Protocolos como o DNS, onde o tamanho da mensagem é pequeno e a simplicidade é vital. Uma consulta de DNS falhada pode ser facilmente repetida pelo cliente em microsegundos, sem precisar da complexidade de uma conexão TCP completa.
• Multicast / Broadcast: O serviço de datagrama é o único suportado para comunicação de um-para-muitos. O modelo de conexão ponto-a-ponto (TCP) não escalaria para enviar dados para milhares de receptores simultaneamente. (Exemplos: IPTV, SDP/SAP, mDNS.)
• Aplicações Tolerantes a Perdas: SNMP (monitoramento de rede), syslog, NTP (sincronização de relógio).

6. Datagrama na Prática: Anatomia de uma Consulta DNS

Considere uma consulta DNS simples do cliente 192.168.0.10 para o resolvedor 8.8.8.8:

13:14:01.223  IP 192.168.0.10.43210 > 8.8.8.8.53: 4753+ A? example.com. (29)
13:14:01.301  IP 8.8.8.8.53 > 192.168.0.10.43210: 4753 1/0/0 A 93.184.216.34 (45)

• Porta origem 43210 (efêmera, escolhida pelo SO), porta destino 53 (DNS).
• 4753 é o Transaction ID do DNS — é a aplicação que implementa o controle (timeout, retransmissão), não o UDP.
• Se a resposta não chegar em ~2 segundos, a libc (glibc) reenvia a consulta: o UDP nada fez no intervalo.

6.1 Comando nmap -sU

Para escanear portas UDP (mais lento que TCP, pois UDP não responde a portas fechadas de forma óbvia):

# Scan das 1000 portas UDP mais comuns:
nmap -sU exemplo.com

# Porta específica (DNS, SNMP):
nmap -sU -p 53,161 exemplo.com

Saída típica:

PORT    STATE         SERVICE
53/udp  open          domain
161/udp open|filtered snmp

O estado open|filtered reflete a dificuldade: se não há resposta, pode ser que a porta está aberta (silêncio) ou que um firewall está filtrando o pacote. Nmap retransmite múltiplas vezes para tentar desambiguar.

6.2 Risco de fragmentação

Datagramas UDP podem ter payload de até 65507 bytes em IPv4 (65535 - 20 IP - 8 UDP), mas se o tamanho exceder o MTU do enlace (1500 em Ethernet padrão), o IP fragmenta. No receptor:

• Se qualquer fragmento for perdido, o datagrama inteiro é descartado.
• Aplicações sensíveis a perda devem limitar o payload a 1472 bytes (1500 - 20 - 8) para evitar fragmentação.
• Em IPv6, o roteador intermediário não fragmenta — a aplicação deve usar Path MTU Discovery (RFC 8201) ou ficar abaixo de 1232 bytes (PMTU seguro para IPv6 sobre Ethernet).

6.3 Exemplo completo com nc (netcat)

# Servidor UDP escutando na porta 5000:
nc -u -l 5000

# Cliente enviando uma mensagem:
echo "ola servidor" | nc -u 127.0.0.1 5000

Como UDP é sem estado, o servidor não "abre" uma conexão: cada recvfrom() devolve um datagrama e o endereço do remetente. Se o cliente não responder, nada detecta a perda.

7. Modelo de Serviço x Implementação

O QUIC (HTTP/3) é um caso interessante: roda sobre UDP e reimplementa confiabilidade, controle de fluxo e congestionamento na camada de aplicação, mostrando que é possível construir serviços complexos sobre o datagrama.

8. Resumo

O serviço de datagrama é o bloco construtivo minimalista da Camada de Transporte. Sua força não está no que oferece, mas no que omite: sem estado, sem handshake, sem retransmissão, ele entrega velocidade bruta e flexibilidade para a aplicação. Quando a aplicação precisa de confiabilidade, ela implementa-a ou usa TCP; quando precisa de velocidade, usa o datagrama.