warum ist der Download von Windowsservern langsamer als von Linuxservern?

[Poison Nuke 10]

Hio,

 

ist mir heute erschreckenderweise aufgefallen, wenn ich von einem HTTP Server auf Windows etwas übers Internet runterlade, dann sind diese oft deutlich langsamer als ein Linuxserver.

 

 

Ausgangssituation:

 

mehrere Windowsserver mit Apache und auch IIS zum testen, dedizierter 100Mbit Switchport für jeden Server als Gegenpart ein paar Linuxserver, teilweise am gleichen Switch wie die Windowsserver.

 

Als Test wurden einfach ein paar große Files mit Zufallszahlen erzeugt (/dev/urandom), und es wurde über HTTP heruntergeladen, entweder Internet Explorer, Firefox, oder wget auf einem Linuxclient.

 

 

Innerhalb des gleichen Rechenzentrums 11MB/s von jedem Server.

grundlegend funktioniert es also.

von einem anderen Rechenzentrum des gleichen Providers aus auch voller Speed, allerdings läuft es hier schon über einen zentralen Router, der auch die Verbindung zur Außenwelt darstellt.

 

Sobald man dann aber von einem anderen Rechenzentrum in Deutschland runterlädt, haben die Windowsserver allesamt so 3-4MB/s, die Linuxserver schaffen die 10-11MB/s.

 

 

irgendwelche Filterregeln auf den Routern scheiden aus, es wurde sogar schon testweise ein Windowsserver mit gleichen IPs mit Linux neuinstalliert, danach ging der auch schnell.

 

 

Ergo alle Tests die gemacht wurden lassen nur eine Schlussfolgerung zu: Windows verursacht ein Problem. Dabei ist es egal welche Version. Getestet wurde mit 2k3 bis hin zu 2k8R2

 

gerade eben nochmal auf einem extra dafür auserkorenen Testserver Debian Lenny und Win2k8R2 im Dualboot installiert, auf Windows Xampp mit Apache, alles in Grundkonfiguration, ohne irgendwelchen Einstellungen. Beim Runterladen vom Windowsserver blieb es wieder bei 4MB/s stehen, als ich dann Linux gebootet hatte hatte ich dann wieder schöne 10-11MB/s.

 

 

das verwunderliche ist ja, im "lokalen" Netz geht es ja, erst wenn der DeCIX dazwischen ist oder einer der anderen großen Knotenpunkte, wird es langsam. Aber dass der DeCIX filtert glaub ich wohl nicht, zudem, woher sollte der wissen, ob das IP Paket von einem Apache unter Windows oder einem Apache unter Linux losgeschickt wurde.

[LukasB 10]

TCP Window Size, Unterschiedliche Window-Scaling Mechanismen, Diverse TCP-Offload Features die Linux meist garnicht unterstützt und die unter Windows mehr Schaden anrichten als sie nützen.

 

Vergleich doch mal einfach mal die TCP Header eines Windows- mit einem Linux-Download. Dann solltest du schnell sehen woran es liegt.

[Poison Nuke 10]

verdammt...gibt es da irgendwie ein Workaround, wie z.B. diese Offload mechanismen Deaktivieren oder so? In den Netzwerkeigenschaften ist IPv4 das einzige was ich noch aktiv gelassen habe alles andere ist schon deaktiviert.

[Hr_Rossi 10]

verdammt...gibt es da irgendwie ein Workaround, wie z.B. diese Offload mechanismen Deaktivieren oder so? In den Netzwerkeigenschaften ist IPv4 das einzige was ich noch aktiv gelassen habe alles andere ist schon deaktiviert.

 

Hallo schau mal hier,

 

An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers

 

http://support.microsoft.com/kb/224829/de

 

lg

[Poison Nuke 10]

der Patch hat leider nicht geholfen, außer dass Windows erstmal nen Hardreboot brauchte um wieder hochzufahren.

 

 

bei dem zweiten...hm, da müsste man erstmal wissen welche Einstellungen optimal sind. Gibt es da keine Erfahrungswerte?

[Hr_Rossi 10]

Vergleich doch mal einfach mal die TCP Header eines Windows- mit einem Linux-Download. Dann solltest du schnell sehen woran es liegt.

 

Hast du das schon gemacht ?

 

 

 

 

 

lg

[Poison Nuke 10]

ja...keine Ahnung was ich da sehen soll ich bin zwar Netzwerkadmin und weiß wie nen TCP Handshake abläuft und wie sequenzen usw aussehen sollten, aber hier weiß ich ganz ehrlich nicht nach was ich Ausschau halten sollte.

 

 

