Mode non connecté

Protocole UDP

User Datagram Protocol. Ici, la discussion se fait sans trop de précautions. Le principe est le suivant:

Celui qui doit parler s'adresse à son interlocuteur, la plupart du temps en posant une question, directement, sans vérifier que l'interlocuteur est présent et peut répondre.
Si la réponse ne vient pas, l'initiateur décidera de la stratégie à appliquer. En général, il n'y a pas trop de solutions:
- Répéter la question au même interlocuteur
- Répéter la question à un autre interlocuteur (C'est le cas par exemple des résolutions de noms)
- Abandonner et arrêter le dialogue.

Parmi les usages les plus connus du mode sans connexion (UDP), notons:

La résolution des noms ou la résolution inverse des adresses (DNS)
La recherche d'une adresse IP dynamique (DHCP)
La plupart des jeux en réseau.

En général, partout où le paquet de données à transmettre peut tenir dans un seul datagramme.

A titre d'exemple, nous allons regarder ça sur quelque chose de nouveau: le protocole NTP (Network Time Protocol). C'est un protocole applicatif qui permet à un hôte de synchroniser son horloge sur un serveur de temps.

L'exemple est pris sous linux par la commande:

#ntpdate ntp0.oleane.net

Comme d'habitude, le sniffer ne perd rien de la conversation…

No. Source           Destination      Protocol Info
16  193.248.36.34    ntp0.oleane.net  NTP      NTP
17  ntp0.oleane.net  193.248.36.34    NTP      NTP
18  193.248.36.34    ntp0.oleane.net  NTP      NTP
19  ntp0.oleane.net  193.248.36.34    NTP      NTP
20  193.248.36.34    ntp0.oleane.net  NTP      NTP
21  ntp0.oleane.net  193.248.36.34    NTP      NTP
22  193.248.36.34    ntp0.oleane.net  NTP      NTP
23  ntp0.oleane.net  193.248.36.34    NTP      NTP

A première vue, nous constatons un dialogue entre le client (193.248.36.34) et le serveur ntp0.oleane.net.

L'objectif est ici, non pas de décortiquer le protocole NTP, encore que ce ne soit pas sans intérêt, mais d'observer un dialogue UDP. Voyons donc le détail:

Le surlignage jaune représente le protocole, la source et la destination, le sur lignage « bleu » représente les données transmises, dans l'organisation décrite par le protocole NTP

Frame 16 (86 on wire, 86 captured)
    ...
    Protocol: UDP (0x11)
    Header checksum: 0x40a6 (correct)
    Source: Mix-Marseille-107-1-34.abo.wanadoo.fr (193.248.36.34)
    Destination: ntp0.oleane.net (194.2.0.28)
User Datagram Protocol
    Source port: ntp (123)
    Destination port: ntp (123)
    Length: 56
    Checksum: 0x5b48
Network Time Protocol
    Flags: DB
        11.. .... = Leap Indicator: alarm condition (clock not synchronized)
        ..01 1... = Version number: NTP Version 3
        .... .011 = Mode: client
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Pooling Interval: 4 (16 sec)
    Peer Clock Precision: 0,015625 sec
    Root Delay:    1,0000 sec
    Clock Dispersion:    1,0000 sec
    Reference Clock ID: Unindentified reference source ''
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: 2001-06-13 12:36:30,1227 UTC

Frame 17 (76 on wire, 76 captured)
    ...
    Protocol: UDP (0x11)
    Header checksum: 0xa111 (correct)
    Source: ntp0.oleane.net (194.2.0.28)
    Destination: Mix-Marseille-107-1-34.abo.wanadoo.fr (193.248.36.34)
User Datagram Protocol
    Source port: ntp (123)
    Destination port: ntp (123)
    Length: 56
    Checksum: 0xa367
Network Time Protocol
    Flags: 1C
        00.. .... = Leap Indicator: no warning
        ..01 1... = Version number: NTP Version 3
        .... .100 = Mode: server
    Peer Clock Stratum: secondary reference (2)
    Peer Pooling Interval: 4 (16 sec)
    Peer Clock Precision: 0,000004 sec
    Root Delay:    0,0130 sec
    Clock Dispersion:    0,1491 sec
    Reference Clock ID: 49.110.238.145
    Reference Clock Update Time: 2001-06-13 12:33:43,8840 UTC
    Originate Time Stamp: 2001-06-13 12:36:30,1227 UTC
    Receive Time Stamp: 2001-06-13 12:35:18,4244 UTC
    Transmit Time Stamp: 2001-06-13 12:35:18,4246 UTC

Frame 18 (86 on wire, 86 captured)
    ...
    Protocol: UDP (0x11)
    Header checksum: 0x40a5 (correct)
    Source: Mix-Marseille-107-1-34.abo.wanadoo.fr (193.248.36.34)
    Destination: ntp0.oleane.net (194.2.0.28)
User Datagram Protocol
    Source port: ntp (123)
    Destination port: ntp (123)
    Length: 56
    Checksum: 0x5a96
Network Time Protocol
    Flags: DB
        11.. .... = Leap Indicator: alarm condition (clock not synchronized)
        ..01 1... = Version number: NTP Version 3
        .... .011 = Mode: client
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Pooling Interval: 4 (16 sec)
    Peer Clock Precision: 0,015625 sec
    Root Delay:    1,0000 sec
    Clock Dispersion:    1,0000 sec
    Reference Clock ID: Unindentified reference source ''
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: 2001-06-13 12:36:30,1879 UTC

Frame 19 (76 on wire, 76 captured)
    ...
    Protocol: UDP (0x11)
    Header checksum: 0xa10d (correct)
    Source: ntp0.oleane.net (194.2.0.28)
    Destination: Mix-Marseille-107-1-34.abo.wanadoo.fr (193.248.36.34)
User Datagram Protocol
    Source port: ntp (123)
    Destination port: ntp (123)
    Length: 56
    Checksum: 0x66a1
Network Time Protocol
    Flags: 1C
        00.. .... = Leap Indicator: no warning
        ..01 1... = Version number: NTP Version 3
        .... .100 = Mode: server
    Peer Clock Stratum: secondary reference (2)
    Peer Pooling Interval: 4 (16 sec)
    Peer Clock Precision: 0,000004 sec
    Root Delay:    0,0130 sec
    Clock Dispersion:    0,1491 sec
    Reference Clock ID: 49.110.238.145
    Reference Clock Update Time: 2001-06-13 12:33:43,8840 UTC
    Originate Time Stamp: 2001-06-13 12:36:30,1879 UTC
    Receive Time Stamp: 2001-06-13 12:35:18,5105 UTC
    Transmit Time Stamp: 2001-06-13 12:35:18,5106 UTC

Etc…

Ce n'est pas nécessaire de voir la suite pour montrer ce qui est important ici. Contrairement à ce qui a été vu en mode connecté avec TCP:

Toute la partie « synchronisation » entre l'hôte et le client n'existe pas ici.
Le client pose tout de suite sa « question“, en fait, ce n'est pas vraiment une question, le client se contente de dire:
alarm condition (clock not synchronized)
Suivi de quelques indicateurs nuls et de la date UTC dont il dispose.
Le serveur répond simplement en envoyant son heure UTC et quelques autres paramètres destinés à informer sur la précision de la date qu'il donne.
Ce dialogue va s'arrêter lorsque le client estimera qu'il dispose de toutes les informations nécessaires pour synchroniser son horloge dans de bonnes conditions. (Je vous laisse étudier le protocole NTP en détail, si ça vous intéresse).
Notez que le dialogue s'arrête sans signalisation particulière, ce qui n'est pas le cas en mode connecté où le signal FIN doit être envoyé et confirmé.
Notez également que les informations à transmettre sont entièrement contenues dans un seul datagramme. Dans un tel cas, le protocole UDP est tout à fait acceptable et plus léger que le mode connecté.

Vous pouvez trouver d'autres exemples de dialogue UDP dans les paragraphes DNS et DHCP sur ce site.