Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

03 - Length

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

Campo Length (Comprimento) do Cabeçalho UDP

1. Definição e Localização

O campo Length (Comprimento) é um campo de 16 bits localizado no cabeçalho UDP, especificamente no terceiro grupo de 16 bits (após os campos de Porta de Origem e Porta de Destino). Sua função é especificar o tamanho total, em bytes, do datagrama UDP, incluindo tanto o cabeçalho (8 bytes) quanto os dados (payload) da aplicação.

Este campo é essencial para que o receptor saiba exatamente onde o datagrama termina e onde os dados da aplicação começam, já que o UDP não possui um campo indicador de "fim de dados" como o TCP possui em seu fluxo contínuo. Sem o Length, a Camada de Transporte não seria capaz de delimitar a mensagem entregue à aplicação.

Características Formais

  • Tamanho: 16 bits (2 bytes)
  • Posição no cabeçalho: Bytes 5 e 6 do cabeçalho UDP (offset 4-5)
  • Endianness: Big-endian (network byte order)
  • RFC de referência: RFC 768 (J. Postel, 1980)

2. Escopo do Cálculo: Cabeçalho + Payload

Diferente de alguns protocolos onde o campo de comprimento indica apenas o tamanho dos dados, no UDP o valor do campo Length inclui tudo o que está dentro da estrutura UDP:

  • Cabeçalho UDP (fixo 8 bytes): Sempre contado.
  • Payload (Dados da Aplicação): Variável.

Portanto, a fórmula básica é:

Length = 8 (cabeçalho) + Tamanho do Payload

Exemplo Prático de Cálculo

Cenário Payload Cabeçalho UDP Campo Length
Consulta DNS simples 12 bytes 8 bytes 20 bytes
Resposta DNS média 512 bytes 8 bytes 520 bytes
Pacote VoIP (RTP) 160 bytes 8 bytes 168 bytes
Datagrama vazio (keep-alive) 0 bytes 8 bytes 8 bytes

Se uma aplicação envia 500 bytes de dados via UDP, o payload é 500 bytes, o cabeçalho UDP é 8 bytes, e o campo Length conterá o valor 508.

3. Faixa de Valores e Limites Teóricos

Como o campo possui 16 bits, ele pode representar valores de 0 a 65.535.

Limite Valor Significado
Mínimo válido 8 Datagrama com apenas cabeçalho (payload vazio)
Máximo teórico 65.535 Limite matemático de 16 bits
Máximo prático (IPv4) 65.515 Limitado por IP (65.535 - 20 bytes cabeçalho IP)
Máximo seguro (Ethernet) 1.500 Limitado pela MTU padrão

Valor Mínimo (8)

O menor valor possível é 8. Isso representa um datagrama UDP válido contendo apenas o cabeçalho e zero bytes de dados (payload vazio). Isso é utilizado em alguns protocolos de sinalização ou para "keep-alive" (manter a conexão ativa em túneis como VXLAN ou Geneve).

Valor Máximo Teórico (65.535)

O limite matemático do campo é 65.535 bytes. Isso incluiria 65.527 bytes de dados. Contudo, o datagrama UDP é encapsulado dentro de um datagrama IP, que também tem seu próprio limite de 65.535 bytes no campo Total Length. Portanto, o datagrama UDP nunca pode ser maior que o datagrama IP que o carrega.

4. Limitação Prática: MTU e Fragmentação

Embora o campo Length permita teoricamente valores enormes, na prática, o tamanho dos datagramas UDP é severamente limitado pela MTU (Maximum Transmission Unit) da Camada de Enlace (Camada 2).

Cálculo da MTU em Ethernet Padrão

  • MTU Padrão Ethernet: 1500 bytes
  • Cabeçalho IP (IPv4): 20 bytes
  • Cabeçalho UDP: 8 bytes
  • Espaço disponível para payload UDP: 1500 - 20 - 8 = 1472 bytes

Fragmentação IP

Se a aplicação tentar enviar um datagrama UDP com Length maior que 1472 bytes (em uma Ethernet padrão), o pacote IP será fragmentado pela Camada de Rede. O datagrama UDP original será partido em múltiplos pacotes IP menores para atravessar a rede e remontado no destino.

