Nagles Algorithmus, ACK Delay und Rlogin echo

Question

Ich wurde vorgeschlagen, auch hier zu fragen, da spezifische Fragen über Protokolle am Thema sind, aber falls jemand interessiert ist, hat die Frage auch eine kleine Prämie auf ServerFault.

Ich lese über TCP-Datenfluss, verzögerte ACK und Nagle-Algorithmus.

Bisher Ich verstehe, dass:

1. Die verzögerte ACK Implementierung auf TCP auf der Anerkennung der Segmente eine Verzögerung schafft erhielt die Möglichkeit, für die Anwendung geben einige Daten zusammen mit der Bestätigung zu schreiben, so Vermeiden, ein leeres ACK-Paket zu senden und zur Netzwerküberlastung beizutragen.
2. Der Algorithmus des Nagle Implementierung besagt, dass Sie nicht immer noch nicht bestätigt ist ein kleines TCP-Segment, während ein anderes kleines Segment senden. Dadurch wird vermieden, dass der Verkehr mit mehreren Tinygrams geladen wird.

Auf einigen interaktiven Anwendungen, wie Rlogin zum Beispiel Nagle-Algorithmus und verzögerte ACKs kann „Konflikt“:

Rlogin sendet die Tastatureingaben an den Server, wie wir sie und einige Tasten geben (wie F1) erzeugt mehr als ein Byte (F1 = Escape + linke Klammer + M). Diese Bytes können in verschiedenen Segmenten gesendet werden, wenn sie einzeln an TCP übergeben werden.

Der Server nicht mit einem Echo antworten, bis er die ganze Folge hat, so dass alle ACKs verzögert würden (einige Daten aus der Anwendung erwartet). Der Client würde andererseits auf die Bestätigung des ersten Bytes warten, bevor er die nächste sendet (unter Berücksichtigung des Nagles Algorithmus). Diese Kombination führt zu einem "laggy" Rlogin.

Die tcpdump der F1 und F2 Schlüssel auf einem Rlogin dargestellt unten gesendet werden:

type Fl key 
1 0.0     slip.1023 > vangogh. login: P 1:2(1) ack 2 
2 0.250520 (0.2505) vangogh.login > slip.1023: P 2:4(2) ack 2 
3 0.251709 (0.0012) slip.1023 > vangogh.login: P 2:4(2) ack 4 
4 0.490344 (0.2386) vangogh.login > slip.1023: P 4:6(2) ack 4 
5 0.588694 (0.0984) slip.1023 > vangogh.login: . ack 6 
    type F2 key 
6 2.836830 (2.2481) slip.1023 > vangogh.login: P 4:5(1) ack 6 
7 3.132388 (0.2956) vangogh.login > slip.1023: P 6:8(2) ack 5 
8 3.133573 (0.0012) slip.1023 > vangogh.login: P 5:7(2) ack 8 
9 3.370346 (0.2368) vangogh.login > slip.1023: P 8:10(2) ack 7 
10 3.388692 (0.0183) slip.1023 > vangogh.login: . ack 10 

die Zweifel nun: Auch wenn die Seite I-Staaten gelesen, dass der Server antwortet nicht mit einem Echo, bevor er die gesamte Schlüsselsequenz hat, die durch tcpdump erfassten Pakete zeigen, dass die Tasten auf ihrem jeweiligen ACKs Echo werden (die erste Antwort ist 2 Byte lang, weil das Echo von ESC zwei Zeichen ist - caret + linke Halterung).

Wenn Daten von der Anwendung an TCP gesendet werden (die Echoantwort), warum werden die ACKs verzögert? Nach dem, was gesagt wurde, über den Server warten die vollständige Sequenz vor dem Echo es, war nicht die ACKs sollten keine Echo bis zum letzten ACK enthalten, das würde die gesamte Sequenz Echo enthalten?

EDIT: Hier ist der Ausgang der tcpdump für die modifizierten Rlogin, ohne den Algorithmus des Nagle (TCP_NODELAY flag):

 type Fl key 
1 0.0  slip.1023 > vangogh.login: P 1:2(1) ack 2 
2 0.002163 (0.0022) slip.1023 > vangogh.login: P 2:3(1) ack 2 
3 0.004218 (0.0021) slip.1023 > vangogh.login: P 3:4(1) ack 2 
4 0.280621 (0.2764) vangogh.login > slip.1023: P 5:6(1) ack 4 
5 0.281738 (0.0011) slip.1023 > vangogh.login: . ack 2 
6 2.477561 (2.1958) vangogh.login > slip.1023: P 2:6(4) ack 4 
7 2.478735 (0.0012) slip.1023 > vangogh.login: . ack 6 
     type F2 key 
8 3.217023 (0.7383) slip.1023 > vangogh.login: P 4:5(1) ack 6 
9 3.219165 (0.0021) slip.1023 > vangogh.login: P 5:6(1) ack 6 
10 3.221688 (0.0025) slip.1023 > vangogh.login: P 6:7(1) ack 6 
11 3.460626 (0.2389) vangogh.login > slip.1023: P 6:8(2) ack 5 
12 3.489414 (0.0288) vangogh.login > slip.1023: P 8:10(2) ack 1 
13 3.640356 (0.1509) slip.1023 > vangogh.login: . ack 10 

Es kann auf Segment 4, die ~ 0,2 ms Verzögerung bemerkt werden, obwohl Nagles Algorithmus ausgeschaltet ist (also alle speziellen Schlüsselbytes zusammen ankommen und zusammen verarbeitet werden können). In Segment 6 können wir die Verzögerung von ~ 0,2 ms nicht identifizieren, da der Server einige Zeit benötigt, um die erneute Übertragung einiger verlorener Segmente erneut zu verarbeiten und neu zu packen, aber diese Verzögerung liegt über 2 Sekunden.

Auf dem F2 Schlüssel Beispiel, auf Segment 11 können wir auch die ~ 0.2ms Verzögerung bemerken. Wir können es nicht in Segment 12 identifizieren, weil es wahrscheinlich direkt nach Segment 11 gesendet wurde.

Dies zeigt, dass @MattTimmersans Antwort richtig ist, und es könnte sein, dass das Buch eine Fehlinterpretation der Segmente Verzögerung macht. Sie könnten tatsächlich eine Eigenschaft des Netzwerkmediums sein, anstatt dass die ACKs verzögert werden, weil Daten nicht an den TCP-Stapel gesendet werden.

Referenz: http://people.na.infn.it/~garufi/didattica/CorsoAcq/Trasp/Lezione9/tcpip_ill/tcp_int.htm

Answer 1

Da die ACKs in Segmenten mit Daten kommen 2,4,5,7, werden sie nicht verzögert ACKs (nicht durch den ACK-Timer verstreicht initiiert).

Ich glaube, die 0,25s Verzögerungen mit denen verbunden sind nur die Umlaufzeit zwischen den Hosts. Ich stelle fest, dass diese Daten 1993 protokolliert wurden. Wenn ich mich richtig erinnere, denke ich, dass ein 250ms-Ping damals nicht ungewöhnlich war.

Wenn die tcpdump auf vangogh statt slip laufen gelassen wurden, sieht es aus wie es das Echo kommt schnell nach den ESC und [M Pakete sehen würde.

Das Beispiel zeigt, dass Nagles Algorithmus auch ohne ACK-Verzögerung saugen kann, da es dem Austausch eine zusätzliche Umlaufzeit hinzufügt.