Eine erneute TCP-Übertragung verursacht eine Verzögerung von 15 Sekunden im WLAN

741
mythos

Ich habe ein seltsames Problem, das zu langen Verzögerungen bei http-Anfragen (in diesem Fall POST) an meinen eigenen Webserver führt. Dies tritt nur dann auf, wenn
- ein Linux- oder Mac-Client verwendet wird (Windows ist in Ordnung) und
- die drahtlose Verbindung verwendet wird und die Kabelverbindung einwandfrei ist. Dies tritt
sowohl im 2,4-GHz- als auch im 5-GHz-Band auf. Auf dem 5-GHz-Band sind nur drei weitere AP aktiv, und ich habe einen Kanal gewählt, der von diesen Kanälen weit entfernt ist (die automatische Einstellung von AP verbessert die Situation nicht). Somit schließe ich externe Störungen des Funkgerätes als Ursache aus. Die meisten (alle?) Anderen Websites über das gleiche WLAN sind in Ordnung.

Wireshark sagt mir, dass der Unterschied zwischen kabelgebundenem und drahtlosem Betrieb eine TCP-Neuübertragung ist. Dies führt zu Verzögerungen von 10 bis 20 Sekunden. Das folgende Bild zeigt
- Linux auf Funk -> Neuübertragung und Verzögerung
- Fenster auf Funk (gleicher Client) -> Neuübertragung, keine Verzögerung
- Linux auf Kabel -> Keine Neuübertragung

Eine erneute TCP-Übertragung verursacht eine Verzögerung von 15 Sekunden im WLAN

Dies ist nicht bei allen Anfragen der Fall, sondern bei den meisten. Die erneute Übertragung befindet sich jedoch immer an derselben Stelle in der Kommunikation (die 200 OK-Antwort auf die POST-Anforderung).

Das Beste wäre, die Ursache für den Paketverlust / die erneute Übertragung zu finden. Aber selbst wenn man sie als unvermeidlich ansieht, bin ich erstaunt, dass so wenige Verluste zu einer Verzögerung von mehreren zehn Sekunden führen können. Nach meinem Verständnis sollte TCP damit viel besser umgehen können.

Hier einige Details zum Setup:
- Server, auf dem Ubuntu 14.04, Kernel 3.13.0-042stab108.2 (in einer VM) ausgeführt wird
- Clientgerät läuft Ubuntu 12.04.5, Kernel 3.2.0-97-Generic, iwlwifi-Treiber, Centrino Advanced -N 6230 AGN REV = 0xB0
- Gerät befindet sich in einem lokalen Netzwerk, NAT erfolgt über Router / WLAN-AP FritzBox 7390, läuft unter FRITZ! OS 06.30

1
Dies ist eine sehr interessante Frage. Bearbeiten Sie Ihre Frage, um mehr Details hinzuzufügen. Auf welchem ​​Gerät wurde diese Paketverfolgung aufgenommen? Welche Betriebssystemversionen sind genau? Befinden sich einige dieser Geräte hinter einem NAT-Gateway? Wie sehen die Ablaufverfolgungspakete im Arbeitsfall aus (insbesondere der Windows-Fall)? Können Sie die vollständige TCP-Sitzung in die von Ihnen bereitgestellten Paketverfolgungsspuren aufnehmen? - Ich möchte den Handshake und die Datenframes sehen, die später bestätigt werden. Wie ist die Pfad-MTU zwischen Client und Server? Sagen Sie, es ist immer die "200 OK" -Meldung, die verloren geht? Spiff vor 8 Jahren 0
Vielen Dank für den Blick in dieses @Spiff und ein frohes neues Jahr! Ich habe meine Frage mit Wireshark-Dumps für die drei Fälle aktualisiert. Tatsächlich war ich mir vorher nicht klar: Die TPC-erneute Übertragung ist auch unter Windows vorhanden, verursacht aber keine Verzögerung. Nach dem Verkabeln erfolgt keine erneute Übertragung. Der Pfad der MTU laut Tracepath ist 1500. Auf welche Weise möchten Sie die vollständige TPC-Sitzung haben (nur ein Screenshot von Wireshark - nur größer als ich oder mehr Details?). mythos vor 8 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme