Auteur Sujet: Bug Rwin limitée à 65ko avec Windows 7 (Lu 12785 fois)

vivien · « **le:** 15 mars 2015 à 14:50:21 »

Bug Rwin limitée à 65ko avec Windows 7 SP1 64bits

J'observe occasionnellement une anomalie : Windows limite la Rwin à 64 Ko (il manque l'option TCP window scale dans le paquet SYN qui établi la connexion)

Je vais un peu expliquer ce que c'est que le TCP window scale (RFC 1323), ceux qui connaissent, ils peuvent passer au post suivant :

Un protocole simple et peu performant consisterait à envoyer un paquet et attendre l’acquittement pour envoyer le suivant. Problème :si la latence aller/retour (ping) n'est pas trés faible, le débit est quasi nul.
TCP est un protocole performant qui a une fenêtre d’acquittement : la Rwin, exprimée en octet.
La taille de la fenêtre n'est stockée que sur 16 bits, ne permettant pas un rwin plus grande que 65 535 octets.

Comme vous pouvez le voir sur le graphique-ci dessous, c'est très pénalisant pour le haut débit :

A partir de 1992 la RFC 1323 TCP Extensions for High Performance permet d'augmenter presque à l'infinie cette Rwin.
Un explication en Français de la RFC 1323 est disponible sur le blog de Stéphane Bortzmeyer.

La RFC 1323 rajoute une option à TCP pour multiplier la Rwin. C'est une option qui ne casse pas la compatibilité : un système non compatible va ignorer l'option qu'il ne connais pas.

Le premier octet d'une option indique son type, ce qui permet au système d’exploitation de savoir si il connaît cette option. Pour TCP Windows scale, c'est 3.

Le second octet d'une option indique la rongeure de l'option. Les options TCP se suivent et la longueur d'une option varie selon l'option. Le champ longueur permet donc de savoir où commence l'option suivante. Pour TCP window scale la longueur est de 3 (1 octet pour le type, un pour la longueur et un pour la valeur du multiplicateur, soit 3 octets)

La valeur est un octet qui indique de combien de bits on va décaler la taille de la fenêtre :
- 0 : pas de décalage (Rwin max de 65 Ko)
- 1 : multiplication de la fenêtre par 2 (Rwin max de 131 Ko)
- 2 : multiplication de la fenêtre par 4 (Rwin max de 262 Ko)
- 3 : multiplication de la fenêtre par 8 (Rwin max de 524 Ko)
- 4 : multiplication de la fenêtre par 16 (Rwin max de 1,0 Mo)
- 5 : multiplication de la fenêtre par 32 (Rwin max de 2,1 Mo)
- 6 : multiplication de la fenêtre par 64 (Rwin max de 4,2 Mo)
- 7 : multiplication de la fenêtre par 128 (Rwin max de 8,4 Mo)
- 8 : multiplication de la fenêtre par 256 (Rwin max de 17 Mo)
- 9 : multiplication de la fenêtre par 512 (Rwin max de 34 Mo)
- 10 : multiplication de la fenêtre par 1024 (Rwin max de 67 Mo)
- 11 ect...

Généralement, le multiplicateur utilisé est entre 32 (Rwin maximum de 2,1 Mo) et 512 (Rwin maximum de 34 Mo)

vivien · « **Réponse #1 le:** 15 mars 2015 à 14:52:12 »

Voici un exemple où tout se passe bien :

Client : Windows 7 RC1 64 bits (avec toutes les maj) + Firefox 36.0.1
Protocole : IPv4 / TCP / https
Serveur : Linux Ubuntu Server 14.04 64bits (avec toutes les maj)

Paquet [SYN] émis par le client Windows 7 avec options TCP de 12 octets
=> Option Windows Scale : "03 03 08" => multiplicateur de 256 (Rwin max de 17 Mo)

Réponse [SYN, ACK] du serveur Ubunutu 14.04 avec options TCP de 12 octets
=> Option Windows Scale : "03 03 07" => multiplicateur de 128 (Rwin max de 8,4 Mo)

Voici le fichier lisible avec Wireshark : 201503_win7_firefox31_https_ubuntu1404_rwin_scale_x128.pcapng.gz

vivien · « **Réponse #2 le:** 15 mars 2015 à 14:57:11 »

Voici un exemple où la Rwin est limitée à 65 Ko :

Bug de Microsoft ?

Le phénomène est reproductible (dans 2% des captures)
Il existe quand je fais des requêtes http ou https, que ce soit sur un serveur récent (Ubuntu 14.04 LTS) ou un serveur ancien (CentOS 5)

Client : Windows 7 RC1 64 bits (avec toutes les maj) + Firefox 36.0.1
Protocole : IPv4 / TCP / https
Serveur : Linux Ubuntu Server 14.04 64bits (avec toutes les maj)

Paquet [SYN] émis par le client Windows 7 avec options TCP de ~~12 octets~~ 8 octets
=> Il manque l'option Windows Scale => Rwin max de 65Ko

Réponse [SYN, ACK] du serveur Ubunutu 14.04 avec options TCP de ~~12 octets~~ 8 octets
=> Il manque l'option Windows Scale => Rwin max de 65Ko

Voici le fichier lisible avec Wireshark : 201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1.pcapng.gz

kgersen · « **Réponse #3 le:** 15 mars 2015 à 15:36:41 »

c'est quoi ton type de réseau (domestique, bureau, public)?

c'est peut-être lié a : https://support.microsoft.com/en-us/kb/2780879 ?

Citer

By default, the TCP window scaling feature is disabled after the second retransmission of a SYN packet in a three-way handshake in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

