Unité de transmission maximale (MTU)

Unité de transmission maximale (MTU)

Dans les réseaux informatiques, le terme Maximum Transmission Unit (MTU) fait référence à la taille (en octets) de la plus grande PDU qu'une couche donnée d'un protocole de communication peut transmettre. Les paramètres MTU apparaissent généralement en association avec une interface de communication (NIC, port série, etc.). La MTU peut être fixée par des normes (comme c'est le cas avec Ethernet) ou décidée au moment de la connexion (comme c'est généralement le cas avec les liaisons série point à point). Un MTU plus élevé apporte une plus grande efficacité car chaque paquet transporte plus de données utilisateur tandis que les frais généraux de protocole, tels que les en-têtes ou les retards sous-jacents par paquet restent fixes, et une efficacité plus élevée signifie une légère amélioration du débit de protocole en masse. Cependant, les paquets volumineux peuvent occuper une liaison lente pendant un certain temps, entraînant des retards plus importants pour les paquets suivants et augmentant le décalage et la latence minimale. Par exemple, un paquet de 1500 14.4 octets, le plus grand autorisé par Ethernet au niveau de la couche réseau (et donc la plupart de l'Internet), lierait un modem XNUMX k pendant environ une seconde.

Découverte du chemin MTU
Le protocole Internet définit le « chemin MTU » d'un chemin de transmission Internet comme le plus petit MTU de l'un des sauts IP du « chemin » entre une source et une destination. En d'autres termes, le chemin MTU est la plus grande taille de paquet qui traverse ce chemin sans subir de fragmentation.

La RFC 1191 décrit la « découverte du chemin MTU », une technique permettant de déterminer le chemin MTU entre deux hôtes IP. Cela fonctionne en définissant l'option DF (Don't Fragment) dans les en-têtes IP des paquets sortants. Tout périphérique le long du chemin dont la MTU est plus petite que le paquet supprimera ces paquets et renverra un message ICMP « Destination inaccessible (datagramme trop gros) » contenant sa MTU, permettant à l'hôte source de réduire la MTU de son chemin supposé de manière appropriée. Le processus se répète jusqu'à ce que la MTU soit suffisamment petite pour parcourir l'intégralité du chemin sans fragmentation.

Malheureusement, un nombre croissant de réseaux abandonnent le trafic ICMP (par exemple pour empêcher les attaques par déni de service), ce qui empêche la découverte de chemin MTU de fonctionner. On détecte souvent un tel blocage dans les cas où une connexion fonctionne pour des données de faible volume mais se bloque dès qu'un hôte envoie un gros bloc de données à la fois. Par exemple, avec IRC, un client connecté peut voir jusqu'au message ping, mais n'obtenir aucune réponse après cela. C'est parce que le grand ensemble de messages de bienvenue est envoyé dans des paquets plus gros que le vrai MTU. De plus, dans un réseau IP, le chemin de l'adresse source à l'adresse de destination est souvent modifié dynamiquement, en réponse à divers événements (équilibrage de charge, congestion, sorties, etc.) - cela peut entraîner un changement de la MTU du chemin (parfois répété) au cours d'une transmission, ce qui peut introduire d'autres pertes de paquets avant que l'hôte ne trouve la nouvelle MTU sûre.

