Entête UDP

Entête UDP

1 – Définition du protocole UDP

Le protocole UDP est basé en couche 4 du modèle OSI. Il n’ouvre pas de session et n’effectue pas de control d’erreur. Il est alors appelé  « mode non connecté ». Il est donc peu fiable, cependant, il permet aux applications d’accéder directement à un service de transmission de Datagrammes rapide. 

UDP est utilisé pour transmettre de faibles quantités de données où le coût de la création de connexions et du maintient de transmissions fiables s’avèrent supérieur aux données à émettre. UDP peut également être utilisé pour les applications satisfaisant à un modèle de type « interrogation réponse ». La réponse étant utilisée comme un accusé de réception à l’interrogation. On y trouve classiquement les protocoles SNMP et DNS. UDP est aussi utilisé dans un second cas, tel que la voix sur IP.  L’envoi en temps réel est primordiale, donc si une trame n’arrivait pas, la retransmission serait inutile

Vous trouverez tous les détails du protocole UDP dans la RFC 768.

2 – Structure de l’entête UDP

Voici la structure de l’entête UDP basé sur 8 octets.

entete-udp entete udp

3 – Définition des différents champs

3.1 – Port source UDP

Le champ Port source est codé sur 16 bits et correspond au port relatif à l’application en cours sur la machine source.

3.2 – Port destination UDP

Le champ Port destination est codé sur 16 bits et il correspond au port relatif à l’application en cours sur la machine de destination.

Vous trouverez la liste des ports TCP officialisées par l’IANA, organisation gérant mondialement les adressage IP.

3.3 – Longueur

Le champ Longueur est codé sur 16 bits et il représente la taille de l’entête et des données. Son unité est l’octet et sa valeur maximale est 64 Koctets (216).

3.4 – Checksum

Le champ Checksum est codé sur 16 bits et représente la validité du paquet de la couche 4. 

Le Checksum est constitué en calculant le complément à 1 sur 16 bits de la somme des compléments à 1 des octets de l’entête et des données pris deux par deux (mots de 16 bits). Si le message entier contient un nombre impair d’octets, un 0 est ajouté à la fin du message pour terminer le calcul du Checksum. Cet octet supplémentaire n’est pas transmis. Lors du calcul du Checksum, les positions des bits attribués à celui-ci sont marquées à 0.

Le Checksum couvre de plus, une pseudo entête de 96 bits préfixée à l’entête UDP. Cette pseudo entête comporte les adresses Internet source et destinataires, le type de protocole et la longueur du message UDP. Ceci protège UDP contre les erreurs de routage.

entete-udp entete udp pseudo

La longueur compte le nombre d’octets de l’entête UDP et des données du message, en excluant les 12 octets de la pseudo entête. 

Voici un exemple de fonction permettant le calcul du checksum UDP. Elle est identique à celle de TCP.

struct pseudo_entete
     {
     unsigned long ip_source; // Adresse ip source
     unsigned long ip_destination; // Adresse ip destination
     char mbz; // Champs à 0
     char type; // Type de protocole (6->TCP et 17->le mode non connecte)
     unsigned short length; // htons( Entete TCP ou non connecte + Data )
     };
 
 unsigned short calcul_du_checksum(bool liberation, unsigned short *data, int taille)
     {
     unsigned long checksum=0;
     // ********************************************************
     // Complément à 1 de la somme des complément à 1 sur 16 bits
     // ********************************************************
     while(taille>1)
         {
         if (liberation==TRUE)
             liberation_du_jeton(); // Rend la main à la fenêtre principale
         checksum=checksum+*data++;
         taille=taille-sizeof(unsigned short);
         }
 
     if(taille)
         checksum=checksum+*(unsigned char*)data;
 
     checksum=(checksum>>16)+(checksum&0xffff);
     checksum=checksum+(checksum>>16);
 
     return (unsigned short)(~checksum);
     }
 
 unsigned short calcul_du_checksum(bool liberation, unsigned long ip_source_tampon, unsigned long ip_destination_tampon, struct entete tampon, char data_tampon[65535])
     {
     struct pseudo_entete pseudo;
     char tampon[65535];
     unsigned short checksum;
 
     // ********************************************************
     // Initialisation du checksum
     // ********************************************************
     tampon.checksum=0; // Doit être à 0 pour le calcul
 
     // ********************************************************
     // Le calcul du Checksum (Idem à TCP)
     // ********************************************************
     // Le calcul passe par une pseudo entete + l'entete + les Data
     pseudo.ip_source=ip_source_tampon;
     pseudo.ip_destination=ip_destination_tampon;
     pseudo.mbz=0;
     pseudo.type=17;
     pseudo.length=htons((unsigned short)(sizeof(struct entete)+(unsigned short)strlen(data_tampon)));
     memcpy(tampon,&pseudo,sizeof(pseudo));
     memcpy(tampon+sizeof(pseudo),&tampon,sizeof(struct entete));
     memcpy(tampon+sizeof(pseudo)+sizeof(struct entete),data_tampon,strlen(data_tampon));
     checksum=calcul_du_checksum(liberation,(unsigned short*)tampon,sizeof(pseudo)+sizeof(struct entete)+strlen(data_tampon));
  
     return(checksum);
     }

