Datagrama UDP - A Unidade de Transferência

1. Definição e Contexto

No contexto do protocolo UDP, a unidade de transferência de dados é chamada de Datagrama. Diferente do TCP, que utiliza o termo "Segmento" e opera com um fluxo contínuo de bytes, o UDP opera com blocos de dados distintos e isolados.

O Datagrama UDP é a PDU (Protocol Data Unit) da Camada de Transporte quando se utiliza o protocolo UDP. Ele consiste em um cabeçalho UDP seguido imediatamente pelos dados da aplicação (payload). Este datagrama é, por sua vez, encapsulado dentro de um datagrama IP para ser enviado através da rede.

Características Formais

• RFC de referência: RFC 768 (J. Postel, 1980)
• Camada OSI: 4 (Transporte)
• Modelo: Sem conexão, melhor esforço
• Orientação: Orientado a mensagem (não a fluxo)
• Confiabilidade: Não confiável (sem ACK, sem retransmissão)

2. Natureza da Unidade: Independência e Autonomia

A característica mais importante do Datagrama UDP é sua autonomia.

• Sem Relacionamento: Se uma aplicação envia três Datagramas UDP consecutivos (A, B e C) para o mesmo destino, a rede não sabe que eles estão relacionados. Eles são tratados como três mensagens separadas e independentes.
• Self-Contained: Cada datagrama carrega todas as informações necessárias para ser entregue e processado (portas de origem e destino, comprimento e checksum). Ele não depende de informações contidas em datagramas anteriores ou posteriores.

Consequências da Autonomia

3. Preservação dos Limites de Mensagem (Message Boundaries)

O uso do Datagrama como unidade tem uma implicação direta na forma como a aplicação envia e recebe dados: os limites são preservados.

Contraste com TCP

• No TCP (modelo de fluxo): Se a aplicação escrever 100 bytes e depois escrever mais 200 bytes, o TCP pode fundir isso em um pacote de 300 bytes ou dividi-lo em pedaços de 50 bytes. A aplicação receptora lê um fluxo contínuo e não sabe onde uma "escrita" terminou e a próxima começou.
• No UDP (orientado a mensagem): O que é enviado é o que é recebido como uma unidade distinta. Se a aplicação enviar um datagrama de 100 bytes, a aplicação receptora receberá um datagrama de 100 bytes (se ele chegar). Se enviar outro de 200 bytes, receberá outro de 200 bytes.

Leitura (Read) com Sockets UDP

Na programação com sockets UDP, uma chamada de leitura (recvfrom) lê exatamente um datagrama completo. Se o buffer da aplicação for menor que o tamanho do datagrama UDP recebido, o excesso é truncado e perdido (dependendo do sistema operacional), mas nunca é combinado com o próximo datagrama.

Exemplo em C (recvfrom)

char buffer[2048];
struct sockaddr_in src_addr;
socklen_t addrlen = sizeof(src_addr);

// Lê exatamente UM datagrama UDP (até 2048 bytes)
ssize_t n = recvfrom(sockfd, buffer, sizeof(buffer), 0,
                     (struct sockaddr*)&src_addr, &addrlen);

if (n < 0) {
    perror("recvfrom falhou");
} else {
    printf("Recebi %zd bytes de datagrama\n", n);
}

4. Estrutura do Datagrama UDP

O Datagrama UDP é composto por duas partes principais:

4.1. Cabeçalho UDP (8 bytes)

Contém as informações de controle essenciais:

4.2. Dados (Payload)

A informação real da aplicação.

• Tamanho Variável: O payload pode ter tamanho variável, de 0 bytes até um máximo teórico de 65.507 bytes (65.535 bytes do datagrama IP menos 20 bytes do cabeçalho IP e 8 bytes do cabeçalho UDP).
• Limite Prático: Na prática, o tamanho é limitado pelo MTU da rede física (geralmente 1500 bytes), resultando em um payload máximo seguro de cerca de 1472 bytes.

5. Encapsulamento

Para viajar pela rede, o Datagrama UDP é encapsulado dentro de um datagrama IP:

+---------------------------+
|  Cabeçalho Ethernet       |  (Camada 2 - 14 bytes + FCS)
+---------------------------+
|  Cabeçalho IP             |  (Camada 3 - 20 bytes mín.)
|    Src IP / Dst IP        |
|    Protocol = 17 (UDP)    |
+---------------------------+
|  Cabeçalho UDP            |  <-- Início do Datagrama UDP (Camada 4)
|    Src Port / Dst Port    |
|    Length / Checksum      |
+---------------------------+
|   Dados (Payload)         |
|      (Aplicação)          |
+---------------------------+
|  FCS (Frame Check Seq.)   |  (Camada 2 - 4 bytes)
+---------------------------+

O protocolo IP vê todo o bloco (Cabeçalho UDP + Payload) apenas como dados. Ele não analisa as portas; essa é a função exclusiva da Camada de Transporte no destino.

6. Unicidade na Terminologia

É importante distinguir as unidades em diferentes camadas para evitar confusão:

O termo "Datagrama" é compartilhado entre IP e UDP porque ambos seguem a filosofia de "melhor esforço" sem conexão, mas o Datagrama UDP é um subconjunto lógico contido dentro do Datagrama IP.

7. Vantagens do Modelo Datagrama

Latência Baixa

Como não há handshake inicial nem buffers de retransmissão, o primeiro byte é enviado imediatamente após a syscall sendto(). Isso é crítico para:

• DNS (consultas rápidas)
• VoIP (voz em tempo real)
• Jogos online (estado do jogo)
• Streaming de vídeo (baixo retardo)

Economia de Recursos

• Sem estado de conexão na memória do kernel.
• Sem timers de retransmissão.
• Sem controle de congestionamento.

Multicast e Broadcast Nativos

UDP suporta nativamente envio para múltiplos destinos com um único datagrama (multicast IP), algo impossível em TCP.

8. Desvantagens e Limitações

9. Exemplos Práticos de Aplicação

# Capturar datagramas UDP com tcpdump
tcpdump -i eth0 udp -n -X

# Ver estatísticas UDP no Linux
ss -s

# Testar throughput UDP com iperf3
iperf3 -c 192.168.1.10 -u -b 100M -l 1472

Resultado Típico do ss -s

Total: 234 (kernel 0)
TCP:   12 (estab 5, closed 0, orphaned 0, synwait 0)
UDP:   18 (in 5, out 13)

10. Resumo Técnico

11. Conclusão

O Datagrama UDP é uma unidade de transferência elegante em sua simplicidade. Sua natureza autônoma e orientada a mensagem faz dele a escolha ideal para aplicações onde latência baixa e simplicidade superam a necessidade de confiabilidade garantida pelo protocolo. Compreender a estrutura do datagrama e seu encapsulamento é fundamental para desenvolvedores de software de rede, engenheiros de sistemas distribuídos e administradores que otimizam aplicações em tempo real.