Erhöhung der TCP-Fenstergröße
Habe ich einige Zweifel über die zunehmende Größe des TCP-Fensters in der Anwendung. In meiner C++ - software-Anwendung, wir senden die Datenpakete der Größe rund 1k vom client zum server über TCP/IP blocking socket. Vor kurzem stieß ich auf dieses Konzept Größe des TCP-Fensters. Also habe ich versucht, erhöhen Sie den Wert auf 64 KB mit setsockopt() für beide SO_SNDBUF und SO_RCVBUF. Nachdem Sie diesen Wert erhöhen, bekomme ich einige Verbesserungen in der performance für WAN-Verbindung, aber nicht in der LAN-Verbindung.
Gemäß meinem Verständnis in TCP-Window-Size,
Client sendet Datenpakete an den server. Bei erreichen dieser Größe des TCP-Fensters, wird er warten, um sicher ACK vom server empfangen für das erste Paket im Fenster Größe. Im Falle von WAN-Verbindung, der ACK ist immer verzögert, die vom server an den client wegen der Latenz in RTT von etwa 100ms. Also in diesem Fall, die Erhöhung der Größe des TCP-Fensters gleicht das ACK warten Sie Zeit und verbessern dadurch die Leistung.
Ich möchte verstehen, wie verbessert sich die performance meiner Anwendung.
In meiner Anwendung, obwohl die TCP-Fenstergröße (Senden und Empfangen Puffer) erhöht sich mit setsockopt auf socket-Ebene, die wir immer noch erhalten die gleiche Paket-Größe von 1k (ich.e die bytes, die wir senden, vom client zum server in einem single-socket senden). Auch wir Behinderte Nagle-Algorithmus (eingebaute option, um zu konsolidieren, kleine Pakete in ein großes Paket dabei vermeidet häufige socket-Aufruf).
Meine Zweifel sind wie folgt:
- Da bin ich mit blockierenden socket, der für jedes Datenpaket senden von 1k sollte es blockieren, wenn ACK kommt nicht vom server. Wie funktioniert dann die Leistung zu verbessern, nach der Verbesserung die Größe des TCP-Fensters in WAN-Verbindung allein ? Wenn ich das falsch verstanden, das Konzept der TCP-Window-Größe, bitte korrigieren Sie mich.
- Für das senden von 64 Kb an Daten, ich glaube, ich muss noch call-Buchse send-Funktion 64 mal ( da bin ich senden 1k pro senden durch blockierenden socket), obwohl ich erhöhte meine TCP-Window-Größe auf 64 Kb. Bitte bestätigen Sie diese.
- Was ist die maximale Anzahl von TCP-Fenster mit der windows-Skalierung aktiviert RFC 1323-Algorithmus ?
Ich bin nicht so gut in mein Englisch. Wenn Sie konnte nicht verstehen, alle der oben genannten, lassen Sie es mich bitte wissen.
InformationsquelleAutor der Frage Prabu | 2013-01-17
Du musst angemeldet sein, um einen Kommentar abzugeben.
Erste von allen, es ist ein großes Missverständnis, das offensichtlich aus Ihrer Frage: dass das TCP-Fenster ist, was wird gesteuert durch
SO_SNDBUFundSO_RCVBUF. Das ist nicht wahr.Was ist die Größe des TCP-Fensters?
In einer nussschale, die TCP-window-Größe bestimmt, wie viel follow-up-Daten (Pakete) von Ihren Netzwerk-stack ist bereit, auf den Draht, die vor Erhalt der Bestätigung für die früheste Paket, das nicht bestätigt wurde noch.
Den TCP-stack hat, um zu Leben mit und für die Tatsache, dass, sobald ein Paket wurde bestimmt, verloren zu sein oder verstümmelt in der übermittlung, bei jedes Paket gesendet, das von diesem abwerden erneut gesendet, da die Pakete können nur anerkannt werden, um durch den Empfänger. Daher, so dass zu viele unbestätigte Pakete zu existieren in der gleichen Zeit verbraucht die Verbindung, die Bandbreite spekulativ: es gibt keine Garantie, dass die Bandbreite, die verwendet wird, tatsächlich etwas zu produzieren, sinnvoll.
Auf der anderen Seite nicht, dass mehrere unbestätigte Pakete zur gleichen Zeit würden Sie einfach töten die Bandbreite der verbindungen, die eine hohe Bandbreite-delay-Produkt. Also, der TCP-stack hat, um die balance zwischen der Bandbreite, die für Sie keinen nutzen und nicht mit dem Auto das Rohr aggressiv genug (und so dass einige seiner Kapazität ungenutzt).
Die TCP-Fenstergröße bestimmt, wo das Gleichgewicht hergestellt wird.
Was tun
SO_SNDBUFundSO_RCVBUFtun?Kontrollieren Sie die Menge an pufferplatz, dass der Netzwerk-stack reserviert für die Wartung Ihrer Steckdose. Diese Puffer dienen, zu sammeln ausgehende Daten, die den stack nicht in der Lage war, um auf den Draht und Daten, die empfangen wurde, aus dem Draht aber noch nicht gelesen, die von Ihrer Anwendung jeweils.
Wenn man dieser Puffer voll ist, werden Sie nicht in der Lage zum senden oder empfangen von Daten mehr, bis Speicherplatz freigegeben wird. Beachten Sie, dass diese Puffer nur beeinflussen, wie der Netzwerk-stack verarbeitet Daten, die auf der "near" - Seite der Netzwerk-Schnittstelle (bevor Sie gesendet wurden, oder nachdem Sie angekommen sind), während die TCP-Fenster beeinflusst, wie der stack verwaltet die Daten auf der "Fernen" Seite der Schnittstelle (d.h. auf der Leitung).
Antworten auf Ihre Fragen
Nicht. Wenn das der Fall ist, dann würden Sie verursachen eine Verzögerung für jedes Paket gesendet werden, das wäre völlig zerstören, die Bandbreite der verbindungen mit hoher Latenz.
Ja, aber das hat nichts zu tun mit entweder die Größe des TCP-Fensters oder mit der Größe der zugeordneten Puffer die Steckdose.
Laut allen Quellen die ich finden konnte, haben (Beispiel), scaling ermöglicht das Fenster, um zu erreichen eine maximale Größe von 1 GB.
InformationsquelleAutor der Antwort Jon
Falsch. Senden von TCP asynchron ist. send() sendet die Daten an den socket gesendete Puffer und kehrt zurück. Es blockiert nur während der socket send buffer voll ist.
Weil Sie, wie falsch es blockiert, bis er bekam ein ACK.
Warum? Sie könnten nenne es einfach mal mit der 64 Kb Daten-Puffer.
Warum? Oder ist das eine Wiederholung von Ihrem Irrtum unter (1)?
Nicht. Kannst du Sie alle auf einmal. Keine Schleife erforderlich.
Viel größer, als Sie jemals brauchen.
InformationsquelleAutor der Antwort user207421