Protocolo de datagrama do usuário - User Datagram Protocol

Em redes de computadores , o User Datagram Protocol ( UDP ) é um dos principais membros do conjunto de protocolos da Internet . Com o UDP, os aplicativos de computador podem enviar mensagens, neste caso chamadas de datagramas , para outros hosts em uma rede de protocolo da Internet (IP). Comunicações anteriores não são necessárias para configurar canais de comunicação ou caminhos de dados.

UDP usa um modelo de comunicação sem conexão simples com um mínimo de mecanismos de protocolo. O UDP fornece somas de verificação para integridade de dados e números de porta para endereçar funções diferentes na origem e no destino do datagrama. Ele não tem diálogos de handshake e, portanto, expõe o programa do usuário a qualquer falta de confiabilidade da rede subjacente; não há garantia de entrega, pedido ou proteção duplicada. Se os recursos de correção de erros forem necessários no nível da interface de rede, um aplicativo pode usar o Transmission Control Protocol (TCP) ou o Stream Control Transmission Protocol (SCTP), que são projetados para esse fim.

O UDP é adequado para finalidades nas quais a verificação e correção de erros não são necessárias ou são realizadas no aplicativo; O UDP evita a sobrecarga desse processamento na pilha de protocolo . Aplicativos sensíveis ao tempo geralmente usam UDP porque é preferível descartar pacotes a esperar por pacotes atrasados ​​devido à retransmissão , o que pode não ser uma opção em um sistema de tempo real .

O protocolo foi desenvolvido por David P. Reed em 1980 e formalmente definido no RFC  768 .

Atributos

UDP é um protocolo de camada de transporte orientado a mensagem simples documentado no RFC  768 . Embora o UDP forneça verificação de integridade (por meio de soma de verificação ) do cabeçalho e da carga útil, ele não oferece garantias ao protocolo da camada superior para entrega de mensagens e a camada UDP não retém o estado das mensagens UDP depois de enviadas. Por esse motivo, o UDP às vezes é conhecido como protocolo de datagrama não confiável . Se a confiabilidade da transmissão for desejada, ela deve ser implementada no aplicativo do usuário.

Vários atributos do UDP o tornam especialmente adequado para determinados aplicativos.

Ports

Os aplicativos podem usar soquetes de datagrama para estabelecer comunicações host-a-host. Um aplicativo liga um soquete ao seu ponto final de transmissão de dados, que é uma combinação de um endereço IP e uma porta . Dessa forma, o UDP fornece multiplexação de aplicativos . Uma porta é uma estrutura de software que é identificada pelo número da porta , um valor inteiro de 16 bits, permitindo números de porta entre 0 e 65535. A porta 0 é reservada, mas é um valor de porta de origem permitido se o processo de envio não espera mensagens em resposta.

A Internet Assigned Numbers Authority (IANA) dividiu os números das portas em três intervalos. Os números de porta de 0 a 1023 são usados ​​para serviços comuns e bem conhecidos. Em sistemas operacionais semelhantes ao Unix , o uso de uma dessas portas requer permissão de operação do superusuário . Os números de porta de 1024 a 49151 são as portas registradas usadas para serviços registrados pela IANA. As portas 49152 a 65535 são portas dinâmicas que não são oficialmente designadas para nenhum serviço específico e podem ser usadas para qualquer finalidade. Eles também podem ser usados ​​como portas efêmeras , que o software em execução no host pode usar para criar pontos de extremidade de comunicação dinamicamente conforme necessário.

Estrutura de datagrama UDP

Cabeçalho do datagrama UDP
Offsets Octeto 0 1 2 3
Octeto Pedaço  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0  0 Porta de origem Porto de destino
4 32 Comprimento Checksum

Um datagrama UDP consiste em um cabeçalho de datagrama e uma seção de dados . O cabeçalho do datagrama UDP consiste em 4 campos, cada um dos quais com 2 bytes (16 bits). A seção de dados segue o cabeçalho e são os dados de carga transportados para o aplicativo.

