it-swarm.com.de

Verwendung von Recv-Q und Send-Q

Wozu dienen die Spalten Recv-Q und Send-Q in der Ausgabe von netstat? Wie verwende ich das in einem realistischen Szenario?

Auf meinem System werden beide Spalten immer als Null angezeigt. Was ist die Bedeutung dafür?

18
mrg

Von meiner Manpage:

Recv-Q

Established: Die Anzahl der Bytes, die vom an diesen Socket angeschlossenen Anwenderprogramm nicht kopiert wurden.

Listening: Seit Kernel 2.6.18 enthält diese Spalte das aktuelle Syn-Backlog.

Send-Q

Established: Die Anzahl der Bytes, die vom Remote-Host nicht bestätigt wurden.

Listening: Seit Kernel 2.6.18 enthält diese Spalte die maximale Größe des Syn-Backlogs.

Wenn Sie diese Einstellung auf 0 festgelegt haben, bedeutet dies nur, dass Ihre Anwendungen auf beiden Seiten der Verbindung und das Netzwerk zwischen ihnen in Ordnung sind. Die tatsächlichen Momentanwerte können von 0 abweichen, sind jedoch so flüchtig und flüchtig, dass Sie keine Chance haben, sie tatsächlich zu beobachten.

Beispiel eines realen Szenarios, in dem dies von 0 abweichen kann (bei bestehenden Verbindungen, aber ich denke, Sie werden die Idee haben):

Ich habe kürzlich an einem eingebetteten Linux-Gerät gearbeitet und mit einem (schlecht designten) Gerät eines Drittanbieters gesprochen. Auf diesem Gerät eines Drittanbieters steckte die Anwendung manchmal eindeutig fest und las nicht die Daten, die sie über die TCP Verbindung empfangen hatte, was dazu führte, dass das TCP Fenster auf 0 abfiel und dort für zehn Sekunden stecken bleiben (Phänomen beobachtet über Wireshark auf einem gespiegelten Port zwischen den 2 Hosts).

  • Recv-Q: Ausführen von netstat auf dem Gerät eines Drittanbieters (was ich nicht tun konnte) Möglicherweise hat Recv-Q zugenommen, bis zu einem bestimmten Wert, bei dem die andere Seite (ich) keine Daten mehr sendet, weil das Fenster auf 0 abfällt, da die Anwendung die auf ihrem Socket verfügbaren Daten nicht liest und diese Daten gepuffert bleiben Bei der Implementierung von TCP im Betriebssystem, nicht zur steckengebliebenen Anwendung wechseln -> auf der Empfängerseite, Anwendungsproblem.

  • Send-Q:netstat auf meiner Seite laufen lassen (was ich wegen 1/des Problems nicht ausprobiert habe war klar von wireshark und war der erste obige Fall und 2/dies war nicht 100% reproduzierbar) kann ein von Null verschiedenes Send-Q zeigen, wenn die andere Seite TCP Implementierung auf Betriebssystemebene blockiert wurde und die Bestätigung meiner Daten gestoppt hat -> vom Absender, der das Problem TCP Implementierung (normalerweise auf Betriebssystemebene) empfängt.

Beachten Sie, dass das oben abgebildete Send-Q-Szenario auch ein Problem auf der Sendeseite sein kann (meine Seite) , wenn mein Linux TCP = Die Implementierung hat sich nicht richtig verhalten und Daten weiter gesendet, nachdem das Fenster TCP auf 0 gesunken ist: Die empfangende Seite hat dann keinen Platz mehr für diese Daten -> weiß nicht.

Beachten Sie auch, dass das Send-Q-Problem möglicherweise nicht auf den Empfänger zurückzuführen ist, sondern auf ein Routing-Problem zwischen Sender und Empfänger . Einige Pakete sind "on the fly" zwischen den beiden Hosts, aber noch kein ACKnowledge. Andererseits ist das Recv-Q-Problem definitiv auf einem Host: Pakete empfangen, bestätigt, aber noch nicht aus der Anwendung gelesen.

EDIT:

In der Praxis kann man davon ausgehen, dass Hosts und Anwendungen, die nicht beschissen sind, das Send-Q-Problem die meiste Zeit durch Routingprobleme und schlechte Netzwerkleistung verursacht haben zwischen sendender und empfangender Seite. Der "on the fly" Status von Paketen sollte niemals vergessen werden:

  • Das Paket kann sich im Netzwerk zwischen dem Sender und dem Empfänger befinden.

  • (oder empfangen aber ACK noch nicht gesendet, siehe oben)

  • oder die ACK kann sich im Netzwerk zwischen dem Empfänger und dem Absender befinden.

Es dauert eine RTT (Round Time Trip), bis ein Paket gesendet und dann bestätigt wird.

21
jbm