Linux – Verwendung von Tcp_defer_accept in der realen Welt?

Ich habe das Apache httpd-Handbuch online gelesen und bin auf eine Anweisung gestoßen, um dies zu aktivieren. Eine Beschreibung in der Manpage für tcp gefunden :

   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 ich bin mir immer noch nicht sicher, für welche Art von Workloads dies nützlich wäre. Ich gehe davon aus, dass wenn httpd eine Option speziell dafür hat, muss sie eine gewisse Relevanz für Webserver haben. Ich gehe auch davon aus, dass es eine Option ist und nicht nur, wie httpd macht Netzwerkverbindungen, dass es Anwendungsfälle gibt, wo Sie es wollen und andere, wo Sie es nicht wollen.

Selbst nachdem ich den Artikel gelesen habe, bin ich mir nicht sicher, welchen Vorteil es hätte, auf den Abschluss des Drei-Wege-Handshakes zu warten. Es erscheint vorteilhaft sicherzustellen, dass der relevante httpd nicht ausgetauscht werden muss Beispielsweise indem Sie dies tun, während der Handshake noch läuft, anstatt möglicherweise diese Verzögerung zu verursachen, nachdem eine Verbindung hergestellt wurde.

Für den Artikel scheint mir auch der TCP_DEFER_ACCEPT egal zu sein Status eines Sockets benötigen Sie immer noch vier Pakete (jeweils Handshake dann Daten). Ich weiß weder, wie sie den Countdown auf drei herunterbekommen, noch wie das eine sinnvolle Verbesserung darstellt.

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

Akzeptierte Antwort:

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

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 (was immer noch der Fall ist, nachdem der Drei-Wege-Handshake abgeschlossen ist), und für einige Protokolle beginnt die Aktivität hier ( z.B. sendet ein SMTP-Server eine 220-Begrüßungszeile), aber für HTTP ist die erste Nachricht in der Konversation der Webbrowser, der seine GET/POST/etc-Zeile sendet, und bis dies geschieht, hat der HTTP-Server kein Interesse an der Verbindung (außer dem Timing it out), daher ist das Aufwecken des HTTP-Prozesses nach Abschluss der Socket-Akzeptanz eine verschwenderische Aktivität, da der Prozess sofort wieder einschläft und auf die erforderlichen Daten wartet.

Es gibt zwar sicherlich Argumente dafür, dass das Aufwecken von Leerlaufprozessen sie für die weitere Verarbeitung „bereit“ machen kann (ich erinnere mich insbesondere daran, Anmeldeterminals auf sehr alten Maschinen aufzuwecken und sie aus dem Swap hineinzutuckern), aber Sie können auch argumentieren, dass jede Maschine, die hat Der ausgelagerte Prozess stellt bereits Anforderungen an seine Ressourcen, und weitere unnötige Anforderungen können die Systemleistung insgesamt verringern – selbst wenn sich die scheinbare Leistung Ihres einzelnen Threads verbessert (was möglicherweise auch nicht der Fall ist, würde eine extrem ausgelastete Maschine Engpässe bei der Festplatten-E / A haben, was würde verlangsamen Sie andere Dinge, wenn Sie einwechseln, 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 auf einer ausgelasteten Maschine nicht unbedingt aus und verursacht sicherlich zusätzliche unnötige Arbeit auf einer Maschine, auf der der Prozess bereits ausgetauscht wurde – Ihr Ansatz optimiert für eine Maschine mit a große Speichermenge von Prozessen, die meistens inaktiv sind, und das Austauschen einer Ruhephase gegen eine andere ist keine große Sache, aber eine Maschine mit einer großen Speichermenge von aktiven Prozessen wird unter zusätzlichen IO leiden, und jede Maschine, die nicht speicherbegrenzt ist, leidet, Jede CPU-gebundene Maschine wird schlechter dran sein.

Verwandte:Linux – Warum behält rsync unter Linux nicht alle Zeitstempel (Erstellungszeit) bei?

Mein allgemeiner Rat in Bezug auf dieses Niveau der Leistungsoptimierung wäre, ohnehin keine programmatischen Entscheidungen darüber zu treffen, was am besten ist, sondern dem Systemadministrator und dem Betriebssystem zu erlauben, bei der Bewältigung der Ressourcenverwaltungsprobleme zusammenzuarbeiten – das ist ihre Aufgabe und sie sind viel besser geeignet, um die Workloads des gesamten Systems und darüber hinaus zu verstehen. Geben Sie Optionen und Konfigurationsoptionen an.

Um die Frage konkret zu beantworten, ist die Option bei allen Konfigurationen von Vorteil, nicht in dem Ausmaß, das Sie wahrscheinlich jemals bemerken würden, außer unter einer extremen Last von HTTP-Verkehr, aber es ist theoretisch der „richtige“ Weg, dies zu tun. Es ist eine Option, weil nicht alle Unix-Varianten (nicht einmal alle Linux-Varianten) diese Fähigkeit haben und es daher aus Gründen der Portabilität so konfiguriert werden kann, dass es nicht enthalten ist.