9.9. UDP – envia um pacote e torce para o melhor¶

O UDP, User Datagram Protocol (Protocolo de Datagrama de Utilizador), é o mais simples dos dois serviços que a camada de transporte oferece. Cada envio UDP é um datagrama – um bloco de bytes auto-contido endereçado a um IP e uma porta, largado na rede por conta própria. O protocolo entrega-o se puder; se não puder, não tenta de novo, não avisa o emissor e não preserva qualquer ordenação entre datagramas.

9.9.1. O que o UDP acrescenta ao IP¶

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

Números de porta em ambos os extremos, para que um datagrama possa ser entregue ao programa certo no anfitrião de destino, não apenas ao anfitrião (ver Portas).
Um campo de comprimento para que o receptor saiba exactamente quantos bytes de payload ler.
Uma pequena soma de verificação sobre o cabeçalho e o payload, para que o receptor possa detectar um datagrama corrompido e descartá-lo.

É isso. Tudo o resto que o IP fazia ou não fazia, o UDP mantém. Os datagramas não são reenviados. Podem chegar fora de ordem. Podem ser duplicados por peculiaridades da rede subjacente. Podem ser silenciosamente descartados se a rede estiver congestionada, o buffer no destino estiver cheio, ou um dos routers intermédios decidir fazê-lo.

Cada datagrama UDP é enviado de forma independente. Se um for perdido em trânsito, nada informa o emissor ou o receptor – a lacuna é silenciosa.¶

9.9.2. Por que razão alguém o usaria¶

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

Velocidade e sobrecarga. Um envio UDP é um único pacote a sair; sem handshake, sem confirmações, sem estado de ligação a manter. A latência e o custo de largura de banda são mínimos.
Mensagens independentes. Algum tráfego é um fluxo de actualizações de estado onde cada mensagem é uma nova captura de imagem e uma antiga não tem valor. Uma câmara que publica «ainda estou activa, aqui está a minha leitura actual» todos os segundos preocupa-se em entregar cada leitura nova, não em repetir as leituras que se perderam.
Multicast. Um único datagrama UDP pode ser enviado a vários receptores de uma só vez. (O TCP não pode fazer isso; cada ligação TCP é entre exactamente dois extremos.) Útil para descoberta de serviços, telemetria para vários receptores, streaming de vídeo.

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

9.9.3. Quando não usá-lo¶

O oposto também merece ser explicitado. O UDP é a escolha errada quando:

Cada byte importa. Dados de configuração, actualizações de código, transacções assinadas – qualquer caso onde um byte em falta 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 o fará. Se alguma peça se perder, toda a mensagem fica incompleta.

Se qualquer uma dessas condições se aplicar, recorra ao TCP.

9.9.4. Exemplos concretos numa câmara¶

Exemplos do lado da câmara de tráfego UDP na prática:

Descoberta. Uma câmara difunde um datagrama «quem está aqui» para a rede local no arranque; outros dispositivos respondem.
Telemetria. Uma vez por segundo, a câmara envia um pequeno datagrama com as suas leituras de sensor actuais para um colector. Perder uma amostra ocasional não importa porque a próxima chega dentro de um segundo de qualquer maneira.
Sincronização de tempo. O NTP, o protocolo de tempo de rede, corre sobre UDP. O cliente envia um pequeno pedido, o servidor responde com a hora actual; se a resposta se perder, o cliente simplesmente pergunta novamente mais tarde.
Pesquisas de DNS. Perguntar à rede «a que IP corresponde este nome?» corre sobre UDP. (Abordado em Nomes e DNS.)

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