Was verursacht doppelte ACK-Datensätze?

Wir überprüfen Wireshark-Erfassungen von einigen Client-Computern, auf denen mehrere doppelte ACK-Datensätze angezeigt werden, die dann eine erneute Übertragung und Pakete außerhalb der Reihenfolge auslösen.

Diese werden im folgenden Screenshot gezeigt. .26 ist Client und .252 ist Server.

Was verursacht die doppelten ACK-Datensätze?

Mehr Hintergrund, wenn es hilft:

Wir untersuchen Bedenken hinsichtlich des Netzwerkdurchsatzes an einem bestimmten Clientstandort. Das aus Sicht der Benutzeroberfläche wahrgenommene Problem besteht darin, dass Daten trotz einer nicht ausgelasteten 1-Gbit / s-WAN-Verbindung nur langsam übertragen werden.

Fast alle Client-Computer haben dasselbe Problem, das auf mehr als 20 Computern getestet wurde. Wir haben zwei Maschinen gefunden, die das Problem nicht haben. Wir sind dabei zu identifizieren, was sich in ihrer Konfiguration unterscheidet. Wir haben festgestellt, dass wir auf den beiden Rechnern, auf denen das Problem nicht auftritt, höchstens einen doppelten ACK-Datensatz gesehen haben. Die Computer, auf denen das Problem auftritt, haben normalerweise drei doppelte ACK-Einträge. Ein bemerkenswerter Unterschied ist, dass die Computer, die einwandfrei funktionieren, zu Mitgliedern des Netzwerkbetriebsteams gehören und alle anderen Computer für "normale" Mitarbeiter bestimmt sind. Die Maschinen sollten Standard sein, aber die Netzwerkadministratoren könnten Änderungen an ihren lokalen Systemen vorgenommen haben, was ein weiterer Aspekt ist, den wir untersuchen.

Wir haben versucht, die TcpMaxDupAcks- Einstellung auf dem Server zu ändern , aber der Wert, den wir wirklich benötigen, ist 5 und der gültige Bereich ist nur 1-3.

Server ist Windows Server 2003. Clients sind alle von Unternehmen verwalteten Windows XP. Auf allen Clients, einschließlich der beiden funktionierenden, ist Symantec Anti-Virus installiert.

Dies ist die einzige Client-Site von Hunderten, die dieses Problem aufweist.

pathping zeigt 56ms RTT und konsistenten 0/100 Paketverlust auch von den problematischen Rechnern.

Vielen Dank,

Sam

Hinweis: Ich gehe davon aus, dass dieses Capture auf dem Clientcomputer aufgenommen wurde.

Eine kurze Zusammenfassung zur TCP-Sequenzierung: TCP liefert zuverlässig Ströme von Bytes zwischen zwei Anwendungen. "Zuverlässig" bedeutet in diesem Fall unter anderem, dass TCP garantiert, dass Daten, die nicht in Ordnung sind, niemals an eine hörende Anwendung geliefert werden.

Ordnungsgemäße, zuverlässige Zustellung wird durch die Verwendung von Sequenznummern realisiert. Jedem Paket in jedem Stream wird eine 32-Bit-Sequenznummer zugewiesen (denken Sie daran, dass TCP effektiv zwei unabhängige Datenströme ist, A-> B und B-> A). Wenn A eine ACK an B sendet, ist der Wert im ACK-Feld die nächste Sequenznummer, die A von B erwartet.

Anscheinend ist mindestens ein TCP-Segment verloren gegangen, das vom Server an den Client gesendet wurde. Die drei aufeinanderfolgenden doppelten ACKs sind ein Versuch des Clients, eine schnelle Neuübertragung auszulösen . Wenn ein TCP-Absender drei doppelte Bestätigungen für dasselbe Datenelement empfängt (dh vier Bestätigungen für dasselbe Segment, bei denen es sich nicht um das zuletzt gesendete Datenelement handelt), kann davon ausgegangen werden, dass das Segment unmittelbar nach dem Abbruch des zu bestätigenden Segments verloren gegangen ist im Netzwerk und führt zu einer sofortigen Neuübertragung.

In diesem Fall kommt die erneute Übertragung durch und wird von Wireshark als fehlerhaft identifiziert.

Wie von joeqwerty erwähnt , wird der Paketverlust am häufigsten durch Überlastung verursacht. Es kann auch eine Folge von CRC- oder anderen Fehlern auf einer Verbindung sein, die auf eine fehlerhafte Schnittstellenkarte, ein loses Kabel usw. zurückzuführen sind. Ich würde die Statistiken aller Verbindungen entlang des Pfads überprüfen, um festzustellen, ob sie stark ausgelastet sind und / oder treten viele Fehler auf.