O uso dos campos de soma de verificação e porta de origem é opcional no IPv4 (fundo rosa na tabela). No IPv6, apenas o campo da porta de origem é opcional.

Número da porta de origem
Este campo identifica a porta do remetente, quando usado, e deve ser considerado a porta a ser respondida, se necessário. Se não for usado, deve ser zero. Se o host de origem for o cliente, o número da porta provavelmente será um número de porta efêmero. Se o host de origem for o servidor, o número da porta provavelmente será um número de porta conhecido .
Número da porta de destino
Este campo identifica a porta do receptor e é obrigatório. Semelhante ao número da porta de origem, se o cliente for o host de destino, o número da porta provavelmente será um número de porta efêmero e se o host de destino for o servidor, o número da porta provavelmente será um número de porta conhecido.
Comprimento
Este campo especifica o comprimento em bytes do cabeçalho UDP e dos dados UDP. O comprimento mínimo é de 8 bytes, o comprimento do cabeçalho. O tamanho do campo define um limite teórico de 65.535 bytes (cabeçalho de 8 bytes + 65.527 bytes de dados) para um datagrama UDP. No entanto, o limite real para o comprimento dos dados, que é imposto pelo protocolo IPv4 subjacente , é de 65.507 bytes (65.535 bytes - cabeçalho UDP de 8 bytes - cabeçalho IP de 20 bytes ).
Usando jumbogramas IPv6 é possível ter datagramas UDP de tamanho maior que 65.535 bytes. O RFC  2675 especifica que o campo de comprimento é definido como zero se o comprimento do cabeçalho UDP mais os dados UDP for maior que 65.535.
Checksum
O campo de soma de verificação pode ser usado para verificação de erros do cabeçalho e dos dados. Este campo é opcional no IPv4 e obrigatório no IPv6. O campo carrega todos os zeros se não for usado.

Cálculo de soma de verificação

O método usado para calcular a soma de verificação é definido no RFC  768 e o cálculo eficiente é discutido no RFC  1071 :

A soma de verificação é o complemento de um de 16 bits da soma do complemento de um de um pseudo cabeçalho de informações do cabeçalho IP, do cabeçalho UDP e dos dados, preenchido com zero octetos no final (se necessário) para fazer um múltiplo de dois octetos .

Em outras palavras, todas as palavras de 16 bits são somadas usando a aritmética do complemento de um. Adicione os valores de 16 bits. Em cada adição, se um carry-out (17º bit) for produzido, balance aquele 17º carry bit e adicione-o ao bit menos significativo do total em execução. Finalmente, a soma é então complementada para produzir o valor do campo UDP checksum.

Se o cálculo da soma de verificação resultar no valor zero (todos os 16 bits 0), ele deve ser enviado como complemento de um (todos os 1s), pois uma soma de verificação de valor zero indica que nenhuma soma de verificação foi calculada. Nesse caso, nenhum processamento específico é necessário no receptor, porque todos os 0s e todos os 1s são iguais a zero na aritmética do complemento de 1.

A diferença entre IPv4 e IPv6 está no pseudo cabeçalho usado para calcular a soma de verificação e a soma de verificação não é opcional no IPv6.

Pseudo cabeçalho IPv4

Quando o UDP é executado no IPv4, a soma de verificação é calculada usando um "pseudo cabeçalho" que contém algumas das mesmas informações do cabeçalho IPv4 real . O pseudo cabeçalho não é o cabeçalho IPv4 real usado para enviar um pacote IP, ele é usado apenas para o cálculo da soma de verificação.

Formato de pseudo cabeçalho IPv4
Offsets Octeto 0 1 2 3
Octeto Pedaço 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Endereço IPv4 de origem
4 32 Endereço IPv4 de destino
8 64 Zeros Protocolo Comprimento UDP
12 96 Porta Fonte Porto de destino
16 128 Comprimento Checksum
20 160+ Dados

Os endereços de origem e destino são aqueles no cabeçalho IPv4. O protocolo é o mesmo para UDP (ver Lista de números de protocolo IP ): 17 (0x11). O campo de comprimento UDP é o comprimento do cabeçalho UDP e dos dados. Os dados do campo representam os dados transmitidos.

