[tutoriel win] Optimisation Pile TCP 2000 et XP

[feyb64]

Optimiser Windows 2000 / XP pour avoir de meilleurs débits

Également disponible dans la catégorie Optimisation des débits :

• Tester son débit : Mode d'emploi pour Windows 2000 / XP  / 2003 / Vista
• Tester son débit : Mode d'emploi pour Linux Ubuntu / Debian
• Tester son débit : Mode d'emploi pour MacOS X / autre unix
• Tester son débit : Mode d'emploi avec un live CD (linux sans rien installer) pour PC et Mac
• Optimiser Windows 2000 / XP pour avoir de meilleurs débits
• Optimiser MacOS X pour avoir de meilleurs débits
• Quel canal Wi-FI choisir pour optimiser son débit ?
• Capturer son trafic internet (pour analyse) sans perdre de paquets
• Mettre en place un serveur IPERF

Autres catégories disponible :

• Optimisation des débits
• Tuto divers
• Problèmes ADSL

Enfin finalisé, voici le tuto qui vous permettra de tirer au mieux partie de votre liaison FTTH !

Tout d'abord, un petit "lexique" :

Paquet IP ou Trame IP (IP Frame) : Un "Paquet IP" est l'élément de base de transmission pour le protocole TCP/IP. Comme son nom le suggère, un paquet est constitué d'un conteneur (ou enveloppe) avec une étiquette dessus (ou entête) et le contenu (les données)

