Uso en el mundo real de TCP_DEFER_ACCEPT?

Estaba leyendo el manual httpd de Apache en línea y encontré una directiva para habilitar esto. Encontró una descripción en la página del manual para 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.

Luego encontré este artículo, pero aún no estoy claro para qué tipo de cargas de trabajo sería útil. Supongo que si httpdtiene una opción específica para esto, debe tener cierta relevancia para los servidores web. También supongo que es una opción y no solo cómo httpdfuncionan las conexiones de red, que hay casos de uso en los que lo desea y otros en los que no.

Incluso después de leer el artículo, no tengo claro cuál sería la ventaja de esperar a que se complete el apretón de manos de tres vías. Parecería ventajoso asegurarse de que no httpdserá necesario intercambiar la instancia relevante haciéndolo mientras el apretón de manos continúa en lugar de potencialmente causar ese retraso después de que se forme una conexión.

Para el artículo, también me parecería que, sin importar el TCP_DEFER_ACCEPTestado de un socket, todavía necesitarás cuatro paquetes (apretón de manos y luego datos en cada caso). No sé cómo reducen la cuenta a tres, ni cómo eso proporciona una mejora significativa.

Entonces, mi pregunta es básicamente: ¿Es solo una vieja opción obsoleta o hay un caso de uso real para esta opción?

(para resumir mis comentarios sobre el OP)

El apretón de manos de tres vías al que se refieren es parte del establecimiento de la conexión TCP, la opción en cuestión no se relaciona específicamente con esto. También tenga en cuenta que el intercambio de datos no es parte del protocolo de enlace de tres vías, esto solo crea la conexión TCP en el estado abierto / establecido.

Con respecto a la existencia de esta opción, este no es el comportamiento tradicional de un zócalo, normalmente el hilo del manejador del zócalo se despierta cuando se acepta la conexión (que todavía es después de que se completa el protocolo de enlace de tres vías), y para algunos protocolos la actividad comienza aquí ( por ejemplo, un servidor SMTP envía una línea de saludo 220), pero para HTTP el primer mensaje en la conversación es el navegador web que envía su línea GET / POST / etc., y hasta que esto suceda, el servidor HTTP no tiene interés en la conexión (aparte del tiempo ), por lo tanto, despertar el proceso HTTP cuando se completa la aceptación del socket es una actividad inútil, ya que el proceso se quedará dormido de nuevo inmediatamente esperando los datos necesarios.

Si bien existe el argumento de que despertar procesos inactivos puede hacer que estén 'listos' para un procesamiento posterior (recuerdo específicamente haber despertado terminales de inicio de sesión en máquinas muy antiguas y hacer que se conecten desde el intercambio), pero también puede argumentar que cualquier máquina que tenga intercambiado dicho proceso ya está demandando sus recursos, y hacer demandas innecesarias adicionales podría en general reducir el rendimiento del sistema, incluso si el rendimiento aparente de su hilo individual mejora (lo que también puede no ocurrir, una máquina extremadamente ocupada tendría cuellos de botella en el disco IO, lo que podría ralentiza otras cosas si cambiaste, y si está tan ocupado, el sueño inmediato podría cambiarlo de nuevo). Parece ser una apuesta, y en última instancia, la apuesta "codiciosa" no necesariamente da resultado en una máquina ocupada,

Mi consejo general con respecto a ese nivel de ajuste de rendimiento sería no tomar decisiones programáticas sobre lo que es mejor de todos modos, sino permitir que el administrador del sistema y el sistema operativo trabajen juntos para lidiar con los problemas de gestión de recursos: ese es su trabajo y son mucho más adecuado para comprender las cargas de trabajo de todo el sistema y más allá. Dar opciones y opciones de configuración.

Para responder específicamente a la pregunta, la opción es beneficiosa en todas las configuraciones, no al nivel que probablemente notarías, excepto bajo una carga extrema de tráfico HTTP, pero en teoría es la forma "correcta" de hacerlo. Es una opción porque no todos los sabores de Unix (ni siquiera todos los Linux) tienen esa capacidad y, por lo tanto, para la portabilidad, se puede configurar para que no se incline.

No tengo claro cuál sería la ventaja de esperar a que se complete el apretón de manos de tres vías.

Los apretones de manos de tres vías son un protocolo común en la telefonía de voz:

1. Servidor : "Buenas tardes, Epiphyte Corp."
2. Persona que llama: "Hola, este es Randy".
3. Servidor : "Sí, ¿en qué puedo ayudarlo?"
4. Persona que llama : el cuerpo de la llamada comienza a solicitar una broma

Son importantes en TCP para garantizar que se establezca el canal. Si el Cliente comenzó a enviar el cuerpo de la llamada antes de escuchar (3) existe la posibilidad de que el Servidor no esté escuchando o no esté listo. La audición (3) no garantiza que el Servidor no haya sufrido una combustión espontánea inmediatamente después de la transmisión, pero sí aumenta la confianza de que el Servidor está listo para recibir.

Como se señaló en la Wikipedia sobre Apretón de manos :

1. Alice [Servidor] responde con un mensaje de reconocimiento con el número de reconocimiento y + 1, que recibe Bob [Cliente] y al que no necesita responder .

Entonces, si está dispuesto a renunciar a un poco de certeza adicional de que el servidor está listo, el servidor puede omitir el paso (3) y el cliente simplemente asumirá que el servidor estaba listo. Esto convierte el intercambio de protocolo anterior en:

1. Servidor : "Buenas tardes, Epiphyte Corp."
2. Persona que llama: "Hola, este es Randy".
3. Persona que llama : "¿Conoces alguna broma sobre Imelda Marcos?"