La plupart des réseaux locaux Ethernet utilisent un MTU de 1500 9000 octets (les réseaux locaux modernes peuvent utiliser des trames Jumbo, ce qui permet un MTU allant jusqu'à XNUMX XNUMX octets), mais les protocoles de bordure comme PPPoE réduiront cela. Cela entraîne l'entrée en vigueur de la découverte de la MTU du chemin avec le résultat possible de rendre inaccessibles certains sites derrière des pare-feu mal configurés. On peut éventuellement contourner cela, selon la partie du réseau que l'on contrôle ; par exemple, on peut changer la MSS (taille maximale de segment) dans le paquet initial qui établit la connexion TCP sur son pare-feu.

Ce problème est apparu plus fréquemment depuis l'introduction de Windows Vista qui introduit la « pile TCP/IP de nouvelle génération ». Cela implémente « le réglage automatique de la fenêtre de réception qui détermine en permanence la taille optimale de la fenêtre de réception en mesurant le produit de délai de bande passante et le taux de récupération de l'application, et ajuste la taille maximale de la fenêtre de réception en fonction des conditions changeantes du réseau. »[2] Cela a échoué en conjonction avec des routeurs et des pare-feu plus anciens qui semblaient fonctionner avec d'autres systèmes d'exploitation. Il est le plus souvent observé dans les routeurs ADSL et peut souvent être rectifié par une mise à jour du firmware.

Backbones ATM, un exemple de réglage MTU
Parfois, il est préférable du point de vue de l'efficacité de déclarer artificiellement une MTU réduite dans le logiciel en dessous de la vraie longueur maximale possible prise en charge. Un exemple de ceci est le cas où le trafic IP est transporté sur un réseau ATM (mode de transfert asynchrone). Certains fournisseurs, en particulier ceux ayant une formation en téléphonie, utilisent l'ATM sur leur réseau fédérateur interne.

L'utilisation de l'ATM avec une efficacité optimale est obtenue lorsque la longueur du paquet est un multiple de 48 octets. En effet, l'ATM est envoyé sous forme de flux de paquets de longueur fixe (appelés « cellules »), dont chacun peut transporter une charge utile de 48 octets de données utilisateur avec 5 octets de surcharge pour un coût total de 53 octets par cellule. Ainsi, la longueur totale de la longueur des données transmises est de 53 * ncells octets, où ncells = le nombre de cellules requises de = INT((payload_length+47)/48). Ainsi, dans le pire des cas, où la longueur totale = (48*n+1) octets, une cellule supplémentaire est nécessaire pour transmettre le dernier octet de charge utile, la cellule finale coûtant 53 octets transmis supplémentaires dont 47 de remplissage. Pour cette raison, déclarer artificiellement une MTU réduite dans le logiciel maximise l'efficacité du protocole au niveau de la couche ATM en faisant en sorte que la longueur totale de la charge utile ATM AAL5 soit un multiple de 48 octets chaque fois que possible.

Par exemple, 31 cellules ATM complètement remplies transportent une charge utile de 31*48=1488 octets. En prenant ce chiffre de 1488 et en en soustrayant tous les frais généraux contribués par tous les protocoles supérieurs pertinents, nous pouvons obtenir une valeur suggérée pour une MTU artificiellement réduite de manière optimale. Dans le cas où l'utilisateur enverrait normalement des paquets de 1500 octets, l'envoi entre 1489 et 1536 octets nécessite un coût fixe supplémentaire de 53 octets transmis, sous la forme d'une cellule ATM supplémentaire.

Pour l'exemple des connexions IP sur DSL utilisant PPPoA/VC-MUX, en choisissant à nouveau de remplir 31 cellules ATM comme auparavant, nous obtenons un chiffre MTU réduit de manière optimale souhaité de 1478 = 31*48-10 en tenant compte d'un surdébit de 10 octets consistant en d'un surcoût de protocole point à point de 2 octets et d'un surcoût AAL5 de 8 octets. Cela donne un coût total de 31*53 = 1643 octets transmis via ATM à partir d'un paquet de 1478 octets transmis à PPPoA. Dans le cas de l'IP envoyé sur ADSL en utilisant PPPoA, le chiffre de 1478 serait la longueur totale du paquet IP, y compris les en-têtes IP. Ainsi, dans cet exemple, conserver une MTU réduite auto-imposée de 1478 par opposition à l'envoi de paquets IP d'une longueur totale de 1500 économise 53 octets par paquet au niveau de la couche ATM au prix d'une réduction de 22 octets de la longueur des paquets IP.

Un MTU maximum pour les connexions PPPoE/DSL est de 1492, par RFC 2516 : 6 octets étant l'en-tête PPPoE, laissant suffisamment de place pour une charge utile de 1488 octets, ou 31 cellules ATM complètes.

Enfin: La valeur standard de MTU doit être 1492.... et en cas de problèmes de navigation ou de problèmes de connectivité MSN, il doit être diminué aux valeurs 1422 et 1420.

Référence: Wikipédia

Meilleures salutations