Ich verwende einen Mac OS-Laptop über ein typisches (d. h. schlechtes) drahtloses Heimnetzwerk und verbinde mich über ein VPN mit der Arbeit. Ich melde mich per SSH beim Linux-Desktop (Ubuntu) an, den ich in meinem Büro habe. (Wenn ich sage: „Ich melde mich per SSH an“: Ich klicke auf eine Schaltfläche, die mir mitteilt, dass „SSH“ verwendet wird, und ein „Terminal“-Fenster öffnet sich und meldet mich bei meinem Desktop an.)
Wenn ich „vim“ verwende, reagiert es häufig (bis zu mehrmals am Tag) nicht mehr, und ein oder zwei Minuten später wird die Verbindung zu meinem Desktop unterbrochen, und das Terminal meldet mir, dass die Verbindung unterbrochen ist. Ich habe häufig mehrere Terminalfenster gleichzeitig zu meinem Desktop geöffnet, und nur das Terminalfenster, in dem ich „vim“ verwende, wird unterbrochen. Die anderen Fenster bleiben verbunden und verwendbar.
Vor kurzem habe ich tcpdump verwendet, um die hin- und hergehenden Pakete zu verfolgen, und ich habe eine Spur aufgezeichnet, in der meine Vim-Sitzung hängen blieb und beendet wurde. Ein paar Minuten vor dem Ausfall kamen Pakete von meinem Desktop mit stetig schrumpfenden Fenstergrößen an, bis wir Null erreichten und die Verbindung etwas später abbrach.
Ich könnte das fast verstehen, wenn ich beispielsweise in den Einfügemodus gewechselt und angefangen hätte, Zeichen einzugeben, während der Desktop hängen geblieben ist, und ich das Fenster durch Tippen gefüllt hätte, während mein Desktop durcheinander war. Die anfängliche Fenstergröße betrug etwa 12.500 und jedes Zeichen, das ich eingebe, scheint ein 48-Byte-Paket zu erzeugen, sodass etwa 250 Zeichen einen TCP-Puffer füllen könnten.
Wenn Vim jedoch hängt, ist es eher so, als würde ich eine Bild-nach-unten-Taste drücken (Strg-F), dann in den Einfügemodus wechseln und dann anfangen, ein paar Zeichen einzugeben. Meine Befehle und Zeichen werden wiederholt, was darauf hinweist, dass Vim die Zeichen empfängt und verarbeitet.
Mir ist nicht klar, wo der TPC-Puffer zwischen dem Socket und „vim“ sitzt. Vermutlich holt ein TTY-Treiber tatsächlich Zeichen aus dem TCP-Puffer ab, gibt sie an mich zurück, übergibt sie an vim und übergibt die Ausgabe von vim an mich zurück. Aber all diese Aktionen würden Bytes aus dem TCP-Puffer ziehen und die Fenstergröße würde nicht auf Null zurückgehen.
Was verstehe ich an der Funktionsweise des Software-Stacks nicht, warum sollte meine Fenstergröße auf Null sinken und wie kann ich das Problem umgehen oder beheben?
Bonusfragen:
1) Warum stellt mein Desktop die Fenstergröße auf ca. 12.500 statt auf ca. 64 KB ein?
2) Wenn ich tcpdump auf dem Mac verwende, erhalte ich keine Ausgabe, wenn ich die Ausdrücke „Host-Hostname“, „Host-IP-Adresse“ oder „Port 22“ verwende (wobei „Hostname“ und „IP-Adresse“ durch den Namen oder die IP-Adresse meines Desktops ersetzt werden). Wenn ich einen dieser Ausdrücke nicht angebe, erhalte ich eine Menge Ausgabe, und die Ausgabe enthält eindeutig den Hostnamen, die IP-Adresse oder den Port, die ich in der Befehlszeile angegeben habe. Gibt es auf dem Mac etwas Besonderes, bei dem tcpdump nicht funktioniert? Gibt es eine Standardmethode, um die Befehlszeile zu vermasseln, und ich bin verwirrt darüber, was ich tcpdump sagen soll?
danke, Cs
Antwort1
Zunächst einmal ist die TCP-Fenstergröße kein Puffer, sondern ein Bestätigungsschwellenwert. Der Knoten, der Datenverkehr empfängt, sendet nur alle x Pakete ein ACK-Paket. In einem zuverlässigen Netzwerk sollte diese Zahl für den Durchsatz so groß wie möglich sein – der Nachteil dabei ist, dass bei einem Datenverlust das gesamte Fenster erneut übertragen werden muss … Dies führt normalerweise dazu, dass der TCP-Stapel die Fenstergröße schrittweise reduziert, um im Falle eines zukünftigen Paketverlusts nicht so viele Daten erneut übertragen zu müssen. Es gibt eine Komponente im Zusammenhang mit dem verfügbaren Speicher (Empfangspuffer), aber in modernen Systemen ist dies größtenteils irrelevant.Wikipedia
Die zugrunde liegende Ursache dieses Problems ist wahrscheinlich eine schlechte Netzwerkverbindung. VPNs können häufig hohe Latenz und/oder Paketverluste aufweisen, ebenso wie drahtlose Netzwerke. Verbessert/löst sich das Problem experimentell, wenn Sie eine Verbindung über eine Festnetzverbindung statt über WLAN herstellen?