Auteur Sujet: Impact du ping sur le très haut débit en fonction du système d'exploitation  (Lu 66909 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 916
    • Twitter LaFibre.info


Les performances de Windows Vista sont identiques à celles de Windows 7.
Les performances de MacOS X 10.5 ou supérieur sont proche de Linux Ubuntu.

vivien

  • Administrateur
  • *
  • Messages: 47 916
    • Twitter LaFibre.info
Vous l'avez compris, la fenêtre de réception TCP (RWin) est la cause de la limitation de débit observé avec Windows.

Windows XP à une RWin fixe qu'il est possible de modifier via la base de registre.
Attention : Une RWin trop importante peut faire s'écrouler les débits : Les données envoyées et non acquittées peuvent être stockés dans des buffer sur des équipements du réseau (ou du modem) et si la capacité de ces buffers est dépassé, de nombreux paquets seront supprimés, entraînant de nombreuses ré-émissions et une chute du débit utile.

Les systèmes d'exploitations modernes ont une RWin dynamique : Si la connexion est bonne et le permet alors la RWin augmente. Si la connexion ne permet pas de RWin importante, la RWin n'augmente pas. En cas de pertes de paquet, la RWin peut même diminuer.

La limitation à 255 Ko maximum de la Rwin de Windows Vista et Windows 7 est lié à une limitation des API WinINet et WinHTTP. Il est complexe du supprimer cette limitation (je pense vous expliquer la méthode dans un prochain post, cela nécessite plusieurs modifications dans la base de registre).

FileZilla est un client FTP qui est développé pour na pas utiliser la RWin du système d’exploitation. A partir de Windows XP SP1, il est possible pour une application de modifier la RWin qu'elle va utiliser. La RWin de FileZilla est de 4 Mo fixe avec Windows XP et dynamique avec un maximum de plusieurs Mo avec Windows Vista et Windows 7.


vivien

  • Administrateur
  • *
  • Messages: 47 916
    • Twitter LaFibre.info
Il n'est nécessaire de régler la MTU que pour les FAI qui font du PPPoE (PPPoE seul prend 6 octets, en cas de LNS, le MTU baisse de 20 octets).

Avec du PPPoA ou de l'IPoE (Free dégroupé) ou encore de l'IPoA (Bouygues Telecom dégroupé Dolmen et dégroupé OVH), la MTU est de 1500.

Dans le cas de mes tests, j'ai réalisé le graphe en me mettant dans un cas idéal : le client est relié directement au serveur. Je fais varier la latence avec un PC équipé de NetEm qui j'insert entre le client et le serveur. La MTU est donc de 1500.

DomZ

  • Abonné SFR THD (câble)
  • *
  • Messages: 24
  • La Verrière 78
La limitation à 255 Ko maximum de la Rwin de Windows Vista et Windows 7 est lié à une limitation des API WinINet et WinHTTP.
Il y a sûrement une raison technique qui fasse que Microsoft ait "bridé" le RWin, sinon pourquoi aurait-il fait cela ?

vivien

  • Administrateur
  • *
  • Messages: 47 916
    • Twitter LaFibre.info
