03 - Length
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
- Ineficiência: Se um fragmento se perder, todo o datagrama UDP é descartado, desperdiçando os fragmentos que chegaram com sucesso.
- Custo de Processamento: A remontagem consome recursos do receptor (CPU e memória).
- 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
Lengthdo UDP é, tecnicamente, redundante, pois o receptor poderia calcular o tamanho subtraindo o tamanho do cabeçalho IP doTotal Lengthdo IP. - Justificativa: A RFC 768 definiu o campo
Lengthpara 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.