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.
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.