Entwurfsaspekte - senden kleiner Datensegmente über TCP mit Winsock

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 214397
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Wenn Sie benötigen, um kleine Datenpakete über TCP zu senden, ist der Entwurf der Winsock-Anwendung besonders wichtig. Eine Design, die nicht die Interaktion der verzögerte Bestätigung der Nagle-Algorithmus und Winsock-Pufferung berücksichtigt kann Leistung erheblich mindern. Dieser Artikel erläutert diese Probleme, die mit zwei Fallstudien, und leitet eine Reihe von Empfehlungen für kleine Datenpakete effizient aus eine Winsock-Anwendung senden.

Weitere Informationen

Hintergrund

Wenn Microsoft TCP-Stack ein Datenpaket erhält, geht ein Verzögerung-Zeitgeber 200 ms aus. Wenn schließlich eine ACK-Meldung gesendet wird, der Verzögerung Zeitgeber zurückgesetzt, und eine weitere Verzögerung von 200 ms wird initiiert, wenn das nächste Datenpaket empfangen wird.Zur Effizienzsteigerung in Internet- und Intranet-Webanwendungen verwendet Microsoft TCP-Stack die folgenden Kriterien um zu entscheiden, wann ein ACK auf Empfangene Datenpakete gesendet:
  • Wenn das zweite Datenpaket empfangen wird, vor Ablauf des Zeitgebers verzögern, wird die Bestätigung gesendet.
  • Wenn Daten in die gleiche Richtung wie die Bestätigung gesendet werden, bevor das zweite Datenpaket empfangen und Ablauf des Zeitgebers verzögern vorhanden sind, ist das ACK Systemsoftware auf das Datensegment und sofort gesendet.
  • Wenn der Verzögerung Zeitgeber abläuft, wird das ACK gesendet.
Um kleine Datenpakete zu belasten das Netzwerk zu vermeiden, ermöglicht Microsoft TCP-Stack den Nagle-Algorithmus wird standardmäßig die Koaliert einen kleinen Datenpuffer aus mehreren senden Aufrufe und Verzögerungen senden, bis eine ACK-Meldung für das vorherige Datenpaket gesendet vom Remotehost empfangen wird. Es folgen zwei Ausnahmen zu den Nagle-Algorithmus:
  • Wenn der Stapel einen Datenpuffer größer als das Maximum Transmission Unit (MTU) verschmolzen wurde, wird ein ganzes Paket sofort ohne warten auf die Bestätigung vom Remotehost gesendet. In einem Ethernet-Netzwerk ist die TCP/IP-MTU 1460 Byte.
  • Die TCP_NODELAY-Socketoption wird angewendet, um den Nagle-Algorithmus zu deaktivieren, damit die kleine Datenpakete an den Remotehost unverzüglich übermittelt werden.
Zum Optimieren der Leistung auf der Anwendungsschicht senden Winsock-Kopien Datenpuffer aus Anwendung Aufrufe an einen Winsock Kernel-Puffer. Anschließend verwendet der Stapel eigenen Heuristiken (z. B. Nagle-Algorithmus) zu bestimmen, wann das Paket tatsächlich in dem Draht versetzen. Sie können den Betrag von Winsock Kernel Puffer reserviert in die Buchse mit der SO_SNDBUF-Option (8K standardmäßig ist) ändern. Bei Bedarf kann der Winsock deutlich mehr als die SO_SNDBUF-Puffergröße Puffer. In den meisten Fällen gibt der Abschluss senden in der Anwendung nur den Datenpuffer in einer Anwendung senden, wird an den Winsock Kernel-Puffer kopiert und bedeutet nicht, dass die Daten das Netzwerkmedium getroffen hat. Die einzige Ausnahme ist, wenn Sie die Winsock-Pufferung durch Festlegen des SO_SNDBUF auf 0 deaktivieren.

Winsock verwendet die folgenden Regeln an, dass ein Abschluss senden an die Anwendung (je nachdem, wie das Senden aufgerufen wird, die Abschlussbenachrichtigung konnte die Funktion zurückgeben aus ein blockierender Aufruf, ein Ereignis signalisieren oder Aufrufen einer Benachrichtigungsfunktion usw.):
  • Wenn der Socket noch in SO_SNDBUF Kontingent ist, Winsock kopiert die Daten von der Anwendung senden und gibt den Abschluss senden an die Anwendung.
  • Wenn der Socket über SO_SNDBUF Kontingent ist, gibt es nur eine zuvor gepufferten Senden des Stapels Kernel-Puffers Winsock kopiert die Daten von der Anwendung senden und gibt den Abschluss senden an die Anwendung.
  • Wenn der Socket über SO_SNDBUF Kontingent ist, und gibt es mehr als ein zuvor gepuffert im Stapel Kernel Buffer gesendet, kopiert Winsock die Daten von der Anwendung senden. Winsock gibt nicht den Abschluss senden an die Anwendung an, bis zum Abschluss des Stapels genügend sendet den Socket wieder in SO_SNDBUF Kontingent bzw. nur eine ausstehende senden sollen.

Fallstudie 1

