Le Mon, 10 May 2004 04:01:47 +0200
[EMAIL PROTECTED] a écrit :

> Bonjour,
> 
> le MTU : maximum transfert unit, soit la taille maximum de chaque paquet IP 
> (en 
> octet) transmis au niveau ethernet
> 

une trame ethernet par défaut fait 1514 octets dont 14 octets pour l'en tête 
ethernet 
ce qui laisse 1500 octets pour les données. 1500 est donc la taille maximale 
que peut
prendre le paquet provenant de la couche IP.
un paquet IP arrivant dans la pile IP depuis l'application peut faire jusqu'à 
64Ko mais
 il sera fragementé en plusieurs paquets qui entrent dans la MTU de la trame la 
contenant.
Dans le cas d'ethernet c'est 1500. 
En pratique il vaut mieux que la pile IP utiliser un MTU correct, tout d'abord 
vis à vis
de l'interface qu'elle utilise mais en fait vis a vis de toutes les interfaces 
que le
paquet va ête amené à traverser de routeur en routeur. Si un routeur reçoit un 
paquet IP
trop grand par rapport à son interface il vérifie tout d'abord s'il a le droit 
de le fragmenter
( le Don't fragment bit ne doit pas être mis ) si c'est le cas le paquet est 
coupé en autant
de nouveaux paquest chacun contenant une en tête IP et une indication pour 
savoir à quel
partie du paquet original il appartient.
un paquet fragmenté par un routeur ne sera réassemblé que par la pile ip de 
reception finale,
de plus il faudra que cette même pile récupère tous les fragments avant de 
pouvoir donner à
la couche du dessus ces informations. Si un seul fragment d'un paquet paquet 
est perdu ( disons 
un paquet IP de 21 octets ne contenant qu'un octet TCP ) c'est tout le paquet 
de MTU octets 
qui sera réémis ( les 1500 octets ).
La fragmentation doit toujours être évitée, en particulier parce qu'elle n'est 
pas bien gérée
par les routeurs engorgés et qu'elle crée un travail supplémentaire qui est 
inutile si la MTU
a bien été fixée entre les deux terminaisons de connections.
La fragmentation au niveau IPv4 a été très discutée et pour IPv6 par exemple il 
a été décidé 
de ne plus la supporter mais que les les paquets envoyés devaient toujours 
utiliser des tailles
infèrieures ou égale à la plus petite taille de paquet sur le chemin du paquet, 
il a été mis
en place un système de découverte de la plus grande taille de paquet possible 
sur un chemin.

> le MRU : maximum receipt unit ?
C'est le MTU vu au niveau de la reception du paquet.

> 
> le MSS : Maximum Segment Size, Taille Maximum du Segment (c'est quoi un 

Quand tout se passe bien un paquet TCP est encapsulé dans un paquet IP qui
lui même est encaplusé dans:
- soit un paquet ethernet 
- soit une trame PPP qui elle même peut être encapsulée dans TCP (PPTP) ou 
ethernet (PPPoe)

Un paquet TCP SYN est le premier paquet envoyé par TCP pour établir une 
connection TCP. L'option MSS lui permet d'indiquer à l'application receptrice
quelle taille les données TCP pourront faire au maximum pour ne pas provoquer
de fragementation du paquet IP en chemin.
Puisque MSS identifie la taille des données tcp il faut faire une conversion
pour la faire correspondre au MTU
[en tete ethernet]<données ethernet max MTU octets                         >
                  [en tete ip]<données ip max (MTU - taille en tete ip)    >
                              [en tete tcp]<données tcp max MSS            >

on voit donc que MSS = MTU - (taille en tete ip + taille en tete tcp).
en pratique les ent têtes ip et tcp sans options font chacun 20 octets.
On obtient donc MSS = MTU-40.


> 
> Certains disent qu'il vaut mieux réduire la taille des paquets d'octets.

En pratique pour un lien PPPoe il faut fixer sa MTU à 1492 'ifconfig mtu ...').

> D'autres pensent qu'il est préférable d'avoir la taille maximum en octet dans 
> Enfin, faut il priviligier la configuration du MTU ou du MSS pour avoir un 
>...
> débit internet optimal ?

Le MTU doit être fixé en premier lieu.
L'utilisation du mss est un hack pour forcer l'hôte distant à utiliser sur le
chemin du retour des tailles sympathiques.


Linux-Azur :      http://www.linux-azur.org
Désinscriptions: http://www.linux-azur.org/liste.php3
**** Pas de message au format HTML, SVP ****

Répondre à