9.9. UDP – envie um pacote e torça pelo melhor

O UDP, o User Datagram Protocol, é o mais simples dos dois serviços que a camada de transporte oferece. Cada envio UDP é um datagrama – um bloco autocontido de bytes endereçado a um IP e a uma porta, lançado na rede por conta própria. O protocolo o entrega se conseguir; se não conseguir, não tenta de novo, não avisa o remetente e não preserva nenhuma ordenação entre os datagramas.

9.9.1. O que o UDP acrescenta ao IP

O UDP é uma camada fina sobre o IP. Ele acrescenta três coisas à entrega bruta do IP:

  • Números de porta em ambas as extremidades, para que um datagrama possa ser entregue ao programa certo no host de destino, e não apenas ao host (veja Portas).

  • Um campo de comprimento para que o destinatário saiba exatamente quantos bytes de payload deve ler.

  • Um pequeno checksum sobre o cabeçalho e o payload, para que o destinatário possa detectar um datagrama corrompido e descartá-lo.

É só isso. Tudo o mais que o IP fazia ou não fazia, o UDP mantém. Os datagramas não são reenviados. Eles podem chegar fora de ordem. Eles podem ser duplicados por peculiaridades da rede subjacente. Eles podem ser silenciosamente descartados se a rede estiver congestionada, se o buffer no destino estiver cheio ou se um dos roteadores no meio decidir descartá-los.

Um diagrama com o remetente à esquerda e o destinatário à direita. Três setas apontam do remetente para o destinatário, rotuladas "datagram 1", "datagram 2", "datagram 3". A seta do datagram 2 é mostrada como uma linha tracejada com um X sobre ela, indicando perda.

Cada datagrama UDP é enviado de forma independente. Se um se perde no trânsito, nada avisa o remetente ou o destinatário – a lacuna é silenciosa.

9.9.2. Por que alguém o usaria

Se o UDP é tão pouco confiável, por que tê-lo afinal? Três razões.

  • Velocidade e sobrecarga. Um envio UDP é um único pacote saindo; sem handshake, sem confirmações, sem estado de conexão para manter. O custo de latência e de largura de banda é mínimo.

  • Mensagens independentes. Parte do tráfego é um fluxo de atualizações de status em que cada mensagem é um snapshot novo e uma antiga não tem valor. Uma câmera publicando “ainda estou viva, aqui está minha leitura atual” a cada segundo se importa em entregar cada leitura nova, não em retransmitir as leituras que se perderam.

  • Multicast. Um único datagrama UDP pode ser enviado para muitos destinatários de uma só vez. (O TCP não pode fazer isso; toda conexão TCP é entre exatamente dois pontos.) Útil para descoberta de serviços, telemetria para muitos ouvintes e streaming de vídeo.

Onde a rede é boa e a tolerância do remetente à perda é alta, o UDP é a resposta certa. Onde a entrega e a ordenação têm de ser garantidas, o UDP precisa de outra camada de confiabilidade por cima, ou a aplicação deveria simplesmente usar o TCP.

9.9.3. Quando não usá-lo

Vale também ser explícito sobre o oposto. O UDP é a escolha errada quando:

  • Cada byte importa. Dados de configuração, atualizações de código, transações assinadas – qualquer caso em que um byte faltante torna o resultado errado.

  • A ordem importa. O datagrama UDP 2 pode chegar antes do datagrama 1.

  • A mensagem é grande. Payloads grandes têm de ser divididos em datagramas menores pela aplicação; a camada de transporte não fará isso. Se qualquer pedaço se perder, a mensagem inteira fica incompleta.

Se algum desses se aplica, recorra ao TCP.

9.9.4. Exemplos concretos em uma câmera

Exemplos de tráfego UDP na prática, no lado da câmera:

  • Descoberta. Uma câmera transmite um datagrama “quem está aqui” para a rede local na inicialização; outros dispositivos respondem.

  • Telemetria. Uma vez por segundo, a câmera envia um pequeno datagrama com suas leituras de sensor atuais para um coletor. Perder uma amostra ocasional não importa, porque a próxima chega em um segundo de qualquer forma.

  • Sincronização de tempo. O NTP, o protocolo de tempo de rede, roda sobre UDP. O cliente envia uma pequena requisição, o servidor responde com a hora atual; se a resposta se perde, o cliente simplesmente pergunta de novo mais tarde.

  • Resoluções DNS. Perguntar à rede “para qual IP este nome mapeia?” roda sobre UDP. (Abordado em Nomes e DNS.)

A API Python para enviar e receber datagramas está em Sockets UDP, depois que o restante da história da camada de transporte estiver no lugar.