====== 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 [[http://www.ntp.org| 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.