Mir ist klar, dass diese Antwort vereinfacht und nicht so explizit ist, wie ich es gerne hätte. Wenn Sie also Fragen zu einem Schritt haben, fragen Sie bitte!
Wenn Sie nach dem Öffnen dieser Datei in Wireshark ein wenig nach unten scrollen, sehen Sie einige Frames in verschiedenen Farben. Sieht wirklich schlecht aus, oder? Nun, es ist nicht so schlimm. Warte, wir kommen dorthin.
Wenn wir das SYN-Paket (Frame 37) überprüfen, sehen wir SACK und Fensterskalierung in den TCP-Optionen. Gut. Gleiches gilt für die SYN / ACK- (Frame 38), SACK- und Windows-Skalierung. Genial. Sehen Sie nichts Seltsames in Bezug auf SACK.
Eine Schätzung der entladenen RTT ist die Zeit zwischen dem SYN-Paket und der ersten ACK (Rahmen 39). Es sind ungefähr 9,3 ms, was Ihren Ergebnissen entspricht. Beachten Sie, dass die Zeit zwischen SYN / ACK und ACK (Frames 38 und 39) viel kürzer ist als zwischen SYN und SYN / ACK (37 und 38). Dies bedeutet, dass diese Erfassungsdatei am Empfänger aufgenommen wird. Um zu sehen, warum dies nicht ideal ist, müssen wir wieder zur Schule gehen.
Zwischen dem Sender und dem Empfänger befindet sich ein Teil des Netzwerkpfads, der am kleinsten ist, wodurch die Bandbreite begrenzt wird. Die RTT-Schätzung, die wir gerade vom Handshake erhalten haben, gibt uns eine Schätzung der Länge dieses Netzwerkpfads. Ein Maß dafür, wie viele Pakete in diese Pipe passen, ist die Rohrkapazität oder das Bandbreitenverzögerungsprodukt - PC [Bits] = R [Bits / s] * RTT [s], wobei R die kleinste Bandbreite ist. Die Rohrkapazität ist dann ein Maß für das Volumen.
Stellen Sie sich einen Gartenschlauch vor. Sein gemessenes Volumen wird auf die gleiche Weise durch seine Länge und seine Breite definiert, oder? Um das meiste Wasser herauszuholen, muss es vollständig mit Wasser gefüllt sein, da sonst Luftspalte den Wasserfluss einschränken. Falls es uns gelingt, es vollständig zu füllen, kann es überlaufen. Wir können einen Eimer verwenden, damit der Boden nicht nass wird und wenn der Eimer überläuft, wirkt sich dies nicht auf den Wasserfluss aus.
Es stellt sich heraus, dass es im Netzwerkpfad genau dasselbe ist. Wir müssen das Rohr füllen ... Mit anderen Worten, die Rohrkapazität ist das kleinste Byte im Flug (wie viel Wasser wir im Rohr + Eimer haben) zwischen dem Sender und dem Empfänger, das die kleinste Bandbreite voll ausnutzt (verursacht nicht) Luftspalte). Also, wenn die Bytes im Flug> PC sind, dann sind wir gut!
Wenn wir uns die TCP-Trace- Statistik -> TCP StreamGraph -> Zeitsequenzdiagramm (tcptrace) ansehen, sehen wir Bytes auf der Y-Achse und die Zeit auf der X-Achse. Die Ableitung dieser Kurve ist Bytes / Sekunde oder Durchsatz. Beachten Sie, wie flach die schwarze "Linie" ist, was bedeutet, dass der Durchsatz stabil ist! Es wird zwar einige Male durch blaue Linien unterbrochen (dies sind die SACK-Bereiche in den doppelten ACKs), aber wie zu sehen ist, hat dies keinen Einfluss auf den Durchsatz.
Sehen Sie, wie die graue durchgezogene Linie unten rechts (etwas zoomen, das sind die ACKs) den schwarzen TCP-Segmenten wirklich nahe kommt? Die Zeit zwischen dem TCP-Segment und dem ACK ist die RTT, hier ist es fast 0! Dies bedeutet, dass nicht viele Segmente im Flug diesen Erfassungspunkt passieren. Dies bedeutet wiederum, dass wir das nicht verwenden können, um die Bytes im Flug zu schätzen, und deshalb ist eine senderseitige Paketerfassung viel besser.
Pakete hier gehen natürlich vor dem Erfassungspunkt verloren. Jedes Datensegment, das zum Zeitpunkt des Verlusts im Flug war, löst eine doppelte ACK aus. Daher können wir die Anzahl der doppelten ACKs verwenden, um die Bytes im Flug zum Zeitpunkt des Paketverlusts zu schätzen. Hier sehen wir ungefähr 9, 16 und 23 Segmente. Jedes Segment verfügt über 1448 Datenbytes. Dies ergibt einen Flugbyte zwischen 13 KB und 33 KB. Der Durchsatz betrug hier ungefähr 3 Mbit / s (aus dem E / A- Diagramm ) und mit der RTT haben wir gemessen, bevor wir eine Rohrkapazität von weniger als 3e6 [Bits / s] * 10e-3 [s] / 8 Bytes = 3750 Bytes oder erhalten haben weniger als 3 Segmente.
Da die zum Zeitpunkt dieser Verluste im Flug befindlichen Bytes nicht wirklich gleich sind (hier mit so wenigen Stichproben schwer zu sagen), kann ich nicht wirklich sagen, ob es sich um zufällige Verluste (die schlecht, schlecht, schlecht sind) oder um Verluste aufgrund einer Warteschlange handelt / Bucket läuft über, aber sie treten auf, wenn Bytes im Flug> PC sind, sodass der Durchsatz nicht beeinträchtigt wird.
Ihre Antwort scheint darauf hinzudeuten, dass sie zwar zufällig waren, aber nicht so viele, um einen geringen Durchsatz zu verursachen.