Wenn Sie keine offensichtlichen Kandidaten sehen können, führen Sie an mehreren Punkten des Pfades gleichzeitig Paketerfassungen durch, um zu ermitteln, wo der Verlust auftritt.

Welche Art von WAN-Verbindung wird hier verwendet? Ist es eine Standleitung? MPLS VPN-Verbindung? IPsec VPN über das öffentliche Internet? Etwas anderes?

Stellen Sie sich einen Packet Dump als eines der Symptome vor, während Sie herausfinden, wo das Problem liegt. Wenn jemand mit Brustschmerzen in die Arztpraxis kommt, wird der Arzt keine drei Stunden damit verbringen, die Art des Problems zu untersuchen der Schmerz. Er verbringt ungefähr zwei Minuten damit und weiß dann, dass 95% der Ursachen entweder Sodbrennen oder Angina sind. Wenn Sie doppelte ACKs sehen, bohren Sie auf die gleiche Weise nicht sofort Ratten in die Unkräuter der Spur .

Nachdem die Verbindung hergestellt wurde, ist die langsame TCP-Leistung nicht immer auf Probleme mit dem Transitnetzwerk zurückzuführen. Manchmal ist dies das Ergebnis von Server-CPU- oder Festplatteneinschränkungen ... und gelegentlich aufgrund eines Problems auf einem Client-PC. Ich habe meinen Schwanz wochenlang in das Unkraut der Wireshark-Spuren gegraben, um das Problem mit mtr oder anderen Host-Metriken wie CPU- und Festplatten-E / A relativ schnell aufzugeben und zu finden .

Ihre erste Aufgabe besteht darin, zu prüfen, ob es sich um ein Netzwerkproblem oder ein Problem auf Hostebene handelt. Konzentrieren Sie sich auf das Senden realen Verkehr über das Netzwerk und beweisen , ob Sie Warteschlangen / lösenden / Nachbestellung ^{Anmerkung 1} es; Das ist immer die Quintessenz für ein potenzielles Netzwerkproblem wie dieses .

Ich würde pingüber einen längeren Zeitraum (normalerweise eine Stunde für mich) eine Stichprobe zwischen dem Client und dem Server durchführen, während das Durchsatzproblem auftritt. Sie können dafür die Freeware mtr oder ping plotter verwenden . Wenn Sie ständig Pakete an einem Hop verlieren und alle Hops danach mindestens so viel verlieren , liegt ein potenzieller Netzwerkverdächtiger vor. Denken Sie daran, dass die ICMP-Ratenbeschränkung bei einigen Geräten dazu führen kann, dass sie Pakete verlieren. Aus diesem Grund möchten Sie nach einem Trend suchen, der von diesem Hop ausgeht, und den folgenden.

^{Hinweis 1} Wenn Sie Traffic nachbestellen, wird dies im Experten- Infofeld von wireshark relativ schnell angezeigt

Wenn viele [TCP-Segment der wieder zusammengesetzten PDU] ohne ACKs angezeigt werden - ich würde sagen, dass diese ACKs aufgrund des Verhaltens der selektiven Bestätigung (auch bekannt als SACK) wahrscheinlich als [TCP-Dup-ACK ...] angezeigt werden .

Beispiel:

• Client sendet Datenteile (..., 0,1,2,3,4,5,6, ...)

• Server bestätigt (0), dann empfangen (2,4,3), dann (5), dann (6) und nie erhalten (1)

In obigem Szenario kann der Server zu Recht festlegen, dass zuerst (2-4) und dann (2-5) und dann (2-6) Bereiche bestätigt werden. Beim Bilden des Pakets "(AB) range ack" muss der Server den zuletzt bestätigten Teil (0) im TCP-Header angeben. Wireshark markiert die Range-Acks (SACKs) als [TCP Dup ACK ...], da alle diese Range-Acks denselben Wert für den zuletzt bestätigten Teil im TCP-Header haben (Ack = 872619 in Ihrem Fall).

Doppelte ACKs in Kombination mit langsamer Netzwerkleistung sind für mich ein Problem mit einer Netzwerküberlastung. Sehen Sie sich das Volumen und die Rate des Broadcast-Verkehrs im Netzwerk an. Achten Sie darauf, Broadcasts auf der physischen Ebene und auf der Netzwerkebene sowie Multicasts zu betrachten.