Il n'est pas toujours nécessaire de disposer de communications totalement fiables, soit pour des raisons d'efficacité, soit qu'il importe peu que des paquets soient altérés. C'est le cas des transmissions vocales où la réduction des délais de transmission est plus importante que l'intégrité des données, ou des communications de serveurs de noms pour lesquelles des transmissions de paquets uniques sont souhaitées. Un autre cas concerne NFS (Network File System [NdT: NFS est un système de partage de fichiers sur réseau (voir le chapitre 29).) qui utilise UDP pour exclusivement mettre en oeuvre via des programmes (en anglais, to implement) des transferts de données à large bande passante. Avec UDP, [NdT: UDP ne garantit pas la bonne réception des données, ni le contrôle de la séquence des paquets. Il n'apporte pas de fonctionnalités supplémentaires à IP mais permet de désigner les numéros de port correspondant aux applications avec des temps de réponses courts], l'utilitaire client envoie et reçoit des paquets individuels qui sont encapsulés dans IP. Les ports sont utilisés de la même manière qu'avec TCP, mais ceux-ci ne sont que des identificateurs. Par conséquent, la notion de flux n'existe pas avec UDP. L'en-tête complet UDP/IP est donnée dans le tableau 17.
Octets (IP) | Description |
---|---|
0 | Bits 0-3: Version, bits 4-7: Internet Header Length (IHL) |
1 | Type de Service (TOS) |
2-3 | Longueur |
4-5 | Identification |
6-7 | Bits 0-3: Indicateurs (flags), bits 4-15: décalage ou offset |
8 | Temps de vie (Time To Live ou TTL) |
9 | Type |
10-11 | Somme de contrôle (checksum) |
12-15 | Adresses IP source |
16-19 | Adresses IP de destination |
20-(IHL *4 - 1) | Options + remplissage pour grouper jusqu'à 4 octets |
Octets (UDP) | Description |
0-1 | Port source |
2-3 | Port destination |
4-5 | Longueur |
6-7 | Somme de contrôle (checksum) |
Les données UDP commencent à IHL * 4 + 8 et finissent à Length -1 |