Praktische Verwendung von TCP_DEFER_ACCEPT?

Question

Ich habe dieApache httpd-Handbuch onlineund bin auf eine Anweisung gestoßen, dies zu aktivieren. Ich habe in der Manpage eine Beschreibung für gefunden 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 fand ichDieser Artikelaber mir ist immer noch nicht klar, für welche Art von Workloads dies nützlich wäre. Ich gehe davon aus, dass, wenn httpdes eine Option speziell dafür gibt, diese für Webserver relevant sein muss. Ich gehe auch davon aus, dass es aufgrund der Tatsache, dass es eine Option ist und nicht nur, wie httpdNetzwerkverbindungen funktionieren, Anwendungsfälle gibt, in denen Sie sie wollen, und andere, in denen Sie sie nicht wollen.

Auch nach dem Lesen des Artikels ist mir nicht klar, was der Vorteil wäre, auf den Abschluss des Drei-Wege-Handshakes zu warten. Es wäre vorteilhaft, sicherzustellen, dass die entsprechende httpdInstanz nicht ausgetauscht werden muss, indem dies getan wird, während der Handshake noch läuft, anstatt diese Verzögerung möglicherweise zu verursachen, nachdem eine Verbindung hergestellt wurde.

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

Meine Frage lautet also im Wesentlichen: Handelt es sich hierbei lediglich um eine alte, veraltete Option oder gibt es einen tatsächlichen Anwendungsfall für diese Option?

Answer 1

(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, dieser erstellt lediglich die TCP-Verbindung im offenen/hergestellten Zustand.

Was die Existenz dieser Option betrifft, so ist dies nicht das herkömmliche Verhalten eines Sockets. Normalerweise wird der Thread des Socket-Handlers aufgeweckt, wenn die Verbindung akzeptiert wird (was immer noch nach Abschluss des Drei-Wege-Handshakes der Fall ist), und bei einigen Protokollen beginnt die Aktivität hier (z. B. sendet ein SMTP-Server eine Begrüßungszeile mit der Zeichenfolge 220). Bei HTTP ist die erste Nachricht im Dialog jedoch der Webbrowser, der seine GET/POST/usw.-Zeile sendet. Bis dies geschieht, hat der HTTP-Server kein Interesse an der Verbindung (außer dem Timeout). Daher ist das Aufwecken des HTTP-Prozesses nach Abschluss der Socket-Akzeptanz eine Verschwendung, da der Prozess sofort wieder in den Ruhezustand versetzt wird, während er auf die erforderlichen Daten wartet.

Es gibt sicherlich Argumente dafür, dass das Aufwecken inaktiver Prozesse diese für die weitere Verarbeitung „bereit“ machen kann (ich erinnere mich insbesondere daran, Login-Terminals auf sehr alten Maschinen aufgeweckt und aus dem Swap-Prozess geladen zu haben). Man kann jedoch auch argumentieren, dass jede Maschine, die den besagten Prozess ausgelagert hat, bereits ihre Ressourcen beansprucht und weitere unnötige Anforderungen die Systemleistung insgesamt verringern können – selbst wenn sich die Leistung Ihres einzelnen Threads scheinbar verbessert (was jedoch auch nicht der Fall sein muss, da eine extrem ausgelastete Maschine Engpässe bei der Festplatten-E/A hätte, die andere Dinge verlangsamen würden, wenn Sie sie auslagern würden, und wenn sie so ausgelastet ist, könnte der sofortige Ruhezustand sie gleich wieder auslagern). Es scheint sich um ein Glücksspiel zu handeln, und letzten Endes zahlt sich das „gierige“ Glücksspiel auf einer stark ausgelasteten Maschine nicht unbedingt aus, und es verursacht mit Sicherheit zusätzliche, unnötige Arbeit auf einer Maschine, auf der der Prozess bereits ausgelagert war – Ihr Ansatz ist für eine Maschine mit einem großen Speichersatz von Prozessen optimiert, die größtenteils inaktiv sind, und das Auslagern eines inaktiven Prozesses gegen einen anderen ist keine große Sache. Eine Maschine mit einem großen Speichersatz von aktiven Prozessen wird jedoch unter der zusätzlichen E/A leiden, und jede Maschine, deren Speicher nicht begrenzt ist, leidet darunter, jede CPU-gebundene Maschine wird schlechter dran sein.

Mein allgemeiner Ratschlag hinsichtlich dieser Leistungsoptimierungsstufe wäre, keine programmatischen Entscheidungen darüber zu treffen, was ohnehin am besten ist, sondern dem Systemadministrator und dem Betriebssystem zu erlauben, bei der Lösung der Ressourcenverwaltungsprobleme zusammenzuarbeiten – das ist ihre Aufgabe und sie sind viel besser geeignet, die Arbeitslasten des gesamten Systems und darüber hinaus zu verstehen. Geben Sie Optionen und Konfigurationsauswahlmöglichkeiten.

Um die Frage konkret zu beantworten: Die Option ist bei allen Konfigurationen von Vorteil, nicht in dem Ausmaß, das Sie wahrscheinlich jemals bemerken würden, außer bei extremer Belastung durch HTTP-Verkehr, aber es ist theoretisch die „richtige“ Vorgehensweise. Es ist eine Option, weil nicht alle Unix-Varianten (nicht einmal alle Linux-Varianten) diese Fähigkeit haben und sie daher aus Gründen der Portabilität so konfiguriert werden kann, dass sie nicht eingeschlossen wird.

Answer 2

Mir ist nicht klar, welcher Vorteil es hätte, auf den Abschluss des Drei-Wege-Handshakes zu warten.

Drei-Wege-Handshakes sind ein gängiges Protokoll in der Sprachtelefonie:

1. Server: „Guten Tag, Epiphyte Corp.“
2. Anrufer: „Hallo, hier ist Randy.“
3. Server: "Ja, wie kann ich Ihnen helfen?"
4. Anrufer:Hauptteil des Anrufs beginnt mit der Bitte um einen Witz

Sie sind in TCP wichtig, um sicherzustellen, dass der Kanal eingerichtet wird. Wenn der Client mit dem Senden begonnen hatHauptteil des AufrufsVor dem Hören von (3) besteht die Möglichkeit, dass der Server nicht zuhört oder nicht bereit ist. Das Hören von (3) garantiert nicht, dass der Server nach der Übertragung nicht sofort eine Selbstentzündung erleidet, erhöht jedoch die Sicherheit, dass der Server zum Empfang bereit ist.

Wie bereits erwähnt in derWikipedia zum Thema Händeschütteln:

1. Alice [Server] antwortet mit einer Bestätigungsnachricht mit der Bestätigungsnummer y + 1, die Bob [Client] empfängt undworauf 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 wird einfach davon ausgehen, dass der Server bereit war. Dadurch wird der obige Protokollaustausch zu:

1. Server: „Guten Tag, Epiphyte Corp.“
2. Anrufer: „Hallo, hier ist Randy.“
3. Anrufer: „Kennen Sie Witze über Imelda Marcos?“