Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Bestimmte Programmiertechniken treten auf Leistungsprobleme auf, die mit der Implementierung von TCP/IP verbunden sind. Solche Leistungsprobleme deuten nicht darauf hin, dass TCP/IP ineffizient oder leistungsengpässe ist; Stattdessen werden diese Probleme erkannt, wenn TCP/IP-Vorgänge nicht verstanden werden.
Die folgenden Probleme identifizieren häufige Szenarien, in denen die Kombination aus TCP/IP-Vorgang und Netzwerkanwendungsentwicklung zu einer schlechten Leistung führt.
Connect-Heavy-Anwendungen.
Einige Anwendungen instanziieren eine neue TCP-Verbindung für jede Transaktion. Die TCP-Verbindungseinrichtung benötigt Zeit, trägt zusätzliche RTTs bei und unterliegt langsamen Start. Darüber hinaus unterliegen die geschlossenen Verbindungen TIME-WAIT, die Systemressourcen verbraucht.
Connect-Heavy-Anwendungen sind häufig üblich, da sie leicht zu erstellen sind; Tests und Fehlerbehandlung sind sehr einfach. Das Erkennen von Fehlern bei einer persistenten Verbindung kann erheblichen Code und Aufwand in Anspruch nehmen und ist daher manchmal nicht abgeschlossen.
Beheben Sie diese Situation, indem Sie die TCP-Verbindung wiederverwenden. Dies kann zur Serialisierung über die TCP-Verbindung führen, es sei denn, die Transaktionen werden über mehrere Verbindungen multixiert. Wenn dieser Ansatz getroffen wird, sollte die Anzahl der Verbindungen auf zwei beschränkt sein, und es ist eine Umrahmung auf Anwendungsebene und eine erweiterte Fehlerbehandlung erforderlich.
Leere Sendepuffer und Blockierungssendungen.
Das Deaktivieren der Pufferung mithilfe der setockopt--Funktion zum Festlegen des Sendepuffers (SO_SNDBUF) auf Null ähnelt dem Deaktivieren der Datenträgerzwischenspeicherung. Beim Festlegen des Sendepuffers auf Null und ausstellen von Blockierungssendungen hat eine Anwendung die Wahrscheinlichkeit, dass eine 200-Millisekunden verzögerte Bestätigung erreicht wird.
Deaktivieren Sie die Sendepufferung nicht, es sei denn, Sie haben die Auswirkungen in allen Netzwerkumgebungen berücksichtigt. Eine Ausnahme: Das Streamen von Daten mit überlappendem E/A sollte den Sendepuffer auf Null festlegen.
Send-Send-Receive Programmiermodell.
Die Strukturierung einer Anwendung zur Durchführung von Send-Send-Empfangen erhöht die Wahrscheinlichkeit, dass der Nagle-Algorithmus auftritt, was zu einer Verzögerung von RTT+200 ms führt. Der Nagle-Algorithmus kann auftreten, wenn der letzte Sendewert kleiner als die maximale TCP-Segmentgröße (MSS, die maximalen Daten in einem einzelnen Datagramm) ist. MSS kann ein sehr großer Wert (64 KB in IPv4 und sogar größer in IPv6) sein. Zählen Sie daher nicht auf ein typisch kleines MSS. Eine bessere Option besteht darin, die beiden Senden mithilfe der WSASend- oder Memcpy--Funktion in einem einzigen Sende zu kombinieren.
Große Anzahl gleichzeitiger Verbindungen.
Gleichzeitige Verbindungen sollten nicht über zwei hinausgehen, außer in Speziellen Anwendungen. Das Überschreiten von zwei gleichzeitigen Verbindungen führt zu verschwendeten Ressourcen. Eine gute Regel besteht darin, bis zu vier kurzlebige Verbindungen oder zwei dauerhafte Verbindungen pro Ziel zu haben.
Verwandte Themen