MTU (Maximum Transfert Unit) : correspond à la taille maximale d'un "Paquet IP" que l'on peut envoyer sur la liaison. Cette taille est définie en fonction des technologies et méthodes de transmission sous jacentes (la liaison et la façon d'y transporter des informations), ainsi que d'autres paramètres dépendant des matériels ou logiciels utilisés.

MSS (Maximum Segment Size) : correspond à la taille maximale de la partie "données" d'un "Paquet IP". Cette taille est déterminée par la formule " MTU moins 'taille de l'entête' " (en général cette entête est de 40 octets).
Toute transmission complète (par exemple un fichier, une demande de page web, un message, ...) dont la taille serait supérieure à cette taille "MSS" sera "fragmenté" (terme couremment utilisé pour dire "découpé en rondelles") en autant de paquets de cette taille "MSS" (le dernier paquet pouvant être plus petit) avant l'envoi sur la liaison.

RWin (Receive Windows) ou "Fenêtre de Réception" : correspond à la quantité maximale de "Paquets IP" pouvant être envoyées par l'émetteur sans avoir à attendre une confirmation de bonne réception de la part du destinataire. Ce "Rwin" est exprimé en nombre d'octets et pas en nombre de paquet de taille "MSS". Le destinataire allouera cette quantité en mémoire (emplacement que l'on appel généralement "tampon" ou "buffer") pour pouvoir y placer les données reçus. En temps normal, le destinataire enverra un "Paquet IP" d'accusé de réception à l'émetteur lorsque ce "buffer" sera plein et pas avant, à moins que l'émetteur ai explicitement indiqué la fin de transmission ou qu'une condition d'erreur soit intervenue (certains paquets non reçus, erreur sur la liaison, ...)

Processus d'optimisation "Rwin" sous Windows 2000/XP :

Le but de l'optimisation du "Rwin" est de déterminer sa taille dans les cas les plus défavorables de délais de transmission sur la liaison. Car aucun paquet n'arrive instantanement à l'autre bout, les accusés de réception aussi. Le risque à éviter est une perte de paquets par délais maximum dépassé (il faut bien en mettre un pour ne pas rester indéfiniment en attente côté émetteur comme destinataire) car la non réception d'un paquet à temps (de x vers y ou y vers x) entraîne automatiquement des retransmissions par l'autre côté, retransmissions qui donc font baisser les performances de l'ensemble, ce que l'on souhaite éviter au maximum (perte de temps et de débit utile).
Grosso modo, un "Rwin" bien calculé permettra à l'émetteur d'envoyer plus souvent "la sauce" et au destinataire de la lui demander ni plus ni moins qu'il le faut et quand il faut.

1 - Déterminer le "MTU" à utiliser pour l'optimisation :
D'abord les valeurs "type" (pour les habitués ou pour allez vite) :
- Connexion ADSL par encapsulation "PPPoA"         : 1500
- Connexion ADSL pas encapsulation "PPPoE"         : 1492
- Connexion FTTH "PBC" via Sagem F@st3190w     : 1400
- Connexion FTTH "PBC" via NeufBox                    : 1500

Si celà vous suffit, passez au point 2
Sinon voici la méthode pour déterminer le "MTU" chez vous si vous voulez trouver le "MTU" par vous même, ou pour être sûr de la valeur à utiliser chez vous (surtout pour les connexions ADSL, car cela dépend non seulement du mode d'encapsulation, "ATM" ou "PPPoE", mais aussi de la "box" ou du "modem" ou du "routeur/modem" ADSL, certains étant paramétrés avec des "MTU" "bizarres" mais qui ne sont pas forcement connus du public ou visualisables dans les paramètres du matériel) :

Le test "MTU" consiste à prendre comme cible un serveur "pinguable" (répondant aux "pings", paquets spéciaux de gestion réseau) dont on sait qu'il accepte des paquets de taille maximale de 1500 (la plupard des serveurs sur le net sont configurés avec cette taille de "MTU", mais ne vous inquiétez pas, je vous en indique quelques uns qui ont bien un "MTU" de 1500 : www.google.fr ou www.tf1.fr) et de "pinguer" cette cible avec des paquets de tailles fixes différentes et "voir si ça passe ou ça casse" quelque part entre vous et elle.

La commande "ping" à utiliser est :
    ping -f -l <taille> <cible>

Le processus de test suit une logique implacable ( Monsieur Spock sera content  ) :
On commence par :
- Ouvrez une "Invite de commande" par "Démarrer" "Executer", puis tapez CMD et validez
- Dans la fenêtre (presque toute) noire qui s'affiche :
- Tapez la commande ping complète avec les bons paramètres.
    ping -f -l 1472 cible
( remplacez cible par le nom du serveur choisi, par exemple : ping -f -l 1472 www.google.fr )

Vous allez me dire "Pourquoi 1472 et pas 1500 la taille maximale d'un paquet IP classique en Ethernet ? ? ? ?"
Je m'y attendais 
Tout simplement parce que le paramètre "-l" du ping indique la taille de la partie "Données Utilisateur" du paquet à envoyer et que la commande "ping" elle même utilise déjà (avec IP derrière) 28 octets, donc pour un "MTU" de 1500 il faut faire 1500 - 28 = 1472, taille des données pouvant être placés dans le paquet.

Cette première commande peut donner deux types de réponses :

a - une réponse correcte du ping du style :

Code:

Envoi d'une requête 'ping' sur <cible> [ip_de_la_cible] avec 1472 octets de données :

Réponse de <ip_de_la_cible> : octets=1472 temps=36 ms TTL=50
Réponse de <ip_de_la_cible> : octets=1472 temps=35 ms TTL=50
Réponse de <ip_de_la_cible> : octets=1472 temps=35 ms TTL=50
Réponse de <ip_de_la_cible> : octets=1472 temps=36 ms TTL=50

Statistiques Ping pour <ip_de_la_cible>:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 35ms, Maximum = 36ms, Moyenne = 35ms

Chouette ! Nous avons trouvé la valeur "MTU" du premier coup ! elle est de 1500 (1472 + 28)

b - une réponse "injurieuse" du style :

Code:

Envoi d'une requête 'ping' sur <cible> [ip_de_la_cible] avec 1472 octets de données :

 Le paquet doit être fragmenté mais paramétré DF.
 Le paquet doit être fragmenté mais paramétré DF.
 Le paquet doit être fragmenté mais paramétré DF.
 Le paquet doit être fragmenté mais paramétré DF.

Statistiques Ping pour <ip_de_la_cible>:
    Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),

NOTA: le "paramétré DF" pour "Don't Fragment" soit "Ne découpez pas ce paquet en plus petits pour passer, il doit passer tel quel ou pas du tout", est forcé par l'option "-f" dans la commande ping
NOTA: au fait le "-l" c'est pour "len" soit "longueur"

Dans ce cas "injurieux", il nous faut refaire le test avec une valeur du paramètre "-l" inférieure jusqu'à ce que "ça passe".

Comme de 1472 à 1372 ça en fait 100 des "ping" à taper si on fait de 1 en 1, pour rapidement approcher la "bonne" valeur, répétons la commande en enlevant 50 de la dernière valeur utilisée et ce jusqu'à avoir une réponse "normale" du ping.

Mais si "ça passe" enfin, nous n'en avons pas terminé pour autant car nous avons obtenu ce dernier test "normal" avec une valeur X et le dernier test "injurieux" avec une valeur X+50. Nous avons donc à tester entre X et X+50 exclu.
Nous allons donc "remonter" plus doucement en augmentant la dernière valeur X de 10 en 10, jusqu'à obtenir une réponse "injurieuse" (on n'en veut pas mais on la cherche quand même fou non ?).

Une fois la première "injure" rencontrée (j'y tiens) en "remontant", nous avons maintenant une valeur Y de ce dernier test "injurieux" et le dernier test "normal" avec Y-10.

Vous l'aurez sans doute compris, nous avons donc à tester entre Y exclu et Y-10.

Nous allons donc "redescendre" à nouveau de Y vers Y-10 mais de 1 en 1.

Dès que celà répond "normalement" nous aurons enfin trouvé le MTU que nous cherchions qui n'est autre que "dernière valeur utilisé" + 28.

C'est clair ? Allez va, je vais vous donner des exemples pour bien comprendre le "mécanisme" :

Un 1er exemple visuel pour un MTU final de 1492 (PPPoE) soit une taille "-l" de 1492-28=1464 :
( je vous donne le résultat )

Code:

ping -f -l 1472 www.google.fr
  -> réponse "injurieuse"
On enlève 50 de 1472 soit 1422
 ping -f -l 1422 www.google.fr
  -> réponse "normale"
La bonne valeur est entre 1422 et 1472 exclu,
On "remonte" donc maintenant en ajoutant 10 à 1422 soit 1432
 ping -f -l 1432 www.google.fr
  -> réponse "normale"
On augmente encore de 10
 ping -f -l 1442 www.google.fr
  -> réponse "normale"
On augmente encore de 10
 ping -f -l 1452
  -> réponse "normale"
On augmente encore de 10
 ping -f -l 1462
  -> réponse "normale"
On augmente encore de 10 soit 1472. Doit on la faire ? allez pour le "fun" :)
 ping -f -l 1472
  -> réponse "injurieuse" ( s'aurait été "drôle" autrement non ? )
La bonne valeur est entre 1472 exclu et 1462,
On "redescent" donc maintenant de 1 en 1
 ping -f -l 1471
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1470
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1469
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1468
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1467
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1466
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1465
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1464
  -> réponse "normale" !!! COOL !

Nous avons donc un MTU de 1464 + 28 = 1492 cqfd

Autre exemple visuel (jamais vu de MTU final pareil, mais c'est pour la compréhension et encore le "fun") :

Code:

ping -f -l 1472 www.google.fr
  -> réponse "injurieuse"
On enlève 50 de 1472 soit 1422
 ping -f -l 1422 www.google.fr
  -> réponse "injurieuse"
Encore 50 de moins soit 1372
 ping -f -l 1372 www.google.fr
  -> réponse "normale"
La bonne valeur est entre 1372 et 1422 exclu,
On "remonte" donc maintenant en ajoutant 10 à 1372 soit 1382
 ping -f -l 1382 www.google.fr
  -> réponse "injurieuse"
La bonne valeur est entre 1382 exclu et 1372
On "redescent" donc maintenant de 1 en 1
 ping -f -l 1381
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1379
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1378
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1377
  -> réponse "injurieuse"
On descend encore de 1
 ping -f -l 1376
  -> réponse "normale" :)

Nous avons donc un MTU de 1376 + 28 = 1404

[feyb64]

2 - Déterminer les cibles potentielles utiles au calcul final du rwin 'optimal' à vos usages :

a - Inclure :
- Sites de téléchargements (HTTP, FTP, ...) souvent utilisés
(par "téléchargements", j'entend des téléchargements de fichiers plutôt "lourds en taille, au delà de 5Mo voir 10Mo)
- Sites de visualisation de vidéos, écoute de musique, radios, ... souvent consultés (gourmands en "volume")

b - Exclure :
- Tous les autres sites : Pas besoin de mettre google ou autres sites "fnac", "3suisses", ou même votre forum préféré
En effet, ces cibles envoient en général peu de "gros" fichiers, sagissant essentiellement de pages de quelques Kilo octets en elles mêmes (html) et constitués d'images/logos/... en général de moins de 100Ko. Ils ne sont donc pas des cibles 'utiles' pour l'optimisation 'RWIN'. Toutefois ils bénéficierons quand même de cette optimisation (visuellement on le verra sur des pages "chargées" d'images, animations et d'icônes de grandes tailles. Sur autres pages, on ne verra pas une grande différence)

NOTA : Dans bien des cas, ce n'est pas le serveur "web" (http://) vous proposant des fichiers/vidéo/musiques/radio à télécharger/voir/écouter qui envoit réellement ces téléchargements mais il vous renvoie vers un ou plusieurs serveurs uniquement dédiés à cette tâche de téléchargement. Dans ces cas, n'incluez pas le serveur du site 'web' lui même mais les véritables serveurs sources.
Pour déterminer facilement les serveurs sources réels, démarrez des téléchargements de quelques fichiers depuis ces sites et notez les noms des serveurs de téléchargement réels (l'adresse de téléchargement est généralement indiquée par les navigateurs dans la boite de dialogue affichant l'état d'avancement du téléchargement. Le nom du serveur correspond à la partie entre :// et le premier / suivant. Récupérez plusieurs noms de serveurs différents pour un même site.
Si le site vous propose directement plusieurs serveurs géographiquement répartis, récupérez les noms de plusieurs serveurs 'proches' dans la liste car dans bien des cas, les serveurs proches sont plus 'véloces'. Exemple type : sourceforge.net propose une liste de serveurs de téléchargement, sélectionnez ceux situés en France et par exemple en Belgique et Irlande, et notez à chaque fois les noms des serveurs correspondants.

[feyb64]

3 - Déteminer les temps de 'propagation' maximums pour les sites notés en 2a :

Le test 'basic' consiste encore à'pinguer' chaque serveur cible. Plusieurs tests sont nécessaires par serveur afin d'avoir une réelle idée de la disponibilité de la liaison entre votre pc et la cible :

a - Notez les différentes plages de temps pendant lesquelles vous accédez le plus souvent à ces sites.
Par exemple, beaucoup d'entre vous ne naviguent à 90% que le soir après le boulot entre 21h et minuit, et le samedi entre 16h et minuit. D'autres aussi très souvent le dimanche entre 15h et 17h, ...

b - Déterminer leur 'accessibilité'
A partir de ces données vous allez lancer des pings vers chacun des serveurs cibles à divers moments dans ces plages horaires, et si possible en le répétant sur plusieurs jours voir quelques semaines.
Bien entendu dès les premiers résultats du premier 'test' sur toutes vos cibles, vous pourrez commencer à optimiser votre 'RWIN', mais il est important de voir comment évolue la 'connectivité' avec ces cibles à plus ou moins long terme afin d'être au plus près de l'idéal en terme d'optimisation.
Il est bien entendu aussi important de revoir de temps et temps la liste des cibles, d'en ajouter des nouvelles (en particulier d'autres 'mirroirs' pour si possible avoir les 'meilleurs' dans sa liste), retirer ceux qui seraient devenus trop 'mauvais', ou qui auraient été remplacés ou devenus inexistants, et refaire le test de pings pour affiner les résultats.

Pour lancer le ping, rien de plus simple, la commande type est : ping -f -l {MTU-28} cible
- Ouvrez une 'invite de commande' par "Démarrer" "Executer", puis tapez CMD et validez
- Dans la fenêtre 'noire' qui s'affiche :
- Tapez la commande ping complète avec les bons paramètres.
 ping -f -l {MTU-28} cible
( remplacez {MTU-28}, accolades comprises, par la valeur du calcul indiqué (MTU-28) en utilisant le MTU trouvé en 1, et cible par le nom du serveur choisi; Par exemple : ping -f -l 1472 ftp.debian.org )

Le résultat affiché est semblable à celui ci :

Code:

Envoi d'une requête 'ping' sur [i]<cible>[/i] [[i]ip_de_la_cible[/i]] avec [i]<MTU-28>[/i] octets de données :

Réponse de [i]<ip_de_la_cible>[/i] : octets=[i]<MTU-28>[/i] temps=36 ms TTL=50
Réponse de [i]<ip_de_la_cible>[/i] : octets=[i]<MTU-28>[/i] temps=34 ms TTL=50
Réponse de [i]<ip_de_la_cible>[/i] : octets=[i]<MTU-28>[/i] temps=35 ms TTL=50
Réponse de [i]<ip_de_la_cible>[/i] : octets=[i]<MTU-28>[/i] temps=36 ms TTL=50

Statistiques Ping pour [i]<ip_de_la_cible>[/i]:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 34ms, Maximum = 36ms, Moyenne = 35ms

Il se peut que certains serveurs ne répondent pas à tous les 'ping' ou pas du tout, alors s'affichera à la place de une ou plusieurs des 4 lignes 'Réponse de', un ou plusieurs lignes comme celle ci :

    Délai d'attente de la demande dépassé.

Ne vous en inquiétez pas pour l'instant, nous en discutons justement maintenant

Les deux lignes qui nous interressent le plus sont :

Paquets : envoyés = __, reçus = __, perdus = __ (perte __%)
et
Minimum = __ms, Maximum = __ms, Moyenne = __ms

Tout d'abord, dans la ligne "Paquets ....." regardez le chiffre noté en poucentage (perte __%)

Si cette perte est égale à 100 : Refaites plusieurs fois ce même ping et si toujours égal à 100, 'retirez' cette cible temporairement de votre liste, et si cela persiste 'plus tard' (autre plage horaire, ou semaines suivantes) retirez la définitivement, elle ne nous donne pas d'informations utiles pour la suite puisque à priori ne répond pas aux pings.

Si cette perte est supérieur à 20 : Refaites plusieurs fois ce même ping et si toujours supérieur à 20, 'retirez' cette cible temporairement de votre liste, elle ne nous donne pas d'informations fiables pour l'heure.

Autrement : Notez la valeur "Maximum"

Répétez le ping autant de fois que vous le voulez (minimum 2) sur cette même cible et si le "Maximum" est supérieur au précédent noté, notez le nouveau "Maximum" à la place.
On ne garde donc en fait que le 'maximum' des "Maximum" pour cette cible.

Répétez ensuite l'opération complète pour toutes les autres cibles et notez à chaque fois le "maximum des Maximum" obtenus sur chaque cible.

Partant maintenant de cette liste de cibles avec pour chacune son "maximum des Maximum", notez la plus forte de toutes. Pour la suite je la nommerai "MAXMAX" (ou MADMAX si vous voulez ).

Exemple de résultat des 'maximum des Maximum' :

Code:

www.cible1.com   47
www.cible2.fr    30
www.cible3.org   52
www.cible4.net   35
www.cible5.com   50

Le MAXMAX sera ici 52 de la cible 3

Calculez la valeur que je nommerai par la suite "MINMAX" avec la formule suivante : MAXMAX * 0.90
(Revient à oter 10% à MAXMAX)

Pour mon exemple, MAXMAX * 0.90 = 52 * 0.90 = 46.8

Maintenant, de votre liste de cibles avec "maximum des Maximum", ne gardez que les cibles qui ont leur valeur "maximum des Maximum" supérieure à MINMAX. Vous suivez ?

Pour mon exemple, je garderai les cibles 1 (47), 3 (52) et 5 (40)

Enfin, calculez la moyenne des valeurs obtenus :
- Additionnez les valeurs
- Divisez le tout par le nombre de cibles gardées et récuperer du résultat la valeur entière avant la virgule.

Notez "précieusement" ce résultat que nous nommerons "RTT".

Pour mon exemple, addition des valeurs 47 + 52 + 40 = 139
J'ai gardé 3 cibles, donc 139 / 3 = 46.33333, soit 46.
46 sera donc mon "RTT"

Ouf ! nous y voilà !
Nous avons notre MTU, notre RTT, nous connaissons notre vitesse maximale de ligne, maintenant "OPTIMISONS"

[feyb64]

4 - Déterminer le 'RWIN' à utiliser  en fonction du MTU, du RTT et de la vitesse maximale de la ligne :

Il nous faut donc les données suivantes :
- MTU trouvé en 1 =
- RTT trouvé en 3 =
- Vitesse maximale de la ligne ou Bande Passante exprimée en Kilo Octets (Ko) (je l'appelerai BP)

NB : Convertions divers vers Kilo Octets (Ko)
 - Mega octets (Mo) : multipliez par 1000
 - Mega bits (Mb)   : multipliez par 1000 puis divisez par 8
 - Kilo bits (Kb)   : divisez par 8
 Dans ces trois cas, ne gardez que la partie avant la virgule.

a - Calculer le 'MSS' :

Code:

A = MTU - 40 = ........

b - Calculer combien de paquets 'MSS' tiennent dans 65536 octets (pour le 'scaling' TCP) :

Code:

B = 65536 / MSS =  ........

(ne garder que la partie 'entière' avant la virgule)

c - Combien cela fait en 'octets' ? :

Code:

C = B * A = ........

d - Multiplier le RTT par BP (la vitesse de ligne en Ko) :

Code:

D = RTT * BP = ........

e - Calculer combien de paquets 'MSS' peuvent circuler sur la ligne :

Code:

E = D / MSS = ........

(ne garder que la partie 'entière' avant la virgule)

f - Pour des raisons (encore) de 'scaling' TCP :

Code:

SI E est pair   : F = E = ........
SI E est impair : F = E + 1 = ........

g - Combien cela fait en 'octets' ? :

Code:

G = F * MSS = ........

h - Maintenant une 'petite' boucle pour déterminer le RWIN 'scalé' :

Code:

Donnons initialement à H la valeur C : H = C

i - La boucle :

Code:

SI G est supérieur à H, Multipliez H par 2 : H = H * 2 (toujours le 'scaling')
et comparer à nouveau ce 'nouveau' H avec G (refaire i)
SINON : le dernier H utilisé dans la comparaison est le RWIN à utiliser :)

Exemple : MTU de 1400, RTT de 100, Liaison de vitesse 25Mb

- Commençons par convertir notre bande passante exprimée en 'Mb' vers des 'Ko' :
 '- Mega bits (Mb)   : multipliez par 1000 puis divisez par 8'
 Soit BP (en Ko) = 25 * 1000 / 8 = 3125

- Maintenant les choses sérieuses :

Code:

a - A = MTU - 40 = 1360
b - B = 65536 / MSS = 65536 / 1360 = 48.18 soit 48 (on ne garde que la partie 'entière' avant la virgule)
c - C = B * A = 48 * 1360 = 65280
d - D = RTT * BP = 100 * 3125 = 312500
e - E = D / MSS = 312500 / 1360 = 229.779 soit 229 (on ne garde que la partie 'entière' avant la virgule)
f - E est impair (229) : F = E + 1 = 230
g - G = F * MSS = 230 * 1360 = 312800
h - H = C = 65280
i - G > H ? 312800 > 65280 ? Bien sûr ! donc le nouveau H est H * 2 = 65280 * 2 = 130560
i - G > nouveau H ? 312800 > 130560 ? Toujours :( donc le nouveau H est H * 2 = 130560 * 2 = 261120
i - G > nouveau H ? 312800 > 261120 ? Toujours :( donc le nouveau H est H * 2 = 261120 * 2 = 522240
i - G > nouveau H ? 312800 > 522240 ? Non ! :) donc le 'RWIN' à utiliser est 522240 !!!!!

[feyb64]

5 - Mettre en oeuvre le MTU et le RWIN préalablement trouvés :

Maintenant que nous avons ce qu'il nous faut, configurons la pile TCP/IP.

Pour cela, nous allons utiliser 'TcpOptimizer', mais en lui indiquant NOS valeurs.
(cet outil est avant tout pour l'adsl et certaines valeurs du mode 'automatique' ne sont pas convenables pour du FTTH)

Créez un répertoire uniquement pour TCPOptimizer sur votre disques (C:\TCPOptimizer par exemple) ce qui permettra d'y garder les 'sauvegardes' que fait automatiquement l'outil des paramètres précédents avant modifications (utile pour passer d'une config à une autre, style adsl chez X à adsl chez Y ou encore FTTH chez Z) et téléchargez le programme 'gratuit' disponible ici : http://www.speedguide.net/downloads.php

Lancez maintenant TCPOptimizer (pas d'installation nécessaire)
La seule fenêtre qui nous interresse est la première.


a - Sélectionnez tout en bas 'Optimal Settings' (histoire de définir certaines valeurs par défaut)
b - Passons en mode 'manuel' en sélectionnant maintenant tout en bas "Custom settings"
c - Dans la liste "Network Adapter Selection" vérifiez que la carte réseau à configurer est bien sélectionnée (du type Ethernet ou Wifi suivant le cas)
d - Juste à droite du nom de carte, modifiez le champ 'MTU' avec la valeur déterminée en 1
e - Modifier le champ 'TCP Receive Windows' en y entrant la valeur RWIN trouvée en 4
f - Mettre 'Time to Live (TTL)' à '64'
g - Mettez 'MTU Discovery' à 'Yes'
h - Mettez 'Black Hole Detect' à 'No'
i - Mettez 'Selective ACKs' à 'Yes'
j - Mettez 'Max Duplicate ACKs' à '2'
k - Cochez la case 'Windows Scaling' dans la partie 'TCP 1323 Options'
l - Décochez la case 'Timestamps' dans la partie 'TCP 1323 Options'
m - Cliquez sur 'Apply changes'

TCPOptimizer va proposer de créer une sauvegarde de vos anciens paramètres (recommandé), et appliquer les nouveaux paramètres et enfin demander de de redémarrer l'ordinateur pour qu'ils prennent effet.

Après ce redémarrage, votre pile TCP/IP est optimisée au mieux en fonction des cibles choisies et des paramètres de lignes.


Pour les 'fainéans' voici une abaque pour les liaisons de par chez nous (PBC) avec une colonne ADSL en prime.
(ADSL : la première colonne correspond au débit max ADSL1, la seconde au débit max ADSL2/2+)


 

	|	Mediafibre	|	Neuf PBC	|	Neuf PBC	|	Orange Fibre	|	ADSL PPPoE	|	ADSL PPPoE	|
	|	25 Mb/s	|	50 Mb/s	|	70 Mb/s	|	100 Mb/s	|	8 Mb/s ATM	|	20 Mb/s ATM	|
	|	MTU : 1400	|	MTU : 1500	|	MTU : 1500	|	MTU : 1492	|	MTU : 1492	|	MTU : 1492	|
RTT	|	RWIN	|	RWIN	|	RWIN	|	RWIN	|	RWIN	|	RWIN	|
---------------	|	---------------	|	---------------	|	---------------	|	---------------	|	---------------	|	---------------	|
5	|	65280	|	64240	|	64240	|	65340	|	65340	|	65340	|
10	|	65280	|	64240	|	128480	|	130680	|	65340	|	65340	|
15	|	65280	|	128480	|	256960	|	261360	|	65340	|	65340	|
20	|	65280	|	128480	|	256960	|	261360	|	65340	|	65340	|
25	|	130560	|	256960	|	256960	|	522720	|	65340	|	65340	|
30	|	130560	|	256960	|	513920	|	522720	|	65340	|	130680	|
35	|	130560	|	256960	|	513920	|	522720	|	65340	|	130680	|
40	|	130560	|	256960	|	513920	|	522720	|	65340	|	130680	|
45	|	261120	|	513920	|	513920	|	1045440	|	65340	|	130680	|
50	|	261120	|	513920	|	513920	|	1045440	|	65340	|	130680	|
55	|	261120	|	513920	|	513920	|	1045440	|	65340	|	261360	|
60	|	261120	|	513920	|	1027840	|	1045440	|	65340	|	261360	|
65	|	261120	|	513920	|	1027840	|	1045440	|	65340	|	261360	|
70	|	261120	|	513920	|	1027840	|	1045440	|	130680	|	261360	|
75	|	261120	|	513920	|	1027840	|	1045440	|	130680	|	261360	|
80	|	261120	|	513920	|	1027840	|	1045440	|	130680	|	261360	|
85	|	522240	|	1027840	|	1027840	|	2090880	|	130680	|	261360	|
90	|	522240	|	1027840	|	1027840	|	2090880	|	130680	|	261360	|
95	|	522240	|	1027840	|	1027840	|	2090880	|	130680	|	261360	|
100	|	522240	|	1027840	|	1027840	|	2090880	|	130680	|	261360	|
105	|	522240	|	1027840	|	1027840	|	2090880	|	130680	|	522720	|
110	|	522240	|	1027840	|	1027840	|	2090880	|	130680	|	522720	|
115	|	522240	|	1027840	|	1027840	|	2090880	|	130680	|	522720	|
120	|	522240	|	1027840	|	2055680	|	2090880	|	130680	|	522720	|
125	|	522240	|	1027840	|	2055680	|	2090880	|	130680	|	522720	|
130	|	522240	|	1027840	|	2055680	|	2090880	|	261360	|	522720	|
135	|	522240	|	1027840	|	2055680	|	2090880	|	261360	|	522720	|
140	|	522240	|	1027840	|	2055680	|	2090880	|	261360	|	522720	|
145	|	522240	|	1027840	|	2055680	|	2090880	|	261360	|	522720	|
150	|	522240	|	1027840	|	2055680	|	2090880	|	261360	|	522720	|
155	|	522240	|	1027840	|	2055680	|	2090880	|	261360	|	522720	|
160	|	522240	|	1027840	|	2055680	|	2090880	|	261360	|	522720	|
165	|	522240	|	2055680	|	2055680	|	2090880	|	261360	|	522720	|
170	|	1044480	|	2055680	|	2055680	|	4181760	|	261360	|	522720	|
175	|	1044480	|	2055680	|	2055680	|	4181760	|	261360	|	522720	|
180	|	1044480	|	2055680	|	2055680	|	4181760	|	261360	|	522720	|
185	|	1044480	|	2055680	|	2055680	|	4181760	|	261360	|	522720	|
190	|	1044480	|	2055680	|	2055680	|	4181760	|	261360	|	522720	|
195	|	1044480	|	2055680	|	2055680	|	4181760	|	261360	|	522720	|
200	|	1044480	|	2055680	|	2055680	|	4181760	|	261360	|	522720	|

[vivien]

Un grand bravo pour le travail.

Je vais quand même préciser qu'une petite erreur à du se glisser :

Pour lancer le ping, rien de plus simple, la commande type est : ping -f -l {MTU-28} cible
[...]
Notez "précieusement" ce résultat que nous nommerons "RTT".

Le RTT dont nous avons besoin pour la formule est le RTT ni d'un ping de quelques octets, ni d'un ping de taille MSS (= MTU -28)

Pour moi le RTT à utiliser est le temps que met un paquet de la taille du MSS à être envoyé + le temps pour recevoir un acquittement.
C'est donc entre environ un ping de la taille de MSS divisé par 2 + le temps d'un ping de quelques octets (pour l'ACK) divisé par 2.


Par ailleurs je ne trouve pas pertinent de prendre la valeur MAX d'un ping.  sur des milliers de ping elle est toujours trés élevée, pas forcément a cause d'un pb réseau. La valeur moyenne me semble plus pertinente.

Sur le reste rien à dire, c'est un tuto bien expliqué.

[feyb64]

Un grand bravo pour le travail.

Je vais quand même préciser qu'une petite erreur à du se glisser :

Pour lancer le ping, rien de plus simple, la commande type est : ping -f -l {MTU-28} cible
[...]
Notez "précieusement" ce résultat que nous nommerons "RTT".

Le RTT dont nous avons besoin pour la formule est le RTT ni d'un ping de quelques octets, ni d'un ping de taille MSS (= MTU -28)

Pour moi le RTT à utiliser est le temps que met un paquet de la taille du MSS à être envoyé + le temps pour recevoir un acquittement.
C'est donc entre environ un ping de la taille de MSS divisé par 2 + le temps d'un ping de quelques octets (pour l'ACK) divisé par 2.


Par ailleurs je ne trouve pas pertinent de prendre la valeur MAX d'un ping.  sur des milliers de ping elle est toujours trés élevée, pas forcément a cause d'un pb réseau. La valeur moyenne me semble plus pertinente.

Sur le reste rien à dire, c'est un tuto bien expliqué.

Pour le ping avec taille du MSS pour obtenir le RTT, les temps donnés en retour par le 'ping' tiennent compte largement du paquet ACK puisque c'est justement le temps entre le moment d'émission du paquet 'ping' et la réception du paquet 'Pong'.
Si on es 'puriste', tu as raison, mais faire faire au lecteur un tas de pings de différentes tailles n'est pas 'simplificateur'. Et comme le rwin est 'scalé' à la taille supérieure, il y a de la marge induite dans mon usage du rtt depuis un unique ping 'MSS'...

Le choix de prendre les 'MAX' plutôt que la moyenne vient de l'idée qu'il faut mieux optimiser le RWIN dans les cas critiques, car pour les 'meilleures' conditions de ligne, TCP fait lui même une négociation de RWIN qui sera forcement plus faible que le RWIN paramétré, puisque meilleures conditions -> RTT plus faible.
Tenant compte du fait que le RWIN paramétré est le MAXIMUM autorisé, si tu prends les conditions moyennes (RTT moyen) pour ton calcul de RWIN, c'est bien 'optimisé' tant qu'elles restent à cette moyenne ou meilleures (RTT réel plus faible que cette moyenne), mais si les conditions se dégradent (RTT plus élevé que cette moyenne), même d'une manière infime mais permanente pendant ton usage, ta pile TCP ne pourra pas allouer plus que le RWIN paramétré, d'où génération de retransmissions, ... donc au final avec la moyenne on agrave encore plus les 'conditions de lignes plus mauvaises' (même si infimes)
La seule chose à laquelle je conscend c'est de rajouter à mon tuto qu'il ne faut pas prendre le 'maximum' sur un seul ping, mais d'abord réaliser plusieurs pings, éliminer de tous ces résultats les maximums qui sont vraiment hors normes par rapport à la moyenne de toutes les maximums, puis prendre le maximum des 'restants' à la place de 'Autrement : Notez la valeur "Maximum"' du point 3. On élimine ainsi les pings max 'farfelus'.

[vivien]

Voici des liens qui donnent plus d'information pour optimiser windows :

• http://www.zebulon.fr/articles/optimiserADSL_1.php
• http://www.dslvalley.com/dossiers/mtu/mtu.php
• http://www.n9ws.com/hotline/index.php?page=adsl_pc_tcpoptimizer

Pour afficher sa Rwin (pour les systéme qui ont des Rwin fixe comme XP) analysée par un serveur :
http://www.speedguide.net/analyzer.php

Rappel : sous Windows Vista et Linux la Rwin s'adapte automatiquement donc ce test est inutile et donneras pas de résultats corrects. (la rwin commence à une petite valeur et elle augmente au fur et a mesure de la connexion TCP si le réseau le permet)

Sous Windows XP on obtient un écran de ce type :

[feyb64]

Je tiens à préciser que les résultats obtenus via http://www.speedguide.net/analyzer.php ne sont pas toujours les valeurs EXACTES actuellement établies dans la pile TCP du système.
Il y a lieu donc de ne pas trop leur faire confiance mais juste donner une idée.
Charger TCPOptimizer et demander 'Current settings' est BIEN PLUS réel

[e-car]

Et pour Vista??
Faut-il suivre le même mode d'emploi pour optimiser?? ou y a t-il des valeurs automatiques ou qui s'adapte en fonction du réseau?? (je rêve un peu là....

[feyb64]

Et pour Vista??
Faut-il suivre le même mode d'emploi pour optimiser?? ou y a t-il des valeurs automatiques ou qui s'adapte en fonction du réseau?? (je rêve un peu là....

Et bien NON tu NE rêves PAS 

Vista a effectivement une pile tcp AUTO-Tunée qui choisira le rwin et autres paramètres en fonction de la ligne.
Il n'y a plus de 'RWin MAX'.
Comme indiqué ce tuto s'adresse à 2000 et XP
Si s'avait été aussi pour Vista, on l'aurai indiqué
(reste qu'il y a toujours des 'tunings' réseau à faire, sur Vista, 2008 ou même linux et autres 'nix', mais celà ne concerne pas l'objet du tuto uniquement sur le 'rwin' et paramètres en liaison avec lui. L'occasion d'autres tutos peut être si le besoin se fait sentir)

[vivien]

[e-car]

ok, merci pour les explications.
De toute façon, l'optimisation ne peut être vraiment visible que pour ceux qui download ou upload beaucoup. Pour 1 simple surf, ce ne sera pas le jour et la nuit.

[jyce]

Tres intéressant ce tuto.
Dans mon cas (citefibre customisé), j'obtiens ce résultat :

Code:

« SpeedGuide.net TCP Analyzer Results »
Tested on: 05.12.2008 10:14
IP address: 217.171.xx.xx
 
TCP options string: 020405ac01010402
MSS: 1452
MTU: 1492
TCP Window: 65535 (NOT multiple of MSS)
RWIN Scaling: 0
Unscaled RWIN : 65535
Reccomended RWINs: 63888, 127776, 255552, 511104
BDP limit (200ms): 2621kbps (328KBytes/s)
BDP limit (500ms): 1049kbps (131KBytes/s)
MTU Discovery: ON
TTL: 111
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

L'encapsulation PPPoE présente chez citefibre (bien que je ne vois pas son intérêt) force le MTU à 1492 alors qu'il est de 1500 sur un réseau local. Du coup il y a fragmentation des paquets par le routeur.
Je me demande si cette fragmentation n'induit pas un délai supplémentaire du RTT (et donc réduit le débit) ?!

[vivien]

A ce propos, les tests fait par Jyce (MSS: 1452 MTU: 1492) et moi (MSS: 1460 MTU: 1500) ne sont pas représentatifs des abonnés citéFibre / médiaFibre. Jyce a un routeur cisco chez lui (cf post ici) et moi j'ai un provisioning spécifique sans PPPoE qui, je le confirme ne sert strictement a rien. (on avait même prévu de l'enlever avec le successeur de la 3190).

D'après feyb64, la MTU avec une 3190 (citéFibre / MédiaFibre) est plutôt proche de 1400....