Windowsserver:

13:09:06.648897 IP (tos 0x0, ttl 64, id 23437, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x251c (correct), win 114 <nop,nop,timestamp 2423242119 110780>
13:09:06.648991 IP (tos 0x0, ttl 123, id 4899, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 4345:5793(1448) ack 12,timestamp 110780 2423242116>
13:09:06.648998 IP (tos 0x0, ttl 64, id 23438, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x1f5d (correct), win 137 <nop,nop,timestamp 2423242119 110780>
13:09:06.649319 IP (tos 0x0, ttl 123, id 4900, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 5793:7241(1448) ack 12,timestamp 110780 2423242116>
13:09:06.649326 IP (tos 0x0, ttl 64, id 23439, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x199f (correct), win 159 <nop,nop,timestamp 2423242119 110780>
13:09:06.649565 IP (tos 0x0, ttl 123, id 4901, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 7241:8689(1448) ack 12,timestamp 110780 2423242116>
13:09:06.649571 IP (tos 0x0, ttl 64, id 23440, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.43794 > 87.118.122.12.80: ., cksum 0x13e0 (correct), win 182 <nop,nop,timestamp 2423242119 110780>
13:09:06.660930 IP (tos 0x0, ttl 123, id 4902, offset 0, flags [DF], proto TCP (6), length 1500) 87.118.122.12.80 > 188.40.42.85.43794: . 8689:10137(1448) ack 1p,timestamp 110780 2423242119>

 

 

 

 

Linux:

13:08:56.918352 IP (tos 0x0, ttl 59, id 51462, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15709353:15710801(144op,nop,timestamp 4144230258 2423239683>
13:08:56.918496 IP (tos 0x0, ttl 59, id 51463, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15710801:15712249(144op,nop,timestamp 4144230258 2423239683>
13:08:56.918500 IP (tos 0x0, ttl 64, id 19350, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0xb94c (correct)12249 win 7399 <nop,nop,timestamp 2423239686 4144230258>
13:08:56.918598 IP (tos 0x0, ttl 59, id 51464, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15712249:15713697(144op,nop,timestamp 4144230258 2423239683>
13:08:56.918742 IP (tos 0x0, ttl 59, id 51465, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15713697:15715145(144op,nop,timestamp 4144230258 2423239683>
13:08:56.918746 IP (tos 0x0, ttl 64, id 19351, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0xadfb (correct)15145 win 7399 <nop,nop,timestamp 2423239687 4144230258>
13:08:56.918989 IP (tos 0x0, ttl 64, id 19352, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0xa2ab (correct)18041 win 7399 <nop,nop,timestamp 2423239687 4144230258>
13:08:56.919237 IP (tos 0x0, ttl 64, id 19353, offset 0, flags [DF], proto TCP (6), length 52) 188.40.42.85.49254 > 193.22.254.100.80: ., cksum 0x975b (correct)20937 win 7399 <nop,nop,timestamp 2423239687 4144230258>
13:08:56.938054 IP (tos 0x0, ttl 59, id 51575, offset 0, flags [DF], proto TCP (6), length 1500) 193.22.254.100.80 > 188.40.42.85.49254: . 15872977:15874425(144op,nop,timestamp 4144230264 2423239688>

 

 

wenn ich ehrlich bin sieht das für mich sogar ziemlich identisch aus.

Oder muss ich noch mehr anzeigen lassen... mehr kann ich mir von tcpdump gar nicht mehr anzeigen lassen.

[Hr_Rossi 10]

hmm

 

lade mal den tcpdump in ein wireshark...

 

Butschek.de Analyse mit tcpdump/wireshark

 

und vergleiche mal beide... vielleicht fällt dir dort etwas auf...

 

lg

[LukasB 10]

Guck mal die Window Sizes an:

 

Windows: win 182

Linux: win 7399

 

Die Window-Size unter Windows ist zu klein um schnellen Link mit höherer Latenz nutzen zu können.

[Poison Nuke 10]

ok, eine Window-Size von 91 bei Linux vs 65412 bei Windows.

 

spielst du auf diesen Unterschied an? Sonst seh ich da keinen weiteren Unterschied.

Hm, ich dachte immer eine größere WindowSize würde das ganze beschleunigen, weil der Gegenüber länger mit dem ACK warten kann, bei einer kleineren Size muss ja dauernd bestätigt werden.

 

Oder versteh ich das falsch?

[Poison Nuke 10]

keine Ideen? Soll ich die WindowsSize vllt einfach mal kleiner machen? Zudem, laut dem Artikel der weiter oben verlinkt ist, kann man ja nur sagen wie die EMPFANGSfenstergröße aussehen soll. Also sagt ja der Remotehost, wie groß sein TCP Fenster ist.

 

Der Server der sendet sagt lediglich, hier du kannst mir x Daten mit einmal schicken, aber braucht der Host ja gar nicht, er schickt ja nur ACK zurück.

Also wäre die Frage, hat diese Einstellung wirklich einen Einfluss? Und wenn ja, warum wirkt es sich negativ aus das Windows so eine große Size hat, bzw Linux so eine extrem kleine und warum unterscheiden sich die Werte bei mir in beiden Fällen so stark von denen von LukasB?

[Windowsbetatest 10]

Hallo,

 

also die ca. 80k Windows Size bei Windows ist ja soweit OK.

 

Aber der Linux Wert von ca. 180 passt nicht.

 

Könnte es sein, das Wireshark Byte und tcpdump Pakete angibt?

 

Dann hätte Linux, bei einer MTU von 1500 Byte, etwa ein 270 KB Window.

 

Dies würde die deutlich besseren Performancewerte erklären. Ein dreimal so großes Window, hat bei gleicher Latenz die dreifache Datenübertragungskapazität.

 

Die 64K bei Windows, sind das Standard TCP Window.

 

Surf mal zu http://www.speedguide.net/analyzer.php und poste mal das jeweilige Ergebnis.

 

mfg

[Poison Nuke 10]

wenn du mir noch einen Tipp gibst wie man die Seite in Linux textmodus öffnen kann...weil das kennt kein JS und werd ich auch sicher nicht deswegen auf einem produktiven Server installieren.

 

hier isses für den Windows Server:

 

« SpeedGuide.net TCP Analyzer Results » 
Tested on: 03.11.2010 16:48 
IP address: 87.118.xxx.xx 
Client OS: Windows Server 2003 

TCP options string: 020405b401010402 
MSS: 1460 
MTU: 1500 
TCP Window: 65535 (NOT multiple of MSS) 
RWIN Scaling: 0 bits  
Unscaled RWIN : 65535 
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 
BDP limit (200ms): 2621kbps (328KBytes/s)
BDP limit (500ms): 1049kbps (131KBytes/s) 
MTU Discovery: ON 
TTL: 117 
Timestamps: OFF 
SACKs: ON 
IP ToS: 00000000 (0) 

[Windowsbetatest 10]

Hallo,

 

die Zeile

 

BDP limit (200ms): 2621kbps (328KBytes/s)

 

beschreibt dein Problem sicherlich ziemlich gut.

 

Dein Linuxserver scheint vorbildlich installiert zu sein und somit sollte dies nicht nötig sein, wäre nur nett gewesen, es zu sehen.

 

Dein Problem ist das hier.

 

RWIN Scaling: 0 bits

 

Ich würde diesen Wert testweise mal auf 1 Bit setzen und der Speed müsste sich verdoppeln. Optimal sollte ein Wert von 4 sein.

 

Anwendung auf eigen Gefahr.

 

Description of Windows 2000 and Windows Server 2003 TCP Features

[Poison Nuke 10]

ok, Value wurde auf 2 bits gestellt

 

« SpeedGuide.net TCP Analyzer Results » 
Tested on: 03.11.2010 17:55 
IP address: 87.118.xxx.xx 
Client OS: Windows Server 2003 

TCP options string: 020405b40103030201010402 
MSS: 1460 
MTU: 1500 
TCP Window: 256960 (multiple of MSS) 
RWIN Scaling: 2 bits (2^2=4) 
Unscaled RWIN : 64240 
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 
BDP limit (200ms): 10278kbps (1285KBytes/s)
BDP limit (500ms): 4111kbps (514KBytes/s) 
MTU Discovery: ON 
TTL: 117 
Timestamps: OFF 
SACKs: ON 
IP ToS: 00000000 (0) 

 

 

aber ich bekomm immernoch nicht mehr als 3,5MB, wenn ich vom Server etwas runterlade.

 

wenn ich hingegen umgedreht etwas auf den Windows Server von dem Linuxtestserver im anderen RZ runterlade hab ich auch wieder 11MB/s.

 

 

ergo, VON einem Windowsserver ZU einem anderen Rechner irgendwo in Deutschland, da klemmt es, aber umgedreht ZU dem Windowsserver VON einem Server in einem anderen Rechenzentrum läuft es ebenfalls supi.

 

 

Ja WTF ??

 

 

das ist doch echt zum Mäusemelken