Reale Verwendung von TCP_DEFER_ACCEPT?

Ich habe das Apache-httpd-Handbuch online durchgesehen und bin auf eine Richtlinie gestoßen, die dies ermöglicht. Eine Beschreibung in der Manpage gefunden für tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

Dann habe ich diesen Artikel gefunden, aber mir ist immer noch unklar, für welche Art von Workloads dies nützlich wäre. Ich gehe davon aus, dass httpdeine Option, die speziell dafür vorgesehen ist, für Webserver relevant sein muss. Ich gehe auch davon aus, dass dies eine Option ist und nicht nur, wie httpdNetzwerkverbindungen funktionieren , sondern dass es Anwendungsfälle gibt, in denen Sie dies wünschen, und andere, in denen dies nicht der Fall ist.

Selbst nach dem Lesen des Artikels ist mir nicht klar, welchen Vorteil es haben würde, auf den Abschluss des Drei-Wege-Handshakes zu warten. Es erscheint vorteilhaft, sicherzustellen, dass die betreffende httpdInstanz nicht ausgetauscht werden muss, während der Handshake noch läuft, anstatt möglicherweise diese Verzögerung nach dem Herstellen einer Verbindung zu verursachen.

Für den Artikel scheint es mir auch, dass Sie unabhängig vom TCP_DEFER_ACCEPTStatus eines Sockets immer noch vier Pakete benötigen (Handshake, dann jeweils Daten). Ich weiß nicht, wie sie den Countdown auf drei herabsetzen oder wie dies eine sinnvolle Verbesserung darstellt.

Meine Frage lautet also im Grunde: Ist dies nur eine veraltete Option oder gibt es einen konkreten Anwendungsfall für diese Option?

— Bratchley
quelle

Mir ist nicht klar, was Sie unter "Countdown auf drei" verstehen, was den Verdacht aufkommen lässt, dass Sie den Drei-Wege-Handschlag missverstehen. Dies ist eine TCP "Open Connection" -Transaktion und besteht aus insgesamt 3 übertragenen Paketen. Bis diese 3 abgeschlossen sind, gibt es keine Daten und keine Verbindung, die gültig ist. Daten fließen daher niemals in den Handshake-Overhead ein. Die Effizienzsteigerung, die durch TCP_DEFER_ACCEPT erzielt werden würde, wäre die Lücke zwischen dem Abschluss des TCP-3-Wege-Handshakes mit Akzeptanz und dem ersten Datenpaket (ich nehme an, hauptsächlich hier, um den 3-gegen-4-Wege-Handshake zu kommentieren)

— iain

Außerdem geht es nicht darum, das „Eintauschen“ zu vermeiden, sondern darum, keine Ressourcen zu verschwenden. Wenn das Auslagern ein Faktor für die Aktivierung eines HTTP-Workers werden sollte, müssen Sie Ihren Worker vorzeitig zum Akzeptanzpunkt einlagern, bevor die Daten bereitstehen. Wenn das Auslagern stattfindet, bedeutet dies, dass Sie etwas anderes erzwingen RAM ... etwas, das vielleicht etwas getan hat und wieder zwischen Ihrem Accept / Data-Teil ausgetauscht wird ... Welche Ressource auch immer - CPU, DiskIO, In-RAM-Seiten, wenn es keine Daten gibt, gibt es keinen Grund, Arbeit zu verursachen.

— iain

Wenn sich der Worker-Prozess bereits im Arbeitsspeicher befindet, ist die Latenz im Vergleich zum möglichen Festplattenbetrieb nicht sehr gering? Das "bis auf drei" ist ein Verweis auf den Artikel, der besagt, dass dies irgendwie dazu führen würde, dass sich das erste Datenpaket vom Client auf dem dritten Paket befindet.

— Bratchley

Außerdem wird das theoretische Einwechseln sowieso passieren, dies würde sich mit dieser TCP-Option nicht ändern. Ich sehe keine Vorteile darin, die Lücke zwischen dem Herstellen der TCP-Verbindung und der Datenübertragung zu schließen. Zumindest wenn Sie dies während des TCP-Verbindungsaufbaus tun, besteht die Möglichkeit, dass beide gleichzeitig auftreten (was die Zeitdauer verringert).

— Bratchley

