☰

was sind gültige „Ack“-Werte?

tag-icon • tag-icon tcp
was sind gültige „Ack“-Werte?

ich habe ein Problem mit einem Anbieter, der behauptet, die Ursache des Problems sei ein ungültiger „ack“-Wert in den TCP-Daten. Ich verwende Java, daher habe ich diese Ebene nicht geschrieben. Ich habe Snoop verwendet, um den Verkehr auf der Leitung aufzuzeichnen, und verwende Wireshark, um die Daten anzuzeigen. Folgendes passiert: Nach dem Empfang einer Multi-Packet(5)-Meldung sehe ich eine Multi-Pack(3)-Antwort. Das erste Paket in der Antwort hat einen „ack“-Wert, der sich von dem „ack“-Wert in den anderen beiden Paketen unterscheidet. Der Anbieter behauptet, diese Daten seien verdächtig. Ich habe unten Beispieldaten bereitgestellt. Ich bin kein TCP-Experte, daher weiß ich nicht, ob dies ein Problem ist oder nicht. Ich habe versucht, etwas zu gültigen ack-Werten herauszufinden und mir scheint, dass der Wert 80018 sein sollte, aber das bedeutet nicht, dass 78345 falsch ist. Ich habe das hier im Internet gefunden und es scheint zuzutreffen, aber ich bin mir nicht sicher: „Der Bestätigungswert eines Datensegments wird als gültig angesehen, solange er keine Daten vor dem nächsten zu sendenden Segment bestätigt.“ Danke für Ihre Hilfe. Meines Wissens hat der Anbieter seine eigene TCP-Schicht geschrieben.

    Quelle Sequenz Bestätigung Länge Zeit
    ich 10734 75465 190 jjjjmmtt 09:18:21.785757
    Verkäufer 75465 10924 0 jjjjmmtt 09:18:21.789319
    Verkäufer 75465 10924 1440 jjjjmmtt 09:18:34.196661
    Verkäufer 76905 10924 1440 jjjjmmtt 09:18:34.196762
    Verkäufer 78345 10924 1440 jjjjmmtt 09:18:34.196901
    Verkäufer 79785 10924 233 jjjjmmtt 09:18:34.196915
    ich 10924 78345 0 jjjjmmtt 09:18:34.196968
    ich 10924 80018 0 jjjjmmtt 09:18:34.197102
    ich 10924 80018 197 jjjjmmtt 09:18:34.579479

Antwort1

http://en.wikipedia.org/wiki/Transmission_Control_Protocolsagt

Bestätigungsnummer (32 Bit) – wenn das ACK-Flag gesetzt ist, ist der Wert dieses Felds die nächste Sequenznummer, die der Empfänger erwartet. Dies bestätigt den Empfang aller vorherigen Bytes (falls vorhanden). Das erste von jedem Ende gesendete ACK bestätigt die anfängliche Sequenznummer des anderen Endes selbst, jedoch keine Daten.

Dies deutet darauf hin, dass das erste Antwortpaket den Empfang der ersten drei Pakete bestätigt vonVerkäufer(Sequenz 76905 + Länge 1440 = 78345)

Das zweite Antwortpaket bestätigt den Empfang des vierten und fünften Pakets vonVerkäufer(Sequenz 79785 + Länge 233 = 80018)

Das dritte Antwortpaket zeigt an, dass keine weiteren Daten empfangen wurden vonVerkäufer(dieselbe Bestätigung) und enthält eine Nutzlast von 197 Bytes.

Das sieht für mich in Ordnung aus.

Wenn Ihre Daten die gesamte Konversation sind, wäre die anfängliche Bestätigung falsch, da sie das erste Paket bestätigen sollte vonVerkäufermit einer Bestätigung von 75465 (Sequenz 75465 + 1 = 75466).

Hier ist eine Sequenz, die ich mit Wireshark aufgezeichnet habe. Zuerst sehen wir den Drei-Wege-Handshake, dann die Übertragung einer HTTP-Get-Anfrage, gefolgt von einer HTTP-Antwort.

Quellflags Sequenz Bestätigung Länge  
Client-SYN 0 - 0  
Server SYN,ACK 0 1 0  
Client-ACK 1 1 0  
Client - 1 1 429 Holen Sie sich ...
Server ACK 1 430 0  
Server - 1 430 1456 HTML-Antwort
Server - 1457 430 1456  
Client-ACK 430 2913 0  
...

Die Sequenz- und Bestätigungsnummern sind relativ (zur zufällig gewählten Startnummer jedes Endes).

Die Verwendung einer einzigen Verbindung für eine Reihe von Anfragen ist eine gängige Optimierung. Sie wurde HTTP in Version 1.1 hinzugefügt und ist bekannt alsdauerhafte Verbindungen. Das Auf- und Abbauen von TCP-Verbindungen ist kostenpflichtig.

Antwort2

Kurz gesagt wird das ACK-Feld verwendet, um die nächste Sequenznummer anzugeben, die ein Empfänger von einem Sender erwartet. Das heißt, die Sequenznummer des letzten empfangenen Segments + Länge dieses Segments. (Es gibt noch einige andere Verwendungsmöglichkeiten im Zusammenhang mit Verlusten/Neuübertragungen, aber diese lassen wir jetzt mal außen vor.)

TCP ist so konzipiert, dass mehrere Segmente in einer einzigen Antwort bestätigt werden können. Dies ermöglicht eine effizientere Nutzung von Verbindungen mit hoher Latenz. SieheRFC1122UndRFC2581, insbesondere die Abschnitte zu verspäteten Bestätigungen.

Zu Ihrer konkreten Frage: Ein TCP-Stack wird immer ein gewisses Maß an Interleaving aufweisen; das heißt, selbst wenn das letzte Paket (Sequenz 79785) im Empfangspuffer platziert worden wäre, wäre es möglicherweise nicht in der zulässigen Zeit verarbeitet worden, bevor eine ACK an das andere Ende der Verbindung zurückgesendet werden musste. Die Header, die Sie bereitgestellt haben, scheinen mir eine völlig normale TCP-Konversation darzustellen. Die Erklärung Ihres Anbieters erscheint bestenfalls zweifelhaft.

verwandte Informationen