Problemas Causados pela Fragmentação

  1. Ineficiência: Se um fragmento se perder, todo o datagrama UDP é descartado, desperdiçando os fragmentos que chegaram com sucesso.
  2. Custo de Processamento: A remontagem consome recursos do receptor (CPU e memória).
  3. Firewalls: Alguns firewalls bloqueiam fragmentos IP por motivos de segurança, pois não conseguem inspecionar portas em fragmentos não-iniciais.

Por isso, aplicações UDP de alta performance (como DNS, VoIP ou jogos online) geralmente limitam seus payloads a menos de 1472 bytes ou usam Path MTU Discovery (RFC 1191) para encontrar o tamanho ideal do caminho e evitar que o IP fragmente os pacotes.

5. Diferença em Relação ao TCP

O campo Length destaca uma diferença fundamental na arquitetura entre UDP e TCP:

Aspecto UDP TCP
Modelo Orientado a mensagem Orientado a fluxo
Campo de tamanho Explícito (Length) Não possui campo de tamanho de payload
Limite de mensagem Datagrama preserva limites Aplicação precisa delimitar
Leitura no socket recvfrom() lê 1 datagrama recv() lê fluxo contínuo

No TCP, o receptor sabe onde a mensagem termina contando os bytes ou baseando-se na lógica da aplicação (ex: Content-Length em HTTP), não olhando para um campo de tamanho no pacote.

6. Redundância com o Cabeçalho IP

O cabeçalho IP (que envolve o UDP) também possui um campo chamado Total Length, que indica o tamanho total do pacote IP (Cabeçalho IP + Cabeçalho UDP + Dados).

  • Redundância Intencional: O campo Length do UDP é, tecnicamente, redundante, pois o receptor poderia calcular o tamanho subtraindo o tamanho do cabeçalho IP do Total Length do IP.
  • Justificativa: A RFC 768 definiu o campo Length para tornar o UDP independente do IP. Teoricamente, o UDP poderia ser usado sobre outros protocolos de rede que não o IP, onde o cálculo baseado no cabeçalho IP não seria possível.

Na prática, os dois valores devem ser consistentes: o Length do UDP deve ser igual ao Total Length do IP menos o tamanho do cabeçalho IP. Firewalls e sistemas de detecção de intrusão (IDS) verificam essa consistência e descartam pacotes com valores incoerentes.

7. Casos Especiais de Uso do Campo Length

UDP-Lite (RFC 3828)

O UDP-Lite é uma variante do UDP onde o campo Length tem significado diferente: em vez de indicar o tamanho total do datagrama, ele indica quantos bytes estão cobertos pelo checksum. Isso é útil em aplicações multimídia onde erros em alguns bytes do payload são toleráveis (ex: codecs de áudio/vídeo com correção de erro interna).

Jumbograms (RFC 2675)

Para datagramas maiores que 65.535 bytes (em redes com MTU muito grande, como InfiniBand), o campo Length é preenchido com zero e o tamanho real é transportado em uma opção de salto por salto (Hop-by-Hop) no IPv6. Isso é raro na prática, mas usado em supercomputação.

8. Resumo Técnico

Atributo Valor
Tamanho do campo 16 bits
Posição no cabeçalho Bytes 5-6 (offset 4)
Valor mínimo 8
Valor máximo 65.535
Inclui cabeçalho? Sim
Inclui payload? Sim
Obrigatório? Sim (RFC 768)
Endianness Big-endian

9. Conclusão

O campo Length do UDP aparenta ser simples, mas carrega consigo decisões de design profundas: a preservação de limites de mensagem, a independência do protocolo de rede subjacente e a limitação prática imposta pela MTU. Para engenheiros de rede e desenvolvedores de software, entender o comportamento deste campo é essencial para otimizar throughput, evitar fragmentação e desenhar protocolos eficientes sobre UDP, especialmente em aplicações sensíveis a latência como VoIP, jogos online e streaming de baixo retardo.