bien que je ne vois pas de "seconde retransmission" dans ton cas, il y a peut-être une corrélation.

vivien · « **Réponse #4 le:** 15 mars 2015 à 16:53:18 »

Environnement :
- Hardware : Dell Inspiron 660, 8Go DDR3 et Core i3-2120 @3,3 Ghz
- OS : Windows 7 Édition Familiale Premium SP1 64bits pré-installé par Dell
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Firefox 36.0.1 (32bits)
- Réseau : Bbox ADSL Sagem F@st 3965b IPv4 uniquement connexion Ethernet (lien 1 Gb/s Ethernet entre le PC et la Bbox)
- Ligne ADSL : 5 Mb/s sans CRC (correction de pertes de paquet au niveau des couches basses)

Je suis pas sur que le bug corresponde à l'Article ID: 2780879 :
1/ J'avais dans les différents cas redémarré le PC peu de temps avant la capture
2/ La ligne ADSL est d’excellente qualité (pas de perte de paquet, j'ai vérifié sur de long transferts, il y a une retransmission au niveau ATM sur la Bbox)
3/ Les connexions suivantes ont un TCP window scaling qui est de plusieurs Mo.

On est sur le même transfert https où le TCP window scaling était désactivé.

Paquet [SYN] émis par le client Windows 7 pour vérifier si le certificat est révoqué : options TCP de 12 octets
=> Option Windows Scale : "03 03 08" => multiplicateur de 256 (Rwin max de 17 Mo)

Réponse [SYN, ACK] du serveur qui dit si le certificat est révoqué avec options TCP de 12 octets
=> Option Windows Scale : "03 03 05" => multiplicateur de 32 (Rwin max de 2,1 Mo)

Donc le transfert https se fait avec une Rwin max de 65 Ko alors que la vérificaiotn du certificat se fait avec une Rwin max de 2,1 Mo !

Voici le fichier lisible avec Wireshark : 201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1.pcapng.gz

BadMax · « **Réponse #5 le:** 15 mars 2015 à 17:07:08 »

Citer

J'observe occasionnellement une anomalie : Windows

Bizarre.

Pour moi ce n'est pas qu'occasionnellement.

(je suis loin)

kgersen · « **Réponse #6 le:** 15 mars 2015 à 18:37:41 »

oui bizarre.

Ca le fait avec autre chose que Firefox ?

Concernant le KB2780879 meme si ca ne parait pas lié, pour autant c'est peut-être ce que corrige ce patch.
Car le probleme avec les patch notes de MS et des produits dont on a pas le source en général, c'est qu'ils racontent un peu ce qu'ils veulent dans le descriptif du patch, souvent sans entrer dans les détails ou en excluant d'autres aspects ou cas corrigés par le patch.

Essais en forçant l'heuristique , pour voir si t'as toujours 2%.

Code: [Sélectionner]

netsh int tcp set heuristics enabled enabled

pasbefri · « **Réponse #7 le:** 15 mars 2015 à 19:32:37 »

Citation de: vivien le 15 mars 2015 à 16:53:18

Environnement :
Je suis pas sur que le bug corresponde à l'Article ID: 2780879 :

Il m'a l'air d'être ancien ce hotfix... Il te donne quoi en version de tcpip.sys ?

As-tu essayé les versions livrées avec le KB 2896146 ? (Ou 2905412 mais j'ai un doute si le système l'acceptera en version Home)

kgersen · « **Réponse #8 le:** 15 mars 2015 à 20:19:25 »

C'est pas forcement le meme tcpip.sys, Y'a le LDR et le GDR (service branch).

Le dernier en date vient du MS14-031 (http://support.microsoft.com/en-us/kb/2957189) , update de sécurité publié le 10 juin 2014 donc a jour si le poste est a jour.

Suivant "son passé", on a le GDR ou LDR si on a appliqué ou pas un hotfix avant.

si la version est 6.1.7601.22xxx on a le LDR et 6.1.7601.18xxx on a le GDR. (bouton droit , propriétés, onglet détail sur c:\windows\system32\drivers\tcpip.sys) ou en ligne de commande:

Code: [Sélectionner]

wmic datafile where name="C:\\Windows\\System32\\drivers\\tcpip.sys" get version
Chez moi je suis en 6.1.7601.22648 donc en LDR.

Apres je ne sais pas si son probleme vient forcement de tcpip.sys.

edit - pour etre plus clair: appliqué le 2780879 fait passer tcpip.sys ( et d'autres fichiers) en LDR donc ensuite toutes les maj ultérieures de ce fichier seront en version LDR. La raison est que 2780879 n'est pas un patch de l'autoupdate mais un hotfix qu'il faut volontairement appliqué (LDR= Limited Distribution Release).

vivien · « **Réponse #9 le:** 17 mars 2015 à 15:42:23 »

Citation de: pasbefri le 15 mars 2015 à 19:32:37

Il te donne quoi en version de tcpip.sys ?

Je ne sais pas comment voir les versions, mais je note que j'ai plusieurs tcpip.sys et qu'ils ont des tailles différentes...

kgersen · « **Réponse #10 le:** 17 mars 2015 à 17:03:36 »

fait

Code: [Sélectionner]

 wmic datafile where name="C:\\Windows\\System32\\drivers\\tcpip.sys" get version

vivien · « **Réponse #11 le:** 17 mars 2015 à 17:07:37 »

Version 6.1.7601.18438

Je n'ai pas appliqué le patch Microsoft, pour rester au plus proche de ce qu'on la plupart des personnes (j'ai pris windows 7, car c'est l'OS le plus représentatif).