La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: Leon le 31 mars 2014 à 08:36:53
-
Bonjour à tous!
J'aimerai comprendre comment les ordinateurs/serveurs adaptent la MTU de chaque connexion.
* Déjà, est-ce qu'un serveur adapte la MTU pour chaque client, en fonction de ce que ce client lui a annoncé? Je pense que oui, mais je n'en suis pas certain...
* Pour TCP, c'est visiblement la "négociation MSS" qui est utilisée. J'ai bon?
* Mais pour UDP, comment est-ce que ça fonctionne? Je n'ai pas trouvé d'information à ce sujet. Est-ce que c'est à la couche supérieure d'indiquer à UDP quelle MTU utiliser? Un autre mécanisme que je n'aurais pas trouvé?
Les connexions PPPoE et les VPN diminuent la MTU, donc cette négociation me semble importante, même à l'heure du très haut débit.
D'ailleurs, quel est l'intérêt de maintenir des MTU réduites sur les connexions ADSL PPPoX? Ne peut-on pas tout simplement élargir la MTU pour qu'au final, en supprimant l'overhead PPPoE, elle atteigne les 1500 standards?
Merci d'avance pour vos retours!
Leon.
-
MTU :
Chaque interface réseau possède une propriété particulière appelée MTU (Maximum Transmission Unit). C'est une valeur entière qui correspond à la taille maximale d'un paquet transitant par cette interface.
- Ethernet : 1500
- Connexion ADSL qui utilise L2TP : 1460
- PPPoA : 1500
- PPPoE : 1492
- PPTP : 1500
- PPP en RTC :
Download : MSS size 1408 bytes (MTU 1448 bytes, unknown interface)
Upload : MSS size 1420 bytes (MTU 1500 bytes, ethernet)
- ATM : 9180
MSS :
MSS = MTU - en-têtes IP - en -têtes TCP/UDP
En-tête IPv4 : (taille sans option : 20 octets)
(https://lafibre.info/images/tuto/IPv4.png)
En-tête TCP : (taille sans option : 20 octets)
(https://lafibre.info/images/tuto/TCP.png)
En-tête UDP : (taille : 8 octets)
(https://lafibre.info/images/tuto/UDP.png)
MSS TCP :
- MTU 1500 (Ethernet) : MSS TCP de 1460 octets
- MTU 1500 (PPPoA) : MSS TCP de 1460 octets
- MTU 1500 (PPTP) : MSS TCP de 1460 octets
- MTU 1492 (PPPoE) : MSS TCP de 1452 octets
- MTU 1460 (Connexion ADSL qui utilise L2TP) : MSS TCP de 1420 octets
MSS UDP :
- MTU 1500 (Ethernet) : MSS UDP de 1472 octets
- MTU 1500 (PPPoA) : MSS UDP de 1472 octets
- MTU 1500 (PPTP) : MSS UDP de 1472 octets
- MTU 1492 (PPPoE) : MSS UDP de 1464 octets
- MTU 1460 (Connexion ADSL qui utilise L2TP) : MSS UDP de 1432 octets
Explication pour les différents cas de MTU / MSS pour l'ADSL / FTTH :
Les lignes avec IPoA / IPoE / PPPoA ont une MSS de 1460 octets soit une MTU de 1500 octets.
Les lignes avec PPPoE ont une MSS de 1452 octets soit une MTU de 1492 octets, car le PPP rajoute un en-tête de 8 octets.
Les lignes en extension qui utilisent un LNS (avec tunnel L2TP) ont une MSS de 1420 soit une MTU de 1460 octets, car le tunnel L2TP rajoute un en-tête de 40 octets.
Il est possible de dépasser 1500 octets sur certains réseaux pour offrir aux clients une MTU de 1500 octets malgré l'utilisation de PPP / LNS mais c'est souvent une chose difficile quand le flux passe sur plusieurs réseaux différents (cas de la collecte)
Évolution du [SYN , ACK] dans le sens Upload avec une connexion en collecte avec PPPoE + LNS (L2tp Network Server) :
Paquet [SYN , ACK] émis par le client derrière une box ADSL vers un serveur en Ethernet en réponse à un [SYN] qui l'on analyse dans le post suivant.
Analyse au niveau du Client :
Le client précise dans les options du paquet [SYN , ACK] qu’il souhaite une MSS de 1460 octets, correspondant à une MTU de 1500 octets.
(https://lafibre.info/images/tuto/200808_mtu_mss_upload_1_client.png)
Analyse au niveau du DSLAM :
La box a modifié à la volée les paquets [SYN , ACK] afin de limiter la MSS à 1452 octets (MTU de 1492 octets) car la box utilise PPPoE ce qui utilise 8 octets.
(https://lafibre.info/images/tuto/200808_mtu_mss_upload_2_dslam.png)
Analyse au niveau du serveur :
Le réseau a modifié à la volée les paquets [SYN , ACK] afin de limiter la MSS de 1420 soit une MTU de 1460 octets, car le L2TP rajoute un en-tête de 40 octets.
(https://lafibre.info/images/tuto/200808_mtu_mss_upload_3_serveur.png)
-
Évolution du [SYN] dans le sens download avec une connexion en collecte avec PPPoE + LNS (L2tp Network Server) :
Paquet émis [SYN] par le serveur vers le client (box ADSL en collecte).
Analyse au niveau du serveur :
Le serveur précise dans les options du paquet [SYN] qu’il souhaite une MSS de 1460 octets, correspondant à une MTU de 1500 octets.
(https://lafibre.info/images/tuto/200808_mtu_mss_download_1_serveur.png)
Analyse au niveau du DSLAM :
Le réseau a modifié à la volée les paquets [SYN] afin de limiter la MSS de 1420 soit une MTU de 1460 octets, car le L2TP rajoute un en-tête de 40 octets.
(https://lafibre.info/images/tuto/200808_mtu_mss_download_2_dslam.png)
Analyse au niveau du Client :
Aucune modification de la box car on a un paquet [SYN] qui a une MSS qui permet de faire passer les 8 octets du PPP.
(https://lafibre.info/images/tuto/200808_mtu_mss_download_3_client.png)
Schéma du réseau utilisé
(https://lafibre.info/images/wireshark/201403_l2tp_architecture.png)
(https://lafibre.info/images/wireshark/201403_l2tp_encapsulation.png)
Source : Frameip (http://www.frameip.com/l2tp-pppoe-ppp-ethernet/#6_-_Larchitecture_PPP_-_L2TP)
-
Merci Vivien!
Je ne savais pas que les équipements réseau changeaient "à la volée" ces paramètres! C'est très intéressant.
Et sais-tu comment ça se passe en UDP?
Leon.
-
En UDP ou ICMP, cela ne passe pas !
Mais généralement le protocole UDP n'est pas utilisé pour des paquets larges (1500 octets).
La principale exception, ce sont des VPN qui se basent sur UDP.
En DNS, dès que la taille augmente on passe en TCP.
-
Pour UDP ou IP au sens large, il y a Path MTU discovery : https://fr.wikipedia.org/wiki/Path_MTU_discovery (https://fr.wikipedia.org/wiki/Path_MTU_discovery)
Chez Cisco, on peut aussi forcer la MTU d'un tunnel GRE à 1500 et reporter la fragmentation au niveau des routers. Evidemment, ça augmente leur charge CPU s'il y a des paquets à gérer. Idéalement, on met la MTU à 1500 sur le tunnel et un MSS plus bas afin que les paquets TCP soient à la bonne taille. Ca permet un bon compromis compatibilité/performance.
-
Et la fragmentation / ré-assemblage au niveau du réseau peut engendrer de la gigue importante entre paquets qui ont été fragmentés sur le réseau et ceux qui ne sont pas fragmentés.
On a même dans certains cas une inversion de l'ordre des paquets au niveau du client : le paquet suivant, plus petit et donc qui a transité directement arrive avant celui plus gros qui a été transporté en deux paquets.
Ce type de comportement (dé-ordonnancement) est catastrophique pour le débit, car le client va demander une retransmission et l’èmetteur va limiter son débit pour éviter de nouvelles occurrences de ce qu'il pense être des pertes.
-
Je ne savais pas que les équipements réseau changeaient "à la volée" ces paramètres! C'est très intéressant.
Très crade aussi.
Cela ne peut marcher que quand TCP est directement au dessus de IP. Si tu as un protocole d'encapsulation comme 6in4 (comme le 6rd de Free), Teredo (connectivité IPv6 reposant sur IPv4), ESP (encapsulation IPsec), le routeur ne reconnaîtra pas un entête TCP (en fait il pourrait reconnaître 6in4, mais pas un contenu protégé par un VPN comme IPsec; c'est le principe d'un VPN : masquer aux routeurs intermédiaires les types de paquets) et dans le cas de IPsec en mode contrôle d'intégrité sans chiffrement, le routeur ne pourra pas modifier le paquet sans casser le contrôle d'intégrité (ce qui revient à détruire le paquet).
La seule bonne solution générale est d'informer les extrémités du MTU à utiliser.
Modifier le MSS c'est vraiment du bricolage.
-
Bonjour à tous!
J'aimerai comprendre comment les ordinateurs/serveurs adaptent la MTU de chaque connexion.
* Déjà, est-ce qu'un serveur adapte la MTU pour chaque client, en fonction de ce que ce client lui a annoncé? Je pense que oui, mais je n'en suis pas certain...
Chaque interface a une MTU; sous Windows :
>netsh interface ipv4 show interfaces
Idx Mét MTU État Nom
--- --- ----- ----------- -------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
9 5 1500 disconnected wifi
8 9 1500 connected ether
Envoi d'un paquet de taille maximale :
-4 : IPv4
-f : fragmentation interdite
-l : taille de la charge utile
>ping -4 -f -l 65500 localhost
Envoi d'une requête 'ping' sur PC [127.0.0.1] avec 65500 octets de données :
Réponse de 127.0.0.1 : octets=65500 temps<1ms TTL=128
Je précise que le suis en "mode bridge" :
>ping -4 -f -l 65500 82.mon.adr.esse
Envoi d'une requête 'Ping' 82.mon.adr.esse avec 65500 octets de données :
Réponse de 82.mon.adr.esse : octets=65500 temps<1ms TTL=128
plus sérieusement :
ping -4 -f -l 1472 82.x.y.254 : passe
ping -4 -f -l 1473 82.x.y.254 : ne pas passe pas
En effet l'entête IP fait 20 octets, et l'entête ICMP 8 octets (WP : Format d'un paquet ICMP (https://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol#Format_d.27un_paquet_ICMP)).
Dans le cas IPv4, l'interface réseau de Windows associée à l'adresse Internet a le MTU maximum autorisé par le driver Ethernet. Ce n'est plus le cas en IPv6 :
>netsh interface ipv6 show interfaces
8 20 1480 connected ether
Le MTU est inférieur de 20 octets au MTU de la carte Ethernet, cela correspond pile poil à l'entête IPv4 utilisé par 6in4 utilisé par 6rd de Free. Par quel miracle Windows a t-il trouvé la bonne valeur?
(... la suite prochainement ...)
-
Merci corrector!
Pour le paquet de 65000 octets, c'est un truquage, ou alors est-ce que l'interface loopback accepte n'importe quelle MTU?
Leon.
-
Aucun trucage!
L'interface de bouclage est particulière, elle sert à tous les paquets qui ne sortent pas de la machine. Elle ne sert pas à uniquement pour l'IP "localhost".
-
Le réseau a modifié à la volée les paquets [SYN] afin de limiter la MSS de 1420 soit une MTU de 1460 octets, car le LNS rajoute un en-tête de 40 octets.
On peut faire ça avec la cible TCPMSS de iptables :
La cible TCPMSS peut être utilisée pour modifier la valeur MSS (Maximum Segment Size) des paquets TCP SYN que le pare-feu examine. La valeur MSS sert à contrôler la taille maximum des paquets d'une connexion spécifique. Dans des circonstances normales, ceci indique la taille de la valeur MTU (Maximum Transfert Unit), moins 40 octets. Elle est utilisée pour éviter que certains fournisseurs d'accès ou serveurs bloquent la fragmentation ICMP des paquets, ce qui peut provoquer des problèmes mystérieux, qui peuvent être décrits principalement par le fait que tout fonctionne parfaitement au niveau de notre routeur/pare-feu, mais que nos hôtes locaux derrière le pare-feu ne peuvent échanger des paquets importants. Ceci peut se traduire par certaines choses comme des serveurs de courrier capables d'envoyer des petits mails, mais pas des gros, des navigateurs web qui se connectent mais ensuite se figent en ne recevant aucune donnée, une connexion ssh propre, mais dont le scp est suspendu après l'établissement de la liaison. Autrement dit, tout ce qui utilise des paquets importants sera incapable de fonctionner.
La cible TCPMSS est capable de résoudre ces problèmes, en changeant la taille des paquets sortants d'une connexion. Notez que nous avons uniquement besoin de placer le MSS sur le paquet SYN, les hôtes s'occupant du MSS après ça. La cible prend deux arguments.
http://www.inetdoc.net/guides/iptables-tutorial/tcpmsstarget.html (http://www.inetdoc.net/guides/iptables-tutorial/tcpmsstarget.html)
-
Les précédentes captures Wireshark datent de 2008, j'ai refait des captures en 2016 avec IPv4 et IPv6.
La capture consiste à télécharger un fichier "1Mo.iso" remplis de zéros, donc facilement compressible pour que les captures ne prennent pas trop de place.
Voici les url utilisées dans les fichiers Wireshark ci-dessous :
- IPv4 : http://ipv4.lafibre.info/fichiers/1Mo.iso (IP du serveur : 46.227.16.8 sur le VLAN 74)
- IPv6 : http://ipv6.lafibre.info/fichiers/1Mo.iso (IP du serveur : 2a01:6e00:10:410::2 sur le VLAN 74)
Le serveur utilise le VLAN 74 pour sa connexion à Internet, ce qui rajoute 4 octets, toutefois, le VLAN est en dessous de TCP/IP (couche N°2) => il ne change rien à la MSS : les paquets simplement ont une taille de 4 octets supplèmentaire. Quand on parle d'un de MTU de 1500 octets, c'est la taille au niveau IP (couche N°3).
Le client, comme le serveur sont des Linux, donc avec l'option TCP Timestamps est activé (qui prend de la place, mais qui permet au serveur d'être plus agressif, via une connaissance fine de la latence).
Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- SFR câble en IPv4 : MTU de 1500 / MSS de 1460 => capture coté client (https://lafibre.info/images/wireshark/201602_capture_sfr_cable_ipv4_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_sfr_cable_ipv4_serveur.pcapng.gz)
- SFR ADSL en IPv4 : MTU de 1492 / MSS de 1452 => capture coté client (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_serveur.pcapng.gz)
- SFR ADSL en IPv6 : MTU de 1453 / MSS de 1393 => capture coté client (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_serveur.pcapng.gz)
- Ikoula en IPv6 : MTU de 1500 / MSS de 1440 => capture coté client (https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_serveur.pcapng.gz)
MSS TCP :
- MTU 1500 (Ethernet) : MSS TCP de 1460 octets
- MTU 1500 (PPPoA) : MSS TCP de 1460 octets
- MTU 1500 (PPTP) : MSS TCP de 1460 octets
- MTU 1492 (PPPoE) : MSS TCP de 1452 octets
- MTU 1460 (Connexion ADSL qui utilise L2TP) : MSS TCP de 1420 octets
MSS UDP :
- MTU 1500 (Ethernet) : MSS UDP de 1472 octets
- MTU 1500 (PPPoA) : MSS UDP de 1472 octets
- MTU 1500 (PPTP) : MSS UDP de 1472 octets
- MTU 1492 (PPPoE) : MSS UDP de 1464 octets
- MTU 1460 (Connexion ADSL qui utilise L2TP) : MSS UDP de 1432 octets
Niveau 4 : En-tête TCP : 20 octets + option timestamps activé par défaut (12 octets) => 32 octets
(https://lafibre.info/images/tuto/TCP.png)
Niveau 3 : En tête IPv4 sans option : 20 octets
(https://lafibre.info/images/tuto/IPv4.png)
(https://lafibre.info/images/tuto/IPv6.png)
Niveau 2 : En-tête Ethernet : 30 octets (Wireshark ne prend en compte que 14 octets sans VLAN et 18 octets avec VLAN)
8 octets pour le préambule + SFD (invisible avec Wireshark)
6 octets pour l'adresse de destination
6 octets pour l'adresse source
2 octets pour la longueur en octets du champ de données (champ EtherType).
4 octets pour le Frame Control Sequence qui contient un CRC [Cyclic Redundancy Check] (invisible avec Wireshark)
4 octets pour le VLAN (Optionnel mais souvent utilisé)
(https://lafibre.info/images/tuto/201204_Ethernet_Type_II.png)
Niveau 1 : Inter Frame Gap: 12 octets
12 octets (96 bits) pour l'Inter Frame Gap. Ce délai normalisé (spécification IEEE 802.3) est fixé à 96 bits (soit 9,6 µs sur un Ethernet 10Mbps), il détermine le temps pendant lequel une station doit attendre entre l'émission de deux trames successives.
-
En IPv4, sur une box SFR ADSL :
Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- SFR ADSL en IPv4 : MTU de 1492 / MSS de 1452 => capture coté client (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_serveur.pcapng.gz)[/size]
Voici les captures d'écran de ce fichier capture coté client (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_serveur.pcapng.gz) :
Le client èmet un [SYN] avec une MSS de 1460 octets :
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_client_syn.png)
La box ADSL a modifié le MSS à la volée pour mettre 1452 octets, c'est ce que reçoit le serveur pour le même paquet : (diminution de 6 octets à cause du PPPoE)
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_serveur_syn.png)
La réponse du serveur avec un [SYN, ACK] avec une MSS de 1460 octets :
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_serveur_syn_ack.png)
La box ADSL modifie là aussi le paquet reçu du serveur pour lui mettre un MSS à 1452 octets :
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv4_client_syn_ack.png)
Le connexion va donc s’établir à 1452 octets de MSS (diminution de 6 octets à cause du PPPoE).
-
En IPv6, sur une box SFR ADSL :
Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- SFR ADSL en IPv6 : MTU de 1453 / MSS de 1393 => capture coté client (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_serveur.pcapng.gz)
Voici les captures d'écran de ce fichier capture coté client (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_serveur.pcapng.gz) :
Le client èmet un [SYN] avec une MSS de 1440 octets soit une MTU de 1500 => MSS = 1500 - (40 octets pour IPv6 + 20 octets pour TCP) :
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_client_syn.png)
La box ADSL ne modifie pas le MSS en IPv6 (contrairement à IPv4à, le serveur reçoit donc un MSS de 1440 (= MTU 1500) :
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_serveur_syn.png)
La réponse du serveur avec un [SYN, ACK] avec une MSS de 1393 octets soit une MTU de 1453 octets :
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_serveur_syn_ack.png)
La box ADSL reçoit le paquet tel que :
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl_ipv6_client_syn_ack.png)
-
A noter que la Neufbox utilisée est pas un modèle top récent : c'est un NeufBox v4 qui date de l'époque de Neuf Telecom :
Le protocole indique mixte PPPoE + DHCP : PPPoE est pour Internet, DHCP est utilisé pour les service TV et est priorisé sur le tunnel PPPoE.
(https://lafibre.info/images/wireshark/201602_capture_sfr_adsl.png)
-
Je cherche a comprendre comment le serveur à conclut que la MSS était de seulement 1393 octets.
Bizarre, je n'observe pas la même chose.
J'envoie MSS=1420 (car PMTU=1480 à cause du 6rd), qui n'est je suppose pas modifié par la Freebox.
Je reçois MSS=1440, donc une MTU de 1500 ce qui veut dire que :
- le serveur a donné cette valeur
- la Freebox ne l'a pas modifiée, ce qui est étonnant : si mon PC en tenait compte (ce qui n'est pas le cas, j'ai vérifié en faisant un POST) il y aurait de la fragmentation en upload à cause du 6rd
-
Aucune fragmentation n'est possible en ipv6
-
hwti, j'ai un peu de mal à comprendre pourquoi ton PC client n’envoie pas une MSS de 1440, il ne sait pas qu'il y a du 6rd...
Pour montrer que le serveur a bien une MSS de 1440 en IPv6, un test avec un client IPv6 qui gère une MTU de 1500 (donc MSS de 1440 en IPv6) :
En IPv6, un client Ikoula (connexion directe depuis le datacenter) :
Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- Ikoula en IPv6 : MTU de 1500 / MSS de 1440 => capture coté client (https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_serveur.pcapng.gz)
Voici les captures d'écran de ce fichier capture coté client (https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_client.pcapng.gz) et capture coté serveur (https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_serveur.pcapng.gz) :
Le client èmet un [SYN] avec une MSS de 1440 octets soit une MTU de 1500 => MSS = 1500 - (40 octets pour IPv6 + 20 octets pour TCP) :
(https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_client_syn.png)
Le serveur reçoit ce même paquet :
(https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_serveur_syn.png)
La réponse du serveur avec un [SYN, ACK] avec une MSS de 1440 octets soit une MTU de 1500 octets :
(https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_serveur_syn_ack.png)
Le client reçoit le paquet [SYN, ACK] tel que :
(https://lafibre.info/images/wireshark/201602_capture_ikoula_ipv6_client_syn_ack.png)
-
Aucune fragmentation n'est possible en ipv6
C'est vrai, j'oubliais.
Donc c'est vraiment bizarre que la Freebox n'ajuste pas le MSS envoyé par le serveur.
Il faut donc que le PC tienne bien compte du MTU donné par la Freebox (voir plus bas), ou du PMTU Discovery (cad des ICMPv6 packet too big).
hwti, j'ai un peu de mal à comprendre pourquoi ton PC client n’envoie pas une MSS de 1440, il ne sait pas qu'il y a du 6rd...
En fait la route link-local fe80::/64 a une MTU de 1480, qui vient du paquet Router Advertisement de la Freebox : il contient une option MTU.
La MTU locale est donc réduite, ce qui n'est pas optimal : seule la route par défaut, pour les accès distants, en a réellement besoin.
-
En DNS, dès que la taille augmente on passe en TCP.
augmente par rapport à quoi?
-
Il y a 15ans, la taille maximale des paquets UDP port 53 utilisée par DNS était de 512 octets. Si une réponse dépassait cette taille, la norme prévoit que la requête doit être renvoyée sur le port TCP 53.
Depuis 1999, cette limite n'existe plus : Il y a très longtemps, lorsque les ministres ne parlaient pas de l'Internet à la télévision, la taille des paquets DNS était limitée à 512 octets (RFC 1035, section 2.3.4). Cette limite a été supprimée par le RFC 2671 en 1999. source: Stéphane Bortzmeyer (http://www.bortzmeyer.org/dns-size.html)
Attention, en DNSSEC, la taille peut dépasser 1500 octets, donc là c'est sur qu'il faudra passer en TCP.
Je ne sais pas comment fait DNS pour connaître la taille maximale en UDP. J'imagine qu'il y a une marge, comme un maximum à 1400 octets de données, ce qui i fait qu'on est sur que cela passe, même avec des tunnels comme chez SFR (MTU de 1453 en IPPv6)
A moins que la MTU IPv6 en zone non dégroupée soit de 1421 octets (tunnel L2TP + IPv6 encapsulé dans IPv4)
-
Un serveur DNS peut envoyer des réponses UDP fragmentées.
-
Effectivement, tout semble passer en UDP qui sera fragmenté (même en IPv6) :
Le protocole IPv6 a un mécanisme de fragmentation des paquets. L'en-tête d'un fragment contient un champ « Identification » (RFC 2460, section 4.5) qui, avec les deux adresses Source et Destination, identifie de manière unique un paquet fragmenté (tous les fragments de ce paquet ont le même identificateur), et permet donc le réassemblage à la destination. La façon la plus simple d'affecter ces identificateurs est d'avoir, dans chaque machine, un compteur global incrèmenté à chaque paquet qu'on fragmente (section 1 du RFC). Une telle façon de faire mène à des identificateurs prévisibles : un observateur qui se connecte à cette machine peut prévoir quel sera l'identificateur du paquet suivant. Cela a de sérieuses conséquences en terme de sécurité. Ce RFC explore ces conséquences, et propose des solutions.
Petit rappel au passage sur la fragmentation IPv6 : contrairement à la fragmentation IPv4, elle ne peut se faire que dans la machine èmettrice, pas dans les routeurs intermédiaires. Voici un exemple de paquet fragmenté, vu par tcpdump, la réponse DNS, trop grosse, a été fragmentée en deux :
10:45:24.818912 IP6 (hlim 56, next-header Fragment (44) payload length: 432) 2001:4b98:dc2:45:216:3eff:fe4b:8c5b > 2001:67c:1348:7::86:133: frag (0x000079cc:0|424) 53 > 37407: 25110*- q: ANY? . 24/0/1 . [1d] DNSKEY, . [1d] DNSKEY, . [1d] DNSKEY[|domain]
10:45:24.819008 IP6 (hlim 56, next-header Fragment (44) payload length: 1458) 2001:4b98:dc2:45:216:3eff:fe4b:8c5b > 2001:67c:1348:7::86:133: frag (0x000079cc:424|1450)
Source : Stéphane Bortzmeyer (http://www.bortzmeyer.org/7739.html), le 7 février 2016
-
Mais généralement le protocole UDP n'est pas utilisé pour des paquets larges (1500 octets).
Tu plaisantes?
Et le NFS, c'est du poulet? Et QUIC?
-
NFS a distance utilise TCP (prise en charge depuis NFS v3). L'UDP est plus utilisé à l’intérieur d'un réseau local.
Tu as raison pour QUIC (utilisé uniquement avec certains services Google avec Google Chrome 29 et ultérieur)
https://www.youtube.com/watch?v=hQZ-0mXFmk8
En TCP/IP, la couche 4 est géré par le système d’exploitation et donc pas souvent mis à jour (il reste encore de nombreux Windows XP).
En UDP/QUIC, la couche 4 est géré par le navigateur et donc mis à jour de façon très régulière, ce qui lui permet de profiter des dernières amélioration.
Google veut accélérer Internet avec QUIC
QUIC (Quick UDP Internet Connections, prononcé 'quick' NdT : 'couic' en français) est un protocole de transport multiplexé au dessus d'UDP avec comme but principal de ne pas ajouter de délai de connexion supplèmentaire.
Robbie Shade, un Développeur de Google, a introduit QUIC dans une vidéo récente, avec comme avantages principaux :
- Tous les avantages de SPDY (multiplexage, priorités, etc.)
- Connexions sans délai supplèmentaire
- Régulation de la vitesse d'émission de paquets pour diminuer les pertes
- Propagation de la correction d'erreurs pour réduire les latences de retransmission
- Gestion de congestion adaptative (proche de TCP), diminuant les reconnexions pour les clients mobiles
- Chiffrement équivalent à TLS
- Chrome peut communiquer avec Google par QUIC dès aujourd'hui
QUIC gère la retransmission, les paquets manquants ou dans le désordre, quelque chose qu'UDP ne fait pas par défaut. Le multiplexage dans QUIC siginifie que le protocole utilise plusieurs canaux pour envoyer les données, donc si un paquet est perdu dans un des flux de données, les autres ne sont pas bloqués en attente de celui-ci, comme c'est le cas pour SPDY, qui fait du multiplexage mais sur un seul canal. Cette approche dans QUIC résoud le problème de Head-of-line blocking (blocage d'un ensemble de paquets en attente du premier) qui peut arriver durant les retransmissions TCP, d'après Shade.
Un des bénéfices majeurs de l'utilisation de QUIC est le fait qu'il ne requiert pas de phase de handshake au premier contact entre le client et le serveur, d'une façon plus ou moins proche de TCP Fast Open, qui a été en discussion depuis 2011 mais n'a pas connu de large adoption. Selon Shade, le handshake TCP peut prendre jusqu'à 300 ms sur une connexion transatlantique si TLS est utilisé, alors que QUIC peut réduire cette latence à 100 ms.
Un autre avantage de QUIC est que les canaux de communication ne sont pas définis par le couple IP+port mais par un ID, ce qui permet de continuer une connexion même en changeant de réseau, par exemple quitter une zone Wi-Fi et entrer dans le réseau mobile.
Toutes les connexions QUIC sont chiffrées selon un mécanisme spécifique détaillé dans le QUIC Crypto document.
Quand on lui demande pourquoi ne pas utiliser une version améliorée de TCP + TLS, Shade répond que tandis que TCP et TLS subissent des améliorations, les itérations du protocole et leur déploiement sont très lents, alors que QUIC est déployé au niveau client et non au niveau du noyau, permettant des itérations beaucoup plus rapides - "des semaines plutôt que des années".
D'après Shade, SPDY peut fonctionner au dessus de QUIC dans le futur, le rendant encore meilleur qu'actuellement. Certaines des leçons apprises et testées par Google en pratique avec QUIC pourraient se retrouver dans TCP dans le futur.
Actuellement, il y a un client et un serveur disponible dans Chromium, et QUIC est utilisé par google.com, GMail, YouTube, et d'autres services Google.
Source : InfoQ (http://www.infoq.com/fr/news/2014/04/quic) le 15 avr. 2014 par Olivier Bourgain
-
J'up avec mon retour d'XP.
Sous Linux, il existe tracepath (de iputils) pour calculer la PMTU, mais c'est manuel et assez galère.
J'ai trouvé sous Windows 2 outils plus évolués, mturoute et mtupath (qui detecte les PMTU blackhole).
https://www.elifulkerson.com/projects/mturoute.php
https://www.iea-software.com/products/mtupath/
-
Bonjour à tous,
Je suis dans un réseau Lan standard Ethernet avec sa MTU par defaut de 1500 aussi bien sur mes cartes réseau que sur les switch cisco du réseau. L'objectif étant de comprendre la fragmentation , d'ou mes question s ci-dessous.
1- Quels sont les équipements capable de fragmenter les paquets ( Ordinateur, switch, router...) ?
2- La fragmentation est elle par défaut activé sur ces équipements ?
3- J'ai cru comprendre qu'elle était activée par défaut et donc j'ai effectué un test sur ma machine que voici. Un test avec une charge de 2000Bytes et autre avec la meme charge mais le bit DF positionné pour interdire la fragmentation.
Si la fragmentation est activée par défaut pourquoi lors du test sans DF le ping ne répond pas.
Merci à vous pour vos réponses
-
La frag fait partie de la spec IP.
Ce sont les routeurs qui fragmentent, s'ils ont assez de mémoire pour et qu'il n'y a pas DF d'indiqué.
-
Merci pour cette réponse rapide.
A vous lire, il y'a juste les routers qui fragmentent les paquets pas d'autres équipements.
Mais pourquoi sur nos machines nous avons la possibilité d'interdire la fragmentation en positionnant le DF ?
-
Normalement en 2019, on ne devrait pas fragmenter hors cas spécifique type contenu qui est placé dans un VPN.
La fragmentation ne permet pas d'avoir de haut débit avec des paquets qui n'arrivent pas toujours dans l'ordre (souvent le dernier paquet non fragmenté arrivera avant l'avant-dernier paquet d'avant qui est fragmenté).
L'expéditeur doit envoyer les paquet de la bonne taille pour ne pas avoir besoin de fragmenter les paquets sur le chemin.
Pour ce faire les équipements changement la MTU/MSS des paquets TCP qui passent par eux afin de réduire la MTU/MSS au maximum disponible sans fragmentation.
-
Certains protocoles L7 ne fonctionnent pas ou mal si il y a du out-of-order dû à la fragmentation. Donc ces protocoles posent DF (le plus connu est SSH) pour indiquer aux routeurs sur le chemin de ne pas fragmenter
-
SSH étant sur TCP, il ne devrait pas voir ça (TCP s'occupe de ré-émettre les paquets perdus et de remettre les paquets dans le désordre pour avoir une information fiable)
-
Bonjour à tous et meilleurs à vous.
@ Vivien, pourriez vous svp plus détailler pourquoi la fragmentation ne permet pas d'avoir du haut débit (cela est valable en TCP et UDP?)
Désolé pour ces questions qui peuvent paraître basique, mais il y'a pas mal d'embrouille dans ma tete sur ces différents points que je profite du forum pour couvrir ces zones d'ombres.
Et juste pour précision, le OUT-OF-ORDER n'est observé que sur des connexion UDP ?
-
Si je ne m'abuse, la fragmentation se fait en soft, c'est à dire sur le CPU généraliste des routeurs, et pas sur le matériel dédié et optimisé