O cálculo da soma de verificação UDP é opcional para IPv4. Se uma soma de verificação não for usada, ela deve ser definida com o valor zero.

Pseudo cabeçalho IPv6

Quando o UDP é executado em IPv6, a soma de verificação é obrigatória. O método usado para computá-lo foi alterado conforme documentado no RFC  2460 :

Qualquer transporte ou outro protocolo de camada superior que inclua os endereços do cabeçalho IP em seu cálculo de soma de verificação deve ser modificado para uso no IPv6 para incluir os endereços IPv6 de 128 bits.

Ao calcular a soma de verificação, novamente um pseudo cabeçalho é usado que imita o cabeçalho IPv6 real :

Formato de pseudo cabeçalho IPv6
Offsets Octeto 0 1 2 3
Octeto Pedaço 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Endereço IPv6 de origem
4 32
8 64
12 96
16 128 Endereço IPv6 de destino
20 160
24 192
28 224
32 256 Comprimento UDP
36 288 Zeros Próximo cabeçalho = protocolo
40 320 Porta Fonte Porto de destino
44 352 Comprimento Checksum
48 384+ Dados

O endereço de origem é aquele no cabeçalho IPv6. O endereço de destino é o destino final; se o pacote IPv6 não contiver um cabeçalho de roteamento, esse será o endereço de destino no cabeçalho IPv6; caso contrário, no nó de origem, será o endereço no último elemento do cabeçalho de roteamento e, no nó de recebimento, será o endereço de destino no cabeçalho IPv6. O valor do campo Próximo Cabeçalho é o valor do protocolo para UDP: 17. O campo de comprimento UDP é o comprimento do cabeçalho UDP e dos dados.

Confiabilidade e controle de congestionamento

Na falta de confiabilidade, os aplicativos UDP devem estar dispostos a aceitar alguma perda de pacote, reordenamento, erros ou duplicação. Se estiver usando UDP, os aplicativos do usuário final devem fornecer qualquer handshaking necessário, como confirmação em tempo real de que a mensagem foi recebida. Aplicativos, como TFTP , podem adicionar mecanismos rudimentares de confiabilidade à camada de aplicativo conforme necessário. Se um aplicativo exigir um alto grau de confiabilidade, um protocolo como o Transmission Control Protocol pode ser usado em seu lugar.

Na maioria das vezes, os aplicativos UDP não empregam mecanismos de confiabilidade e podem até ser prejudicados por eles. Streaming de mídia , jogos multijogador em tempo real e voz sobre IP (VoIP) são exemplos de aplicativos que costumam usar UDP. Nessas aplicações específicas, a perda de pacotes geralmente não é um problema fatal. Em VoIP, por exemplo, latência e jitter são as principais preocupações. O uso de TCP causaria jitter se algum pacote fosse perdido, pois o TCP não fornece dados subsequentes ao aplicativo enquanto solicita o reenvio dos dados perdidos.

Formulários

Vários aplicativos importantes da Internet usam UDP, incluindo: o Sistema de Nomes de Domínio (DNS), onde as consultas devem ser rápidas e consistir apenas em uma única solicitação seguida por um único pacote de resposta, o Protocolo Simples de Gerenciamento de Rede (SNMP), o Protocolo de Informação de Roteamento ( RIP) e o protocolo de configuração dinâmica de hosts (DHCP).

O tráfego de voz e vídeo geralmente é transmitido usando UDP. Os protocolos de streaming de áudio e vídeo em tempo real são projetados para lidar com pacotes perdidos ocasionais, portanto, ocorre apenas uma ligeira degradação da qualidade, em vez de grandes atrasos se os pacotes perdidos forem retransmitidos. Como o TCP e o UDP são executados na mesma rede, muitas empresas estão descobrindo que um aumento recente no tráfego UDP desses aplicativos em tempo real está prejudicando o desempenho dos aplicativos que usam TCP, como pontos de venda , contabilidade e sistemas de banco de dados . Quando o TCP detecta a perda de pacotes, ele reduz o uso da taxa de dados. Como os aplicativos em tempo real e de negócios são importantes para as empresas, a alta qualidade de serviço é considerada crucial por alguns.

