FAQ R�seauxConsultez toutes les FAQ

TCP et UDP sont les deux principaux protocoles pour le transport de donn�es sur les r�seaux. Il en existe d'autres mais ils sont plut�t orient�s vers le contr�le que le transport de donn�es.

TCP est un protocole connect� et synchronis�. Il n�cessite la mise en �uvre d'une connexion entre les deux interlocuteurs, puis un protocole d'�change et d�acquittement durant tout l'�change et enfin la fermeture de la connexion. On peut le comparer � une conversation t�l�phonique, o� il faut d'abords appeler son correspondant, dialoguer, puis mettre fin � la conversation.

UDP est tout le contraire. C'est un protocole non connect�. Il n'y a pas de synchronisation des �changes. Un paquet envoy� sur le r�seau par UDP est envoy� � l'aveugle, peu importe si le destinataire existe ou pas, peu importe s'il est pr�t � recevoir ou pas, peu importe s'il sera capable de r�pondre ou pas. On pourrait comparer UDP � un orateur devant une foule.

TCP garanti l'�change des donn�es. Il garantit que les deux interlocuteurs sont pr�ts � s'�changer des donn�es, il garantit que les donn�es �chang�es sont correctement re�ues de part et d'autre. Par contre, il ne peut garantir ni le d�lai de r�ception des donn�es, ni l'ordre de r�ception (un paquet mal re�u sera de nouveau demand� et r��mis et ce, m�me si des paquets post�rieurs ont d�j� �t� re�us correctement).
TCP est relativement lourd.

UDP est par contre beaucoup plus l�ger, mais il ne garantit absolument rien. Ne s'assurant ni de la disponibilit� du destinataire ni de la r�ception r�elle des donn�es, envoyant celles-ci en aveugle, UDP est utile par exemple lorsque le destinataire n'est pas connu (requ�te DHCP par exemple), n'est pas directement identifiable (broadcast). Il peut aussi �tre utilis� lorsqu'il est n�cessaire d'envoyer un flux important de donn�es, o� la perte d'un paquet n'est pas probl�matique, mais o�, par contre, l'ordre de r�ception devient important, ou un d�bit �lev� est � assurer et ou une synchronisation deviendra trop lourde. C'est le cas notamment en streaming audio/vid�o, pour la voip, diffusion pseudo temps-r�el comme la vision-conf�rence, etc.
A noter que UDP ne garantit pas ni l'ordre, ni les d�lais de r�ception, mais �tant nettement plus l�ger, il est moins p�nalisant pour le respect de ces points

Pour r�sumer :

• TCP : lorsque l'arriv�e r�elle et correcte des donn�es est importante et doit �tre contr�l�e.
• UDP : lorsque la perte d'un ou plusieurs paquets n'est pas probl�matique au regard des autres aspects.

Les Jumbo Frame sont des paquets dont la taille en octets n'est pas ordinaire. En effet, sur le r�seau Ethernet (sp�cification IEEE 802.3), les paquets ont une taille maximale de 1500 octets (limite appel�e MTU : Maximum Transmission Unit). Toutefois, si vous souhaitez transmettre de grandes quantit�s de donn�es, cela oblige les syst�mes � d�couper les paquets et � traiter les ent�tes (les remplir lors d'une �mission et les lire lors d'une r�ception). Cela ajoute un surco�t, que ce soit en termes d'utilisation de la bande passante, mais aussi en ressources CPU. Par cons�quent, il est devenu int�ressant d'augmenter la quantit� de donn�es utiles transport�es.
Ainsi, certains �quipements r�seau supportent les Jumbo Frame (c'est-�-dire, des paquets dont la taille d�passe 1500 octets, le plus souvent 9000 octets), permettant � l'administrateur de reconfigurer la MTU dans le but de transporter plus de donn�es dans chaque paquet. �videmment, le support des Jumbo Frame doit �tre disponible sur les deux �quipements reli�s et la MTU d�finie doit �tre identique.

En r�alit�, le gain n'est pas tant dans la bande passante lib�r�e (environ 200 Mo pour 10 Go, pour un transfert TCP), mais plus dans la lib�ration des ressources CPU en charge de traiter les paquets.

L'Audio Video Briding (AVB) est un ensemble de sp�cifications d�finies par l'IEEE dont le but est de r�duire la latence et d'assurer la synchronisation des �quipements r�seau. L'objectif est d'am�liorer la fiabilit� du r�seau afin que ce dernier puisse �tre utilis� dans le secteur de l'automobile ou parmi les professionnels de l'audio et de la vid�o. En effet, dans ce contexte, la latence a un impact non n�gligeable, de m�me que pour la synchronisation du r�seau, notamment dans le cadre d'un travail de synchronisation de la bande-son avec l'image.
AVB regroupe les sp�cifications suivantes :

IEEE 802.1AS-2011 : synchronisation pour les applications sensibles au temps ;
IEEE 802.1Qav-2009 : transfert et mise en queue de flux sensibles au temps ;
IEEE 802.1Qat-2010 : protocole de r�servation de flux ;
IEEE 802.1BA-20011 : syst�mes AVB ;
IEEE-1722-2011 : protocole de transport pour les applications sensibles au temps ;
IEEE 1722.1-2013 : protocole de contr�le, de gestion de connexion, d'�num�ration et de d�couverte (AVDECC).

La sp�cification 802.1Q ajoute des donn�es � un paquet Ethernet afin d'identifier les r�seaux virtuels. Plus pr�cis�ment, quatre octets sont ajout�s entre l'adresse MAC de la source et le champ identifiant le protocole encapsul� (EtherType). Ces octets contiennent :

un tag sur 16 bits, permettant d'identifier que le paquet contient les informations d�finies par la norme 802.1Q. Ce champ vaut 0x8100 ;
trois bits permettant d'identifier la classe de service en vue d'une priorisation ;
un bit indiquant si le paquet peut �tre ignor� en cas de congestion ;
12 bits identifiant � quel r�seau virtuel le paquet appartient.

Il est � noter que comme ces informations sont trait�es par les �quipements r�seau eux-m�mes, ces donn�es ne sont pas visibles en cas de capture � la sortie d'un switch.

Certains switchs proposent une fonctionnalit� nomm�e � clonage de port � (port mirroring). Cette fonctionnalit� permet de configurer le switch afin que celui-ci copie tous les paquets transitant par un port (ou par un VLAN) vers un autre port. Cela peut �tre utile dans des cas de diagnostic ou d'analyse du trafic r�seau.