Microsoft à bridé le multiplicateur de la Rwin de windows 7 à 4 (4 x 64 = 256 Ko) au cas où des entreprises auraient des vieux équipements qui ne prennent pas en compte ce multiplicateur. En effet de vieux équipements (plus en service aujourd'hui je vous rassure) ne sont pas compatible avec une Rwin > 64 Ko. En mettant un multiplicateur x128 si windows indique avoir une rwin de 256 Ko (2x128) alors l'équipement incompatible comprendra 2 Ko de Rwin. Avec un multiplicateur plus faible la perte de performances avec les équipements incompatible est plus faible. C'est donc un compromis entre les performances avec du matériel actuel et du matériel ancien qui n'est plus en service aujourd'hui.

Il faut que je réalise le tutoriel, quelques modifications dans la base de registre permet d'avoir un comportement du type Linux ou Filezilla sous windows.

  • Invité
Rappelons tout d'abord que dans TCP les indications de quantité de données sont exprimées en un nombre d'octets, parce que TCP transmet des octets (pas des bits, des quadruplets, des mots). La Receive Window est une quantité de données donc un nombre d'octets.

La Receive Window effectue le contrôle de flux de TCP afin qu'un récepteur lent (ou puissant mais débordé!) ne soit pas saturé par les données reçues. Cette valeur correspond à la quantité de données que le récepteur croit pouvoir accepter dans l'immédiat. Le terme de contrôle de flux doit être pris avec des pincettes parce qu'il ne s'agit pas d'un port série où les données doivent être prises en compte impérativement pour ne pas être perdues : l'èmetteur TCP doit de toute façon garder toutes les données envoyées dont il ne sait pas qu'elles ont été reçues. Un récepteur qui annoncerait une RWin large mais qui se retrouverait saturé n'aurait qu'à ignorer les segments TCP qu'il ne sait pas gérer et l'envoyeur les retransmettrait plus lentement, en fonction de la RWin réduite annoncée.

La RWin n'est donc pas une garantie formelle de pouvoir accepter des données (heureusement), mais tout récepteur qui aurait la RWin plus gros que le ventre aurait une performance médiocre puisque l'envoyeur essaierait de saturer le récepteur en permanence.

Précisons qu'historiquement la RWin est un entier positif x codé sur 16 bits, donc limité à 64 Ko. Il n'était pas question de changer la taille du champ (donc réorganiser l'entête TCP, donc faire un TCPv2 à la place de TCPv1, comme IPv6 à la place d'IPv4) juste pour changer ça : il fallait ruser un peu pour faire rentrer plus de bits dans le formalisme de l'entête TCP, tout en maintenant la plus grande compatibilité possible : le code de TCP ne sait pas a priori si celui qui est en face est une implèmentation historique ou moderne de TCP.

Heureusement les concepteurs de TCP savaient bien dès le départ que le protocole serait perfectionné et ils ont prévu un mécanisme d'extension : les options TCP. Les options ne doivent servir qu'à des extensions qui ne sont pas obligatoires pour communiquer, sinon on aurait meilleur compte de définir un TCPv2 entièrement nouveau. (IP dispose aussi d'un tel système d'extensions optionnelles.)

Il faut donc que l'entête TCP soit compréhensible par une implèmentation historique qui regarde juste le champ RWin de 16 bits. Il faut donc (à peu près) conserver de sens ce champ.

Par ailleurs, si la possibilité de rajouter des informations par des options est précieuse, il ne faut pas non plus gaspiller la place disponible dans un paquet TCP avec une tripoté d'options encombrantes : le but est d'améliorer les performances pas de les diminuer. La possibilité de définir une option TCP "RWin vraie" codée sur plus de 16 bits qui supplanterait la RWin sur 16 bits de l'entête n'a pas été retenue, sans doute pour cette raison.

On peut remarquer que la possibilité d'indiquer une RWin de 1534111 octets exactement n'a aucun sens puisque la RWin est juste une estimation de la capacité de traitement future et pas une garantie sur la taille d'une zone mémoire réservée, donc la résolution de l'indication de la RWin n'a pas besoin d'être à l'octet près : il faut juste une précision relative correcte.

La RWin en octets peut maintenant être codée comme
RWin = x * 2**y
c'est à dire un entier multiplié par une puissance de 2.
x est codé par la RWin historique de l'entête TCP.
y est indiqué par une option TCP transmise par le récepteur TCP lors de l'ouverture de la connexion, appelé Window Scaling

Les contraintes sont donc :
1) pour un récepteur TCP x est variable mais y est une constante
2) de plus pour un TCP envoyeur historique qui ne comprend pas cette option TCP, RWin = x

Il faut donc dans ces contraintes choisir a priori une bonne valeur pour y avant qu'un seul octet soit transmis dans le TCP. Si dès que la RWin est plus grande que gRWin, on veut qu'un TCP envoyeur historique reçoive l'indication de RWin d'au moins hRWin (x >= hRWin), alors il faut limiter la valeur de y à log2 (gRWin / hRWin) ce qui limite la RWin annoncée (pour un envoyeur TCP moderne) à
x * 2**y
avec x = 64 K
et y = log2 (gRWin / hRWin)
soit RWin < 64 K * 2**log2 (gRWin / hRWin) = 64 K * gRWin / hRWin

Si on veut une performance optimale avec une implèmentation historique dès que la RWin dépasse gRWin, alors (hRWin = 64 Ko) on limite la RWin réelle à gRWin.

Si on suppose que la RWin va rarement baisser significativement, on peut prendre gRWin très grand, et donc avoir une bonne performance dans tous les cas.

Grincheux

  • Technicien agréé Orange et Bouygues Telecom
  • Abonné Orange adsl
  • *
  • Messages: 131
  • Mathenay (39)
Une partie des réponses aux questions de mon post précédent se trouve dans le post de vivien. Je viens aussi d'y découvrir qu'en plus de l'OS, certains softs optimisent les transferts.

Cela remet ma question "Optimiser, mais jusqu'où" d'actualité.

  • Invité
Impact du ping sur le très haut débit en fonction du système d'exploitation
« Réponse #7 le: 09 octobre 2011 à 15:19:30 »
Bonjour tout le monde,
vivien pourrais tu si il te plait nous donné la manip a effectué pour retiré la limitation de windows 7 pour le rwin, merci.

vivien

  • Administrateur
  • *
  • Messages: 47 916
    • Twitter LaFibre.info
Impact du ping sur le très haut débit en fonction du système d'exploitation
« Réponse #8 le: 11 octobre 2011 à 19:24:10 »
Non, je devrais avoir les infos demain ou après-demain.

Si je connaissais directement la manip je l'aurais donné :-)

  • Invité
Impact du ping sur le très haut débit en fonction du système d'exploitation
« Réponse #9 le: 11 octobre 2011 à 22:11:26 »
C'est sympa vivien, je doute bien que c'est pas facile, j'ai effectué des recherche chez technet msdn et tout les sites les plus connu dans ce domaine, mais il n'y figure pas la manip.
J'espere avoir une reponse demain et que tu arrive a obtenir quelque chose, si non ben on aura pas le choix dans resté a notre sort LoL.

  • Invité
Impact du ping sur le très haut débit en fonction du système d'exploitation
« Réponse #10 le: 14 octobre 2011 à 23:38:26 »
Salut vivien, toujours pas de nouvelle?

  • Invité
Impact du ping sur le très haut débit en fonction du système d'exploitation
« Réponse #11 le: 19 octobre 2011 à 21:07:46 »
Salut vivien, tu n'a toujours pas pu recupéré la manip?
Merci d'avance pôur la reponse.