Alguns sistemas VPN , como o OpenVPN, podem usar UDP e executar verificação de erros no nível do aplicativo enquanto implementam conexões confiáveis.

QUIC é um protocolo de transporte criado com base no UDP. O QUIC fornece uma conexão confiável e segura. HTTP / 3 usa QUIC em oposição a versões anteriores de HTTPS, que usam uma combinação de TCP e TLS para garantir confiabilidade e segurança, respectivamente. Isso significa que o HTTP / 3 usa um único handshake para configurar uma conexão, em vez de ter dois handshakes separados para TCP e TLS, o que significa que o tempo geral para estabelecer uma conexão é reduzido.

Comparação de UDP e TCP

O Protocolo de Controle de Transmissão é um protocolo orientado a conexão e requer handshaking para configurar comunicações ponta a ponta. Depois que uma conexão é configurada, os dados do usuário podem ser enviados bidirecionalmente pela conexão.

  • Confiável - o TCP gerencia o reconhecimento, a retransmissão e os tempos limite de mensagens. Várias tentativas de entregar a mensagem são feitas. Se os dados forem perdidos ao longo do caminho, eles serão reenviados. No TCP, não há dados ausentes ou, no caso de vários tempos limite, a conexão é interrompida.
  • Ordenado - Se duas mensagens forem enviadas por meio de uma conexão em sequência, a primeira mensagem chegará ao aplicativo receptor primeiro. Quando os segmentos de dados chegam na ordem errada, o TCP armazena os dados fora de ordem até que todos os dados possam ser reordenados adequadamente e entregues ao aplicativo.
  • Pesado - o TCP requer três pacotes para configurar uma conexão de soquete, antes que qualquer dado do usuário possa ser enviado. O TCP lida com confiabilidade e controle de congestionamento .
  • Streaming - Os dados são lidos como um fluxo de bytes , nenhuma indicação de distinção é transmitida para os limites da mensagem de sinal (segmento).

O User Datagram Protocol é um protocolo sem conexão baseado em mensagens mais simples . Os protocolos sem conexão não configuram uma conexão ponta a ponta dedicada. A comunicação é obtida pela transmissão de informações em uma direção da origem ao destino, sem verificar a prontidão ou o estado do receptor.

  • Não confiável - Quando uma mensagem UDP é enviada, não é possível saber se ela alcançará seu destino; ele pode se perder ao longo do caminho. Não há conceito de confirmação, retransmissão ou tempo limite.
  • Não ordenado - Se duas mensagens forem enviadas para o mesmo destinatário, a ordem em que chegaram não pode ser garantida.
  • Leve - Não há ordem de mensagens, nem rastreamento de conexões, etc. É uma camada de transporte muito simples projetada sobre o IP.
  • Datagramas - os pacotes são enviados individualmente e são verificados quanto à integridade na chegada. Os pacotes têm limites definidos que são respeitados após o recebimento; uma operação de leitura no soquete do receptor produzirá uma mensagem inteira da forma como foi enviada originalmente.
  • Sem controle de congestionamento - o próprio UDP não evita o congestionamento. As medidas de controle de congestionamento devem ser implementadas no nível do aplicativo ou na rede.
  • Broadcasts - sendo sem conexão, o UDP pode broadcast - os pacotes enviados podem ser endereçados para serem recebidos por todos os dispositivos na sub-rede.
  • Multicast - um modo de operação multicast é suportado por meio do qual um único pacote de datagrama pode ser roteado automaticamente sem duplicação para um grupo de assinantes.

Padrões

  • RFC  768 - Protocolo de Datagrama do Usuário
  • RFC  2460 - Especificação do protocolo da Internet, versão 6 (IPv6)
  • RFC  2675 - Jumbogramas IPv6
  • RFC  4113 - Base de informações de gerenciamento para o UDP
  • RFC  8085 - Diretrizes de uso de UDP

Veja também

Referências

links externos