La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: 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 :
(https://lafibre.info/images/tuto/201503_impact_du_ping_sur_debit.png)
(https://lafibre.info/images/tuto/RWin.png)
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 (http://www.bortzmeyer.org/1323.html).
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)
-
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)
(https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x128_1.png)
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)
(https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x128_2.png)
Voici le fichier lisible avec Wireshark : 201503_win7_firefox31_https_ubuntu1404_rwin_scale_x128.pcapng.gz (https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x128.pcapng.gz)
-
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
(https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1_1.png)
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
(https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1_2.png)
Voici le fichier lisible avec Wireshark : 201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1.pcapng.gz (https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1.pcapng.gz)
-
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 ?
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.
-
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)
(https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1_3.png)
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)
(https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1_4.png)
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 (https://lafibre.info/testdebit/windows7/201503_win7_firefox31_https_ubuntu1404_rwin_scale_x1.pcapng.gz)
-
J'observe occasionnellement une anomalie : Windows
Bizarre.
Pour moi ce n'est pas qu'occasionnellement.
(je suis loin)
-
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%.
netsh int tcp set heuristics enabled enabled
-
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)
-
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:
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).
-
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...
(https://lafibre.info/testdebit/windows7/201503_tcpip_sys_windows7.png)
-
fait
wmic datafile where name="C:\\Windows\\System32\\drivers\\tcpip.sys" get version
-
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).
-
Version 6.1.7601.18438
Je n'ai pas appliqué le patch Microsoft, pour rester au plus proche de ce qu'on les clients.
Si je me souviens, en 2008R2/ 7 tu n'as plus la clé de registre qui permet de fixer RWin, donc le seul moyen de mettre une valeur c'est une option lorsque tu ouvres le socket avec l'API Win32 qui va bien.
Ce qui expliquerait ton comportement si c'est bien le module CAPI2 qui fait la vérification du certificat (composant système) alors que la gestion https est faite par le navigateur.
Tu as la possibilté de
1- tester avec un autre navigateur ?
2- avoir la sortie de netsh interface tcp show global pour savoir quel réglage tu as de l'algo de tuning? ( a priori ca devrait être normal) P.Ex.
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : disabled
Direct Cache Access (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : enabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
-
A noter que j'ai le souci qui apparait aussi lors d'une connexion http (je ne suis pas sur que le fait que le système soit informé que c'est ce soit https a part pour le port cible (443 vs 80) car le pb c'est dans le paquet SYN où pour une étrange raison, il manque des options)
L'auto-tuning est "normal", j'ai tout fait pour être représentatif de Mme Michu
Windows 7 Home 64bits :
C:\Users\Vivien>netsh interface tcp show global
Recherche du statut actif...
Paramètres TCP globaux
----------------------------------------------
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : automatic
État NetDMA : enabled
Accès direct au cache : disabled
Réglage auto fenêtre de réception : normal
Fournisseur de ctrl surcharge comp.: none
Fonctionnalité ECN : disabled
Horodatages RFC 1323 : disabled
L'horodatages RFC 1323 n'était pas activé sous Windows XP ?
Il me semble que si (même si cela bloquait ensuite si le serveur était sous Linux)
=> Timestamps - Horodatage TCP : Bug dans la pile TCP/IP de Windows ? (https://lafibre.info/serveur-linux/timestamps-horodatage-tcp/)
-
Windows 10 Pro 64bits Technical Preview Build 9926 : (Compaq 6510b Core2 Duo T8100 @2,10 GHz / 4Go RAM)
C:\Users\Vivien>netsh interface tcp show global
Recherche du statut actif...
Paramètres TCP globaux
----------------------------------------------
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : disabled
État NetDMA : disabled
Accès direct au cache : disabled
Réglage auto fenêtre de réception : normal
Fournisseur de ctrl surcharge comp. : none
Fonctionnalité ECN : disabled
Horodatages RFC 1323 : disabled
RTO initial : 3000
État RSC (Receive Segment Coalescing) : disabled
Résilience non Sack RTT : disabled
Retransmissions SYN max : 2
Windows 8.1 64bits : (Pré-installé par Dell sur un Core i3-4150 @3.50Ghz / 16 Go RAM)
C:\Users\Vivien>netsh interface tcp show global
Recherche du statut actif...
Paramètres TCP globaux
----------------------------------------------
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : disabled
État NetDMA : disabled
Accès direct au cache : disabled
Réglage auto fenêtre de réception : normal
Fournisseur de ctrl surcharge comp. : none
Fonctionnalité ECN : disabled
Horodatages RFC 1323 : disabled
RTO initial : 3000
État RSC (Receive Segment Coalescing) : disabled
Résilience non Sack RTT : disabled
Retransmissions SYN max : 2
Windows 8.0 64bits :
C:\Users\vivie_000>netsh interface tcp show global
Recherche du statut actif...
Paramètres TCP globaux
----------------------------------------------
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : disabled
État NetDMA : disabled
Accès direct au cache : disabled
Réglage auto fenêtre de réception : normal
Fournisseur de ctrl surcharge comp. : none
Fonctionnalité ECN : disabled
Horodatages RFC 1323 : disabled
RTO initial : 3000
État RSC (Receive Segment Coalescing) : disabled
-
'netsh' n'est plus supporté sous Windows 8.x/Server 2012 et Windows 10. Meme si la commande 'marchouille' encore sous ses systemes, il est recommandé d'utilisé Powershell (en mode admin) et les commandes (cmdlet): get-NetTCPSetting et set-NetTCPSetting
En effet il y a maintenant des 'profiles' (Internet, Datacenter, Custom, etc) pour les parametres TCP et il faut utiliser ces commandes pour y accéder.
La doc des commandes est la : https://technet.microsoft.com/fr-fr/library/hh826123.aspx
"get-NetTCPSetting Internet" permet de voir les parametres pour les connexions qui utilisent le profil "Internet" (usuellement utilisé pour acceder a Internet).
"get-NetTCPConnection" permet d'afficher les connexions en cours et voir leur profil (dernière colonne).
-
Ah oui, il y a plus de choses avec PowerShell...
On ne comprend pas bien quel profil est utilisé...
Windows 8.1 64bits : (Pré-installé par Dell sur un Core i3-4150 @3.50Ghz / 16 Go RAM)
Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. Tous droits réservés.
PS C:\Users\Vivien> get-NetTCPSetting
SettingName : Automatic
MinRto(ms) :
InitialCongestionWindow(MSS) :
CongestionProvider :
CwndRestart :
DelayedAckTimeout(ms) :
DelayedAckFrequency :
MemoryPressureProtection :
AutoTuningLevelLocal :
AutoTuningLevelGroupPolicy :
AutoTuningLevelEffective :
EcnCapability :
Timestamps :
InitialRto(ms) :
ScalingHeuristics :
DynamicPortRangeStartPort :
DynamicPortRangeNumberOfPorts :
AutomaticUseCustom :
NonSackRttResiliency :
ForceWS :
MaxSynRetransmissions :
SettingName : InternetCustom
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 4
CongestionProvider : CTCP
CwndRestart : False
DelayedAckTimeout(ms) : 50
DelayedAckFrequency : 2
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
AutomaticUseCustom : Disabled
NonSackRttResiliency : Disabled
ForceWS : Disabled
MaxSynRetransmissions : 2
SettingName : DatacenterCustom
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
DelayedAckFrequency : 2
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
AutomaticUseCustom : Disabled
NonSackRttResiliency : Disabled
ForceWS : Disabled
MaxSynRetransmissions : 2
SettingName : Compat
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 2
CongestionProvider : Default
CwndRestart : False
DelayedAckTimeout(ms) : 200
DelayedAckFrequency : 2
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
AutomaticUseCustom : Disabled
NonSackRttResiliency : Disabled
ForceWS : Disabled
MaxSynRetransmissions : 2
SettingName : Datacenter
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
DelayedAckFrequency : 2
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
AutomaticUseCustom : Disabled
NonSackRttResiliency : Disabled
ForceWS : Disabled
MaxSynRetransmissions : 2
SettingName : Internet
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 4
CongestionProvider : CTCP
CwndRestart : False
DelayedAckTimeout(ms) : 50
DelayedAckFrequency : 2
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
AutomaticUseCustom : Disabled
NonSackRttResiliency : Disabled
ForceWS : Disabled
MaxSynRetransmissions : 2
Windows 10 Pro 64bits Technical Preview Build 9926 : (Compaq 6510b Core2 Duo T8100 @2,10 GHz / 4Go RAM)
C'est strictement identique, sauf que sous "MaxSynRetransmissions : 2"
il ya deux nouvelles lignes qui sont à 0 pour tous les profils :
AutoReusePortRangeStartPort : 0
AutoReusePortRangeNumberOfPorts : 0
Windows 7 : Non supporté
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. Tous droits réservés.
PS C:\Users\Vivien> get-NetTCPSetting
Le terme « get-NetTCPSetting » n'est pas reconnu comme nom d'applet de commande, fonction, fichier de script ou programme exécutable. Vérifiez l'orthographe du nom, ou si un chemin d'accès existe, vérifiez que le chemin d'accès est correct et réessayez.
Au niveau de ligne : 1 Caractère : 18
+ get-NetTCPSetting <<<<
+ CategoryInfo : ObjectNotFound: (get-NetTCPSetting:String) [], CommandNotFoundException
-
On ne comprend pas bien quel profil est utilisé...
Chaque connexion a son profil:
"get-NetTCPConnection" permet d'afficher les connexions en cours et voir leur profil (dernière colonne).
-
Ok. tout est dans la classe "Internet"
Il y a eu une évolution des profils entre Windows 8 et Windows 8.1 :
Windows PowerShell
Copyright © 2012 Microsoft Corporation. Tous droits réservés.
PS C:\Users\vivie_000> get-NetTCPSetting
SettingName : Automatic
MinRto(ms) :
InitialCongestionWindow(MSS) :
CongestionProvider :
CwndRestart :
DelayedAckTimeout(ms) :
MemoryPressureProtection :
AutoTuningLevelLocal :
AutoTuningLevelGroupPolicy :
AutoTuningLevelEffective :
EcnCapability :
Timestamps :
InitialRto(ms) :
ScalingHeuristics :
DynamicPortRangeStartPort :
DynamicPortRangeNumberOfPorts :
SettingName : Custom
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Compat
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 2
CongestionProvider : Default
CwndRestart : False
DelayedAckTimeout(ms) : 200
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Datacenter
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Internet
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 4
CongestionProvider : CTCP
CwndRestart : False
DelayedAckTimeout(ms) : 50
MemoryPressureProtection : Disabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Disabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
-
fait
wmic datafile where name="C:\\Windows\\System32\\drivers\\tcpip.sys" get version
Je tente d'installer sur un Windows Serveur 2008 SP2 32bits le patch https://support.microsoft.com/en-us/kb/2762983 "TCP receive window autotuning feature does not work correctly in Windows Vista or in Windows Server 2008"
J'ai le droit au message d'erreur "La mise à jour ne s'applique pas à votre système."
L'article de Microsoft KB2762983 (https://support.microsoft.com/en-us/kb/2762983) indique que la version du patch est "Tcpip.sys 6.0.6002.22947"
Je regarde ma version de Tcpip.sys et c'est la version 6.0.6002.23370.
J'ai copié / collé l'intégralité des informations remontées par wmic datafile where name="C:\\Windows\\System32\\drivers\\tcpip.sys" mais je n'arrive pas a trouver la date du patch :
C:\Users\Administrator>wmic datafile where name="C:\\Windows\\System32\\drivers\\tcpip.sys"
AccessMask Archive Caption Compressed CompressionMethod
18809279 TRUE c:\windows\system32\drivers\tcpip.sys FALSE
CreationClassName CreationDate
CIM_LogicalFile 20140827104418.550903+120
CSCreationClassName CSName Description
Win32_ComputerSystem WINDOWS2008 c:\windows\system32\drivers\tcpip.sys
Drive EightDotThreeFileName
c: c:\windows\system32\drivers\tcpip.sys
Encrypted EncryptionMethod Extension FileName FileSize FileType
FALSE sys tcpip 915392 System file
FSCreationClassName FSName Hidden InstallDate InUseCount
Win32_FileSystem NTFS FALSE 20140827104418.550903+120
LastAccessed LastModified
20140827104418.550903+120 20140405052310.115785+120
Manufacturer Name
Microsoft Corporation c:\windows\system32\drivers\tcpip.sys
Path Readable Status System Version Writeable
\windows\system32\drivers\ TRUE OK FALSE 6.0.6002.23370 TRUE
D'où ma question : la version 6.0.6002.23370 est plus récente que la version 6.0.6002.22947 ?
Pourquoi la version 6.0.6002.23370 n'inclue pas le patch ? J'ai régulièrement des Rwin bridée à 64 Ko.
La version livré avec ce Windows Server 2008 SP2 semble la 6.0.6002.19080
Voici ma version de Windows Server 2008 : (j'ai bien tenté d'installer le patch x86)
A noter qu'il me dit "Cette copie de Windows n'est pas authentique" car je n'ai pas activé ma copie de windows (il me propose a chaque démarrage de l'activer et j'ai un fond d'écran noir, mais cela fonctionne bien)
-
D'où ma question : la version 6.0.6002.23370 est plus récente que la version 6.0.6002.22947 ?
Pourquoi la version 6.0.6002.23370 n'inclue pas le patch ? J'ai régulièrement des Rwin bridée à 64 Ko.
La version livré avec ce Windows Server 2008 SP2 semble la 6.0.6002.19080
Au vu de ce qui est dit dans http://blogs.technet.com/b/mrsnrub/archive/2009/05/14/gdr-qfe-ldr-wth.aspx c'est cohérent dans le schéma de numérotation.
Mais ça ne serait pas la 1ere fois qu'un hotfix introduit une régression...
Essaie de forcer le patch avec la procédure suivante : http://social.technet.microsoft.com/wiki/contents/articles/3323.how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx
-
D'où ma question : la version 6.0.6002.23370 est plus récente que la version 6.0.6002.22947 ?
oui et les 2 sont en LDR.
la 6.0.6002.23370 correspond au patch de securité: MS14-031 (https://support.microsoft.com/en-us/kb/2957189)
Pourquoi la version 6.0.6002.23370 n'inclue pas le patch ? J'ai régulièrement des Rwin bridée à 64 Ko.
Elle devrait, a moins d'une régression du a un patch quelque part entre les 2. Il faudrait rechercher en détails dans l'historique des patchs (wmic qfe list /format:table)
-
La 6.0.6002.23370 est bien celle du patch que j'avais déjà installé, j'ai fais un test sur un VM neuve.
C'est juste Microsoft qui m'a troublé en parlant sur son site de la 6.0.6002.22947, probablement une erreur : Cela ne correspond ni à la version du Service Pack 2 (6.0.6002.19080) ni à celle du patch (6.0.6002.23370)
Pour les pb de perf (rencontrés avec curl), je vais faire un comparatif curl vs Firefox pour voir si j’obtiens bien les mêmes performances.