Hätte gerade eine Antwort schreiben sollen ... Da dies eine Option ist, ist es nicht so, wie "normale" Unix-Standards funktionieren ... Insbesondere in Bezug auf HTTP ist der Schlüsselpunkt, dass der Client (Webbrowser) die Konversation mit dem initiiert GET line ... Der Server kümmert sich also nicht um die tatsächliche Verbindung, sondern nur um die ersten Daten. Im Gegensatz zu SMTP, bei dem der Client warten muss, bis der Server die Meldung "220 welcome banner" ausgibt. Dh DIESER Server muss beim Verbinden Bescheid wissen, nicht bei Daten.

— iain

Antworten:

(um meine Kommentare zum OP zusammenzufassen)

Der Drei-Wege-Handshake, auf den sie sich beziehen, ist Teil des TCP-Verbindungsaufbaus. Die betreffende Option bezieht sich nicht speziell darauf. Beachten Sie auch, dass der Datenaustausch nicht Teil des Drei-Wege-Handshakes ist, sondern lediglich die TCP-Verbindung im geöffneten / eingerichteten Zustand erstellt.

In Bezug auf das Vorhandensein dieser Option ist dies nicht das traditionelle Verhalten eines Sockets. Normalerweise wird der Thread des Socket-Handlers aufgeweckt, wenn die Verbindung akzeptiert wird (noch nachdem der Drei-Wege-Handshake abgeschlossen wurde). Bei einigen Protokollen beginnt die Aktivität hier ( Beispiel: Ein SMTP-Server sendet eine 220-Begrüßungszeile. Bei HTTP sendet der Webbrowser jedoch als erste Nachricht in der Konversation seine GET / POST / etc-Zeile. Bis dahin hat der HTTP-Server kein Interesse an der Verbindung (außer dem Timing) Es ist daher eine Verschwendung, den HTTP-Prozess zu aktivieren, wenn die Socket-Annahme abgeschlossen ist, da der Prozess sofort wieder einschlafen wird und auf die erforderlichen Daten wartet.

Zwar gibt es durchaus Argumente dafür, dass durch das Aufwecken von inaktiven Prozessen diese für die weitere Verarbeitung "bereit" gemacht werden können (ich erinnere mich insbesondere, dass ich Anmeldeterminals auf sehr alten Computern aufgeweckt habe und sie aus dem Swap-Modus mit hineingepackt habe), aber Sie können auch argumentieren, dass jeder Computer dies hat Der ausgelagerte Prozess stellt bereits Anforderungen an die Ressourcen, und weitere unnötige Anforderungen können die Systemleistung insgesamt verringern - selbst wenn sich die scheinbare Leistung des einzelnen Threads verbessert (was möglicherweise auch nicht der Fall ist, würde ein stark ausgelasteter Computer Engpässe bei der Datenträger-E / A aufweisen, die dies zur Folge haben würden verlangsamen Sie andere Dinge, wenn Sie eingewechselt sind, und wenn es so beschäftigt ist, kann der sofortige Schlaf es gleich wieder auswechseln). Es scheint ein Glücksspiel zu sein, und letztendlich zahlt sich das "gierige" Glücksspiel nicht unbedingt auf einem ausgelasteten Computer aus.

Mein allgemeiner Rat bezüglich dieser Leistungsoptimierung wäre, keine programmatischen Entscheidungen darüber zu treffen, was sowieso am besten ist, sondern es dem Systemadministrator und dem Betriebssystem zu ermöglichen, zusammenzuarbeiten, um die Ressourcenverwaltungsprobleme zu lösen - das ist ihre Aufgabe und sie sind viel besser geeignet, um die Auslastung des gesamten Systems und darüber hinaus zu verstehen. Geben Sie Optionen und Konfigurationsoptionen an.

Um die Frage genau zu beantworten, ist die Option für alle Konfigurationen von Vorteil, und zwar nicht in dem Ausmaß, das Sie wahrscheinlich jemals bemerken würden, es sei denn, der HTTP-Datenverkehr ist extrem hoch, aber theoretisch ist dies die "richtige" Methode. Dies ist eine Option, da nicht alle Unix-Versionen (auch nicht alle Linux-Versionen) über diese Funktion verfügen und daher für die Portabilität so konfiguriert werden kann, dass sie nicht geneigt sind.

— Iain
quelle

Danke für die tolle Zusammenfassung. Während die Serverauslastung und das Auslagern / Aufwecken im Leerlauf einen potenziellen Vorteil darstellen (einen, der, wie Sie bereits erwähnt haben, nuanciert ist), gibt es klare Vorteile, wenn Sie sich einen HTTP-Server ansehen, der Clients mit hoher und niedriger Latenz bedient. Wenn Sie beispielsweise den Apache-Webserver ausführen, steht eine feste Anzahl von Serverprozessen / -threads zur Verfügung. Dies bedeutet, dass zu einem bestimmten Zeitpunkt eine feste Anzahl von Clients bedient werden kann. Wenn ein Serverprozess nicht "aufgebraucht" wird, während das "Daten" -Paket von einem Client nicht angekommen ist, kann dies bedeuten, dass der Serverprozess in der Zwischenzeit einen anderen Client bedienen kann.

— Ram

-1

Ich bin mir nicht sicher, welchen Vorteil es hat, auf den Drei-Wege-Handshake zu warten.

Drei-Wege-Handshakes sind ein verbreitetes Protokoll in der Sprachtelefonie:

Server : "Guten Tag, Epiphyte Corp."
Anrufer : "Hallo, das ist Randy."
Server : "Ja, wie kann ich Ihnen helfen?"
Anrufer : Der Hauptteil des Anrufs fordert einen Witz an

Sie sind in TCP wichtig, um sicherzustellen, dass der Kanal eingerichtet ist. Wenn der Client vor dem Hören von (3) mit dem Senden von Anrufen begonnen hat, besteht die Möglichkeit, dass der Server nicht zuhört oder nicht bereit ist. Das Hören (3) garantiert nicht, dass der Server nach der Übertragung nicht sofort eine Selbstentzündung erlitten hat, erhöht jedoch das Vertrauen, dass der Server empfangsbereit ist.

Wie in der Wikipedia zum Handshaking vermerkt :

Alice [Server] antwortet mit einer Bestätigungsnachricht mit der Bestätigungsnummer y + 1, die Bob [Client] erhält und auf die er nicht antworten muss .

Wenn Sie also bereit sind, auf ein wenig zusätzliche Sicherheit zu verzichten, dass der Server bereit ist, kann der Server Schritt (3) überspringen, und der Client geht lediglich davon aus, dass der Server bereit ist. Dies macht den obigen Protokollaustausch zu:

Server : "Guten Tag, Epiphyte Corp."
Anrufer : "Hallo, das ist Randy."
Anrufer : "Kennst du irgendwelche Witze über Imelda Marcos?"

— msw
quelle

Es ist mehr als nur Vertrauen, das Sie senden, bevor 3way abgeschlossen ist und Ihre Daten zusammengefasst sind. Beim Aufbau von TCP-Verbindungen in modernen OS-Stacks werden bis zum 3. Teil der Verbindung tatsächlich keine Verbindungsdaten in Tabellen protokolliert, die Anforderung der 3. Nachricht, bevor Ressourcen verbraucht werden, erfolgt über die Verwendung von "Syn-Cookies" und verhindert "Syn Attacks" (das sind gefälschte Quell-IP-Handshake-Pakete 1. Paket 3, die diese gefälschte Quell-IP untergraben). Daher existiert vor diesem Punkt keine Verbindung oder kein Eintrag dafür.

— iain

Das Hören (3) garantiert nicht, dass der Server nach der Übertragung nicht sofort eine Selbstentzündung erlitten hat, erhöht jedoch das Vertrauen, dass der Server empfangsbereit ist.

— msw

Erhöhen, ansteigen? Von null? Nun ja, ich denke wörtlich, das ist wahr, aber die meisten Leute würden implizieren, dass es vor Paket 3 / some / chance gab, sich zu erhöhen. Und das gibt es nicht. Es ist nur die Redewendung "Erhöhen Sie das Vertrauen", die ich nicht mag, und ich glaube nicht, dass die Berücksichtigung von 0,001% "Hauptproblemen der realen Welt" dabei hilft, das Problem klar zu halten. Klar, bevor der Server das Paket bekommt, könnte ein Atomkrieg stattfinden. Es könnte eine Menge passieren.

— 13.

Außerdem habe ich gerade den letzten Absatz aufgegriffen, in dem Sie implizieren, dass Schritt 3 optional ist. Es ist nicht absolut nicht. Lesen Sie den Absatz noch einmal, Schritt 3 lautet "Alice antwortet mit einer Bestätigung". das ist nicht optional. Bob, der darauf antwortet (ein theoretischer 4. Schritt), ist.

— Iain