.png)
Das Problem
Hinweis: Zuerst möchte ich verstehen, WARUM das passiert. Natürlich wäre auch eine Lösung schön. :)
Wenn ich eine große Datei mit hoher Geschwindigkeit über HTTP herunterlade, kommt mein drahtloser Datenverkehr praktisch zum Stillstand: Ich kann keine Webseiten öffnen und der Download selbst wird unterbrochen. Er wird praktisch sofort nach dem Start unterbrochen; manchmal bei 800 KB, manchmal bei ein paar MB. Nach einiger Zeit wird der Download (und der übrige Datenverkehr) fortgesetzt, aber das Problem tritt während desselben Downloads immer wieder auf.
Das Problem tritt nicht auf, wenn eine kabelgebundene Verbindung über denselben Router (Linskys WRT120N) verwendet wird. Beachten Sie auch, dass die Verbindungnichtunterbrochen, wenn dies geschieht. Es ist nur so, dass der Datenverkehr stoppt und ich nicht zu Webseiten usw. navigieren kann (SYN-Pakete werden gesendet, aber nichts wird empfangen usw.).
Die Überprüfung mit Wireshark zeigt, dass Folgendes passiert:
- Der Server sendet Datenpakete, die vom Client bestätigt werden
- Der Server sendet ein Paket, aber SEQ zeigt an, dass einige Pakete verloren gegangen sind (6 Pakete in einem Vorkommen).
- Der Server sendet noch ein paar Pakete und der Client bestätigt diese mit „selektiver Bestätigung“
- Der Server sendet für eine Weile keine Daten mehr (da die verlorenen Pakete nicht bestätigt wurdenoderder Router hört auf, sie weiterzuleiten?)
- Schließlich führt der Server eine „neue Übertragung“ durch und der Datenverkehr wird wie gewohnt fortgesetzt.
Für mich scheint das alles ein normales Verhalten zu sein, wenn ein Paketverlust auftritt.Es ist der ständige Paketverlust während eines großen Hochgeschwindigkeitsdownloads, der mich verwirrt.
Was könnte die Ursache dafür sein?
Meine eigene Idee ist die folgende: Mein Internet ist ziemlich schnell (100 MBit/s), also puffert der Router beim Starten des Downloads einer großen Datei die eingehenden Daten (da es bei drahtloser Verbindung zu leichten Verzögerungen bzw. geringerer Geschwindigkeit kommt, teilweise aufgrund anderer Netzwerke), aber der Puffer läuft über und der Router verwirft Pakete, um den Verkehr zu regulieren (und weil er keine andere Wahl hat).
Aber wie konnte das passieren? Begrenzt die TCP-Fenstergröße nicht die Datenmenge, die unbestätigt bleiben kann? Wie kann es also zu einem Pufferüberlauf des Routers kommen, wenn nur etwa 64 KB auf eine Bestätigung warten können?
Notiz:Ich habe die TCP-Fensterskalierung und die dynamische Fenstergröße über netsh
die Optionen deaktiviert, um das Problem zu beheben, aber es scheint kein Problem zu sein.
Auch,Wireshark zeigt ein Muster, bei dem der Server 2 Pakete (von 1514 Bytes) sendet und der Client ein ACK sendet. Schließt das also einen möglichen Pufferüberlauf aus? Und noch ein paar weitere nachfolgende PaketeSinderhalten...
Ich bin hier ratlos. Danke für alle Einsichten.
Dinge, die (wahrscheinlich) NICHT die Ursache sind / mit denen ich experimentiert habe
- Der Browser
- Verschiedene TCP-Optionen in Windows 7 (
netsh
usw.) - Routereinstellungen wie MTU, Beacon-Intervall, UPnP, ...
Antwort1
Die Lösung
Die Lösung bestand einfach darin,WMM-Unterstützung deaktivierenin der Routerkonfiguration. Offenbar funktioniert die WMM-Unterstützung des Linksys WRT120N aus irgendeinem Grund nicht gut mit dem drahtlosen Windows 7-Netzwerk.
Weitere Einzelheiten
Wenn das Problem auftrat, wurde der Datenverkehr (für dieselbe Verbindung) oft wieder aufgenommen, als ob Pakete eine Zeit lang vom Router in die Warteschlange gestellt worden wären. Diese Pausen dauerten normalerweise 40 Sekunden oder länger. Ehrlich gesagt, verwirrt mich das immer noch.
Während dieser Zeit konnten keine anderen (TCP-)Verbindungen hergestellt werden: Beim Versuch, eine Webseite oder ähnliches aufzurufen, sendete der Laptop SYN-Pakete, aber es kam keine Antwort. DNS- und ARP-Anfragenwarnormal verarbeitet.