4 – Les vidéos

  • 4.1 - What is QUIC ? Vidéo en Anglais

    Among the many problems with TCP is that the approach to reliably delivering data between machines is one-size-fits-all. But not every connection has the same needs, and some have extra information that can be used to improve reliable transport. Partly to enable innovation and customization at the transport layer (and partly to address well-understood problems with TPC), Google has created and is rolling out QUIC: Quick UDP Internet Connection. QUIC enables secure connections to be established using fewer round-trips, reducing connection latency—​particularly when reconnecting to servers that have been used before. QUIC is also designed to fetch all of the multiple resources typically needed to render a web page using a single connection while avoiding the head-of-the-line that TCP would cause.

  • 4.2 - UDP and ICMP with Wireshark Vidéo en Anglais

    Cette video en anglais vous présente les protocoles UDP (User Datagram Protocol) et ICMP (Internet Control Message Protocol) dans Wireshark. UDP stands for User Datagram Protocol. This is another layer 4 protocol, commonly called a 'connectionless protocol', that is used on lots of modern networks to make the transmission of data fast! The weird thing about UDP is it doesn't have a start handshake and a cutoff process like with TCP. Since UDP doesn't have the whole packet handshake that TCP does, you'd think that it wouldn't work right, but it actually HELPS other protocols streamline data in a fast pace. A UDP header packet is super small and only has four parts. First you have the Bit Offset, the source port / destination port, the packet length, and the checksum.. The source and destination are self-explanatory. The packet length is in bytes and the checksum ensures the data is intact when it arrives. Next we have ICMP. This stands for the Internet Control Message Protocol. This protocol works with TCP/IP, and tells you if a device, service or route is available on a TCP/IP network. ICMP packet headers have a Type, a Code, a Checksum, and a Variable. The Type is the type of ICMP message based on RFC code. The Code is the subclass of ICMP message, also part of the RFC code. Checksum makes sure the content is intact, and Variable is a bit that changes depending on the type and code. This IANA website shows you all the known types and codes you might run into when dealing with an ICMP packet. If there is a problem with a connection, it may have to do with this packet. Using the Type and the Code, you can determine what went wrong and where. I also wanted to mention a bit about why ICMP exists for other reasons. First, it's great for the ping utility. In command prompt, type ping 10.71.31.1 (your target) to see an echo/ping request and response. You can also see what happens when you run Ping and check it in Wireshark. ICMP packets are also a part of trace routing. Trace routing is when you ID the path that some data takes from one device to another. It'll tell you how many routers it had to go through to get to it's destination. If you find an ICMP packet that has a TTL value is set to 1 (that's time to live), that means it only had to travel through one router. In a traceroute, the packet will return to the original source with a type of 11 and a code of 0. This means the destination was unreachable due to the TTL being exceeded during transit. You might find some people call this a double-headed packet because there is an extra IP header inside it. This data is from the original echo request. You'll see this pattern continue until the destination host is reached by the packet. The route can also be seen in CMD with tracert 8.8.8.8. Let me know what you think. Send me a comment below or email us at tips@hak5.org. And be sure to check out our sister show, Hak5,org for more great stuff just like this. I'll be there, reminding you to trust your technolust.

    UDP and ICMP with Wireshark

  • 4.3 - Choose the unreliable UDP protocol over TCP ? Vidéo en Anglais

    Cette video en anglais vous présente pourquoi choisir le protocole UDP (User Datagram Protocol). Compared to TCP, UDP seems less useful. It drops packets and provides no guidance on how fast packets should be sent. But there are some very important internet applications that can benefit from unreliable packet delivery and sometimes suffer due to TCP’s guarantees. Typical to the design of the rest of the internet, the overall goal is flexibility. UDP allows applications that do not need TCP’s guarantees to avoid them.

    Choose the unreliable UDP protocol over TCP ?

  • 4.4 - What is the universal UDP protocol Vidéo en Anglais

    Cette video en anglais vous présente le protocole UDP (User Datagram Protocol). The transmission control protocol (TCP) creates reliable and fair connections between multiple computers on the internet. It is the most widely-used internet transport protocol-​at least for now. But there is another widely-deployed transport protocol called the universal datagram protocol, or UDP. Unlike TCP, UDP provides no reliability. And unlike TCP, UDP provides no flow control or fairness. It does preserve port numbers similar to TCP, although UDP does not establish a connection between multiple computers. While UDP may seem to jettison several useful features of TCP, the fact that it exists and many internet-connected computers support it is enabling important innovation at the transport layer.

    What is the universal UDP protocol

  • 4.5 - UDP headers Vidéo en Anglais

    Cette video en anglais vous présente les entêtes du protocole UDP (User Datagram Protocol).

    UDP headers

  • 4.6 - UDP Programming in C Vidéo en Anglais

    Cette video en anglais vous présente comment gérer en C les sockets en mode non connecté UDP (User Datagram Protocol).

    UDP Programming in C

  • 4.7 - UDP and TCP: Comparison of Transport Protocols Vidéo en Anglais

    Video en anglais présentant, avec de beaux slides, la comparaison entre les protocoles TCP et UDP.

    UDP and TCP: Comparison of Transport Protocols

  • 4.8 - UDP, TCP, IP and Ethernet Header Vidéo en Anglais

    Video en anglais présentant en détail l'ensemble des champs des entêtes UDP, TCP, IP et Ethernet.

    UDP, TCP, IP and Ethernet Header

  • 4.9 - Cours réseaux sur TCP, UDP via netstat Vidéo en Français

    A l'aide de la commande netstat, voici une video claire expliquant la différence entre TCP et UDP.

    Cours réseaux sur TCP, UDP via netstat