Übersicht:

Winsock TCP-Client muss 10.000 Datensätze an einen Winsock TCP-Server zum Speichern in einer Datenbank zu senden. Die Größe der Datensätze ist von 20 Bytes zu 100 Byte lang. Um die Anwendungslogik zu vereinfachen, ist der Entwurf wie folgt:
  • Der Client ist nur blockierende senden. Der Server wird nur blockierende empfangen.
  • Der Client-Socket setzt die SO_SNDBUF auf 0, damit jeder Datensatz in einem einzelnen Segment geht.
  • Der Server ruft Recv in einer Schleife. Puffer Recv erschienen ist 200 Byte, so dass jeder Datensatz in einem Recv Aufruf empfangen werden kann.

Leistung:

Während des Testens, findet der Entwickler, dass der Client nur fünf Datensätze pro Sekunde an den Server senden kann. Die insgesamt 10.000 Datensätze, maximale Weichzeichnung 976 KB Daten (10000 * 100 / 1024), mehr als eine halbe Stunde an den Server senden.

Analyse:

Da der Client nicht die Option TCP_NODELAY festgelegt wird, erzwingt der Nagle-Algorithmus des TCP-Stapels auf eine Bestätigung warten, bevor er ein weiteres Paket bei der Übertragung senden kann. Allerdings hat der Client deaktiviert die Winsock-Pufferung durch die SO_SNDBUF-Option auf 0 festlegen. Daher die 10000 senden Aufrufe gesendet haben und ACK'ed individuell. Jeder ACK ist verzögerte 200-ms, da auf dem Server TCP-Stack, Folgendes geschieht:
  • Wenn der Server ein Paket empfängt, wird die Verzögerung-Zeitgeber 200 ms erlischt.
  • Der Server muss nicht alles zurück, senden damit das ACK Piggyback werden nicht möglich.
  • Der Client sendet keine ein weiteres Paket, es sei denn, das vorherige Paket bestätigt wird.
  • Ablauf der Verzögerung auf dem Server und das ACK zurück gesendet.

Wie Sie verbessern:

Es gibt zwei Probleme mit diesem Entwurf. Erstens ist das Problem des Delay Timer. Der Client muss in der Lage, zwei Pakete an den Server innerhalb von 200 ms gesendet werden, da der Client standardmäßig den Nagle-Algorithmus verwendet, sollte es nur verwenden standardmäßige Winsock-Pufferung und SO_SNDBUF nicht auf 0 gesetzt. Sobald der TCP-Stack einen Puffer, der größer als das Maximum Transmission Unit (MTU) verschmolzen wurde, wird ein ganzes Paket sofort ohne warten auf die Bestätigung vom Remotehost gesendet.

Zweitens ruft dieses Design eine Send für jeden Datensatz so klein. Senden diese kleine Größe ist nicht sehr effizient. In diesem Fall sollten der Entwickler jeden Datensatz auf 100 Bytes aufgefüllt und 80 Datensätze gleichzeitig von einem Client Anruf senden senden. Um soll dem Server mitteilen, wie viele Datensätze insgesamt gesendet werden, sollten der Client damit beginnen, die Kommunikation mit einem Update-sized Header mit der Anzahl von Datensätzen zu folgen.

Fallstudie 2

Übersicht:

Eine Clientanwendung Winsock TCP zwei Verbindungen mit einer Dienstleistung Aktienkurse Winsock TCP-Serveranwendung geöffnet. Die erste Verbindung wird als ein Befehlskanal verwendet, um das Aktiensymbol an den Server gesendet. Die zweite Verbindung wird als Datenkanal verwendet, den Aktienkurs zu erhalten. Nach zwei Verbindungen hergestellt wurden, kann der Client sendet ein Aktiensymbol an den Server über den Befehlskanal und wartet, bis der Aktienkurs über den Datenkanal zurückkehren. Es sendet die nächste Aktiensymbol Anforderung an den Server erst nach der ersten Aktienkurs eingegangen ist. Der Client und der Server legen Sie die Option SO_SNDBUF und TCP_NODELAY nicht.

Leistung:

Während des Testens, findet der Entwickler, dass der Client nur fünf Quotes pro Sekunde erhalten könnte.

Analyse:

Dieser Entwurf ermöglicht eine hervorragende Aktienkurs-Anforderung nur zu einem Zeitpunkt. Das erste Aktiensymbol über den Befehlskanal (Anschluss) an den Server gesendet und eine Antwort wird sofort gesendet vom Server an den Client über den Kanal (Verbindung). Dann sendet des Clients sofort die zweite Anforderung Aktiensymbol und senden gibt sofort der Anfrage-Puffer im Send-Aufruf an den Winsock Kernel-Puffer kopiert. Allerdings kann nicht der Client TCP-Stack sendet die Anforderung aus der Kernel-Puffer sofort, da die erste senden über der Befehlskanal noch nicht bestätigt wird. Nach Verzögerung von 200-ms-Zeitgebers auf der Befehlskanal Server abläuft, die ACK-Meldung für die erste Anforderung Symbol kommt zurück an den Client. Die zweite Anfrage ist dann erfolgreich an den Server gesendet, nachdem für 200 ms, die das Angebot für das zweite Aktiensymbol sofort über den Datenkanal zurückkehrt, da zu diesem Zeitpunkt des Zeitgebers Verzögerung an den Clientchannel Daten Ablauf verzögert wird. Eine ACK-Meldung für die vorherigen Angebot Antwort wird vom Server empfangen. (Beachten Sie, dass der Client nicht eine zweite Anforderung Aktienkurs für 200-ms senden konnte, damit Zeit für die Verzögerung Zeitgeber auf dem Client ablaufen und eine ACK-Meldung an den Server senden.) Daher wird der Client Ruft die zweite Antwort für Angebot und einer anderen Anfrage, die unterliegt den gleichen Zyklus ausstellen kann.

