Wie kann ich die TCP-Sende- und Empfangswarteschlangengrößen unter Windows anzeigen?


10

Linux netstat zeigt die Größen der Sende- und Empfangswarteschlangen an.

Wie erhalte ich diese Informationen unter Windows, insbesondere unter Server 2003?


Können Sie ein Beispiel für die Ausgabe einfügen, die Sie sehen möchten?
Izzy

Schauen Sie sich diesen Link an. Ich benötige die Spalten Recv-Q und Send-Q von netstat. linux-ip.net/html/tools-netstat.html

Antworten:


3

(Dies ist ein bisschen wie ein Brain Dump)

Wenn Sie sich einige Versionen der netstat-Quelle ansehen, scheinen die gesuchten Informationen direkt vom Kernel (/ proc / net / ...) abgefragt zu werden, nicht über Socket-bezogene Aufrufe mit Windows-Entsprechungen. Wenn Sie wirklich entschlossen sind, dies zu tun, würde ich mir ansehen, wie es in netstat abgerufen wird, und sehen, was Sie finden können, das etwas Äquivalentes bietet.

Informationen zu Treiberebene finden Sie wahrscheinlich unter ndis.com (Network Driver Interface Specification) und PCAUSA.com , da dies wahrscheinlich der beste Ort ist, um diese Informationen unter Windows abzurufen.

Ich glaube nicht, dass getockopt () oder der größte Teil der Winsock-Arena Sie irgendwohin bringen wird, aber wenn Sie in diese Richtung gehen möchten, lesen Sie die MSDN Winsock-Informationen und lesen Sie auch die FAQ des Winsock-Programmierers .

Für eingehende Daten können Sie möglicherweise mit der Funktion ioctlsocket () mit FIONREAD nützliche Informationen abrufen, um die Menge der lesbaren Daten für einen Socket abzurufen. Möglicherweise können Sie dies nicht prozessübergreifend übertragen. Je nach Datentyp werden möglicherweise nur Informationen für den ersten Datenblock und nicht für die gesamte Warteschlange zurückgegeben, wenn sich mehr als ein Element in der Warteschlange befindet.

In diesem Zusammenhang könnten Sie sich mit "Rückstand" befassen, aber das meiste, was ich sah, schien sich auf die Festlegung der maximalen Größe für den Umgang mit SYN-Überschwemmungen zu beziehen, nicht wirklich darauf, wie groß der tatsächliche Rückstand war.

Wenn Sie wirklich entschlossen sind, können Sie möglicherweise etwas mit Ihrem eigenen Layered Service Provider tun , aber das ist eine seltsame und hässliche Straße voller Gefahren, und ich werde vorschlagen, sich davon fernzuhalten.

UPDATE: Nachdem Sie ein bisschen mehr herumgestöbert haben, sollten Sie sich auf jeden Fall die Abfrage von NDIS-OIDs ansehen. Das Finden der für Sie relevantesten Informationen bleibt eine Übung zwischen Ihnen, MSDN und TechNet.


3

Diese Frage ist alt, aber ich wollte einige Informationen hinzufügen. Es ist ein ziemlich hohes Suchergebnis bei Google.

Soweit ich das beurteilen kann, gibt es keinen Weg, dies zu tun, aber wenn jemand mehr graben und eine gültige Alternative finden kann, wäre das sehr dankbar!

Wie @Fencepost in seiner Antwort hervorhob, können Sie versuchen, NDIS-OIDs abzufragen. Die relevanteste NDIS-OID, die ich gefunden habe, ist OID_GEN_TRANSMIT_QUEUE_LENGTH

Die meisten NDIS-OIDs sind WMI-Klassen zugeordnet. Sie können sie in Powershell mit auflisten

Get-WmiObject -Namespace root\wmi -List  | Where-Object {$_.name -Match "MSNdis" } | Sort-Object

Es scheint jedoch keine für die Länge der Übertragungswarteschlange zu geben.

@ Chris J erwähnte die Netzwerkschnittstelle \ Länge der Ausgabewarteschlange. Sie können diesen Wert in der Befehlszeile mit typeperf abrufen .

typeperf "\Network Interface(*)\Output Queue Length" -sc 1

Der Wert ist jedoch immer 0: http://support.microsoft.com/kb/822226

Windows verfolgt diese Informationen nur in der NIC-Treibersoftware, und es werden nur Pakete pro NIC in die Warteschlange gestellt, und es wird nicht unterschieden, was pro Socket in die Warteschlange gestellt wird.

Wenn Sie das Netzwerk-Debugging in der Befehlszeile durchführen möchten, können alle in perfmon gefundenen Zähler mit typeperf oder logman abgefragt werden .


1

Was Sie möchten, sind möglicherweise die Ergebnisse der WinSock-API-Funktionsaufrufe getsockopt:

  • SO_RCVBUF Der gesamte für den Empfang reservierte Pufferplatz pro Socket. Dies SO_MAX_MSG_SIZEhat nichts mit der Größe des TCP-Empfangsfensters zu tun und entspricht nicht unbedingt dieser.

  • SO_SNDBUF Der gesamte für Sends reservierte Pufferplatz pro Socket. Dies SO_MAX_MSG_SIZEhat nichts mit der Größe eines TCP-Sendefensters zu tun und entspricht nicht unbedingt dieser.

Das Problem ist, dass nach Sockets gefragt werden kann, deren Handle Sie kennen. Das Abfragen von außen scheint schwierig zu sein. Schauen Sie sich das sysinternale TcpView- Tool an. Mark Russinovich ist wirklich ein Knaller und selbst er liefert die Informationen nicht in seinem Tool. Ich bin mir ziemlich sicher, dass er eine Spalte hinzugefügt hätte, wenn er einen Mittelwert gehabt hätte, um die Werte leicht zu erhalten ...

Ich denke, ein Kernel-Treiber könnte helfen, einen Drilldown in das System durchzuführen, fand aber kein verfügbares Tool. Die Größen können pro Socket festgelegt werden, sodass globale Werte keine Bedeutung haben ...


1

Das nächste, was ich finden kann, ist der Leistungsindikator Network Interface\Output Queue Length. Dies ist jedoch nicht pro Verbindung - nur pro Schnittstelle und deckt nur die ausgehende Warteschlange ab (offensichtlich nach ihrem Namen).


1

Jetzt sind die Fenstergrößen pro Sockel unterschiedlich! Die Einstellungen pro Schnittstelle stellen nur die Standardwerte dar.

Ich kenne keine Möglichkeit, die Fenstergröße der einzelnen Sockets anzuzeigen. In Solaris kann dies mit "netstat" gesehen werden.


0

1
Was soll ich mir dort ansehen?

Windows verwendet verschiedene Algorithmen, um die Größe des TCP-Empfangsfensters festzulegen. Sie können die Standardeinstellung überschreiben, indem Sie einen Registrierungsschlüssel festlegen. Dieses Programm kann Ihnen auch helfen: dslreports.com/drtcp .
Massimo

Massimo- Sie verwechseln Fenstergrößen mit Daten in der Warteschlange. Die Fenstergrößen interessieren mich nicht.

Ok, tut mir Leid. Diese Informationen sind in Windows sowieso nicht verfügbar.
Massimo
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.