9.9. UDP – invia un pacchetto e spera per il meglio

UDP, il User Datagram Protocol, è il più semplice dei due servizi offerti dal livello di trasporto. Ogni invio UDP è un datagramma – un blocco autonomo di byte indirizzato a un IP e a una porta, immesso nella rete per conto proprio. Il protocollo lo consegna se può; se non può, non riprova, non avvisa il mittente e non preserva alcun ordinamento tra i datagrammi.

9.9.1. Cosa aggiunge UDP a IP

UDP è un sottile strato che si appoggia su IP. Aggiunge tre cose alla pura consegna IP:

  • Numeri di porta a entrambe le estremità, in modo che un datagramma possa essere consegnato al programma corretto sull’host di destinazione, e non solo all’host (vedi Porte).

  • Un campo lunghezza in modo che il destinatario sappia esattamente quanti byte di payload leggere.

  • Un piccolo checksum sull’header e sul payload, in modo che il destinatario possa rilevare un datagramma corrotto e scartarlo.

Tutto qui. Tutto il resto che IP faceva o non faceva, UDP lo mantiene. I datagrammi non vengono ritrasmessi. Possono arrivare fuori ordine. Possono essere duplicati per stranezze della rete sottostante. Possono essere scartati silenziosamente se la rete è congestionata, se il buffer alla destinazione è pieno, o se uno dei router intermedi decide di farlo.

Un diagramma con il mittente a sinistra e il destinatario a destra. Tre frecce puntano dal mittente al destinatario, etichettate "datagramma 1", "datagramma 2", "datagramma 3". La freccia per il datagramma 2 è mostrata come una linea tratteggiata con una X sopra, a indicare la perdita.

Ogni datagramma UDP viene inviato in modo indipendente. Se uno si perde durante il transito, niente lo segnala al mittente o al destinatario – il vuoto è silenzioso.

9.9.2. Perché mai qualcuno dovrebbe usarlo

Se UDP è così inaffidabile, perché averlo? Tre ragioni.

  • Velocità e overhead. Un invio UDP è un singolo pacchetto che esce; nessun handshake, nessuna conferma, nessuno stato di connessione da mantenere. Il costo in termini di latenza e larghezza di banda è minimo.

  • Messaggi indipendenti. Parte del traffico è un flusso di aggiornamenti di stato in cui ogni messaggio è uno snapshot fresco e uno vecchio è inutile. Una camera che pubblica «sono ancora viva, ecco la mia lettura attuale» ogni secondo si preoccupa di consegnare ogni nuova lettura, non di ritrasmettere le letture andate perse.

  • Multicast. Un singolo datagramma UDP può essere inviato a molti destinatari contemporaneamente. (TCP non può farlo; ogni connessione TCP è tra esattamente due endpoint.) Utile per il rilevamento di servizi, la telemetria verso molti ascoltatori, lo streaming video.

Dove la rete è buona e la tolleranza del mittente alla perdita è elevata, UDP è la risposta giusta. Dove la consegna e l’ordinamento devono essere garantiti, UDP necessita o di un ulteriore strato di affidabilità in cima, oppure l’applicazione dovrebbe semplicemente usare TCP.

9.9.3. Quando non usarlo

Vale la pena essere espliciti anche sul contrario. UDP è la scelta sbagliata quando:

  • Ogni byte conta. Dati di configurazione, aggiornamenti di codice, transazioni firmate – qualsiasi caso in cui un byte mancante rende il risultato errato.

  • L’ordine conta. Il datagramma UDP 2 potrebbe arrivare prima del datagramma 1.

  • Il messaggio è grande. I payload di grandi dimensioni devono essere suddivisi in datagrammi più piccoli dall’applicazione; il livello di trasporto non lo farà. Se anche un solo pezzo si perde, l’intero messaggio è incompleto.

Se uno qualsiasi di questi casi si applica, ricorri invece a TCP.

9.9.4. Esempi concreti su una camera

Esempi lato camera di traffico UDP nel mondo reale:

  • Rilevamento. All’avvio una camera trasmette in broadcast un datagramma «chi c’è» alla rete locale; altri dispositivi rispondono.

  • Telemetria. Una volta al secondo, la camera invia un piccolo datagramma con le sue letture attuali del sensore a un collettore. Perdere occasionalmente un campione non ha importanza, perché il successivo arriva comunque entro un secondo.

  • Sincronizzazione temporale. NTP, il network time protocol, gira su UDP. Il client invia una piccola richiesta, il server risponde con l’ora corrente; se la risposta si perde, il client si limita a richiederla più tardi.

  • Risoluzioni DNS. Chiedere alla rete «a quale IP corrisponde questo nome?» gira su UDP. (Trattato in Nomi e DNS.)

L’API Python per inviare e ricevere datagrammi è in Socket UDP, dopo che il resto della storia del livello di trasporto è a posto.