Wie Sie verbessern:

Zwei Verbindungsentwurf (Kanal) ist hier nicht erforderlich. Wenn Sie nur eine Verbindung für den Aktienkurs Anforderung und Antwort verwenden, kann die ACK-Meldung für die Anfrage Systemsoftware auf die Antwort des Angebots und kommen sofort. Zur weiteren Verbesserung der Leistung des Clients konnte "bündeln" mehrere Aktienkurs-Anforderungen in eine senden-Aufruf an den Server, und der Server könnte auch "bündeln" mehrere Kostenvoranschläge in einem Aufruf von Senden an den Client. Wenn der Entwurf zwei unidirektionaler Kanal wirklich aus irgendeinem Grund erforderlich ist, sollten beide Seiten die TCP_NODELAY festlegen, dass kleine Pakete sofort gesendet werden können, ohne auf eine ACK-Meldung für das vorherige Paket warten.

Empfehlungen:

Während diese beiden Fallstudien hergestellt werden, helfen sie um einige ungünstigsten Fall zu veranschaulichen. Beim Entwurf einer Anwendung, bei der umfangreiche kleiner Datensegmente, sendet und Recvs, sollten Sie die folgenden Richtlinien berücksichtigen:
  • Wenn die Daten, die Segmente sind nicht kritische Zeit, sollte die Anwendung in einen größeren Datenblock auf einen Send-Aufruf übergeben sie zusammengefügten. Da Sendepuffers wahrscheinlich in den Winsock Kernel-Puffer kopiert werden, sollte der Puffer nicht groß sein. Etwas weniger als 8 KB ist in der Regel wirksam. Solange der Winsock Kernel einen Block größer ist als die MTU erhält, sendet er mehrere Pakete mit voller Größe und dem letzten Paket mit was übrig ist. Die sendende Seite, mit Ausnahme der letzten Paket wird vom Zeitgeber 200 ms Verzögerung nicht erreicht. Das letzte Paket, ist wenn er ein Paket ungerade ist noch unter dem Vorbehalt der Algorithmus für die verzögerte Bestätigung. Wenn der sendende End-Stapel ein weiterer Block größer als die MTU erhält, kann den Nagle-Algorithmus noch umgangen werden.
  • Wenn möglich, vermeiden Sie Socketverbindungen mit unidirektionaler Datenfluss. Kommunikation über unidirektionale Sockets sind leichter von der Nagle betroffen sind und verzögerte Bestätigung Algorithmen. Die Kommunikation eine Anforderung und eine Antwort Ablauf folgt, verwenden Sie ein Sockel, Sends und Recvs tun, damit die Bestätigung für die Antwort Piggyback werden kann.
  • Wenn die kleiner Datensegmente sofort gesendet werden, stellen Sie TCP_NODELAY-Option auf Senderseite.
  • Es sei denn, Sie soll sichergestellt werden, dass ein Paket bei der Übertragung gesendet wird, wenn ein Abschluss Senden von Winsock angegeben wird, sollten Sie die SO_SNDBUF nicht 0 (null) festlegen. In der Tat Puffers für den 8-K heuristisch festgestellt wurde für die meisten Situationen geeignet, und Sie sollten diese nicht ändern, wenn Sie geprüft haben, dass die neue Puffereinstellung Winsock-Ihnen eine bessere Leistung als die Standardeinstellung bietet. Außerdem ist die SO_SNDBUF auf 0 (null) festlegen meist für Anwendungen, die Datenübertragung massenzukopieren,. Sogar dann für maximale Effizienz verwenden sie in Verbindung mit doppelten Pufferung (mehrere ausstehende senden zu jedem Zeitpunkt) und überlappende e/a.
  • Verfügt die Datenübertragung nicht garantiert werden, verwenden Sie UDP.

Informationsquellen

Weitere Informationen über die verzögerte Bestätigung und den Nagle-Algorithmus finden Sie Folgendes:

Brad R. [1989], RFC 1122, Anforderungen für das Internet Hosts ? Communication Layers Internet Engineering Task Force.

Eigenschaften

Artikel-ID: 214397 - Geändert am: Montag, 3. März 2014 - Version: 4.0
Keywords: 
kbdswnet2003swept kbapi kbinfo kbip kbnetwork kbwinsock kbmt KB214397 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 214397
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com