5 – Suivi du document

Création et suivi de la documentation par _SebF

Modification de la documentation par _SebF

  • Ajout du schéma de la pseudo entête.

6 – Discussion autour de l’entête UDP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de l’entête UDP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :

Commentaire et discussion

4 commentaires sur la page : “Entête UDP”

  1. Bonjour,

    Il me semble qu’il y a une contradiction, pour le calcul du checksum, pour la valeur de la longueur :

    – dans le texte, vous dites « La longueur compte le nombre d’octets de l’entête UDP et des données du message, en excluant les 12 octets de la pseudo entête » ;

    – dans le code d’exemple de calcul, le commentaire pour le champ longueur indique que sa valeur tient compte aussi de la longueur du pseudo-entête : « unsigned short length; // htons( Taille de l’entete Pseudo + Entete TCP ou non connecte + Data ) », ce qui est d’ailleurs fait lors de l’appel à la fonction calcul-du_checksum().


    Merci pour votre site qui me permet de réviser et approfondir des notions toutes fraiches pour moi…

    1. Lu Hérvé,

      Je viens de relire et je pense que l’erreur est présente dans le commentaire du code C. En claire, le calcul doit bien ne pas inclure les 12 octets de la pseudo entête.
      On peut le voir un peut plus bas dans le code :
      pseudo.length=htons((unsigned short)(sizeof(struct entete)+(unsigned short)strlen(data_tampon)));

      @+
      Sebastien FONTAINE

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *