On Mon, 8 Jan 2001, Daniel Cordey wrote:
> Je ne sais pas si j'ai bien compris, mais il me semble que c'est TCP qui
> est charge du 'flow control' et donc du reassemblage des paquets. TCP
Attention, il y a deux niveaux ici: les paquets et les fragments. Un
paquet contient les données du byte X au byte Y. Maintenant, si l'on veut
transmettre plus que le MTU du medium local, on peut:
- envoyer des paquets à la suite de plus petite taille (TCP fait cela
tout seul, UDP je ne sais pas: soit une erreur, soit fragmente, VOIR
PLUS LOIN)
- envoyer un gros paquet virtuel qui est composé de *fragments*.
Maintenant, à quoi ça sert d'avoir des fragments, finalement, vu que TCP
peut couper à la source en paquets ? Ben si tu ne peux pas deviner quel
est le MIN(MTU, chemin parcouru sur Internet), il y aura forcément un jour
ou l'autre fragmentation du paquet en petits morceaux (sauf si tu envoies
des paquets de size 200, p.ex., il y a grande chance que cela passe
partout, mais alors ta performance sera abysmale: certains réseaux veulent
des tailles de paquets de 32k ou 64k, voire plus (cf window scale
option)).
L'autre solution que la fragmentation est le bit DF, cf autre mail. Plus
efficace (car de nos jours les routeurs perdent souvent des paquets).
Les paquets (sans la fragmentation, donc) sont réassemblés par TCP pour
garantir l'intégrité (checksum simple) et l'ordre (numéro de séquence).
Quand un paquet n'arrive pas (ie timeout: un ordre incorrect n'est pas
suffisant), il y a réémission *depuis* ce paquet.
Si l'on ajoute la problématique des fragments, c'est la même chose (si
timeout et >= 1 fragment d'un paquet pas arrivé -> réémission du paquet).
PS: j'espère que je ne dis pas trop de bêtises, car les fragments cela n'a
jamais été mon fort.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
